[gentoo-dev] imlib/imlib2 useflag inconsistency

[gentoo-dev] imlib/imlib2 useflag inconsistency

[Benedikt Morbach]

[-- Attachment #1.1: Type: text/plain, Size: 1589 bytes --]

Hello everybody,
I recently noticed, that there are two imlibs in the tree, media-libs/imlib
and media-libs/imlib2.
There are also two corresponding useflags, imlib and imlib2, while imlib is
a global useflag and imlib2 a local one.
At the moment of writing, a total of 48 ebuilds in the tree use one of these
flags and none uses both.
Many ebuilds use the imlib useflag to enable support for media-libs/imlib2,
while only one uses imlib2.

The problem is, that the last imlib release is over three years old and it's
upstream is dead, so  many people might not want to have it, but still want
the features they get when compiling apps against imlib2.

Here are some statistics:
The 48 ebuilds consist of 19 packages.
24 ebuilds do imlib? ( media-libs/imlib2 )
22 ebuilds do imlib? ( media-libs/imlib )
1 ebuild does imlib2? ( media-libs/imlib2 ) (x11-misc/fbdesk)
1 ebuild does something completely different ( imlib? ( kde-base/kuickshow )
) (kde-base/kdegraphics-meta-3.5.9)

Possible solutions include: (sorted by necessary effort)
1. Leaving everything like it is (not a real solution)
2. Removing the imlib2 useflag
3. Changing the 24 ebuilds depending on imlib2 to use the imlib2 useflag
(and possibly making it a global flag)

In my opinion, making imlib2 a global useflag would be the best solution, as
it gives users who do not want an ancient unmaintained library a fine
grained control over their system.

Please discuss! :)

Attachments:
[1] imlib.txt: ebuilds using imlib for imlib support
[2] imlib2.txt: ebuilds using imlib for imlib2 support

Greetings from a humble user

[-- Attachment #1.2: Type: text/html, Size: 1959 bytes --]

[-- Attachment #2: imlib.txt --]
[-- Type: text/plain, Size: 844 bytes --]

app-office/magicpoint/magicpoint-1.12a-r1.ebuild
app-office/magicpoint/magicpoint-1.13a.ebuild
kde-base/kdegraphics/kdegraphics-3.5.9.ebuild
media-gfx/gimageview/gimageview-0.2.27-r2.ebuild
www-client/w3mmee/w3mmee-0.3.2_p24-r4.ebuild
www-client/w3mmee/w3mmee-0.3.2_p24-r5.ebuild
www-client/w3mmee/w3mmee-0.3.2_p24-r6.ebuild
x11-misc/wmakerconf/wmakerconf-2.11.ebuild
x11-terms/mlterm/mlterm-2.9.3-r1.ebuild
x11-terms/mlterm/mlterm-2.9.4.ebuild
x11-terms/mlterm/mlterm-2.9.4-r1.ebuild
x11-wm/fvwm/fvwm-2.5.18-r1.ebuild
x11-wm/fvwm/fvwm-2.5.19.ebuild
x11-wm/fvwm/fvwm-2.5.21.ebuild
x11-wm/fvwm/fvwm-2.5.25.ebuild
x11-wm/fvwm/fvwm-2.5.26.ebuild
x11-wm/icewm/icewm-1.2.30.ebuild
x11-wm/icewm/icewm-1.2.30-r1.ebuild
x11-wm/icewm/icewm-1.2.32.ebuild
x11-wm/icewm/icewm-1.2.33.ebuild
x11-wm/icewm/icewm-1.2.34.ebuild
x11-wm/icewm/icewm-1.2.35.ebuild

[-- Attachment #3: imlib2.txt --]
[-- Type: text/plain, Size: 1067 bytes --]

app-office/texmacs/texmacs-1.0.6.14.ebuild
dev-libs/DirectFB-extra/DirectFB-extra-0.9.25.ebuild
dev-libs/DirectFB-extra/DirectFB-extra-1.0.0.ebuild
dev-libs/DirectFB-extra/DirectFB-extra-1.0.0-r1.ebuild
dev-libs/DirectFB-extra/DirectFB-extra-1.1.0.ebuild
media-libs/libcaca/libcaca-0.99_beta11.ebuild
media-libs/libcaca/libcaca-0.99_beta13.ebuild
media-libs/libcaca/libcaca-0.99_beta14.ebuild
media-video/ffmpeg/ffmpeg-0.4.9_p20070616.ebuild
media-video/ffmpeg/ffmpeg-0.4.9_p20070616-r1.ebuild
media-video/ffmpeg/ffmpeg-0.4.9_p20070616-r20.ebuild
media-video/ffmpeg/ffmpeg-0.4.9_p20070616-r2.ebuild
media-video/ffmpeg/ffmpeg-0.4.9_p20070616-r3.ebuild
media-video/ffmpeg/ffmpeg-0.4.9_p20080206.ebuild
media-video/ffmpeg/ffmpeg-0.4.9_p20080326.ebuild
www-client/w3m/w3m-0.5.2.ebuild
www-client/w3m/w3m-0.5.2-r1.ebuild
www-client/w3m/w3m-0.5.2-r2.ebuild
x11-libs/libast/libast-0.7.ebuild
x11-libs/libast/libast-9999.ebuild
x11-misc/alock/alock-60-r3.ebuild
x11-wm/awesome/awesome-3.0_rc2.ebuild
x11-wm/fluxbox/fluxbox-1.0.0.ebuild
x11-wm/fluxbox/fluxbox-1.0.0-r2.ebuild

[gentoo-dev] Re: imlib/imlib2 useflag inconsistency

[Duncan]

"Benedikt Morbach" <benedikt.morbach@googlemail.com> posted
6faa67950808141256p32b8b6d0uaa59ebe7d2a2653@mail.gmail.com, excerpted
below, on  Thu, 14 Aug 2008 21:56:16 +0200:

> Possible solutions include: (sorted by necessary effort) 1. Leaving
> everything like it is (not a real solution) 2. Removing the imlib2
> useflag 3. Changing the 24 ebuilds depending on imlib2 to use the imlib2
> useflag (and possibly making it a global flag)
> 
> In my opinion, making imlib2 a global useflag would be the best
> solution, as it gives users who do not want an ancient unmaintained
> library a fine grained control over their system.

Good catch/argument.

Based on what was done with qt and gtk, option 2 above, removing the 
imlib2 USE flag and converting everything to use the imlib USE flag, is 
the most likely solution.  Check the archives on gtk/gtk2 if you'd like.

In the gtk/gtk2 case, where many packages could link against either, gtk 
was used to toggle the gtk general preference, while gtk2 if enabled 
indicated a preference for it over gtk(1).  The solution was to deprecate 
the gtk2 flag and in general prefer gtk2 to gtk(1), if both could be 
linked.  Individual package maintainers could of course decide to prefer 
gtk(1) if there was an overriding reason to do so.  (qt had somewhat 
different details which I don't fully recall ATM, but I don't believe 
it's quite as direct a parallel in any case.)

Since you mentioned that no imlib/imlib2 packages seem to use both flags, 
that solution would seem even more applicable here.  Just do away with 
the imlib2 flag entirely, and prefer imlib2 in any cases where there is 
now or may be later a choice unless there's an overriding reason not to.

But while I follow the discussion here regularly and have done so for 
some time, I'm just a user.  We'll see what the devs have to say.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman