Re: Superseded packages

[Ludovic Courtès]

Hello!

Leo Famulari <address@hidden> skribis:

> On Tue, Sep 06, 2016 at 11:36:32PM +0200, Ludovic Courtès wrote:
>> Hi!
>> 
>> address@hidden (Ludovic Courtès) skribis:
>> 
>> > I had an idea to use a ‘superseded’ entry in ‘properties’ that would
>> > tell ‘guix package’ et al. to upgrade to the new package:
>> >
>> >   (package
>> >     (name "attic")
>> >     ;; …
>> >     (properties `((superseded . ,borg))))
>> 
>> This is now implemented both at the package lookup level and in ‘guix
>> package -u’ (the code is in 01afdab89c6a91f4cd05d3c4f4ff95a0402703eb and
>> an example is in 967cfd18f666f24ae9cbad14ea8e6921c10cba81):
>
> This is nice :)
>
> In 56ab55d1df I used it to properly replace the old letsencrypt package
> with certbot.
>
> In this case, I had already made letsencrypt inherit from certbot some
> months ago. I wanted letsencrypt users to get the latest version of the
> software from the EFF team, and presumably users have since fixed the
> breakage caused by the executable name change. Now, their profiles will
> finally stop including a letsencrypt package as they upgrade, and I plan
> to remove the letsencrypt variable completely after a couple more
> certbot releases.
>
> I think using this mechanism is appropriate in this case because
> letsencrypt / certbot are from the same team. Basically it's the same
> software, with 's/letsencrypt/certbot/g' applied to the codebase.

This is definitely the target use case.

> I'm not sure about Attic / Borg. Superseding attic will break
> automation, although I did that when I made letsencrypt inherit from
> certbot. Also, the authors are different. Advice?

I would make Borg supersede Attic.  However, if Borg does not provide,
say, an ‘attic’ command, which would make it incompatible by default, we
may want to change the Borg package to include such a command.

WDYT?

Ludo’.