is the virtual package <locale>-tanslation correct?

is the virtual package <locale>-tanslation correct?

[Lu, Lianhao]

Hi guys,

I found that in package.bbclass when generating the -locale packages, it sets RPROVIDES to provide the virtual packages <locale>-translation,
  d.setVar('RPROVIDES_' + pkg, '%s-locale %s-translation' % (pn, ln))

This would result different real packages provide the same <locale>-translation, i.e. eglibc-locale-ca and glib-2.0-locale-ca will both RPROVIDES ca-translation, even though they contain different messages.

Is it desirable or should we remove the <locale>-translation in RPROVIDES?

Best Regards,
-Lianhao

Re: is the virtual package <locale>-tanslation correct?

[Phil Blundell]

On Tue, 2012-04-24 at 09:33 +0000, Lu, Lianhao wrote:
> I found that in package.bbclass when generating the -locale packages, it sets RPROVIDES to provide the virtual packages <locale>-translation,
>   d.setVar('RPROVIDES_' + pkg, '%s-locale %s-translation' % (pn, ln))
> 
> This would result different real packages provide the same <locale>-translation, i.e. eglibc-locale-ca and glib-2.0-locale-ca will both RPROVIDES ca-translation, even though they contain different messages.
> 
> Is it desirable or should we remove the <locale>-translation in RPROVIDES?

Yes, that is the intended behaviour.  This is necessary to support
dynamically installed language packs.

p.

Re: is the virtual package <locale>-tanslation correct?

[Richard Purdie]

On Tue, 2012-04-24 at 10:42 +0100, Phil Blundell wrote:
> On Tue, 2012-04-24 at 09:33 +0000, Lu, Lianhao wrote:
> > I found that in package.bbclass when generating the -locale packages, it sets RPROVIDES to provide the virtual packages <locale>-translation,
> >   d.setVar('RPROVIDES_' + pkg, '%s-locale %s-translation' % (pn, ln))
> > 
> > This would result different real packages provide the same <locale>-translation, i.e. eglibc-locale-ca and glib-2.0-locale-ca will both RPROVIDES ca-translation, even though they contain different messages.
> > 
> > Is it desirable or should we remove the <locale>-translation in RPROVIDES?
> 
> Yes, that is the intended behaviour.  This is necessary to support
> dynamically installed language packs.

What uses this out of interest?

Cheers,

Richard

Re: is the virtual package <locale>-tanslation correct?

[Phil Blundell]

On Tue, 2012-04-24 at 11:45 +0100, Richard Purdie wrote:
> On Tue, 2012-04-24 at 10:42 +0100, Phil Blundell wrote:
> > Yes, that is the intended behaviour.  This is necessary to support
> > dynamically installed language packs.
> 
> What uses this out of interest?

I'm not entirely sure to be honest.  We used to use it quite heavily in
Familiar but I have no idea whether Angstrom does the same.  The systems
I'm working on nowadays don't tend to require language packs so I
haven't personally used that mechanism for a while.

p.

Re: is the virtual package <locale>-tanslation correct?

[Richard Purdie]

On Tue, 2012-04-24 at 11:48 +0100, Phil Blundell wrote:
> On Tue, 2012-04-24 at 11:45 +0100, Richard Purdie wrote:
> > On Tue, 2012-04-24 at 10:42 +0100, Phil Blundell wrote:
> > > Yes, that is the intended behaviour.  This is necessary to support
> > > dynamically installed language packs.
> > 
> > What uses this out of interest?
> 
> I'm not entirely sure to be honest.  We used to use it quite heavily in
> Familiar but I have no idea whether Angstrom does the same.  The systems
> I'm working on nowadays don't tend to require language packs so I
> haven't personally used that mechanism for a while.

How did the system use this? I can imagine querying the list of
installed packages and then attempting installing xx-locale as a resuilt
but I'm not sure how this other provider helps?

As far as I know, opkg doesn't directly support anything like this?

Cheers,

Richard

Re: is the virtual package <locale>-tanslation correct?

[Phil Blundell]

On Tue, 2012-04-24 at 17:33 +0100, Richard Purdie wrote:
> On Tue, 2012-04-24 at 11:48 +0100, Phil Blundell wrote:
> > On Tue, 2012-04-24 at 11:45 +0100, Richard Purdie wrote:
> > > On Tue, 2012-04-24 at 10:42 +0100, Phil Blundell wrote:
> > > > Yes, that is the intended behaviour.  This is necessary to support
> > > > dynamically installed language packs.
> > > 
> > > What uses this out of interest?
> > 
> > I'm not entirely sure to be honest.  We used to use it quite heavily in
> > Familiar but I have no idea whether Angstrom does the same.  The systems
> > I'm working on nowadays don't tend to require language packs so I
> > haven't personally used that mechanism for a while.
> 
> How did the system use this? I can imagine querying the list of
> installed packages and then attempting installing xx-locale as a resuilt
> but I'm not sure how this other provider helps?
> 
> As far as I know, opkg doesn't directly support anything like this?

Ipkg did have (and I assume opkg still has, though I haven't checked) a
"greedy depends" mechanism which works exactly like this.  If it sees a
line like:

Recommends: xx-locale*

then it will install all the packages which Provide: xx-locale and whose
dependencies are already satisfied.  The way we used this in Familiar
was that the .ipk containing message catalogs for language CC and
package PN would Provide: PN-locale, CC-translation, and would Depend:
on PN and locale-base-CC.  PN itself would Recommend: PN-locale*, and
there was a language-pack-CC metapackage which would Depend: on
locale-base-cc and Recommend: CC-translation*.  So...

- if you did "ipkg install language-pack-de", it would install
locale-base-de (via the hard Depends) and then install PN-locale-de for
each PN that was already installed (via the Recommends).

- if you did "ipkg install frozen-bubble", it would install the program
itself (obviously) and then install the message catalogs for all the
locale-bases that were already installed.

Likewise, if you subsequently removed locale-base-de or frozen-bubble
then the dependency chain would cause all the corresponding message
catalogs to get ripped out as well.

Obviously this was about a decade ago so my recollection might not be
100% reliable.  But I'm fairly sure that the basic gist of the above is
correct.

p.

Re: is the virtual package <locale>-tanslation correct?

[Richard Purdie]

On Tue, 2012-04-24 at 17:47 +0100, Phil Blundell wrote:
> On Tue, 2012-04-24 at 17:33 +0100, Richard Purdie wrote:
> > On Tue, 2012-04-24 at 11:48 +0100, Phil Blundell wrote:
> > > On Tue, 2012-04-24 at 11:45 +0100, Richard Purdie wrote:
> > > > On Tue, 2012-04-24 at 10:42 +0100, Phil Blundell wrote:
> > > > > Yes, that is the intended behaviour.  This is necessary to support
> > > > > dynamically installed language packs.
> > > > 
> > > > What uses this out of interest?
> > > 
> > > I'm not entirely sure to be honest.  We used to use it quite heavily in
> > > Familiar but I have no idea whether Angstrom does the same.  The systems
> > > I'm working on nowadays don't tend to require language packs so I
> > > haven't personally used that mechanism for a while.
> > 
> > How did the system use this? I can imagine querying the list of
> > installed packages and then attempting installing xx-locale as a resuilt
> > but I'm not sure how this other provider helps?
> > 
> > As far as I know, opkg doesn't directly support anything like this?
> 
> Ipkg did have (and I assume opkg still has, though I haven't checked) a
> "greedy depends" mechanism which works exactly like this.  If it sees a
> line like:
> 
> Recommends: xx-locale*
> 
> then it will install all the packages which Provide: xx-locale and whose
> dependencies are already satisfied.  The way we used this in Familiar
> was that the .ipk containing message catalogs for language CC and
> package PN would Provide: PN-locale, CC-translation, and would Depend:
> on PN and locale-base-CC.  PN itself would Recommend: PN-locale*, and
> there was a language-pack-CC metapackage which would Depend: on
> locale-base-cc and Recommend: CC-translation*.  So...
> 
> - if you did "ipkg install language-pack-de", it would install
> locale-base-de (via the hard Depends) and then install PN-locale-de for
> each PN that was already installed (via the Recommends).
> 
> - if you did "ipkg install frozen-bubble", it would install the program
> itself (obviously) and then install the message catalogs for all the
> locale-bases that were already installed.
> 
> Likewise, if you subsequently removed locale-base-de or frozen-bubble
> then the dependency chain would cause all the corresponding message
> catalogs to get ripped out as well.
> 
> Obviously this was about a decade ago so my recollection might not be
> 100% reliable.  But I'm fairly sure that the basic gist of the above is
> correct.

This is interesting information, thanks! Back in <checks logs> 2007 I
disabled some of the functionality you mention above since I couldn't
find anyone who could explain to me what it was meant to be doing but it
was causing problems:

http://git.yoctoproject.org/cgit.cgi/poky/commit/meta/classes/package.bbclass?id=cee4b2a05a506817c65267ff9786c2e9c980306a

and we still have that comment block in the code to this day. I'm sure
at the time I tried to get opkg/ipkg to do something sensible with this
and couldn't.

It would certainly be interesting to revisit some of this and see if we
could bring it back to life, maybe as part of the ipk backend this time
instead of in the core. It is going to be package manager specific
though and that may be the right place to add in some of these
dependencies if they aren't going to be useful (or functional)
elsewhere.

Cheers,

Richard