Bug#876453: [debhelper-devel] Bug#876453: Remove support for upstart jobs from dh_installinit

[Niels Thykier]

Dimitri John Ledkov:
> On 22 September 2017 at 19:24, Michael Biebl  wrote:
>> [...]
>>
>> Niels mentioned on IRC, that in compat 11, debhelper could make it an
>> error to have an upstart file and use the opportunity to remind people
>> to remove the conffile.
>>
>> I like that idea.
>>
> 
> I'm not sure about the timing though. Many people maintain backports
> for their packages, and do backport them "unmodified" sometimes by
> means of backporting debhelper first to keep things building
> unmodified.
> 
> Under such conditions, having upstart support in debhelper makes some
> marginal sense.
> 

Just to clarify: If I understand you correctly, you are happy with the
change itself but would not like it to be a part of a compat level being
released in buster?
  I.e. we are only debating /when/ to apply/enable this change?

I believe it would be a non-issue to postpone it until compat 12.  There
is no other helper/part of debhelper relying on this change that it need
to synchronize with; the only "issue" is that we (Debian) keep the
upstart jobs longer.

> What is the timing of the compat 11? is this something for buster or bullseye?
> 

Compat 11 is targeted for buster.  Postponing compat 11 itself for
bullseye is not really an option as there are several changes in compat
11 that are needed or makes it easier for people to comply with "recent"
policy changes (like the doc change 3.9.7 and DEB_BUILD_OPTIONS="nodoc")

> Btw, are debhelper major version numbers going to synchronise with the
> debian release numbers? = it would be cute.
> 

No.  At times, I need the flexibility of doing != 1 compat levels in a
given Debian release.

Thanks,
~Niels

Bug#876453: [debhelper-devel] Bug#876453: Remove support for upstart jobs from dh_installinit

[Axel Beckert]

Hi,

Michael Biebl wrote:
> Am 24.09.2017 um 00:36 schrieb Dimitri John Ledkov:
> > I'm not sure about the timing though. Many people maintain backports
> > for their packages, and do backport them "unmodified" sometimes by
> > means of backporting debhelper first to keep things building
> > unmodified.

I think so, too.

> Well, maintainers don't have to bump the compat mode if backportability
> is important to them. Do we really have to support this special case?

I don't think that wanting backports should prevent maintainers to
bump the compatibility level.

Please do also not that quite often, even the official backports are
_not_ done the original package maintainers.

Additionally, backports of debhelper are not uncommon, so the urge to
not use newer compat levels because of backports is not really
present.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#876453: Remove support for upstart jobs from dh_installinit

[Michael Biebl]

Am 24.09.2017 um 00:36 schrieb Dimitri John Ledkov:
> On 22 September 2017 at 19:24, Michael Biebl  wrote:
>> Am 22.09.2017 um 14:59 schrieb Michael Biebl:
>>> I see that we already cleaned up dh_installinit wrt to .service and
>>> .tmpfile units in compat level 11 and beyond so it seems like a good
>>> opportunity to do the same for .upstart jobs as an intermediate step
>>> until we can remove upstart support completely from debhelper.
>>>
>>> Attached is a patch doing this first step (deprecating .upstart in newer
>>> compat levels).
>>>
>>> WDYT?
>>
>> Niels mentioned on IRC, that in compat 11, debhelper could make it an
>> error to have an upstart file and use the opportunity to remind people
>> to remove the conffile.
>>
>> I like that idea.
>>
> 
> I'm not sure about the timing though. Many people maintain backports
> for their packages, and do backport them "unmodified" sometimes by
> means of backporting debhelper first to keep things building
> unmodified.

Well, maintainers don't have to bump the compat mode if backportability
is important to them. Do we really have to support this special case?


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#876453: Remove support for upstart jobs from dh_installinit

[Dimitri John Ledkov]

On 22 September 2017 at 19:24, Michael Biebl  wrote:
> Am 22.09.2017 um 14:59 schrieb Michael Biebl:
>> I see that we already cleaned up dh_installinit wrt to .service and
>> .tmpfile units in compat level 11 and beyond so it seems like a good
>> opportunity to do the same for .upstart jobs as an intermediate step
>> until we can remove upstart support completely from debhelper.
>>
>> Attached is a patch doing this first step (deprecating .upstart in newer
>> compat levels).
>>
>> WDYT?
>
> Niels mentioned on IRC, that in compat 11, debhelper could make it an
> error to have an upstart file and use the opportunity to remind people
> to remove the conffile.
>
> I like that idea.
>

I'm not sure about the timing though. Many people maintain backports
for their packages, and do backport them "unmodified" sometimes by
means of backporting debhelper first to keep things building
unmodified.

Under such conditions, having upstart support in debhelper makes some
marginal sense.

What is the timing of the compat 11? is this something for buster or bullseye?

Btw, are debhelper major version numbers going to synchronise with the
debian release numbers? = it would be cute.

-- 
Regards,

Dimitri.

Bug#876453: Remove support for upstart jobs from dh_installinit

[Michael Biebl]

Am 22.09.2017 um 14:59 schrieb Michael Biebl:
> I see that we already cleaned up dh_installinit wrt to .service and
> .tmpfile units in compat level 11 and beyond so it seems like a good
> opportunity to do the same for .upstart jobs as an intermediate step
> until we can remove upstart support completely from debhelper.
> 
> Attached is a patch doing this first step (deprecating .upstart in newer
> compat levels).
> 
> WDYT?

Niels mentioned on IRC, that in compat 11, debhelper could make it an
error to have an upstart file and use the opportunity to remind people
to remove the conffile.

I like that idea.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#876453: Remove support for upstart jobs from dh_installinit

[Michael Biebl]

Am 22.09.2017 um 14:18 schrieb Michael Biebl:
> Package: debhelper
> Version: 10.9
> Severity: normal
> 
> dh_installinit supports the installation of upstart job files.
> I think we should stop doing that, given that upstart is no longer a
> supported init system in Debian.
> 
> I'm a bit uncertain whether we should just rip out the code or keep it
> and make it conditional on the use of the debhelper compat level.
> 
> Since upstart jobs are conffiles, they need to be removed manually on
> upgrades. I guess the best we can do is to document that maintainers
> need to that that themselves (e.g. via a .maintscript file)?


I guess removing upstart support completely can only be done once
https://lintian.debian.org/tags/package-installs-deprecated-upstart-configuration.html
is close to zero.

I see that we already cleaned up dh_installinit wrt to .service and
.tmpfile units in compat level 11 and beyond so it seems like a good
opportunity to do the same for .upstart jobs as an intermediate step
until we can remove upstart support completely from debhelper.

Attached is a patch doing this first step (deprecating .upstart in newer
compat levels).

WDYT?

Michael


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
diff --git a/debhelper.pod b/debhelper.pod
index b03a8bbd..5c0a7e4e 100644
--- a/debhelper.pod
+++ b/debhelper.pod
@@ -595,6 +595,11 @@ B instead.
 
 =item -
 
+B no longer installs F files.  Please make sure to
+remove existing files on upgrades (e.g. by using the B mechanism).
+
+=item -
+
 The B<-s> (B<--same-arch>) option is removed.  Please use B<-a> (B<--arch>) instead.
 
 =item -
diff --git a/dh_installinit b/dh_installinit
index 02282e0d..cbd691cf 100755
--- a/dh_installinit
+++ b/dh_installinit
@@ -50,7 +50,7 @@ build directory.
 =item debian/I.upstart
 
 If this exists, it is installed into etc/init/I.conf in the package
-build directory.
+build directory. Only used in compat levels 10 and below.
 
 =item debian/I.service
 
@@ -255,7 +255,7 @@ foreach my $package (@{$dh{DOPACKAGES}}) {
 		install_file($tmpfile, "$path/$script.conf");
 	}
 
-	my $job=pkgfile($package,"upstart");
+	my $job=pkgfile($package,"upstart") if compat(10);
 	if ($job ne '' && ! $dh{ONLYSCRIPTS}) {
 		install_dir("$tmp/etc/init");
 		install_file($job, "$tmp/etc/init/$jobfile.conf");


signature.asc
Description: OpenPGP digital signature

Bug#876453: Remove support for upstart jobs from dh_installinit

[Michael Biebl]

Package: debhelper
Version: 10.9
Severity: normal

dh_installinit supports the installation of upstart job files.
I think we should stop doing that, given that upstart is no longer a
supported init system in Debian.

I'm a bit uncertain whether we should just rip out the code or keep it
and make it conditional on the use of the debhelper compat level.

Since upstart jobs are conffiles, they need to be removed manually on
upgrades. I guess the best we can do is to document that maintainers
need to that that themselves (e.g. via a .maintscript file)?


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

Kernel: Linux 4.12.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), 
LANGUAGE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages debhelper depends on:
ii  autotools-dev20161112.1
ii  binutils 2.29.1-1
ii  dh-autoreconf14
ii  dh-strip-nondeterminism  0.038-1
ii  dpkg 1.18.24
ii  dpkg-dev 1.18.24
ii  file 1:5.32-1
ii  libdpkg-perl 1.18.24
ii  man-db   2.7.6.1-2
ii  perl 5.26.0-8
ii  po-debconf   1.0.20

debhelper recommends no packages.

Versions of packages debhelper suggests:
ii  dh-make  2.201608

-- no debconf information