On Thu, Jun 13, 2002 at 11:10:10PM +0100, Scott James Remnant wrote:
> I don't, AM_MAINTAINER_MODE will remove the need to touch all those
> files (it makes it so it doesn't generate all the "rebuild autotools
> files" rules aren't generated unless --enable-maintainer-mode is passed
> to configure).
This I will try. I've added it to my TODO list, but it probably will not
go into the first repackaged version until I'm sure things work properly.
The packages already change too much for me to be comfortable cramming
something else in right now.
My SDL packages use DBS now, so the normally associated troubles with
managing such a diff will go away with the next upload. I won't mind
doing this then because the huge diff created (and in theory regenerated
often) is simple enough to handle. If I can get desirable results without
the 50+ line hacks on i386 and at least one other arch and autothing
version (probably PPC since I have intermittent access to one and one of
the Debian PPC guys follows the SDL packages closely), then I will be
happy to stop using autothings in debian/rules binary.
I will not accept the current behavior as a bug, however, because the
currently used method can be made to not produce a few megs of diff file
without much trouble. What you propose will add huge amounts to the
diffs, most of which can be expected to not apply to future versions, and
is not trivally thrown out before applying the Debian diff to a new
upstream version. This is of course one of the reasons why DBS exists,
but it is not an agreed-upon standard (many developers consider use of DBS
to be a bug in and of itself), and I'm not willing to advocate replacing a
few small hacks with a number of really big ones (in terms of hackishness
and archive diskspace..)
To those who would use DBS even though the documentation basically doesn't
exist, even though many developers would file RC bugs against the package
for using it if they thought they could get away with it, and even though
it isn't anything approaching a standard, I'll agree (once I've seen it
work successfully for more than just me) that it's probably not necessary
to actually have a build-dep on autothings.
> If all else fails, and you *really* need to run autotools on the build
> platform (I really can't see an unfixable reason for this) then you
> should build-dep on the right version of automake and call the versioned
> binary not the alternative.
But that is my point - there is no need to build-dep on a specific version
if the scripts are portable across autothing versions. These are.
> > SDL, of course, works with any version of autoconf 2.13 or greater and any
> > version of automake 1.4 or greater. And as long as I have the technical
> > ability to test previous and future versions, it will continue to work
> > that way.
> >
> There may be subtle differences that you don't know about. Do you
> really test every version of automake, autoconf and every variant on
> every build architecture?
I test autoconf2.13 and 2.53 with automake1.4 and (now) 1.6. Three of
these work together. I test them on i386 and when I get a chance, PPC.
It wasn't my idea for us to have support for a dozen oddball processors
with perhaps a dozen users, total. Can you tell me that there's not some
subtle breakage like that across glibc versions? Of course you can't. We
find these things - we fix them when we find them.
--
Joseph Carter <knghtbrd@bluecherry.net> We can hope for the future
But there might not be one
<Mercury> LordHavoc: The reason why GL has overdraw is because it is only
using HALF of the system they designed for vis.
<Mercury> LordHavoc: Shooting itself in the foot.
* Dabb looks at all those bullet holes in his shoes - damn, lots :)
Attachment:
pgp32Kw8fAi30.pgp
Description: PGP signature