On Mon, Feb 18, 2008 at 12:47:41PM +0000, Mark Brown wrote:
> On Sun, Feb 17, 2008 at 11:55:03PM +0100, Bas Wijnen wrote:
> > On Sun, Feb 17, 2008 at 09:29:59PM +0000, Mark Brown wrote:
> > > If you're willing to do things by forcing a particular version in the
> > > general case then this sounds more like something that could be checked
> > > outside the standard package build process.
> >
> > No, I don't want to force a version, I want the package to force it.
>
> By forcing a version I mean doing so in the package.
Then I still don't understand your statement above. What is the thing
that you prefer to check outside the normal build process?
> > > If you're keen on introducing this I'd suggest doing some work to see
> > > how much effort would be involved in doing so.
>
> > Or do you mean I should manually transition some packages? I'm happy to
>
> Yes, that's the sort of thing I meant.
Ok, I'll see what I can do. I repeat my request for packages which may
be hard to transition. If I get none of those, I'll just pick some
random packages from the archive which currently build-depend on
autotools-dev.
It would be nice to have some consensus that my transition efforts are
not wasted though. So I have a question:
Does everyone agree that it would in theory be better to run autotools
during the build process? In other words, if you don't have to do
anything to your packages for it, would you have a problem with this?
("you" above is addressed to anyone reading this.)
> > > We already have regular tests for things that aren't caught by the
> > > normal build processes, this could be checked in a similar fashion.
>
> > We could check if an automake upgrade would produce many FTBFSs, if the
> > packages are already build-depending on automake. However, most
> > packages currently don't do that, and it's in the general case not
> > possible (AFAICS) to run it for them automatically.
>
> What I'm suggesting is that if you add something out of the normal build
> process which regenerates autotools stuff (like an extra target in the
> rules file, for example) then we could test this without doing it on
> every single build.
I still consider "not building from source" to be a Bad Thing, and
therefore I think this is the wrong approach.
The best argument I've heard so far, is "we care more about other bugs,
and we want to be able to ignore those". However, I don't really think
this is a big problem. The program was tested with the same automake
version that it is built with. Why would it suddenly FTBFS? I can see
that it might do so while doing the transition to running autotools
during the build. But that's the maintainer's problem. They can take
their time (or ask me for help :-) ). It's not a big problem if they
delay following my proposed rule. Once they have changed their rules
files, things should just keep working.
And if it doesn't, a dirty workaround of not running autotools can
always be installed, if fixing whatever problem does come up seems to be
too hard.
Build-depending on versioned automake doesn't look really nice, though.
This is how it currently should be done, AFAIK, but it might be better
to recommend against it. However, in that case great care must be taken
when increasing its version, similar to increasing the default gcc
version.
All this can easily be tested before actually starting the transition,
though, just like with gcc. Bugs can be filed and fixed to make
packages work with the newer automake before it becomes the default.
Transitions may be some work, but they shouldn't result in too much
breakage. And if the RMs don't like it, and want us to spend time on
other bugs, they can just say "the newer automake will not be the
default for the next release, therefore bugs with it are not RC".
> > > Personally, I expect the package to restore things to the state they
> > > were in the distribution tarball.
>
> > That has been suggested, but it would mean backing up generated files
> > which get overwritten during the build (such as config.guess and
> > config.sub). There seems to be agreement that such backing up is not
> > useful.
>
> My point is that I don't expect the clean target to clean with respect
> to anything except the upstream tarball rather than going around making
> things clean with respect to upstream revision control or similar.
So you don't want to remove files which are unchanged during the build.
Do you agree on removing all files which were changed though? I think
even that would require rerunning of some autotools parts in some cases,
but I'm not sure.
And just that statement, "all changed files should be removed by the
clean target", is enough to fix the bug we're talking about. This rule
automatically makes two builds in a row give identical results (except
for time stamps).
Of course this is a separate point. IMO clean should remove any file
which was changed during the build. And secondly, I think build should
regenerate everything it can. Combined, these can be formulated as
"clean should remove all non-source files", because every shipped
non-source file must be updated (and thus changed) by the build.
Thanks,
Bas
--
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://pcbcn10.phys.rug.nl/e-mail.html
Attachment:
signature.asc
Description: Digital signature