Re: RV: Request: building all packages from source
On Wednesday 23 April 2008 8:37:28 am Miriam Ruiz wrote:
> Hi,
>
> I'm forwarding this from the Alioth's mailing list.
>
> 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.
>
> Greetings,
> Miry
>
> --- 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
>
> ______________________________________________
> Enviado desde Correo Yahoo! La bandeja de entrada más inteligente.
Feel free to test with funguloids. It uses and regenerates the autotools stuff
during build.
--
Regards,
Andres
Reply to: