Date: Mon, 23 Oct 2000 13:51:41 -0400 (EDT) From: Antoine Beaupre <beaupran@IRO.UMontreal.CA> To: Mike Meyer <mwm@mired.org> Cc: questions@freebsd.org Subject: Re: Adding the package concept to the ports collection Message-ID: <Pine.LNX.4.21.0010231336280.9745-100000@phobos.IRO.UMontreal.CA> In-Reply-To: <14831.44879.402723.564087@guru.mired.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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? Well then this is Yet Another Problem with the packages. Not PREFIX-independent. > 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... > > 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..." > 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! Which is often needed by other older packages... Yes. I know. This is not nice. The multiple version thing is really a big problem. > 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. 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?"... > 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. Yes. This is really a problem I did not even think of then. I think this is getting way out of control. > > 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? If they're available on the local machine. Or am I mistaken? > 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. I think I'll do some tests before getting further into this. I seem to have missed a good part of pkg_ad functionalities (i.e. I know it can install a package from a remote anonymous ftp site, but I didn't think it could do it for dependencies) > > 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 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. Yeah. I'll have to think this over. A. Si l'image donne l'illusion de savoir C'est que l'adage pretend que pour croire, L'important ne serait que de voir Lofofora 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?Pine.LNX.4.21.0010231336280.9745-100000>