Re: Proposal: dirlist.d/ directory support

[Robert Schiele]

On Fri, Aug 25, 2006 at 02:35:26AM +0200, Stepan Kasal wrote:
> Hello,
> 
> On Wed, Aug 23, 2006 at 10:04:48PM +0200, Robert Schiele wrote:
> > Exactly.  Let's take GNOME in /opt/gnome/ as an example.  If you have that 
> > you
> > might want to have GNOME m4 files in /opt/gnome/share/aclocal/ but you may
> > want to make some GNOME package also provide
> > /usr/share/aclocal/dirlist.d/gnome that includes only the line
> > "/opt/gnome/share/aclocal/".
> 
> this example is very illustrative.  I think the dirlist.d/package
> files would contain one absolute patch each.  And that can be

Uhm, but there might be packages that provided multiple pathes.  Thus there
might be more lines in one file or even a pattern.

> expressed with an absolute symlink.

But you can only do that when your assumption you made is true.  In most cases
it might be true but my approach is more generic because it just modularizes
the current dirlist feature.

> I would do
>       echo "/usr/share/aclocal/*.d" >>/usr/share/aclocal/dirlist
> and then
> ln -s /opt/gnome/share/aclocal /usr/share/aclocal/gnome.d
> 
> > Sure you could also do this with some symbolic
> > links but actually in my opinion the solution I provided is more clean since
> > it does not invent a new way of doing something but instead provides a
> > straight-forward extension of an existing one.
> 
> My opinion is exactly oposite: why do we need to invent a new
> mechanism when the current one perfectly fits the need?

It's more flexible, more convenient in more complex cases, and does not
require changes to current configs, i.e. you are not forced to use this if you
don't like it.  For example you could still do it the way you described above.

And after all it is not that new.  SUSE uses this on it's distributions for
years (but implemented with an ugly hack) and many other projects use similar
solutions (/etc/pam.d/, /etc/modprobe.d/, /etc/udev/rules.d/, ...).  Because
of that I consider this solution just appropriate because it is well
understood by most system administrators.

> PS:
> (There are some fundamental problems with the dirlist mechanism, like
> when you have /opt/gnome24 and /opt/gnome26 and want to use one of
> them for one build and another one for another build.  But your
> proposal does not help with that, so I really do not see any reason
> to adopt it.)

If a vendor provides packages that can be used only mutual exclusive for
development then he has to provide a solution to make sure that a maximum of
_one_ development package is setup for default use.  You can't blame a
configuration mechanism for existence of broken configs.

Your argument sounds to me like you said: "There are some fundamental problems
with C compilers, like when you write '7d8re%)(' to a file and want to compile
it.  gcc does not help with that, so I really do not see any reason to use
gcc." --- Or to make my argument more objective: It was not subject of this
design to prevent people from doing stupid things but to make it easier for
them doing the right thing.

Robert

-- 
Robert Schiele                  Tel.: +49-621-181-2214
Dipl.-Wirtsch.informatiker      mailto:address@hidden

"Quidquid latine dictum sit, altum sonatur."

pgpK6qg84hZ18.pgp
Description: PGP signature