Hi, On Sun, Apr 27, 2008 at 01:59:07AM -0400, Andres Mejia wrote: > On Wednesday 23 April 2008 8:37:28 am Miriam Ruiz wrote: > > I'm forwarding this from the Alioth's mailing list. Thanks. I sent it there because I thought it would be more appropriate there, but perhaps I was wrong about that. > > Just for the record, I share the same point of view as Bas regarding > > bulding everything from sources, but I already know that some other members > > of the Games Team won't like the packages to regenerate autotools stuff (We > > already had that discussion in IRC once). > > > > It would be nice to read the pros and cons people see. I'm especially > > interested in Sam's and Goneri's point of view, as it was quite different > > from mine. Ping! Would Sam, Goneri, or anyone else with an opinion please tell me if they object to (or support) me adding realclean targets to all games in the repository? And thoughts about calling them as normal clean targets would be welcome as well. In particular, why should a package ever use generated files during build? If there'll be no replies within 2 weeks, I'll go ahead and add realclean targets (and targets to recover from it). I shall not actually call them unless there is explicit support. This means that even if I mess up, no package will stop building if those changes are uploaded. > Feel free to test with funguloids. It uses and regenerates the > autotools stuff during build. Thanks. I'll have a look what I can do with it. However, what I'm looking for is trying to transition packages to using autotools during build, so packages which already do that are slightly less interesting for the purpose. > > --- Bas Wijnen <wijnen@debian.org> wrote: > > > Date: Wed, 23 Apr 2008 14:32:47 +0200 > > > From: Bas Wijnen <wijnen@debian.org> > > > To: pkg-games-devel@lists.alioth.debian.org > > > Subject: Request: building all packages from source > > > > > > 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
Attachment:
signature.asc
Description: Digital signature