Hi Felix,
Felix Lechner wrote:
> On Sun, Sep 19, 2021 at 7:12 AM Axel Beckert <a...@debian.org> wrote:
> > Huh? This should be obvious from the binary package version number.
>
> It isn't. A well-known example is python-defaults [1], which is native
> even though the version number suggests otherwise.
I see. While I was aware that binary and source package numbers can
easily differ, I wasn't aware that the binary versions package can be
arbitrary even in their type.
> The corresponding heuristics were dropped from Lintian two years
> ago. [2]
Oh, wasn't aware of that either.
> In addition, it is not well-publicized that version numbers for
> installation (aka "binary") packages are not necessarily tied to the
> version strings for their sources,
I was aware of that. I just never thought of the fact that this also
means that it is possible that native source packages build non-native
looking binary packages and hence version numbers are error-prone when
trying to distinguish between native and non-native packages.
> But I do not remember an example right now.
The common case I remember and also already used, is to generate
transitional packages formerly built by other source packages which
used to have a higher version. So the trick is to prepend an epoch to
the actual version for just that binary package..
Thanks for the insight and details!
Regards, Axel
--
,''`. | Axel Beckert <a...@debian.org>, 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
