Re: Automake 2.50 migration strategy, as implemented
On Sun, May 27, 2001 at 12:04:28PM +0200, Adrian Bunk wrote:
> On Sun, 27 May 2001, Steve M. Robbins wrote:
> > 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!
That "build-essential" packages must be installed is a fact,
i.e. "knowledge". The rule to satisfy dependence on a virtual package
is also knowledge. If you don't want to call this knowledge
"special", so be it. I don't want to get hung up on definitions.
That knowledge must be programmed into a build daemon. That it is
also written down in the policy document doesn't diminish this.
[This knowledge must also be instilled in all the human builders, too.
Where do they get their programming from? Policy! The policy document
also serves as part of the "programming" for us humans.]
The fact that package A requires package B to build is also knowledge.
We require this to be encoded in the "build-depends" of package A.
That is a reasonable requirement because it pushes the work out to a
person intimately familiar with package A.
Now, the case at hand is the following: package B is a tool that
suddenly changes its behaviour. There are a couple of possible
courses of action. One is to wait until the packager of A checks
whether it builds or not using the new version of B and, if not,
updates either the code or the build-depends of A. The other is to
install the following heuristic in the build daemon: if a package does
not build with version N of tool B, then try version N-1.
If there is a single package in the class of A, the first is the
most rational response. If there are 200, is it still rational
to wait?
> > 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?
If the autobuilder can help the maintainer by saying, "package A
does not build with version N of tool B, but it builds with version
N-1 of tool B", what is the harm?
A clueful human might try reverting to autoconf2.13 if a package
failed to build. Why would you want autobuilders to be less smart?
Let's automate some of this stuff!
Regards,
-Steve
--
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants
Reply to: