Eivind Eklund wrote:
> [Gobolinux use a one-dir-per-package model. -Eivind]
>
> I think both models should be supported.  Gentoo use the same model as
> GoboLinux, I believe.  The problem I have is with people coming and
> telling me "I am going to force all FreeBSD and Debian and Red Hat and
> etc users to go with my completely incompatible setup, because your
> work is too complex for me and I've tried out packaging 0.5% as many
> packages as you have for 1% of the number of users you have and my way
> is better and there's no reason for you to do all your stuff cause
> mine has worked fine so all your complexity is just stupid."
>
> I'm not going to tell Gobolinux not to experiment with this.  I think
> Gobolinux experimenting with this is GOOD.  If that works out really
> really well, it will take over the Linux packaging world, and we'll
> just kill the *BSD and Debian and PLD and etc packaging models and the
> Linux Filesystem Hierarchy Standard, migrating to a system that works
> a la Gobolinux and RubyGems.
>
> Until we do, however, I think that having Ruby implemented in a way
> that makes it possible to follow the standards reasonably well is
> necessary.
>
> And until I stop hearing complaints that it's impossible to package
> Rails and RailsGen properly (which I last heard from a new repackager
> a few days ago), I won't think this problem is solved.

Actually that's interesting. Perhaps the authors of the packages
themselves should have some sort of specfile to designate information
about their files which another build tool could use to build the
layout for particular distribution's needs. So the build tool could
have different adapters, FHS adaptor, Gentoo Adapter, Windows
Adaptor... not sure how the specfile mihgt look though.

> > Hmm... by that definition then most of site_ruby should be in share/.
>
> Yes.  site_ruby is (AFAIK) inherited from site_perl, and I think that
> predated the proper share/ splitting.

Interesting.

> > Though I really wonder how many people do such a thing.
>
> Not many for each particular case.  The ones that do are often very
> much power users, however, and contribute disproportionally to the
> system, and additionally there is a much larger number that don't use
> it, yet feel more comfortable with the system because it's there in
> case they need it.

That makes sense. Though I imagine, even in their case some of it is
overkill. Plus consider that even if it is all quite rational, if it is
just too complex how effective is it gogin to be anyway?

> I would prefer to go through with Austin privately and then do the
> public rundown afterwards; initial discussions with too many
> participants tend to be less than fruitful.

Okay.

> I think it's important to go through and find exactly what parts are
> worth support and which parts we'll just want to say "So long with
> that".  After having gone through and found what we think we can drop,
> I'd like to discuss it with some more repackagers, to make sure we get
> a good solution.

Quite resonable.

> > Actually I worry about MS' WinFS for Linux' sake. It may be behind schedule, but that's
> > what MS is working on to be sure.
>
> I'm not particularly worried.  KDE is working on technology that fill
> similar goals, GNOME has some already, ReiserFS include some parts,
> and overall I don't think it makes that much of a difference.

I'm not sure. Perhaps. Sometimes it seems like their just adding layer
upon layer rather reworking inot something original.

> If anything, I'm worried by .NET.  This kind of infrastructure could
> become a security must on a more hostile Internet, and that could put
> a several year dent in Open Source technology (and even more in open
> source trust.)

That's true too :(

Thanks for these well put replys.

T.

P.S. Where does one put demo/example files in Debian/FHS?