Guillem Jover writes ("Re: Bug#1123630: Please reconsider new
Version->is_native warning"):
> Because I expect this to continue to be contentious, and I don't have
> the energy for it (besides writing this reply), I've added new methods
> with better and more neutral names to introspect on the properties of
> the version, called has_epoch() and has_revision(). Users can then
> use/misuse them to handle source packages if they wish to…
Could we please have a much longer transition plan for this, or
(better) a way of suppressing the warning that is compatible with
older libdpkg-perl? An obvious possibility would be for libdpkg-perl
to check `$main::libdpkg_perl_version_suppress_is_native_warning`.
Consider, for example, devscripts. We could change devscripts to use
the new method names in forky. But if we do that, then backporting
devscripts will involve reverting that change.
Packaging tools are the ones likely to use this method and they are
often backported. It would be much better not to ask every such tool
to maintain two versions of its code. We want to be keep backporting
devscripts etc. as easy as possible. [1]
Thanks,
Ian.
[1] In src:dpkg we try to make the same .debs installable and useable
back as far as we can.
Frankly, we are not likely to write some kind of autodetection code
that determines what the method is called in libdpkg-perl. Rather,
we'll reimplement this function with !~ m/-/.
That's very easy for us. It might be a good idea in devscripts too.
The only reason I'm having this conversation with you is for the
benefit of everyone else, and because I think you don't actually want
to make open-coding pieces of libdpkg-perl people's best option.
--
Ian Jackson <[email protected]> These opinions are my own.
Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.
