[pacman-dev] Versioned packages

[Eli Schwartz]

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.
Because, you should not have to change your mind about what these
particular files actually are, and start calling them something else on
a whim. Particularly as it disappears from the repositories, stops being
trusted as signed by a central authority (the TUs), cannot be reinstalled...

> 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 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.

-- 
Eli Schwartz