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-bugs-dist-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 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-bugs-dist-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-bugs-dist-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-bugs-dist-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-bugs-dist-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-bugs-dist-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-bugs-dist-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-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
