18 Oct
2017
18 Oct
'17
6:50 p.m.
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&…
[2]
https://packages.ubuntu.com/search?suite=all§ion=all&arch=amd64…
[3] https://osmocom.org/issues/2257
[4] https://build.opensuse.org/project/monitor/network:osmocom:nitb-split:night…
[5] https://build.opensuse.org/project/monitor/network:osmocom:nightly
--
Max Suraev <msuraev(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Director: Harald Welte
18 Oct
18 Oct
11:04 p.m.
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
20 Oct
20 Oct
11:16 a.m.
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.
--
Max Suraev <msuraev(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Director: Harald Welte
31 Oct
31 Oct
11:11 p.m.
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/
24 Oct
24 Oct
2:19 p.m.
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.ht… 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?
/
--
Max Suraev <msuraev(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Director: Harald Welte
31 Oct
31 Oct
11:11 p.m.
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.ht… 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/
1 Nov
1 Nov
8:59 a.m.
Hi Max, Thorsten,
On Tue, Oct 31, 2017 at 11:11:23PM +0100, Thorsten Alteholz wrote:
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
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
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 ...
... 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.
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.ht… 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).
8:11 p.m.
Hi Harald,
On Wed, 1 Nov 2017, Harald Welte wrote:
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:.
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
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
2375
days inactive
2389
days old
7 comments
3 participants
participants (3)
-
Harald Welte -
Max -
Thorsten Alteholz