On Tue, Apr 16, 2019 at 07:23:36AM -0000, Etienne Dysli Metref wrote: > On 15/04/2019 16.51, Robie Basak wrote: > > I'm afraid that this is going to be too time consuming for me to > > review - there seem to be additional complications the more I look > > into it (eg. Cosmic and the new soname as you mention above). Based > > on previous experience I think that the technical difficulties in > > landing this safely to existing 18.04 users are going to overwhelm > > the available volunteer time available from developers who are able > > to review it. > > You are right that Cosmic must also be taken into account. However, the > situation on Cosmic is much simpler: it already has the SPv3 stack so > the upgrade would boil down to 3.0.2 -> 3.0.4. The only small issue it > that Cosmic is still using the old package names with "2" in them (i.e. > "shibboleth-sp2"), but that can be dealt with Breaks/Replaces to ensure > a smooth upgrade (as I've already done for Debian backports). Is there > something else complicating the SRU for Cosmic you were thinking of?
No, but that's still a whole lot of extra uploads, and package renaming is another task that needs to be done right. > Can you explain how the new soname is a problem? I think it clearly > separates the new and old libraries. We can't delete the old library from Bionic, so the new and old must exist concurrently. Therefore you can't just upload a replacement source package, because that would make a security fix or regular update for the old library impossible[1]. We call this situation "NBS", or "not built from any source". You'll need to create a new parallel source package with a different name (for example with a version number in it), so that's another whole bunch of renaming. > > You might be better off maintaining a PPA for users on 18.04, or > > just recommending the use of Disco once it's released, combined with > > suitable automation, tests and CI to ensure that you can roll forward > > on a six monthly basis until the next LTS is released. If that seems > > hard to you, updating 18.04 seems harder to me. > > Users of the Shibboleth SP software are typically web server operators, > as it is installed alongside Apache httpd. These people completely > ignore non-LTS releases and it is already hard enough to get them to > upgrade from one LTS to the next before its support expires. I've had > way more requests to backport the SPv3 stack to Xenial than I've got for > Bionic (for our PPA at http://pkg.switch.ch/switchaai/). Therefore, I > think it is unrealistic to ask server operators to upgrade their whole > OS every six months just to get a new SP version. I think it is worse to > leave Bionic with a broken Shibboleth SP for four more years than > upgrading it and risk breaking Moonshot (which can be fixed with a > no-change rebuild). > > Those who have the "suitable automation, tests and CI" have already > moved past Bionic, I suppose. I want to do something for the rest out > there. I understand, and I don't intend to block you from fixing Bionic now. It's just an unrealistic amount of work, in my opinion, both to do and to review, and I can't justify spending the time to review it. I expect it'll take many review iterations, based on previous experience. For example, see the Let's Encrypt/Certbot update in bug 1640978. The effort really needed to have been spent while Bionic was in development. That would have been at least an order of magnitude less effort. I honestly think that it would be more beneficial to spend that effort on future development (both upstream and in distributions) and maintain an out-of-archive backport for Bionic users, than spend this disproportionate amount of effort on updating Bionic now. For example, you could add dep8 tests which would automatically block package updates in Ubuntu unless they pass, preventing the release of broken Shibboleth packages from happening again. > > However I welcome other Ubuntu developers to take a look if they want > > to help you getting this landed. > > Could you please circulate this internally so someone else may see and > tackle it? Ubuntu development is done in public, and anyone can participate. So there isn't an "internal" as such. Feel free to email ubuntu-devel@ to point to this bug and ask for sponsorship. That should reach all active Ubuntu developers. > > I've added bug tasks for Bionic and Cosmic - getting the statuses > > all correct would be helpful if you want to proceed. > > What would be the correct status then? Fix Released for everything in the development release that won't need any further upload, Triaged for tasks in Bionic and Cosmic that do need uploads, Invalid for tasks in Bionic and Cosmic that do not need uploads for this SRU. > > I'm sorry I can't help you further. I hope this doesn't discourage > > you from continuing to help with Shibboleth packaging in Ubuntu. > > Appearing as a newcomer wanting to do major surgery is your challenge > > here. I hope that you'll find that maintaining packaging in the > > development release, and landing routine bugfixes in stable releases > > are much easier. > > It is indeed a daunting task for a newcomer. I submitted one security > patch for Shibboleth just before and it went well so I figured I'd > embark on a larger endeavour. :) For me, how packages are maintained in > Ubuntu is still fairly unclear (where is the VCS?)... Packages are team maintained. Like Debian, use (and choice) of a VCS is a team decision, and the archive itself is the single source of truth. The default is none. As there isn't a Shibboleth team in Ubuntu at the moment, you are welcome to form one, create a VCS somewhere (though not using Launchpad or Salsa would be swimming against the tide for Ubuntu developers), and ask that others use it. In the absence of a specific team, these packages currently fall under the remit of the MOTU team, but I'm not aware that anyone from MOTU has ever worked on them, so I don't think there would be any conflict there. Hope that helps! Robie [1] Strictly speaking you could produce a source package at security fix time that produced only a fixed binary, but punting that complexity to when a security fix needs to land doesn't seem like a good idea to me. If we're going to land something complex, we should leave our house in order to whoever might have to deal with it later. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1822069 Title: SRU: Shibboleth SPv3 for bionic To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/log4shib/+bug/1822069/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
