Hi Alec, On Tue, May 24, 2016 at 11:29:38AM +0200, Alec Leamas wrote: > I am the upstream maintainer of the lirc [1] package which is part of > universe. Also, I am more or less new to the Ubuntu developing community.
Welcome, and thank you for looking out for the lirc packaging in Ubuntu! > My interest is to update lirc to a more recent version. As of today, lirc > has released 0.9.4. Ubuntu is still on 0.9.0, from 2011, and this is > becoming a problem upstream since we cannot really support the users of this > very old version. Also, recent kernel changes will break lirc 0.9.0 in some > usecases. > > Of course, I have tried to make the update to Debian. However, the debian > lirc maintainer is inactive, so this road is complicated. I have tried, > really, for more or less a year. I have a packaging and a sponsor, but I'm > blocked on the maintainer. I don't see a Debian bug against lirc for this (based on your description I'd expect to see bugs in Debian tagged with patches). Though I do see only NMU uploads in Debian recently. It might be worth sorting out bugs in Debian so that it's clear to all Debian developers exactly what the situation is. Have you joined Debian's lirc Maintainer Team? Where exactly are you blocked on the maintainer? > So, questions: Is it policy-wise possible to update lirc in universe to > 0.9.4 even though Debian is still at 0.9.0? Yes, we can do this. Going faster than Debian is a valid reason. However, that does introduce a maintenance burden, so I'd expect whoever pushes ahead with lirc in Ubuntu to make a reasonable commitment about future maintenance. > If possible, how should it be handled? The update cannot really be handled > as a diff (891 files changed: 147080 insertions, 77248 deletions). It's > basically new packages. > > There is a a PPA with a 0.9.4 packaging at [2]. The changelog is a mess, > see below for a tentative entry How big is the diff of the debian/ directory? This is the part that I'd want to review carefully. Treating it as an entirely new package doesn't really work because then any review would miss any upgrade path issues. It also makes for a much harder path for Debian to catch up in the future, putting us far more on our own in maintaining a delta. I don't think you've wasted effort in repackaging using dh primitives; what you have sounds like a good goal state. What I'd like to see is a diff (or multiple diffs if complex) that get us logically from where we are now to that goal, such that each change can be verified for correctness individually. So yes, we can do it, but as an Ubuntu sponsor, I'd personally prefer to see Debian refuse this type of patchset first, and I don't see anything like that right now. Other sponsors' views may vary. Robie -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
