Re: apt-get

[Bill Huey (hui) <billh@xxxxxxxxxxxxxxxxx>]

On Sun, May 30, 2004 at 04:01:19PM -0700, Matthew Dillon wrote:
>     Well, I must say this is an eye-opener!   The only exposure to apt-get
>     that I have had has been with personal workstations, and it seems to
>     work great for keeping things reasonably up to date.  But, obviously,
>     there are some serious issues when it comes to using it on large
>     clusters of machines.

I'm curious, what issues are you talking about ? My experience is that it
can pretty much seamlessly upgrade a ton of workstations if you have the
package cache path exported via NFS to other machines. It's a great system
and I've been able to upgrade hundreds of packages at once without failure
on a stagnant machine. It's a great packaging system.

There's a serialization issue with locking the NFS directory, but that can
be handled with the typical rsh scripts and such to remotely update all
machine with some kind of ordering. It's still superior to the traditional
source package only systems that the *BSDs use for frequent and mass updates.

Things like X, KDE/GNOME go through rapid development and minior revision
changes happen all of the time. Having a binary system like apt-get is very
useful, since rebuild times of those ports and dependent library are
excruciating and often unreliable.

>     So, maybe we should roll our own after all.
> 
>     This does solidify my opinion that we need VFS environments to provide
>     truely isolated setups for various subsystems (e.g. apache vs login user
>     vs root vs mail vs whatever), and then run the port/packaging system
>     within each environment.  The one thing I have *always* dreaded when
>     doing large installs is that I would have half a dozen subsystems all
>     working properly and then I would try to install something for some
>     other subsystem and blow up one of the existing subsystems.  UNIX has
>     this wonderful concept of a 'user' which seriously under-used when it
>     comes to services.

IMO, namespace are abused to handle things that should be solve with some
kind of name versioning. You don't need a sophisticated VFS namespace systems
just to rename a binary package so that it can co-exist with another older
package. It's just a function of how the group or individual manages their
own dpkg repository.

I would think that VFS namespaces are potentially more useful for things like
security sandboxing and other things that need direct kernel support that
can't be done in userspace, etc... It seems overkill otherwise. apt-get
handles all of this stuff pretty transparently and I've never had problems
even with a ton of unofficial apt repositories/lines.

The VFS suggestion seems to be a mismatch solution to a problem by abusing
a kernel facility, stuck in *BSD packaging conventions, where the problem
should be handled by proper version manangement or create a method so that
other don't need to dependent on a centralized management system, and
people maintaining it.

That's my two cents :)

bill