From mboxrd@z Thu Jan  1 00:00:00 1970
From: Ricardo Wurmus <rekado@elephly.net>
Subject: Re: [PATCH] gnu: Add glibc-locales variants for older versions of
	glibc.
Date: Sun, 20 Jan 2019 20:54:52 +0100
Message-ID: <87o98bdrzn.fsf@elephly.net>
References: <20190117131753.15696-1-rekado@elephly.net>
	<87a7jzh0yy.fsf@elephly.net> <87tvi4p84x.fsf@gnu.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Return-path: <guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org>
Received: from eggs.gnu.org ([209.51.188.92]:56119)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <rekado@elephly.net>) id 1glJBR-0007pt-L3
	for guix-devel@gnu.org; Sun, 20 Jan 2019 14:55:06 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <rekado@elephly.net>) id 1glJBQ-0001Gt-VP
	for guix-devel@gnu.org; Sun, 20 Jan 2019 14:55:05 -0500
In-reply-to: <87tvi4p84x.fsf@gnu.org>
List-Id: "Development of GNU Guix and the GNU System distribution."
	<guix-devel.gnu.org>
List-Unsubscribe: <https://lists.gnu.org/mailman/options/guix-devel>,
	<mailto:guix-devel-request@gnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/archive/html/guix-devel/>
List-Post: <mailto:guix-devel@gnu.org>
List-Help: <mailto:guix-devel-request@gnu.org?subject=help>
List-Subscribe: <https://lists.gnu.org/mailman/listinfo/guix-devel>,
	<mailto:guix-devel-request@gnu.org?subject=subscribe>
Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org
Sender: "Guix-devel" <guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org>
To: Ludovic =?utf-8?Q?Court=C3=A8s?= <ludo@gnu.org>
Cc: guix-devel@gnu.org


Hi Ludo,

>> * gnu/packages/base.scm (make-glibc-locales, make-glibc-utf8-locales): N=
ew
>> procedures.
>> (glibc-locales): Express in terms of make-glibc-locales.
>> (glibc-utf8-locales): Express in terms of make-glibc-utf8-locales.
>> (glibc-locales-2.27, glibc-utf8-locales-2.27): New variables.

[=E2=80=A6]

> I don=E2=80=99t like the package name trick, but I don=E2=80=99t have a b=
etter solution.
> Perhaps we could have a special property to explicitly allow for several
> versions of this package in the same profile (say
> =E2=80=98allow-multiple-versions?=E2=80=99), but that=E2=80=99s a bit mor=
e work.

I also don=E2=80=99t like to work around this by changing the package names=
.  I
thought of allowing multiple versions via property, but it=E2=80=99s not cl=
ear
how it should behave.  I=E2=80=99d want to have only major versions appear =
as
non-conflicting and still prevent the installation of variants of the
same version.

The next question then is if the property should be a procedure that
takes the current and the potentially conflicting package as arguments
and decides whether they are conflicting, or if this should be handled
centrally when the property is present.

--
Ricardo