guile-2.0.11 installation on system with 2.0.5

guile-2.0.11 installation on system with 2.0.5

[Federico Beffa]

Hi,

I'm on Debian 7.6 with guile-2.0.5 installed. I would like to install
a newer version of guile. Therefore I downloaded 2.0.11 and installed
in /usr/local with

./configure
make
sudo make install

Everything appeared to be fine. However, with my surprise, when I
started the newly installed guile with

$ /usr/local/bin/guile

I was greeted with

GNU Guile 2.0.5-deb+1-3
Copyright (C) 1995-2012 Free Software Foundation, Inc.
...

which correspond to the version provided by the Debian package.

Am I doing something wrong? Is it possible to have two guile versions
on the same system?

Regards,
Fede

Re: guile-2.0.11 installation on system with 2.0.5

[Vernon Oberholzer]

[-- Attachment #1: Type: text/plain, Size: 1487 bytes --]

Hi Federico,
That is odd, on my Debian "wheezy" system, the debian packaged guile is a
symbolic link /usr/bin/guile to
/etc/alternatives/guile, which in turn is a symbolic link to
/usr/bin/guile-2.0 . What returns from the command "which guile" on your
system ?

The method I have tended to use, which may not be the ideal way, but works
for my purposes is
to create a dir, /usr/local/guile2 and then
./configure --prefix=/usr/local/guile2
make && make install

I like this method, as when further releases come out, for example 2.0.12,
I can simply create
another dir, for example, /usr/local/guile2012

I have geiser with emacs installed, so in my .emacs I have
(setq geiser-guile-binary "/usr/local/guile2/bin/guile")


Kind Regards,
Vernon Oberholzer


On Sat, Sep 13, 2014 at 12:52 PM, Federico Beffa <beffa@ieee.org> wrote:

> Hi,
>
> I'm on Debian 7.6 with guile-2.0.5 installed. I would like to install
> a newer version of guile. Therefore I downloaded 2.0.11 and installed
> in /usr/local with
>
> ./configure
> make
> sudo make install
>
> Everything appeared to be fine. However, with my surprise, when I
> started the newly installed guile with
>
> $ /usr/local/bin/guile
>
> I was greeted with
>
> GNU Guile 2.0.5-deb+1-3
> Copyright (C) 1995-2012 Free Software Foundation, Inc.
> ...
>
> which correspond to the version provided by the Debian package.
>
> Am I doing something wrong? Is it possible to have two guile versions
> on the same system?
>
> Regards,
> Fede
>
>

[-- Attachment #2: Type: text/html, Size: 2150 bytes --]

Re: guile-2.0.11 installation on system with 2.0.5

[Neil Jerram]

Federico Beffa <beffa@ieee.org> writes:

> Hi,
>
> I'm on Debian 7.6 with guile-2.0.5 installed. I would like to install
> a newer version of guile. Therefore I downloaded 2.0.11 and installed
> in /usr/local with
>
> ./configure
> make
> sudo make install
>
> Everything appeared to be fine. However, with my surprise, when I
> started the newly installed guile with
>
> $ /usr/local/bin/guile
>
> I was greeted with
>
> GNU Guile 2.0.5-deb+1-3
> Copyright (C) 1995-2012 Free Software Foundation, Inc.
> ...
>
> which correspond to the version provided by the Debian package.
>
> Am I doing something wrong? Is it possible to have two guile versions
> on the same system?

This is just a guess, but what happens if you do this:

$ LD_LIBRARY_PATH=/usr/local/lib /usr/local/bin/guile

Regards,
     Neil

Re: guile-2.0.11 installation on system with 2.0.5

[Ludovic Courtès]

Federico Beffa <beffa@ieee.org> skribis:

> Everything appeared to be fine. However, with my surprise, when I
> started the newly installed guile with
>
> $ /usr/local/bin/guile
>
> I was greeted with
>
> GNU Guile 2.0.5-deb+1-3
> Copyright (C) 1995-2012 Free Software Foundation, Inc.
> ...

It may be that, while /usr/local/bin/guile is indeed from the new
version, it ends up loading .scm and .go files from the old version.

You could check that by running:

  strace -o log /usr/local/bin/guile --version

and grepping for .scm and .go files in ‘log’.

That could happen, for instance, if there’s a GUILE_LOAD_PATH or
GUILE_LOAD_COMPILED_PATH environment variable pointing to
/usr/share/guile/...

> Am I doing something wrong? Is it possible to have two guile versions
> on the same system?

Yes.

Thanks,
Ludo’.

Re: guile-2.0.11 installation on system with 2.0.5

[Federico Beffa]

> Hi Federico,
> That is odd, on my Debian "wheezy" system, the debian packaged guile
> is a symbolic link /usr/bin/guile to
> /etc/alternatives/guile, which in turn is a symbolic link to
> /usr/bin/guile-2.0 . What returns from the command "which guile" on
> your system ?

With the locally installed guile 2.0.11 `which guile' reports
/usr/local/bin/guile. I've now uninstalled it (`make uninstall').

Without the local copy of guile I see the same as you: /usr/bin/guile is
a symbolic link to /etc/alternatives/guile which in turn is a symlink to
/usr/bin/guile-2.0.

Regards,
Fede

Re: guile-2.0.11 installation on system with 2.0.5

[Federico Beffa]

Neil Jerram <neil@ossau.homelinux.net> writes:

>
> This is just a guess, but what happens if you do this:
>
> $ LD_LIBRARY_PATH=/usr/local/lib /usr/local/bin/guile
>
> Regards,
>      Neil

With this it works!

I notice that there is an /etc/ld.so.cache file. Do I somehow need to update
it?

Thanks,
Fede

Re: guile-2.0.11 installation on system with 2.0.5

[mhw]

Federico Beffa <beffa@ieee.org> writes:

> Neil Jerram <neil@ossau.homelinux.net> writes:
>
>>
>> This is just a guess, but what happens if you do this:
>>
>> $ LD_LIBRARY_PATH=/usr/local/lib /usr/local/bin/guile
>>
>> Regards,
>>      Neil
>
> With this it works!
>
> I notice that there is an /etc/ld.so.cache file. Do I somehow need to update
> it?

Yes, you update it by running "ldconfig" as root.  This needs to be done
when installing libraries outside of your package manager, not only for
Guile, but for essentially all packages containing libraries.

      Mark

Re: guile-2.0.11 installation on system with 2.0.5

[Neil Jerram]

On 2014-09-15 02:16, mhw@netris.org wrote:
> Federico Beffa <beffa@ieee.org> writes:
> 
>> Neil Jerram <neil@ossau.homelinux.net> writes:
>> 
>>> 
>>> This is just a guess, but what happens if you do this:
>>> 
>>> $ LD_LIBRARY_PATH=/usr/local/lib /usr/local/bin/guile
>>> 
>>> Regards,
>>>      Neil
>> 
>> With this it works!
>> 
>> I notice that there is an /etc/ld.so.cache file. Do I somehow need to 
>> update
>> it?
> 
> Yes, you update it by running "ldconfig" as root.  This needs to be 
> done
> when installing libraries outside of your package manager, not only for
> Guile, but for essentially all packages containing libraries.

I agree that this will allow /usr/local/bin/guile to load 
/usr/local/lib/libguile*.

However, won't it also cause /usr/bin/guile (2.0.5) to load 
/usr/local/lib/libguile* (2.0.11) ?  If not, what is the mechanism that 
tells /usr/bin/guile (2.0.5) to load /usr/lib/libguile* (2.0.5) instead 
of /usr/local/lib/libguile* (2.0.11) ?

Thanks,
      Neil

Re: guile-2.0.11 installation on system with 2.0.5

[Federico Beffa]

On Mon, Sep 15, 2014 at 11:49 AM, Neil Jerram <neil@ossau.homelinux.net> wrote:
> On 2014-09-15 02:16, mhw@netris.org wrote:
>>
>> Federico Beffa <beffa@ieee.org> writes:
>>
>>> Neil Jerram <neil@ossau.homelinux.net> writes:
>>>
>>>>
>>>> This is just a guess, but what happens if you do this:
>>>>
>>>> $ LD_LIBRARY_PATH=/usr/local/lib /usr/local/bin/guile
>>>>
>>>> Regards,
>>>>      Neil
>>>
>>>
>>> With this it works!
>>>
>>> I notice that there is an /etc/ld.so.cache file. Do I somehow need to
>>> update
>>> it?
>>
>>
>> Yes, you update it by running "ldconfig" as root.  This needs to be done
>> when installing libraries outside of your package manager, not only for
>> Guile, but for essentially all packages containing libraries.
>
>
> I agree that this will allow /usr/local/bin/guile to load
> /usr/local/lib/libguile*.
>
> However, won't it also cause /usr/bin/guile (2.0.5) to load
> /usr/local/lib/libguile* (2.0.11) ?  If not, what is the mechanism that
> tells /usr/bin/guile (2.0.5) to load /usr/lib/libguile* (2.0.5) instead of
> /usr/local/lib/libguile* (2.0.11) ?
>
> Thanks,
>      Neil
>

yes, that's what I've found out by running ldconfig. Both versions now
show version 2.0.11 in the startup message.

Regards,
Fede

Re: guile-2.0.11 installation on system with 2.0.5

[Chris Vine]

On Mon, 15 Sep 2014 12:22:27 +0200
Federico Beffa <beffa@ieee.org> wrote:
> On Mon, Sep 15, 2014 at 11:49 AM, Neil Jerram
[snip]
> > However, won't it also cause /usr/bin/guile (2.0.5) to load
> > /usr/local/lib/libguile* (2.0.11) ?  If not, what is the mechanism
> > that tells /usr/bin/guile (2.0.5) to load /usr/lib/libguile*
> > (2.0.5) instead of /usr/local/lib/libguile* (2.0.11) ?
> >
> > Thanks,
> >      Neil
> >
> 
> yes, that's what I've found out by running ldconfig. Both versions now
> show version 2.0.11 in the startup message.

I would strongly advise you not to have two binary compatible versions
of any given library on your system at the same time, unless you really
know what you are doing.  Otherwise you are at the mercy of the look-up
order of the dynamic linker.  It is much better simply to upgrade your
system to guile-2.0.11 using your distribution's package manager. Since
guile maintains binary compatibility between micro versions, you should
be absolutely fine (and you can always back out if not).

However if you insist on doing what you are doing, see my separate
posting and use environmental variables to achieve what you want.

Chris

Re: guile-2.0.11 installation on system with 2.0.5

[Mark H Weaver]

Neil Jerram <neil@ossau.homelinux.net> writes:

> On 2014-09-15 02:16, mhw@netris.org wrote:
>> Federico Beffa <beffa@ieee.org> writes:
>>
>>> I notice that there is an /etc/ld.so.cache file. Do I somehow need
>>> to update
>>> it?
>>
>> Yes, you update it by running "ldconfig" as root.  This needs to be
>> done
>> when installing libraries outside of your package manager, not only for
>> Guile, but for essentially all packages containing libraries.
>
> I agree that this will allow /usr/local/bin/guile to load
> /usr/local/lib/libguile*.
>
> However, won't it also cause /usr/bin/guile (2.0.5) to load
> /usr/local/lib/libguile* (2.0.11) ?

True, but I don't see why anyone would want to run 2.0.5 anymore.  It
has lots of bugs and other problems that are fixed in 2.0.11, so that's
probably a good thing :)

> If not, what is the mechanism
> that tells /usr/bin/guile (2.0.5) to load /usr/lib/libguile* (2.0.5)
> instead of /usr/local/lib/libguile* (2.0.11) ?

This is not a guile-specific issue.  Any time you want to use two
different versions of the same shared library, you need to rely on some
other mechanism.

If you really want to preserve your ability to run the old buggy 2.0.5
libguile, then first of all you need to avoid installing 2.0.11 in a
directory that's in /etc/ld.so.conf (or /etc/ld.so.conf.d), because even
if you avoid running "ldconfig" yourself, your package manager will run
it the next time you install a library package.  So, you'd have to
install 2.0.11 to a different prefix.

Then you need a way for your new PREFIX/guile to find its shared library
in a non-standard place, and for that you'd best use rpaths.  See
<https://en.wikipedia.org/wiki/Rpath_%28linking%29>, but one way is to
make sure that LD_RUN_PATH is set to PREFIX/lib at the time that the
'guile' executable is linked.

Note that in GNU Guix <http://gnu.org/s/guix>, rpaths are always used
and this issue wouldn't have arisen.

     Regards,
       Mark

Re: guile-2.0.11 installation on system with 2.0.5

[Chris Vine]

On Sun, 14 Sep 2014 21:16:39 -0400
mhw@netris.org wrote:
> Federico Beffa <beffa@ieee.org> writes:
> 
> > Neil Jerram <neil@ossau.homelinux.net> writes:
> >
> >>
> >> This is just a guess, but what happens if you do this:
> >>
> >> $ LD_LIBRARY_PATH=/usr/local/lib /usr/local/bin/guile
> >>
> >> Regards,
> >>      Neil
> >
> > With this it works!
> >
> > I notice that there is an /etc/ld.so.cache file. Do I somehow need
> > to update it?
> 
> Yes, you update it by running "ldconfig" as root.  This needs to be
> done when installing libraries outside of your package manager, not
> only for Guile, but for essentially all packages containing libraries.

I would not recommend doing that where the OP has two _binary
compatible_ versions of the same library in different prefixes (as he
appears to have), otherwise the one which will be found and linked in
will depend on the dynamic linker's look-up order from
reading /etc/ld.so.conf.  This could be the old micro version where in
a given case the OP in fact wants the new one, or conversely the new
micro version where he in fact wants the old one.

Presumably in the general case he wants the micro version supplied by
the distribution's package manager to be linked in, otherwise he would
simply have replaced that one with the (binary compatible) newer
version of the same library.  Presumably also he wants the updated
version which he has installed to be linked in instead only when
specially called.  If that is right, he is much better off putting his
updated version in a directory which is _not_ specified
in /etc/ld.so.conf, and invoking it on the occasions when he does not
want the general case to apply by setting the LD_LIBRARY_PATH
environmental variable for that invocation.  Then he is guaranteed to
have the correct version loaded in.

Chris

Re: guile-2.0.11 installation on system with 2.0.5

[Federico Beffa]

ludo@gnu.org (Ludovic Courtès) writes:

> It may be that, while /usr/local/bin/guile is indeed from the new
> version, it ends up loading .scm and .go files from the old version.
>
> You could check that by running:
>
>   strace -o log /usr/local/bin/guile --version
>
> and grepping for .scm and .go files in ‘log’.
>
> That could happen, for instance, if there’s a GUILE_LOAD_PATH or
> GUILE_LOAD_COMPILED_PATH environment variable pointing to
> /usr/share/guile/...
>

Yes, that's what happens. I can see libraries from /usr/share and
/usr/lib/guile being used.

I do not have any GUILE_LOAD_* environment variable defined. However, I
see in the "log" file generated as suggested that the /etc/ld.so.cache
file gets opened. Should I need somehow to update it?

Thanks,
Fede

Re: guile-2.0.11 installation on system with 2.0.5

[Chris Vine]

On Sun, 14 Sep 2014 17:42:58 +0200
Federico Beffa <beffa@ieee.org> wrote:
> ludo@gnu.org (Ludovic Courtès) writes:
> 
> > It may be that, while /usr/local/bin/guile is indeed from the new
> > version, it ends up loading .scm and .go files from the old version.
> >
> > You could check that by running:
> >
> >   strace -o log /usr/local/bin/guile --version
> >
> > and grepping for .scm and .go files in ‘log’.
> >
> > That could happen, for instance, if there’s a GUILE_LOAD_PATH or
> > GUILE_LOAD_COMPILED_PATH environment variable pointing to
> > /usr/share/guile/...
> >
> 
> Yes, that's what happens. I can see libraries from /usr/share and
> /usr/lib/guile being used.
> 
> I do not have any GUILE_LOAD_* environment variable defined. However,
> I see in the "log" file generated as suggested that
> the /etc/ld.so.cache file gets opened. Should I need somehow to
> update it?

If it is any use to you, to run guile-1.8 on a guile-2.0 system (which
I rarely do) I set the following environmental variables in the script
which starts guile and/or which compiles or loads anything which uses
the 1.8 version of libguile.

  export LD_LIBRARY_PATH=/opt/guile18/lib
  export PATH=/opt/guile18/bin:$PATH
  export GUILE_LOAD_PATH=/opt/guile18/share/guile/1.8:/opt/guile18/share/guile/site:/opt/guile18/share/guile
  export PKG_CONFIG_PATH=/opt/guile18/lib/pkgconfig:$PKG_CONFIG_PATH
  export LDFLAGS=-L/opt/guile18/lib:$LDFLAGS

For guile-2.0 you will probably also want to set GUILE_LOAD_COMPILED_PATH.

However, generally this is not a very sensible approach if you are upgrading
the same minor version of guile.  It would be better to build guile-2.0.11
using the debian build scripts and replace guile-2.0.5 entirely.

Chris

Re: guile-2.0.11 installation on system with 2.0.5

[Ludovic Courtès]

Federico Beffa <beffa@ieee.org> skribis:

> ludo@gnu.org (Ludovic Courtès) writes:
>
>> It may be that, while /usr/local/bin/guile is indeed from the new
>> version, it ends up loading .scm and .go files from the old version.
>>
>> You could check that by running:
>>
>>   strace -o log /usr/local/bin/guile --version
>>
>> and grepping for .scm and .go files in ‘log’.
>>
>> That could happen, for instance, if there’s a GUILE_LOAD_PATH or
>> GUILE_LOAD_COMPILED_PATH environment variable pointing to
>> /usr/share/guile/...
>>
>
> Yes, that's what happens. I can see libraries from /usr/share and
> /usr/lib/guile being used.
>
> I do not have any GUILE_LOAD_* environment variable defined. However, I
> see in the "log" file generated as suggested that the /etc/ld.so.cache
> file gets opened. Should I need somehow to update it?

You probably need to run ‘ldconfig’.

HTH,
Ludo’.

Re: guile-2.0.11 installation on system with 2.0.5

[Federico Beffa]

Chris Vine <chris@cvine.freeserve.co.uk> writes:

> On Sun, 14 Sep 2014 21:16:39 -0400
> mhw@netris.org wrote:
>> Federico Beffa <beffa@ieee.org> writes:
>>
>> > Neil Jerram <neil@ossau.homelinux.net> writes:
>> >
>> >>
>> >> This is just a guess, but what happens if you do this:
>> >>
>> >> $ LD_LIBRARY_PATH=/usr/local/lib /usr/local/bin/guile
>> >>
>> >> Regards,
>> >>      Neil
>> >
>> > With this it works!
>> >
>> > I notice that there is an /etc/ld.so.cache file. Do I somehow need
>> > to update it?
>>
>> Yes, you update it by running "ldconfig" as root.  This needs to be
>> done when installing libraries outside of your package manager, not
>> only for Guile, but for essentially all packages containing libraries.
>
> I would not recommend doing that where the OP has two _binary
> compatible_ versions of the same library in different prefixes (as he
> appears to have), otherwise the one which will be found and linked in
> will depend on the dynamic linker's look-up order from
> reading /etc/ld.so.conf.  This could be the old micro version where in
> a given case the OP in fact wants the new one, or conversely the new
> micro version where he in fact wants the old one.
>
> Presumably in the general case he wants the micro version supplied by
> the distribution's package manager to be linked in, otherwise he would
> simply have replaced that one with the (binary compatible) newer
> version of the same library.  Presumably also he wants the updated
> version which he has installed to be linked in instead only when
> specially called.  If that is right, he is much better off putting his
> updated version in a directory which is _not_ specified
> in /etc/ld.so.conf, and invoking it on the occasions when he does not
> want the general case to apply by setting the LD_LIBRARY_PATH
> environmental variable for that invocation.  Then he is guaranteed to
> have the correct version loaded in.
>
> Chris

Your guess is correct: The distribution that I'm using (Debian wheezy)
ships 2.0.5 as the newest guile version and I need to keep it to satisfy
dependencies of other distribution supplied packages.  However, I would
like to experiment with a newer version of guile. I will then follow
your advice and install it in a different directory.

Thanks for all the explanations!
Regards,
Fede

Re: guile-2.0.11 installation on system with 2.0.5

[Chris Vine]

On Mon, 15 Sep 2014 13:46:07 +0200
Federico Beffa <beffa@ieee.org> wrote:
[snip]
> Your guess is correct: The distribution that I'm using (Debian wheezy)
> ships 2.0.5 as the newest guile version and I need to keep it to
> satisfy dependencies of other distribution supplied packages.
> However, I would like to experiment with a newer version of guile. I
> will then follow your advice and install it in a different directory.

Surely dependency requirements would be satisfied by a later library
version with the same so name?  I should read up the documentation on
dpkg.

But quite honestly, if you want to experiment with newer software don't
use an archaic distribution such as debian stable, which is out of date
even when first released.

Chris

Re: guile-2.0.11 installation on system with 2.0.5

[Mark H Weaver]

Chris Vine <chris@cvine.freeserve.co.uk> writes:
> But quite honestly, if you want to experiment with newer software don't
> use an archaic distribution such as debian stable, which is out of date
> even when first released.

Umm, I think it's quite reasonable to run a distribution of older
software that has gone through a long testing period and works well
together, and then to compile more recent versions of selected packages
of particular interest.

In my experience, every time I've run a more cutting-edge distro, I
inevitably end up hitting bugs in software I don't care about when I'm
just trying to get something else done, leaving me less time to work on
the packages I choose to focus on.  YMMV, of course.

     Mark

Re: guile-2.0.11 installation on system with 2.0.5

[Federico Beffa]

Chris Vine <chris@cvine.freeserve.co.uk> writes:

> On Mon, 15 Sep 2014 13:46:07 +0200
> Federico Beffa <beffa@ieee.org> wrote:
> [snip]
>> Your guess is correct: The distribution that I'm using (Debian wheezy)
>> ships 2.0.5 as the newest guile version and I need to keep it to
>> satisfy dependencies of other distribution supplied packages.
>> However, I would like to experiment with a newer version of guile. I
>> will then follow your advice and install it in a different directory.
>
> Surely dependency requirements would be satisfied by a later library
> version with the same so name?  I should read up the documentation on
> dpkg.
>

As far as I inderstand the Debian package manager mantains a package
database. This is the place where it looks for installed packages. So,
if I have a newer version of guile which is not installed through the
package manager, the package manager will not know about it.

Regards,
Fede

Re: guile-2.0.11 installation on system with 2.0.5

[David Pirotte]

[-- Attachment #1: Type: text/plain, Size: 1202 bytes --]

Hello,

> As far as I inderstand the Debian package manager mantains a package
> database. This is the place where it looks for installed packages. So,
> if I have a newer version of guile which is not installed through the
> package manager, the package manager will not know about it.

even if you are locked in a debian stable, you can, and you should in the case of
guile really, install packages from testing, unstable and even experimental [which
is not recommended unless you know what you are doing of course].

So:

	update your /etc/apt/sources.list, add a line with testing source
	update you /etc/preferences
		
		Package: *
		Pin: release a=stable
		Pin-Priority: 800
	
		Package: guile
		Pin: release a=testing
		Pin-Priority: 600

	aptitude update
	aptitude
		search for the guile-2.0 package aptitude entry
		press enter [Menu: Package -> information]
		select and install the testing version [2.0.11+1-1 as of today]

with that setting, aptitude|debian future updates will track and offer you to update
the installed guile-2.0 testing package, while keeping everything else on stable...
there are doc about that, duckduckgo for it...

Cheers,
David

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 173 bytes --]

Re: guile-2.0.11 installation on system with 2.0.5

[Federico Beffa]

David Pirotte <david@altosw.be> writes:

> Hello,
>
>> As far as I inderstand the Debian package manager mantains a package
>> database. This is the place where it looks for installed packages. So,
>> if I have a newer version of guile which is not installed through the
>> package manager, the package manager will not know about it.
>
> even if you are locked in a debian stable, you can, and you should in the case of
> guile really, install packages from testing, unstable and even experimental [which
> is not recommended unless you know what you are doing of course].
>
> So:
>
>     update your /etc/apt/sources.list, add a line with testing source
>     update you /etc/preferences
>
>         Package: *
>         Pin: release a=stable
>         Pin-Priority: 800
>
>         Package: guile
>         Pin: release a=testing
>         Pin-Priority: 600
>
>     aptitude update
>     aptitude
>         search for the guile-2.0 package aptitude entry
>         press enter [Menu: Package -> information]
>         select and install the testing version [2.0.11+1-1 as of today]
>
> with that setting, aptitude|debian future updates will track and offer you to update
> the installed guile-2.0 testing package, while keeping everything else on stable...
> there are doc about that, duckduckgo for it...
>

You convinced me that I should be fine using guile from testing.

I've added the following lines in sources.list:

deb http://ftp.ch.debian.org/debian/ testing main
deb-src http://ftp.ch.debian.org/debian/ testing main

created /etc/apt/preferences.d/00-stable containing:

Package: *
Pin: release a=stable
Pin-Priority: 800

and created /etc/apt/preferences.d/20-guile containing:

Package: guile
Pin: release a=testing
Pin-Priority: 600

Now, before installing guile from testing, I wanted to check if I still
get no updatable packages as a moment before doing the change:

aptitude update
aptitude full-upgrade

This tells me that the package libxnvctrl0 can be update. If I remove
the testing entry from sources.list, then I get no updates. So, something
is coming in from testing.

Am I doing something wrong?

Regards,
Fede

Re: guile-2.0.11 installation on system with 2.0.5

[Federico Beffa]

On Tue, Sep 16, 2014 at 1:09 PM, Federico Beffa <beffa@ieee.org> wrote:
> David Pirotte <david@altosw.be> writes:
>
>> Hello,
>>
>>> As far as I inderstand the Debian package manager mantains a package
>>> database. This is the place where it looks for installed packages. So,
>>> if I have a newer version of guile which is not installed through the
>>> package manager, the package manager will not know about it.
>>
>> even if you are locked in a debian stable, you can, and you should in the case of
>> guile really, install packages from testing, unstable and even experimental [which
>> is not recommended unless you know what you are doing of course].
>>
>> So:
>>
>>     update your /etc/apt/sources.list, add a line with testing source
>>     update you /etc/preferences
>>
>>         Package: *
>>         Pin: release a=stable
>>         Pin-Priority: 800
>>
>>         Package: guile
>>         Pin: release a=testing
>>         Pin-Priority: 600
>>
>>     aptitude update
>>     aptitude
>>         search for the guile-2.0 package aptitude entry
>>         press enter [Menu: Package -> information]
>>         select and install the testing version [2.0.11+1-1 as of today]
>>
>> with that setting, aptitude|debian future updates will track and offer you to update
>> the installed guile-2.0 testing package, while keeping everything else on stable...
>> there are doc about that, duckduckgo for it...
>>
>
> You convinced me that I should be fine using guile from testing.
>
> I've added the following lines in sources.list:
>
> deb http://ftp.ch.debian.org/debian/ testing main
> deb-src http://ftp.ch.debian.org/debian/ testing main
>
> created /etc/apt/preferences.d/00-stable containing:
>
> Package: *
> Pin: release a=stable
> Pin-Priority: 800
>
> and created /etc/apt/preferences.d/20-guile containing:
>
> Package: guile
> Pin: release a=testing
> Pin-Priority: 600
>
> Now, before installing guile from testing, I wanted to check if I still
> get no updatable packages as a moment before doing the change:
>
> aptitude update
> aptitude full-upgrade
>
> This tells me that the package libxnvctrl0 can be update. If I remove
> the testing entry from sources.list, then I get no updates. So, something
> is coming in from testing.
>
> Am I doing something wrong?
>
> Regards,
> Fede

OK, I've found out by using "apt-cache policy package-name": I need to
lower the default priorities of packages from testing other than guile
with

Package: *
Pin: release o=Debian
Pin-Priority: 10

Now I do not get other packages with "aptitude full-upgrade", but if I
pull in guile-2.0 from testing it wants to change several other
libraries:

$ sudo aptitude -t testing full-upgrade guile-2.0
The following NEW packages will be installed:
  libffi6{a}
The following packages will be upgraded:
  guile-2.0 guile-2.0-libs libc6 libgc1c2 libgssapi-krb5-2
libk5crypto3 libkeyutils1
  libkrb5-3 libkrb5support0 libtirpc1 locales nfs-common
12 packages upgraded, 1 newly installed, 0 to remove and 1353 not upgraded.
Need to get 12.1 MB of archives. After unpacking 2,553 kB will be used.
The following packages have unmet dependencies:
 krb5-user : Depends: libkrb5-3 (= 1.10.1+dfsg-5+deb7u2) but
1.12.1+dfsg-9 is to be installed.
 libgc-dev : Depends: libgc1c2 (= 1:7.1-9.1) but 1:7.2d-6.3 is to be installed.
 libc6-i386 : Depends: libc6 (= 2.13-38+deb7u4) but 2.19-11 is to be installed.
 guile-2.0-dev : Depends: guile-2.0 (= 2.0.5+1-3) but 2.0.11+1-1 is to
be installed.
 libc6-dev : Depends: libc6 (= 2.13-38+deb7u4) but 2.19-11 is to be installed.
 libc-dev-bin : Depends: libc6 (< 2.14) but 2.19-11 is to be installed.

I think I will just install guile 2.0.11 "manually".

Thanks for all the help!
Fede

Re: guile-2.0.11 installation on system with 2.0.5

[David Pirotte]

[-- Attachment #1: Type: text/plain, Size: 2200 bytes --]

Hello,

> ...
> OK, I've found out by using "apt-cache policy package-name": I need to
> lower the default priorities of packages from testing other than guile
> with
> 
> Package: *
> Pin: release o=Debian
> Pin-Priority: 10

good to know, tx!

> Now I do not get other packages with "aptitude full-upgrade", but if I
> pull in guile-2.0 from testing it wants to change several other
> libraries:

yes, this is to be expected indeed, as guile-2.0-libs, in testing, depends on
libgc1c2 >= 7.2d, which triggers a series of dependency updates.

i am actually _very_ surprised that this would not be the case when manually
installing guile-2.0.11: I thought configure would not let you install unless ....

note also that guile-2.0-dev is not required, not sure it is the 'full-upgrade'
terribly scary beast that triggered that?

> $ sudo aptitude -t testing full-upgrade guile-2.0
> The following NEW packages will be installed:
>   libffi6{a}
> The following packages will be upgraded:
>   guile-2.0 guile-2.0-libs libc6 libgc1c2 libgssapi-krb5-2
> libk5crypto3 libkeyutils1
>   libkrb5-3 libkrb5support0 libtirpc1 locales nfs-common
> 12 packages upgraded, 1 newly installed, 0 to remove and 1353 not upgraded.
> Need to get 12.1 MB of archives. After unpacking 2,553 kB will be used.
> The following packages have unmet dependencies:
>  krb5-user : Depends: libkrb5-3 (= 1.10.1+dfsg-5+deb7u2) but
> 1.12.1+dfsg-9 is to be installed.
>  libgc-dev : Depends: libgc1c2 (= 1:7.1-9.1) but 1:7.2d-6.3 is to be installed.
>  libc6-i386 : Depends: libc6 (= 2.13-38+deb7u4) but 2.19-11 is to be installed.
>  guile-2.0-dev : Depends: guile-2.0 (= 2.0.5+1-3) but 2.0.11+1-1 is to
> be installed.
>  libc6-dev : Depends: libc6 (= 2.13-38+deb7u4) but 2.19-11 is to be installed.
>  libc-dev-bin : Depends: libc6 (< 2.14) but 2.19-11 is to be installed.
> 
> I think I will just install guile 2.0.11 "manually".

It should request you to update libgc1c2 as well, and actually constraints might even
be stronger [when the tarball is >=, in version, to the 1 used by debian pkg
maintainer]?

Hum, mark, ludovic,  am I wrong here?

Cheers,
David








[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 173 bytes --]