guix-devel
[Top][All Lists]
Advanced

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

Re: 01/01: gnu: vlc: Update to 2.2.0


From: Ludovic Courtès
Subject: Re: 01/01: gnu: vlc: Update to 2.2.0
Date: Sun, 15 Mar 2015 14:41:07 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux)

"Jason Self" <address@hidden> skribis:

> Ludovic Courtès said;
>> Right.  The version has to be chosen carefully (should be a LTS 
>> version and one that is likely to remain on fsfla.org and/or that we
>> mirror on alpha.gnu.org), plus we don’t want glibc’s requirement to
>> be too high so people can use Guix on GNU/Linux with relatively old
>> kernels.
>
> If using an LTS version is desired, support for the 3.3 series ended
> almost three years ago. The 3.4 series is supported until September
> 2016. I seem to recall a discussion about a separation of roles though
> where, even though there may be some overlap, the intent of GSRC was
> to be something people installed on an existing distro and that the
> intent of Guix was to be completely independent and standalone. Given
> that, how much effort do we want to put in to maintaining that
> overlap?

I think we want to Guix to be usable on distros other than GuixSD for
the foreseeable future.  It doesn’t cost us much in terms of
maintenance, and it’s definitely helpful for those not willing/able to
switch to GuixSD.

I don’t this there’s much overlap with GSRC here anyway.

> Anyway, Debian seems sufficently slow moving to me and so I looked at
> that to get an idea of what might be acceptable. They have 3.5 in
> Wheezy and are jumping to 3.16 for Jessie which I understand is due
> soon? Given that, what about using 3.14? It is much newer and
> supported until August 2016 [0].

The real problem is that our libc must be able to work kernels typically
found out there in the wild, which may be older than this.  Thus, 3.14
may be a bit too recent.

Now, I think libc’s --enable-kernel can specify a baseline older than
the available kernel headers.  So it may be that we can use 3.14 headers
but build a libc that assumes a kernel possibly as old as 3.4.

Then again, one should look at kernel-features.h to see what features we
miss out by using, say, 3.4 instead of 3.14 (I expect there are few.)

Would you like to look at these aspects more closely?

Thanks,
Ludo’.



reply via email to

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