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.
It is needed for bootstrapping icedtea on platforms where there is no icedtea-bin.
Ok, that's some argument. You just offered fixing toolchain.eclass, thanks ;).
The dependency on sys-devel/gcc[awt] appears not to be a hard dependency but instead triggered by the USE=X.
(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 :).
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.
And I've just confirmed that both icedtea-6 and -7 can be successfully bootstrappem with gcj-jdk[-X].
please disregard 520728 I was meaning bug #513576
What exactly is the motivation here for crippling gcj?
(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?
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.
(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.
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.
(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.
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.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=e10da1c831456043bdbeca9d0ffb4dbd87f5d9da commit e10da1c831456043bdbeca9d0ffb4dbd87f5d9da Author: Jakov Smolić <jsmolic@gentoo.org> AuthorDate: 2022-05-17 19:02:31 +0000 Commit: Jakov Smolić <jsmolic@gentoo.org> CommitDate: 2022-05-17 19:07:43 +0000 dev-java/gcj-jdk: treeclean Closes: https://bugs.gentoo.org/531900 Closes: https://bugs.gentoo.org/465572 Signed-off-by: Jakov Smolić <jsmolic@gentoo.org> dev-java/gcj-jdk/files/javac.in | 57 ---------------- dev-java/gcj-jdk/gcj-jdk-5.4.0-r1.ebuild | 107 ------------------------------- dev-java/gcj-jdk/metadata.xml | 19 ------ profiles/package.mask | 1 - 4 files changed, 184 deletions(-)
