public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
* [gentoo-dev] [RFC] iconv and libintl virtuals
@ 2005-12-11 17:02 Diego 'Flameeyes' Pettenò
  2005-12-11 18:29 ` Spider (D.m.D. Lj.)
  2005-12-24  2:03 ` Diego 'Flameeyes' Pettenò
  0 siblings, 2 replies; 6+ messages in thread
From: Diego 'Flameeyes' Pettenò @ 2005-12-11 17:02 UTC (permalink / raw
  To: gentoo-dev

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

Okay now that virtual/x11 introduced the new generation's virtuals, the 
decision of waiting to have virtuals for iconv and libintl can be considered 
concluded, and we might start adding them, right? :D

Proposed virtuals for now would be:

virtual/iconv: || ( sys-libs/glibc dev-libs/iconv )
virtual/libintl: || ( sys-libs/glibc sys-devel/gettext )

The deps of programs using libintl would then be

RDEPEND="nls? ( virtual/libintl )"
DEPEND="nls? ( sys-devel/gettext )"

for iconv instead simply add virtual/iconv to RDEPEND; note that most of the 
packages do depend on libintl but don't on libintl, as that is pulled in 
mostly as a dep of gettext... there are though some packages that actually 
uses libiconv directly, such as glib and mpd iirc.

If this is ok, I won't ask any maintainer to add that stuff by himself (well 
if somebody wants, I'll thank him for sure), I'll take care of updating the 
deps as they are needed.

Embedded team: this would probably be a good test for NLS support on uclibc, 
if you want, please add me (or alt) as CC if you'll ever have to file bugs of 
NLS not being correctly disabled with --disable-nls, as I found quite a few 
programs taking that bad.

Thanks to everybody who cared to read this mail.
-- 
Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/
Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [gentoo-dev] [RFC] iconv and libintl virtuals
  2005-12-11 17:02 [gentoo-dev] [RFC] iconv and libintl virtuals Diego 'Flameeyes' Pettenò
@ 2005-12-11 18:29 ` Spider (D.m.D. Lj.)
  2005-12-11 19:40   ` Diego 'Flameeyes' Pettenò
  2005-12-24  2:03 ` Diego 'Flameeyes' Pettenò
  1 sibling, 1 reply; 6+ messages in thread
From: Spider (D.m.D. Lj.) @ 2005-12-11 18:29 UTC (permalink / raw
  To: gentoo-dev

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

On Sun, 2005-12-11 at 18:02 +0100, Diego 'Flameeyes' Pettenò wrote:
> Okay now that virtual/x11 introduced the new generation's virtuals, the 
> decision of waiting to have virtuals for iconv and libintl can be considered 
> concluded, and we might start adding them, right? :D
> 
> Proposed virtuals for now would be:
> 
> virtual/iconv: || ( sys-libs/glibc dev-libs/iconv )
> virtual/libintl: || ( sys-libs/glibc sys-devel/gettext )
> 
> The deps of programs using libintl would then be
> 
> RDEPEND="nls? ( virtual/libintl )"
> DEPEND="nls? ( sys-devel/gettext )"
> 
> for iconv instead simply add virtual/iconv to RDEPEND; note that most of the 
> packages do depend on libintl but don't on libintl, as that is pulled in 
> mostly as a dep of gettext... there are though some packages that actually 
> uses libiconv directly, such as glib and mpd iirc.
> 
> If this is ok, I won't ask any maintainer to add that stuff by himself (well 
> if somebody wants, I'll thank him for sure), I'll take care of updating the 
> deps as they are needed.
> 
> Embedded team: this would probably be a good test for NLS support on uclibc, 
> if you want, please add me (or alt) as CC if you'll ever have to file bugs of 
> NLS not being correctly disabled with --disable-nls, as I found quite a few 
> programs taking that bad.
> 
> Thanks to everybody who cared to read this mail.

How will you deal with the packages that build against glibc iconv but
not against the separated?
There used to be a lot of issues here, which caused me to hard-mask
iconv ( still should be hard masked for most/all glibc-based systems )
due to the split and mainline packages running out of sync.


This situation may be fixed now, but I'm more likely to believe that it
just hasn't cropped up "Just yet" ( yep, I'm cynical here ) 


//Spider

-- 
begin  .signature
Tortured users / Laughing in pain
See Microsoft KB Article Q265230 for more information.
end


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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [gentoo-dev] [RFC] iconv and libintl virtuals
  2005-12-11 18:29 ` Spider (D.m.D. Lj.)
@ 2005-12-11 19:40   ` Diego 'Flameeyes' Pettenò
  2005-12-11 23:47     ` Spider (D.m.D. Lj.)
  0 siblings, 1 reply; 6+ messages in thread
From: Diego 'Flameeyes' Pettenò @ 2005-12-11 19:40 UTC (permalink / raw
  To: gentoo-dev

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

On Sunday 11 December 2005 19:29, Spider (D.m.D. Lj.) wrote:
> How will you deal with the packages that build against glibc iconv but
> not against the separated?
I'll patch them, if they are common packages, ports from FreeBSD, NetBSD, 
OpenBSD, DragonFly BSD or DarwinPorts will have patches for them, as they use 
libiconv.

> There used to be a lot of issues here, which caused me to hard-mask
> iconv ( still should be hard masked for most/all glibc-based systems )
> due to the split and mainline packages running out of sync.
That's why the virtual consider glibc first, for systems where glibc is not 
present it will go with libiconv. Everyone using glibc *must not* use 
libiconv, and it *has* to remain hardmasked for them.
But libiconv is unmasked for Gentoo/FreeBSD, Gentoo/NetBSD and Gentoo/OpenBSD 
systems, where it's needed to have iconv() function.

-- 
Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/
Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [gentoo-dev] [RFC] iconv and libintl virtuals
  2005-12-11 19:40   ` Diego 'Flameeyes' Pettenò
@ 2005-12-11 23:47     ` Spider (D.m.D. Lj.)
  2005-12-12  2:28       ` Diego 'Flameeyes' Pettenò
  0 siblings, 1 reply; 6+ messages in thread
From: Spider (D.m.D. Lj.) @ 2005-12-11 23:47 UTC (permalink / raw
  To: gentoo-dev

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

On Sun, 2005-12-11 at 20:40 +0100, Diego 'Flameeyes' Pettenò wrote:
> On Sunday 11 December 2005 19:29, Spider (D.m.D. Lj.) wrote:
> > How will you deal with the packages that build against glibc iconv but
> > not against the separated?
> I'll patch them, if they are common packages, ports from FreeBSD, NetBSD, 
> OpenBSD, DragonFly BSD or DarwinPorts will have patches for them, as they use 
> libiconv.

Sounds good enough : )

> 
> > There used to be a lot of issues here, which caused me to hard-mask
> > iconv ( still should be hard masked for most/all glibc-based systems )
> > due to the split and mainline packages running out of sync.
> That's why the virtual consider glibc first, for systems where glibc is not 
> present it will go with libiconv. Everyone using glibc *must not* use 
> libiconv, and it *has* to remain hardmasked for them.

Yeah, I certainly -HOPE- that it will retain its blocker vs. glibc, or
things may slip downhill on a certain rollercoasterride of party and
fun.   Not to mention that they claim the same files ;)


> But libiconv is unmasked for Gentoo/FreeBSD, Gentoo/NetBSD and Gentoo/OpenBSD 
> systems, where it's needed to have iconv() function.

Aye, I just raised the point that such packages -do- exist and will(I'm
still not an optimist) be an issue in the future (tm) for you : ) 


Anyhow, as long as this doesn't impose the case where some poor sod will
get iconv on his glibc system I'm quite happy with the change, no worry
from me, and do go ahead with the updated deps for all I care. Just try
not to make a mess of things *wink*


//Spider


-- 
begin  .signature
Tortured users / Laughing in pain
See Microsoft KB Article Q265230 for more information.
end


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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [gentoo-dev] [RFC] iconv and libintl virtuals
  2005-12-11 23:47     ` Spider (D.m.D. Lj.)
@ 2005-12-12  2:28       ` Diego 'Flameeyes' Pettenò
  0 siblings, 0 replies; 6+ messages in thread
From: Diego 'Flameeyes' Pettenò @ 2005-12-12  2:28 UTC (permalink / raw
  To: gentoo-dev

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

On Monday 12 December 2005 00:47, Spider (D.m.D. Lj.) wrote:
> Yeah, I certainly -HOPE- that it will retain its blocker vs. glibc, or
> things may slip downhill on a certain rollercoasterride of party and
> fun.   Not to mention that they claim the same files ;)
AS long as nobody does stupid things like touching my ebuild without telling 
me, it should be safe, I'm quite territorial, so I monitor my own packages..

> Aye, I just raised the point that such packages -do- exist and will(I'm
> still not an optimist) be an issue in the future (tm) for you : )
Some packages depends on || condition on libiconv already, I haven't seen a 
single bug about it since I maintain it.
Maybe I'm lucky, maybe the current situation is better handled.

-- 
Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/
Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [gentoo-dev] [RFC] iconv and libintl virtuals
  2005-12-11 17:02 [gentoo-dev] [RFC] iconv and libintl virtuals Diego 'Flameeyes' Pettenò
  2005-12-11 18:29 ` Spider (D.m.D. Lj.)
@ 2005-12-24  2:03 ` Diego 'Flameeyes' Pettenò
  1 sibling, 0 replies; 6+ messages in thread
From: Diego 'Flameeyes' Pettenò @ 2005-12-24  2:03 UTC (permalink / raw
  To: gentoo-dev

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

On Sunday 11 December 2005 18:02, Diego 'Flameeyes' Pettenò wrote:
> Okay now that virtual/x11 introduced the new generation's virtuals, the
> decision of waiting to have virtuals for iconv and libintl can be
> considered concluded, and we might start adding them, right? :D

I'm still waiting for other answers to this, a part Spider's consideration 
about libiconv (that shown no problems yet, I'll anyway see to mask it on 
default-linux profile and other glibc-based profiles).

If people has no complaints with this, next week I would start adding the 
packages and fixing the ebuilds to use the right deps.

-- 
Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/
Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2005-12-24  2:06 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-12-11 17:02 [gentoo-dev] [RFC] iconv and libintl virtuals Diego 'Flameeyes' Pettenò
2005-12-11 18:29 ` Spider (D.m.D. Lj.)
2005-12-11 19:40   ` Diego 'Flameeyes' Pettenò
2005-12-11 23:47     ` Spider (D.m.D. Lj.)
2005-12-12  2:28       ` Diego 'Flameeyes' Pettenò
2005-12-24  2:03 ` Diego 'Flameeyes' Pettenò

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox