Bug#872589: dpkg-gencontrol: please allow field "Important: yes"

2017-08-18 Thread Guillem Jover
Hi!

On Fri, 2017-08-18 at 23:09:08 +0200, Adam Borowski wrote:
> Package: dpkg-dev
> Version: 1.18.24
> Severity: wishlist

> Stretch's versions of all apt frontends other than cupt already support
> "Important: yes" packages, thus it'd be reasonable to allow them in Buster.

We are actually not very happy with the name and were already thinking
about using something else. We've also written down our thoughts on
the matter, as there are still some undecided/undesirable semantics:

  

but as we were on the freeze didn't bring it into a wider audience.
We'll be probably doing that in the coming days.

> However, dpkg-gencontrol currently fails to copy the field into a generated
> package.  If I post-process it with a hack like:
> .
> override_dh_gencontrol:
> dh_gencontrol
> sed -e '2i Important: yes' -i debian/${PACKAGE}/DEBIAN/control
> `
> all is ok.

Just for reference, the proper way to tell dpkg-gencontrol how to
export unknown fields into various outputs is to use the export markers
such as SBC as in «XB-Important: yes», as described in deb-src-control(5).

> It is not documented in the Policy, I've filed #872587 asking for their
> opinion.

I don't think it makes sense to file this kind of bug on policy as
long as there's no support in dpkg, nor a clear plan yet on how to
proceed. :)

Thanks,
Guillem



Bug#872589: dpkg-gencontrol: please allow field "Important: yes"

2017-08-18 Thread Adam Borowski
Package: dpkg-dev
Version: 1.18.24
Severity: wishlist

Hi!
Stretch's versions of all apt frontends other than cupt already support
"Important: yes" packages, thus it'd be reasonable to allow them in Buster.

However, dpkg-gencontrol currently fails to copy the field into a generated
package.  If I post-process it with a hack like:
.
override_dh_gencontrol:
dh_gencontrol
sed -e '2i Important: yes' -i debian/${PACKAGE}/DEBIAN/control
`
all is ok.

It is not documented in the Policy, I've filed #872587 asking for their
opinion.


If you'd want to test the behaviour of current frontends yourself, you can
use my test packages:

deb http://angband.pl/debian essimp main
(-src, https), key:
wget -qO- https://angband.pl/deb/archive.html|apt-key add -
"test-essential", "test-important"



Meow!
-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), 
(150, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.13.0-rc5-debug-00121-gc6b5a5fd577f (SMP w/6 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages dpkg-dev depends on:
ii  binutils  2.29-4
ii  bzip2 1.0.6-8.1
ii  libdpkg-perl  1.18.24
ii  make  4.1-9.1
ii  patch 2.7.5-1+b2
ii  perl  5.26.0-5
ii  tar   1.29b-2
ii  xz-utils  5.2.2-1.3

Versions of packages dpkg-dev recommends:
ii  build-essential  12.3
ii  clang-4.0 [c-compiler]   1:4.0.1-1
ii  fakeroot 1.22-1
ii  gcc [c-compiler] 4:7.1.0-2
ii  gcc-7 [c-compiler]   7.1.0-13
ii  gnupg2.1.23-2
ii  gpgv 2.1.23-2
ii  libalgorithm-merge-perl  0.08-3
ii  tcc [c-compiler] 0.9.27~git20161217.cd9514ab-3

Versions of packages dpkg-dev suggests:
ii  debian-keyring  2017.05.28

-- no debconf information