On Sun, Sep 22, 2013 at 12:51:52PM +0100, Julian Gilbey wrote: > On Sun, Sep 22, 2013 at 08:42:47PM +0930, Ron wrote: > > On Sun, Sep 22, 2013 at 12:45:12AM +0100, Julian Gilbey wrote: > > > > > > Ron - would you have any objections to this? > > > > Yes, I do, for the same reason I've already said in this bug report. > > > > Nobody talked to me about whether this package was ready for a m-a > > transition before creating this mess - or I'd have told them the same > > thing. Please wait until we have a stable release out. > > > > Right now, it's more important that developers be able to backport > > updates to it trivially, than for people to be able to run non-free > > stuff in sid. > > > > If you want stable m-a, use stable. Or use a chroot. > > > > > > This will be fixed once we have a formal stable release version out. > > > > Ron > > Hi Ron! > > As you will see from reading the bug report log: > > (i) it affects *lots* of people using testing/unstable
There are lots of m-a problems that affect people using testing/unstable. This is unfortunate, but the basic wisdom so far is if you don't want m-a trouble, stick to stable. That's just reality on the ground for its current implementation. > (ii) the fix is almost entirely trivial, and orthogonal to any changes > in the opus package itself - it only affects the package build by > specifying that the libraries should be installed in locations > conforming to the multiarch specification, and it does this by > modifying only four files in the debian/ directory - it does not touch > anything outside of there Yes, as I mentioned already, I know exactly what the patch does and even before there was a patch, what needs to be done :) > (iii) the fix should work fine in stable and backports as well - > stable already had support for multiarch But squeeze does not, and that's still a supported release. And lots of people have contacted me about the backports they are doing for it for things they are shipping. > (iv) a significant number of people have used the patch with success > > Please do reconsider applying this patch to the current not-yet-stable > release of opus! It will also indicate if there are as-yet unforeseen > problems afoot which would otherwise bite if it were applied to the > as-yet-to-be-released stable version. As you said, it's orthogonal, so there's no reason to believe there will be any problems on this front - and even if there are, there's plenty of life left in sid before the next freeze to deal with those. If you want to put a patched version in experimental, or in a private archive somewhere, that's fine. But I really want to keep the version in testing/unstable trivially backportable until we're less worried about important updates not getting pulled by other developers because we made it harder for _them_. I mean really, people who can't figure out how to fix this for themselves really shouldn't be using m-a on sid, or sid, at all. People who think sending hundreds of insistent me-toos about transition issues in a development release is the way to fix things ought to have a good think about what this word 'unstable' means and how software development works. People who say "Why wasn't this fixed during the wheezy freeze!!!" in a confused frenzy doubly so ... I'm sorry this is painful. I understand that. But I didn't cause the pain, and I don't think that transferring it to real software developers in favour of people with unrealistic expectations is a very good plan. People who can't fix transition issues in sid for themselves just shouldn't be using it. This is why we make stable releases :) The important thing here is to minimise the work for the people actually doing work. The people who expect others to do it for them will just have to be patient, or smarter about what release they use, or both. If people want to hurry this up, simple nagging is not the way to do it. Get involved upstream, help with testing, help with getting the next release ready to release. That's how open software development works. Ron -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
