On 3/29/22 20:40, Martin Wilck wrote:
On Tue, 2022-03-29 at 10:49 +1030, Simon Lees wrote:
If I do not set the publish flag, it's almost impossible for me to test that stuff myself.
But the description of e.g. home:seife:testing contains a warning for the users :-)
Yeah I also have publishing enabled on all my test repos, some are well named others less well so. But once your working with multiple packages together the only sane way to test such things is to enable publishing add the repo to a VM and test from there.
Looks like a missing feature to me. Perhaps we should be able to distinguish between "public" repos that are meant for the public (and should be included by opi, s.o.o, and whatnot), and repos that just need to be made available to the developer himself in a fashion that facilitates testing.
Currently this is simple "Public" repos start with either.
https://download.opensuse.org/distribution/ https://download.opensuse.org/tumbleweed/
And anything under https://download.opensuse.org/repositories/
Is not yet an official part of an openSUSE "product" and should be used with upmost caution.
If what we are trying to address is mostly old packages in Leap maybe we should look at a similar approach to package hub (not the same) rather then pointing people to devel projects. For example before a package can be accepted into package hub we run checkers to make sure it wont conflict with or break packages that come from SLE.
Maybe we could take this idea further and if I wanted to provide the latest version of fish or enlightenment (examples because I maintain them) for fish its an individual packge so maybe it could go into a common repo if it passes our basic checks. Enlightenment on the other hand requires a group of packages so maybe there should be a separate repo with just those packages people can add should they want them. You could probably even do something similar with kernels.
Where it gets much harder is there was a number of packages that couldn't be updated in Leap 15.3 because Qt was too old. So do you add a new version of Qt to a repo (or multiple) and hope that there backwards compatibility promises work right and it doesn't introduce new bugs. Atleast with this kind of setup you could add those packages then run the KDE openqa test suites and have some idea of the answers. But then I guess the other question here is how far should you go with this because if you took this idea to its extremes you basically just end up with tumbleweed.
The other issue here is while something like this is probably a much better solution its probably also a large amount of work for a someone or group of someones and we'd have to find them somewhere. But on the plus side we'd no longer end up with cases where users click a one click install and end up with the wrong python on there system and everything broken (Yes this has happened plenty of times in the past). So until we have an actual proper solution as a project we should just be recommending the official repos at the same time if 3rd parties recommend 3rd party repos there isn't alot more we can do.