#91 Consider tuning up the way how users are receiving repositories for Leap
Opened 5 months ago by lkocman. Modified a month ago

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)

3 months ago

Metadata Update from @lkocman:
- Issue status updated to: Open (was: Closed)

3 months ago

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.

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 |

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.

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.

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.

But we don't use any attributes in the openSUSE repos that aren't supported by both. What's the concern there?

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.

Can we at least make the repo-ids from the service match the ones from 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.

Login to comment on this ticket.

Metadata