Am Donnerstag, den 05.01.2017, 16:09 -0700 schrieb Jason Gunthorpe: > On Thu, Jan 05, 2017 at 08:01:07PM +0100, Benjamin Drung wrote: > > 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. Good to hear. It looked more like being near of a release (and thus being the first step). Expect more comments from my side. ;) > 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. > 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. > > 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. Okay. > > 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? > 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. > > 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). > > 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 > 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? -- Benjamin Drung System Developer Debian & Ubuntu Developer ProfitBricks GmbH Greifswalder Str. 207 D - 10405 Berlin Email: benjamin.drung@xxxxxxxxxxxxxxxx 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
