Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 531900 - dev-java/gcj-jdk: drop USE=awt
Summary: dev-java/gcj-jdk: drop USE=awt
Status: CONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Andrew John Hughes
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-12-07 16:16 UTC by Michał Górny
Modified: 2020-11-15 11:39 UTC (History)
5 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2014-12-07 16:16:35 UTC
Can we lastrite gcj-jdk, please? I can't think of any real use case for it today. It's a revdep of jdk:1.5 (old) and a possible bootstrap dep of icedtea. But then, it never reached stable, and both cases can be less painfully satisfied using other packages.

This is also the only revdep of gcc[gcj,awt]. If we were able to remove awt support from gcc, we would avoid a lot of added complexity fixing the awt deps.
Comment 1 Chí-Thanh Christopher Nguyễn gentoo-dev 2014-12-07 21:55:48 UTC
It is needed for bootstrapping icedtea on platforms where there is no icedtea-bin.
Comment 2 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2014-12-07 21:59:57 UTC
Ok, that's some argument. You just offered fixing toolchain.eclass, thanks ;).
Comment 3 Chí-Thanh Christopher Nguyễn gentoo-dev 2014-12-08 13:33:06 UTC
The dependency on sys-devel/gcc[awt] appears not to be a hard dependency but instead triggered by the USE=X.
Comment 4 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2014-12-08 19:23:40 UTC
(In reply to Chí-Thanh Christopher Nguyễn from comment #3)
> The dependency on sys-devel/gcc[awt] appears not to be a hard dependency but
> instead triggered by the USE=X.

Are you aware if it is possible to bootstrap icedtea without USE=X? I can't check right now since I'm on battery :).
Comment 5 Francesco Riosa 2014-12-08 22:53:22 UTC
for pdftk, USE=X is totally not neded, bug 520728 is a minor problem and probably it's also not needed for bootstrapping icedtea (but this last one is a bet)

I should create a patch for bug 520728 and possibly solve the problem and even remove the alsa, X* dep.
But honestly I cannot guarantee to be able to do that.
Comment 6 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2014-12-08 23:05:48 UTC
And I've just confirmed that both icedtea-6 and -7 can be successfully bootstrappem with gcj-jdk[-X].
Comment 7 Francesco Riosa 2014-12-08 23:20:03 UTC
please disregard 520728 I was meaning bug #513576
Comment 8 Andrew John Hughes 2014-12-09 15:28:01 UTC
What exactly is the motivation here for crippling gcj?
Comment 9 Francesco Riosa 2014-12-12 10:58:57 UTC
(In reply to Andrew John Hughes from comment #8)
> What exactly is the motivation here for crippling gcj?

for gentoo gcc is a really fundamental package, not only in the packagers hands, also for the users.

Having gcc depending on X or on alsa it's really not desiderable, even if actually the only part of gcc broken by broken dependancies is gcj not c or c++.

gcj is also used very, very sporadically, by two packages, imule and pdftk, of which only pdftk is still relevant nowadays.
The remainig use is to bootstrap other java engines.

Since neither pdftk nor bootstrapping java need X lib. it would be very convenient for gentoo to remove the dependancy from gcj.

And  the consequences of the "crippling" would be nil.

Did I miss something?
Comment 10 Andrew John Hughes 2014-12-12 17:53:01 UTC
Sure, but these are optional dependencies; they only occur if the user requests GCC with gcj and X support.

There may be only a few packages that explicitly depend on gcj, but it's a) a JDK implementation which could potentially be used for any Java code and b) an end-user application which may be used by Java developers.

So, can you be more specific as to what you mean by "avoid a lot of added complexity fixing the awt dep"? I build gcc with gcj and AWT. I'm not aware of any issues and, if this support was to be removed, I'd have to fork and maintain the gcc eclass/ebuild myself, which is not ideal.

I would much prefer that the option is kept unless there is something truly problematic with the existing setup. One of the reasons I use Gentoo is that it gives me the option of building such packages with the options I want, rather than what is dictated to me by upstream.

I also don't like the idea of IcedTea having to rely on this crippled gcj to build. It may not be an issue now, but it could easily become one in some future update, and I don't want to be hitting this during a security update where limited time is available.
Comment 11 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2014-12-12 18:38:46 UTC
(In reply to Andrew John Hughes from comment #10)
> So, can you be more specific as to what you mean by "avoid a lot of added
> complexity fixing the awt dep"? I build gcc with gcj and AWT. I'm not aware
> of any issues and, if this support was to be removed, I'd have to fork and
> maintain the gcc eclass/ebuild myself, which is not ideal.

Just because you don't see issues *now* doesn't mean there aren't any. In 1-2 months time you won't be able to build it because emul-linux-x86 packages are being removed.

Additionally, gcc[gcj,awt] has a number of automagic dependencies that changed per version. The initial patch to fix all of that adds over 200 lines to the eclass. However, for proper EAPI support it will grow to around 600 lines. While I can't say the eclass is very optimal right now, the sole *dependency handling* code will take around 20% of the eclass. And *someone* will have to maintain that creepy code.

I'm looking for a simple solution here. I don't feel like we ought to maintain some wannabe code for the stupid sake of some pseudo-choice of having useless software lying around. If you need awt support in gcj, we can discuss. But adding 600 lines for something that is *unlikely* to be ever used is just stupid. If you really want that, why don't you handle it yourself?

That said, I'm not considering gcc a blocker anymore. If you can't figure out a solution in time and we end up having gcc with broken dependencies, I will just mask the flags as necessary to get people to upgrade.
Comment 12 Francesco Riosa 2014-12-13 09:27:04 UTC
would be a separate ebuild for gcj +awt be possible?
Would it be beneficial?

downside could be you need to rebuild a whole gcc for only gcj but build time is cpu time which count less than human time.
Comment 13 Andrew John Hughes 2015-02-09 17:22:55 UTC
(In reply to Michał Górny from comment #11)
> (In reply to Andrew John Hughes from comment #10)
> > So, can you be more specific as to what you mean by "avoid a lot of added
> > complexity fixing the awt dep"? I build gcc with gcj and AWT. I'm not aware
> > of any issues and, if this support was to be removed, I'd have to fork and
> > maintain the gcc eclass/ebuild myself, which is not ideal.
> 
> Just because you don't see issues *now* doesn't mean there aren't any. In
> 1-2 months time you won't be able to build it because emul-linux-x86
> packages are being removed.

Sure, that's exactly why I was asking what these issues are. I'm aware the emul-linux-x86 packages are going and I think it's a good thing.

> 
> Additionally, gcc[gcj,awt] has a number of automagic dependencies that
> changed per version. The initial patch to fix all of that adds over 200
> lines to the eclass. However, for proper EAPI support it will grow to around
> 600 lines. While I can't say the eclass is very optimal right now, the sole
> *dependency handling* code will take around 20% of the eclass. And *someone*
> will have to maintain that creepy code.
> 

I'm guessing most of this comes from multilib support for the X11/Gtk+ stack gcj+awt needs?

> I'm looking for a simple solution here. I don't feel like we ought to
> maintain some wannabe code for the stupid sake of some pseudo-choice of
> having useless software lying around. If you need awt support in gcj, we can
> discuss. But adding 600 lines for something that is *unlikely* to be ever
> used is just stupid. If you really want that, why don't you handle it
> yourself?
> 

I would end up handling it myself either way. I'd prefer not to have to maintain a gcc build out of tree.

> That said, I'm not considering gcc a blocker anymore. If you can't figure
> out a solution in time and we end up having gcc with broken dependencies, I
> will just mask the flags as necessary to get people to upgrade.
Comment 14 James Le Cuirot gentoo-dev 2015-08-19 22:43:31 UTC
Just a BTW, I've changed the X flag on gcj-jdk to awt to better reflect what it does. This has gnu_andrew's blessing. I also moved mgorny's masks from the amd64 to the base profile because no one should use this unless they know what they're doing.