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

Re: RFC: Rules for distro-friendly packages

OoO Pendant  le temps de  midi du jeudi  16 septembre 2010,  vers 12:28,
Enrico Weigelt <weigelt@metux.de> disait :

>> About autoconf stuff:
>> - Why require autogen.sh? On a release, configure script should be
>> present. No need to rebuild it. 

> No, there often *is* a need to rebuild it (actually, much of my
> QM work on dozens packages requires changing configure.in+friends).
> And you don't seriously want to patch autogenerated files, do you ? ;-o

>> Some users just don't have recent enough autotools to rebuild the
>> configure. 

> They should simply install it. Similar as they need recent toolchain,
> make, pkg-config, etc, etc.

No, no, no. Users are not  limited to Debian developers using Sid. Users
may try to compile  on an old RHEL 2. They should  absolutely not try to
rebuild configure since it is likely  to not work and leave them with an
unconfigurable package. On most projects, there is not autogen/bootstrap
in the realeases  for this very reason: do not confuse  the user and let
him install  autotools which is not mandatory  at all. autogen/bootstrap
is shipped in the VCS repository because this is targeted at developer.

autotools are  aimed at the end  user, not the distro  packager. This is
stated in the  introduction to autotools.  This is nice  to be nice with
the distro packager but the primary  target is the lambda user (which is
usually less skilled than the distro packager).

Compiling software from source is  enough a pain to avoid any unecessary
dependency. No need for a recent toolchain and no need for autotools for
a software aimed at running on a lot of systems (which is what autotools
are for too).

>> - Not using AC_TRY_RUN is too strong. 

> No, it's mandatory. It simply cannot crosscompile, no chance.

>> This macro has a parameter to be used when cross-compiling.

> It's inherently unreliable, by design. The developer has to specify
> some default behaviour in case of crosscompiling. And that's most
> likely wrong. If you do use that macro, you've normally relying
> on basicly assumptions. Such as the building system is equal 
> (yes *equal*, not just similar) to the actual target system.

>> It is more useful to detect a problem when not cross-compiling
>> with AC_TRY_RUN than to not detect it at all.

> If you really wanna have some runtime tests, then it should be
> done separately (eg. separate script or in make test stage).

Oh sure, if there  is a problem that can only be  detected at runtime, I
will let  the user  deal with it  in some  "make test" that  nobody runs
instead  of  handling  the  problem   for  him  in  most  situations  in
configure. Again, configure is targetted  at the end user (which usually
does not cross-compile). It  should automatically configure the software
to  be in  a workable  state  after compilation.  No need  to read  some
README or run some additional scripts.

As upstream, I  care about Debian and cross-compiling  but I also should
care about  people wanting to  compile my software  on old RHEL 2  or on
Debian Etch (an  old enough platform to require some  runtime test in my
case). None of those platforms have a recent enough autotools to rebuild
configure, BTW.
Use the "telephone test" for readability.
            - The Elements of Programming Style (Kernighan & Plauger)

Attachment: pgp_xwDVLaq_H.pgp
Description: PGP signature

Reply to: