Bug#933128: libparse-debianchangelog-perl: Unsuitable for Bullseye unless someone becomes upstream
Hi, Axel Beckert (2020-06-07): > Since Guillem cleared up this and even provided a patch for aptitude > (which is applied and in testing for a week or two), I changed my > opinion on this topic completely. > >> If another team member +1's the package removal, I'll happily proceed. > > Seconded. :-) Thanks! ROM bug filed: #962521
Bug#933128: libparse-debianchangelog-perl: Unsuitable for Bullseye unless someone becomes upstream
Hi, intrigeri wrote: > I did not dare proposing this course of action so far because the > notes from our BoF at DebConf19 are a bit ambiguous about whether we > decided to remove the package from sid, in addition to removing it > from testing. I wasn't at the BoF, but was opposing rather strongly afterwards since I was not aware that libdpkg-dev is partially a fork and provides the same functionality. (And I didn't want to loose the changelog parsing functionality in aptitude.) Since Guillem cleared up this and even provided a patch for aptitude (which is applied and in testing for a week or two), I changed my opinion on this topic completely. > If another team member +1's the package removal, I'll happily proceed. Seconded. :-) 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 signature.asc Description: PGP signature
Bug#933128: libparse-debianchangelog-perl: Unsuitable for Bullseye unless someone becomes upstream
Hi, gregor herrmann (2020-05-22): > On Fri, 22 May 2020 09:58:12 +0200, intrigeri wrote: > >> So, once aptitude >= 0.8.13-1 has migrated to testing, we'll need to >> ask (presumably the release team) for libparse-debianchangelog-perl to >> lose its "key package" status, so the autoremoval machinery can remove >> it from testing due to this very RC bug. > > Unless we go directly for an RM;RoM bug, then it will be removed from > testing when it's gone from unstable. Indeed. This would be my preferred option: it's simpler for everyone involved, it communicates the maintenance status more clearly, and it avoids confusion that could lead to new reverse-dependencies to be uploaded. I did not dare proposing this course of action so far because the notes from our BoF at DebConf19 are a bit ambiguous about whether we decided to remove the package from sid, in addition to removing it from testing. If another team member +1's the package removal, I'll happily proceed. Cheers!
Bug#933128: libparse-debianchangelog-perl: Unsuitable for Bullseye unless someone becomes upstream
On Fri, 22 May 2020 09:58:12 +0200, intrigeri wrote: > So, once aptitude >= 0.8.13-1 has migrated to testing, we'll need to > ask (presumably the release team) for libparse-debianchangelog-perl to > lose its "key package" status, so the autoremoval machinery can remove > it from testing due to this very RC bug. Unless we go directly for an RM;RoM bug, then it will be removed from testing when it's gone from unstable. Cheers, gregor -- .''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06 `. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe `- signature.asc Description: Digital Signature
Bug#933128: libparse-debianchangelog-perl: Unsuitable for Bullseye unless someone becomes upstream
Hi,
intrig...@debian.org (2019-07-26):
> Therefore, at the pkg-perl BoF today at DebConf, after pondering other
> options such as orphaning this package, we decided that we don't want
> this package to be included in Bullseye (at least, maintained under
> the Perl team umbrella) unless someone else steps up and becomes its
> upstream maintainer. [...]
> libparse-debianchangelog-perl has quite a few reverse-dependencies, [...]
10 months later, we've reached the point when there's 1 single
reverse dependency left in sid: customdeb, whose maintainer promptly
agreed it can be removed at the same time as libparse-debianchangelog-perl.
All other previous reverse dependencies were ported to something else
(most often libdpkg-perl) and nobody volunteered to adopt it upstream.
Thanks a lot to everyone who participated in making this happen :)
In testing there's another reverse-dependency: aptitude, which has
been ported away from libparse-debianchangelog-perl in 0.8.13-1.
So, once aptitude >= 0.8.13-1 has migrated to testing, I think it'll
be time to ensure libparse-debianchangelog-perl itself is removed from
testing, which was the goal of the whole operation.
But:
> Note that libparse-debianchangelog-perl is on the list of key
> packages¹ so this RC bug won't trigger the autoremoval machinery for
> it, nor for any of its reverse dependencies.
>
> [1] https://udd.debian.org/cgi-bin/key_packages.yaml.cgi
libparse-debianchangelog-perl is on the list of key packages because
it's installed on many machines ("popcon"). This will prevent the
autoremoval machinery from removing it from testing.
So, once aptitude >= 0.8.13-1 has migrated to testing, we'll need to
ask (presumably the release team) for libparse-debianchangelog-perl to
lose its "key package" status, so the autoremoval machinery can remove
it from testing due to this very RC bug.
Cheers!
Bug#933128: libparse-debianchangelog-perl: Unsuitable for Bullseye unless someone becomes upstream
Hi!, Guillem Jover: > Ah! Thanks for the info. How about the following clarification then? :) Perfect! That's exactly what I would have needed :) Cheers, -- intrigeri
Bug#933128: libparse-debianchangelog-perl: Unsuitable for Bullseye unless someone becomes upstream
Hi!
On Sat, 2019-11-02 at 16:31:24 +0100, intrigeri wrote:
> Guillem Jover:
> > On Sat, 2019-07-27 at 12:20:00 -0300, intrigeri wrote:
> >> Oh, this is very interesting, thanks! I had taken a look at that
> >> module, but from the documentation I understood it only gives us "the
> >> number of changelog entries that have been parsed with success", so
> >> I had discarded this option.
>
> > If the documantion was not clear, I'd be happy to try to improve it so
> > that other people do not get this impression too. Could you cover a bit
> > what lead you to that conclusion?
>
> Back then I had read only `perldoc Dpkg::Changelog::Debian`, which
> documents one method:
>
> $c->parse($fh, $description)
> Read the filehandle and parse a Debian changelog in it. The data in
> the object is reset before parsing new data.
>
> Returns the number of changelog entries that have been parsed with
> success.
>
> I understood only later that "See also: Dpkg::Changelog" was not
> optional :)
Ah! Thanks for the info. How about the following clarification then? :)
Regards,
Guillem
diff --git i/scripts/Dpkg/Changelog/Debian.pm w/scripts/Dpkg/Changelog/Debian.pm
index 937acb5e0..a85f3af12 100644
--- i/scripts/Dpkg/Changelog/Debian.pm
+++ w/scripts/Dpkg/Changelog/Debian.pm
@@ -24,6 +24,12 @@ Dpkg::Changelog::Debian - parse Debian changelogs
=head1 DESCRIPTION
+This class represents a Debian changelog file as an array of changelog
+entries (Dpkg::Changelog::Entry::Debian).
+It implements the generic interface Dpkg::Changelog.
+Only methods specific to this implementation are described below,
+the rest are inherited.
+
Dpkg::Changelog::Debian parses Debian changelogs as described in
deb-changelog(5).
@@ -118,10 +124,11 @@ my $ancient_delimiter_re = qr{
=over 4
-=item $c->parse($fh, $description)
+=item $count = $c->parse($fh, $description)
-Read the filehandle and parse a Debian changelog in it. The data in the
-object is reset before parsing new data.
+Read the filehandle and parse a Debian changelog in it, to store the entries
+as an array of Dpkg::Changelog::Entry::Debian objects.
+Any previous entries in the object are reset before parsing new data.
Returns the number of changelog entries that have been parsed with success.
diff --git i/scripts/Dpkg/Changelog/Entry.pm w/scripts/Dpkg/Changelog/Entry.pm
index 144dacb0f..d6ce55601 100644
--- i/scripts/Dpkg/Changelog/Entry.pm
+++ w/scripts/Dpkg/Changelog/Entry.pm
@@ -39,7 +39,7 @@ Dpkg::Changelog::Entry - represents a changelog entry
=head1 DESCRIPTION
-This object represents a changelog entry. It is composed
+This class represents a changelog entry. It is composed
of a set of lines with specific purpose: an header line, changes lines, a
trailer line. Blank lines can be between those kind of lines.
diff --git i/scripts/Dpkg/Changelog/Entry/Debian.pm w/scripts/Dpkg/Changelog/Entry/Debian.pm
index defa3b0b6..04bf8ef04 100644
--- i/scripts/Dpkg/Changelog/Entry/Debian.pm
+++ w/scripts/Dpkg/Changelog/Entry/Debian.pm
@@ -47,9 +47,10 @@ Dpkg::Changelog::Entry::Debian - represents a Debian changelog entry
=head1 DESCRIPTION
-This object represents a Debian changelog entry. It implements the
-generic interface Dpkg::Changelog::Entry. Only functions specific to this
-implementation are described below.
+This class represents a Debian changelog entry.
+It implements the generic interface Dpkg::Changelog::Entry.
+Only functions specific to this implementation are described below,
+the rest are inherited.
=cut
diff --git i/scripts/Dpkg/Control/Changelog.pm w/scripts/Dpkg/Control/Changelog.pm
index 1f65127c4..9184cedbc 100644
--- i/scripts/Dpkg/Control/Changelog.pm
+++ w/scripts/Dpkg/Control/Changelog.pm
@@ -32,7 +32,7 @@ Dpkg::Control::Changelog - represent info fields output by dpkg-parsechangelog
=head1 DESCRIPTION
-This object derives directly from Dpkg::Control with the type
+This class derives directly from Dpkg::Control with the type
CTRL_CHANGELOG.
=head1 METHODS
Bug#933128: libparse-debianchangelog-perl: Unsuitable for Bullseye unless someone becomes upstream
Hi, Guillem Jover: > On Sat, 2019-07-27 at 12:20:00 -0300, intrigeri wrote: >> gregor herrmann: >> > In dpt-new-upstream we're using Dpkg::Changelog::Debian from >> > libdpkg-perl, which might help here as well. >> Oh, this is very interesting, thanks! I had taken a look at that >> module, but from the documentation I understood it only gives us "the >> number of changelog entries that have been parsed with success", so >> I had discarded this option. > If the documantion was not clear, I'd be happy to try to improve it so > that other people do not get this impression too. Could you cover a bit > what lead you to that conclusion? Back then I had read only `perldoc Dpkg::Changelog::Debian`, which documents one method: $c->parse($fh, $description) Read the filehandle and parse a Debian changelog in it. The data in the object is reset before parsing new data. Returns the number of changelog entries that have been parsed with success. I understood only later that "See also: Dpkg::Changelog" was not optional :) Cheers, -- intrigeri
Bug#933128: libparse-debianchangelog-perl: Unsuitable for Bullseye unless someone becomes upstream
Hi!
On Sat, 2019-07-27 at 12:20:00 -0300, intrigeri wrote:
> gregor herrmann:
> > In dpt-new-upstream we're using Dpkg::Changelog::Debian from
> > libdpkg-perl, which might help here as well.
> Oh, this is very interesting, thanks! I had taken a look at that
> module, but from the documentation I understood it only gives us "the
> number of changelog entries that have been parsed with success", so
> I had discarded this option.
If the documantion was not clear, I'd be happy to try to improve it so
that other people do not get this impression too. Could you cover a bit
what lead you to that conclusion?
> I'm very glad I was mislead. It looks like Dpkg::Changelog{,::*} are
> sufficient for many, if not most, use cases of Parse::DebianChangelog :)
> We might have to check what API is public and supported, and improve
> the documentation accordingly: for example, the "load" method that
> our new-upstream script uses does not seem to be documented anywhere.
Right (see my other mail), given that it's a direct successor, it
should cover almost everything, except for example the output formats
that got axed.
Hmm about the load() method, it seems I removed that because this
class does not implement the parse() method which load() requires,
when trying to clarify and document all the inherited methods in
commit 853f59ec0468f72fa29811a8fe48fad91fab6083. Thanks, will fix! :)
BTW, currently the preferred way to parse a changelog file is IMO to
use Dpkg::Changelog::Parse, as that will make sure to handle possible
custom formatters. I'm not entirely happy with this interface, because
it seems obviously less discoverable than just creating a new
Dpkg::Changelog (or Dpkg::Changelog::Debian), but merging it into the
base class' new() does not seem right either, but maybe as another
constructor method… :)
Thanks,
Guillem
Bug#933128: libparse-debianchangelog-perl: Unsuitable for Bullseye unless someone becomes upstream
Hi again,
intrigeri:
> I'm very glad I was mislead. It looks like Dpkg::Changelog{,::*} are
> sufficient for many, if not most, use cases of Parse::DebianChangelog :)
Hoping it will help other affected folks go through this transition,
here are MRs that give examples about how some code can be ported to
Dpkg::Changelog:
https://salsa.debian.org/perl-team/modules/packages/dh-make-perl/merge_requests/1
https://salsa.debian.org/perl-team/modules/packages/pkg-perl-tools/merge_requests/4
Cheers,
--
intrigeri
Bug#933128: libparse-debianchangelog-perl: Unsuitable for Bullseye unless someone becomes upstream
gregor herrmann:
> In dpt-new-upstream we're using Dpkg::Changelog::Debian from
> libdpkg-perl, which might help here as well.
Oh, this is very interesting, thanks! I had taken a look at that
module, but from the documentation I understood it only gives us "the
number of changelog entries that have been parsed with success", so
I had discarded this option.
I'm very glad I was mislead. It looks like Dpkg::Changelog{,::*} are
sufficient for many, if not most, use cases of Parse::DebianChangelog :)
We might have to check what API is public and supported, and improve
the documentation accordingly: for example, the "load" method that
our new-upstream script uses does not seem to be documented anywhere.
Cheers,
--
intrigeri
Bug#933128: libparse-debianchangelog-perl: Unsuitable for Bullseye unless someone becomes upstream
On Fri, 26 Jul 2019 18:28:38 -0300, intrigeri wrote: > dh-make-perl uses this module for three things: > > - t/debian-version.t: extracting the latest version of >a changelog file > > - copyright_from_changelog: > > - extract maintainer and date for each changelog entry > > - extract content of the changelog entry, AFAICT only in order to > detect email address changes → seems non-critical to me > but nice to have (and I bet Lintian needs that too anyway) In dpt-new-upstream we're using Dpkg::Changelog::Debian from libdpkg-perl, which might help here as well. Cheers, gregor -- .''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06 `. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe `- signature.asc Description: Digital Signature
Bug#933128: libparse-debianchangelog-perl: Unsuitable for Bullseye unless someone becomes upstream
intrigeri: > https://udd.debian.org/cgi-bin/bts-usertags.cgi?tag=libparse-debian-changelog-removal=debian-perl%40lists.debian.org Scratch that (typo), it is actually: https://udd.debian.org/cgi-bin/bts-usertags.cgi?tag=libparse-debian-changelog-perl-removal=debian-perl%40lists.debian.org
Bug#933128: libparse-debianchangelog-perl: Unsuitable for Bullseye unless someone becomes upstream
> - Users of Parse::DebianChangelog could list their minimal >requirements for a new implementation. If more folks want to play this game, we should probably move this to a wiki page, but for the sake of getting things moving simply, here we go: dh-make-perl uses this module for three things: - t/debian-version.t: extracting the latest version of a changelog file - copyright_from_changelog: - extract maintainer and date for each changelog entry - extract content of the changelog entry, AFAICT only in order to detect email address changes → seems non-critical to me but nice to have (and I bet Lintian needs that too anyway) pkg-perl-tools uses this module only in scripts/missing-upstream (aka. "dpt missing-upstream"), for extracting, from each changelog entry, the name and version of the source package. AFAICT, all this could be reimplemented using dpkg-parsechangelog(1), either in Parse::DebianChangelog itself or in a brand new module. Cheers, -- intrigeri
Bug#933128: libparse-debianchangelog-perl: Unsuitable for Bullseye unless someone becomes upstream
Package: libparse-debianchangelog-perl Version: 1.2.0-13 Severity: serious Hi, many years ago, the Debian Perl group has unwillingly inherited the role of de facto upstream maintainer for this package: all changes done since 2011 were applied as Debian patches. We don't feel we're in a good position to wear the upstream hat here and would rather not to. Therefore, at the pkg-perl BoF today at DebConf, after pondering other options such as orphaning this package, we decided that we don't want this package to be included in Bullseye (at least, maintained under the Perl team umbrella) unless someone else steps up and becomes its upstream maintainer. Hence, we're filing this RC bug to alert about this situation. I'll also file bugs against all reverse-dependencies, pointing to this discussion. libparse-debianchangelog-perl has quite a few reverse-dependencies, some of them critical to Debian (such as Lintian) or to our own team (dh-make-perl, pkg-perl-tools) so let's hope that something good comes out of this currently unsustainable situation. For example: - Users of Parse::DebianChangelog could list their minimal requirements for a new implementation. This could be useful in case someone is ready to write and maintain something like this, but does not want to maintain the current codebase and its full API. - Someone takes over Parse::DebianChangelog and becomes the new upstream. - Note that libparse-debianchangelog-perl is on the list of key packages¹ so this RC bug won't trigger the autoremoval machinery for it, nor for any of its reverse dependencies. [1] https://udd.debian.org/cgi-bin/key_packages.yaml.cgi Cheers, -- intrigeri
