Date: Thu, 19 Oct 2000 21:34:55 -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: <14831.44879.402723.564087@guru.mired.org> In-Reply-To: <63199379@toto.iv>
next in thread | previous in thread | raw e-mail | index | archive | help
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. 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. > 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. In theory, it's pretty easy: generate the dependency list for each package to be updated. merge and tsort the lists of ports foreach port in the list: try: make in <portdir> pkg_delete the old version except: Tell the user it died and bail reverse the port list foreach port in the list: try: make install in <portdir> except: Tell the user it died and bail Note that "pkg_version -c" tries to do this for you. However, "pkg_version -c" has at least one serious problem. All my installed packages are up to date - but I get *96* lines from "pkg_version -c", because there are multiple versions of some of the ports. In some of these cases, it just deinstalls and rebuilds the current port. In some, it's going to upgrade a package where I'm running an older one (which is still in the ports tree) on purpose. In the worst case - well, consider this: # # glib # multiple versions (index has 1.2.8,1.3.1) # cd /usr/ports/devel/glib13 make && pkg_delete -f glib-1.2.8 make install It's going to delete my glib 1.3, and install 1.2! I don't even want to think what it would have done if I'd had japanese/w3m installed instead of www/w3m. 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. That's what kept me from turning the above pseudo code into a real script: I couldn't figure out a reliable way to go from a package name to a port name. I figure that the script wouldn't be much longer than the pseudo, as a good HLL has most of the operations needed as primitives or in a library. But getting that <portdir> is a pain. I though briefly about trying to do this by grovelling through the ports Makefile, but that's - well, you can see how well pkg_version does at it. > The problem with the current package system is that it does not resolve > dependency problems by itself as the ports does. How could it anyways? A > package is all it says: a package of information regarding a particular > piece of software. It might include information on which other packages > are needed by this one, but nothing else. 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? Come to that, if you don't believe that packages can do this job, then there's no way you can make ports that load packages do it, as the port may depend on a package that depends on things you don't have installed. Once you fix that, you might as well just install the package you're building instead of the port, and let the software that deals with package technologies work there. Except it's already been fixed, and packages behave like you want. > 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. > I would be personnally ready to work on the ports for this to happen but I > want to know wether or not this would be a good idea, or if there's > already some work in pregress. Ok, the right place to talk about ports is ports@freebsd.org. However, this is a recurring topic there. Between that and it not being clear about whether you wanted to work on packages or ports, I left the discussion here. If you're wanting to work on the package system, check with jkh. The interface library is being worked on, but I'm not sure about the rest of it. <mike *) I know, I know - "ports aren't part of FreeBSD". I choose to distinguish between locally written/installed software and them. You should thank me - I'm helping keep the ports tree PREFIX-clean! 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?14831.44879.402723.564087>