On 5/5/21 7:08 PM, Neal Gompa wrote:
On Wed, May 5, 2021 at 11:55 AM Qiyu Yan
<yanqiyu(a)fedoraproject.org> wrote:
>
> 在 2021-05-05星期三的 07:44 +0200,Dan Čermák写道:
>> przemek klosowski via devel <devel(a)lists.fedoraproject.org> writes:
>>
>>> Is that something we need to worry about? I couldn't think of any new
>>> rules to impose on repositories, but maybe dnf should have more
>>> explicit
>>> warnings when it sees multiple versions of the same package, or at
>>> least
>>> a way to show such versions.
>>
>> Or how about teaching dnf that only certain repositories are allowed to
>> be used for updates (with an allowedlist for exceptions)? Then
>> microsoft
>> or any other third party repo could put hello-5000-1 into their repo
>> and
>> it could never compromise your system, as dnf would not consider the
>> 3rd
>> party repo a valid update repo for a base system package.
Neal, I remember you had a really good idea about this - repo stickiness
(+repo equivalence classes). It might be a better option than vendor
stickiness. I'd like to explore this more in DNF 5 (see my excuses why I
don't want to do it in DNF 4 below).
>>
>> That would require dnf to track where it got the package from though
>> and I am not sure if it does that at the moment?
> This reminds me of an idea named Vendor Change from Zypper of openSUSE
>
https://en.opensuse.org/SDB:Vendor_change_update
> This approach seems to solve our problems here?
Well, we do have the sticky vendor feature in DNF, DNF on openSUSE has
it switched on by default[1]. If we want to have this feature turned
on in Fedora, we could look at having it switched on.
[1]:
https://build.opensuse.org/package/view_file/openSUSE:Factory/libdnf/libd...
Yes, there's basic support for ventor stickiness in DNF.
It probably works fine with dnf install and upgrade.
I have concerns about the following commands:
* downgrade
* not supported in Zypper
* no support in libsolv
* dnf emulates downgrades with installs, that implies vendor changes
* distro-sync
* unsupported with allow_vendor_change=1
* install
* installing explicit NEVRA lead to vendor change
* vendor changes are not displayed in the transaction table
* updateinfo
* dnf probably considers all package versions as update candidates
* needs thorough testing at least
* literally all dnf commands that query the package set,
because vendor impacts the meaning of the latest package.
* list
* info
* repoquery
* repoclosure
* COPR
* enabling a COPR repo would do nothing if the repo provides
alternatives to packages shipped in Fedora
* maybe a good thing, but definitely a change in user expectations
What's also important, DNF team currently doesn't have capacity to fix
all new bugs related to turning `allow_vendor_change` option on. Our
priority is RHEL 9 (that includes new modularity depsolver among other
bugs/RFEs) and DNF 5 (doing it right takes time and is relatively hard,
but we believe it pays off long-term due to bringing better APIs,
overall consistency etc.)
To be clear, I like the idea of vendor/repo stickiness turned on by
default, it could solve a lot of problems and eventually provide a very
simple alternative to modularity. I'm just not convinced that the DNF
stack is ready for that now and turning it on would most likely make
user experience worse. I'm fine with my team looking into this when we
have capacity to do so - that means in about one year from now.