On Mon, Jan 19, 2004 at 12:16:47PM +0000, Henning Makholm wrote:
> Scripsit Anthony Towns <aj@azure.humbug.org.au>
> > On Sat, Jan 17, 2004 at 08:24:44PM +0000, Henning Makholm wrote:
> > > I like to think that our promise that main is closed with respect to
> > > building tools implies, at least morally,
> > Oh dear. There are lots of "moral" things we can be done, lots of which
> > are more important than this. Hopefully we can still avoid getting too
> > puritanical on this issue.
> So providing the tools users need to rebuild our software from source
> is "puritanical"? Sheesh.
No, building up ideological arguments, and insisting we do something,
no matter the cost is "puritanical". You haven't done that, but once we
start declaring certain things to be "moral", it doesn't seem to take
us long to head down that way.
> > > Therefore, I hold that if we remove libtool1.4, then it becomes a bug
> > > if the internal configuration infrastructure in a package cannot be
> > > rebuilt without having libtool1.4 installed.
> > That's what build-depends are for.
> As far as I know, build-depends are for the things buildds need to
> have installed. Am I wrong?
If the buildds can rebuild a package with just the build-depends
installed, so can anyone else.
> > If you want to go through packages and work on ensuring that current
> > versions of libtool can be used to re-libtoolize them, that's fine
> I'm saying that libtool1.4 should not be gratuitously removed from the
> archive until someone has done this,
It's not going to be gratuitously removed, it's going to be removed if the
maintainer requests it.
> so that we are sure that we still
> ship all the tools needed to build our OS.
And if our build-depends are correct, and satisfied, we do do this.
> > I don't think it's a reportable bug -- if you make one change (updating
> > automake.in or whatever, or using X library functions), and things
> > stop working because you haven't made another change (updating to a new
> > libtool, or including the right headers respectively), well, that's really
> > your problem.
> Remark that the first change may well be limited to
> touch configure.in
*shrug*
> If that makes things break (and, because of libtool1.4 being gone, it
> is not possible to prevent the breakage by having the right packages
> installed), then I don't see how it can *not* be a bug.
The first change could well be "rm -rf *", too. That's even fewer
characters, and presumably you'd agree that it's not a bug that you can't
build the package easily after having done that. The question isn't how
easily you can stop something from building, it's how easily you can build
it. If touching configure.in makes that harder, well, don't do that, then.
Look at it this way: if you think libtool1.4 is worth keeping, take
it over.
Cheers,
aj
--
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.
Linux.conf.au 2004 -- Because we can.
http://conf.linux.org.au/ -- Jan 12-17, 2004
Attachment:
signature.asc
Description: Digital signature