opi
opi copied to clipboard
openSUSE
OPI defaults to factory repos for tumbleweed
This should not be the default behavior and will lead to broken systems and issues. Tumbleweed should be using tumbleweed repos and not factory.
os_release = get_os_release()
name = os_release['NAME']
version = os_release.get('VERSION') # VERSION is not set for TW
if version:
# strip prerelease suffix (eg. " Alpha")
version = version.split(' ', 1)[0]
if name == 'openSUSE Tumbleweed' or name == 'openSUSE MicroOS':
project = 'openSUSE:Factory'
elif name == 'openSUSE Leap':
if use_releasever_variable:
project = 'openSUSE:Leap:$releasever'
else:
project = 'openSUSE:Leap:' + version
elif name.startswith('SLE'):
project = 'SLE' + version
if prefix:
project = 'openSUSE.org:' + project
return project```
It should be
```def get_distribution(prefix=False, use_releasever_variable=False):
os_release = get_os_release()
name = os_release['NAME']
version = os_release.get('VERSION') # VERSION is not set for TW
if version:
# strip prerelease suffix (eg. " Alpha")
version = version.split(' ', 1)[0]
if name == 'openSUSE Tumbleweed' or name == 'openSUSE MicroOS':
project = 'openSUSE:Tumbleweed'
elif name == 'openSUSE Leap':
if use_releasever_variable:
project = 'openSUSE:Leap:$releasever'
else:
project = 'openSUSE:Leap:' + version
elif name.startswith('SLE'):
project = 'SLE' + version
if prefix:
project = 'openSUSE.org:' + project
return project```
def get_distribution(prefix=False, use_releasever_variable=False):
os_release = get_os_release()
name = os_release['NAME']
version = os_release.get('VERSION') # VERSION is not set for TW
if version:
# strip prerelease suffix (eg. " Alpha")
version = version.split(' ', 1)[0]
if name == 'openSUSE Tumbleweed' or name == 'openSUSE MicroOS':
project = 'openSUSE:Factory'
elif name == 'openSUSE Leap':
if use_releasever_variable:
project = 'openSUSE:Leap:$releasever'
else:
project = 'openSUSE:Leap:' + version
elif name.startswith('SLE'):
project = 'SLE' + version
if prefix:
project = 'openSUSE.org:' + project
return project
It should be:
def get_distribution(prefix=False, use_releasever_variable=False):
os_release = get_os_release()
name = os_release['NAME']
version = os_release.get('VERSION') # VERSION is not set for TW
if version:
# strip prerelease suffix (eg. " Alpha")
version = version.split(' ', 1)[0]
if name == 'openSUSE Tumbleweed' or name == 'openSUSE MicroOS':
project = 'openSUSE:Tumbleweed'
elif name == 'openSUSE Leap':
if use_releasever_variable:
project = 'openSUSE:Leap:$releasever'
else:
project = 'openSUSE:Leap:' + version
elif name.startswith('SLE'):
project = 'SLE' + version
if prefix:
project = 'openSUSE.org:' + project
return project
That should fix the markdown weirdness
Just from testing this patch, it doesn't work as it should. I think it has something to do with the OBS API right now.
Yep, as I thought. Because openSUSE:Tumbleweed doesn't contain any packages, OBS won't return anything from it even though it does contain the package in the published repository
I'm thinking maybe a message instead would work, telling the user to search the official repositories first
The thing with OPI is to make it so one doesnt have to go to software.opensuse.org to search for packages and to search through other repos both first and third party. Yet having looked at the mess that is tumbleweed repo naming on OBS i can see this will be a trifle bit difficult as there are some project repos that dont have a tumbleweed repo and some projects that dont have a factory repo. Hopefully this can be resolved.
The main usecase of opi (installing packages from devel and home projects) is not affected as there automatically an available repo is selected which doesn't happen via this codepath.
The main usecase of opi (installing packages from devel and home projects) is not affected as there automatically an available repo is selected which doesn't happen via this codepath.
I don't think you understand. When on tumbleweed people should be using the tumbleweed repos for home and devel projects... Period. If there is no tumbleweed repo, as is the case with the current utilities repo, then it should not be listed or show up as an option.
Do not mix factory and tumbleweed repos unless you enjoy having a bad time.
I do not consider this resolved. Putting a warning about using Factory Repos or adding them is not a resolution to this. For Tumbleweed the default should be Tumbleweed repos first then Factory repos.
That also isnt a resolution to the issue as if a user needs something that isn't in the repos they have included then OPI's default is to factory.
Having to deal with users who come in to the various support channels with a broken system because they have a mix of tumbleweed and factory repos due to this is an exhausting endeavor. It is compounded by the issue that even and experienced user has a high chance of slipping up and then winding up with a malfunctioning or broken system.
Again this issue is about FIXING the default for tumbleweed. Not putting a different bandaid on it to obscure that it has not been resolved.
When something is in factory, it is also in the official repos that every user has by default (unless it is a new package and the user managed to run opi in the ~24h timeframe before the new tumbleweed snapshot is released, in which case the user might even want to install from factory and will be presented with a warning and a confirmation dialog that defaults to [abort]).
The local default repos (obs devel, home and factory repos are filtered out) will be always added on top of the repo view, so if a package is in the default repo, it will be listed at position 1. So the default IS the local repo and not factory anymore.
This is still not satisfactory. You are making the assumption that a package or series of packages will go from Factory to OSS/NON-OSS which is not always the case. I would post examples of this but alas many of the *.opensuse.org domains are having issues (june 7th 2023).
So again this is not a resolution. It is a bandaid over the problem that covers up that it still persists and will continue to persist.
A better way to think of it is... and this will be done in poorly written programming terminology.
If $release=tumbleweed
then default to tumbleweed repo
Else default to Factory repo
to implement an if else like that is beyond my wheelhouse. Opi should be searching for Tumbleweed repos first when the installed system is tumbleweed and then offer Factory if one doesnt exist.
That would be interesting to know more deeply indeed as AFAIK tumbleweed is just a snapshot of factory.
But this is just one more reason that factory should still remain as an option, to allow users to install such packages.
There is no default anyway. The user is presented with a list of repos. And in most cases with the new code, factory is not the first entry. Maybe it would make sense to list factory below the devel projects. That would also make more sense in regard to the already applied color coding. Even though currently the repos are more or less sorted by the path that a package takes from home->devel->factory->oss.
Opi should be searching for Tumbleweed repos first when the installed system is tumbleweed and then offer Factory if one doesnt exist.
but this is exactly what we have with the PR. The first entry in the repos list is the tumbleweed repo, if the package exists there. Otherwise (eg. in that edge case you mentioned) the first repo might be factory.
That would be interesting to know more deeply indeed as AFAIK tumbleweed is just a snapshot of factory.
But this is just one more reason that factory should still remain as an option, to allow users to install such packages.
There is no default anyway. The user is presented with a list of repos. And in most cases with the new code, factory is not the first entry. Maybe it would make sense to list factory below the devel projects. That would also make more sense in regard to the already applied color coding. Even though currently the repos are more or less sorted by the path that a package takes from home->devel->factory->oss.
There are project repos that dont have a Factory repo and there are project repos that dont have a tumbleweed repo.
I understand the reason behind having factory as an option. However Tumbleweed repos are not even given.
Ah you are refering to the repos within a project vs. the openSUSE:Factory project?
Ah you are refering to the repos within a project vs. the openSUSE:Factory project?
One example that only has a Factory repo (off the top of my head while download.opensuse.org is down) is the Utility repo. This repo has many programs that never make it to OSS/NON-OSS.
Another Example the other way is if a user needs ZFS which is only avalible in the Filesystem repo. There is no Factory repo there and only a Tumbleweed one is offered outside of leap and SLE.
so you actually only want to use the tumbeweed repo within a project, if that exists. So that is about something quite unrelated to the PR I guess. The PR is about selecting the local repo over the openSUSE:Factory PROJECT.
But your request seems to be about using the Tumbleweed REPO within the OBS PROJECT selected by the user. So in case the user selects a project that only build the requested package against factory, we use that one. But if the package in that project was build against both factory and tumbleweed, we should use tumbleweed.
Did I understand that correctly?
so you actually only want to use the tumbeweed repo within a project, if that exists. So that is about something quite unrelated to the PR I guess. The PR is about selecting the local repo over the openSUSE:Factory PROJECT.
But your request seems to be about using the Tumbleweed REPO within the OBS PROJECT selected by the user. So in case the user selects a project that only build the requested package against factory, we use that one. But if the package in that project was build against both factory and tumbleweed, we should use tumbleweed.
Did I understand that correctly?
Correct. The Pull Request basically doesn't resolve the issue here and i was confounded as to why the issue was closed when it doesn't solve the issue.
I will be away for a while with no internet to any movement to solve issue #113 i will be unable to test until i get back. If this could be reopened i would appreciate it.
If i am understanding the PR if one has a repo (OSS) and they use opi to install something like Ark, the old method would default to adding the factory OSS repo ignoring the local tumbleweed OSS repo.
If that is the case than wonderful. That is one step towards a final resolution as that was bugger all irritating too.
Some projects (eg. Base:System) will build their packages against "standard" repo.
Would you consider that one better or worse than factory?
in the past the standard repo thing has been flakey as all heck and worse than mixing repos imhe. It would complicate things worse and really as far as i know only OSS/Non-OSS have standard repos but i could be wrong. Usualy in the past when i see standard in the url/name of a repo i either nuke it or edit it to the correct repo url.
This has also lead to support issues as far back as 11.3 when users would wind up with conflicting repos using standard and mainline ones when using the old YMP or one click install method. Also the standard repos had a habit of having their link break quite often.
i will test this as soon as i can. sadly being away with spotty internet makes testing a trifle bit difficult.