[SCM] dpkg's main repository branch, master, updated. 1.14.20-105-g3a960ff
The following commit has been merged in the master branch:
commit b77330f6fbe386fe2dde014b6010cd1d3283b9ae
Author: Guillem Jover [EMAIL PROTECTED]
Date: Sun Jul 6 21:34:54 2008 +0300
dpkg: Move trig_file_activate call from namenodetouse to its callers
diff --git a/ChangeLog b/ChangeLog
index 9962ff4..4ddf962 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,12 @@
+2008-07-06 Guillem Jover [EMAIL PROTECTED]
+
+ * src/main.h: Remove comment about side effect in namenodetouse.
+ * src/help.c (namenodetouse): Move call to trig_file_activate to ...
+ * src/archives.c (tarobject): ... here.
+ * src/processarc.c (process_archive): Likewise.
+ * src/remove.c (removal_bulk_remove_files): Likewise.
+ (removal_bulk_remove_leftover_dirs): Likewise.
+
2008-07-06 Michel Lespinasse [EMAIL PROTECTED]
* dselect/baselist.cc (baselist::startdisplay): Create the
diff --git a/src/archives.c b/src/archives.c
index 2c7c248..70fe4c5 100644
--- a/src/archives.c
+++ b/src/archives.c
@@ -400,6 +400,7 @@ int tarobject(struct TarInfo *ti) {
static struct varbuf conffderefn, hardlinkfn, symlinkfn;
static int fd;
const char *usename;
+ struct filenamenode *usenode;
struct conffile *conff;
struct tarcontext *tc= (struct tarcontext*)ti-UserData;
@@ -450,7 +451,10 @@ int tarobject(struct TarInfo *ti) {
}
}
- usename= namenodetouse(nifd-namenode,tc-pkg)-name + 1; /* Skip the
leading `/' */
+ usenode = namenodetouse(nifd-namenode, tc-pkg);
+ usename = usenode-name + 1; /* Skip the leading '/'. */
+
+ trig_file_activate(usenode, tc-pkg);
if (nifd-namenode-flags fnnf_new_conff) {
/* If it's a conffile we have to extract it next to the installed
diff --git a/src/help.c b/src/help.c
index 26385cb..9c9030e 100644
--- a/src/help.c
+++ b/src/help.c
@@ -53,7 +53,7 @@ struct filenamenode *namenodetouse(struct filenamenode
*namenode, struct pkginfo
if (!namenode-divert) {
r = namenode;
-goto found;
+return r;
}
debug(dbg_eachfile,namenodetouse namenode=`%s' pkg=%s,
@@ -70,8 +70,6 @@ struct filenamenode *namenodetouse(struct filenamenode
*namenode, struct pkginfo
namenode-divert-pkg ? namenode-divert-pkg-name : none,
r-name);
- found:
- trig_file_activate(r, pkg);
return r;
}
diff --git a/src/main.h b/src/main.h
index 49a1973..a1a30c0 100644
--- a/src/main.h
+++ b/src/main.h
@@ -208,9 +208,6 @@ int chmodsafe_unlink_statted(const char *pathname, const
struct stat *stab,
const char **failed);
void checkpath(void);
-/* NB side effect! This not only computes the appropriate filename
- * to use including thinking about any diversions, but also activates
- * any file triggers. */
struct filenamenode *namenodetouse(struct filenamenode*, struct pkginfo*);
/* all ...'s are const char*'s ... */
diff --git a/src/processarc.c b/src/processarc.c
index a3b455d..b0582b9 100644
--- a/src/processarc.c
+++ b/src/processarc.c
@@ -632,12 +632,17 @@ void process_archive(const char *filename) {
*/
reversefilelist_init(rlistit,pkg-clientdata-files);
while ((namenode= reversefilelist_next(rlistit))) {
+struct filenamenode *usenode;
+
if ((namenode-flags fnnf_new_conff) ||
(namenode-flags fnnf_new_inarchive))
continue;
+usenode = namenodetouse(namenode, pkg);
+trig_file_activate(usenode, pkg);
+
fnamevb.used= fnameidlu;
-varbufaddstr(fnamevb, namenodetouse(namenode,pkg)-name);
+varbufaddstr(fnamevb, usenode-name);
varbufaddc(fnamevb,0);
if (!stat(namenode-name,stab) S_ISDIR(stab.st_mode)) {
diff --git a/src/remove.c b/src/remove.c
index 1f80a4a..679441e 100644
--- a/src/remove.c
+++ b/src/remove.c
@@ -213,15 +213,21 @@ static void removal_bulk_remove_files(
reversefilelist_init(rlistit,pkg-clientdata-files);
leftover = NULL;
while ((namenode= reversefilelist_next(rlistit))) {
+ struct filenamenode *usenode;
+
debug(dbg_eachfile, removal_bulk `%s' flags=%o,
namenode-name, namenode-flags);
if (namenode-flags fnnf_old_conff) {
push_leftover(leftover,namenode);
continue;
}
+
+ usenode = namenodetouse(namenode, pkg);
+ trig_file_activate(usenode, pkg);
+
varbufreset(fnvb);
varbufaddstr(fnvb,instdir);
- varbufaddstr(fnvb,namenodetouse(namenode,pkg)-name);
+ varbufaddstr(fnvb, usenode-name);
before= fnvb.used;
varbufaddstr(fnvb,DPKGTEMPEXT);
@@ -340,6 +346,8 @@ static void removal_bulk_remove_leftover_dirs(struct
pkginfo *pkg) {
reversefilelist_init(rlistit,pkg-clientdata-files);
leftover = NULL;
while ((namenode= reversefilelist_next(rlistit))) {
+struct filenamenode *usenode;
+
debug(dbg_eachfile, removal_bulk `%s' flags=%o,
namenode-name, namenode-flags);
if (namenode-flags fnnf_old_conff) {
@@ -347,9 +355,12 @@ static void
[SCM] dpkg's main repository branch, master, updated. 1.14.20-105-g3a960ff
The following commit has been merged in the master branch:
commit 3a9602b8ff08d924e5e4fcba8fec640b43be
Author: Guillem Jover [EMAIL PROTECTED]
Date: Thu Jul 10 09:12:11 2008 +0300
Do not leave new conffile as .dpkg-new when it has been diverted
Also properly activate the file trigger for the diverted conffile.
Based on a patch by Timothy G Abbott. Closes: #58735, #476899
diff --git a/ChangeLog b/ChangeLog
index 4ddf962..5eeb626 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,11 @@
+2008-07-10 Guillem Jover [EMAIL PROTECTED],
+Timothy G Abbott [EMAIL PROTECTED]
+
+ * src/configure.c (deferred_configure): Call namenodetouse to handle
+ diverted conffiles. Use trig_file_activate on usenode, instead of
+ trig_file_activate_byname, to activate the correct file trigger for
+ the diverted conffile.
+
2008-07-06 Guillem Jover [EMAIL PROTECTED]
* src/main.h: Remove comment about side effect in namenodetouse.
diff --git a/debian/changelog b/debian/changelog
index 63f3d52..7b807bc 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -28,6 +28,9 @@ dpkg (1.15.0) UNRELEASED; urgency=low
* Print a longer string when a disallowed field value is found when parsing.
* Use $(filter ...) instead of $(findstring ...) to extract space separated
options from DEB_BUILD_OPTIONS in debian/rules.
+ * Do not leave new conffile as .dpkg-new when it has been diverted, also
+properly activate the file trigger for the diverted conffile.
+Based on a patch by Timothy G Abbott. Closes: #58735, #476899
[ Raphael Hertzog ]
* Enhance dpkg-shlibdeps's error message when a library can't be found to
diff --git a/src/configure.c b/src/configure.c
index 5bf60d5..0924020 100644
--- a/src/configure.c
+++ b/src/configure.c
@@ -171,7 +171,12 @@ void deferred_configure(struct pkginfo *pkg) {
* processed this one.
*/
for (conff= pkg-installed.conffiles; conff; conff=
conff-next) {
- r= conffderef(pkg, cdr, conff-name);
+ struct filenamenode *usenode;
+
+ usenode = namenodetouse(findnamenode(conff-name,
+fnn_nocopy), pkg);
+
+ r = conffderef(pkg, cdr, usenode-name);
if (r == -1) {
conff-hash= EMPTY_HASH;
continue;
@@ -207,7 +212,8 @@ void deferred_configure(struct pkginfo *pkg) {
what= cfo_identical;
} else if (!strcmp(currenthash,NONEXISTENTFLAG)
fc_conff_miss) {
fprintf(stderr, _(\nConfiguration file `%s',
does not exist on system.\n
- Installing new config
file as you request.\n), conff-name);
+ Installing new config file
as you request.\n),
+ usenode-name);
what= cfo_newconff;
useredited= -1;
distedited= -1;
@@ -231,9 +237,11 @@ void deferred_configure(struct pkginfo *pkg) {
debug(dbg_conff,
deferred_configure `%s' (= `%s')
useredited=%d distedited=%d what=%o,
- conff-name, cdr.buf, useredited,
distedited, what);
+ usenode-name, cdr.buf, useredited, distedited,
+ what);
- what=promptconfaction(conff-name, cdr.buf, cdr2.buf,
useredited, distedited, what);
+ what = promptconfaction(usenode-name, cdr.buf,
cdr2.buf,
+ useredited, distedited, what);
switch (what ~(cfof_isnew|cfof_userrmd)) {
case cfo_keep | cfof_backup:
@@ -246,7 +254,7 @@ void deferred_configure(struct pkginfo *pkg) {
varbufaddstr(cdr,DPKGDISTEXT);
varbufaddc(cdr,0);
strcpy(cdr2rest,DPKGNEWEXT);
- trig_file_activate_byname(conff-name,
pkg);
+ trig_file_activate(usenode, pkg);
if (rename(cdr2.buf,cdr.buf))
fprintf(stderr,
_(dpkg: %s:
warning - failed to rename `%.250s' to `%.250s': %s\n),
@@ -279,10 +287,11 @@ void deferred_configure(struct pkginfo *pkg) {
pkg-name,
cdr.buf, cdr2.buf, strerror(errno));
/* fall through */
Re: Multiarch and idea for improved diversions and alternatives handling
Neil Williams [EMAIL PROTECTED] writes: On Fri, 2008-07-04 at 08:33 +0200, Tollef Fog Heen wrote: * Neil Williams | Just a thought - why use /usr/lib/$ARCH and /usr/include/$ARCH at all | when it would (IMHO) be simpler to use /usr/$TRIPLET/ and put the entire | package under that, as we do with dpkg-cross currently: How would you then handle libraries that go in /lib? (Apart from the fact that I think just using a subdirectory of /usr/lib is much neater than random subdirectories in /usr. /lib/ /arm-linux-gnu/lib/ (did I miss that bit?) A single subdirectory of /usr is, IMHO, neater than a subdirectory of /usr/include and /usr/lib/. It would also mean less changes for those who are currently using multiple architectures on one system for the purposes of cross building. I wouldn't want to go the whole hog though and have /arm-linux-gnu/usr/lib /arm-linux-gnu/lib because that would be ugly, at least to me. | /usr/include/ | /usr/arm-linux-gnu/include/ Please note that the initial goal of multiarch at least has been just running of packages from foreign architectures. Not building them. True but the current usage of these mechanisms is in cross-building so sometimes the results of having to do something without major changes elsewhere can be helpful in designing the subsequent mechanism. The current mechanism is a total mess and needs to be thrown out and done right in any case. binutils on amd64 uses /usr/i386-linux-gnu/lib while i386 uses /usr/i486-linux-gnu/lib. So cross-building will fail there anyway. It also misses /i486-linux-gnu/lib making several core libraries go missing. Not to mention that multilib gcc does not provide the cross compiler binaries for the other supported archs, i.e. i486-linux-gnu-gcc on amd64. Further those directories are totaly wrong when compiling code for e.g. uclibc. The binutils upstream has further decided that it is not binutils place to support multiarch directories. That is a job of the compiler. As such binutils should be stoped from blindly adding the (wrong) cross-compile dir and gcc should add the right directories. So no matter what actual path you pick there has to be exactly the same change. Both binutils and gcc need adapting. | multiarch could even add: | /usr/share/ | /usr/arm-linux-gnu/share Pardon my language, but this is crack. The point of /usr/share is you can share it between systems. If you go down this route, just use a chroot and some wrapper scripts to bounce between them instead. It was only a suggestion for /usr/share - it was an alternative to renaming the package to get a different directory in /usr/share/ as the current tools do. Until all suitable packages have things like translations separated out into TDebs and other things like images in a -data or -common package instead of being packaged along with the architecture-dependent binaries, conflicts will occur if /usr/share is used as intended. Then you could not just share /usr/share via nfs but would have to share all the multiarch share dirs. bad bad bad. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: Idea for improved diversions and alternatives handling
Neil Williams [EMAIL PROTECTED] writes: Goswin von Brederlow wrote: working on dpkg reminded me that I wanted to propose a better diversion and alternatives handling for debian packages. Currently they have to be manually added and removed in the maintainer scripts. This method is prone to errors and can easily leave diversions or alternatives behind. Instead I suggest creating two new control files detailing the diversions and alternatives a package should have. Can symlinks be supported in the declarative control file stanzas? Don't symlinks work in diversions now? Diverting should just move the file around so I see no reason why it should even care about the file type. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
New Build-Options field and build-arch option, please review
Hello,
in order to fix #229357 I decided to add a new Build-Options field.
I modified Dpkg::BuildOptions to parse this field and DEB_BUILD_OPTIONS.
And I added support for a build-arch option, that if present, will let
dpkg-buildpackage call debian/rules build-arch and build-indep.
It's not obvious that this was the right choice when you think of the
currently existing build options but once you start thinking of possible
additions (as requested in #489771), it becomes more evident that it makes
sense. Even if some build options should really only be used in
the field while others should only be used in the environment variable,
the possibility to override the former with the latter is nice.
The current patchset is available in my public repository but I'll attach
it as well so that you can easily review it. I intend to merge it this
week-end after some tests but feel free to test and comment in the mean
time.
http://git.debian.org/?p=users/hertzog/dpkg.git;a=shortlog;h=refs/heads/pu/bug229357-build-options
The patchset only applies on top of master.
Cheers,
--
Raphaël Hertzog
Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/
From 1ebeff797bc36c91e50f02c6d32cba094e827add Mon Sep 17 00:00:00 2001
From: Raphael Hertzog [EMAIL PROTECTED]
Date: Sun, 6 Jul 2008 22:03:27 +0200
Subject: [PATCH] Refactor Dpkg::BuildOptions to handle Build-Options field
* scripts/Dpkg/BuildOptions.pm: complete rewrite of the module
to handle various sources of build options: some options are auto-set
based on the standards version, then the maintainer can define options
with the Build-Options field in debian/control and last the builder
can use DEB_BUILD_OPTIONS to override everything. Some options are
meant to be exported through DEB_BUILD_OPTIONS and some are not.
* scripts/t/300_Dpkg_BuildOptions.t: adjust test suite for the new module
* scripts/dpkg-buildpackage.pl: adjust to use the new Dpkg::BuildOptions
API.
* scripts/Dpkg/Fields.pm, scripts/Dpkg/Source/Package.pm: add the new
Build-Options field as a valid field in the source section of
debian/control (and in .dsc files).
---
scripts/Dpkg/BuildOptions.pm | 257 +
scripts/Dpkg/Fields.pm|2 +-
scripts/Dpkg/Source/Package.pm|5 +-
scripts/dpkg-buildpackage.pl | 10 +-
scripts/t/300_Dpkg_BuildOptions.t | 61 +
5 files changed, 273 insertions(+), 62 deletions(-)
diff --git a/scripts/Dpkg/BuildOptions.pm b/scripts/Dpkg/BuildOptions.pm
index 9d6741b..5b2acdd 100644
--- a/scripts/Dpkg/BuildOptions.pm
+++ b/scripts/Dpkg/BuildOptions.pm
@@ -5,51 +5,252 @@ use warnings;
use Dpkg::Gettext;
use Dpkg::ErrorHandling qw(warning);
+use Dpkg::Control;
+use Dpkg::Version qw(compare_versions);
-sub parse {
-my ($env) = @_;
+# Define behavior for known options:
+# export - the option is meant to be exported in DEB_BUILD_OPTIONS
+# valued - the option can have a value
+# check_value_rx - if defined, a regex to check the value, invalid value
+# will lead to the option being discarded
+# min_standards_version - if the s-v field is = to the version given,
+# the option is auto-enabled
+our %OPTIONS = (
+noopt = {
+export = 1,
+valued = 0,
+},
+nostrip = {
+export = 1,
+valued = 0,
+},
+nocheck = {
+export = 1,
+valued = 0,
+},
+parallel = {
+export = 1,
+valued = 1,
+check_value_rx = qr/^-?\d+$/,
+},
+);
-$env ||= $ENV{DEB_BUILD_OPTIONS};
+=head1 NAME
-unless ($env) { return {}; }
+Dpkg::BuildOptions - handle build options from debian/control and environment
-my %opts;
+=head1 DESCRIPTION
-foreach (split(/\s+/, $env)) {
- unless (/^([a-z][a-z0-9_-]*)(=(\S*))?$/) {
-warning(_g(invalid flag in DEB_BUILD_OPTIONS: %s), $_);
-next;
+It provides an object to analyze and manipulate build options as defined
+by combining information provided by the debian/control file and by the
+DEB_BUILD_OPTIONS environment variable.
+
+=head1 FUNCTIONS
+
+=over 4
+
+=item $b = Dpkg::BuildOptions($file)
+
+Create a new Dpkg::BuildOptions object. The $file parameter is simply
+forwarded to Dpkg::Control-new($file). If undef, it will simply use
+debian/control by default.
+
+=cut
+sub new {
+my ($this, $ctl_file) = @_;
+my $class = ref($this) || $this;
+my $self = {
+'opts' = {},
+'control' = Dpkg::Control-new($ctl_file),
+};
+bless $self, $class;
+$self-parse_options();
+return $self;
+}
+
+=item $b-reset()
+
+Forget all options already parsed. Start afresh.
+
+=cut
+sub reset {
+my ($self) = @_;
+$self-{'opts'} = {};
+}
+
+=item $b-parse_options()
+
+Do a full parse of options, including the Build-Options field in
+debian/control and the DEB_BUILD_OPTIONS variable.
+
+=cut
+sub parse_options {
+my ($self) = @_;
+
Re: New Build-Options field and build-arch option, please review
El 10/07/08 18:02 Raphael Hertzog escribió: Hello, in order to fix #229357 I decided to add a new Build-Options field. I modified Dpkg::BuildOptions to parse this field and DEB_BUILD_OPTIONS. And I added support for a build-arch option, that if present, will let dpkg-buildpackage call debian/rules build-arch and build-indep. It's not obvious that this was the right choice when you think of the currently existing build options but once you start thinking of possible additions (as requested in #489771), it becomes more evident that it makes sense. Even if some build options should really only be used in the field while others should only be used in the environment variable, the possibility to override the former with the latter is nice. I'm not really sure this is right. There are two things that we want to do here: declare that a package supports something, and asking the package to do something. This difference is blurred now, and I think it is confusing. OTOH, it gives the benefit of being able to ignore the package capabilities via the environment (ie, unset a given option). I fear it will give rise to abuses such as setting parallel=n in the control file. Saludos, Felipe Sateler signature.asc Description: This is a digitally signed message part.
Processed: setting package to dselect dpkg-dev dpkg, tagging 58735, tagging 476899
Processing commands for [EMAIL PROTECTED]: # Automatically generated email from bts, devscripts version 2.10.33 # via tagpending # # dpkg (1.15.0) UNRELEASED; urgency=low # # * Do not leave new conffile as .dpkg-new when it has been diverted, also #properly activate the file trigger for the diverted conffile. #Based on a patch by Timothy G Abbott. Closes: #58735, #476899 # package dselect dpkg-dev dpkg Ignoring bugs not assigned to: dpkg-dev dselect dpkg tags 58735 + pending Bug#58735: [CONFFILE] dpkg: leaves diverted conffile.dpkg-new file after installation Tags were: patch Bug#476899: dpkg: Leaves new conffiles as file.dpkg-new if the conffile is diverted Tags added: pending tags 476899 + pending Bug#476899: dpkg: Leaves new conffiles as file.dpkg-new if the conffile is diverted Tags were: pending patch Bug#58735: [CONFFILE] dpkg: leaves diverted conffile.dpkg-new file after installation Tags added: pending End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#229357: New Build-Options field and build-arch option, please review
Hello,
in order to fix #229357 I decided to add a new Build-Options field.
I modified Dpkg::BuildOptions to parse this field and DEB_BUILD_OPTIONS.
And I added support for a build-arch option, that if present, will let
dpkg-buildpackage call debian/rules build-arch and build-indep.
It's not obvious that this was the right choice when you think of the
currently existing build options but once you start thinking of possible
additions (as requested in #489771), it becomes more evident that it makes
sense. Even if some build options should really only be used in
the field while others should only be used in the environment variable,
the possibility to override the former with the latter is nice.
The current patchset is available in my public repository but I'll attach
it as well so that you can easily review it. I intend to merge it this
week-end after some tests but feel free to test and comment in the mean
time.
http://git.debian.org/?p=users/hertzog/dpkg.git;a=shortlog;h=refs/heads/pu/bug229357-build-options
The patchset only applies on top of master.
Cheers,
--
Raphaël Hertzog
Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/
From 1ebeff797bc36c91e50f02c6d32cba094e827add Mon Sep 17 00:00:00 2001
From: Raphael Hertzog [EMAIL PROTECTED]
Date: Sun, 6 Jul 2008 22:03:27 +0200
Subject: [PATCH] Refactor Dpkg::BuildOptions to handle Build-Options field
* scripts/Dpkg/BuildOptions.pm: complete rewrite of the module
to handle various sources of build options: some options are auto-set
based on the standards version, then the maintainer can define options
with the Build-Options field in debian/control and last the builder
can use DEB_BUILD_OPTIONS to override everything. Some options are
meant to be exported through DEB_BUILD_OPTIONS and some are not.
* scripts/t/300_Dpkg_BuildOptions.t: adjust test suite for the new module
* scripts/dpkg-buildpackage.pl: adjust to use the new Dpkg::BuildOptions
API.
* scripts/Dpkg/Fields.pm, scripts/Dpkg/Source/Package.pm: add the new
Build-Options field as a valid field in the source section of
debian/control (and in .dsc files).
---
scripts/Dpkg/BuildOptions.pm | 257 +
scripts/Dpkg/Fields.pm|2 +-
scripts/Dpkg/Source/Package.pm|5 +-
scripts/dpkg-buildpackage.pl | 10 +-
scripts/t/300_Dpkg_BuildOptions.t | 61 +
5 files changed, 273 insertions(+), 62 deletions(-)
diff --git a/scripts/Dpkg/BuildOptions.pm b/scripts/Dpkg/BuildOptions.pm
index 9d6741b..5b2acdd 100644
--- a/scripts/Dpkg/BuildOptions.pm
+++ b/scripts/Dpkg/BuildOptions.pm
@@ -5,51 +5,252 @@ use warnings;
use Dpkg::Gettext;
use Dpkg::ErrorHandling qw(warning);
+use Dpkg::Control;
+use Dpkg::Version qw(compare_versions);
-sub parse {
-my ($env) = @_;
+# Define behavior for known options:
+# export - the option is meant to be exported in DEB_BUILD_OPTIONS
+# valued - the option can have a value
+# check_value_rx - if defined, a regex to check the value, invalid value
+# will lead to the option being discarded
+# min_standards_version - if the s-v field is = to the version given,
+# the option is auto-enabled
+our %OPTIONS = (
+noopt = {
+export = 1,
+valued = 0,
+},
+nostrip = {
+export = 1,
+valued = 0,
+},
+nocheck = {
+export = 1,
+valued = 0,
+},
+parallel = {
+export = 1,
+valued = 1,
+check_value_rx = qr/^-?\d+$/,
+},
+);
-$env ||= $ENV{DEB_BUILD_OPTIONS};
+=head1 NAME
-unless ($env) { return {}; }
+Dpkg::BuildOptions - handle build options from debian/control and environment
-my %opts;
+=head1 DESCRIPTION
-foreach (split(/\s+/, $env)) {
- unless (/^([a-z][a-z0-9_-]*)(=(\S*))?$/) {
-warning(_g(invalid flag in DEB_BUILD_OPTIONS: %s), $_);
-next;
+It provides an object to analyze and manipulate build options as defined
+by combining information provided by the debian/control file and by the
+DEB_BUILD_OPTIONS environment variable.
+
+=head1 FUNCTIONS
+
+=over 4
+
+=item $b = Dpkg::BuildOptions($file)
+
+Create a new Dpkg::BuildOptions object. The $file parameter is simply
+forwarded to Dpkg::Control-new($file). If undef, it will simply use
+debian/control by default.
+
+=cut
+sub new {
+my ($this, $ctl_file) = @_;
+my $class = ref($this) || $this;
+my $self = {
+'opts' = {},
+'control' = Dpkg::Control-new($ctl_file),
+};
+bless $self, $class;
+$self-parse_options();
+return $self;
+}
+
+=item $b-reset()
+
+Forget all options already parsed. Start afresh.
+
+=cut
+sub reset {
+my ($self) = @_;
+$self-{'opts'} = {};
+}
+
+=item $b-parse_options()
+
+Do a full parse of options, including the Build-Options field in
+debian/control and the DEB_BUILD_OPTIONS variable.
+
+=cut
+sub parse_options {
+my ($self) = @_;
+
Bug#229357: New Build-Options field and build-arch option, please review
El 10/07/08 18:02 Raphael Hertzog escribió: Hello, in order to fix #229357 I decided to add a new Build-Options field. I modified Dpkg::BuildOptions to parse this field and DEB_BUILD_OPTIONS. And I added support for a build-arch option, that if present, will let dpkg-buildpackage call debian/rules build-arch and build-indep. It's not obvious that this was the right choice when you think of the currently existing build options but once you start thinking of possible additions (as requested in #489771), it becomes more evident that it makes sense. Even if some build options should really only be used in the field while others should only be used in the environment variable, the possibility to override the former with the latter is nice. I'm not really sure this is right. There are two things that we want to do here: declare that a package supports something, and asking the package to do something. This difference is blurred now, and I think it is confusing. OTOH, it gives the benefit of being able to ignore the package capabilities via the environment (ie, unset a given option). I fear it will give rise to abuses such as setting parallel=n in the control file. Saludos, Felipe Sateler signature.asc Description: This is a digitally signed message part.
