Re: Some upcoming dpkg changes, test and feedback welcome

On Wed, 2011-09-21 at 22:52:32 +0200, Raphael Hertzog wrote: > So I updated the field to return all distributions because either way > it's not going to change much (and it's always possible to add > DEB_FIRST_DISTRIBUTION later if we ever have to reconsider the question). Such variable still does

Re: Some upcoming dpkg changes, test and feedback welcome

* Raphael Hertzog [110922 13:59]: > We can imagine more use cases in the context of other distributions than > Debian. Ubuntu for example could want to adjust the behaviour when > targetting a source packages for an older release (since they always use > the codename in that field). > > > Currentl

Re: Some upcoming dpkg changes, test and feedback welcome

On Thu, 22 Sep 2011, Bernhard R. Link wrote: > Sorry for again joining in late in the distribution, but what is the use > case of this field exactly? ifeq($(DEB_DISTRIBUTION),unstable) $(error GNOME 3 packages should be uploaded to experimental) endif Or rather: ifneq(,$(filter unstable,$(DEB

Re: Some upcoming dpkg changes, test and feedback welcome

* Raphael Hertzog [110921 22:52]: >>> [...] DEB_DISTRIBUTION [...] > But this is all wishful thinking at this point given that I have no use > case where some analysis of the distributions returned needs to be > portable across several derivatives and Debian itself. Sorry for again joining in lat

Re: Some upcoming dpkg changes, test and feedback welcome

On Wed, 21 Sep 2011, Guillem Jover wrote: > So returning all the values is fine, and would be useful for other > derivatives where more than one is actually allowed, and for Debian > using equality should also be just fine (although using filter would > be more correct, would avoid archive checks a

Re: Some upcoming dpkg changes, test and feedback welcome

On Wed, 2011-09-21 at 09:02:39 +0200, Raphael Hertzog wrote: > On Tue, 20 Sep 2011, Guillem Jover wrote: > > > +# DEB_DISTRIBUTION: the first distribution of the current entry in > > > debian/changelog > > > > Why only the first, what makes it special? If there's multiple filter > > can always be

Re: Some upcoming dpkg changes, test and feedback welcome

On Tue, 20 Sep 2011, Guillem Jover wrote: > > +# DEB_SOURCE_PACKAGE: the source package name > > Why DEB_SOURCE_PACKAGE instead of say, DEB_SOURCE? I guess it depends if > we want to map to field names or to more descriptive (although probably > redundant) variable names. Yeah, for me the importa

Re: Some upcoming dpkg changes, test and feedback welcome

On Tue, 20 Sep 2011, Guillem Jover wrote: > I find having to define DPKG_EXPORT_BUILDFLAGS a bit ugly (less than > DPKG_DONT_EXPORT_BUILDFLAGS though). What about shifting completely > the responsibility to the includer over what specific variables to > export instead. As in: > > -include /usr/sha

Re: Some upcoming dpkg changes, test and feedback welcome

On Fri, 2011-07-29 at 16:31:36 +0200, Raphael Hertzog wrote: > On Wed, 20 Jul 2011, Raphael Hertzog wrote: > > Thus my personal preference would be to provide something to cover > > those use cases. > > I attached a patch for this. I ended up diverging slightly on the > variable names to be more c

Re: Some upcoming dpkg changes, test and feedback welcome

On Wed, 2011-07-20 at 14:32:50 +0200, Raphael Hertzog wrote: > On Wed, 20 Jul 2011, Guillem Jover wrote: > > > 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? > > Becau

Re: Some upcoming dpkg changes, test and feedback welcome

On Wed, 20 Jul 2011, Raphael Hertzog wrote: > Forgot to expand a bit: the version related variables are commonly used in > "get-orig-source" targets, and it would be nice to factor out the version > splitting logic. > > The source package name is often the same as the name of the only > binary pac

Re: Some upcoming dpkg changes, test and feedback welcome

Hi, On Wed, 20 Jul 2011, Guillem Jover wrote: > > 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 spl

Re: Some upcoming dpkg changes, test and feedback welcome

On Wed, 20 Jul 2011, Raphael Hertzog wrote: > > 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. Forgot to expand a bit: the version related variables a

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, bu

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