Date: Tue, 27 Nov 2001 00:32:49 -0600 From: Mike Meyer <mwm@mired.org> To: Simon J Mudd <sjmudd@pobox.com> Cc: questions@freebsd.org Subject: Re: Packaging with ports (was: gv port builds but fails - needing libpng.so.4) Message-ID: <15363.13201.327012.470117@guru.mired.org> In-Reply-To: <119510040@toto.iv>
next in thread | previous in thread | raw e-mail | index | archive | help
Simon J Mudd <sjmudd@pobox.com> types: > On Mon, 26 Nov 2001, Mike Meyer wrote: > > > I'm still surprised that I'm allowed to install kdelibs-2.2_3 > > > over kdelibs-2.1.1. That IMHO shouldn't be allowed. > > I've already addressed why it's allowed, and should continue to be > > allowed. > If there are no conflicts it makes sense (using a different PREFIX for > example). If there are conflicts it doesn't make sense. It's not that simple. If I'm upgrading from libfoo.so.1 to libfoo.so.2, then instaling .2 over .1 means I don't break the applications that depend on .1. Later, when I delete .1 I'm probably going to screw up .2. On the other hand, at that time I'll be reinstalling everything that depends on .1 anyway, so reinstalling .2 isn't that much of a problem. > What I was getting at here is that it's easy to shoot yourself in the toe > and _sometimes_ it's IMO too easy. > > In the end I don't think we are arguing about content, more about end-user > (system administrator in this case) presentation of the packaging system. Yup. I've agreed that having packages test the plist and warn you if any of the files already exist would be a good thing. Even for ports, it'd be a good thing - just a lot harder to do. > > > Those files with different paths aren't affected. > > > Those files with the same names which differ will effectively wipe out the > > > older version. this conflict effectively makes the stored package > > > information wrong and misleading. > > Yup. That's just one reason for deleting the old version of a package > > before installing a new one. > perhaps portupgrade should be a basic part of the port system. that way it > would be more consistent if I could do a "make upgrade" There are two problems with that. One is that it's a stop-gap, waiting on the libh work. The second is that it would require putting ruby in the base system. That in itself will generate a lot of resistance. > [snip] > > You aren't supposed to install two packages that use the same > > file. That usually indicates an error on the users part. > > A check could probably be added to pkg_add for that. Doing it for > > ports is more interesting. > But these days an installed port is registered as if it were a package. > So is there any difference from a users point of view between the two? For the ultimate end-user, no. As a sysadmin, I certainly think so. Ports provide a lot more flexibility, but use a lot more resources. > > Basically, it just didn't work worth diddly. There's no option - at > > least on the version I have - to make it automatically install rpm's > > that are required but aren't on the system. > Yes, I agree this is one of the things about ports that I really like. > While /usr/ports when "clean" is not tiny it is very useful, and not > having to search here or there for required packages is definitely a > god-send. I heartedly agree. Obviously all the information about all > ports is also at hand which for contributed rpms isn't the case either. You don't need /usr/ports installed to get the "automaticly fetch dependencies" feature. pkg_add will do the same thing for you. If you're fetching the packages from a remote site, it will try to fetch the dependency packages remotely as well. > > > I think that perhaps "make install" in ports is rather dangerous. > > > there appears to be no checks that the installed software will > > > overwrite existing packages or software. Perhaps this could be > > > improved, or am I missing some command to avoid this problem? > > Nope, you're not missing a command. The problem is that "make install" > > normally just hands things off to the installation procedure for the > > program that was ported. It might be possible to add a > > "checkoverwrites" target that uses the plist, but I'm not sure. Some > > ports build the plist on the fly. > This obviously complicates the installation process, one of the current > pains with rpm. However with rpm (and the ports could do the same thing) > you install into an install root to generate the binaries. With the > ports you'd need to do this before recopying the files to their final > locations. I can see people seeing this "double copy" process as being > unnecessary, but it does allow you to generate your plist dynamically. You don't have to go through that. Ports have "packing lists" in them. The catch is that some ports generate them dynamically depending on the build-time environment. If it weren't for that, you could take the packing list and PREFIX and check for the files. Once the package is built, the plist is fixed, so the problem goes away. > An alternative would simply to see if you would install over a file _while > installing_ and be able to stop/warn the user if that happens. In rpm > this is automatic. This isn't contemplated for the reasons you state with > the ports. That alternative doesn't get you anything, which is why I never mentioned it. You get half-way through installing a package and it complains, so what happens next? If you abort the install, you've got half of a package installed and have to figure out how to back it out. If you overwrite the file anyway, you may have just broken some other package, and won't be able to remove that other package without breaking this one. If you don't overwrite the file, you may break *this* package, and will have to change the packing list on the fly to keep backing this package out from breaking the other package. I figure it's much easier just to do it beforehand in the first place. BTW, if it's not obvious, two ports installing the same file is considered a problem in the ports. The only exceptions are when the two ports are two different versions of one application - say a development and stable version, or one that expects a4 paper and one that expects us letter, or with different language options. <mike -- Mike Meyer <mwm@mired.org> http://www.mired.org/home/mwm/ Q: How do you make the gods laugh? A: Tell them your plans. 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?15363.13201.327012.470117>