[aps-devel] Fwd: GNU package management

[Robert Millan]

On Fri, Nov 29, 2002 at 07:53:11PM +0100, Wolfgang Jaehrling wrote:
> On Fri, Nov 29, 2002 at 05:11:19PM +0100, Robert Millan wrote:
> > On Wed, Nov 27, 2002 at 02:14:42PM +0100, Wolfgang Jaehrling wrote:
> > > RMS' suggestion was that the file system that unites the package
> > > directories should also provide a node where you can lookup problems,
> > > like unresolved dependencies and conflicts, and should hide the
> > > packages which currently have such problems.  This will enable the
> > > user to manipulate the package system manually without messing up
> > > things, and I hope we can all agree that this is the Right Thing, even
> > > if we will have frontends which take care that everything is alright.
> > 
> > I'm not sure that's the best solution. We have at one side a filesystem that
> > includes all packages, and at the other UnionFS which links a list of the
> > packages it considers installed.
> 
> Yes, like this: Ext2fs -> UnionFS
> 
> > If you add another filesystem between them that manages
> > dependencies,
> 
> ... which would look like this: Ext2fs -> PackageFS -> UnionFS
> and is not the same as the idea I described above, actually (although
> I mentioned it later).  The idea (from RMS) described in my paragraph
> above was to let UnionFS do that, so your comment at this point
> slightly confuses me.
> 
> > that fs won't have a list of installed packages, so the only chance
> > would be to ask UnionFS back about it.
> 
> This confuses me even more. :) It seems we have some kind of
> misunderstanding here, but I will try to reply anyway.
> 
> The ``PackageFS'' mentioned above would be the part that knows which
> packages are installed and would hide the packages with problems, so
> why would it have to ask UnionFS about anything?  It is in a layer
> below UnionFS, thus it does not even need to know about its existance.
> If we do not need Unix compatiblity, we could even drop the UnionFS
> part entirely (of course we don't want that).
> 
> > If we can get a filesystem that manages conflicts, though, it can also
> > manage dependencies and other package relationships (eg, foo depends on
> > bar, so when you add a link to foo it automaticaly adds a link to bar).
> 
> Yes, of course it should manage all package relationships!  (However,
> automatically creating links seems like a bad idea.  Rather, it should
> fail to create a link if a required link is not available.  Otherwise,
> you open up a huge can of worms.  But I have to admit that I did not
> yet think in detail about the exact organization of this part of the
> file system, but I think neither has anybody else.)
> 
> > That is, if we can get a filesystem to do that task, which i'm not sure
> > if it's the best way to go.
> 
> Well, in my previous mail, I said why I think we cannot do _only_ that
> (i.e. implement it in the file system), but this was with the
> assumption that package installation sources are an orthogonal issue,
> see below.
> 
> > > Whether we modify UnionFS this way or (cleaner, but maybe just too
> > > slow) create a seperate PackageFS that resides in the layer below
> > > UnionFS is another question, and I do not have a firm opinion about it
> > > yet.
> > 
> > I don't think maintaining a "hacked" version of UnionFS is a good idea.
> 
> I agree that it is not the best thing to do, conceptionally.  But one
> could maintain a UnionFS policy module, if UnionFS supports them.
> That is quite a crazy idea of course.
> 
> > unionfs does (or aims to) have a stable specification. If we implement
> > a dependency tracking filesystem it can be outside it
> 
> Certainly it can, I even explained in my previous mail why it can.
> The question is whether it is feasable or not, and I have no
> particular opinion on that yet.
> 
> > Besides this, I think we should start a Savannah project, so we can start
> > writing down planification and keep this discussion in a mailing list,
> > where it goes archived.
> 
> I agree.  Feel free to create one.  If you do so, please post all the
> mails of the current discussion on a list there, so that we have it in
> the archive.
> 
> > Merging the ideas we have now the whole thing would look like this:
> > 
> > GNUnet -> OtherFS -> TrustFS -> PackageFS -> UnionFS
> > 
> > gnunet provides the package media.
> > otherfs adds unix/gnu permission sets gnunet doesn't provide (ala umsdos).
> > trustfs uses GPG and a set of complex rules to determine wether a package
> > is trusted.
> > packagefs resolves dependencies/conflicts
> > unionfs links installed packages
> > 
> > The idea behind the three first servers is providing an anarchistic
> > contribution system in which everyone can participate freely, being trust
> > evaluated democraticaly.
> 
> Such a contribution system is a very good idea.  But is this a good
> way to implement it? (It seems what you want is to use the network
> instead of a stored (or NFS) file system.)  I have a few doubts:
> 
> - It would require that the network is always up
> - Data would have to be loaded from the network all the time
> - If something is broken in the GNUnet repository, every system will break
> 
> [I am aware of the possibility of local caching, but you will have to
> convince me that it will actually work well enough.]
> 
> Such a system would not be a general-purpose operating system anymore
> (and I can guarantee you that I would not ever want to use it myself).
> I think that neither of these are necessary, so why do them?  Why not
> keep package storage and package installation sources orthogonal from
> each other, that would be _way_ more flexible.
> 
> Of course, there is no reason not to implement your design as well: We
> can easiely replace the part ``GNUnet -> OtherFS -> TrustFS'' with
> ``Ext2fs'' and vice versa, but I think that it is very useful to be
> able to use Ext2fs but _still_ get packages over GNUnet with your
> (certainly very cool) mechanism.  Sure, no reason not to have both,
> but it looks rather obvious to me which variant would be useful for
> more people, and just as obvious which one is easier to implement;
> remember that file systems are more complicated to write than other
> programs, and I see few reasons to not have a normal stored file
> system (or NFS in some cases) at the lowest level.
> 
> To summerize: I think that I am very open minded with respect to crazy
> ideas, but this one is even to crazy for me. :-) Of course it might be
> the case that I just misunderstood your intentions.
> 
> > My initial idea was to call it "GNU Anarchist Package Tool" (gapt)
> > in comparison to debian's APT. But this now looks like a System of
> > components rather than a Tool, so perhaps "GNU Anarchist Package
> > System" (gaps) would suit better.
> 
> I like this name.
> 
> Cheers,
> GNU/Wolfgang
>