Re: Automake 2.50 migration strategy, as implemented
Adrian Bunk <bunk@fs.tum.de> wrote:
>On Sun, 27 May 2001, Steve M. Robbins wrote:
>> 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.
This isn't at all clear to me.
Certainly, it's a good thing that all the autobuilders will build
functionally the same package for all architectures. However, from time
to time a user files a bug report saying "I'm still running stable, but
I'd like to recompile this newer version of your package, except it
doesn't work". Should we tell them to bugger off because we've got our
nicely synchronized build-dependencies and the package has to build on
an unstable environment everywhere?
You *know* this - you rebuild packages for potato yourself, and I'm
pretty sure the output is different on potato otherwise you wouldn't
bother. Steve explicitly mentioned different library versions as a
reason why packages might build differently in different environments,
which is exactly what you have between potato and woody/sid. The fact
that source dependencies are more liberal than binary dependencies is a
*good* thing about the way libraries are versioned, not a bug.
And before somebody says that shlibdeps aren't a meaningful difference,
they are. Look at all the packages in unstable compiled against old
libraries that have since disappeared, and which thus now have grave
bugs. All they need is a recompile, but we'd be lying to our users if at
the same time we tightened up the build-dependencies and said "no, look,
it only works if you compile it on unstable, honest" (I'm probably being
hypocritical about this ...). Keeping the build environment up to date
*is* the autobuilder's job (generally done well, I might add), and we
shouldn't use that as an excuse to tell users that they can't have
functionality that actually works perfectly well.
Let's not get too anal about this.
--
Colin Watson [cjw44@flatline.org.uk]
Reply to: