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

Re: Automake 2.50 migration strategy, as implemented

On Sun, 27 May 2001, Steve M. Robbins wrote:

> > Also, the case where the
> > autobuilders will build things in a different environment than a normal
> > user, or the maintainer would, is not acceptable. The autobuilders may
> > be able to build it, but a normal user would have to know some secret
> > (installing autoconf2.13) to get it to rebuild.
> Philosophically, it is not ideal to have packages built in different
> environments.  Practically speaking, however, it is unavoidable: the
> probability that any two human builders have the same environment is
> rather small, I expect.

When two users fulfill the build dependencies and the build conflicts of a
package and the package builds differently for them that's IMHO a bug in
the package.

> I think it is a bit of a myth that the autobuilders will produce
> precisely the same sequence of bits that I get when I build a package.
> For one thing, I might have libfoo-1.3.2 installed while the
> autobuilder has libfoo-1.3.1.  For another, if the package
> build-depends on a virtual libbar-dev, I and the autobuilder might
> build against completely different libraries.  Worse: two different
> autobuilders might choose different libraries to satisfy the same
> virtual package.

When this makes an important difference the bug is in the build
dependencies of the package.

> The build daemons necessarily have some special knowledge built into
> them.  There must be, at least, a map specifying a real package for
> each virtual package.  The set of "build essential" packages is

That's still a case where I'll see a missing build dependency when I try
to manually rebuild the package - and the rule which real package to
choose for a virtual package can be "choose randomly one of the real
packages that provide this virtual package" - it's a case that needs to be
handled, but there's no special knowledge required.

> another example of special knowledge.  This list is not internal to
> the build daemons, of course, but the fact that "build-essential" must
> be installed *is* built in to them.

The fact that "build-essential" must be installed is not special
knowledge, it is part of the policy!

> I don't see this knowledge represented in build daemons as a bad
> thing.  To the contrary, decent heuristics might enable more packages
> to be built without human intervention (cutting down on the number of
> failed autobuilder logs you'd need to look at).  This information is
> not hidden or lost: it is (or could be) available on-line for anyone
> to see how to generate a given package for a given architecture.

I want that my packages are built the same way on both my machine as on an
autobuilder - every time I do a "dpkg-buildpackage".

> Why wouldn't one want autobuilders that are more robust to such
> changes?  Putting the knowledge into the autobuilders is not just an
> expediency; it also means that you solve the problem once in one
> place, rather than giving all the package maintainers more busy-work
> to do, checking whether the package will still build with the new tool
> version.

This may cause that all the autobuilders will happily compile a package
but the maintainer has no clue why he can't compile it himself?

> -Steve


A "No" uttered from deepest conviction is better and greater than a
"Yes" merely uttered to please, or what is worse, to avoid trouble.
                -- Mahatma Ghandi

Reply to: