Re: btrfs-progs and libbtrfsutil versioning

[Neal Gompa <ngompa13@gmail.com>]

On Fri, Oct 2, 2020 at 1:19 PM David Sterba <dsterba@suse.cz> wrote:
>
> On Wed, Sep 23, 2020 at 09:48:44PM -0400, Neal Gompa wrote:
> > I've been working on a set of patches to synchronize the version
> > numbers across everything produced by btrfs-progs and add pkgconfig
> > files to make it easier for software to consume the libraries, but as
> > I worked through it, I started realizing that btrfs-progs actually has
> > *two* distinctly separate projects in one package.
>
> Yes, we ended up doing it like that as it makes development easier. The
> util library is there for 3rd party tools to use but otherwise is's
> internally used by btrfs-progs too. Synchronizing btrfs-progs
> development that would need new interfaces from the util library would
> require separate release and deployment.
>
> > This is somewhat problematic since it makes properly representing that
> > versioning in the packages I ship in Fedora rather difficult.
> >
> > Would it be possible to consider splitting libbtrfsutil into its own
> > project with its own releases?
>
> There's probably not a hard reason why to have them both in one project,
> but like it is now is saving my time spent on annoying tasks.
>

That's fine with me.

> > If not, is there a reason that we
> > *can't* synchronize the versions across btrfs-progs, libbtrfs, and
> > libbtrfsutil? We could still make sure that the library sonames are
> > versioned properly, but having the user-facing versions actually sync
> > up makes life a lot easier...
>
> I'm a bit lost in which versions are not in sync. The shared library
> version is an ABI and that changes only when new symbols appear. The
> whole project release versions follow the kernel scheme. So what are you
> suggesting? Eg. that libbtrfsutil should not be 5.9 but follow the
> soname version which is 1.2.0?
>

No, I'm suggesting the other way around. The libbtrfsutil "public
version" (that is, not the ABI version) would be synchronized with the
kernel version like the rest of btrfs-progs. Right now it's not,
evidenced by python-btrfsutil giving me 1.2.0 instead of 5.9.

Basically, I want to add pkgconfig files and fix the version emitted
by the Python metadata to use the project version rather than whatever
soname version is used. The soname version would still be preserved
and work as a way to track the ABI changes, but everything that reads
metadata would get the btrfs-progs parent version consistently.

> Can this be solved on the packaging side by 3 projects that are built
> from the same sources but produce only a subset of all the built files?
> This is slightly inefficient as you'd have 3 copies of btrfs-progs.tar
> but otherwise it's one time job, comparted to me having to update and
> deploy 2 projects just to progress with progs development?

It _could_, but I'd rather avoid that if I can, because it makes
keeping everything up to date painful.


-- 
真実はいつも一つ！/ Always, there's only one truth!