#1150 request for clarification wrt. base version / compat package naming
Opened 2 years ago by decathorpe. Modified a year ago

There's several pieces of documentation for compat packages, for example:

I seem to remember that the general guideline is also that the base package without version suffix MUST (or SHOULD) be the one with the latest version, and compat packages should only be created for older versions of the base package, but I cannot find references to this rule anywhere. At this point, I'm not sure whether it's an actual rule at all, or just "common sense" that is not written down anywhere.

c.f. https://bugzilla.redhat.com/show_bug.cgi?id=2037863#c1
c.f. https://bugzilla.redhat.com/show_bug.cgi?id=2037557#c1


Consensus seemed to be "common sense", and we probably don't want to change that.

I don't think there is any such rule. In fact, there are situations where I would not recommend it.

E.g. when we introduce new alternate (development) Python versions to Fedora, it's too soon to update the "main" Python package to the new version and introduce the previous version as the "main".

What I remember here is that we deliberately did not say that the unversioned package should be the latest. All we did is say not to use things like "-latest" because they tend to become untrue without diligence.

It's really going to be up to what the packager decides for each individual piece of software. Is it worth adding a statement to that effect?

Here is an example from the packaging list where it is asked if the exception applies
and the request is denied because the base package is not the latest:
[Fedora-packaging] Multi-version and review exception.

In my opinion, it would be better to make the rule explicit.
Now different people have different understanding of what the rule actually is.

Exactly. Because this is not really explicit in the guidelines for package naming and package review exemptions, everybody seems to interpret this differently.

And to my chagrin, "Gwyn can just do whatever she likes" isn't a great policy.

I'd prefer to encode in policy that the unversioned package is the latest version and that versioned packages are primarily compatibility/legacy versions. That aligns with the rest of our policies and makes things relatively straightforward.

If there is a case where there's no unversioned package (e.g. Python, GTK, Qt), then the compatibility/legacy exception doesn't apply to them at all ever.

Metadata Update from @tibbs:
- Issue tagged with: meeting

2 years ago

Using libsoup as an example, I think these would be the naming options.

A. libsoup2 and libsoup (3)
B. libsoup2 and libsoup3
C. libsoup (2) and libsoup3

A seems best to me, B is acceptable, and C should not be allowed. This could be phrased in the guidelines along the lines of "an unversioned package should be the latest upstream version, if you want to do anything else then version all packages of that software". An unversioned package that is not the latest version is too confusing. This would only apply to the main package names (SRPM) in Rawhide. Stable branches should stick with the naming scheme they used when they branched from Rawhide, even if upstream releases a new major version later during that release's lifecycle. Subpackages can have more flexibility to do things like what Python does.

There's a problem with variant A if you only want this to apply to rawhide. You probably also want to build libsoup 3.x on stable branches, because some applications start using it, and you want to update those. Would you need to create a libsoup3 package that only exists on stable branches, a libsoup2 package that only exists on rawhide, and libsoup has version 2 in stable branches and version 3 in rawhide? ...

There's a problem with variant A if you only want this to apply to rawhide. You probably also want to build libsoup 3.x on stable branches, because some applications start using it, and you want to update those. Would you need to create a libsoup3 package that only exists on stable branches, a libsoup2 package that only exists on rawhide, and libsoup has version 2 in stable branches and version 3 in rawhide? ...

We already deal with this problem with OpenSSL, it seems to be fine...

I seem to remember that the general guideline is also that the base package without version suffix MUST (or SHOULD) be the one with the latest version,

The Golang guidelines effectively say the opposite. Packages are named for the import path, and the convention there is that 0.x.y and 1.x.y are unsuffixed, but [23456789].x.y get a /v[2346789] suffix, which is put into the package name by the Go macros, meaning unsuffixed is not going to be latest.

The Golang guidelines effectively say the opposite. Packages are named for the import path, and the convention there is that 0.x.y and 1.x.y are unsuffixed, but [23456789].x.y get a /v[2346789] suffix, which is put into the package name by the Go macros, meaning unsuffixed is not going to be latest.

Yeah, that makes sense, since it matches conventions for upstream import paths. It's also a consistent rule. It would be nice to have at least a consistent recommendation for other packages as well.

You probably also want to build libsoup 3.x on stable branches,

I don't think that scenario is that common. More often than not, we want to update a library to a new major version and applications are not compatible yet and require the previous major version. This can be worked out in Rawhide (sometimes with snapshots of unreleased software to fix compatibility) without impact on stable branches. In fact, I'd go as far to say that adding the new major version as a versioned package into a stable Fedora branch should be difficult/discouraged (this may be an unpopular opinion).

Can this issue be closed, or was there something else that you wanted the FPC to discuss/decide? I'm moving the issue to needinfo because nothing has really happened in months, but it might be better to just close and reference it in a new issue if you have follow on questions/requests.

Metadata Update from @james:
- Issue untagged with: meeting
- Issue tagged with: needinfo

a year ago

I no longer feel particularly strongly about this, so I think we can just leave things as they are - but I still would like to have some sort of guidance in the Packaging Guidelines (even if that guidance ends up being "use common sense").

Login to comment on this ticket.

Metadata