On 6/15/20 11:01 PM, Martin Wilck wrote:
On Mon, 2020-06-15 at 07:11 -0400, Neal Gompa wrote:
On Mon, Jun 15, 2020 at 4:49 AM Andreas Schwab
wrote: On Jun 09 2020, Ondřej Súkup wrote:
-- developer --> Tumbleweed ( and all devel repos have TW enabled)
That's cmpletely backwards. As a developer you need a *stable* system.
That doesn't mean you need a *stale* system (i.e. Leap).
Come on guys, this discussion is pointless. We have Leap *and* TW precisely to give people a choice.
The starting point of the discussion was the idea to provide Leap users access to up-to-date software in those areas where they need it, while keeping the rest of the system stable. That's a very reasonable thing to want to have.
The question is how to get there. Up-to-date software on older distros can e.g. be obtained by using flatpak, but AFAICS flatpak is no 1st class citizen on openSUSE. Also, it works best for "leaf" packages, less so for other things.
As for regular packaging, I hear people say that devel repos don't work for this purpose, because they're all targeted for factory. I wonder whether that has to be that way. In some areas (Rust?) it seems to be commonplace to have to update the entire stack just to be able to install a single leaf package. Even that might be possible on Leap, if such stacks were sufficiently separate from the main OS stack. In other areas, maintaining a Leap version means probably just a number of conditionals in the spec file. It's about whether or not developers care, and invest time into fixing Leap issues.
In general, I believe we should educate ourselves not to mechanically respond "install Tumbleweed" when users ask for features.
It is possible, especially for leaf packages it just requires more packaging effort and packager's don't always want to do that. One example is in Leap 15.1/15.2 there is a fish and fish3 package, the fish3 package was added post release using the maintenance update process, the fish3 package is in the devel project but not tumbleweed as the fish package in tumbleweed is fish3. The biggest issue is the bigger repo's that have a combination of system libraries and apps where some users want the apps but not the libraries. My personal solution is to branch the few applications that I need to be newer into one home repo but that's not user friendly. Similarly you could take for example all the "Games" people care about that have new version and branch them into a Games:15.1 repo that only has things that wouldn't interfere with other libs the user might have on there system as long as they still build. However for packages to be considered "openSUSE quality" they need to be reviewed etc, and when new packages are being developed for tumbleweed etc they would also get pulled in so this solution isn't something we as a project could recommend as a stable reviewed solution. You could however look at whats being done for devel:lang:python:backports, where packages only sync across to the repo once they are accepted into factory. So there are a couple of potential solutions it is just a matter of whether anyone wants to put in the effort to implement them. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B