[gentoo-dev] help with readline confusion

[gentoo-dev] help with readline confusion

[Matthew Kennedy]

I was creating an ebuild for octave and I noticed something interesting.
The 2.1.x branch of octave checks for readline 4.2 during configure.
Since my system (recently rsync'd too) has readline 4.1, octave's
configure fails.

Then I happened to look in /usr/portage/sys-libs/readline and I see
ebuilds for 4.1, 4.2 and 4.2a: 

  readline-4.1-r3.ebuild  
  readline-4.2.ebuild  
  readline-4.2a.ebuild

(4.2a having the latest mtime)

If I emerge --search, I get the following:

*   sys-libs/readline 
      Latest version Available:  4.1-r3
      Latest version Installed:  4.1-r3
 
My question has two parts. 1.I had expected that the "latest version
available" would show 4.2a, but it doesn't. I must be missing something
about how emerge determines which ebuild is the latest available. Is
4.2a not to be used just right now?

2. octave want's 4.2. I can satisfy it with an "ebuild
readline-4.2a.ebuild merge", but then I don't think i should, because if
users aren't getting 4.2 from an emerge, then I doubt I can expect them
to ebuild it manually when they emerge the octave package. Does this
logic sound right?

Many thanks,

Matt

Re: [gentoo-dev] help with readline confusion

[Ilian Zarov]

On Sat, 2002-02-09 at 11:52, Matthew Kennedy wrote:
> My question has two parts. 1.I had expected that the "latest version
> available" would show 4.2a, but it doesn't. I must be missing something
> about how emerge determines which ebuild is the latest available. Is
> 4.2a not to be used just right now?
emerge checks if the packages is blocked (whether it is included in
/usr/portage/profiles/package.mask). Blocked packages are usually
broken/incomplete ebuilds or early alpha/beta versions of the specified
application.
 
> 2. octave want's 4.2. I can satisfy it with an "ebuild
> readline-4.2a.ebuild merge", but then I don't think i should, because if
> users aren't getting 4.2 from an emerge, then I doubt I can expect them
> to ebuild it manually when they emerge the octave package. Does this
> logic sound right?

You should talk to an @gentoo.org developer about removing readline-4.2a
from package.mask if you consider it stable enough (isn't this actually
an alpha version ?). Not very sure of how the package.mask stuff is
handled.
> Many thanks,
> 
> Matt
 

	Best Regards,
		Ilian Zarov

Re: [gentoo-dev] help with readline confusion

[Martin Schlemmer]

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

On Sat, 2002-02-09 at 11:52, Matthew Kennedy wrote:
> I was creating an ebuild for octave and I noticed something interesting.
> The 2.1.x branch of octave checks for readline 4.2 during configure.
> Since my system (recently rsync'd too) has readline 4.1, octave's
> configure fails.
> 
> Then I happened to look in /usr/portage/sys-libs/readline and I see
> ebuilds for 4.1, 4.2 and 4.2a: 
> 
>   readline-4.1-r3.ebuild  
>   readline-4.2.ebuild  
>   readline-4.2a.ebuild
> 
> (4.2a having the latest mtime)
> 
> If I emerge --search, I get the following:
> 
> *   sys-libs/readline 
>       Latest version Available:  4.1-r3
>       Latest version Installed:  4.1-r3
>  
> My question has two parts. 1.I had expected that the "latest version
> available" would show 4.2a, but it doesn't. I must be missing something
> about how emerge determines which ebuild is the latest available. Is
> 4.2a not to be used just right now?
> 

Something (think it was bash-2.4) didnt want to build against
readline-4.2, so if you can build a system totally against
readline-4.2 (you will have to unmask it before
bootstrapping), without problems, we can start to think about
doing so.

> 2. octave want's 4.2. I can satisfy it with an "ebuild
> readline-4.2a.ebuild merge", but then I don't think i should, because if
> users aren't getting 4.2 from an emerge, then I doubt I can expect them
> to ebuild it manually when they emerge the octave package. Does this
> logic sound right?
> 
> Many thanks,
> 
> Matt
> 
> 
> _______________________________________________
> gentoo-dev mailing list
> gentoo-dev@gentoo.org
> http://lists.gentoo.org/mailman/listinfo/gentoo-dev
-- 

Martin Schlemmer
Gentoo Linux Developer, Desktop Team Developer
Cape Town, South Africa


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 232 bytes --]

Re: [gentoo-dev] help with readline confusion

[Martin Schlemmer]

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

On Sun, 2002-02-10 at 06:41, Ilian Zarov wrote:
> On Sat, 2002-02-09 at 11:52, Matthew Kennedy wrote:
> > My question has two parts. 1.I had expected that the "latest version
> > available" would show 4.2a, but it doesn't. I must be missing something
> > about how emerge determines which ebuild is the latest available. Is
> > 4.2a not to be used just right now?
> emerge checks if the packages is blocked (whether it is included in
> /usr/portage/profiles/package.mask). Blocked packages are usually
> broken/incomplete ebuilds or early alpha/beta versions of the specified
> application.
>  
> > 2. octave want's 4.2. I can satisfy it with an "ebuild
> > readline-4.2a.ebuild merge", but then I don't think i should, because if
> > users aren't getting 4.2 from an emerge, then I doubt I can expect them
> > to ebuild it manually when they emerge the octave package. Does this
> > logic sound right?
> 
> You should talk to an @gentoo.org developer about removing readline-4.2a
> from package.mask if you consider it stable enough (isn't this actually
> an alpha version ?). Not very sure of how the package.mask stuff is
> handled.

No, 4.2a was latest version at that time (not sure about
currently).

> > Many thanks,
> > 
> > Matt
>  
> 
> 	Best Regards,
> 		Ilian Zarov
> 
> _______________________________________________
> gentoo-dev mailing list
> gentoo-dev@gentoo.org
> http://lists.gentoo.org/mailman/listinfo/gentoo-dev
-- 

Martin Schlemmer
Gentoo Linux Developer, Desktop Team Developer
Cape Town, South Africa


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 232 bytes --]