Re: [gentoo-dev] Re: News item: World file handling changes in Portage-2.2
To avoid having @system added to world_sets, you could add [system] world-candidate = false to your /etc/portage/sets.conf
[gentoo-dev] imlib/imlib2 useflag inconsistency
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 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 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-.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
Re: [gentoo-dev] [EMAIL PROTECTED]
++ I'm a user too and I really find it annoying that one can't read this list to keep up with recent development, without digging to tons of FUD, insults and other crap. I personally came to the conclusion that it is best to simply ignore all mails from certain people (hint: Most of them were forcibly retired and work on an alternative package manager and a certain dokument where they try to set gentoo standards from the outside.) I found out, that you loose nearly nothing by completely ignoring these people. What especially makes me sad is, that there are so many people here feeding the trolls. (And yes, sometimes I can't even hold myself back) --- Benedikt -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: Default blank lines for error, elog, einfo, etc
On Sun, Jun 15, 2008 at 12:02 PM, Peter Volkov [EMAIL PROTECTED] wrote: But speaking about names of options - -A and -B are easier to remember as -A stands for above and -B for below and grep users already knew that. for grep -A means after and -B before ;) -- Benedikt -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] dedicated USE-flag is inconsequent and confusing
I think it should be made consistent or it should be turned into a local use flag. no-* or *-only flag don't make sense in my opinion, because you can get the same with: -gui instead of nogui (maybe -gtk/-qt4/-kde or something would be even better) -* server instead of server-only (sure, this can only be done for each single package, but it looks cleaner to me than -only) Benedikt -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] RFC: lzma tarball usage
On Wed, May 7, 2008 at 3:23 PM, Mart Raudsepp [EMAIL PROTECTED] wrote: I'd be happy if some other unpacker is used than lzma-utils - one that does not depend on libstdc++ - I'm sure it can be done, heck it's done in integrated form in some other projects in less than a couple kilobytes of code for the unpacking from a VFS. Meanwhile please consider using the upstream provided .tar.gz tarballs instead and not roll patchsets in .lzma just cause you can. tar-1.20 has lzma support, so maybe it could handle this too, once it goes into stable -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] RFC: lzma tarball usage
Hi, I sent this to -dev to, but I think as an ordinary user I can't write there... On Wed, May 7, 2008 at 3:23 PM, Mart Raudsepp [EMAIL PROTECTED] wrote: I'd be happy if some other unpacker is used than lzma-utils - one that does not depend on libstdc++ - I'm sure it can be done, heck it's done in integrated form in some other projects in less than a couple kilobytes of code for the unpacking from a VFS. Meanwhile please consider using the upstream provided .tar.gz tarballs instead and not roll patchsets in .lzma just cause you can. tar-1.20 has lzma support, so maybe it could handle this too, once it goes into stable. -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] sqlite/sqlite3 useflag inconsistency
Hi out there, as I was told on bugzilla, I am taking this here. I do not know if this was proposed earlier, but I noticed, that USE=sqlite seems to just pull in any dev-db/sqlite, which in many cases does not really mean any, like DEPEND=sqlite? dev-db/sqlite would do, but something like DEPEND=sqlite? ( =dev-db/sqlite-3 ) ## from app-portage/eix/eix-0.10.3.ebuild While sqlite3 pulls in dev-db/sqlite-3* (At least it should, I have not really checked that one) In my humble opinion it would be nice to have a greater degree of control by separating this into two useflags, sqlite2 and sqlite3, just like e.g. qt3 and qt4 Regards, Benedikt -- gentoo-dev@lists.gentoo.org mailing list
