Date: Tue, 24 Oct 2000 03:18:14 -0500 (CDT) From: Mike Meyer <mwm@mired.org> To: Antoine Beaupre <beaupran@IRO.UMontreal.CA> Cc: questions@freebsd.org Subject: Re: Adding the package concept to the ports collection Message-ID: <14837.17862.862159.95960@guru.mired.org> In-Reply-To: <Pine.LNX.4.21.0010231336280.9745-100000@phobos.IRO.UMontreal.CA> References: <14831.44879.402723.564087@guru.mired.org> <Pine.LNX.4.21.0010231336280.9745-100000@phobos.IRO.UMontreal.CA>
next in thread | previous in thread | raw e-mail | index | archive | help
Antoine Beaupre writes: > On Thu, 19 Oct 2000, Mike Meyer wrote: > > > Antoine Beaupre writes: > > > I was wondering if it would be possible to add the 'package' concept to > > > the ports collection in a sense that the database would include the name > > > of the package or if there's none, why. An install target would then only > > > have to download the package and save the compilation time. I also > > > think that the package would be smaller than the source, and so, faster to > > > download. > > Yup, that's the advantages of packages. However, you can't go from > > installing a port to installing packages. For instance, I set > > LOCALBASE=/usr/opt in /etc/make.conf. A prebuilt package with > > LOCALBASE=/usr/local won't work, because the libraries it's looking > > for won't be in the right place, even though the dependencies are > > met. Not to mention violating my system policies by installing what I > > consider an optional part of FreeBSD(*) in /usr/local. > Are you sure about that? Actually, I'm not sure about libraries specificall (I generally don't use packages). However, anything with wired-in path names won't work - and that I do know, having run into it. > Well then this is Yet Another Problem with the packages. Not > PREFIX-independent. Well, I think it's a bit much to ask people to fix ports so that you can compile them targeted at /usr/foo, and have them actually work when loaded in /usr/bar. Nuts - even fixing things so that everything works when you change PREFIX is difficult. Anything using the PERL package meachanisms isn't PREFIX-clean, because the path name to the perl library location is determined at PERL build time. Ditto for Python modules, etc. > > If you really want this, why don't you apply it to the port you're > > working on, and install the package instead of the port? Once you've > > got things set up right, it should all work as you describe. Caveat: I > > don't use packages, and so have never done this. > The problem is that I am lazy and have sometimes many packages to > install. And what I end up doing is to download the package, try to > install it, download the dependencies, try to install them, etc... What I > would like would be for pkg_add to download the necessary dependencies by > itself... It should do that; check out the manual page carefully, especially the "-r" option. > > > I think the port collection as it is now has several drawbacks, in terms > > > of a software indexing facility, that is. Upgrading ports is a nightmare. > > > The more we go, the more various ports have dependency lists that grow and > > > grow. So when a single package such as GTK or ORBit gets updated, a whole > > > chunk of ports have to be updated too. The problem is that > > > "updated" means: > > Well, the details aren't right (updating GTK may cause a package > > dependent on it to be updated, but it doesn't mean you have to get the > > new distfile for that package; just recompile it), but updating ports > > is certainly a problem. > Yes. I got it the wrong way around. It's more like "updating gimp needs a > later version of gtk which will install over an older one..." Yup. And you can either recompile the ports that depend on the older version, or had a symlink so they find the new library. I've as yet to run into a case where I had to have both versions of a library around. > > It's going to delete my glib 1.3, and install 1.2! > Which is often needed by other older packages... Yes. I know. This is not > nice. The multiple version thing is really a big problem. Well, I don't think it's a big problem. If you needed two versions of a library installed, that would be a *big* problem. > > And right there is the root of the problem. A port name has two > > selectors - the category and the name: www/w3m; sysutils/grub, > > devel/glib13, etc. In that last case, the "name" is a composite of the > > package name and the version. Packages just capture the name and > > version, and don't notice when the version creeps into the name. > One thing we could do would be to integrate the "category" and the > "version" into the name. It would be a good thing since I'm always looking > around in /var/db/pkg wondering: "do I have a good cdplayer package?" or > "what's that chat client name again?"... I think that's overkill. Just putting the port name as a comment in the packing list will do the job. > > First, packages *do* include the dependency information. And what else > > do you need? pkg_add will auto-install the required packages for you - > > which is exactly what you're wanting it to do, right? > If they're available on the local machine. Or am I mistaken? I'm pretty sure you're mistaken, but can't confirm it because I don't use the things. > > > Is it me or all this woudn't be that hard to implement? Just a PACKAGENAME > > > variable along with a version variable of some sort (PORTVERSION would > > > probably be OK) and a PACKAGE_SITE hierarchy of variables. That would be > > > the biggest desgin problem... > > The package system needs a rewrite before you can add a formal > > "update" method for ports, which would be nice to have. If you're > > going to do that, jkh has a wishlist for packages that include things > > like an archive format with a directory, a secure scripting language, > > a device-independent UI library, etc. > Yeah... I have to read this article again. URL? I finally found it at <URL: http://people.FreeBSD.org/~alex/libh/ >. <mike To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?14837.17862.862159.95960>