Re: [Gnu-arch-users] Managing changes to projects that use autoconf/automake with tla

[Andrew Suffield]

On Tue, Apr 06, 2004 at 08:49:03AM -0700, Tom Lord wrote:
> 2) Define and implement wrapper technology for driving more or 
>    less arbitrary package-specific configure/build/install processes.
>    Dependencies are typically declared here and inconsistencies in
>    individual packages c/b/i methods are worked-around.
...
> 0) Individual package c/b/i technology, typically auto*, the Python
>    configure library, Ant, etc.
> 
> I have a few problems with the stack as it has evolved.
> 
> First, layers 2 and 0 should not really be separate or, more
> precisely, layer 2 should be far thinner than it is.  As it stands,
> layers 0 and 2 are typically implemented by separate parties for each
> package; layer 2 is typically implemented multiple times; and the work
> needed to implement layer 2 is largely a matter of figuring out things
> already known to the author of layer 0 and redundently expressing that
> information in a standard form.  The opportunity missed here (now
> especially difficult because each upstream project would have to agree
> to take up the opportunity) is to build c/b/i tools which are a
> pleasure to use for layer 0 needs, but which also as a side-effect
> present most of what's needed for layer 2 in a useful form.

Unfortunately the real world isn't that simple. In some cases, this
problem can be solved, and has been (at least in Debian); to pick a
random example, the problem of library dependencies for anything that
compiles to an ELF object is solved by dpkg-shlibdeps, which computes
them at build time.

In some other cases it can't be solved, because there isn't a single
answer. Some packages can vary their feature set based on what other
packages are available (auto* facilitates and encourages this). You
could specify a minimal list of interfaces and dependencies, or a
maximal one, or even something more complicated, but sooner or later
it's going to come down to choices that matter.

You also have to contend with the real reason for vendors:

Upstream authors are stupid.

The underlying problem is not that upstream authors can't provide the
necessary data, but that they make stupid decisions. We *could* have a
mechanism by which they exposed all this data, but we'd still need a
layer 2 that wraps everything and overrides their mistakes. Vendors
are there to take the result of highly varied upstream insanity and
make it all work together.

> It doesn't take much to make overreliance on layer 1 into a huge
> problem.   9 packages may, individually, do a pretty good job of using
> auto* correctly but then if they all depend on the same 10th package,
> and that 10th package does a poor job -- then all 10 are suddenly not
> portable after all.

This sort of problem is easily fixed. If it's a serious problem then
somebody will fix it.

> Third, people and organizations implementing layer 2 for the core
> packages a typical GNU/Linux system have that activity as their major
> raison d'etre.  They may ask upstream to fix this or that c/b/i bug to
> make their job easier -- but they generally don't have strategy
> meetings where the agenda is "What can we ask upstreams to do that
> will put us out of business?"  The closest we get to that is when 3rd
> party folks send upstream maintainers like me package configuration
> files and ask that they be included in distributions (an unattractive
> option because they are system specific, because no provisions have
> been made anywhere to maintain them, and because even if such
> provisions were made it's just "extra work" -- the work of maintaining
> the package configuration doesn't get re-used in ways that help the
> upstream project generally).

I think you overestimate the difficulty and significance of this
problem; this is common, and a perpetual irritatant from users and
prospective developers who think it's a significant part of
maintaining packages in Debian.

Throwing together the necessary files to wrap a package, even one with
a strange build system, is the *easy* part. I would expect any
reasonably experienced developer to spend no more than 30 minutes per
package on it, once; keeping it up to date takes very little effort.

The hard part (and the important part) is handling bugs, users, and
upstream changes (where these three can be distinguished).

> 4) That problem can be solved deep down, with better c/b/i standards
>    and tools -- or it can be worked around, perpetually, largely by
>    hand.  Solving it deep down requires a decision to cooperate by
>    many upstream projects led off by the development of better tools.

Alas, things are never that easy. This would only work if all (or even
a significant number) of upstream authors understood and cared about
the issues. In reality they just don't want to deal with it. Even
proper use of auto* is usually beyond them - somebody has to come
along and fix it for them on occasion, and it's usually the vendors
who do this.


As always, the problem isn't that you've got the wrong kind of
government. The problem is that you've got the wrong kind of
people. It's easy to blame the government, but it really isn't their
fault.

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'                          |
   `-             -><-          |

signature.asc
Description: Digital signature