should automake1.6 "provide" automake?
Hello all,
The new automake version 1.6 package, "automake1.6" does not "provide
automake". Apparently, this was removed at the specific request of
some unnamed ftpmaster. [See Bug #150027]
This is a mild, but continuous, irritant for this user when dealing
with packages that depend, suggest, or recommend automake.
Now that the furor has died down, I have gone through and read all
this month's threads on automake 1.6. Much of the debate was
concerned with whether the package "automake" should be replaced with
version 1.6, or whether the automake1.5 model should be followed. The
consensus was to go the latter route, at least for now. There was
also some secondary debate on whether or not automake1.6 should ship
the file /usr/bin/automake; this was eventually resolved to follow
upstream practice (i.e. ship the file).
I couldn't find any message noting a problem caused by the fact that
automake1.5 "provides automake". Indeed, Anthony Towns noted
the buildds will always choose a real package named "automake" in
place of the virtual package provided by automake1.5.
http://lists.debian.org/debian-devel/2002/debian-devel-200206/msg00369.html
On the other hand, Junichi Uekawa has argued against providing
automake in messages to bug #150028, such as the following.
On Mon, Jun 17, 2002 at 10:21:35PM +0900, Junichi Uekawa wrote:
> 2. The "buildd" currently has means of working around other automakes,
> because their aim is to build software for other arches.
> There are other software for autobuilding, which do not aim at
> building software, but to its rebuildability.
I agree that "rebuildability" is a useful goal. I also believe that
though autoconf "recommends automake", the maintainer did not intend
to recommend "automake 1.4 or automake 1.5 ONLY". It is inconsistent
to have only those two versions of automake satisfy such dependencies.
If these two goals are in conflict, then it comes down to making a
choice about which is more important. I'm interested in hearing
opinions on the matter.
> 3. Debian (I'm not talking about specific software, such as "buildd", or
> "sbuild") does not really distinguish between packages Provided:
> and real packages. I.e. if a package Build-Depends: on automake,
> and automake1.6 fails to build the package, it is a serious bug
> on the package, or a grave bug on automake1.6.
>
> 4. "apt-get build-dep " will not try to remove automake1.6 to install
> automake1.4. If user chooses to use automake1.6 and use
> apt-get build-dep to build a package which build-depends on automake,
> and it fails, there will be quite a few bug reports.
Debian has been operating with automake1.5 "providing automake" since
2001-10-19. How many bugs have been filed because of this? None on
automake or automake1.5 that I could find. If any have been filed on
other packages, they can trivially be corrected by using a versioned
"build-depend", if I read the policy section 7.4 correctly.
Providing "automake" is not a problem with the "official buildd"
software and any bugs so induced (which would have been induced with
automake1.5 last October) can be fixed with a change to
debian/control. Thus Junichi's worry, while valid, strikes me
personally as minor.
So what's the reason for ftpmasters vetoing the "provides" line?
-S
P.S. I only read -devel via the web, so CC me if you desire a prompt
reply.
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: