search

rpm-software-management / mock

Mock is a tool for a reproducible build of RPM packages.
GNU General Public License v2.0
383 stars 231 forks source link

opensuse leap configs need separation by minor number? #386

Open brianjmurrell opened 5 years ago

brianjmurrell commented 5 years ago

Short description of the problem

The epel, rhel and mageia configs all seem to have a single config for all minor versions within a major version. opensuse-leap seems to be an outlier here with different configs for each minor version. It would be nice if opensuse-leap would follow the other distros with just a single opensuse-leap-15-*.cfg for all minor versions.

Conan-Kudo commented 5 years ago

SUSE structures their distribution releases somewhat differently from Red Hat. Each minor version has its own ABI contract and support period within the same major version of SUSE distributions. This extends to the repositories. The distribution release repositories are different for each minor version, with different content. There is, of course, forward compatibility for packages built in 15.0 to 15.1 and 15.2. But backwards compatibility of a 15.1 package to work on 15.0 is not guaranteed, since a 15.0 system will not have access to the content of a 15.1 system without changing repositories and doing a distribution upgrade.

This effectively means that each minor version release should be treated the same way a Fedora release is.

brianjmurrell commented 5 years ago

Isn't this minor-release "abi contract" the same as with RHEL?

Conan-Kudo commented 5 years ago

Not really. Red Hat repositories are generally "continuous" on the major version for RHEL. You can lock onto a point release, but it is not the default way you set up repositories. So you generally seamlessly update into new point releases.

praiskup commented 5 years ago

RHEL has similar approach, but the repositories are managed probably managed differently (through subscription manager).

praiskup commented 5 years ago

The question is, is really separate config for each minor useful in a) mock b) copr?

Seems like from end-user perspective, at least copr should have "floating" build target.

Conan-Kudo commented 5 years ago

@praiskup We could have a opensuse-leap-15 symlink that points to the latest stable openSUSE Leap 15.x point release...

brianjmurrell commented 5 years ago

@praiskup We could have a opensuse-leap-15 symlink that points to the latest stable openSUSE Leap 15.x point release...

I would be in support of that. It seems it achieves the request of this ticket while maintaining the per-point-release model that exists.

Conan-Kudo commented 5 years ago

@brianjmurrell I can prepare a pull request for that, if this solution is okay with you @praiskup?

praiskup commented 5 years ago

I'd say it's technically OK. Updating the symlink will always take some time to release, so some "floating" baseurl/mirrorlist url would be better than symlink for floating target... are there any options? Feel free to submit PR.

brianjmurrell commented 4 years ago

Agree with @praiskup. This is almost begging for a separation of mock and the configs so that updates to the latter can be released with much less rigmarole (and latency) than I am sure goes into making a new mock release.

Conan-Kudo commented 4 years ago

I'd say it's technically OK. Updating the symlink will always take some time to release, so some "floating" baseurl/mirrorlist url would be better than symlink for floating target... are there any options? Feel free to submit PR.

@lnussel @DimStar77 Is there some kind of floating 15 target that maps to the latest Leap 15.x release?

lnussel commented 4 years ago

On the download server you mean? So far no, only openSUSE-current and openSUSE-stable but that would switch to 16 in the future also. We could create something if there was actual need.

I don't think it makes sense for a build tool though. There's an overlap of maintenance period for the minor releases, so for a while people may want to build for two minor releases and not just for the latter. 15.2 for example now gets new versions of GNOME, Qt, KDE, openssl. Certainly packages built against those won't work on 15.1.

Conan-Kudo commented 4 years ago

On the download server you mean? So far no, only openSUSE-current and openSUSE-stable but that would switch to 16 in the future also. We could create something if there was actual need.

@lnussel, this would be greatly appreciated to have.

15.2 for example now gets new versions of GNOME, Qt, KDE, openssl. Certainly packages built against those won't work on 15.1.

This happens with RHEL as well. It did with RHEL 7 and continues to occur with RHEL 8. Most people seem to be fine with having a floating version that points to the latest and people choosing the build against older minor versions when strictly desired. CentOS also does it this way.

(cc: @lkocman)