On 5/5/21 7:08 PM, Neal Gompa wrote:
On Wed, May 5, 2021 at 11:55 AM Qiyu Yan <yanqiyu@xxxxxxxxxxxxxxxxx> wrote:
在 2021-05-05星期三的 07:44 +0200，Dan Čermák写道：
przemek klosowski via devel <devel@xxxxxxxxxxxxxxxxxxxxxxx> 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/libdnf-0.55.0-Switch-allow_vendor_change-off.patch?expand=1
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.
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
