Re: Some upcoming dpkg changes, test and feedback welcome
On Wed, 20 Jul 2011, Guillem Jover wrote:
> I'd prefer to have the makefiles under scripts/mk/ (for example), as
> those are definitely dpkg-dev specific, while the tables (which can
> stay where they are now) can be eventually used by the C code.
Ok.
> I don't quite like the all-vars.mk name, but right now I cannot come
> up with something better. The rest look good, matching the tool name
> w/o the dpkg- prefix.
full.mk? complete.mk? common.mk? default.mk? dpkg-vars.mk? build-vars.mk?
> It probable makes sense to namespace vendor_derives_from with dpkg_.
Right.
> I think it would be more useful to add support to retrieve specific
> fields from dpkg-parsechangelog (for which we arelady have a wontfix
This is #284664. I dropped the wontfix tag because I also agree
that it would be useful.
> bug), and given that those should not really be overridable and I
> think uncommonly used, they don't seem to belong on the makefiles.
I don't really see the logic behind that statement.
> > I have also decided to not export the build flags in the environment by
> > default. If the caller really wants this, he should set
> > DPKG_EXPORT_BUILDFLAGS.
>
> Why?
Because many people believe that the correct way to pass CFLAGS to the
build system is on the ./configure command line and not through the
environment.
And debian/rules doesn't know all variables that buildflags.mk might
set so it can't reliably call unexport on all variables. Instead it should
use a flag that controls the behaviour of buildvars.mk.
That said if you believe the correct default is to export the variables
I'm happy to reverse the test and ask people who don't want it in the
environment to set DPKG_DONT_EXPORT_BUILDFLAGS.
I really don't have any personal preference here.
> > As discussed on debian-devel at the end of may, I have implemented
> > some changes to source format 3.0 (quilt) so that a build fails if there
> > are upstream changes which are not yet managed by quilt. Recording the
> > change in a new quilt patch must now be done explicitly by the maintainer
> > with dpkg-source --record-changes. This will require the user to give
> > a patch name and an editor will be run to let the maintainer edit the
> > patch header.
>
> Did you consider naming it something like --commit instead?
Nope, good idea. Shorter, maybe not clearer for everybody but
definitely clearer for anyone with VCS experience.
> > It required some important restructuring of the source package build
> > procedure so I would be glad to have some more people running with this.
> > Also you might have some input on the new interface.
>
> It would be preferable in general to split refactoring from new
> additional features so that reviewing is actually easier.
I know. For some reasons, I did not manage it this time. Every time I
tried I got hit by further complications.
And I also like to have each pushed commit as "working" at least in
theory. I don't like to split commits if I know that it leaves flaws
in some of the intermediary commits.
> > 4/ We should really think of releasing 1.16.1 once those changes are
> > merged. Guillem, do you have other things that you wanted to see merged
> > for 1.16.1?
>
> Yes, there are some pending changes I want to merge first, some
> requirements for the other multiarch changes, but I don't want to
> upload it as long as at least the the Build-Features stuff is on
> master.
What about merging pu/build-arch and documenting the Build-Features:
build-arch as only useful if the auto-detection doesn't work or has bad
side effects? And explain that in any case, its usage should only last
for as long as the auto-detection remains in place, that is until all
Debian packages have been modified to provide the required targets.
The rebuild stats shown on the tech-ctte bug proved that this is a
sensible migration scenario.
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Follow my Debian News ▶ http://RaphaelHertzog.com (English)
▶ http://RaphaelHertzog.fr (Français)
Reply to: