I stumbled across this today when updating jruby from the java team overlay, that now requires dev-util/jay; the jay command and man pages are already supplied by mono-2.4 itself, I guess it should be gone from there, and added as a dependency instead..
Upstream says that it shoul dprobably just not be installed from mono, I guess we can remove the binary and man pag.
's true. I even searched for the package once but drew blanks.
After looking at the jay ebuild in java-overlay I believe it is in a state where it can go into the main tree. Believe the only thing extra it should have is a blocker on mono. I will do some testing etc and move it into the main tree tonight (+12 hours), then mono can do with it as they wish. With the blocker should it just be !<=dev-lang/mono-2.4
Ok it is now in the tree dev-util/jay dotnet ppl do your worst.
I've added a mono 2.4-r1 that simply doesn't install jay any longer (removes it after install), as suggested by upstream.
Please tell me dev-util/jay also does C# ? If it does not, would you please tell me how you can consider it a full replacement? Masked till we have a satisfactory resolution.
have you spoken with Mono upstream about this? They never intended that to be installed, it was a glitch that it was. Do you think there is _anything_ in tree that is using jay for C#? I don't think so, the Mono project has NOTHING that uses the jay version in Mono beside mcs itself.
First of all: jay needs skeleton files to be installed to be usable. They're there in the tarball. They're not being installed. Has anyone diffed the skeleton.cs installed by mono and jay? Please do so. Quoting from the INSTALL file which *noone* apparently bothered to read: installation instructions (0) if you work with SSCLI, make sure the path to this directory (after resolving any symbolic links) does not contain blanks -- blanks seem to confuse at least SSCLI on MacOS X 10.2.2. (1) in the current directory, execute 'make'. This should at least create jay/jay.$(OSTYPE). If a suitable JDK is installed, it will also create java/yydebug.jar, java/arith/{arith,tables}.jar, and java/recover/{recover,tables}.jar. If a suitable SSCLI is installed, it will also create cs/yyDebug.dll and install it with a fake strong name in the GAC, cs/arith/arith.exe, and cs/recover/recover.exe. (2) in the current directory, execute 'make test'. This should at least run the regression test in conflict/. If a suitable JDK is installed, it will also test in java/{arith,recover}/. If a suitable SSCLI is installed, it will also test in cs/{arith,recover}/. (3) copy jay/jay.$(OSTYPE) to a convenient location. (4) copy some of {java,cs}/skeleton.* to a convenient location. (5) you might want to install a skript somewhere with something like #!/bin/sh exec [path]/jay < [path]/[skeleton] "$@" So, plz2make your replacement work with Java and Mono before you fix this again.Kthx. Also looks like there's a test suite in there somewhere.
That's Java's team problem for what I'm concerned. Is there _any_ reason for which you want Mono to keep installing something *that is not supposed to be installing*? Note that I didn't add _any_ depend at all on jay for Mono because _it won't ever use the installed copy_, the version bundled is modified and used and useful only to build mcs. The fix mono-side would have been valid even if jay was never present in tree. Again, can you bring any reason on why we can't just remove jay?
(In reply to comment #9) > That's Java's team problem for what I'm concerned. Then leave it to them. It's true that there are no in-tree users of jay, but that doesn't mean that it's not a useful tool for users. The thing you are proposing to replace it with does not have the same functionality. http://qa.debian.org/popcon.php?package=mono (look under mono-jay) This thing obviously has users. Don't get me wrong, I'm all for getting it replaced with the original package (YAY for modularization), but please make sure the replacement actually works.
While not in tree there is one package in an official overlay that is broken by this (jruby). And As I said, that jay should not be used. Have you spoken with upstream? I asked explicitly if the jay copy in mono should be useful to the end user and they answered that it should not be used. Sorry but I don't count on Debian having done the right thing, I never do; does Novell package it?
(In reply to comment #11) > While not in tree there is one package in an official overlay that is broken by > this (jruby). Which brings me to my rant about Java team and their Godzilla overlays. > And As I said, that jay should not be used. Have you spoken with > upstream? I asked explicitly if the jay copy in mono should be useful to the > end user and they answered that it should not be used. Perhaps you should ask them if it's more useful than a jay that does not work with C#. The answer might be different there. > Sorry but I don't count on Debian having done the right thing, I never do; does > Novell package it? Mono's jay has users, regardless of upstream intentions. I've pointed out how dev-util/jay can be fixed.
*** Bug 268599 has been marked as a duplicate of this bug. ***
Created attachment 190862 [details, diff] Fix for jay's perceived failings as-is @Java herd, could one of you guys take a look at this?
(In reply to comment #14) > Created an attachment (id=190862) [edit] > Fix for jay's perceived failings as-is > > @Java herd, could one of you guys take a look at this? > If you have optional java support java-pkg-opt-2 eclass should be used.
Created attachment 190897 [details, diff] Change to use java-pkg-opt-2
Patch has been applied to jay. Thank you Peter. I will let you close this once mono has been unmasked.
2.4-r2 is in tree with a fix for bug 257313. Closing.
*** Bug 269790 has been marked as a duplicate of this bug. ***
