Hi.
For quite some time Osmocom packages are available in Debian [1] and Ubuntu [2] repositories. That's a really nice thing although there're only minor distro-specific updates between different releases so far.
In addition to usual "fix old bugs, add new features (and bugs :)" progress, there're bigger changes happening in Osmocom [3] projects.
Most notably: we now have multiple repositories for BSC/MSC/SGSN instead of single OpenBSC repo. The process is not finished yet (doc/manuals update is still under way for example) but I think it's already a good time to discuss how can we bring those changes into Debian/Ubuntu repositories. We already have nightly builds for all packages from new repositories [4] as well as old ones [5].
The basic question is - what shall we do to get the packages built from new repositories into Debian/Ubuntu?
Is there something we (upstream) can do, to facilitate the process?
Are there some notable .deb-specific patches you'd like to see merged?
Should I have used some other channel to communicate instead of emails I've fetched from changelogs?
[1] https://packages.debian.org/search?keywords=osmocom&searchon=names&s...
[2] https://packages.ubuntu.com/search?suite=all%C2%A7ion=all&arch=amd64&...
[3] https://osmocom.org/issues/2257
[4] https://build.opensuse.org/project/monitor/network:osmocom:nitb-split:nightl...
[5] https://build.opensuse.org/project/monitor/network:osmocom:nightly
Hi Max,
On Wed, 18 Oct 2017, Max wrote:
The basic question is - what shall we do to get the packages built from new repositories into Debian/Ubuntu?
I am already looking at those new repositories and there will be packages soon ...
Is there something we (upstream) can do, to facilitate the process?
As maintaining the copyright information in debian/copyright is the most boring task of a maintainer, maybe you can take over this? :-)
Are there some notable .deb-specific patches you'd like to see merged?
No, I didn't encounter any strange stuff you do yet, so I don't expect any patches in this regard. Thus, some time ago I already started to submit patches to some other repositories for stuff that lintian complains about ...
Should I have used some other channel to communicate instead of emails I've fetched from changelogs?
No, from my point of view this is totally fine.
Thorsten
Hi!
On 18.10.2017 23:04, Thorsten Alteholz wrote:
I am already looking at those new repositories and there will be packages soon ...
Glad to hear that.
As maintaining the copyright information in debian/copyright is the most boring task of a maintainer, maybe you can take over this? :-)
I've submitted few patches to it recently but that's just some stuff I've spotted by accident when looking at lintian output. Are there some tools/docs about it? I mean what's the actual maintenance procedure?
I'm not promising I'll keep it 100% updated all the time :-) but at least we can document this in the wiki and maybe try to plug it into release automation scripts.
Hi,
On Fri, 20 Oct 2017, Max wrote:
I've submitted few patches to it recently but that's just some stuff I've spotted by accident when looking at lintian output. Are there some tools/docs about it? I mean what's the actual maintenance procedure?
Taking care of all the things lintian complains about, is a good start. The file format is described in [1]. The procedure is to manually check each file whether there are any license information in it. As tools like licensecheck and debmake and whatever are good, but might miss strange formats, the best thing is to look into each file. That's why this is the most boring part of maintenance ..
I'm not promising I'll keep it 100% updated all the time :-) but at least we can document this in the wiki and maybe try to plug it into release automation scripts.
That would be fine.
Thorsten
[1] https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
Hi.
There's another question related to .deb packaging which emerged recently: how do we update libraries properly?
Let's take concrete example - libosmo-netif, current version is 0.0.7; libversion is 3:0:0
I'd like to release new version: 0.0.8, libversion is 4:0:1
What do I do with debian/?
The library package named libosmonetif3.install According to https://wiki.debian.org/TransitionBestPractices it should be renamed to libosmonetif4.install because we're changing "current" component of libversion.
We should also change debian/control to reflect this rename, but what about "Conflicts:" in there? I've tried reading https://debian-handbook.info/browse/stable/sect.package-meta-information.htm... but still not sure how it should be applied in case of shared libraries.
Shall we put libosmonetif3 in Conflicts? Both libosmonetif3 and libosmonetif2? Shall we use /Replaces instead? If so, for which version(s)?
Also, am I even reading this in the right place or there're some better docs recommended for Debian library packaging? /
Hi,
On Tue, 24 Oct 2017, Max wrote:
There's another question related to .deb packaging which emerged recently: how do we update libraries properly?
Let's take concrete example - libosmo-netif, current version is 0.0.7; libversion is 3:0:0
I'd like to release new version: 0.0.8, libversion is 4:0:1
What do I do with debian/?
if there is a SONAME change, the package name should change. The link in the dev package should point to the new version. And ...
The library package named libosmonetif3.install According to https://wiki.debian.org/TransitionBestPractices it should be renamed to libosmonetif4.install because we're changing "current" component of libversion.
... yes, this as well (not only this file but all others that belong to this package as well)
We should also change debian/control to reflect this rename, but what about "Conflicts:" in there? I've tried reading https://debian-handbook.info/browse/stable/sect.package-meta-information.htm... but still not sure how it should be applied in case of shared libraries.
Shall we put libosmonetif3 in Conflicts? Both libosmonetif3 and libosmonetif2? Shall we use /Replaces instead? If so, for which version(s)?
Replaces: is only for two packages with the same functionality, so a Conflicts: would be right. It should be for each version available earlier (there might be an old version left during an upgrade).
Also, am I even reading this in the right place or there're some better docs recommended for Debian library packaging?
The Debian Handbook is written by a well known Debian Developer, so this is a good starting point (though there seems to be no version for Stretch yet). There is even a package called debian-handbook. There is also the Maintainer guide[1] and of course the Debian policy[2].
It would be also nice to have versioned Depends: For example libosmo-netif depends on libosmo-abis, but what would be the minimal version that really satisfies this dependency for the latest libosmo-netif?
Thorsten
[1] https://www.debian.org/doc/manuals/maint-guide/ [2] https://www.debian.org/doc/debian-policy/
Hi Max, Thorsten,
On Tue, Oct 31, 2017 at 11:11:23PM +0100, Thorsten Alteholz wrote:
On Tue, 24 Oct 2017, Max wrote: if there is a SONAME change, the package name should change. The link in the dev package should point to the new version. And ...
The library package named libosmonetif3.install According to https://wiki.debian.org/TransitionBestPractices it should be renamed to libosmonetif4.install because we're changing "current" component of libversion.
... yes, this as well (not only this file but all others that belong to this package as well)
... which is BTW what is more or less obvious and what I did for all the releases for the osmocom:latest feed that I created on the weekend.
We should also change debian/control to reflect this rename, but what about "Conflicts:" in there? I've tried reading https://debian-handbook.info/browse/stable/sect.package-meta-information.htm... but still not sure how it should be applied in case of shared libraries.
Shall we put libosmonetif3 in Conflicts? Both libosmonetif3 and libosmonetif2? Shall we use /Replaces instead? If so, for which version(s)?
Replaces: is only for two packages with the same functionality, so a Conflicts: would be right. It should be for each version available earlier (there might be an old version left during an upgrade).
Why would it conflict? The point of having the LIBVERSION "current" as part of the .so name is that you can have both installed at the same time, and that applications are linked against a specific version. So let's say I have an incompatible older version of the library installed, some older programs can still use it, while the newer library is used by newer / newly linked applications.
I see situations like this quite normally on any debian system:
ii libreadline5:amd64 5.2+dfsg-3+b1 amd64 GNU readline and history libraries, run-time libraries ii libreadline7:amd64 7.0-3 amd64 GNU readline and history libraries, run-time libraries
Hi Harald,
On Wed, 1 Nov 2017, Harald Welte wrote:
Replaces: is only for two packages with the same functionality, so a Conflicts: would be right. It should be for each version available earlier (there might be an old version left during an upgrade).
Why would it conflict? The point of having the LIBVERSION "current" as part of the .so name is that you can have both installed at the same time, and that applications are linked against a specific version. So let's say I have an incompatible older version of the library installed, some older programs can still use it, while the newer library is used by newer / newly linked applications.
you are right, this is not a technical Conflicts: but rather a policy one. In Debian only one version of a source package is allowed in the archive (one for each release). So when you upload libosmo-netif which builds libosmonetif3 and afterwards the newer libosmo-netif that builds libosmonetif4, the former source package will be removed. This results in a missing source package for libosmonetif3. This situation is detectd by the archive software that takes care of transitions and unless all packages that depend on libosmonetif3 will be rebuilt with libosmonetif4, the package may not migrate from unstable to testing and hence never appears in any release. So in the end you have a libosmonetif3 on your computer that never will be used and such should be removed, therefore the Conflicts:.
I see situations like this quite normally on any debian system:
ii libreadline5:amd64 5.2+dfsg-3+b1 amd64 GNU readline and history libraries, run-time libraries ii libreadline7:amd64 7.0-3 amd64 GNU readline and history libraries, run-time libraries
Sure, from time to time you really need two versions of a library. So if you look at your example: dpkg-query --showformat='${binary:Package}\t${source:Package}\t${Version}\n' --show "libreadline*:amd64" libreadline-dev:amd64 readline 7.0-3 libreadline5:amd64 readline5 5.2+dfsg-3+b1 libreadline6:amd64 readline6 6.3-9 libreadline7:amd64 readline 7.0-3
you can see that each version of libreadline* also has a different source package readline*
Thorsten
-
Harald Welte -
Max -
Thorsten Alteholz