Re: Pros and cons of Emacs package management through Guix instead of package.el

[Catonano <catonano@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1881 bytes --]

2018-04-03 7:17 GMT+02:00 Pierre Neidhardt <ambrevar@gmail.com>:

>
> I am thinking of using Guix to manage all my Emacs packages.  I can
> think of several benefits:
>
> - Guix provides (possibly) more stable versions.
>
> - Guix can update all packages without hanging Emacs.
>
> - Guix can update all packages from the commandline, i.e. it can be
> scripted.
>
> - Guix can rollback Emacs packages.  Emacs package updates and system
>   program updates can belong to the same transaction: this enforces the
>   integrity of the software stack at the user level.
>
> - Guix allows for sharing package files among several users on a
> multi-user system.
>
> And possible downsides:
>
> - package.el provides more up-to-date packages through MELPA but if we
>   really want to be more cutting edge (i.e. for development), we are
>   usually better off cloning the repository anyway.
>
> - Guix is basically duplicating the effort of (M)ELPA.
>
> What's your take on this?
>
>

I had a oghh time in packaging python-genshi

Genshi is an abandoned package, I copied the solution fom Fedora. A few
patches, some from the Genshi repository, submitted as solutions to issues
but not released yet (they will never be released because Genshi was dead,
last time I checked)

And maybe also a patch produced by Fedora on its own

Genshi was required as a dependency of Tryton (Tryton has a ticket about
how to substitute Genshi)

So yes, i replicated some work already done by other distros

But what else would you do ?

If you come up with a new packaging system you will need packages

One mitigation is that you can import melpa packages so replicating
shouldn't be that hard

When the world will migrate to functional package management and 20
somethings won't know what .deb and .rmp are, then we won't need to
reproduce wor already done by "imperative" based distros

That's my take

[-- Attachment #2: Type: text/html, Size: 2579 bytes --]