[csw-maintainers] Review of updated libotr2

Maciej (Matchek) Bliziński maciej at opencsw.org
Sat May 4 12:20:09 CEST 2013


2013/5/4 Laurent Blume <laurent at opencsw.org>:
> On 2013-05-04 11:17 AM, Maciej (Matchek) Bliziński wrote:
>> A nit: in the intermediate step, would CSWpidginotr be 3.2.1 rather than 3.2.0?
>
> No, I intend to do it quickly, so without bothering to push 3.2.1. Does
> that matter? I guess I could do it if it does.

No, it doesn't matter, I just thought it was built from the same source tarball.

>> I like your plan: first splitting the package without changing the
>> version (too much) and making space for new sonames, then updating the
>> version and building the new soname.
>>
>> Ideally, in the target state you'd also break the dependency between
>> CSWotr and CSWlibotr2; current reverse dependencies of CSWotr are
>> small: it's just mcabber. So if you rebuilt mcabber too, you could
>> make CSWotr not depend on CSWlibotr2 and drop CSWlibotr2 entirely.
>
> Well, there will be a dependency: CSWotr depends on CSWlibotr5 which
> depends on CSWlibotr2 (followed the flac libs there).
> So that's the one that would be ultimately removed when all other
> dependencies are rebuilt against CSWlibotr5. There should be no
> dependency at all on CSWotr in the end (AFAICT, there is no reason to).

Not sure why CSWlibotr5 would depend on CSWlibotr2. What role do flac
libraries play in there?

>> Also, CSWotrdevel could go away in the target state. I think we can be
>> a bit more aggressive with development package renames and deletions.
>
> Okay, how to make sure that it'll go away when somebody runs pkgutil
> --cleanup?

OBSOLETED_BY is the only currently existing directive that does it.
Maybe we could add a new one, or (ab)use OBSOLETED_BY?

Maciej


More information about the maintainers mailing list