Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Bug#949258: debian-policy: Support negated architecture specifications in debian/control Architecture field
0 views
Skip to first unread message
Samuel Thibault
Jan 18, 2020, 8:00:02 PM1/18/20
to
Package: debian-policy
Version: 4.4.1.2
Severity: normal
Hello,
I didn't find a previous discussion on this: it would be useful to
support negated architecture specifications in the debian/control
Architecture field, so that we can e.g. write:
Architecture: !s390 !s390x
(for xorg stuff)
Architecture: !hppa !hurd-any !kfreebsd-any
(for java stuff)
and even things like
Architecture: linux-any kfreebsd-any !hppa !m68k-any
which would be understood as [ (linux-any or kfreebsd-any) and not hppa
and not m68k-any ]. I.e. if no positive specification is set, an "any"
positive specification is assumed.
That would help to remove quite a few entries of
https://buildd.debian.org/quinn-diff/experimental/Packages-arch-specific
and avoid packages with some java bits to have to hardcode the list of
ports on which java jni bindings packages should be built.
I guess support would be needed in dpkg, lintian, etc.
Samuel
-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), (500, 'proposed-updates'), (500, 'oldstable-proposed-updates-debug'), (500, 'oldstable-proposed-updates'), (500, 'oldoldstable'), (500, 'buildd-unstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.4.0-2-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
debian-policy depends on no packages.
Versions of packages debian-policy recommends:
ii libjs-sphinxdoc 1.8.5-5
Versions of packages debian-policy suggests:
pn doc-base <none>
-- no debconf information
--
Samuel
<i> ben oui ce serait idiot, mais osb
-+- m'en fous de faire un truc débile ! -+-
Version: 4.4.1.2
Severity: normal
Hello,
I didn't find a previous discussion on this: it would be useful to
support negated architecture specifications in the debian/control
Architecture field, so that we can e.g. write:
Architecture: !s390 !s390x
(for xorg stuff)
Architecture: !hppa !hurd-any !kfreebsd-any
(for java stuff)
and even things like
Architecture: linux-any kfreebsd-any !hppa !m68k-any
which would be understood as [ (linux-any or kfreebsd-any) and not hppa
and not m68k-any ]. I.e. if no positive specification is set, an "any"
positive specification is assumed.
That would help to remove quite a few entries of
https://buildd.debian.org/quinn-diff/experimental/Packages-arch-specific
and avoid packages with some java bits to have to hardcode the list of
ports on which java jni bindings packages should be built.
I guess support would be needed in dpkg, lintian, etc.
Samuel
-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), (500, 'proposed-updates'), (500, 'oldstable-proposed-updates-debug'), (500, 'oldstable-proposed-updates'), (500, 'oldoldstable'), (500, 'buildd-unstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.4.0-2-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
debian-policy depends on no packages.
Versions of packages debian-policy recommends:
ii libjs-sphinxdoc 1.8.5-5
Versions of packages debian-policy suggests:
pn doc-base <none>
-- no debconf information
--
Samuel
<i> ben oui ce serait idiot, mais osb
-+- m'en fous de faire un truc débile ! -+-
Russ Allbery
Sep 9, 2023, 6:00:04 PM9/9/23
to
Samuel Thibault <sthi...@debian.org> writes:
> I didn't find a previous discussion on this: it would be useful to
> support negated architecture specifications in the debian/control
> Architecture field, so that we can e.g. write:
> Architecture: !s390 !s390x
> (for xorg stuff)
> Architecture: !hppa !hurd-any !kfreebsd-any
> (for java stuff)
> and even things like
> Architecture: linux-any kfreebsd-any !hppa !m68k-any
> which would be understood as [ (linux-any or kfreebsd-any) and not hppa
> and not m68k-any ]. I.e. if no positive specification is set, an "any"
> positive specification is assumed.
> That would help to remove quite a few entries of
> https://buildd.debian.org/quinn-diff/experimental/Packages-arch-specific
> and avoid packages with some java bits to have to hardcode the list of
> ports on which java jni bindings packages should be built.
> I guess support would be needed in dpkg, lintian, etc.
Hi Samuel,
> I didn't find a previous discussion on this: it would be useful to
> support negated architecture specifications in the debian/control
> Architecture field, so that we can e.g. write:
> Architecture: !s390 !s390x
> (for xorg stuff)
> Architecture: !hppa !hurd-any !kfreebsd-any
> (for java stuff)
> and even things like
> Architecture: linux-any kfreebsd-any !hppa !m68k-any
> which would be understood as [ (linux-any or kfreebsd-any) and not hppa
> and not m68k-any ]. I.e. if no positive specification is set, an "any"
> positive specification is assumed.
> That would help to remove quite a few entries of
> https://buildd.debian.org/quinn-diff/experimental/Packages-arch-specific
> and avoid packages with some java bits to have to hardcode the list of
> ports on which java jni bindings packages should be built.
> I guess support would be needed in dpkg, lintian, etc.
I agree that this would be useful. This has come up frequently over the
years, and back when I was maintaining architecture-specific packages, the
lack of this feature was often annoying.
But (as may be obvious from the long delay in even getting a response),
Policy can't drive the implementation of this change and therefore
probably isn't a good place to start with the request. I think it would
need to start with dpkg and ftp-master (for DAK). I'm therefore probably
going to have to close this bug against Policy as unactionable since I
don't know of any efforts towards implementing this support, and Policy
would only be able to change once the support is available.
If I misunderstood the current state, please do let me know.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Adam Borowski
Sep 10, 2023, 8:30:04 AM9/10/23
to
On Sat, Sep 09, 2023 at 02:53:00PM -0700, Russ Allbery wrote:
> Samuel Thibault <sthi...@debian.org> writes:
> > Architecture: !s390 !s390x
> > Architecture: !hppa !hurd-any !kfreebsd-any
and send a bug/mail to the relevant teams, asking if there are objections
before anyone spends work to implement this.
I for one have currently no less than three related ideas:
* this
* richer arch aliases (better than current dpkg aliases; could be
implemented like shell foo-$@-bar word multiplication, thus linux-64bit
would expand to linux-amd64 linux-arm64 linux-s390x ...); idea was kind
of shot before though
* replacing explicit arch names in source packages by facets (like:
x86, little-endian, sse2, time64, ...) that are expanded at build time;
procrastiplanning to propose this
It's good to discuss such things -- if someone offers to implement such a
change.
> going to have to close this bug against Policy as unactionable since I
> don't know of any efforts towards implementing this support, and Policy
> would only be able to change once the support is available.
Could we oh so please have this as a policy policy in other cases, too?
Meow!
--
⢀⣴⠾⠻⢶⣦⠀ Elemental clouds:
⣾⠁⢠⠒⠀⣿⡁ • earth: cumulogranite (aviation)
⢿⡄⠘⠷⠚⠋⠀ • fire: pyrocumulus (forestry, volcanism)
⠈⠳⣄⠀⠀⠀⠀ No known relations of clouds to air or water.
> Samuel Thibault <sthi...@debian.org> writes:
> > Architecture: !s390 !s390x
> > Architecture: !hppa !hurd-any !kfreebsd-any
> > Architecture: linux-any kfreebsd-any !hppa !m68k-any
> > which would be understood as [ (linux-any or kfreebsd-any) and not hppa
> > and not m68k-any ]. I.e. if no positive specification is set, an "any"
> > positive specification is assumed.
> > which would be understood as [ (linux-any or kfreebsd-any) and not hppa
> > and not m68k-any ]. I.e. if no positive specification is set, an "any"
> > positive specification is assumed.
> > I guess support would be needed in dpkg, lintian, etc.
> I agree that this would be useful. This has come up frequently over the
> years, and back when I was maintaining architecture-specific packages, the
> lack of this feature was often annoying.
>
> But (as may be obvious from the long delay in even getting a response),
> Policy can't drive the implementation of this change and therefore
> probably isn't a good place to start with the request. I think it would
> need to start with dpkg and ftp-master (for DAK). I'm therefore probably
> going to have to close this bug against Policy as unactionable since I
> don't know of any efforts towards implementing this support, and Policy
> would only be able to change once the support is available.
Agreed, but it might be good to say "it would be good to have this",
> years, and back when I was maintaining architecture-specific packages, the
> lack of this feature was often annoying.
>
> But (as may be obvious from the long delay in even getting a response),
> Policy can't drive the implementation of this change and therefore
> probably isn't a good place to start with the request. I think it would
> need to start with dpkg and ftp-master (for DAK). I'm therefore probably
> going to have to close this bug against Policy as unactionable since I
> don't know of any efforts towards implementing this support, and Policy
> would only be able to change once the support is available.
and send a bug/mail to the relevant teams, asking if there are objections
before anyone spends work to implement this.
I for one have currently no less than three related ideas:
* this
* richer arch aliases (better than current dpkg aliases; could be
implemented like shell foo-$@-bar word multiplication, thus linux-64bit
would expand to linux-amd64 linux-arm64 linux-s390x ...); idea was kind
of shot before though
* replacing explicit arch names in source packages by facets (like:
x86, little-endian, sse2, time64, ...) that are expanded at build time;
procrastiplanning to propose this
It's good to discuss such things -- if someone offers to implement such a
change.
> going to have to close this bug against Policy as unactionable since I
> don't know of any efforts towards implementing this support, and Policy
> would only be able to change once the support is available.
Meow!
--
⢀⣴⠾⠻⢶⣦⠀ Elemental clouds:
⣾⠁⢠⠒⠀⣿⡁ • earth: cumulogranite (aviation)
⢿⡄⠘⠷⠚⠋⠀ • fire: pyrocumulus (forestry, volcanism)
⠈⠳⣄⠀⠀⠀⠀ No known relations of clouds to air or water.
Russ Allbery
Sep 10, 2023, 11:30:03 AM9/10/23
to
Adam Borowski <kilo...@angband.pl> writes:
> Agreed, but it might be good to say "it would be good to have this", and
> send a bug/mail to the relevant teams, asking if there are objections
> before anyone spends work to implement this.
> I for one have currently no less than three related ideas:
> * this
> * richer arch aliases (better than current dpkg aliases; could be
> implemented like shell foo-$@-bar word multiplication, thus linux-64bit
> would expand to linux-amd64 linux-arm64 linux-s390x ...); idea was kind
> of shot before though
> * replacing explicit arch names in source packages by facets (like:
> x86, little-endian, sse2, time64, ...) that are expanded at build time;
> procrastiplanning to propose this
> It's good to discuss such things -- if someone offers to implement such a
> change.
Yes, I agree.
> Agreed, but it might be good to say "it would be good to have this", and
> send a bug/mail to the relevant teams, asking if there are objections
> before anyone spends work to implement this.
> I for one have currently no less than three related ideas:
> * this
> * richer arch aliases (better than current dpkg aliases; could be
> implemented like shell foo-$@-bar word multiplication, thus linux-64bit
> would expand to linux-amd64 linux-arm64 linux-s390x ...); idea was kind
> of shot before though
> * replacing explicit arch names in source packages by facets (like:
> x86, little-endian, sse2, time64, ...) that are expanded at build time;
> procrastiplanning to propose this
> It's good to discuss such things -- if someone offers to implement such a
> change.
>> going to have to close this bug against Policy as unactionable since I
>> don't know of any efforts towards implementing this support, and Policy
>> would only be able to change once the support is available.
> Could we oh so please have this as a policy policy in other cases, too?
real problems even if no apparent forward progress is being made on that
bug, but I'm starting to think this is too conservative and keeping really
old stalled bugs open is often not useful. However, there are a lot of
bugs and I don't touch them very frequently, since I'm trying to focus on
closing bugs that do have forward progress.
If you or anyone else has a list of bugs that you think fall into that
category (no known efforts towards an implementation, Policy can't change
until that implementation happens), please do send a list. (Feel free to
send that privately if you think it might be controversial.) I'm happy to
take a look.
Edward Little
Sep 10, 2023, 9:20:05 PM9/10/23
to
Please remove the following email address: e.lit...@gmail.com
0 new messages