On Sun, Feb 10, 2008 at 03:48:20PM -0800, Russ Allbery wrote:
> Raphael Geissert <[EMAIL PROTECTED]> writes:
> 
> > Quoting the Debian Policy, section 4.9 Main building script:
> > debian/rules[1]
> >
> >> clean
> >> 
> >> This must undo any effects that the build and binary targets may
> >> have had, except that it should leave alone any output files
> >> created in the parent directory by a run of a binary target.  
> >
> > So according to the policy the clean target must put the original
> > files back on place.
> 
> This Policy dictate as written is pretty widely ignored and (IMO) is
> somewhat hard to defend in several of its implications.  We haven't
> figured out what to say instead, but deleting the files is fairly
> common right now.
> 
> See http://bugs.debian.org/397939 for some additional discussion.

Thank you for this link.  I would like to add a suggestion as a
solution.  IMO the important thing is, as stated by Bill, that "clean"
and "clean; binary; clean" should result in the same tree.  From the log
it seems that people agree that this implies either creating a huge
diff.gz, or running autotools in the clean target.

This is not true if you simply build the whole package from source.
That is, run autotools during build, remove all generated files,
including Makefile.in, configure, etc, in the clean target.

For some reason many people seem to think that the whole package must be
built from source, except for configure and Makefile.in.  I still don't
understand what the idea behind this exception is.  Especially when it
leads to unwanted concequences (unreadable diff.gzs, for example), I
don't think it is a good idea to hold on to the idea that running
autotools is not part of building the package.

Apart from that, this discussion is about users making changes to the
source and compiling a package with those changes in it.  When not
running autotools during build, that doesn't work if the user changes
Makefile.am or configure.ac.  Yet another undesirable effect of this
strange exception to "build everything from source".

I suggest to mandate "remove all generated files in the clean target"
(formulated in a way which includes "generated by upstream", not only
"generated by the build target), which implies "rebuild everything in
the build target".

With the current wording it is allowed to use shipped built files from
the upstream tarball, as long as the source is present.  It is even
allowed to ship the build results (uuencoded, for example) in the
diff.gz and use those.  I suppose we all agree that this is unacceptable
for normal build results.

Now reread the previous paragraph while thinking of Makefile.in instead
of "normal build results".  It is common practice to do exactly that:
ship and use pre-built versions, or even ship them in the diff.gz (which
then gets huge).  Makefile.am is only present as source-file, but it
isn't used at all during the build.  Any changes the user makes will not
be noticed by the build system.

I'd like to hear why this exception is so important for people.  Or
better yet, I'd like to hear that everyone agrees with me, so we can
make this change and finally to the Right Thing. :-)

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

Reply via email to