rdma-core package version schema

rdma-core package version schema

[Benjamin Drung]

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.

>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)

-- 
Benjamin Drung
System Developer
Debian & Ubuntu Developer

ProfitBricks GmbH
Greifswalder Str. 207
D - 10405 Berlin

Email: benjamin.drung-EIkl63zCoXaH+58JC4qpiA@public.gmane.org
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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: rdma-core package version schema

[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.

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.

> 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.

> 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.

> 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.

> 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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: rdma-core package version schema

[Benjamin Drung]

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-EIkl63zCoXaH+58JC4qpiA@public.gmane.org
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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: rdma-core package version schema

[Jason Gunthorpe]

On Fri, Jan 06, 2017 at 06:28:24PM +0100, Benjamin Drung wrote:
> 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

> > > 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

> > 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?

> 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..

> > 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.

> 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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: rdma-core package version schema

[Leon Romanovsky]

[-- Attachment #1: Type: text/plain, Size: 1866 bytes --]

On Fri, Jan 06, 2017 at 06:28:24PM +0100, Benjamin Drung wrote:
> 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:
> >
> > 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.

>
> > 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.

>
> PS: How will you create the release tarballs?

Via github interface.
https://help.github.com/articles/creating-releases/

>
> --
> Benjamin Drung
> System Developer
> Debian & Ubuntu Developer
>
> ProfitBricks GmbH
> Greifswalder Str. 207
> D - 10405 Berlin
>
> Email: benjamin.drung-EIkl63zCoXaH+58JC4qpiA@public.gmane.org
> 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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: rdma-core package version schema

[Leon Romanovsky]

[-- Attachment #1: Type: text/plain, Size: 758 bytes --]

On Fri, Jan 06, 2017 at 11:47:17AM -0700, Jason Gunthorpe wrote:
> On Fri, Jan 06, 2017 at 06:28:24PM +0100, Benjamin Drung wrote:
> > 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.

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.

>
> Jason
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: rdma-core package version schema

[Knut Omang]

On Sun, 2017-01-08 at 10:47 +0200, Leon Romanovsky wrote:
> On Fri, Jan 06, 2017 at 06:28:24PM +0100, Benjamin Drung wrote:
> > 
> > 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:
> > > 
> > > 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.
> 
> > 
> > 
> > > 
> > > 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.
> 
> > 
> > 
> > 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

> 
> > 
> > 
> > --
> > Benjamin Drung
> > System Developer
> > Debian & Ubuntu Developer
> > 
> > ProfitBricks GmbH
> > Greifswalder Str. 207
> > D - 10405 Berlin
> > 
> > Email: benjamin.drung-EIkl63zCoXaH+58JC4qpiA@public.gmane.org
> > 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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> > 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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: rdma-core package version schema

[Leon Romanovsky]

[-- Attachment #1: Type: text/plain, Size: 2967 bytes --]

On Wed, Jan 11, 2017 at 01:59:16PM +0100, Knut Omang wrote:
> On Sun, 2017-01-08 at 10:47 +0200, Leon Romanovsky wrote:
> > On Fri, Jan 06, 2017 at 06:28:24PM +0100, Benjamin Drung wrote:
> > >
> > > 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:
> > > >
> > > > 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.
> >
> > >
> > >
> > > >
> > > > 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.
> >
> > >
> > >
> > > 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?

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

>
> Thanks,
> Knut
>
> >
> > >
> > >
> > > --
> > > Benjamin Drung
> > > System Developer
> > > Debian & Ubuntu Developer
> > >
> > > ProfitBricks GmbH
> > > Greifswalder Str. 207
> > > D - 10405 Berlin
> > >
> > > Email: benjamin.drung-EIkl63zCoXaH+58JC4qpiA@public.gmane.org
> > > 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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> > > More majordomo info at  http://vger.kernel.org/majordomo-info.html

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: rdma-core package version schema

[Jason Gunthorpe]

On Wed, Jan 11, 2017 at 01:59:16PM +0100, Knut Omang wrote:

> 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.


> Isn't a dist target a well established standard the rdma_core packages 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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: rdma-core package version schema

[Knut Omang]

On Wed, 2017-01-11 at 15:10 -0700, Jason Gunthorpe wrote:
> On Wed, Jan 11, 2017 at 01:59:16PM +0100, Knut Omang wrote:
> 
> > 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.

Wonderful, I'll add it to my git vocabulary,

Thanks,
Knut

> > Isn't a dist target a well established standard the rdma_core packages 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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html