From mboxrd@z Thu Jan 1 00:00:00 1970 From: Catonano Subject: Re: Pros and cons of Emacs package management through Guix instead of package.el Date: Tue, 3 Apr 2018 13:33:58 +0200 Message-ID: References: <87efjwdg2f.fsf@gmail.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="001a114e4f2e1ce3e50568f015e8" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:49438) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f3KCP-00046x-KR for help-guix@gnu.org; Tue, 03 Apr 2018 07:34:02 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1f3KCO-0002EL-Da for help-guix@gnu.org; Tue, 03 Apr 2018 07:34:01 -0400 Received: from mail-yw0-x231.google.com ([2607:f8b0:4002:c05::231]:41670) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1f3KCO-0002E3-7m for help-guix@gnu.org; Tue, 03 Apr 2018 07:34:00 -0400 Received: by mail-yw0-x231.google.com with SMTP id u15so6004066ywg.8 for ; Tue, 03 Apr 2018 04:34:00 -0700 (PDT) In-Reply-To: <87efjwdg2f.fsf@gmail.com> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-guix-bounces+gcggh-help-guix=m.gmane.org@gnu.org Sender: "Help-Guix" To: Pierre Neidhardt Cc: help-guix --001a114e4f2e1ce3e50568f015e8 Content-Type: text/plain; charset="UTF-8" 2018-04-03 7:17 GMT+02:00 Pierre Neidhardt : > > 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 --001a114e4f2e1ce3e50568f015e8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


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.=C2=A0 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 scripte= d.

- Guix can rollback Emacs packages.=C2=A0 Emacs package updates and system<= br> =C2=A0 program updates can belong to the same transaction: this enforces th= e
=C2=A0 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
=C2=A0 really want to be more cutting edge (i.e. for development), we are =C2=A0 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 Fe= dora. A few patches, some from the Genshi repository, submitted as solution= s to issues but not released yet (they will never be released because Gensh= i was dead, last time I checked)

And maybe als= o a patch produced by Fedora on its own

Genshi was requir= ed as a dependency of Tryton (Tryton has a ticket about how to substitute G= enshi)

So yes, i replicated some work already done by oth= er distros

But what else would you do ?
If you come up with a new packaging system you will need packag= es

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 w= on't know what .deb and .rmp are, then we won't need to reproduce w= or already done by "imperative" based distros

<= /div>
That's my take
--001a114e4f2e1ce3e50568f015e8--