Subject: problems with packages (was Re: CVS commit: src/distrib/sets)
To: Laurent DAVERIO <email@example.com>
From: Douglas Wade Needham <firstname.lastname@example.org>
Date: 11/12/2004 12:18:49
Content-Type: text/plain; charset=us-ascii
Quoting Laurent DAVERIO (email@example.com):
> Greg Troxel wrote:
> > fwiw, it's *extremely* convenient to be able to rm -rf /usr/pkg and
> > /var/db/pkg and start from scratch, on any pkgsrc system, anywhere.
> >I agree, and I do this, but usually 'pkg_delete -r \*', and then
> >delete crud from /usr/pkg, saving etc.
> IMHO, the mere idea that it may be desirable to rm -rf /usr/pkg and rebui=
> it completely, makes me think that there must be something flawed with th=
> pkgsrc system - not *fundamentally* flawed, but at least very incomplete.
I don't know if the flaw which is causing folks to go around
pkg_delete and use rm is with the pkgsrc system or the procedures
people use, or both. I would have to agree that part of it is at
least a fundemental incompleteness in the system, as witnessed by the
recent message noting that they were wanting to remove a group of
pkgs, but it was not smart enough to order the list for you instead of
failing. But regardless of that problem (which I have seen on
countless other OSes as well), I think there would still be people out
there who would do the 'rm -rf', even if that were fixed.
Things I think we need to do are:
1) Fix the issues with 'make update'. Like Laurent and others who
have stated they have been bitten by this, I too have been bitten,
and is one reason why I resurrected my system for doing builds in
chrooted sandboxes. But it is not the main reason, and would
suggest to anyone to go back and read my note from last week yet
again. But yes, it would be nice to be able to do a quick `make
update` for a simple update of a package, rather than a 12+ hour
rebuild of my sandbox, with the interactive installs for things
A thought...perhaps what should happen is that the tools create a
working copy of the current version, including +CONTENTS and the
other files, puts the new versions into place, and then cleans up
files which are not listed in the new version but were in the old
version. And if a update fails?? Clean up the new versions and
put the old versions back into place before returning the error
condition and exiting. And perhaps this whole mechanism could even
be smart enough to query if you wanted to rollback the packages
which you updated in the same `make update`...
BTW...This would probably be a pre-req for...
2) Stop talking about it and get the base OS and X11 into the fold. I
would lay odds I could find a message on at least one of the lists
where we were talking about defining packages for the OS 12 months
ago. As has been noted, it would be nice to have pkgsrc handle
and enforce requirements on things like X11 or misc.
3) Give some thought/consideration to sub-packages. It would be nice
to have this added level, so that we do not end up with packages
such as foo, foo-man, foo-lib, foo-clients, foo-server, foo-opt1,
foo-opt2, and so on.
4) Give some thought to enhancing install to write to a history/log
file if the environment is setup to request this. This way, you
run a command to say "I am going to be installing package foo", and
the install commands issued between that time and a time when you
run a second command log all the files installed/updated.
> I've been administering several FreeBSD servers for the last three years,=
> and "portupgrade" (not a part of the base FreeBSD port system, I know)=20
> helped me a lot. In these three years, I've never had to rebuild my ports=
> from scratch, so the idea seems very unnatural to me. I cannot even start=
> to imagine deleting 500 installed packages from a server, and telling my=
> users to wait a couple of weeks till everything is recompiled and working=
> I should add that I've been bitten rather badly by "make update" in pkgsr=
> (as a consequence of which I'm currently unable to reinstall xpm on one=
> Solaris 8 server), because it starts by deleting a port and its=20
> dependencies, without first making sure that it will be able to install t=
> new versions or restore the old ones.
Nor can I envision having to delete 500 installed packages and telling
the users they would have to wait even one day while I **try** to
compile the packages. IMO any administrator who did this should be
shot, either with a gun, or off the front of an aircraft carrier at
sea, without the aircraft or a flotation device. But unlike most
folks, I have worked a number of years in environments where uptimes
of 24x366 were __just__ good enough, and in environments with so many
hosts that not even the core folks with LISA could easily think about
them even just 5-10 years ago. As a result of being the person
responsible for those systems (1200+ in four countries) back then, I
gained what is likely a very unique knowledge set and view point.
> But I agree that I am not a pkgsrc expert, as I tried it, with more or le=
> success, only on thre "exotic" platforms (Solaris 7, Solaris 8, AIX 5).=
> Just my 2 cents...
I have worked with pkgsrc for many years now, and with packaging tools
on SVR4, Solaris, UnixWare, HP/UX, IRIX, Linux, etc. And while I would
have to say that while there are some flaws and deficiencies, things
are probably better here than with other systems in many regards. And
at least we are using MD5 instead of a checksum which is insensitive
enough that it cannot detect swaping two characters on a 16-byte
Douglas Wade Needham - KA8ZRT UN*X Consultant & UW/BSD kernel progra=
Email: cinnion @ ka8zrt . com http://cinnion.ka8zrt.com
Disclaimer: My opinions are my own. Since I don't want them, why
should my employer, or anybody else for that matter!=20
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 5.0i for non-commercial use
-----END PGP SIGNATURE-----