Steve Langasek wrote:
> > Which would be totally pointless until dpkg itself is fixed to give
> > packagers an alternative to ${Source-Version}.
>
Thomas Bushnell BSG wrote:
> I thought we had a fix-strategy in place for addressing these cases.
> I'm sorry if we don't; then of course this strategy doesn't work. :(
I *wrote* one, but then they went and changed the binNMU version numbering.
This *cannot* be done without a consistent numbering scheme for binNMUs which
we can rely on. Given that the numbering scheme was changed silently at a
random time for no apparent reason, I don't know if I can rely on this
numbering scheme being retained.
It appears that nothing prohibits a "b????" suffix in a regular source NMU, or
indeed in a regular maintainer upload, for native packages or non-native
packages, so I believe binNMUs can be automatically detected any more.
There's also no documentation of this numbering scheme: does it differ when
applied to a {native, non-native} package? A {maintainer upload, NMU}?
So actually I can't write a fix, period.
Furthermore (sigh) the developer's reference still advises the old numbering
scheme for binNMUs, so we can expect to see it for manual binNMUs for a good
while yet. So any routine will have to handle *both*.
So the silent and unmotivated changes made to binNMU version numbering have
*prevented* this from being fixed. Good example of how not to do things.
I await advice on how to fix this problem now that we are stuck with this
random, unmotivated, undocumented, likely-to-break-things change. Oh, and
I'd like the head of whoever changed it while I'm at it. :-)
--Nathanael
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
