> >> Le Thu, Jul 10, 2014 at 04:46:53PM +0200, Bill Allombert a écrit :
> >> > + <p>
> >> > + If your package includes the scripts <prgn>config.sub</prgn>
> >> > and
> >> > + <prgn>config.guess</prgn>, you should arrange for the versions
> >> > + provided by the package <package>autotools-dev</package> be
> >> > used
> >> > + instead (see <package>autotools-dev</package> documentation
> >> > for
> >> > + details how to achieve that).
> > On Sat, Jul 12, 2014 at 09:42:23AM +0900, Charles Plessy wrote:
> >>
> >> I agree with the intent, but I think that the wording is too restrictive,
> >> since
> >> a package that would use autoreconf and install config.* files at a version
> >> newer than what autotools-dev provides would not comply with the Policy.
> On 12 July 2014 19:50, Bill Allombert <ballo...@debian.org> wrote:
> >
> > This was intentional: this allow porters to update config.sub and
> > config.guess
> > in autotools-dev and not have to update all the automake versions.
Le Sat, Jul 12, 2014 at 08:24:25PM +0100, Dimitri John Ledkov a écrit :
>
> I thought autoreconf / dh-autoreconf install the versions provided by
> autotools-dev on Debian systems. If that's not the case, we should fix
> it.
Hi Bill, Dimitry, and everybody,
I looked at the autoconf and autotools-dev packages:
- The autoconf packages depend on autotools-dev and replace their config.sub
and
config.guess files by the ones provided by autotools-dev, using symbolic
links.
- The documentation in the autotools-dev package recommends as best practice
to run autoreconf, and discourages the other options.
Altogether, the wording was not restrictive as I thought.
Nevertheless, what would people think of adding a bit more explanation on the
purpose of replacing these files ? Not all readers will have
/usr/share/doc/autotools-dev/README.Debian.gz available on their computer. How
about the following addition or an equivalent?
"This ensures that these files can be updated distribution-wide when
introducing
new architectures."
Also, adding "at build time" somewhere may clarify that patching these files is
not
a good solution.
Have a nice Sunday,
--
Charles Plessy
Tsurumi, Kanagawa, Japan
--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140713003626.gd12...@falafel.plessy.net
