* Re: Different versions of a package in the same profile?
@ 2014-11-02 18:52 Federico Beffa
2014-11-03 8:58 ` Ludovic Courtès
0 siblings, 1 reply; 6+ messages in thread
From: Federico Beffa @ 2014-11-02 18:52 UTC (permalink / raw)
To: andreas, Guix-devel, Ludovic Courtès
Andreas Enge <andreas@enge.fr> writes:
> On Sun, Nov 02, 2014 at 06:22:28PM +0100, Ludovic Courtès wrote:
> There is also the question of conflicts with identical file names. They are
> already there now, but their probability should be higher with identical
> package names. Maybe we need to rethink the handling of conflicts also.
In the past I did use the packaging system called SEPP
http://oss.oetiker.ch/op-sepp/
It allow installing several versions of a program on a single system.
The way they use to avoid naming conflicts it to systematically add a
suffix to binary names, with the suffix corresponding to the version of
the package. They even went one step further and they added a suffix
with the initials of the administrator who packaged the application.
Each program was available with several names. For program foo:
- foo
- foo-1.2.3
- foo-1.2.3-fb
Obviously if more foo versions were installed, only one would be
referred to by foo. The others were available with versioned names.
As a user, the system did work very well.
To handle updating, specifying foo should update the version owning
the name foo. To update another version one would give the versioned
name "foo-1.2.3".
Regards,
Fede
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Different versions of a package in the same profile?
2014-11-02 18:52 Different versions of a package in the same profile? Federico Beffa
@ 2014-11-03 8:58 ` Ludovic Courtès
0 siblings, 0 replies; 6+ messages in thread
From: Ludovic Courtès @ 2014-11-03 8:58 UTC (permalink / raw)
To: Federico Beffa; +Cc: Guix-devel
Federico Beffa <beffa@ieee.org> skribis:
> Andreas Enge <andreas@enge.fr> writes:
>
>> On Sun, Nov 02, 2014 at 06:22:28PM +0100, Ludovic Courtès wrote:
>> There is also the question of conflicts with identical file names. They are
>> already there now, but their probability should be higher with identical
>> package names. Maybe we need to rethink the handling of conflicts also.
>
> In the past I did use the packaging system called SEPP
>
> http://oss.oetiker.ch/op-sepp/
Interesting.
> It allow installing several versions of a program on a single system.
> The way they use to avoid naming conflicts it to systematically add a
> suffix to binary names, with the suffix corresponding to the version of
> the package. They even went one step further and they added a suffix
> with the initials of the administrator who packaged the application.
>
> Each program was available with several names. For program foo:
> - foo
> - foo-1.2.3
> - foo-1.2.3-fb
> Obviously if more foo versions were installed, only one would be
> referred to by foo. The others were available with versioned names.
>
> As a user, the system did work very well.
>
> To handle updating, specifying foo should update the version owning
> the name foo.
OK, this is a strategy similar to what Andreas was suggesting.
> To update another version one would give the versioned name
> "foo-1.2.3".
I see.
Ludo’.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Problems with downloading from https
@ 2014-10-27 12:24 Ludovic Courtès
2014-10-27 13:27 ` Alex Kost
0 siblings, 1 reply; 6+ messages in thread
From: Ludovic Courtès @ 2014-10-27 12:24 UTC (permalink / raw)
To: Mark H Weaver; +Cc: guix-devel, Alex Kost
Mark H Weaver <mhw@netris.org> skribis:
> ludo@gnu.org (Ludovic Courtès) writes:
>
>> Alex Kost <alezost@gmail.com> skribis:
>>
>>> Ludovic Courtès (2014-10-26 16:46 +0300) wrote:
>>>
>>>> Alex Kost <alezost@gmail.com> skribis:
>>>>
>>>>> Yes, I installed gnutls, but it didn't work because I didn't set the
>>>>> right guile paths: “guix package --search-paths” recommends
>>>>> "/usr/local/var/guix/profiles/per-user/<user>/guix-profile/share/guile/site/2.0"
>>>>> but "gnutls.scm" is actually placed in
>>>>> "/usr/local/var/guix/profiles/per-user/<user>/guix-profile/share/guile/site"
>>>>> so ‘(use-modules (gnutls))’ failed for me.
>>>>
>>>> Oh, that’s a bug of the GnuTLS package: we should pass the right
>>>> configure flag so that modules go to site/2.0. Could you do that?
>
> Alex committed this change, and it broke all https downloads in Guix,
> leading to hydra build failures. For example, see:
>
> http://hydra.gnu.org/build/132928/nixlog/1/raw
>
> The reason is that guix/download.scm contains this code:
>
> ;; Add GnuTLS to the inputs and to the load path.
> #~(eval-when (load expand eval)
> (set! %load-path
> (cons (string-append #$(gnutls-package)
> "/share/guile/site")
> %load-path)))
> #~#t)
Oops, my bad. I think this code should be changed to use site/2.0,
which is the standard search path specification.
> For now, I think we should revert this commit and discuss it further
> before proceeding.
I would just fix the above code to append (effective-version). WDYT?
>>> Yes, but I'm a little concerned. Should it really be so? What about
>>> guile-1.8; isn't it supposed to use gnutls module as well?
>>
>> 1.8 has long been deprecated, so let’s not worry about it.
>
> I think Alex was right to be concerned. We'll have the same problem
> when Guile 2.2 comes around, and then again for 2.4. I'm reluctant to
> hardcode "2.0" into the code above. Think about what it implies for
> GnuTLS in the future. Will they be expected to install their modules
> into site/2.0, site/2.2, site/2.4, etc? Do we really want to advocate
> this practice to projects that install Guile modules?
No, you’re right, of course. However, I tend to distinguish between the
immediate issue that calls for a fix, and the design issue that has to
be addressed, but is less pressing.
Currently, there are a couple of packages that hard-code site/2.0. They
should be changed to use:
(string-append "--with-site-dir=.../site/" (effective-version))
That doesn’t help with 1.8, though, because 1.8 uses /site. Perhaps a
fix would be to change 1.8 in Guix so that it uses a versioned site
directory like future versions do? Another option would be to ignore 1.8.
WDYT?
There may be similar problems with Python, Ruby, etc., although these
haven’t come up yet, I think. These can hopefully be addressed by
having their respective build system pass #:effective-version to the
build code. Thoughts?
Thanks,
Ludo’.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Problems with downloading from https
2014-10-27 12:24 Problems with downloading from https Ludovic Courtès
@ 2014-10-27 13:27 ` Alex Kost
2014-10-27 14:43 ` Mark H Weaver
0 siblings, 1 reply; 6+ messages in thread
From: Alex Kost @ 2014-10-27 13:27 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: guix-devel
Ludovic Courtès (2014-10-27 15:24 +0300) wrote:
> Mark H Weaver <mhw@netris.org> skribis:
>
>> ludo@gnu.org (Ludovic Courtès) writes:
>>
>>> Alex Kost <alezost@gmail.com> skribis:
>>>
>>>> Ludovic Courtès (2014-10-26 16:46 +0300) wrote:
>>>>
>>>>> Alex Kost <alezost@gmail.com> skribis:
>>>>>
>>>>>> Yes, I installed gnutls, but it didn't work because I didn't set the
>>>>>> right guile paths: “guix package --search-paths” recommends
>>>>>> "/usr/local/var/guix/profiles/per-user/<user>/guix-profile/share/guile/site/2.0"
>>>>>> but "gnutls.scm" is actually placed in
>>>>>> "/usr/local/var/guix/profiles/per-user/<user>/guix-profile/share/guile/site"
>>>>>> so ‘(use-modules (gnutls))’ failed for me.
>>>>>
>>>>> Oh, that’s a bug of the GnuTLS package: we should pass the right
>>>>> configure flag so that modules go to site/2.0. Could you do that?
>>
>> Alex committed this change, and it broke all https downloads in Guix,
>> leading to hydra build failures. For example, see:
>>
>> http://hydra.gnu.org/build/132928/nixlog/1/raw
>>
>> The reason is that guix/download.scm contains this code:
>>
>> ;; Add GnuTLS to the inputs and to the load path.
>> #~(eval-when (load expand eval)
>> (set! %load-path
>> (cons (string-append #$(gnutls-package)
>> "/share/guile/site")
>> %load-path)))
>> #~#t)
>
> Oops, my bad. I think this code should be changed to use site/2.0,
> which is the standard search path specification.
>
>> For now, I think we should revert this commit and discuss it further
>> before proceeding.
>
> I would just fix the above code to append (effective-version). WDYT?
>
>>>> Yes, but I'm a little concerned. Should it really be so? What about
>>>> guile-1.8; isn't it supposed to use gnutls module as well?
>>>
>>> 1.8 has long been deprecated, so let’s not worry about it.
>>
>> I think Alex was right to be concerned. We'll have the same problem
>> when Guile 2.2 comes around, and then again for 2.4. I'm reluctant to
>> hardcode "2.0" into the code above. Think about what it implies for
>> GnuTLS in the future. Will they be expected to install their modules
>> into site/2.0, site/2.2, site/2.4, etc? Do we really want to advocate
>> this practice to projects that install Guile modules?
>
> No, you’re right, of course. However, I tend to distinguish between the
> immediate issue that calls for a fix, and the design issue that has to
> be addressed, but is less pressing.
>
> Currently, there are a couple of packages that hard-code site/2.0. They
> should be changed to use:
>
> (string-append "--with-site-dir=.../site/" (effective-version))
>
> That doesn’t help with 1.8, though, because 1.8 uses /site. Perhaps a
> fix would be to change 1.8 in Guix so that it uses a versioned site
> directory like future versions do? Another option would be to ignore 1.8.
>
> WDYT?
>
> There may be similar problems with Python, Ruby, etc., although these
> haven’t come up yet, I think. These can hopefully be addressed by
> having their respective build system pass #:effective-version to the
> build code. Thoughts?
Why not just allow gnutls and other packages to install guile modules in
a site dir (without version) and to augment GUILE_LOAD_PATH with it as I
suggested at
<http://lists.gnu.org/archive/html/guix-devel/2014-10/msg00333.html>?
--
Alex
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Problems with downloading from https
2014-10-27 13:27 ` Alex Kost
@ 2014-10-27 14:43 ` Mark H Weaver
2014-10-27 16:24 ` Ludovic Courtès
0 siblings, 1 reply; 6+ messages in thread
From: Mark H Weaver @ 2014-10-27 14:43 UTC (permalink / raw)
To: Alex Kost; +Cc: guix-devel
Alex Kost <alezost@gmail.com> writes:
> Why not just allow gnutls and other packages to install guile modules in
> a site dir (without version) and to augment GUILE_LOAD_PATH with it as I
> suggested at
> <http://lists.gnu.org/archive/html/guix-devel/2014-10/msg00333.html>?
In my opinion, this is the right fix. There is plenty of Guile code
that works on both Guile 1.8 and Guile 2.0, so there's no need to put
Scheme modules in versioned directories. We provide 'cond-expand' when
it's really needed, after all.
Guile 2 puts both "site/2.0" and "site" in its load path by default,
which signals to developers that they can choose either location.
Furthermore, if changing the installation directory of the GnuTLS
modules broke Guix, there's a non-trivial possibility that we might
break something else.
Please, let's leave the GnuTLS modules where they are, and add "site" to
the search-path-specification, as Alex suggests.
What do you think?
Mark
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: Problems with downloading from https
2014-10-27 14:43 ` Mark H Weaver
@ 2014-10-27 16:24 ` Ludovic Courtès
2014-10-27 16:44 ` Alex Kost
0 siblings, 1 reply; 6+ messages in thread
From: Ludovic Courtès @ 2014-10-27 16:24 UTC (permalink / raw)
To: Mark H Weaver; +Cc: guix-devel, Alex Kost
Mark H Weaver <mhw@netris.org> skribis:
> Alex Kost <alezost@gmail.com> writes:
>
>> Why not just allow gnutls and other packages to install guile modules in
>> a site dir (without version) and to augment GUILE_LOAD_PATH with it as I
>> suggested at
>> <http://lists.gnu.org/archive/html/guix-devel/2014-10/msg00333.html>?
>
> In my opinion, this is the right fix. There is plenty of Guile code
> that works on both Guile 1.8 and Guile 2.0, so there's no need to put
> Scheme modules in versioned directories. We provide 'cond-expand' when
> it's really needed, after all.
A problem is that it would make it impossible to install the 1.8/2.1 and
the 2.0 version of something in the same profile.
Currently it’s possible to install both ‘python’ and ‘python2’ in the
same profile, as well as ‘python-foo’ and ‘python2-foo’.
With the addition of a --program-suffix configure flag, it would be
possible to do the same with Guile 1.8/2.0/2.1.
I think it’s a useful feature. WDYT?
> Furthermore, if changing the installation directory of the GnuTLS
> modules broke Guix, there's a non-trivial possibility that we might
> break something else.
Given that the search path spec for guile-2.0 has always been site/2.0,
I think this change is unlikely to break anything else. On the
contrary: this change brought GnuTLS in conformance with the other
Guile-using packages.
Thanks,
Ludo’.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Problems with downloading from https
2014-10-27 16:24 ` Ludovic Courtès
@ 2014-10-27 16:44 ` Alex Kost
2014-10-28 8:03 ` Ludovic Courtès
0 siblings, 1 reply; 6+ messages in thread
From: Alex Kost @ 2014-10-27 16:44 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: guix-devel
Ludovic Courtès (2014-10-27 19:24 +0300) wrote:
> Mark H Weaver <mhw@netris.org> skribis:
>
>> Alex Kost <alezost@gmail.com> writes:
>>
>>> Why not just allow gnutls and other packages to install guile modules in
>>> a site dir (without version) and to augment GUILE_LOAD_PATH with it as I
>>> suggested at
>>> <http://lists.gnu.org/archive/html/guix-devel/2014-10/msg00333.html>?
>>
>> In my opinion, this is the right fix. There is plenty of Guile code
>> that works on both Guile 1.8 and Guile 2.0, so there's no need to put
>> Scheme modules in versioned directories. We provide 'cond-expand' when
>> it's really needed, after all.
>
> A problem is that it would make it impossible to install the 1.8/2.1 and
> the 2.0 version of something in the same profile.
>
> Currently it’s possible to install both ‘python’ and ‘python2’ in the
> same profile, as well as ‘python-foo’ and ‘python2-foo’.
[...]
But currently it's not possible to install 2 (or more) packages with the
same name. So a user can't have guile 2.0 and guile 1.8 in the same
profile. The same thing with python: there is no ‘python2’ package.
Both python packages have “python” name and can't be installed in the
same profile, as far as I understand.
--
Alex
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Problems with downloading from https
2014-10-27 16:44 ` Alex Kost
@ 2014-10-28 8:03 ` Ludovic Courtès
2014-10-29 22:22 ` Andreas Enge
0 siblings, 1 reply; 6+ messages in thread
From: Ludovic Courtès @ 2014-10-28 8:03 UTC (permalink / raw)
To: Alex Kost; +Cc: guix-devel
Alex Kost <alezost@gmail.com> skribis:
> Ludovic Courtès (2014-10-27 19:24 +0300) wrote:
>
>> Mark H Weaver <mhw@netris.org> skribis:
>>
>>> Alex Kost <alezost@gmail.com> writes:
>>>
>>>> Why not just allow gnutls and other packages to install guile modules in
>>>> a site dir (without version) and to augment GUILE_LOAD_PATH with it as I
>>>> suggested at
>>>> <http://lists.gnu.org/archive/html/guix-devel/2014-10/msg00333.html>?
>>>
>>> In my opinion, this is the right fix. There is plenty of Guile code
>>> that works on both Guile 1.8 and Guile 2.0, so there's no need to put
>>> Scheme modules in versioned directories. We provide 'cond-expand' when
>>> it's really needed, after all.
>>
>> A problem is that it would make it impossible to install the 1.8/2.1 and
>> the 2.0 version of something in the same profile.
>>
>> Currently it’s possible to install both ‘python’ and ‘python2’ in the
>> same profile, as well as ‘python-foo’ and ‘python2-foo’.
>
> [...]
>
> But currently it's not possible to install 2 (or more) packages with the
> same name. So a user can't have guile 2.0 and guile 1.8 in the same
> profile. The same thing with python: there is no ‘python2’ package.
> Both python packages have “python” name and can't be installed in the
> same profile, as far as I understand.
Good point! (Somehow I thought there was ‘python2’.)
I don’t know if I’m in an over-engineering mindset or something ;-), but
I still feel keeping versioned directory is more flexible.
After all, parallel installability (info "(guile) Parallel
Installations") is initially intended to solve issues for FHS-style
systems. Guix has other ways to deal with that. But still, the same
kind of problems arise when mixing things in a Guix build environment or
profile.
Ludo’.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Problems with downloading from https
2014-10-28 8:03 ` Ludovic Courtès
@ 2014-10-29 22:22 ` Andreas Enge
2014-10-30 7:27 ` Alex Kost
0 siblings, 1 reply; 6+ messages in thread
From: Andreas Enge @ 2014-10-29 22:22 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: guix-devel, Alex Kost
On Tue, Oct 28, 2014 at 09:03:44AM +0100, Ludovic Courtès wrote:
> Alex Kost <alezost@gmail.com> skribis:
> > But currently it's not possible to install 2 (or more) packages with the
> > same name. So a user can't have guile 2.0 and guile 1.8 in the same
> > profile. The same thing with python: there is no ‘python2’ package.
> > Both python packages have “python” name and can't be installed in the
> > same profile, as far as I understand.
>
> Good point! (Somehow I thought there was ‘python2’.)
Is it really not possible to install two packages with the same name?
I thought you could do
guix package -i python python-2.7.6
where the first one will chose the latest package? It just requires that
there are no overlapping paths.
Andreas
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Problems with downloading from https
2014-10-29 22:22 ` Andreas Enge
@ 2014-10-30 7:27 ` Alex Kost
2014-10-30 7:49 ` Andreas Enge
0 siblings, 1 reply; 6+ messages in thread
From: Alex Kost @ 2014-10-30 7:27 UTC (permalink / raw)
To: Andreas Enge; +Cc: guix-devel
Andreas Enge (2014-10-30 01:22 +0300) wrote:
> On Tue, Oct 28, 2014 at 09:03:44AM +0100, Ludovic Courtès wrote:
>> Alex Kost <alezost@gmail.com> skribis:
>> > But currently it's not possible to install 2 (or more) packages with the
>> > same name. So a user can't have guile 2.0 and guile 1.8 in the same
>> > profile. The same thing with python: there is no ‘python2’ package.
>> > Both python packages have “python” name and can't be installed in the
>> > same profile, as far as I understand.
>>
>> Good point! (Somehow I thought there was ‘python2’.)
>
> Is it really not possible to install two packages with the same name?
> I thought you could do
> guix package -i python python-2.7.6
> where the first one will chose the latest package? It just requires that
> there are no overlapping paths.
I think such an "evil" case is just not handled currently. If you have
python-3… installed and you install python-2… in the same profile, then
python-3… would be replaced, but if you install both packages in the
same command, then both would be installed. It's OK for pythons,
because there are no name collisions in these packages, but if you try
to install both "guile-2.0.11" and "guile-1.8.8" is such a way, then you
will have several collisions.
So I think installing packages with the same name in one transaction
should also be prohibited.
As both python packages can co-exist in one profile, either python-2…
may be renamed into “python2” or python-3… into “python3”. As python3
is the future, I think it would be better to have “python2” and “python”
(which is python3) packages. Or maybe they shouldn't be renamed and we
can introduce a little collision instead by adding "…/bin/python"
symlink to python-3… package.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Problems with downloading from https
2014-10-30 7:27 ` Alex Kost
@ 2014-10-30 7:49 ` Andreas Enge
2014-10-30 12:31 ` Alex Kost
0 siblings, 1 reply; 6+ messages in thread
From: Andreas Enge @ 2014-10-30 7:49 UTC (permalink / raw)
To: Alex Kost; +Cc: guix-devel
On Thu, Oct 30, 2014 at 10:27:59AM +0300, Alex Kost wrote:
> I think such an "evil" case is just not handled currently. If you have
> python-3… installed and you install python-2… in the same profile, then
> python-3… would be replaced, but if you install both packages in the
> same command, then both would be installed.
Interesting, I did not know this, but you are right:
$ guix package -i python
$ guix package -i python-2.7.6
The following package will be upgraded:
python 3.3.5 → 2.7.6 /gnu/store/iz5shg4py68mbccv2kkd0siv6ryfl3y1-python-2.7.6
If you do instead
$ guix package -i python python-2.7.6
both packages are installed.
I think the former behaviour is a bug. If I use "-i" and not "-u", a package
should not be "upgraded", but added in every case, independently of its name.
Andreas
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Problems with downloading from https
2014-10-30 7:49 ` Andreas Enge
@ 2014-10-30 12:31 ` Alex Kost
2014-10-30 12:38 ` Andreas Enge
0 siblings, 1 reply; 6+ messages in thread
From: Alex Kost @ 2014-10-30 12:31 UTC (permalink / raw)
To: Andreas Enge; +Cc: guix-devel
Andreas Enge (2014-10-30 10:49 +0300) wrote:
> On Thu, Oct 30, 2014 at 10:27:59AM +0300, Alex Kost wrote:
>> I think such an "evil" case is just not handled currently. If you have
>> python-3… installed and you install python-2… in the same profile, then
>> python-3… would be replaced, but if you install both packages in the
>> same command, then both would be installed.
>
> Interesting, I did not know this, but you are right:
>
> $ guix package -i python
> $ guix package -i python-2.7.6
> The following package will be upgraded:
> python 3.3.5 → 2.7.6 /gnu/store/iz5shg4py68mbccv2kkd0siv6ryfl3y1-python-2.7.6
>
> If you do instead
> $ guix package -i python python-2.7.6
>
> both packages are installed.
>
> I think the former behaviour is a bug. If I use "-i" and not "-u", a package
> should not be "upgraded", but added in every case, independently of its name.
I think the latter is a bug. IMHO it shouldn't be possible to install
several packages with the same name in one profile.
--
Alex
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Problems with downloading from https
2014-10-30 12:31 ` Alex Kost
@ 2014-10-30 12:38 ` Andreas Enge
2014-10-30 23:07 ` Different versions of a package in the same profile? Ludovic Courtès
0 siblings, 1 reply; 6+ messages in thread
From: Andreas Enge @ 2014-10-30 12:38 UTC (permalink / raw)
To: Alex Kost; +Cc: guix-devel
On Thu, Oct 30, 2014 at 03:31:15PM +0300, Alex Kost wrote:
> I think the latter is a bug. IMHO it shouldn't be possible to install
> several packages with the same name in one profile.
Well, having python 2 and 3 is reasonable, and from what I saw in their
naming scheme, it is entirely possible (the python binary being renamed
to python 3). Qt 4 and 5 are, I think, another case. How about GTK+ 2 and 3?
Of course we could rename the packages, but this is not our policy so far.
Andreas
^ permalink raw reply [flat|nested] 6+ messages in thread
* Different versions of a package in the same profile?
2014-10-30 12:38 ` Andreas Enge
@ 2014-10-30 23:07 ` Ludovic Courtès
2014-11-01 10:46 ` Andreas Enge
0 siblings, 1 reply; 6+ messages in thread
From: Ludovic Courtès @ 2014-10-30 23:07 UTC (permalink / raw)
To: Andreas Enge; +Cc: guix-devel, Alex Kost
Andreas Enge <andreas@enge.fr> skribis:
> On Thu, Oct 30, 2014 at 03:31:15PM +0300, Alex Kost wrote:
>> I think the latter is a bug. IMHO it shouldn't be possible to install
>> several packages with the same name in one profile.
>
> Well, having python 2 and 3 is reasonable, and from what I saw in their
> naming scheme, it is entirely possible (the python binary being renamed
> to python 3). Qt 4 and 5 are, I think, another case. How about GTK+ 2 and 3?
Actually, Qt 4 and 5 use non-versioned file names under bin/.
Technically it would be easy to allow the installation of different
versions of a package in the same profile, but I wonder about the
implications.
For instance, ‘-u foo’ would upgrade all the installed versions of
‘foo’, so you would end up with exactly the same version twice.
Ludo’.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Different versions of a package in the same profile?
2014-10-30 23:07 ` Different versions of a package in the same profile? Ludovic Courtès
@ 2014-11-01 10:46 ` Andreas Enge
2014-11-02 17:22 ` Ludovic Courtès
0 siblings, 1 reply; 6+ messages in thread
From: Andreas Enge @ 2014-11-01 10:46 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: guix-devel, Alex Kost
On Fri, Oct 31, 2014 at 12:07:14AM +0100, Ludovic Courtès wrote:
> Technically it would be easy to allow the installation of different
> versions of a package in the same profile, but I wonder about the
> implications.
>
> For instance, ‘-u foo’ would upgrade all the installed versions of
> ‘foo’, so you would end up with exactly the same version twice.
Good catch (or rather "bad feature"?).
So should we indeed rename version 2 of the python package to python2, to
allow easy installation together with python version 3?
We could do the same for Qt, but if anyway versions 4 and 5 are not
installable together, there does not seem to be a need.
How about guile?
In any case, the outcome of installation should not depend on whether we
do them in one or in several commands.
Another idea: How about letting "guix package -u foo" upgrade only the
package with name foo and the latest version if there are several with the
same name?
Andreas
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Different versions of a package in the same profile?
2014-11-01 10:46 ` Andreas Enge
@ 2014-11-02 17:22 ` Ludovic Courtès
2014-11-02 17:39 ` Andreas Enge
0 siblings, 1 reply; 6+ messages in thread
From: Ludovic Courtès @ 2014-11-02 17:22 UTC (permalink / raw)
To: Andreas Enge; +Cc: guix-devel, Alex Kost
Andreas Enge <andreas@enge.fr> skribis:
> On Fri, Oct 31, 2014 at 12:07:14AM +0100, Ludovic Courtès wrote:
>> Technically it would be easy to allow the installation of different
>> versions of a package in the same profile, but I wonder about the
>> implications.
>>
>> For instance, ‘-u foo’ would upgrade all the installed versions of
>> ‘foo’, so you would end up with exactly the same version twice.
>
> Good catch (or rather "bad feature"?).
>
> So should we indeed rename version 2 of the python package to python2, to
> allow easy installation together with python version 3?
>
> We could do the same for Qt, but if anyway versions 4 and 5 are not
> installable together, there does not seem to be a need.
I don’t think so. In this thread, I rather wanted to discuss the
implications of allowing same-named packages to be installed in the same
profile, should we decide to go that route.
> In any case, the outcome of installation should not depend on whether we
> do them in one or in several commands.
Agreed.
> Another idea: How about letting "guix package -u foo" upgrade only the
> package with name foo and the latest version if there are several with the
> same name?
That’s a possibility, yes.
But I wonder if there are other issues beyond -u.
Ludo’.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Different versions of a package in the same profile?
2014-11-02 17:22 ` Ludovic Courtès
@ 2014-11-02 17:39 ` Andreas Enge
0 siblings, 0 replies; 6+ messages in thread
From: Andreas Enge @ 2014-11-02 17:39 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: guix-devel, Alex Kost
On Sun, Nov 02, 2014 at 06:22:28PM +0100, Ludovic Courtès wrote:
> I don’t think so. In this thread, I rather wanted to discuss the
> implications of allowing same-named packages to be installed in the same
> profile, should we decide to go that route.
>
> > Another idea: How about letting "guix package -u foo" upgrade only the
> > package with name foo and the latest version if there are several with the
> > same name?
> That’s a possibility, yes.
> But I wonder if there are other issues beyond -u.
Good question, I do not know. But if we allow several packages with the same
name in a profile, I do not see another possibility for "guix package -u"
than my suggestion.
There is also the question of conflicts with identical file names. They are
already there now, but their probability should be higher with identical
package names. Maybe we need to rethink the handling of conflicts also.
Andreas
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2014-11-03 8:58 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-11-02 18:52 Different versions of a package in the same profile? Federico Beffa
2014-11-03 8:58 ` Ludovic Courtès
-- strict thread matches above, loose matches on Subject: below --
2014-10-27 12:24 Problems with downloading from https Ludovic Courtès
2014-10-27 13:27 ` Alex Kost
2014-10-27 14:43 ` Mark H Weaver
2014-10-27 16:24 ` Ludovic Courtès
2014-10-27 16:44 ` Alex Kost
2014-10-28 8:03 ` Ludovic Courtès
2014-10-29 22:22 ` Andreas Enge
2014-10-30 7:27 ` Alex Kost
2014-10-30 7:49 ` Andreas Enge
2014-10-30 12:31 ` Alex Kost
2014-10-30 12:38 ` Andreas Enge
2014-10-30 23:07 ` Different versions of a package in the same profile? Ludovic Courtès
2014-11-01 10:46 ` Andreas Enge
2014-11-02 17:22 ` Ludovic Courtès
2014-11-02 17:39 ` Andreas Enge
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).