[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

binNMU version detection

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.  :-)


Reply to: