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
cu
Adrian
--
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: