[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

RV: Request: building all packages from source



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.

Attachment: signature.asc
Description: pat905529187

_______________________________________________
Pkg-games-devel mailing list
Pkg-games-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-games-devel

Reply to: