Hi RT, On 06-05-13 23:01, Paul Gevers wrote: > So my question basically is, what would be the most appropriate order to > do things? > > My proposal would be (with your approval) to just get motif into > unstable/main and start converting the dependencies with the help of > their maintainers (the libraries can coexist). Because the -dev package > name has to change all build dependencies would have to get a > source-full update. I would have liked to stage everything in > experimental, but due to this (quoted from ftp-master) nasty dak bug, > that would leave unstable (non-free) without (open-)motif. Having thought about this again today, how about the following proposal: - Upload the latest packaging of motif to non-free to get the new packaging and rename of the source past the NEW queue. - Ask and help the current maintainers of reverse dependencies to try out building their packages in experimental with libmotif-dev in non-free. Yes, the policy does not allow this, but as ftp-master agrees that we move the package to main, I expect this could be acceptable, if at all possible. - When all packages are lined up, remove motif from non-free into main and start the transition in unstable. Do you think this works and do you find this acceptable? An alternative that I could come up with, but maybe it is an insane idea, is that I update the lesstif2 package to make the lesstif2-dev package a transitional package that depends on libmotif-dev. I believe only the packages that need the additional build dependencies (e-mail from Graham) would not be helped by this temporary solution, but that can be fixed in advance. So than we could upload motif and lesstif2 to unstable after your approval and start converting the packages to properly build-depend on libmotif-dev. Do you prefer that I file a proper transition bug for this issue now? Please advice on what you find acceptable. I propose that we start to inform the reverse dependent package maintainers about our intent to replace lesstif2 with motif when we have agreed on the proposed attack path from your point of view. Paul
Attachment:
signature.asc
Description: OpenPGP digital signature