From owner-freebsd-questions Tue Oct 24 1:18:19 2000 Delivered-To: freebsd-questions@freebsd.org Received: from guru.mired.org (okc-27-149-77.mmcable.com [24.27.149.77]) by hub.freebsd.org (Postfix) with SMTP id E5D5837B479 for ; Tue, 24 Oct 2000 01:18:15 -0700 (PDT) Received: (qmail 45084 invoked by uid 100); 24 Oct 2000 08:18:14 -0000 From: Mike Meyer MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14837.17862.862159.95960@guru.mired.org> Date: Tue, 24 Oct 2000 03:18:14 -0500 (CDT) To: Antoine Beaupre Cc: questions@freebsd.org Subject: Re: Adding the package concept to the ports collection In-Reply-To: References: <14831.44879.402723.564087@guru.mired.org> X-Mailer: VM 6.75 under 21.1 (patch 10) "Capitol Reef" XEmacs Lucid X-face: "5Mnwy%?j>IIV\)A=):rjWL~NB2aH[}Yq8Z=u~vJ`"(,&SiLvbbz2W`;h9L,Yg`+vb1>RG% *h+%X^n0EZd>TM8_IB;a8F?(Fb"lw'IgCoyM.[Lg#r\ Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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 .