Hi Marco, On 13.05.19 08:12, Kees Meijs wrote:
I'm not sure how the process works exactly in terms of backports, but maybe it makes sense to provide the bird2 package via stretch-backports as well? That is, if Buster is considered stable.
The typical Ubuntu Package Cycle works in a way that like 3 months before a new Ubuntu Release will happen, they pull the Debian Testing src packages, do some "testing" aka does it compile on all platforms and then things are just declared as "stable" and are part of the new Ubuntu Release. This really hits packages in "universe" and "multiverse", because as far as I know these packages are considered "community maintained" so the packages gets no proper testing for bugs or anything from the core team. (The term used is "masters of the universe") I think that's what Bryce said with: they will just magically appear. Personally I would go for distinct package names, where `bird2` conflicts or replaces `bird`, but I need to have a look at the manual too on how to handle a shared config-path of booth packages in that case. Easiest would be to have a separate config path and init/systemd units, too. Because of reasons a user could run booth daemons in parallel; or do a far more smooth "failover" from one version to the other. Because this topic pops up quiet often: Are there any decisions/deep-thoughts on the packaging, because just having a package with binaries and man-packages does not solve these problems... or maybe I just missed the thread on the list. Best Bernd, and btw: thanks for all the work done here!