[pacman-dev] Versioned packages

Gordian Edenhofer gordian.edenhofer at gmail.com
Wed Sep 21 09:56:06 UTC 2016


On Tue, 2016-09-20 at 21:41 -0400, Eli Schwartz wrote:
> On 09/19/2016 11:49 AM, Gordian Edenhofer wrote:
> > 
> > What about adding a new option to pacman's '-D, --database'
> > operator
> > which would enable users to rename packages and add a corresponding
> > provide field. This would empower everyone to decide on their own
> > which
> > packages they want in different versions and which they don't want.
> > Pacman would handle file conflicts as usual without introducing a
> > new
> > kind of packages. Plus it would avoid discussions about which
> > package
> > should be a dummy package and which shouldn't be.
> 
> Was that meant to be some sort of a joke? Because even Debian is not
> that insane, AFAIK.

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.
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: This is a digitally signed message part
URL: <https://lists.archlinux.org/pipermail/pacman-dev/attachments/20160921/b35c1bdd/attachment.asc>


More information about the pacman-dev mailing list