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
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
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}
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
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:
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)
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
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
8 matches
Mail list logo
