Request: building all packages from source

Bas Wijnen wijnen at debian.org
Wed Apr 23 12:32:47 UTC 2008


Hello,

There have been some discussions on -policy about what the clean target
should do exactly, and what should and what shouldn't be rebuilt during
package generation.  For testing things, I need a set of packages to
work on.  I am planning to use the games team's packages, so I'm asking
here if that is a problem.

First of all, I'll give my own opinion on this: I think everything
should be built from source during package generation, and a good way to
make sure this happens is by making the clean target remove all
generated files (including generated game data, Makefile.in, etc).

I am also thinking about a copyright file parser (for files using the
proposed parsable format).  For that, it is important to know which
files are sources and which aren't.  If clean would leave only source
files, this would also be possible.

Currently, requiring all packages to build everything from source
doesn't seem feasable.  So my idea is to do it in smaller steps.  First
make things optional, and if/when many packages are doing things, they
can be recommended and maybe later required.  The first steps I'm
planning to do are:

- Add a "realclean" target to debian/rules, which does what I think the
  clean target should do.
- Add rules to rebuild everything, so that debian/rules build will still
  work after debian/rules realclean.
- Store a list of Realclean-Build-Depends somewhere.  These are packages
  needed to make debian/rules realclean && debian/rules build work
  (which aren't in Build-Depends).  I don't have a clear idea of where
  to store this; debian/control would probably be best, but it shouldn't
  propagate to Packages.  Just like Build-Depends, actually. :-)  Ideas
  for other options are welcome. :-)

The main problem, and the reason people don't like it, is
autoconf/automake.  Rebuilding Makefile.in and configure is often hard.
There seems to be consensus that this is worth solving (debian/rules
would serve as documentation for how to regenerate the files for the
package), but it isn't seen as something with high priority.  In
particular, it shouldn't result in too many FTBFSs, for example when
automake gets upgraded to a new version.

For this I need some evidence: how hard is it really to write those
rules?  So I need to transition some packages into the shape I would
want them.  I hope you will let me use the team's packages for this.

If you don't have a problem with this, I shall implement the realclean
target plus rules to restore it, as described above.  I'll also make
realclean and clean the same target, so that things work as I want them
(everything is built from source for every package build).  This implies
that the Realclean-Build-Depends is empty, so I don't need to know where
to put it. :-)

So my questions to the team:
- Do you have a problem if I add realclean targets and build rules?
- Do you have a problem if I call them?  The other option is to allow the
  user to manually call them.  In that case, we're avoiding the possible
  FTBFS that people are fearing.  Such an FTBFS really is a bug which
  needs fixing anyway; not letting it show is only to be able to lower
  the severity of it.
- Do you know of packages which seem particularly hard to implement this
  for?
- Do you feel like helping? ;-)

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/pkg-games-devel/attachments/20080423/86b59e80/attachment.pgp 


More information about the Pkg-games-devel mailing list