guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Packages for old Emacs versions


From: Philip Kaludercic
Subject: Re: Packages for old Emacs versions
Date: Wed, 16 Mar 2022 16:08:42 +0000

Ludovic Courtès <ludo@gnu.org> writes:

> Hi,
>
> Philip Kaludercic <philipk@posteo.net> skribis:
>
>> Thiago Jung Bauermann <bauermann@kolabnow.com> writes:
>>
>>>> My fear is that with further upstream development,
>>>> there might be conflicts between the packages I inherit from (emacs,
>>>> emacs-no-x, emacs-minimal) and the packages I have definined in [1].
>>>> An easy fix might be to not rely on the upstream package definitions,
>>>> but I am not certain if there are any down-sides I haven't considered.
>>>>
>>>> Of course, if the Guix project isn't interested in providing old
>>>> versions of packages, then I will continue look into maintaining my own
>>>> channel.
>>>
>>> I don’t have much experience with the Guix projects and its preferences
>>> and practices, so I can’t tell if it would be interested or not,
>>> unfortunately. I just wanted to mention that if not, another upstreaming
>>> option could be the Guix-Past channel:
>>>
>>> https://gitlab.inria.fr/guix-hpc/guix-past
>>
>> While interesting, this appears to be a closed project, so I am
>> uncertain how I could contribute my package definitions upstream.
>
> Contributions to Guix-Past are open to anyone.  Unfortunately, creating
> an account on gitlab.inria.fr is pretty tedious (essentially you need to
> put me as your “mentor” when applying for an account), in addition to
> being annoying in the first place.
>
> I think we could consider moving it to a more convenient place, be it
> sr.ht, notabug.org, or even Savannah (in which case we’d use the same
> workflow as with the rest of Guix).
>
> Thoughts?

Personally I would prefer an anything that doesn't use the GitHub-esque
"Pull Request" mechanism, and I guess as long as it is all Free
Software, Savannah should do the job.

>> Would it be unconventional for me to try and set up my own repository?
>
> No, of course not.  It’s better if we can team up IMO, but if
> maintaining your own repo works better for you, that’s okay.

I would certainly appreciate it, having run into a number of issues and
being frequently confused while writing the package definitions I had
linked above.

> Thanks,
> Ludo’.

-- 
        Philip Kaludercic



reply via email to

[Prev in Thread] Current Thread [Next in Thread]