Re: GNU System Explanation

[Gianluca Guida]

Hi,

Seems to be my turn to talk.

On 2/11/06, Barry deFreese <address@hidden> wrote:
> Can someone please give me a concise explanation of what the intended goals
> are here?

If I get you straight, you talking about stowfs.

> I understand that you want packages isolation in /packages, but why?
> Managing multiple versions of a package could potentially become a headache
> I believe.
>
> For example:  I have /packages/foo-1.1/bin/foo  and /lib/libfoo.  Then I
> install foo-1.2 which has /packages/foo-1.2/bin/foo and /lib/libfoo, foo-1.1
> becomes pretty much unusable anyway, does it not?

We discussed both this and the dependency issues of a stowfs-like
architecture. I would have like to go quite rude on this, without
caring about dependencies and multiple versions installed. Alfred was
not of my opinion, and he always stated for the necessity to support
both easy multiple-versions and automatical dependecy issue.

We had some discussion about, and we basically met each other on the
decision that unionfs-based stowfs would just had cared about the "low
level" part of this packaging management. That is the unification of
the packages itself. Handling of the packages itself is one
abstraction layer on top of it. We can implement it both by modifying
unionfs support for stow (which would generally keep unhappy other
unionfs fans like Ben Asselstine) or by implementing something on top
of it (exporting an API or something like this). This can be done,
quite easily.


And now, some word about current status of unionfs-based stowfs.
Basic stowing functionality works, and works quite great. There are
some minor bugs and unimplemented things which are -- as I said --
minors.
They are, at the moment:
 - Missing support for exotic (but *needed* in things like an
unionfs'd GNU/Hurd LiveCD) operations like mkdev etc etc.
 - Some stupid bug in options handling.
Don't come to tell me that these are serious or architectural bugs. I
haven't had time to fix them. unionfs is a quite clear and well
designed program, so it's easy to hack even for hurd non-experts
(which I claim to be).

Another well known problem, which has in past caused sarcasm by other
people, is that I failed to get such a system booting. The more I
think about, the more I think that it was due to my own fault and my
laptop that has ever shown lot of problems on getting the Hurd
booting.
I was in a rush when I was trying to get that, so I didn't go too much
deep into the booting problems. And after this unsleepy hacking week I
had lot of others real-life things to do (other than some more fun GNU
Mach hacking) so I suddenly abandoned the effort.
People interested in having fun, being sarcastic, etc. can try
continuing my effort.

> What do people see as currently wrong with dpkg other than being Debian and
> a little cumbersome for developers?

(personal opinion here).

Hm, Debian Tools engineered as a mess of scripts for initiated is a
good motivation to try another way?

> Can someone please enlighten me?

Hope this helps.

Thank you,
Gianluca

--
It was a type of people I did not know, I found them very strange and
they did not inspire confidence at all. Later I learned that I had been
introduced to electronic engineers.
                                                  E. W. Dijkstra