Re: [arch-general] [arch-dev-public] RFC: Forbid dummy packages from AUR
El jue, 24 mar 2022 a las 8:14, Allan McRae via arch-dev-public (<arch-dev-public@lists.archlinux.org>) escribió:
On 24/3/22 11:07, Brett Cornwall via arch-dev-public wrote:
Summary: Reject AUR packages that fulfill package dependencies without providing the files/binaries of the package in question.
But why? I don't quite understand why this should be banned. IMHO I think it is something very interesting and also, as described in the RFC, has a clear and justified use. It would be different if there was a way to tell Pacman by configuration to assume that these dependencies are covered, but as far as I know it is not possible. And while it is true that you can pass the `--assume-installed` option to it, but that must always be done at run time and if you have a high number of dummy dependencies it can be messy. Greetings -- Óscar García Amor | ogarcia at moire.org | http://ogarcia.me
On 24/03/2022 07:39, Óscar García Amor via arch-general wrote:
But why?
I don't quite understand why this should be banned.
It's essentially the equivalent of installing a package then -Rdd a dependency. Would that process be encouraged in other situations?
as described in the RFC, has a clear and justified use.
If you're referring to the shim package, there's a difference between a "pure" dummy package that has no content and only meets a dependency, and a shim package that implements functionality in a different way.
if you have a high number of dummy dependencies it can be messy.
What sort of situations are there where you would have a large number of dummy packages? And as a follow-up, why is that situation acceptable? J
El jue, 24 mar 2022 a las 12:54, Jonathon Fernyhough via arch-general (<arch-general@lists.archlinux.org>) escribió:
On 24/03/2022 07:39, Óscar García Amor via arch-general wrote:
But why?
I don't quite understand why this should be banned.
It's essentially the equivalent of installing a package then -Rdd a dependency. Would that process be encouraged in other situations?
Not exactly, it depends on the package. There are packages that create users and do not remove them after uninstallation, so not all packages have a 100% clean uninstallation (not counting the impact on the disk, fragmentation...).
as described in the RFC, has a clear and justified use.
If you're referring to the shim package, there's a difference between a "pure" dummy package that has no content and only meets a dependency, and a shim package that implements functionality in a different way.
I believe that both cases are justified. At least as long as there is no entry in the pacman configuration that allows to assume that certain packages are already installed.
if you have a high number of dummy dependencies it can be messy.
What sort of situations are there where you would have a large number of dummy packages? And as a follow-up, why is that situation acceptable?
In my personal case, I have to use `--assume-installed` with subversion and mercurial because they are dependencies of devtools although they are not really necessary if you don't use that kind of repositories. But of course, this is my personal case, I understand that there may be other cases in which there are people who may have more packages in this situation. Greetings -- Óscar García Amor | ogarcia at moire.org | http://ogarcia.me
On 22-03-24 13:14, Óscar García Amor via arch-general wrote:
El jue, 24 mar 2022 a las 12:54, Jonathon Fernyhough via arch-general (<arch-general@lists.archlinux.org>) escribió:
On 24/03/2022 07:39, Óscar García Amor via arch-general wrote:
But why?
I don't quite understand why this should be banned.
It's essentially the equivalent of installing a package then -Rdd a dependency. Would that process be encouraged in other situations?
Not exactly, it depends on the package. There are packages that create users and do not remove them after uninstallation, so not all packages have a 100% clean uninstallation (not counting the impact on the disk, fragmentation...).
If I remember correctly, the reason we don't remove users/groups on uninstall is due to security reasons. It is self-explanatory why package log/state dirs are not removed. And I don't think fragmentation has been an issue since 1999. The impact on the disk is negligible, let's be honest. -- George Rawlinson
participants (3)
-
George Rawlinson
-
Jonathon Fernyhough
-
Óscar García Amor