Re: Some upcoming dpkg changes, test and feedback welcome
Hi!
On Fri, 2011-07-15 at 21:14:40 +0200, Raphael Hertzog wrote:
> 1/ Makefile snippets for use in debian/rules
>
> http://anonscm.debian.org/gitweb/?p=users/hertzog/dpkg.git;a=commitdiff;h=pu/makefile-snippets
Ok, so this is somewhat what I was proposing long time ago in
<http://lists.debian.org/debian-devel/2009/05/msg00044.html> :).
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.
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.
It probable makes sense to namespace vendor_derives_from with dpkg_.
> Should I also include some variables corresponding to changelog related
> variables ? If yes, we should certainly pick a set compatible with CDBS.
> DEB_SOURCE_PACKAGE
> DEB_VERSION
> DEB_NOEPOCH_VERSION
> DEB_UPSTREAM_VERSION
> DEB_DISTRIBUTION
I think it would be more useful to add support to retrieve specific
fields from dpkg-parsechangelog (for which we arelady have a wontfix
bug), and given that those should not really be overridable and I
think uncommonly used, they don't seem to belong on the makefiles.
> Note that the makefiles have been written in a way so that they do not
> result in useless forks for unused variables (thanks to Mike Hommey for
> the idea) and still ensure we run each command only once even if a
> variable is referenced multiple times.
Nice!
> 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?
> 2/ dpkg-source --record-changes
>
> http://anonscm.debian.org/gitweb/?p=users/hertzog/dpkg.git;a=shortlog;h=refs/heads/pu/master
The man pages command and option entries seem bogus, the italics and
roman fonts are inverted. The dashes for variable text should not be
escaped, escaping is only needed for literal strings that are for
example copy-and-pasted to a terminal.
> 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?
> 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.
> 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.
thanks,
guillem
Reply to: