[Midnightbsd-mports] How to prevent the automatic use of cached installed packages with old dependencies?

[Lucas Holt]

On May 19, 2008, at 6:45 PM, Stevan Tiefert wrote:
> ...

> During the installation of linux-firefox the process tried to use  
> also the cached packages and stopped during the build of linux_base- 
> fc-4 when it wanted to use the rpm-*, gcpio-* and libpopt-*- 
> packages. The error hinted me to a missing libintl.so.6 (but at the  
> same time gettext 0.16.1 with libintl.so.8 was installed) which was  
> in gettext-0.14 (an outdated build-dependency). I had to build these  
> three again and then linux_base-fc-4 was ok. After the first starts  
> of linux-firefox it crashed with coredumps and the error hintet me  
> to a problem with linux-fontconfig which also was a cached installed  
> package with the outdated build-dependency to gettext-0.14. After a  
> rebuild of linux-fontconfig the browser was working how it should.
>
> My question is: Which behavior is wrong? Mine or mports :-) ?


I've been bitten by this before.  There was a discussion about  
removing cached packages, but I don't remember what the outcome of  
that was.  I typically delete all the packages when I'm doing a big  
update (like KDE or Gnome) to avoid this.  One possible solution is to  
use a tool like portupgrade to update ports depending on a package as  
well.  (it will rebuild them)

In the future, this can be avoided with mport, the tool to update  
packages that ctriv@ is working on.  The other factor is that  
PORTREVISION needs to get bumped more frequently when dependancies are  
updated.  We sometimes forget to do this and it causes a lot of  
problems.

Going from 0.1.1 mports to now is a big jump.  When I setup a system  
now, I don't install any packages for this reason.  I just checkout  
the latest mports.  In my opinion, we need to get automated updates of  
packages on the FTP server for current and maybe 0.1.1 so users will  
always have a bunch of matching packages and they can avoid mports.   
(when it makes sense)

In order to do that we need the following:

mport utility finished or

1.  A method to sort out packages by license to be put on the FTP  
server.  We may also need to have a special whitelist for packages  
that are in the other category that we can distribute.  At the very  
least, GPL, BSDL, and perl stuff should be up.

2. A script to generate the symlinks the pkg_add tool is expecting.   
ctriv@ and I had a go at this part recently.

3. A script to let the magus cluster upload new packages after a run  
is "approved".  This is tricky because packages are not stored with  
the database server anymore.  This isn't that important as we just  
need to scp the files to stargazer.

4. Make sure that INDEX-6 is updated with these packages (or a newer  
version) .  Right now I'm manually updating this when I remember.

We also need to decide how to deal with old packages and what the best  
behavior is with a release.  When we make packages for a release, a  
special index file is generated for the CD and placed on the FTP  
server as well.  That allows you to do an FTP install of say 0.1.1 and  
grab the same packages that are on the CD.  The other issue in 0.1.1's  
case is that we had x.org 6.9 and so a package install from ftp with  
newer packages might screw up royally since sysinstall knows nothing  
about x.org 7's modular nature.  That might need to be tested.

This interaction is important to figure out.  We might want to change  
the way we get new packages.  A user might want a choice between the  
packages that came with the release or new ones.  I think ubuntu does  
this.  I can select dvd packages, ftp packages, or updated ones?


Regardless, Stevan's experience demonstrates a usability problem for  
end users.  There are several ways to deal with it, but our target  
userbase isn't going to deal with it.

Lucas Holt
Luke at FoolishGames.com
________________________________________________________
MidnightBSD.org (Free OS)
JustJournal.com (Free blogging)