Bug#661538: Patch generalization and field to mark staged packages
On Wed, 13 Jun 2012, P. J. McDermott wrote: > Fair enough. I think a separate hash could address both of these points: > > sub field_get($) { > my ($field) = @_; > return $FIELDS{$field} if exists $FIELDS{$field}; > foreach my $key (keys %FIELDS_RE) { > return $FIELDS_RE{$key} if $field =~ m/^$key$/; > } > return undef; > } > > Would this be acceptable? Yes. > Do you have a preference between the supplementary attribute and the > separate hash? I tend to prefer the separate hash currently. If I change my mind during the review, it's easy to convert to the other way. Cheers, -- Raphaël Hertzog ◈ Debian Developer Get the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#661538: Patch generalization and field to mark staged packages
On 2012-06-13 02:01, Raphael Hertzog wrote: > It's sub-optimal. If we go that way, I would like: > > 1/ that you try direct access first, and fallback to use pattern matching > only if the direct access failed > 2/ use pattern matching only on fields that actually are patterns (i.e. > you should tag them with a supplementary attribute, or you should put them > in a separate hash) Fair enough. I think a separate hash could address both of these points: sub field_get($) { my ($field) = @_; return $FIELDS{$field} if exists $FIELDS{$field}; foreach my $key (keys %FIELDS_RE) { return $FIELDS_RE{$key} if $field =~ m/^$key$/; } return undef; } Would this be acceptable? Do you have a preference between the supplementary attribute and the separate hash? Thanks, -- P. J. McDermott(_/@\_),--. http://www.pehjota.net/ o< o o > / oo \ http://www.pehjota.net/contact.html o \ `-/| <> |. o o o"~v/_\--/_/ -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#661538: Patch generalization and field to mark staged packages
On Tue, 12 Jun 2012, P. J. McDermott wrote: > And the subroutines in Dpkg::Control::Fields that get values from > %FIELDS can call the following new subroutine to do so: > > sub field_get($) { > my ($field) = @_; > foreach my $key (keys %FIELDS) { > return $FIELDS{$key} if $field =~ m/^$key$/; > } > return undef; > } > > This should be fairly unintrusive. I'll test this further and check to > see if I've overlooked any complications before adding this to Wookey's > patch. Does this solution look obviously wrong in any way? It's sub-optimal. If we go that way, I would like: 1/ that you try direct access first, and fallback to use pattern matching only if the direct access failed 2/ use pattern matching only on fields that actually are patterns (i.e. you should tag them with a supplementary attribute, or you should put them in a separate hash) Cheers, -- Raphaël Hertzog ◈ Debian Developer Get the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#661538: Patch generalization and field to mark staged packages
On 2012-06-08 23:49, P. J. McDermott wrote: > Then could you (or anyone else) suggest a way to handle "Build-Depends- > StageN" and "Build-Depends-Indep-StageN" fields for any values of "N"? > Any clues in this direction would be appreciated. I'll look further > through the code tomorrow to see if I can come up with anything. Looking through the uses of %FIELDS in Dpkg::Control::Fields, I've come up with the following idea of a generic implementation to recognize fields for any numbered build stage. I propose supporting the use of regular expressions in %FIELDS keys. Staged build dependency fields can then be defined generally as follows: 'Build-Depends-Stage\d' => { allowed => ALL_SRC, dependency => 'normal', dep_order => 3, }, 'Build-Depends-Indep-Stage\d' => { allowed => ALL_SRC, dependency => 'normal', dep_order => 4, }, And the subroutines in Dpkg::Control::Fields that get values from %FIELDS can call the following new subroutine to do so: sub field_get($) { my ($field) = @_; foreach my $key (keys %FIELDS) { return $FIELDS{$key} if $field =~ m/^$key$/; } return undef; } This should be fairly unintrusive. I'll test this further and check to see if I've overlooked any complications before adding this to Wookey's patch. Does this solution look obviously wrong in any way? Thanks, -- P. J. McDermott(_/@\_),--. http://www.pehjota.net/ o< o o > / oo \ http://www.pehjota.net/contact.html o \ `-/| <> |. o o o"~v/_\--/_/ -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#661538: Patch generalization and field to mark staged packages
On 2012-06-08 02:00, Raphael Hertzog wrote: > This is not OK. It means that those fields would be basically unknown > when you're not doing a staged build. Yet they are always present > in debian/control (and probably the .dsc) and thus they need to exist > in that hash to avoid warnings, and to be able to output them in the > correct order, etc. Ah, yes, good point. Then could you (or anyone else) suggest a way to handle "Build-Depends- StageN" and "Build-Depends-Indep-StageN" fields for any values of "N"? Any clues in this direction would be appreciated. I'll look further through the code tomorrow to see if I can come up with anything. Thanks, -- P. J. McDermott(_/@\_),--. http://www.pehjota.net/ o< o o > / oo \ http://www.pehjota.net/contact.html o \ `-/| <> |. o o o"~v/_\--/_/ -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#661538: Patch generalization and field to mark staged packages
P. J. McDermott wrote: > As mentioned previously by Wookey and Jonathan, staged binary packages > should be marked as such in their control files so they aren't > accidentally uploaded to the archive as complete packages. > > To this end, I propose the addition of a new "Build-Stage: N" (or > similar) field. This would of course be added to %FIELDS in > Dpkg::Control::Fields and be set (if "stage=N" is found in > DEB_BUILD_OPTIONS) by dpkg-gencontrol. Thanks --- yes, this would be a comfort. Do I understand correctly that in the stage-N build, the installed versions of all build-time dependencies (and their dependencies, et cetera) must have build-stage >= (N-1)? What about the standard build? Does it happen repeatedly, incrementing the stage number, until the result is stable, or is there some other method for approximating the limit? :) Jonathan -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#661538: Patch generalization and field to mark staged packages
Hi, On Thu, 07 Jun 2012, P. J. McDermott wrote: > Generalization > == [...] > Rather than modifying a lot of dpkg code to handle field "patterns" or > the like, I propose a simple dynamic definition of "Build-Depends- > StageN" and "Build-Depends-Indep-StageN" hash elements in %FIELDS: > > 'Build-Depends-Stage'.$buildstage => { > allowed => ALL_SRC, > dependency => 'normal', > dep_order => 3, > }, > > Then $buildstage could be defined by parsing DEB_BUILD_OPTIONS in > Dpkg::Control::Fields. This is not OK. It means that those fields would be basically unknown when you're not doing a staged build. Yet they are always present in debian/control (and probably the .dsc) and thus they need to exist in that hash to avoid warnings, and to be able to output them in the correct order, etc. Cheers, -- Raphaël Hertzog ◈ Debian Developer Get the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#661538: Patch generalization and field to mark staged packages
Hi, I have some ideas to finish the patch that has been proposed in this bug report and hopefully address the concerns that have been raised. I'm proposing these ideas before implementing them just because I've only been programming in Perl and working with dpkg-dev code (beyond simply looking at it) for about a week. :) Generalization == In practice it looks like no more than two stages will be necessary, but, as Raphaël noted previously, it would be nice to have a more general solution for stage numbering. The current patch offers this in dpkg-buildpackage, dpkg-checkbuilddeps, and dpkg-source. The only place in which stages 1 and 2 are statically defined is in the Dpkg::Control::Fields module. Rather than modifying a lot of dpkg code to handle field "patterns" or the like, I propose a simple dynamic definition of "Build-Depends- StageN" and "Build-Depends-Indep-StageN" hash elements in %FIELDS: 'Build-Depends-Stage'.$buildstage => { allowed => ALL_SRC, dependency => 'normal', dep_order => 3, }, Then $buildstage could be defined by parsing DEB_BUILD_OPTIONS in Dpkg::Control::Fields. Staged Package Marking == As mentioned previously by Wookey and Jonathan, staged binary packages should be marked as such in their control files so they aren't accidentally uploaded to the archive as complete packages. To this end, I propose the addition of a new "Build-Stage: N" (or similar) field. This would of course be added to %FIELDS in Dpkg::Control::Fields and be set (if "stage=N" is found in DEB_BUILD_OPTIONS) by dpkg-gencontrol. -- P. J. McDermott(_/@\_),--. http://www.pehjota.net/ o< o o > / oo \ http://www.pehjota.net/contact.html o \ `-/| <> |. o o o"~v/_\--/_/ -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org