Sylpheed-Claws' ebuild defaults to USE="-imap". This is a highly bad idea, and it's already the fifth Gentoo user we're helping find out why IMAP doesn't work in Sylpheed-Claws. I wonder how many other users just stated that S-C was a broken piece of shit, and scraped it.
Please set USE="+imap" by default so that people actually get a mailer that handles the two major and unavoidable email protocols.
We can't do any such thing, not supported by portage.
*** This bug has been marked as a duplicate of 44796 ***
In this case I would like you to just remove the optional dependancy to libetpan:
imap? ( >=net-libs/libetpan-0.46 )
and just make it required.
See, set your use flags as needed like everyone else does. libetpan is not an unconditional dependency.
Jakub, you may have missed that I'm reporting this bug as a Sylpheed-Claws maintainer, not Gentoo user.
We are providing --disable-libetpan for *hardcore* CVS users who know what they're doing. not passing --disable-libetpan, if libetpan's not present, result in an error.
IMAP is an important part of a mailer, as I'm sure you'll agree. If you keep this bug closed without letting Marius (firstname.lastname@example.org, SC's ebuild maintainer) handle the issue, the solution will be very simple: we may just ship the next version with libetpan as a required dep, with no matching --disable flag.
Thank you for your attention.
And you may have missed the ever-lasting rants on mailing lists about bloat of use flags in default profiles. Plus the minute we remove imap use flag from the ebuild, someone will file a bug ranting about "oh noes, where's the IMAP use flag gone, don't force IMAP and redundant dependencies on me, I never use IMAP".
If you don't compile the thing with USE=imap, you won't have IMAP, pretty obvious. That's the whole point of that use flag. If users are filing upstream bugs about this, then close them as INVALID/PEBKAC. If you as upstream believe that solution for user stupidity is taking away the choice from users that are not stupid, oh well, not much we could do in that case.
Hmm, delicate issue. I'd rather want to keep the flag but I can understand your concern. And looking at the mailing list I see that there were some cases where it caused you (minor) trouble.
Lets make the following deal:
When SC-2.6 comes out and portage still doesn't support package default flags I'll drop the flag for that and the following versions. Does that sound acceptable?
I won't hoever drop it from the current ebiulds (including the 2.5.5 I'm about to commit) as this would cause even more trouble due to unnecessary rebuilds of existing installs.
thanks for your answer. Yes, that would be really nice to do that. On the other hand, Andrej Kacian tried to convince me of the fact dropping flags wasn't the Gentoo way, with more or less success (;-)) but enough to make me put big fat warnings in S-C's GUI, near every mention of "IMAP4" if libetpan's not available. So, the problem may be much less annoying in 2.6 even if you do nothing in the end.
Up to you to choose what you prefer :-)
Basically, I convinced Colin, that the choice whether or not build SC with IMAP support is straightforward and clearly visible for Gentoo users, as the "imap" USE flag is used by SC ebuild itself. I am very glad he decided the way he decided (warnings on application level), because this will make the casual user more informed in the future.
I also promised that I will look for a way to make "imap" USE flag on by default in Gentoo. From my search of the tree, not many packages use this flag (about 7 or so, iirc, I still have the list somewhere in my homedir), and for modern system, it really does make sense to have it enabled by default.
I suggest we wait until current discussions about per-package USE flags and/or package.use support in profiles come to their conclusions, and go from there.
I definitely want "imap" USE flag to be on by default in default profiles.
Well, Zac already committed the patch, so default flags are available in trunk, and the profile package.use doesn't even need the usual delay before it can be used.
(In reply to comment #9)
> Well, Zac already committed the patch, so default flags are available in trunk,
> and the profile package.use doesn't even need the usual delay before it can be
Thinking about it that comment was wrong. While using package.use wouldn't break anything it wouldn't necessarily work as the depgraph is generated before portage would be updated, so the flag would only get enabled after the install requiring a consistency rebuild.
*sigh*, really should find someone to sort out that EAPI stuff so it can be done via IUSE.
Colin, I'll delay dealing with this issue until 2.7 so it's combined with the rename (makes it easier to communicate to users to combine changes). Hate to break my promise, but this is a stupid situation right now for us as default use flags are technically available, just can't be used for compability reasons, and removing it just to readd it later sucks.
no problem. 2.6.0 makes the problem clear enough when it happens, anyway :)