guix-devel
[Top][All Lists]
Advanced

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

Re: On the quest for a new release model


From: Tomas Volf
Subject: Re: On the quest for a new release model
Date: Sat, 14 Dec 2024 13:26:35 +0100
User-agent: Gnus/5.13 (Gnus v5.13)

Suhail Singh <suhailsingh247@gmail.com> writes:

> Tomas Volf <~@wolfsden.cz> writes:
>
>> I would like to point out that there is more work involved than just
>> splitting it into separate channels and adding those into
>> %default-channels.
>
> Could you please elaborate?  Or were these the two points you noted
> below?

Yes, I have meant that the various issues would need to be fixed or
figured out.

>
>> While multiple channels do work well with guix pull, there are annoying
>> limitations when used in other places.
>
> Could you please share some references for this?

Definitely.  I personally have run into these two issues:

#74396
  When you install system-wide guix with multiple channels, it shadows
  channels from your guix-pulled guix (except for 'guix channel).  That
  was unpleasant surprise.

guix-for-channels does not cache
  `guix-for-channels' procedure is a way how to produce a guix package
  for a channel list.  However it does not cache the computation, so it
  is extremely slow when actually used.  I wrote a bit about that here:
  https://wolfsden.cz/blog/post/what-goes-into-guix-shaped-hole.html .

I am not sure if there are more, but my impression is that using
multiple channels (outside of guix-pull) is not well explored territory,
so I would not be surprised.

>
>> Also you would need some way to specify what channel commits are able to
>> work together version-wise.
>
> Let's say we have two channels in the future: $guix-slim and
> $guix-extras.  Wouldn't it be sufficient for $guix-extras to depend on
> $guix-slim ?  If not, could you please elaborate?

You say depend on guix-slim, but on *what* commit from guix-slim?  You
can pin channels.  What happens when you pin guix-slim, but pull
guix-extras?  I believe some human readable error should be given, not a
failure to build something due to, for example, not having the required
version of gcc now (for example because guix-extras increased the
required version).

Also what about substitutes?  Which combinations of commits will have
substitutes built?

I just feel there is a lot to figure out with this proposal.

Have a nice day,
Tomas

-- 
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.

Attachment: signature.asc
Description: PGP signature


reply via email to

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