On 2018-07-31 22:15, kuLa wrote:
> Hi Andreas,
>
> Thx for this report, I'm not sure how it have happened that piuparts didn't
> report any issues when I was testing it locally, but it doesn't really
> matter right now.
It's some script looking for possible file collisions and feeding the
candidate package combinations to piuparts.
It triggered because it found both libpqxx6 (6.2.4-2) and libpqxx-6.2
(6.2.4-3) in sid, sharing a file.
> In regards to what you suggest for Breaks+Replaces, do you mean this:
>
> Replaces: libpqxx6 (>= 6.2)
> Breaks: libpqxx6 (>= 6.2)
That is what I meant.
(Usually you would use (<< 6.2.4-3) if you moved some files, but here
you uploaded two buggy package versions (-1 (wrong library name) and -2
(wrong package name)) while the older versions are OK and
co-installable; and the old package name "disappears" in -3.)
> To be honest I'm not sure if this is what we need as libpqxx-6.2.so has been
> introduced in 6.2.4-2 and 6.2.4-3 is broken for upgrade. If I'll upload
> 6.2.4-4
> then I'd expect to replace all earlier versions of 6.2,
What do you plan to change for -4?
The renaming of the package to libpqxx-6.2 sounds like the correct
solution to me. You cannot have a libpqxx6 package not shipping
libpqxx-6.1.so . This just needs to be handled as a proper library
transition (you already filed the corresponding bug).
> so I'd expect B+R as
> below:
In which package?
> Replaces: libpqxx-6.2 (<< ${binary:Version})
> Breaks: libpqxx-6.2 (<< ${binary:Version})
>
> But I have to say that I'm not 100% sure about it, so if you could shade a bit
> more light on what you think it'd be great.
This sounds seriously wrong. (Unless you have a very special package, or
a very big strange mess to be cleaned up.)
Why would you want to B+R the newly introduced package?
Why would you want to bump the B+R every time you upload a new version?
You need Depends: foo (= ${binary:Version}) to keep something in sync
but for B+R there is usually a first "good" version that no longer needs
to be replaced, so no substvar needed.
(The exception would be a package frequently getting new upstream
releases in stable with diverging packaging in stable and sid, where
every upload to stable would invalidate the first "good" version in sid.
cf. chromium)
Andreas
