Re: Automake 2.50 migration strategy, as implemented
On Sun, 27 May 2001, Colin Watson wrote:
> 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?
I know that it's sometimes some work to get a package building on stable
that has a build dependency on debhelper (>= 3.0) . Shall we prohibit
maintainers from setting this build dependency?
And often strict build dependencies are required by upstream, when you'd
e.g. try to recompile the latest gnumeric for stable I expect you'll have
to recompile more than a dozen libraries before.
> 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.
It's all right to have the build dependencies relaxed as long as it
doesn't make an "important difference". The "important" means that the
package should e.g. have the same functionality.
I'm thinking of the case where a missing build conflict and build
dependency causes different builds dependendent whether a specific library
or program is installed on the build machine or not.
The slight differences between version 2.1.8 and 2.1.9 of a library should
normally be handled by the shlibs file of the library so that a more
specific build dependency isn't needed in most cases (and when the binary
size changes by a few Bytes that's nothing I'd consider an "important
difference").
> 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.
I agree with you with the exception that an architecture might have for
any reason (e.g. a failed build) only an older version of a library
available and with relaxed build dependencies the autobuilder will compile
the package with this old library. To force the autobuilder to use the new
library you must tighten the build dependency.
We make our packages for unstable and check that they build and work
correctly on unstable - and when the build dependencies aren't fulfilled
on stable this doesn't mean that you can't get the package building and
working on stable.
An example for a case where we explicitely force the build machine to have
packages from unstable installed are build dependencies on xlibs-dev. This
doesn't mean that the package won't compile on stable (and many of these
packages do compile on stable).
> Let's not get too anal about this.
I hope you understand better now what I wanted to say
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: