Hi Nicholas, Graham, On 02-07-13 20:33, Nicholas Breen wrote: > Yes, transitioning xbae to openmotif without also transitioning its > dependencies does break things - grace won't even start up in that state. Very good to know, therefore cc'ed to bug 708462. (Oops, somehow I missed xbae, in my testing so far.) > However, I've been testing motif builds of xbae+grace locally, and so far as I > can tell, everything works just fine when the libraries are in sync. That was indeed what I was hoping. > I can even drop a few old patches that were only there to work around > lesstif bugs. Nice. > For my own packages, I was considering this approach: > * xbae: For the libxbae4 binary package, set Breaks on <= current versions of > all reverse dependencies. > * grace: Set a versioned Build-Depends on libxbae-dev (>= 4.60.4-4), which will > be the first motif-enabled upload. I can also do this for xmhtml1-dev. > > I could force an xbae SONAME change, but the list of reverse dependencies is so > small, I think we could probably get by with only the Breaks: - it's a very > short list, requiring changes in only two source packages, grace and paw. > geant321 picks up its dependencies indirectly from paw, and cernlib has no > source or binary dependencies on xbae at all, only lesstif. I don't think the release team would agree, think about local programs build against these libraries. > Preliminary xbae packages (without any Breaks: at the moment) are up at > <http://people.debian.org/~nbreen/xbae/>. Unfortunately, I don't know those > other reverse-depends well enough to test them myself. I believe they're all > linked together anyhow - paw and geant321 are built on top of cernlib - so I > can certainly wait on any xbae uploads until their maintainers settle on a plan > as well. I imagine they'll want to rename the binaries with "lesstif" in the > name! If they set a versioned B-D on libxbae-dev in src:paw, I think that will > cover it. I think it is a good idea to get a strategy agreed. I think we should indeed pull in the maintainers of those packages as well as the RT. And couldn't (and shouldn't) we start testing this in experimental? Paul
Attachment:
signature.asc
Description: OpenPGP digital signature