On Wed, 2016-09-21 at 23:28 -0400, Eli Schwartz wrote:
On 09/21/2016 05:56 AM, Gordian Edenhofer wrote:
You bar for insanity is whether the debian folks do it? Please explain yourself why do you think this is the wrong approach for the problem. My reasoning would be that packaging a dummy package would result in the same 'renamed' package on the system but would require the package maintainer to take action.
Well, I can usually count on them to be over-engineered.
But in all seriousness, then. :) Building in to the package manager, a capacity for retroactively modifying the definition of a specific package, seems to me to be a clear case of over-engineering. And just a bad idea in principle.
If you want to do that, it is because you are already doing *something* wrong.
I wouldn't assume that the user has done anything wrong, rather something with the system is wrong if one feels the need to 'backup' packages.
Because, you should not have to change your mind about what these particular files actually are, and start calling them something else on
Since one is intending to backup a package one should be highly aware of the purpose of the package.
a whim. Particularly as it disappears from the repositories, stops being trusted as signed by a central authority (the TUs), cannot be reinstalled...
The provide field makes sure that it is still treated the same. But to allow backups for all packages, the user has to live with them not being signed-off.
Btw. my Arch system is rock solid and I am not especially interested in dummy packages on my system but for those who need it it can be a huge difference. Therefore it makes sense to give those specific user base the ability to do so on their own. It wouldn't even be a dangerous operation since by adding a provide field one should be unable to brick the system. However I admit that it would require some additions to pacman which is obviously an argument against this but the way packages are treated would stay the same. Currently I don't see a reason why one should change the way of packaging just to circumvent the underlying problem.
I am a bit confused as to what this all means...
Do you prefer dummy packages which pull in versioned kernels and depend on changing the packaging (for that specific package)? Or do you prefer additions to pacman while "treating the packages the same"?
I dislike dummy packages and therefore would keep the current way of creating e.g. the linux package. If using dummy packages the main question becomes where to draw the line. You are currently referring to linux as "for that specific package" but what if users need different versions for another package... The system of everyone else would become more and more cluttered with dummy packages.
I think we may have a drastically different idea of what constitutes "circumventing the underlying problem". To be specific, we both seem to think the other is the one circumventing the underlying problem.
That's true :D