Currently the netbeans ebild wants to download and compile the source code. Please add a -bin version that uses the downloadable installer, not the source. Justification follows. Now, I understand that it is preferable to build netbeans from source, but there are several very serious problems with this approach. home ~ # emerge --pretend netbeans | grep F [ebuild N F ] dev-java/jmx-1.2.1 [ebuild N F ] dev-java/sun-jaf-bin-1.0.2 [ebuild N F ] dev-java/javahelp-bin-2.0.02-r1 To build netbeans from source I have to get 3 sources by hand. Let's start with the first one. home ~ # emerge -f jmx <snip> * * Due to license restrictions, we cannot fetch the * distributables automagically. * * 1. Visit http://wwws.sun.com/software/communitysource/jmx/download.html and follow instructions * 2. Download jmx-1_2_1-scsl.zip Ok, I go to the page and am greeted with: You must first register or log into the Sun Download Center (SDLC) and agree to the license agreement before you can download this product. I scroll a little down the page to see: International Use Restrictions Due to limited intellectual property protection and enforcement in certain countries, the Java 2 Platform, Standard Edition source code may only be distributed to an authorized list of countries. You will not be able to access the source code if you are downloading from a country that is not on this list. We are continuously reviewing this list for addition of other countries. The mentioned country list is http://www.sun.com/software/communitysource/countries.xml . Guess what ! My country - Bulgaria, is not on the list. Most of the European Union ( or the world ) is not on the list either. I am sure you can imagine the level of frustration at this point. Building java code has very little benefits ( at least in comparison with building C/C++ code ) anyway, and forcing users to download sources from such extremely download-hostile sites as sun's is a wrong approach in my opinion. That said, please add a netbeans-bin ebuild to the tree. Reproducible: Always Steps to Reproduce:
even if we would add a binary version, there is no way around of downloading these files from sun. the
even if we would add a binary version, there is no way around of downloading these files from sun. theír license sucks, and we're not allowed to redistribute these files. a binary ebuild doesnt mean that we would allow a package to use packed jars. take a look at the following page why we build even java code from source: http://gentoo-wiki.com/Why_Build_Java_Code_From_Source
>>> take a look at the following page why we build even java code from >>> source: >>> http://gentoo-wiki.com/Why_Build_Java_Code_From_Source This is what I was refering to when I said 'compiling Netbeans from source is preferable'. However, I am not sure you fully understand the situation. Being a resident of Bulgaria, a country not in their white-list, I can not legally download the source files, but I can download the prebuilt files. Downloading the source code is _the_ right thing to do with open source projects - where the source is really available. In the Sun case, however, the availability is, IMO, purely theoretical. The license is such that the packages still are just a closed source package. I am not sure you are legally allowed to apply any tweaks or even security fixes. I am not asking you to drop the source-based ebuild. I am asking you to provide the user base with a choice. If you live in a white-listed country and don't mind providing all your personal information ( address, phone... ) - that's fine, you get all the benefits of source-based ebuilds. However if you don't want to provide biometric data, or don't live in a white listed country - you use the -bin packages, because this is the only legal option.
i understand what you wanted to say, but that doesnt change the fact that your idea introduces a new packed jar issue. we still have to remove other issues like that, and we're not going to add new ones to the tree.
Ok, am I correct in understanding that: 1) A jar issue = a jar that could *with reasonable effort on behalf of developers AND users* be compiled from source. If so, then my idea does not create jar issues since many users are not legally allowed to download the source. 2) You adopt the Sun white-list. You understand some of the users will not be able to emerge the SCSL-covered ebuilds and you don't see it as a problem. 3) You plan to drop dev-java/sun-jdk in favour of dev-java/sun-j2sdk. 5) You don't think that the SCSL in any way prevents you from applying patches in the ebuild, so the advantages of source ebuilds are fully exploited. 5) You don't think there is anything wrong with forcing users to provide personal information to a third party to emerge these three ebuilds. 6) You think that for the user the inconvenience of disclosing personal information is fully compensated by the power of source-based ebuilds. I am by no means trying to be mean, I simply want to fully understand your position on this matter, so we can find a way out of the problem.
you can also download and install a binary netbeans distribution manually. it comes with a lot of copies of jars, which have the same license restrictions as the ones you have to download manually if you use our package. the only thing is you dont have to signup yourself. it dont say that sun is a good company, i dont even say that these manually downloading foo is good. sun and these stupid license is crap, but we dont want to introduce more packed jar issues. the problem is as follows: xerces-1.3.1 and for example provide xerces.jar, there are maybe 15 or even 20 packages in the tree (just guessing) which use a xerces.jar. most java projects think they should pack every external library which is needed into the distfile. if you emerge all of these 20 packages you have to keep 20 copies of xerces.jar on your system, maybe another one which is in the dev-java/xerces package. we as a linux distribution cant do that, this simply sucks. if you feel comfortable while doing so you're allowed to do so but you cant demand that we're going to do this in our packages. if there is a security vulnerability or another showstopper in xerces now we would either have to wait for all upstream projects to replace the xerces.jar or we have to do this on our own. to avoid such an amount of work we just keep one single copy on a users system. that one can be replaced easily. keep in mind, the xerces.jar archive was just an example. there are a quite a lot of packages which are just often by many different packages. so, we dont introduce a new packed jar issue. if you feel mad about the license, blame sun. we havnt invented it, we just have to live with it and have to take care that we dont violate it.
clsong
>>> you can also download and install a binary netbeans distribution manually. Unfortunately it is not working. I have downloaded the installer ( netbeans-4_1-linux.bin ) but it complains it can not find a JDK installed, even if I manually point it to the directory with the JDK. For various reasons, I prefer portage to handle software, anyway. >>> which have the same license restrictions as >>> the ones you have to download manually No, they don't. To download the _prebuilt_ jars I don't have to be located in white-listed country, or register. I simply click download, accept the binary license ( which is not SCSL ) and download the file. The same procedure used for downloading the J2SDK. I can download the binary, but not the source. >>> if you emerge all of these 20 packages you have to keep 20 copies of xerces.jar Ok, I understand. I think I have worded the original request wrongly, sorry for that. The idea I am trying to comunicate is not to remove ( just an exmaple! ) xerces.jar and keep 20 copies of it, but rather that xerces.jar can be downloaded and installed precompiled. You still have one copy, only this copy was not built locally, but rather downloaded prebuilt. For the example - xerces.jar this makes little sense, since getting the source is not a problem. Yet, for the SCSL covered F restricted ebuilds it, IMO, makes sense because 1) Everyone can legally download the binary which is covered by 'Sun Microsystems, Inc. Binary Code License Agreement' and not everyone can download the source which is covered by SCSL 2) Even if you can download the source it requires registration. Why do you force the users to do this ? Why not provide them with an option to emerge jmx-bin instead of jmx ? You still have to replace or hardmask only _one_ package on security issues. There still is only _one_ copy of it. For example, of the three F restricted ebuilds need for netbeans, dev-java/jmx is a problem because it it SCSL covered. dev-java/sun-jaf-bin and dev-java/javahelp-bin are NOT a problem because they are covered by Sun's Binary License and downloading them is 5-click process, no registration required. Changing the resume, to hopefully better reflect the problem, as I see it.
wontfix, it stays the same. no new packed jar issues...
This is a valid bug. We are just a little off track at the beginning.
Created attachment 63875 [details] sun-bcla-jmx-1.2 Attaching the jmx license. Copied with drag-n-drop from http://tinyurl.com/d593u . Needed by the jmx-bin ebuild.
Created attachment 63876 [details] jmx-bin-1.2.1.ebuild The jmx-bin ebuild. Based on the jmx-1.2.1 ebuild in portage.
Created attachment 63877 [details, diff] commons-modeler-1.1.ebuild.patch Patch to dev-java/commons-modeler-1.1 to make it depend on either jmx-bin or jmx.
Created attachment 63878 [details, diff] tomcat-5.0.28-r4.ebuild.patch Patch to www-servers/tomcat-5.0.28-r4 to make it depend on either jmx-bin or jmx.
Using the attached ebuild and patches netbeans compiles and works fine. Cheers !
Created attachment 68495 [details] jmx-bin-1.2.1.ebuild Pointed DOWNLOADSITE to the correct place.
It is worth noting that dev-java/mx4j is an open source implementation of the JMX API. I had previously done some work to make packages use open source implementations instead of Sun's implementations here: http://svn.gentooexperimental.org/svn/java/free-java-overlay/ (Note: it probably depends on packages from the overlay here: http://svn.gentooexperimental.org/svn/java/gentoo-java-experimental/ ) I had luck with several other packages using mx4j instead of jmx, but had not tried tomcat or netbeans yet.
Given that Java 5 also contains JMX from the same guys who built the standalone package perhaps this should be a virtual package now Current choices are 1)sun jmx standalone 2)dependency met by Java 5 3) mx4j or others
jmx is now a virtual so this is fixed
