On Fri, Apr 21, 2023 at 12:44:37PM +0200, Carlos E. R. wrote:
On 2023-04-21 12:28, Erik Skultety wrote:
On Fri, Apr 21, 2023 at 12:22:04PM +0200, Carlos E. R. wrote:
On 2023-04-21 12:17, Erik Skultety wrote:
On Fri, Apr 21, 2023 at 11:35:46AM +0200, Carlos E. R. wrote:
On 2023-04-21 10:26, Erik Skultety wrote:
Hi, first of all, if this list is not the right one for this kind of request, please point me to the right direction where it would be.
I'd like to request adding a 'latest' or even '15' (any major release version) named symlink to the HTTP OS tree [1] as both to be consistent in how Leap containers are tagged [2] as well as helping other projects/consumers e.g. libosinfo [3] or our libvirt-ci [4] tool etc. to always conveniently track the latest minor release of Leap. The use case of most of these upstream communities is to always consume the latest contents to find regressions and compatibility issues early, and it poses some (not completely negligible) burden for all these communities to manually flip all URLs to flip the Leap release they track to the latest minor when it's released. So, I'm kindly asking whether such a thing could be considered.
How about
https://download.opensuse.org/distribution/openSUSE-current/
or
https://download.opensuse.org/distribution/openSUSE-stable/
?
Both point to 15.4 currently.
What happens with these when Leap 16 is out?
There is not going to be Leap 16.
I don't know what there will be, but something very different. Not upgradeable, I think. Should have a different name.
That's not the point though. The point is there's going to be something and I'm curious what the expected outcome in terms of the URLs or distro vendor support for the current release might be in that case? Ultimately that is the reason why I even asked for the 'latest' symlinks in the first place.
AFAIK it is impossible to decide what to do if it is not known what distro will be there and how will it be upgraded and what servers it needs. Maybe it doesn't use repos at all.
Certainly nothing a link change can handle.
It is impossible, AFAIK, to upgrade a 15.5 Leap machine to whatever come next. Not viable to add a link to the server.
Why are you adding upgrades into the mix? The fact that you're always able to track the latest minor release of any major version with a given link is irrelevant to upgrades, IOW, CI systems are more often than not set up in a way where in case of containers you just specify "from <registry>/leap:15" and it'll give you the latest 15.minor there is. When the next big thing arrives, unless vendor drops support for Leap 15, the 15 tag isn't going anywhere and it'll point to the latest 15.minor there is. Why can't there be the same thing for install trees? That way anyone consuming Leap 15 in their CI will always refresh to whatever contents is the latest for Leap 15. Now, let's say hypotheticaly there would be Leap 16. That CI system would either decide to drop 15 completely, but if that release is still supported by the vendor, than the more likely scenario is to add another entry and another instance for Leap 16, keeping 15 fresh. This is very much relevant for VM workloads and installs. I mean if you look at Alma for example, they track RHEL releases, but they only ever expose the latest RHEL minor for a given Alma major. I get it, OpenSUSE has a different process, different policy, but so far IMO I haven't been given a compelling reason why the idea of having a symlink in the tree is bad, because like I hopefully explained, that's something which, although a thing, is mostly irrelevant to existence of such a link in the first place.
The people going from 15.5 to whatever comes next have to read a lot of documentation (that doesn't exist yet) and install fresh something new in some way yet to be invented.
Okay, point taken, but again, ^this IMO doesn't have a practical impact on what I'm requesting, IOW if one uses the links for things that aren't supported it's their problem. Unless you're trying to tell me that upgrades among minor versions are either not seamless or not supported at all, i.e. going from 15.4 to 15.5 which would ultimately be enough of a justification to me not to do what I'm asking and we're basically done here, because so far I considered your upgrade argument to only relate to going to the next major release. Erik