Copy paste from release team meeting minutes https://bugzilla.opensuse.org/show_bug.cgi?id=1200446 (haven't deep dive to this yet) ^ (see previous meeting minutes for more info) lkocman: I'm still thinking of a service to deliver these repositories compared to current file definitions ... we wanted it for Jump. 15.5 is
This is the last release, I'd do any sort of trivial fixes, but would not intrudoce any big complex or compatibility-breaking changes.
was discussed during todays meeting
Changing repo getting dramatically e.g. by introducing a new service is not a good solution for the very last release. We can consider that for ALP.
For 15.5 we will use existing rpm-repos-openSUSE package that recommends the repo files https://build.opensuse.org/request/show/1000660 so autoyast can filter it out in case of offline install.
Metadata Update from @lkocman: - Issue close_status updated to: Completed - Issue status updated to: Closed (was: Open)
Metadata Update from @lkocman: - Issue status updated to: Open (was: Closed)
Re-openning as there are still quite some issues to be worked out.
Agreed direction after discussion with Michael Andres and Neal is service (my original wish).
https://doc.opensuse.org/projects/libzypp/HEAD/zypp-services.html#services-usecase-4
Original response from Michael
On Friday 02 September 2022 13:13:32 Lubos Kocman wrote:
I had a conversation with Max yesterday and DimStar today about an easy way to filter out our online repositories during autoyast installation.
JFYI: I'll be on vacation next week. Back on Sept.12.
Related issue https://bugzilla.suse.com/show_bug.cgi?id=1200446 / Related feature tracker to revisit the way how we define repos for Leap
Frankly, why does not use a (local) service for it, like SLE does for a long time. I don't understand why openSUSE complains that it's so hard to manage the repos, OTOH does not use the solutions we have.
I have a local repoindex.xml describing the openSUSE repos. This is what could be shipped in a package (and/or offered online).
root@fibonacci:~ $ $ head /Local/Service/repo/repoindex.xml <repoindex ttl="0" disturl="https://download.opensuse.org" distsub="leap/" distver="${releasever}" debugenable="false" sourceenable="false">
<repo url="%{disturl}/distribution/%{distsub}%{distver}/repo/oss" alias="repo-oss" name="%{alias} (%{distver})" enabled="true" autorefresh="true"/> <repo url="%{disturl}/distribution/%{distsub}%{distver}/repo/non-oss" alias="repo-non-oss" name="%{alias} (%{distver})" enabled="true" autorefresh="true"/> <repo url="%{disturl}/update/%{distsub}%{distver}/oss" alias="update-oss" name="%{alias} (%{distver})" enabled="true" autorefresh="true"/>
A single command adds the service: zypper as /Local/Service/repo/repoindex.xml openSUSE
A service refresh adds the missing repos and removes repos that where removed from the service. The settings in the service are used as default. You are able to change them in the repo or restore the services defaults.
root@fibonacci:~ $ zypper ls -r openSUSE # | Alias | Enabled | Refresh | Type --+--------------------------------------+---------+---------+--------- 1 | openSUSE | Yes | No | ris - | openSUSE:debug-non-oss | No | ---- | - | openSUSE:debug-oss | No | ---- | - | openSUSE:repo-backports-debug-update | No | ---- | | openSUSE:repo-backports-update | Yes | Yes | | openSUSE:repo-non-oss | Yes | Yes | | openSUSE:repo-oss | Yes | Yes | - | openSUSE:repo-sle-debug-update | No | ---- | | openSUSE:repo-sle-update | Yes | Yes | - | openSUSE:source-non-oss | No | ---- | - | openSUSE:source-oss | No | ---- | | openSUSE:upadte-non-oss | Yes | Yes | | openSUSE:update-oss | Yes | Yes |
Disabling the service (zypper ms -d openSUSE) disables all repos the service provides:
root@fibonacci:~ (0) $ zypper ms -d openSUSE Service 'openSUSE' has been successfully disabled.
root@fibonacci:~ (0) $ zypper ls -r openSUSE # | Alias |Enabled | Refresh | Type --+--------------------------------------+---------+---------+--------- 1 | openSUSE |No | ---- | ris - | openSUSE:debug-non-oss |No | ---- | - | openSUSE:debug-oss |No | ---- | - | openSUSE:repo-backports-debug-update |No | ---- | - | openSUSE:repo-backports-update |No | ---- | - | openSUSE:repo-non-oss |No | ---- | - | openSUSE:repo-oss |No | ---- | - | openSUSE:repo-sle-debug-update |No | ---- | - | openSUSE:repo-sle-update |No | ---- | - | openSUSE:source-non-oss |No | ---- | - | openSUSE:source-oss |No | ---- | - | openSUSE:upadte-non-oss |No | ---- | - | openSUSE:update-oss |No | ---- |
Re-enabling the service zypper ms -d openSUSE) restores the repos with their previous state:
root@fibonacci:~ (0) $ zypper ms -e openSUSE Service 'openSUSE' has been successfully enabled.
Removing the service would remove all provided repos.
Pro in the current context, the distribution just defines where the repos are and does not need to care about the packagemanager handling them.
I've discussed it with DimStar, and creating just a symlink (original thought from Neal) would not be sufficient. Having two separate rpms from the spec seems to be preferred for the following reasons: We're worried about zypper and yast behavior while processing DNF-style options from the repo files. An example could be editing repo attrs via yast etc.
I've discussed it with DimStar, and creating just a symlink (original thought from Neal) would not be sufficient. Having two separate rpms from the spec seems to be preferred for the following reasons:
We're worried about zypper and yast behavior while processing DNF-style options from the repo files. An example could be editing repo attrs via yast etc.
They may get lost.
The current package has merged Repos rpm, debug, and src in a single repo file, which I like.
Why? Usually no one sees or fidles with the .repo files directly.
However, many Leap systems could end up having duplicated repo entries for debug and source repositories after migration. We've had a similar issue with moving from ports.
Zypp handles repos according to their alias, not to the file that ships the entry. The alias needs to be unique on the system. If you chose one that the user/system has chosen as well, simply install the .repo file, you create clashes.
That's why service repos use the service name as namespace.
For sure, we need to keep DNF and Zypp repo entries identical. If the package generated two sets of .repo files from a single source during building, that would be the best.
If the disto generates a local repoindex, it would not need to care about the packagemanager.
Thoughts Michael, do you also believe we need two sets of repo files (DNF/zypp) or could we have unified ones? Or would you not recommend such an approach (splitting repos from release-package) at all?
I would not go for unified .repo files in a hurry. It's not just because of the repo option sets. Also the supported URL schemata probably differ as well as the handling of custom schemata.
DimStar seemed to be supportive of it. It fixes the little issue but provides a bit more "flexibility" with autoyast deployments.
With a wellknown openSUSE (Leap... whatever) service you just need to disable it. In Conjunction with repo variables you may even be able to further tune it.
If we would find a common way we could go forward. Regarding timing in Leap I'm bit unhappy that such change is in 15.5, so we'd definitely had to do the change in Early Alpha and probably not later.
--
cu, Michael Andres
+------------------------------------------------------------------+ Key fingerprint = 2DFA 5D73 18B1 E7EF A862 27AC 3FB8 9E3A 27C6 B0E4 +------------------------------------------------------------------+ Michael Andres (he/him/his), Engineering & Innovation, ma@suse.com +------------------------------------------------------------------+ SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany, (HRB 36809, AG Nürnberg) Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Martje Boudien Moerman +------------------------------------------------------------------+
Did anyone actually look at the repo files I made? The settings used are supported by both DNF and Zypper.
See for example:
Yes we did, there was a discussion with Michael Andres, he did not recommend to re-using the same files for both DNF and zypper as not all of attrs are supported on both sides. I did introduce him to proposal of using prioritized list for repo file lookup.
If the support for attributes would be the same in both dnf and zypp reusing would be probably the best option. However, as of today there were options to use service (highly appraised by Michael) or effectively doubling amount of repositories provided in rpm-repos-openSUSE.
The agreement that Michael, me and Dimstar reached out to was repo files managed by a local zypp service to get most out of default packaging tool.
But we don't use any attributes in the openSUSE repos that aren't supported by both. What's the concern there?
Can we at least make the repo-ids from the service match the ones from rpm-repos-openSUSE?
rpm-repos-openSUSE
This will always add the openSUSE: prefix so e.g. openSUSE:repo-oss. Otherwise yes we can. All definitions are currently in https://github.com/openSUSE/openSUSE-repos/
Lubos to go through naming to make sure we do not differentiate.
Addition of NVIDIA https://github.com/openSUSE/openSUSE-repos/pull/31
Metadata Update from @lkocman: - Issue set to the milestone: None (was: 15.5)
Login to comment on this ticket.