Bug#864615: please update version of posix standard for scripts (section 10.4)
control: tag -1 -moreinfo +patch Hello, On Sat, Oct 14 2017, Adam D. Barratt wrote: > The 2016 edition is Technical Corrigendum 2. I'm not sure that it's > conventional to use versioning such as 4.2 in such cases, however. I'd > expect it to be referred to as SUSv4, SUSv4TC2, or SUSv4 2016 edition; > the latter seems to be more common. Thank you for the clarification, Adam. I am seeking seconds for the following patch. It's not so readable, so let me summarise the changes: - replace the string "SUSv3" with "SUSv4 (2016 edition)" wherever it appears - reflow paragraphs where necessary For the reasons explained in my previous e-mail, I think it's reasonable to make this change now. > diff --git a/policy/ch-files.rst b/policy/ch-files.rst > index d4df316..dc0d152 100644 > --- a/policy/ch-files.rst > +++ b/policy/ch-files.rst > @@ -202,9 +202,9 @@ may instead be easier to check the exit status of > commands directly. See > Every script should use ``set -e`` or check the exit status of *every* > command. > > -Scripts may assume that ``/bin/sh`` implements the SUSv3 Shell Command > -Language [#]_ plus the following additional features not mandated by > -SUSv3.. [#]_ > +Scripts may assume that ``/bin/sh`` implements the SUSv4 (2016 > +edition) Shell Command Language [#]_ plus the following additional > +features not mandated by SUSv4 (2016 edition).. [#]_ > > - ``echo -n``, if implemented as a shell built-in, must not generate a > newline. > @@ -237,18 +237,20 @@ SUSv3.. [#]_ > which are the same as for ``kill`` above, 13 (SIGPIPE) must be > allowed. > > -If a shell script requires non-SUSv3 features from the shell interpreter > -other than those listed above, the appropriate shell must be specified > -in the first line of the script (e.g., ``#!/bin/bash``) and the package > -must depend on the package providing the shell (unless the shell package > -is marked "Essential", as in the case of ``bash``). > - > -You may wish to restrict your script to SUSv3 features plus the above > -set when possible so that it may use ``/bin/sh`` as its interpreter. > -Checking your script with ``checkbashisms`` from the devscripts package > -or running your script with an alternate shell such as ``posh`` may help > -uncover violations of the above requirements. If in doubt whether a > -script complies with these requirements, use ``/bin/bash``. > +If a shell script requires non-SUSv4 (2016 edition) features from the > +shell interpreter other than those listed above, the appropriate shell > +must be specified in the first line of the script (e.g., > +``#!/bin/bash``) and the package must depend on the package providing > +the shell (unless the shell package is marked "Essential", as in the > +case of ``bash``). > + > +You may wish to restrict your script to SUSv4 (2016 edition) features > +plus the above set when possible so that it may use ``/bin/sh`` as its > +interpreter. Checking your script with ``checkbashisms`` from the > +devscripts package or running your script with an alternate shell such > +as ``posh`` may help uncover violations of the above requirements. If > +in doubt whether a script complies with these requirements, use > +``/bin/bash``. > > Perl scripts should check for errors when making any system calls, > including ``open``, ``print``, ``close``, ``rename`` and ``system``. > diff --git a/policy/ch-opersys.rst b/policy/ch-opersys.rst > index 7d9e20a..9574f82 100644 > --- a/policy/ch-opersys.rst > +++ b/policy/ch-opersys.rst > @@ -461,19 +461,19 @@ statement at the top of the script, like this: > test -f program-executed-later-in-script || exit 0 > > Often there are some variables in the ``init.d`` scripts whose values > -control the behavior of the scripts, and which a system administrator is > -likely to want to change. As the scripts themselves are frequently > -``conffile``\ s, modifying them requires that the administrator merge in > -their changes each time the package is upgraded and the ``conffile`` > -changes. To ease the burden on the system administrator, such > -configurable values should not be placed directly in the script. > +control the behavior of the scripts, and which a system administrator > +is likely to want to change. As the scripts themselves are frequently > +``conffile``\ s, modifying them requires that the administrator merge > +in their changes each time the package is upgraded and the > +``conffile`` changes. To ease the burden on the system administrator, > +such configurable values should not be placed directly in the script. > Instead, they should be placed in a file in ``/etc/default``, which > typically will have the same base name as the ``init.d`` script. This > -extra file should be sourced by the script when the script runs. It must > -contain only variable settings and comments in SUSv3 ``sh`` format. It > -may either be a ``conffile`` or a configuration file maintained by the > -package maintainer scripts. See :ref:`s-config-files`
Processed: Re: Bug#864615: please update version of posix standard for scripts (section 10.4)
Processing control commands: > tag -1 -moreinfo +patch Bug #864615 [debian-policy] please update version of posix standard for scripts (section 10.4) Removed tag(s) moreinfo. Bug #864615 [debian-policy] please update version of posix standard for scripts (section 10.4) Added tag(s) patch. -- 864615: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=864615 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#749826: Documenting `Multi-Arch: foreign`
Hello Helmut, On Mon, Sep 04 2017, Helmut Grohne wrote: > On Sat, Sep 02, 2017 at 08:44:14AM -0700, Sean Whitton wrote: >> Rather than introduce the new terminology 'intended interface', which >> we would definitely have to define, how about something like this: >> >> If all a package's architecture-dependent interfaces are listed >> in README.multiarch, the package is not considered to have any >> architecture-dependent interfaces for the purposes of determining >> whether it may be labelled Multi-Arch: foreign. > > This is not how it works. It's not like you can just mark any package > Multi-Arch: foreign after saying that it is > architecture-dependent. That documentation must come with a contract > saying that reverse dependencies must not use those > architecture-dependent interfaces. I see what you mean. I find the terminology "intended interface" confusing: if something is not intended as an interface, then it is simply not an interface. The interfaces of a package are up to its maintainer. I just pushed a commit using this text, which gets around this issue; let me know what you think: The interfaces of a package are determined by its maintainer. However, some packages might expose architecture dependencies when other packages use them in a manner not intended by the maintainer. This can happen when it is not clear which parts of the package are its interfaces. In such cases, where the package satisfies the criterion for ``Multi-Arch: foreign`` but might expose architecture dependency because it is not clear which parts of the package are its interfaces, the interfaces of the package should be described in the file ``debian/README.multiarch``. >> If libc6's use is legitimate then it seems we'd need to include this >> as an exception. > > Well, it's not exactly legitimate. It's more like unavoidable as Simon > pointed out in his reply. Technically, libc6's behaviour is wrong and > causes unpack errors. The reasonable solution would be prohibiting > coinstallation of libc6:mips and libc6:mipsel, but package metadata > does not allow us to do that currently (#747261 -> self-conflicts are > always ignored). The other option of removing Multi-Arch: same from > libc6 would essentially render Multi-Arch useless. So all we can do > now is pretend the issue wasn't there. I don't think Policy should be silent about this. I have pushed a commit adding a footnote which notes that libc6 is not expected to be in compliance. >> > * If you rebuild the source package with a very different >> > installation set (i.e. much newer Build-Depends), does it still >> > have to match with older instances? Example: #825146. What >> > divergence in installation sets is ok? >> >> We could just say that it must match the instances in the target >> suite. > > We could. That would render libgiac0 rc buggy for instance, because it > was built on mips64el three weeks later than on other architectures > and thus uses an incompatible gettext. Is this a problem? Don't we usually binNMU in such a situation? > That definition is pretty annoying for bootstraps though as > replicating ancient toolchain is kinda the opposite of what > bootstrappers do. I'm not sure what you mean. My suggestion is that we say it should match what's in the suite right now -- /not/ any ancient toolchain. >> Could you turn this into some commits against my branch, please? > > I tried and ran into a new problem: I am now convinced that we cannot > just describe one Multi-Arch value after another as they do share some > common values. That "interface" aspect and architecture-constraints on > dependencies is a common theme and likely deserves an introductory > text. > > Yet, I am attaching what I have. Thanks! Applied, and then followed up with a commit tweaking wording. > As Simon's mail demonstrates, we likely need more answers/consensus > before continuing. I'll reply in a separate mail. Do these remaining issues affect our definitions of the `foreign` and `no` values, or only the definitions for the other possible values? If we are finished with our definitions for `no` and `foreign`, I think it would be worth releasing them in Policy, of course with a caveat saying "there are other possible values". I say this as a package maintainer would has benefitted from reading your descriptions of `foreign` and `no`. These are useful and should be out there. -- Sean Whitton signature.asc Description: PGP signature
Bug#864615: please update version of posix standard for scripts (section 10.4)
On Sat, 2017-10-14 at 11:30 -0700, Sean Whitton wrote: > control: tag -1 +moreinfo > > Hello Ralf, > > On Sun, Jun 11, 2017 at 06:51:49PM +0200, Ralf Treinen wrote: > > section 10.4 says: > > > > Scripts may assume that /bin/sh implements the SUSv3 Shell > > Command > > Language ... > > > > This version of the standard is so outdated that it isn't even any > > longer available on the opengroup web site. Really? http://pubs.opengroup.org/onlinepubs/009695399/ is still there, and indeed referenced from https://en.wikipedia.org/wiki/Single_UNIX_Sp ecification > > The latest version of the > > standard is 4.2 (published in 2016), earlier versions currently > > available on the opengroup site are 4 (from 2008) and 4.1 (from > > 2013). > > Please consider updating the policy. > > I found the 2016 edition of version 4 of the SUS,[1] but what makes > you think that is version 4.2? I couldn't find that version number > anywhere. If they've changed their versioning scheme, maybe Policy > needs to use the expression "SUSv4 (2016 edition)"? The 2016 edition is Technical Corrigendum 2. I'm not sure that it's conventional to use versioning such as 4.2 in such cases, however. I'd expect it to be referred to as SUSv4, SUSv4TC2, or SUSv4 2016 edition; the latter seems to be more common. Regards, Adam
Bug#683495: Mandating use of /usr/bin/perl in Policy
On Sat, Oct 14, 2017 at 11:49:59AM -0700, Sean Whitton wrote: > control: tag -1 +patch > > Hello, > > I am seeking seconds for the following patch to close this bug, which I > think is uncontroversial at this point. > > > @@ -185,7 +185,7 @@ All command scripts, including the package maintainer > > scripts inside the > > package and used by ``dpkg``, should have a ``#!`` line naming the shell > > to be used to interpret them. > > > > -In the case of Perl scripts this should be ``#!/usr/bin/perl``. > > +In the case of Perl scripts this must be ``#!/usr/bin/perl``. > > > > When scripts are installed into a directory in the system PATH, the > > script name should not include an extension such as ``.sh`` or ``.pl`` > > ~ Seconded. > As has been pointed out by Gian, there is a broader issue of whether it > is right for Policy to say > > Perl programs and modules should follow the current Perl policy. > > or > > Perl programs and modules must follow the current Perl policy. > > I think this is actually quite tricky: if packages must follow the Perl > policy, does that erase the difference between 'should' and 'must' > requirements in the Perl policy? > > If someone thinks it is a big deal that Policy says only that packages > should follow the Perl policy, and is willing to do the work to handle > these complexities, they should file a new bug against Policy. > Otherwise, let's put that broader issue aside and just fix this > confusing inconsistency about shebangs. Logically speaking, since the Perl policy is a part of policy (at least, it is shipped in the same package and has the same update policies applied to it), it must be followed by all packages dealing with Perl. It seems that all that's really required here is an informational pointer that there is relevant information to be found in this separate document. However, if the statement above is kept, it should be changed to 'must'. Probably in 2001 when this statement, and the perl policy itself, was added to the policy package, many packages did not meet the perl policy, so this statement, with the 'should' wording, was needed to weaken the relationship, as a transitional arrangement. After 15 years, I think we can safely remove this. The same wording appears in relation to the menu policy, and though I haven't looked into it, the same reasoning might apply there. Cheers, Dominic.
Bug#846970: Patch to document Build-Indep-Architecture field
Hello, On Sat, Oct 14 2017, Mattia Rizzolo wrote: > On Sat, Oct 14, 2017 at 11:15:10AM -0700, Sean Whitton wrote: >> I am seeking seconds for the following patch. > > Thank you for working on this! Thank you for the review, though I don't believe I need to update my patch in light of your comments. See responses below. >> - I've included the ability to specify the architectures on which the >> package is known /not/ to build. This seems useful because in many >> cases the architectures that don't work is precisely what the >> maintainer knows, and wants to document in machine-readable form. I >> don't buy the argument that it creates any additional uncertainty > > Whilst you did this, I think the proper syntax is not clear by your > wording. For example, I take that > Build-Indep-Architecture: !amd64 means "this thing builds > everywhere except amd64". But then, how can I specify "it builds on > all 32-bit architectures except i386", for example? I copied the wording from the Architecture: field. Just as it is not possible to say that an architecture-dependent package is buildable on all 32-bit archs except i386 without listing all those archs, it is not possible to specify that architecture-independent packages are buildable on all 32-bit archs except i386 without listing all those archs. We want Architecture: and Build-Indep-Architecture: to use the same format. I don't think we should try to extend our format at this point because there are already various parsers of Architecture:. > See the following inline comments: > >> +Debian machine architectures. If specified, it should be either >> + +- A unique single word identifying a Debian machine architecture >> as > ^^ >> + described in :ref:`s-arch-spec`. >> + +- An architecture wildcard identifying a set of Debian machine >> + architectures, see :ref:`s-arch-wildcard-spec`. > > This also implies a single word. > > But… > >> +maintainer's control. The specification should entail that the >> +architecture-independent packages are buildable on at least two >> +architectures. > > this is not compatible with the above: both cases say that you have to > provide at most one word, but how can you provide at least two > architectures if you have only one word and can't use a wildcard? It says that you /should/ provide at least two architectures. This is not a /must/ requirement, so it should still be possible to use a unique single word. > And if you can provide multiple words, you need to specify a separator > (whitespace vs comma, I suppose). This is detailed in the architecture wildcard spec. > Also, I dislike the sentence in itself, I believe it should be more > straightforward in conveying its meaning of "pretty please at least > two arch". It has to be that way for cases like this: Build-Indep-architecture: !amd64 That entails that it builds on at least two architectures, but on a common reading of 'specify', it does not specify two archs. -- Sean Whitton signature.asc Description: PGP signature
Bug#636383: debian-policy: 10.2 and others: private libraries may also be multi-arch-ified
Hello, On Sat, Oct 14 2017, Mattia Rizzolo wrote: > Seconded. Thanks. > Triviality: could you please (in the changelog, upgrading checklist, > etc) word this change to mean "allow private libraries to be placed in > a multiarch location" rather than "disallow private libraries to be > places directly under /usr/lib/" which very weirdly seemed to > be what most of the mails in this bug are about? I'm not sure why you find it to be weird. The current language seems to permit putting private libraries in /usr/lib/, which is bad, and this patch also fixes that problem. I'll include both :) -- Sean Whitton signature.asc Description: PGP signature
Bug#846970: Patch to document Build-Indep-Architecture field
On Sat, Oct 14, 2017 at 11:15:10AM -0700, Sean Whitton wrote: > I am seeking seconds for the following patch. Thank you for working on this! > - I've included the ability to specify the architectures on which the > package is known /not/ to build. This seems useful because in many > cases the architectures that don't work is precisely what the > maintainer knows, and wants to document in machine-readable form. I > don't buy the argument that it creates any additional uncertainty Whilst you did this, I think the proper syntax is not clear by your wording. For example, I take that Build-Indep-Architecture: !amd64 means "this thing builds everywhere except amd64". But then, how can I specify "it builds on all 32-bit architectures except i386", for example? See the following inline comments: > +Debian machine architectures. If specified, it should be either > + > +- A unique single word identifying a Debian machine architecture as ^^ > + described in :ref:`s-arch-spec`. > + > +- An architecture wildcard identifying a set of Debian machine > + architectures, see :ref:`s-arch-wildcard-spec`. This also implies a single word. But… > +maintainer's control. The specification should entail that the > +architecture-independent packages are buildable on at least two > +architectures. this is not compatible with the above: both cases say that you have to provide at most one word, but how can you provide at least two architectures if you have only one word and can't use a wildcard? And if you can provide multiple words, you need to specify a separator (whitespace vs comma, I suppose). Also, I dislike the sentence in itself, I believe it should be more straightforward in conveying its meaning of "pretty please at least two arch". -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#636383: debian-policy: 10.2 and others: private libraries may also be multi-arch-ified
On Sat, Oct 14, 2017 at 11:36:55AM -0700, Sean Whitton wrote: > diff --git a/policy.sgml b/policy.sgml > index b8db0ab..d0baa1b 100644 > --- a/policy.sgml > +++ b/policy.sgml > @@ -7697,8 +7697,9 @@ strip --strip-unneeded your-lib > Shared object files (often .so files) that are not > public libraries, that is, they are not meant to be linked > to by third party executables (binaries of other packages), > - should be installed in subdirectories of the > - /usr/lib directory. Such files are exempt from the > + should be installed in subdirectories of the /usr/lib > + or /usr/lib/triplet directories (see > +for a definition). Such files are exempt from the > rules that govern ordinary shared libraries, except that > they must not be installed executable and should be > stripped. Seconded. Triviality: could you please (in the changelog, upgrading checklist, etc) word this change to mean "allow private libraries to be placed in a multiarch location" rather than "disallow private libraries to be places directly under /usr/lib/" which very weirdly seemed to be what most of the mails in this bug are about? -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#683495: Mandating use of /usr/bin/perl in Policy
control: tag -1 +patch Hello, I am seeking seconds for the following patch to close this bug, which I think is uncontroversial at this point. > @@ -185,7 +185,7 @@ All command scripts, including the package maintainer > scripts inside the > package and used by ``dpkg``, should have a ``#!`` line naming the shell > to be used to interpret them. > > -In the case of Perl scripts this should be ``#!/usr/bin/perl``. > +In the case of Perl scripts this must be ``#!/usr/bin/perl``. > > When scripts are installed into a directory in the system PATH, the > script name should not include an extension such as ``.sh`` or ``.pl`` ~ As has been pointed out by Gian, there is a broader issue of whether it is right for Policy to say Perl programs and modules should follow the current Perl policy. or Perl programs and modules must follow the current Perl policy. I think this is actually quite tricky: if packages must follow the Perl policy, does that erase the difference between 'should' and 'must' requirements in the Perl policy? If someone thinks it is a big deal that Policy says only that packages should follow the Perl policy, and is willing to do the work to handle these complexities, they should file a new bug against Policy. Otherwise, let's put that broader issue aside and just fix this confusing inconsistency about shebangs. -- Sean Whitton signature.asc Description: PGP signature
Processed: Mandating use of /usr/bin/perl in Policy
Processing control commands: > tag -1 +patch Bug #683495 [debian-policy] perl scripts: "#!/usr/bin/perl" MUST or SHOULD? Added tag(s) patch. -- 683495: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=683495 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: Re: Bug#636383: debian-policy: 10.2 and others: private libraries may also be multi-arch-ified
Processing control commands: > tag -1 +patch Bug #636383 [debian-policy] debian-policy: 10.2 and others: private libraries may also be multi-arch-ified Added tag(s) patch. -- 636383: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=636383 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#636383: debian-policy: 10.2 and others: private libraries may also be multi-arch-ified
control: tag -1 +patch Hello, On Sun, Dec 04, 2011 at 04:33:56PM +0900, Charles Plessy wrote: > How about the attached patch ? Do you think it is clear enough that > /usr/lib/triplet is not allowed ? Seconded: diff --git a/policy.sgml b/policy.sgml index b8db0ab..d0baa1b 100644 --- a/policy.sgml +++ b/policy.sgml @@ -7697,8 +7697,9 @@ strip --strip-unneeded your-lib Shared object files (often .so files) that are not public libraries, that is, they are not meant to be linked to by third party executables (binaries of other packages), - should be installed in subdirectories of the - /usr/lib directory. Such files are exempt from the + should be installed in subdirectories of the /usr/lib + or /usr/lib/triplet directories (see + for a definition). Such files are exempt from the rules that govern ordinary shared libraries, except that they must not be installed executable and should be stripped. Jonathan, I take it from your reply that you also second this? -- Sean Whitton signature.asc Description: PGP signature
Processed: Re: Bug#864615: please update version of posix standard for scripts (section 10.4)
Processing control commands: > tag -1 +moreinfo Bug #864615 [debian-policy] please update version of posix standard for scripts (section 10.4) Added tag(s) moreinfo. -- 864615: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=864615 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#864615: please update version of posix standard for scripts (section 10.4)
control: tag -1 +moreinfo Hello Ralf, On Sun, Jun 11, 2017 at 06:51:49PM +0200, Ralf Treinen wrote: > section 10.4 says: > > Scripts may assume that /bin/sh implements the SUSv3 Shell Command > Language ... > > This version of the standard is so outdated that it isn't even any > longer available on the opengroup web site. The latest version of the > standard is 4.2 (published in 2016), earlier versions currently > available on the opengroup site are 4 (from 2008) and 4.1 (from 2013). > Please consider updating the policy. I found the 2016 edition of version 4 of the SUS,[1] but what makes you think that is version 4.2? I couldn't find that version number anywhere. If they've changed their versioning scheme, maybe Policy needs to use the expression "SUSv4 (2016 edition)"? On Sun, Jun 25, 2017 at 04:12:42PM +0200, Guillem Jover wrote: > On Sun, 2017-06-11 at 20:46:23 +0200, Bill Allombert wrote: > > Before doing that, we have to check whether all the relevant packages > > are compliant with this update. > > Well, I don't all of our current shell packages are even compliant with > the current version specified in policy. > > dash is one of such packages, with several non-compliancy bugs. And given > that it is our default shell… Concur. If we're not in compliance now, this Policy update does not immediately make packages buggy. And people will be far more motivated to bring their packages into compliance if they're being asked to bring them into compliance with the latest version of the standard. [1] http://pubs.opengroup.org/onlinepubs/9699919799/toc.htm -- Sean Whitton signature.asc Description: PGP signature
Bug#846970: Patch to document Build-Indep-Architecture field
control: tag -1 +patch Hello, I am seeking seconds for the following patch. Comments: - I've made the two architecture requirement a 'should', because I agree that we might otherwise end up with "amd64" being the only value anyone uses for this field. But perhaps it should be a 'recommends' - I've included the ability to specify the architectures on which the package is known /not/ to build. This seems useful because in many cases the architectures that don't work is precisely what the maintainer knows, and wants to document in machine-readable form. I don't buy the argument that it creates any additional uncertainty - Let's stick with th ename Build-Indep-Architecture since it's already in use in the archive. diff --git a/policy/ch-controlfields.rst b/policy/ch-controlfields.rst index 0ee6684..c54a341 100644 --- a/policy/ch-controlfields.rst +++ b/policy/ch-controlfields.rst @@ -121,6 +121,8 @@ package) are: - :ref:`Build-Depends et al ` +- :ref:`Build-Indep-Architecture ` + - :ref:`Standards-Version ` (recommended) - :ref:`Homepage ` @@ -1016,6 +1018,29 @@ This field is automatically added to Debian source control files field may also be used in source package control files (``debian/control``) if needed in other situations. +.. _s-f-Build-Indep-Architecture: + +``Build-Indep-Architecture`` + + +Specification of architectures on which the architecture-independent +binary packages are known to be buildable and/or not buildable. If +this field is not specified, it defaults to ``any``, matching all +Debian machine architectures. If specified, it should be either + +- A unique single word identifying a Debian machine architecture as + described in :ref:`s-arch-spec`. + +- An architecture wildcard identifying a set of Debian machine + architectures, see :ref:`s-arch-wildcard-spec`. + +This header is useful in the rare case where architecture-independent +packages cannot be built on all architectures for reasons outside the +maintainer's control. The specification should entail that the +architecture-independent packages are buildable on at least two +architectures. This provides flexibility to the administrators of +autobuilder infrastructure. + .. _s5.7: User-defined fields -- Sean Whitton signature.asc Description: PGP signature
Processed: Patch to document Build-Indep-Architecture field
Processing control commands: > tag -1 +patch Bug #846970 [debian-policy] debian-policy: Proposal for a Build-Indep-Architecture: control file field Added tag(s) patch. -- 846970: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=846970 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: limit source to debian-policy, tagging 878523
Processing commands for cont...@bugs.debian.org: > limit source debian-policy Limiting to bugs with field 'source' containing at least one of 'debian-policy' Limit currently set to 'source':'debian-policy' > tags 878523 + pending Bug #878523 [debian-policy] debian-policy: [PATCH] Spelling fixes Added tag(s) pending. > thanks Stopping processing here. Please contact me if you need assistance. -- 878523: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=878523 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
