[pacman-dev] Versioned packages

[Gordian Edenhofer]

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
-------------- 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/20160922/f262b603/attachment.asc>