Re: autogen is misconfigured

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


On Sun, 2007-03-04 at 12:08 -0800, Bruce Korb wrote:
> Michael Schwendt wrote:
> > There seems to be a separate "autogen-devel" package, which contains
> > header files. Most likely options.h is included.
> Given that autogen is a development package anyway.  GCC-from-source
> builders aside, essentially anyone wanting autogen is going to want
> the two files in autogen-devel.  Given that and the sub-marginal
> amount of space taken by the two files, I fail to understand why
> it is worth the bother to separate.
Please open a bug in bugzilla.  The packager of autogen needs to respond
to your comments and that's the only way to be sure to get a hold of
them.  If you find the packager to be unreasonable other packagers can
then get involved if there's a clear path forward.

> >> and the two misnamed executables.
> > 
> > The package uses the "alternatives" system for these two. Probably this is
> > not obvious. /usr/bin/columns and /usr/bin/getdefs are two very generic
> > file names which pollute the /usr/bin namespace and bear the risk of
> > causing a conflict with other software. It would be beneficial if autogen
> > called the files differently and used an own namespace, e.g. with a prefix
> > or postfix.
> "getdefs" can be so treated.  Go ahead and add an "ag-" prefix or something.
> I don't particularly see it as a very generic name, but renaming it is
> not crucial.  Renaming "columns" _is_ a problem.  "autogen" under various
> incarnations is about a decade old with widely available public releases
> available for over 6 years and it has been officially "GNU" for several
> years now.  "columns" is a program incorporated into many templates.
> It cannot be renamed without invalidating the templates in use by at least
> a few hundred people.  That is not a good idea.  "columns" can certainly
> be treated as a "generic" program anyway.  It does what its name suggests
> fairly well.  Nearly as well as ``ls -C'' or ``ls -x'' (does not support
> different widths for different columns).  By making "columns" have a
> separate name, you are invalidating these templates.

As stated, these programs are packaged using the alternatives system.
So the end user is able to have /usr/bin/columns and /usr/bin/getdefs
point at the autogen implementation or at a different implementation.
So this isn't as far wrong as you make it out to be.  Take a look at my
system, for instance:

$ rpm -ql autogen|grep bin
$ ls -al /usr/bin/columns /usr/bin/getdefs
lrwxrwxrwx 1 root root 25 Feb 25 15:39 /usr/bin/columns
-> /etc/alternatives/columns
lrwxrwxrwx 1 root root 25 Feb 25 15:39 /usr/bin/getdefs
-> /etc/alternatives/getdefs
$ ls -al /etc/alternatives/columns /etc/alternatives/getdefs
lrwxrwxrwx 1 root root 24 Feb 25 15:39 /etc/alternatives/columns
-> /usr/bin/columns.autogen
lrwxrwxrwx 1 root root 24 Feb 25 15:39 /etc/alternatives/getdefs
-> /usr/bin/getdefs.autogen

Running rpm -q --scripts autogen will show you the scriptlets that are
registering columns and getdefs with the alternatives system to
automatically create /usr/bin/columns and /usr/bin/getdefs on
installation of the package.

Is alternatives the right solution to this problem?  Probably not.
Alternaties was invented to address things like sendmail's sendmail
program vs postfix's sendmail program.  Both those programs take the
same options on the commandline and yield similar results through
different backends.  Is autogen's version of /usr/bin/columns part of
POSIX, the Single Unix Specification, or LSB?  If so, we have a solid
foundation and alternatives (or removing alternatives as there is no
alternative implementation in the system currently) makes sense.  If
not, then we can only hope that no other open source software chooses
the generic /usr/bin/columns name for their program otherwise we all


Attachment: signature.asc
Description: This is a digitally signed message part

fedora-extras-list mailing list

[Index of Archives]     [Fedora General Discussion]     [Fedora Art]     [Fedora Docs]     [Fedora Package Review]     [Fedora Desktop]     [Big List of Linux Books]     [Yosemite Backpacking]     [KDE Users]

  Powered by Linux