rdma-core package version schema
Hi,
I looked at the Debian packaging of rdma-core and stumbled over the versioning. You change the version of the binary library packages (libibcm1, libibumad3, etc.) from the Debian package version (currently 12-1) to their shared library versions. This change is uncommon and confusing besides other issues. [1] It is common that the package version differ from the library (soname) version. As potential Debian sponsor I would reject this package version change.
The second problematic thing is that each library has its own major and minor number, but use the package version as patch level. This restricts the package version to one number which will increase fast.
Quoted 1 line
From my Debian maintainer perspective, I recommend following change:
Maintain two different versions, the package version and the library versions.
The package version could follow the semantic versioning [2], the version schema from the kernel [3], or by date [4]. Make that version number be useful in itself. I suggest to start with version 2.0 (since 1.3.10 is the highest version that I found in one of its libraries when they were maintained separately).
For the library version numbers, you could either maintain them separately (increase only if you touch that library between two releases) or maintain a common patch level (like you do now).
PS: I am thinking about offering becoming a co-maintainer for the rdma- core Debian package.
[1] Andrey Rahmatullin wrote in https://bugs.debian.org/850145 :
"Please make sure you fully understand the consequences of using binary package versions different from the source one."
[2] http://semver.org/
[3] major.minor.patch were major is increased when minor becomes too big.
[4] year.${number of release of the year}.patch (e.g. 2017.1)
Signature · 18 lines
Benjamin Drung System Developer Debian & Ubuntu Developer ProfitBricks GmbH Greifswalder Str. 207 D - 10405 Berlin Email: [email protected] URL: http://www.profitbricks.com Sitz der Gesellschaft: Berlin. Registergericht: Amtsgericht Charlottenburg, HRB 125506B. Geschäftsführer: Andreas Gauger, Achim Weiss. -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 7 lines · Benjamin Drung
I looked at the Debian packaging of rdma-core and stumbled over the versioning. You change the version of the binary library packages (libibcm1, libibumad3, etc.) from the Debian package version (currently 12-1) to their shared library versions. This change is uncommon and confusing besides other issues. [1] It is common that the package version differ from the library (soname) version. As potential Debian sponsor I would reject this package version change.
Just to be clear, the packaging as it is today was only a suggested starting point for discussion. I have no objection at all to changing this or other things.
This was only done for two reasons:
1) A clear migration from the pre-existing binary packages, using similar versioning (eg upgrading from librdmacm1 1.2 to 12 seems pretty wonky)
2) A possibility in future to make use of the library minor version. Eg librdmacm1 1.2 might introduce new APIs and build-depends could sanely use librdmacm1-dev (>= 1.2). RH has said they don't want to do this, and if Debian goes the same way then we won't bother manipulating the shlib minor version. Build depends will have to be based on the overall release number instead.
Quoted 3 lines
The second problematic thing is that each library has its own major and minor number, but use the package version as patch level. This restricts the package version to one number which will increase fast.
We are not using libtool so there is no concept of a 'patch level'. The file name of the shared library is not a semantic version string either. The main package version can be any string and everything will work out correctly.
If Debian does not use the library version as part of the binary package then there is no reason at all to be concerned about its construction as nothing will really see it.
Each of the libraries uses strong ABI compatability with symbol versioning.
Quoted 2 lines
The package version could follow the semantic versioning [2], the version schema from the kernel [3],
We discussed these options on the mailing list and they were not popular.
To be clear the full form of the package version is <release>.<patchlevel> similar to other projects. Eg a backport or bugfix could be called '12.1', a vendor fork could be called '12.vnd1' and so on.
We don't have any of the legacy compat reasons to have a two level release number scheme like the kernel.
Quoted 1 line
or by date [4].
I don't recall if date was discussed. It doesn't seem significantly better than a release serial number.. I think that makes more sense for a project that is doing timed releases, which we are not planning to do.
Quoted 2 lines
PS: I am thinking about offering becoming a co-maintainer for the rdma- core Debian package.
This is very exciting news! Please feel free to send any patches or pull requests to improve the packaging, or otherwise! I hope that significant parts of the the debian/ dir can be maintained upstream like Redhat is going to do for their packaging.
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): 20170105230928.GA4262-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org
Am Donnerstag, den 05.01.2017, 16:09 -0700 schrieb Jason Gunthorpe:
Quoted 11 lines · Benjamin Drung
Quoted 9 lines
I looked at the Debian packaging of rdma-core and stumbled over the versioning. You change the version of the binary library packages (libibcm1, libibumad3, etc.) from the Debian package version (currently
12-1) to their shared library versions. This change is uncommon and confusing besides other issues. [1] It is common that the package version differ from the library (soname) version. As potential Debian
sponsor I would reject this package version change.
Quoted 3 lines
Just to be clear, the packaging as it is today was only a suggested starting point for discussion. I have no objection at all to changing this or other things.
Good to hear. It looked more like being near of a release (and thus being the first step). Expect more comments from my side. ;)
Quoted 5 lines
This was only done for two reasons:
1) A clear migration from the pre-existing binary packages, using similar versioning (eg upgrading from librdmacm1 1.2 to 12 seems pretty wonky)
The version should be a little above max(pre-existing packages). That's why I suggested to start with 2.0 (which is > 1.3.10) and doesn't look scary to upgrade to.
Quoted 7 lines
2) A possibility in future to make use of the library minor version. Eg librdmacm1 1.2 might introduce new APIs and build-depends could sanely use librdmacm1-dev (>= 1.2). RH has said they don't want to do this, and if Debian goes the same way then we won't bother manipulating the shlib minor version. Build depends will have to be based on the overall release number instead.
I concur with RH. The overall release numbers are fine and useful for specifying release numbers.
Quoted 6 lines
Quoted 5 lines
The second problematic thing is that each library has its own major and
minor number, but use the package version as patch level. This restricts the package version to one number which will increase fast.
Quoted 8 lines
We are not using libtool so there is no concept of a 'patch level'. The file name of the shared library is not a semantic version string either. The main package version can be any string and everything will work out correctly.
If Debian does not use the library version as part of the binary package then there is no reason at all to be concerned about its construction as nothing will really see it.
Okay.
Quoted 5 lines
Quoted 2 lines
The package version could follow the semantic versioning [2], the version schema from the kernel [3],
We discussed these options on the mailing list and they were not popular.
Can you point me to these mails?
Quoted 8 lines
To be clear the full form of the package version is <release>.<patchlevel> similar to other projects. Eg a backport or bugfix could be called '12.1', a vendor fork could be called '12.vnd1'
and so on.We don't have any of the legacy compat reasons to have a two level release number scheme like the kernel.
I like the two level release numbers, because they prevent the major number to rise high too early. IMO 42.1 is not simpler than 2.5.1.
Quoted 6 lines
Quoted 1 line
or by date [4].
I don't recall if date was discussed. It doesn't seem significantly better than a release serial number.. I think that makes more sense for a project that is doing timed releases, which we are not planning to do.
Using the date for the version number has benefits outside of time based releases. For example you can tell from the version number whether the release is recent or old (2017.1 is fresh, but 2012.5 is old legacy stuff).
Quoted 6 lines
Quoted 3 lines
PS: I am thinking about offering becoming a co-maintainer for the rdma-
core Debian package.This is very exciting news! Please feel free to send any patches or pull requests to improve the packaging, or otherwise!
Expect patches from me. Before starting a bigger review, I will wait for the pull request https://github.com/linux-rdma/rdma-core/pull/50
Quoted 3 lines
I hope that
significant parts of the the debian/ dir can be maintained upstream like Redhat is going to do for their packaging.
That is doable as long as the future Debian maintainers will have commit access. Otherwise the debian directory will get out of sync soon.
PS: How will you create the release tarballs?
Signature · 18 lines
Benjamin Drung System Developer Debian & Ubuntu Developer ProfitBricks GmbH Greifswalder Str. 207 D - 10405 Berlin Email: [email protected] URL: http://www.profitbricks.com Sitz der Gesellschaft: Berlin. Registergericht: Amtsgericht Charlottenburg, HRB 125506B. Geschäftsführer: Andreas Gauger, Achim Weiss. -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 2 lines · Benjamin Drung
Good to hear. It looked more like being near of a release (and thus being the first step). Expect more comments from my side. ;)
Great
Quoted 7 lines
Quoted 5 lines
Quoted 2 lines
The package version could follow the semantic versioning [2], the version schema from the kernel [3],
We discussed these options on the mailing list and they were not popular.
Can you point me to these mails?
They were on the linux-rdma mailing list..
I think there were a couple threads, but here is one:
http://www.spinics.net/lists/linux-rdma/msg40407.html
Quoted 5 lines
Quoted 2 lines
We don't have any of the legacy compat reasons to have a two level release number scheme like the kernel.
I like the two level release numbers, because they prevent the major number to rise high too early. IMO 42.1 is not simpler than 2.5.1.
The down side is that 2.5.1 looks like a semantic version '42' does not.
Systemd is up to 278 and coreos is up to 1284, doesn't seem to bother anyone?
Quoted 4 lines
Using the date for the version number has benefits outside of time based releases. For example you can tell from the version number whether the release is recent or old (2017.1 is fresh, but 2012.5 is old legacy stuff).
Maybe, I don't think anyone was advocating for it..
Quoted 7 lines
Quoted 3 lines
I hope that
significant parts of the the debian/ dir can be maintained upstream like Redhat is going to do for their packaging.That is doable as long as the future Debian maintainers will have commit access. Otherwise the debian directory will get out of sync soon.
We will have to see how things work with this approach.
My hope is to keep things up to date on an ongoing basis, eg this patch would be an example
https://github.com/linux-rdma/rdma-core/commit/4910f1eb752e1303b796ede7d45fcd2f618f220a
Which includes .spec and debian/ updates for the new installed files added.
I suspect the packaging changelogs will have to be maintained downstream however.
Quoted 1 line
PS: How will you create the release tarballs?
via github so far:
https://github.com/linux-rdma/rdma-core/releases
https://github.com/linux-rdma/rdma-core/archive/rdma-core-12-rc4.tar.gz
I think Doug is still experimenting with this.
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): 20170106184717.GC5724-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org
Quoted 9 lines · Jason Gunthorpe
Quoted 1 line · Benjamin Drung
PS: How will you create the release tarballs?
via github so far:
https://github.com/linux-rdma/rdma-core/releases
https://github.com/linux-rdma/rdma-core/archive/rdma-core-12-rc4.tar.gzI think Doug is still experimenting with this.
Yes, and I'm waiting for him to do first release, so it will be acceptable by distro. This is why I didn't stick to the release schedule.
Quoted 6 lines
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 8 lines · Benjamin Drung
Am Donnerstag, den 05.01.2017, 16:09 -0700 schrieb Jason Gunthorpe:
Quoted 4 lines · Benjamin Drung
This is very exciting news! Please feel free to send any patches or pull requests to improve the packaging, or otherwise!
Expect patches from me. Before starting a bigger review, I will wait for the pull request https://github.com/linux-rdma/rdma-core/pull/50
Thanks, Talat is working to address your's and Jason's feedback.
Quoted 8 lines
Quoted 4 lines
I hope that
significant parts of the the debian/ dir can be maintained upstream like Redhat is going to do for their packaging.That is doable as long as the future Debian maintainers will have commit access. Otherwise the debian directory will get out of sync soon.
I don't think so, we are pretty fast to accept pull requests, and especially distro related ones from verified committers. However if it stops future Debian maintainer to manage this package upstream, we will give write access without doubts.
Quoted 2 lines
PS: How will you create the release tarballs?
Via github interface.
https://help.github.com/articles/creating-releases/
Quoted 20 lines
--
Benjamin Drung
System Developer
Debian & Ubuntu DeveloperProfitBricks GmbH
Greifswalder Str. 207
D - 10405 BerlinEmail: [email protected]
URL: http://www.profitbricks.comSitz der Gesellschaft: Berlin.
Registergericht: Amtsgericht Charlottenburg, HRB 125506B. Geschäftsführer: Andreas Gauger, Achim Weiss.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): 20170108084759.GJ15685-U/[email protected]
Quoted 32 lines · Leon Romanovsky
Quoted 10 lines · Benjamin Drung
Am Donnerstag, den 05.01.2017, 16:09 -0700 schrieb Jason Gunthorpe:
Quoted 5 lines · Benjamin Drung
This is very exciting news! Please feel free to send any patches or pull requests to improve the packaging, or otherwise!
Expect patches from me. Before starting a bigger review, I will wait for the pull request https://github.com/linux-rdma/rdma-core/pull/50
Thanks, Talat is working to address your's and Jason's feedback.
Quoted 10 lines
Quoted 6 lines
I hope that
significant parts of the the debian/ dir can be maintained upstream like Redhat is going to do for their packaging.That is doable as long as the future Debian maintainers will have commit access. Otherwise the debian directory will get out of sync soon.
I don't think so, we are pretty fast to accept pull requests, and especially distro related ones from verified committers. However if it stops future Debian maintainer to manage this package upstream, we will give write access without doubts.
Quoted 2 lines
Quoted 4 lines
Quoted 1 line
PS: How will you create the release tarballs?
Via github interface.
https://help.github.com/articles/creating-releases/
It seems that interface is only available for those with write access to the github repo which does not cover the (for me at least) common use case that I want to built my own slightly modified test .rpm of something. Then users will end up creating tarballs manually, or outside the build logic, with potentials for mistakes, not to mention the documentation need to tell users this.
Isn't a dist target a well established standard the rdma_core packages should support for simplicity and uniformity?
Thanks,
Knut
Quoted 15 lines
Quoted 15 lines
--
Benjamin Drung
System Developer
Debian & Ubuntu DeveloperProfitBricks GmbH
Greifswalder Str. 207
D - 10405 BerlinEmail: [email protected] URL: http://www.profitbricks.com
Quoted 7 lines
Quoted 7 lines
Sitz der Gesellschaft: Berlin.
Registergericht: Amtsgericht Charlottenburg, HRB 125506B. Geschäftsführer: Andreas Gauger, Achim Weiss.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 38 lines · Knut Omang
Quoted 32 lines · Leon Romanovsky
Quoted 10 lines · Benjamin Drung
Am Donnerstag, den 05.01.2017, 16:09 -0700 schrieb Jason Gunthorpe:
Quoted 5 lines · Benjamin Drung
This is very exciting news! Please feel free to send any patches or pull requests to improve the packaging, or otherwise!
Expect patches from me. Before starting a bigger review, I will wait for the pull request https://github.com/linux-rdma/rdma-core/pull/50
Thanks, Talat is working to address your's and Jason's feedback.
Quoted 10 lines
Quoted 6 lines
I hope that
significant parts of the the debian/ dir can be maintained upstream like Redhat is going to do for their packaging.That is doable as long as the future Debian maintainers will have commit access. Otherwise the debian directory will get out of sync soon.
I don't think so, we are pretty fast to accept pull requests, and especially distro related ones from verified committers. However if it stops future Debian maintainer to manage this package upstream, we will give write access without doubts.
Quoted 2 lines
Quoted 4 lines
Quoted 1 line
PS: How will you create the release tarballs?
Via github interface.
https://help.github.com/articles/creating-releases/
Quoted 8 lines
It seems that interface is only available for those with write access to the github repo which does not cover the (for me at least) common use case that I want to built my own slightly modified test .rpm of something. Then users will end up creating tarballs manually, or outside the build logic, with potentials for mistakes, not to mention the documentation need to tell users this.
Isn't a dist target a well established standard the
rdma_corepackages should support for simplicity and uniformity?
I have a long standing task for myself to connect rdma-core to SuSe's open build facilities [1]. It will give us RPM and DEB packages.
[1] https://build.opensuse.org
Quoted 26 lines
Thanks,
KnutQuoted 22 lines
Quoted 22 lines
--
Benjamin Drung
System Developer
Debian & Ubuntu DeveloperProfitBricks GmbH
Greifswalder Str. 207
D - 10405 BerlinEmail: [email protected] URL: http://www.profitbricks.com
Sitz der Gesellschaft: Berlin.
Registergericht: Amtsgericht Charlottenburg, HRB 125506B. Geschäftsführer: Andreas Gauger, Achim Weiss.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 6 lines · Knut Omang
It seems that interface is only available for those with write access to the github repo which does not cover the (for me at least) common use case that I want to built my own slightly modified test .rpm of something. Then users will end up creating tarballs manually, or outside the build logic, with potentials for mistakes, not to mention the?? documentation need to tell users this.
Any user can run git archive and it will always create the correct result.
$ git archive --prefix rdma-core/ --output rdma-core-12.tgz HEAD
No other steps are required.
Quoted 2 lines
Isn't a dist target a well established standard the
rdma_corepackages should?? support for simplicity and uniformity?
'make dist' is kinda a GNUism where packages that use auto* require building pre-build auto* stuff into their tar files. We do not require that and our dist tar file is identical to what git archive produces.
For developers we have the buildlib/cbuild script. Install docker and it will automate building packages for you:
$ buildlib/cbuild build-images centos7 # One time $ buildlib/cbuild pkg centos7
It takes care of all the details and guarantees the build is done with the correct set of build time packages.
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): 20170111221004.GA31081-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org
Quoted 9 lines · Jason Gunthorpe
Quoted 6 lines · Knut Omang
It seems that interface is only available for those with write access to the github repo which does not cover the (for me at least) common use case that I want to built my own slightly modified test .rpm of something. Then users will end up creating tarballs manually, or outside the build logic, with potentials for mistakes, not to mention the?? documentation need to tell users this.
Quoted 6 lines
Any user can run git archive and it will always create the correct result.
$ git archive --prefix rdma-core/ --output rdma-core-12.tgz HEADNo other steps are required.
Wonderful, I'll add it to my git vocabulary,
Thanks,
Knut
Quoted 10 lines
Quoted 2 lines
Isn't a dist target a well established standard the
rdma_corepackages should?? support for simplicity and uniformity?'make dist' is kinda a GNUism where packages that use auto* require building pre-build auto* stuff into their tar files. We do not require that and our dist tar file is identical to what git archive produces.
For developers we have the buildlib/cbuild script. Install docker and it will automate building packages for you:
Quoted 7 lines
$ buildlib/cbuild build-images centos7 # One time $ buildlib/cbuild pkg centos7It takes care of all the details and guarantees the build is done with the correct set of build time packages.
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html