Re: Automake 2.50 migration strategy, as implemented
On Sun, May 27, 2001 at 09:13:32AM -0400, Steve M. Robbins wrote:
> 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.
What you called knowledge is what I'd call an interface. An interface
should be defined, in this case policy defines it, and programs implement
it.
> 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.
This is the normal way to go, right.
> 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.
There is only ever one version of specific package available in a Debian
distribution. You can't get version N-1. It's take or leave.
> 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?
If waiting causes problems, one should probably not introduce such a major
change. This is Debian, where we are waiting for over two releases until
the move from /usr/doc to /usr/share/doc is completed, and this affects all
packages, and you are asking if it is rational? ;)
> A clueful human might try reverting to autoconf2.13 if a package
> failed to build.
There is no programmable interface which let's me know that autoconf2.13 is
what I'd expect to be autoconf. What you are proposing is the use of a
non-existing interface which is not implemented. The new autoconf would
need a tag that points back to autoconf2.13 to make this work. Such a tag
doesn't exist, so we can't use it.
> Why would you want autobuilders to be less smart?
> Let's automate some of this stuff!
Such interfaces are easily cast in stone, and should not be added lightly, on
the rush, just because of a single problem (which is more a problem of
schedule rather than inherent technical issues anyway). You are welcome to
think this through and propose an interface, but we should not first
implement it, then define it and afterwards see if it is really feasible.
Personally, I don't think such an interface is reasonable. I don't want to
try K packages, walking my way down in history, to see if some of these
works. Also, a failure might not lead to a compilation error and introduce
subtle bugs.
Thanks,
Marcus
--
`Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd@debian.org
Marcus Brinkmann GNU http://www.gnu.org marcus@gnu.org
Marcus.Brinkmann@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de
Reply to: