2013/5/4 Laurent Blume <[email protected]>: > 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 _______________________________________________ maintainers mailing list [email protected] https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
