On 16/04/2019 11.31, Robie Basak wrote: >> 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.
Ah I see now, thanks. Short of forcing every Bionic user to upgrade to the new libraries and removing the old ones from the archive, that's an untenable position. > 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. Yes, removing Shibboleth packages from Bionic would have been better. Absent packages don't block backports. ;) > 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. Agreed. I'm already maintaining the out-of-archive backports, but I'd like to streamline it more so it feels like using [LTS]-backports (no special versions like ...-1switchaai1~bionic1, for example). In the Shibboleth case, I know that upstream is contemplating packaging for Debian and Ubuntu, but their support policy of "only the latest version is supported" is really at odds with the current policy of both Linux distributions. > 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. Thanks for the idea! I'll look into that. > 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. IMHO, ideally, the Shibboleth packaging repositories over on salsa.d.o [1] should be the reference also for Ubuntu packaging. I can create an ubuntu/ branch namespace there for this purpose, as per DEP-14. If I understand you correctly, creating a team on LP would be enough to "claim" ownership of these packages, though not enough to force others to use salsa before uploading to Ubuntu. I'll go ahead and create a team on LP as that seems to be a step in the right direction. Then I'll try to reflect the current state of Ubuntu packages in the Git repositories on salsa under ubuntu/ (changelog, patches, etc.) so that all of this can be unified. I'd still need sponsorship to upload though, but that can be sorted later. Cheers, Etienne [1] https://salsa.debian.org/shib-team -- 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
