Bug 28621

Created attachment 12484 [details]
Discover insurrection

Discover offers an update in /etc/urpmi/skip.lst

Created attachment 12485 [details]
Compliant mgaapplet

The mgaapplet does the right thing.

Hi, thanks reporting this.

Plasma Discover proposes you updates through DNF-backend from PackageKit.
Rpmdrake and mgaapplet both use urpmi as backend.

Packages in /etc/urpmi/skip.lst are only ignored by urpmi, not by DNF and all softwares that use DNF.

This is NOT a bug but a side effect of having both packages managers.


To resolve this:

To add packages to be ignored by DNF:
add for example:
exclude=git kernel* nss-*
to /etc/dnf/dnf.conf file as root.
Note you can use wildcard like "*" in names.

We currently don't support synchronization between urpmi/dnf for
 - /etc/urpmi/skkip.lst and /etc/dnf/dnf.conf ; 
 - activated/deactivated repositories
 - dependencies from packages installed from the other package manager.


perhaps, if we rewrite urpmi plugin for PackageKit, Discover will use urpmi and this time, will ignore updates for packages in /etc/urpmi/skip.lst

Assignee: bugsquad => mageiatools
Summary: Discover doesn't respect skip.lst => Restore urpmi plugin for PackageKit to make Plasma Discover respects skip.lst
Status comment: (none) => Write/restore urpmi PackageKit plugin
Version: 8 => Cauldron
Whiteboard: (none) => MGA8TOO
Severity: major => normal
CC: (none) => ouaurelien
Source RPM: discover-5.20.4-3.1.mga8.src.rpm => urpmi-8.125-1.mga8.src.rpm

maat is interested to work on this task.

Assignee: mageiatools => maat-ml
CC: (none) => mageia

(In reply to Aurelien Oudelet from comment #3)

> 
> Packages in /etc/urpmi/skip.lst are only ignored by urpmi, not by DNF and
> all softwares that use DNF.
> 
> This is NOT a bug but a side effect of having both packages managers.
> 

Thanks for all the work I can see you and the devs do.

[rolf@x570i ~]$ sudo urpme dnf
To satisfy dependencies, the following 2 packages will be removed (2MB):
  dnf-4.6.0-1.mga8.noarch
  yum-4.6.0-1.mga8.noarch
   (due to unsatisfied dnf == 4.6.0-1.mga8)
Remove 2 packages? (y/N)y

OK with me, since I use neither.  However, that did not silence the Discover update applet and removing packagekit looked to remove things I use, albeit I did not try --nodeps

Discover settings has no provision to disable any part of it, except to de-select software sources, and "Flatpak" is greyed-out, can't be de-selected.  I removed what sources I could and maybe I will have to be satisfied with that, for now.

I see the also very-hard-working Neal Gompa promising for quite a while some urpm "shim" to make a seamless integration with the package managers yum and dnf, which he seems more motivated to promote.

Please, disabuse my of my perception that Mr. Gompa is not so familiar with the capabilities of urpm as he is with the packaging initiatives of other distributions and that he promotes yum, dnf, maybe flatpaks to the detriment of the features of urpm.

My opinion might be more than a resistance to change; some long-time developers have expressed their misgivings about an apparent decrementation of support for urpm.

I use urpm and have done since mid 2000 with my first linux OS, Linux Mandrake 7.1 Deluxe 7 CD set shipped from California, when Mandrake had offices here. 

Under the "Severity" dropdown in bugzilla, I see, "Major: A major feature is broken.  From where I sit, the loss of this and any other function of urpm due to the involuntary imposition of other software managers IS a bug.

(In reply to Rolf Pedersen from comment #5)
> (In reply to Aurelien Oudelet from comment #3)
> 
> > 
> > Packages in /etc/urpmi/skip.lst are only ignored by urpmi, not by DNF and
> > all softwares that use DNF.
> > 
> > This is NOT a bug but a side effect of having both packages managers.
> > 
> 
> Thanks for all the work I can see you and the devs do.
> 
> [rolf@x570i ~]$ sudo urpme dnf
> To satisfy dependencies, the following 2 packages will be removed (2MB):
>   dnf-4.6.0-1.mga8.noarch
>   yum-4.6.0-1.mga8.noarch
>    (due to unsatisfied dnf == 4.6.0-1.mga8)
> Remove 2 packages? (y/N)y
> 
> OK with me, since I use neither.  However, that did not silence the Discover
> update applet and removing packagekit looked to remove things I use, albeit
> I did not try --nodeps
> 
> Discover settings has no provision to disable any part of it, except to
> de-select software sources, and "Flatpak" is greyed-out, can't be
> de-selected.  I removed what sources I could and maybe I will have to be
> satisfied with that, for now.
> 
> I see the also very-hard-working Neal Gompa promising for quite a while some
> urpm "shim" to make a seamless integration with the package managers yum and
> dnf, which he seems more motivated to promote.
> 

The shim does exist, it is just not packaged in Mageia. Right now, it only has dnf-urpmi and dnf-urpme. I haven't yet written urpmf/urpmq wrappers mostly due to decreasing time. The upstream project is on GitHub[1] and accepts PRs for adding functionality. It was shipped in OpenMandriva, but I did not import it into Mageia because I didn't want to get flamed to death for only having shims for urpmi(8) and urpme(8) and not urpmf(8) and urpmq(8).

[1]: https://github.com/rpm-software-management/dnf-URPM

> Please, disabuse my of my perception that Mr. Gompa is not so familiar with
> the capabilities of urpm as he is with the packaging initiatives of other
> distributions and that he promotes yum, dnf, maybe flatpaks to the detriment
> of the features of urpm.
> 
> My opinion might be more than a resistance to change; some long-time
> developers have expressed their misgivings about an apparent decrementation
> of support for urpm.
> 

I'm extremely familiar with all major package managers and several minor ones. I've contributed to several Linux distributions and work on software management tooling for many platforms.

For my day job, I do a lot of work with RH/Fedora, Debian/Ubuntu, and SUSE distributions. As part of that work, I contribute to those distributions and have met and worked with all of the software management teams in those platforms.

The reason I work on DNF and advocate for it in Mageia is because the DNF team actually *cares* about our needs and have been willing to write code to support our needs. Moreover, they were willing to review and accept my patches and eventually give me maintainer status on the projects. They've even gone so far as to write a Perl binding for the underlying libdnf library (which has involved more or less rewriting the whole library to support a Perl binding) so that Thierry Vignaud can port the current Perl URPMI CLI tools and the DrakX installer to it. I've built snapshots[2] for him as it's being developed so he can work with it.

As a developer in a small Linux distribution with *very few* developer resources, I have *greatly* appreciated the fact that they give bugs I file on behalf of Mageia the same priority they gave bugs filed for Fedora and quickly resolve them. They're kind, helpful, and willing to work with me to solve problems. There are more developers working on DNF than there are developers in Mageia today, and they're genuinely willing to help do stuff *for us*. There has been a ton of improvements in DNF specifically for Mageia and I have greatly appreciated their willingness to accommodate our needs.  

From a technical perspective, the DNF package manager is considerably more advanced than URPMI. It supports all the functionality that RPM has introduced in the past six years, including Supplements/Enhances[3] and conditional dependencies[4]. It also supports RPM file dependencies, which URPMI has never fully supported, which has forced us to patch things specifically to avoid file dependencies when we shouldn't need to.

The ManaTools project (which is part of Mageia) develops dnfdragora[5] as a replacement for rpmdrake tool, which has seen significant adoption outside of Mageia as well. The benefit to using common underlying tooling is that people are willing to use it and contribute to it, and we've benefited from that with dnfdragora. The development of dnfdragora should be proof that Mageia can provide something on top of DNF that feels at home with the rest of the Mageia tools.

Additionally, we are also able to support AppStream[6] repository metadata, which is required for Plasma Discover and GNOME Software. And DNF offers a built-in method for incremental fetching of repository metadata[7] which helps for more bandwidth constrained users by making it possible to only fetch portions of the repository metadata to synchronize local copies with what remote repositories have to save bandwidth.

[2]: https://copr.fedorainfracloud.org/coprs/ngompa/dnf5-mga/
[3]: https://rpm.org/user_doc/dependencies.html#weak-dependencies 
[4]: http://rpm.org/user_doc/boolean_dependencies.html
[5]: https://github.com/manatools/dnfdragora
[6]: https://www.freedesktop.org/wiki/Distributions/AppStream/
[7]: https://www.jdieter.net/posts/2018/04/30/introducing-zchunk/

> I use urpm and have done since mid 2000 with my first linux OS, Linux
> Mandrake 7.1 Deluxe 7 CD set shipped from California, when Mandrake had
> offices here. 
> 
> Under the "Severity" dropdown in bugzilla, I see, "Major: A major feature is
> broken.  From where I sit, the loss of this and any other function of urpm
> due to the involuntary imposition of other software managers IS a bug.

This is not a bug, the PackageKit URPMI backend has been rotten since at least 2009, and nobody ever worked to make it better before I took over PackageKit maintenance. It was finally removed last year after years of bitrot to simplify the PackageKit codebase, along with the YUM backend and others.

Let's say we restored the PackageKit-URPMI backend somehow and made it work. Even if we did that somehow, GNOME Software and Plasma Discover would be utterly broken because there's no way to ship AppStream data with URPMI. It would require significant work to change URPMI so that it would be possible to attach, fetch, and synchronize that data. There are no PackageKit frontends that would work with the old URPMI backend except pkcon(1), which basically nobody uses.

I would implore that you consider taking a second look at the DNF package manager stack in Mageia[8]. In every release since it was introduced in Mageia 6[9], it has considerably improved in both performance and capability[10].

The issue with the Plasma Discover notifier is that it doesn't seem to be able to be disabled easily. Other distributions typically split the notifier out to a subpackage to avoid this problem while being able to ship Discover, but since we don't ship Plasma Discover by default, it hasn't really been a concern for us.

[8]: https://wiki.mageia.org/en/Using_DNF
[9]: https://blog.mageia.org/en/2017/07/21/dandifying-mageia-part-2/
[10]: https://dnf.readthedocs.io/en/latest/release_notes.html

Priority: Normal => Low
Severity: normal => enhancement
CC: (none) => ngompa13

(In reply to Aurelien Oudelet from comment #3)
>
> We currently don't support synchronization between urpmi/dnf for
>  - /etc/urpmi/skkip.lst and /etc/dnf/dnf.conf ; 
>  - activated/deactivated repositories
>  - dependencies from packages installed from the other package manager.
> 

These are actually all things I want to fix by adding tools and DNF plugins to read the urpmi configuration files and translate them into DNF configuration. Since nobody else has been willing to step up on it, it's mostly on my plate to find time to do that work. It's definitely workable to make those be respected.

I've been getting my feet wet with writing DNF plugins and I'm hoping to have something for these soon.

(In reply to Neal Gompa from comment #6)
Ok, Mr. Gompa.  I said you were hard-working. ;)

Notably, urpmq and urpmf are tools the equivalents of which I consistently fail to find when auditing other package managers.

I will steer my energies toward learning what it is you and the development community are developing for Mageia and, as needed, utilize what are, to me, the formidable query tools of urpm.

Thanks for broadening my perspective.

Please NEAL don't take bugs and modify names as you want.


Maat have started to look to add back urpmi support. This but will speak about this.

Summary: Add support for DNF to import URPMI user preferences => Write/restore urpmi PackageKit plugin
Assignee: ngompa13 => maat-ml

Just for you knowledge in case you forgot, urpmi is still default and this is not planned to remove it at this day. 

This sound logical we have our distribution compatible with it.
urpmi support in packagekit have been remove because we were not working on it and because we move to dnf backend.

This sound more logical to go back to our backend.

We have the chance to have someone available to work on it.

Please do not assign the bug to you (

"urpmi support in packagekit have been remove because we were not working on it and *NOT* because we move to dnf backend in mageia."

a more clear sentence :-)

Hi all,

I'm starting to work on urpmi (among other topics)... i'll first work to add back the packagekit urpmi backend and ensure that Discovery behaves as expected on Mageia. Not that I consider Discover and packagekit as critical components to manage the distribution but It will both allow me to "discover" :@) the topic and solve a user side issue.


Then we will work to upgrade urpmi to get the best from last rpm enhancements... and later we'll work to to add whistles and bells and performance improvements if everything goes well.

Stay tuned but do not expect a lightning fast result as i dont know yet how much time i'll need to learn urpm* internals.

Kind regards,

Status: NEW => ASSIGNED

Maat, thank you for taking it on, we understand it is complicated :)

(In reply to Rolf Pedersen from comment #8)
> (In reply to Neal Gompa from comment #6)
> Ok, Mr. Gompa.  I said you were hard-working. ;)
> 
> Notably, urpmq and urpmf are tools the equivalents of which I consistently
> fail to find when auditing other package managers.
> 
> I will steer my energies toward learning what it is you and the development
> community are developing for Mageia and, as needed, utilize what are, to me,
> the formidable query tools of urpm.
> 
> Thanks for broadening my perspective.

The equivalent in DNF is "dnf repoquery"[1]. It contains all the equivalent functionality. For simpler cases, you can use "dnf search"[2] and "dnf provides"[3].

[1]: https://dnf.readthedocs.io/en/latest/command_ref.html#repoquery-command-label
[2]: https://dnf.readthedocs.io/en/latest/command_ref.html#search-command
[3]: https://dnf.readthedocs.io/en/latest/command_ref.html#provides-command

(In reply to Nicolas Lécureuil from comment #9)
> Please NEAL don't take bugs and modify names as you want.
> 
> 
> Maat have started to look to add back urpmi support. This but will speak
> about this.

You're the one who changed the original ticket. I was reverting it back to what the original ask was (make it so that information is synchronized and respected).

when you criticize, please do it cleverly :-)

This is Aurelien that renamed the bug.

(In reply to Nicolas Lécureuil from comment #16)
> when you criticize, please do it cleverly :-)
> 
> This is Aurelien that renamed the bug.

Original BR has:
>  Discover doesn't respect skip.lst

I renamed it to:
> Restore urpmi plugin for PackageKit to make Plasma Discover respects skip.lst

Because urpmi was named there, not DNF.

But both you are right:
the sooner we get urpmi supports appstream and has a good PackageKit backend, AND libDNF is able to synchronise his settings with urpmi onnMageia, the better we are, this will many issues.

We can have *both* in a win-win experience. Users used to urpmi will have it and so do users of DNF.

Now, as soon as work done on one package manager will be done, this BR can be closed. We can also clone this BR to track libDNF support for urpmi settings.

(In reply to Aurelien Oudelet from comment #17)
> (In reply to Nicolas Lécureuil from comment #16)
> > when you criticize, please do it cleverly :-)
> > 
> > This is Aurelien that renamed the bug.
> 
> Original BR has:
> >  Discover doesn't respect skip.lst
> 
> I renamed it to:
> > Restore urpmi plugin for PackageKit to make Plasma Discover respects skip.lst
> 
> Because urpmi was named there, not DNF.

Yes as you are in the bugtriage team, i think you did it right.