Re: [aur-general] Java name guideliness
On Wed, Sep 10, 2014 at 4:22 AM, Det nimetonma...@gmail.com wrote: Enough of that already. Why I chose the java-8-jdk naming comes from the fact that java-8-openjdk sounds like we're trying to do java-major version-project name. The project name of JDK is not Oracle JDK, and that's why I chose it. Now, OpenJDK apparently still calls these projects by their base name[3], but _I_ would still prefer (read: I don't refuse; I prefer) having packages called jdk8-openjdk and jdk that install in /usr/lib/jvm/java-8-openjdk/ and /usr/lib/jvm/java-8-jdk/, respectively. This also means we can currently do: $ man java-openjdk8 $ man java-jdk8 To access the man pages. For what it's worth, I support this naming scheme. Kind regards, Marcel
Re: [aur-general] Java name guideliness
2014-09-23 13:13 GMT-03:00 Marcel Korpel marcel.li...@gmail.com: On Wed, Sep 10, 2014 at 4:22 AM, Det nimetonma...@gmail.com wrote: Enough of that already. Why I chose the java-8-jdk naming comes from the fact that java-8-openjdk sounds like we're trying to do java-major version-project name. The project name of JDK is not Oracle JDK, and that's why I chose it. Now, OpenJDK apparently still calls these projects by their base name[3], but _I_ would still prefer (read: I don't refuse; I prefer) having packages called jdk8-openjdk and jdk that install in /usr/lib/jvm/java-8-openjdk/ and /usr/lib/jvm/java-8-jdk/, respectively. This also means we can currently do: $ man java-openjdk8 $ man java-jdk8 To access the man pages. For what it's worth, I support this naming scheme. Kind regards, Marcel I preffer ad a hyphen after the version as all the other arch packages do when is needed. so my vote is for : * java-openjdk-8 * java-jdk-8 -- *Pablo Lezaeta*
Re: [aur-general] Java name guideliness
On Tue, Sep 23, 2014 at 05:22:52PM -0300, Pablo Lezaeta Reyes wrote: 2014-09-23 13:13 GMT-03:00 Marcel Korpel marcel.li...@gmail.com: On Wed, Sep 10, 2014 at 4:22 AM, Det nimetonma...@gmail.com wrote: Enough of that already. Why I chose the java-8-jdk naming comes from the fact that java-8-openjdk sounds like we're trying to do java-major version-project name. The project name of JDK is not Oracle JDK, and that's why I chose it. Now, OpenJDK apparently still calls these projects by their base name[3], but _I_ would still prefer (read: I don't refuse; I prefer) having packages called jdk8-openjdk and jdk that install in /usr/lib/jvm/java-8-openjdk/ and /usr/lib/jvm/java-8-jdk/, respectively. This also means we can currently do: $ man java-openjdk8 $ man java-jdk8 To access the man pages. For what it's worth, I support this naming scheme. Kind regards, Marcel I preffer ad a hyphen after the version as all the other arch packages do when is needed. so my vote is for : * java-openjdk-8 * java-jdk-8 -- *Pablo Lezaeta* All the other arch packages? Really? $ pacman -Ssq | grep -Ec '[^-][0-9]+$' 322 $ pacman -Ssq | grep -Ec -- '-[0-9]+$' 5
Re: [aur-general] Java name guideliness
2014-09-23 17:39 GMT-03:00 Dave Reisner d...@falconindy.com: On Tue, Sep 23, 2014 at 05:22:52PM -0300, Pablo Lezaeta Reyes wrote: 2014-09-23 13:13 GMT-03:00 Marcel Korpel marcel.li...@gmail.com: On Wed, Sep 10, 2014 at 4:22 AM, Det nimetonma...@gmail.com wrote: Enough of that already. Why I chose the java-8-jdk naming comes from the fact that java-8-openjdk sounds like we're trying to do java-major version-project name. The project name of JDK is not Oracle JDK, and that's why I chose it. Now, OpenJDK apparently still calls these projects by their base name[3], but _I_ would still prefer (read: I don't refuse; I prefer) having packages called jdk8-openjdk and jdk that install in /usr/lib/jvm/java-8-openjdk/ and /usr/lib/jvm/java-8-jdk/, respectively. This also means we can currently do: $ man java-openjdk8 $ man java-jdk8 To access the man pages. For what it's worth, I support this naming scheme. Kind regards, Marcel I preffer ad a hyphen after the version as all the other arch packages do when is needed. so my vote is for : * java-openjdk-8 * java-jdk-8 -- *Pablo Lezaeta* All the other arch packages? Really? $ pacman -Ssq | grep -Ec '[^-][0-9]+$' 322 $ pacman -Ssq | grep -Ec -- '-[0-9]+$' 5 Ironically this show how bad I'm greep-ing, Well if is for follow the main rule go for the *java-openjdk8 and *java-jdk8 I will be happywhit this one specifically -- *Pablo Lezaeta*
Re: [aur-general] Java name guideliness
On Tue, Sep 23, 2014 at 10:39 PM, Dave Reisner d...@falconindy.com wrote: All the other arch packages? Really? $ pacman -Ssq | grep -Ec '[^-][0-9]+$' 322 This is not a *completely* fair search, as this resultset also includes bin86, libx264, xf86-video-i740 and v8, where the number parts are not indicating version numbers. ;-) Kind regards, Marcel
Re: [aur-general] Java name guideliness
On Wed, Sep 24, 2014 at 01:29:44AM +0200, Marcel Korpel wrote: On Tue, Sep 23, 2014 at 10:39 PM, Dave Reisner d...@falconindy.com wrote: All the other arch packages? Really? $ pacman -Ssq | grep -Ec '[^-][0-9]+$' 322 This is not a *completely* fair search, as this resultset also includes bin86, libx264, xf86-video-i740 and v8, where the number parts are not indicating version numbers. ;-) Kind regards, Marcel Unfortunately, this also holds true of the other search. spring-1944 isn't version 1944, but an open source RTS called Spring: 1944. Similarly, 'gl-177' is a flight simulator called GL-177. This inflates the number of packages by 60%. Unfair! d
Re: [aur-general] Java name guideliness
2014-09-21 0:27 GMT-03:00 Kevin Ott supercodingmon...@gmail.com:
On Saturday, September 20, 2014 10:19:52 PM Pablo Lezaeta Reyes wrote:
If you know how not topposting using gmail please that will help me, and
as
I stated I use gmail.
It's actually pretty easy, although a bit more involved than it should be.
When you hit reply you'll notice that at the bottom left corner of the edit
box will have a button with three dots in it. Click on that (it will show
the content of the message you are replying to) and move your cursor to the
bottom of that text and reply there instead of at the top.
Well thanks, really.
Now what are the options?
java-jdk/jre-5/6/7/devel or {,open}jdk/jre-5/6/7/devel
I keep thinking that the first is better but the seccond is what I think is
the one who will ended used.
--
*Pablo Lezaeta*
Re: [aur-general] Java name guideliness
If you know how not topposting using gmail please that will help me, and as I stated I use gmail. and what part ou not underestand? All the official packagen in the official repos that append a version they append it as pkgname---version and NOT pkgnameversion as is now for jre/jdk(7,6) 2014-09-19 22:46 GMT-03:00 Det nimetonma...@gmail.com: On Fri Sep 19 00:02:27 EDT 2014, Pablo Lezaeta Reyes wrote: but upstream name not necesary mean the name that the encapsulate that contain the package need to be named. There ar a handfull either throw arch and aur history and actual named packages that not follow the name. but too looking to the other packages in aur the version is alwas separate from the name of the package so in the end namepackage-version will be used. Upstream not give a version or give a - or a plain space for versions if ou are going to follow uptream. I'm sorry, but I didn't understand any of this. Also, please don't top-post, as already stated. Det -- *Pablo Lezaeta*
Re: [aur-general] Java name guideliness
On Saturday, September 20, 2014 10:19:52 PM Pablo Lezaeta Reyes wrote: If you know how not topposting using gmail please that will help me, and as I stated I use gmail. It's actually pretty easy, although a bit more involved than it should be. When you hit reply you'll notice that at the bottom left corner of the edit box will have a button with three dots in it. Click on that (it will show the content of the message you are replying to) and move your cursor to the bottom of that text and reply there instead of at the top.
Re: [aur-general] Java name guideliness
On Fri Sep 19 00:02:27 EDT 2014, Pablo Lezaeta Reyes wrote: but upstream name not necesary mean the name that the encapsulate that contain the package need to be named. There ar a handfull either throw arch and aur history and actual named packages that not follow the name. but too looking to the other packages in aur the version is alwas separate from the name of the package so in the end namepackage-version will be used. Upstream not give a version or give a - or a plain space for versions if ou are going to follow uptream. I'm sorry, but I didn't understand any of this. Also, please don't top-post, as already stated. Det
Re: [aur-general] Java name guideliness
but upstream name not necesary mean the name that the encapsulate that contain the package need to be named. There ar a handfull either throw arch and aur history and actual named packages that not follow the name. but too looking to the other packages in aur the version is alwas separate from the name of the package so in the end namepackage-version will be used. Upstream not give a version or give a - or a plain space for versions if ou are going to follow uptream. 2014-09-18 16:54 GMT-03:00 Det nimetonma...@gmail.com: On Thu Sep 11 14:02:41 EDT 2014, Pablo Lezaeta Reyes wrote: If look to the pther packages (not java) the fewers who need a version they apend the versión at the endm so for consistency whit the all others packages I think is better keep the version at the end: vendor-jre/jdk-version: oracle/openjdk-jre-7/8 We can't do that, because our own upstream (the OpenJDK packager) alredy decided on it. To change it you're going to have to start a bug report/feature request on our own packages. If you can change _his_ mind, then we can talk about implementing that in the AUR as well. On Thu Sep 11 18:13:11 EDT 2014, Justin Dray wrote: The fact that one naming convention or the other being chosen is still not the issue, it's the fact that in the interim there are *both* packages in there. Yes, I get that you're eager to get whatever parties out of there ASAP, and sort it out later. Unfortunately, that's not how it's going to play out and this discussion so far has prevented the proper way from happening as well, as I was already pointed out some time ago. Therefore, I'm taking this and my suggestions back directly to the respective maintainers, and only if they want to continue it here, we will. Det -- *Pablo Lezaeta*
Re: [aur-general] Java name guideliness
More input. On 09/09/14 23:08, Justin Dray wrote: Part of the issue here however is that now there are both jre7 and jre7-oracle and so on duplicate packages in the AUR. Yes, but why are you bringing that up as an issue, as we are trying to decide exactly which one to keep before just removing the other. I think you know neither I nor the maintainers were never for leaving both - we just don't, at this point, know which one. I mean, isn't that like saying: A: We need to figure out the right type of fuel for this car. B: Yes, but the issue is the car doesn't move. A: Well. Yeah.. On 10/09/14 01:20, Pablo Lezaeta Reyes wrote: Refusal is what happend when two or more not agree in something I never mention who is refusing who cause both side from the vewpoint of the other is refusing the other side of view. Who is refusing whom? One not want use the other guidelines, so using the bare meaning of refusal that mean not accdept the other. But you see you hit the problem right there. We don't _have_ a guideline for the naming. That's what the debate is about: we are trying to establish one. or this is sick. Maybe you are overreacting (or I not expresed it corretly), I mean that is no sane (synonimous of ill synonimos of sick) Ok. Just use makes no sense. I thing that is bvous that all are java. so why not something like providerjre/jdk-version: openjdk-9 or oraclejdk-7. The names in the official repos are jre/jdk8-openjdk, so that's why the previous suggestion was jre/jdk8-oracle. However, I believe it should be pretty obvious which one you're dealing with, if a package is named just jre or jdk (isn't that the ultimate KISS?). The java- prefix is used for archlinux-java (extra/java-common), and already decided upstream. That I would refuse to divert from. On 10/09/14 08:38, P. A. López-Valencia wrote: My opinion is that the AUR should follow the example set by the Arch Linux developers in the extra repository and everything else must go, starting with the jdk/jre pair as clarity trumps over brevity in naming Explained above. As far as I know in all the years I maintained these things, nobody ever confused them with OpenJDK, because that's always mentioned. On 10/09/14 07:43, Rafael Ferreira wrote: +1 for 'java-8-jdk' and 'java-8-jre' is a good name. Just would be nice to have the word Oracle in the description, so a yaourt -Ss oracle could easily track your package. I agree. Added. Again, to summarize the Java guidelines: Package name: project nameversion-vendor (e.g. jdk8-openjdk, jre7-openjdk) archlinux-java name: java-version-vendor(/jre) (e.g. java-8-openjdk, java-7-openjdk/jre) And what I support for AUR (same as what we had before): Package name: project name(version) (e.g. jdk, jre7) archlinux-java name: java-version-project name(/jre) (e.g. java-8-jdk, java-7-jre/jre) (just java-7-jre unsupported by archlinux-java) Det
Re: [aur-general] Java name guideliness
If look to the pther packages (not java) the fewers who need a version they apend the versión at the endm so for consistency whit the all others packages I think is better keep the version at the end: vendor-jre/jdk-version: oracle/openjdk-jre-7/8 2014-09-11 13:41 GMT-03:00 Det nimetonma...@gmail.com: More input. On 09/09/14 23:08, Justin Dray wrote: Part of the issue here however is that now there are both jre7 and jre7-oracle and so on duplicate packages in the AUR. Yes, but why are you bringing that up as an issue, as we are trying to decide exactly which one to keep before just removing the other. I think you know neither I nor the maintainers were never for leaving both - we just don't, at this point, know which one. I mean, isn't that like saying: A: We need to figure out the right type of fuel for this car. B: Yes, but the issue is the car doesn't move. A: Well. Yeah.. On 10/09/14 01:20, Pablo Lezaeta Reyes wrote: Refusal is what happend when two or more not agree in something I never mention who is refusing who cause both side from the vewpoint of the other is refusing the other side of view. Who is refusing whom? One not want use the other guidelines, so using the bare meaning of refusal that mean not accdept the other. But you see you hit the problem right there. We don't _have_ a guideline for the naming. That's what the debate is about: we are trying to establish one. or this is sick. Maybe you are overreacting (or I not expresed it corretly), I mean that is no sane (synonimous of ill synonimos of sick) Ok. Just use makes no sense. I thing that is bvous that all are java. so why not something like providerjre/jdk-version: openjdk-9 or oraclejdk-7. The names in the official repos are jre/jdk8-openjdk, so that's why the previous suggestion was jre/jdk8-oracle. However, I believe it should be pretty obvious which one you're dealing with, if a package is named just jre or jdk (isn't that the ultimate KISS?). The java- prefix is used for archlinux-java (extra/java-common), and already decided upstream. That I would refuse to divert from. On 10/09/14 08:38, P. A. López-Valencia wrote: My opinion is that the AUR should follow the example set by the Arch Linux developers in the extra repository and everything else must go, starting with the jdk/jre pair as clarity trumps over brevity in naming Explained above. As far as I know in all the years I maintained these things, nobody ever confused them with OpenJDK, because that's always mentioned. On 10/09/14 07:43, Rafael Ferreira wrote: +1 for 'java-8-jdk' and 'java-8-jre' is a good name. Just would be nice to have the word Oracle in the description, so a yaourt -Ss oracle could easily track your package. I agree. Added. Again, to summarize the Java guidelines: Package name: project nameversion-vendor (e.g. jdk8-openjdk, jre7-openjdk) archlinux-java name: java-version-vendor(/jre) (e.g. java-8-openjdk, java-7-openjdk/jre) And what I support for AUR (same as what we had before): Package name: project name(version) (e.g. jdk, jre7) archlinux-java name: java-version-project name(/jre) (e.g. java-8-jdk, java-7-jre/jre) (just java-7-jre unsupported by archlinux-java) Det -- *Pablo Lezaeta*
Re: [aur-general] Java name guideliness
The fact that one naming convention or the other being chosen is still not the issue, it's the fact that in the interim there are *both* packages in there. There should only be duplicates of the same package for as long as it takes for a merge request to be processed. This is clearly not the case, and I think one of the more annoying points that has been brought up in this thread. In fact it probably never would have come up on this mailing list if there weren't 2 subtly divergent jdk/jre packages in the aur simultaneously. Regards, Justin Dray E: jus...@dray.be M: 0433348284 On Fri, Sep 12, 2014 at 4:02 AM, Pablo Lezaeta Reyes prfl...@gmail.com wrote: If look to the pther packages (not java) the fewers who need a version they apend the versión at the endm so for consistency whit the all others packages I think is better keep the version at the end: vendor-jre/jdk-version: oracle/openjdk-jre-7/8 2014-09-11 13:41 GMT-03:00 Det nimetonma...@gmail.com: More input. On 09/09/14 23:08, Justin Dray wrote: Part of the issue here however is that now there are both jre7 and jre7-oracle and so on duplicate packages in the AUR. Yes, but why are you bringing that up as an issue, as we are trying to decide exactly which one to keep before just removing the other. I think you know neither I nor the maintainers were never for leaving both - we just don't, at this point, know which one. I mean, isn't that like saying: A: We need to figure out the right type of fuel for this car. B: Yes, but the issue is the car doesn't move. A: Well. Yeah.. On 10/09/14 01:20, Pablo Lezaeta Reyes wrote: Refusal is what happend when two or more not agree in something I never mention who is refusing who cause both side from the vewpoint of the other is refusing the other side of view. Who is refusing whom? One not want use the other guidelines, so using the bare meaning of refusal that mean not accdept the other. But you see you hit the problem right there. We don't _have_ a guideline for the naming. That's what the debate is about: we are trying to establish one. or this is sick. Maybe you are overreacting (or I not expresed it corretly), I mean that is no sane (synonimous of ill synonimos of sick) Ok. Just use makes no sense. I thing that is bvous that all are java. so why not something like providerjre/jdk-version: openjdk-9 or oraclejdk-7. The names in the official repos are jre/jdk8-openjdk, so that's why the previous suggestion was jre/jdk8-oracle. However, I believe it should be pretty obvious which one you're dealing with, if a package is named just jre or jdk (isn't that the ultimate KISS?). The java- prefix is used for archlinux-java (extra/java-common), and already decided upstream. That I would refuse to divert from. On 10/09/14 08:38, P. A. López-Valencia wrote: My opinion is that the AUR should follow the example set by the Arch Linux developers in the extra repository and everything else must go, starting with the jdk/jre pair as clarity trumps over brevity in naming Explained above. As far as I know in all the years I maintained these things, nobody ever confused them with OpenJDK, because that's always mentioned. On 10/09/14 07:43, Rafael Ferreira wrote: +1 for 'java-8-jdk' and 'java-8-jre' is a good name. Just would be nice to have the word Oracle in the description, so a yaourt -Ss oracle could easily track your package. I agree. Added. Again, to summarize the Java guidelines: Package name: project nameversion-vendor (e.g. jdk8-openjdk, jre7-openjdk) archlinux-java name: java-version-vendor(/jre) (e.g. java-8-openjdk, java-7-openjdk/jre) And what I support for AUR (same as what we had before): Package name: project name(version) (e.g. jdk, jre7) archlinux-java name: java-version-project name(/jre) (e.g. java-8-jdk, java-7-jre/jre) (just java-7-jre unsupported by archlinux-java) Det -- *Pablo Lezaeta*
Re: [aur-general] Java name guideliness
2014-09-09 23:22 GMT-03:00 Det nimetonma...@gmail.com: Enough of that already. Why I chose the java-8-jdk naming comes from the fact that java-8-openjdk sounds like we're trying to do java-major version-project name. The project name of JDK is not Oracle JDK, and that's why I chose it. Now, OpenJDK apparently still calls these projects by their base name[3], but _I_ would still prefer (read: I don't refuse; I prefer) having packages called jdk8-openjdk and jdk that install in /usr/lib/jvm/java-8-openjdk/ and /usr/lib/jvm/java-8-jdk/, respectively. +1 for 'java-8-jdk' and 'java-8-jre' is a good name. Just would be nice to have the word Oracle in the description, so a yaourt -Ss oracle could easily track your package. Rafael Ferreira
Re: [aur-general] Java name guideliness
On 10/09/14 00:20, Pablo Lezaeta Reyes wrote: First of all, I really *really* urge you to stop using phrases like refusal Refusal is what happend when two or more not agree in something I never mention who is refusing who cause both side from the vewpoint of the other is refusing the other side of view. In fact, _nowhere_ do I see anybody refusing to do _anything_. One not want use the other guidelines, so using the bare meaning of refusal that mean not accdept the other. Maybe the way I use the word not is the correct, you knoe false friends in english. or this is sick. Maybe you are overreacting (or I not expresed it corretly), I mean that is no sane (synonimous of ill synonimos of sick) having all the packages with different names, that is simply confusing the user who want install a simple jdk packages (me, I ended more confusin with this). I certainly understood perfectly well the meaning and the spirit of your words, and the native speakers in this thread have too. As maintainer of a fairly visible Java-based package, vuze, I have always wondered about the chaotic situation of java runtimes in the AUR both in the packaging and the naming. Thus, I have actively refused to support anything that doesn't include a provides=java-runtime, punting the whole problem to the packaging upstreams. The creation of java-common has eased my work, although it took me off guard at first and I did a couple of silly packaging mistakes working around the new features that one of my users kindly pointed out to me. I accepted his corrections humbly and ashamed for not having understood the first time. My opinion is that the AUR should follow the example set by the Arch Linux developers in the extra repository and everything else must go, starting with the jdk/jre pair as clarity trumps over brevity in naming.
[aur-general] Java name guideliness
Since the new java-common come to the repo Is now possible have multiple java, but this bring and open another issue, java naming scheme the guy in jre/jdk[1] and jre-devel and jdk-devel refuse to follow a convention non generic name and the other maintaining jre7/jdk7 [2] and jre7-oracle/jdk7-oracle that do the same [3] refuse to accept or merge jre7-oracle into jre7 for the same reason even if the jre-oracle was merged into jre, this is a chaos. Many packages doing the same in different verion having different name conventions and ALL arguin bein correct. There is need to a conventional standar name scheme or this will be worst, instead to be kiss this is sick. There is a name scheme or name convention to follow? [1] https://aur.archlinux.org/packages/jdk/ [2] https://aur.archlinux.org/packages/jdk7/ [3] https://aur.archlinux.org/packages/jdk7-oracle/ There is also a jdk5-compat. Also mergins as ben posponed until name convention come. -- *Pablo Lezaeta*
Re: [aur-general] Java name guideliness
Agreed, someone complained on one of my java packages that it was using the incorrect path for oracle java from the aur, and upon inspection I noticed these multiple packages providing the same thing, none of which work as they should be. I assumed they would have fixed it since that was only a short time after the new java common stuff, but it appears that they may need some assistance with that task. Regards, Justin Dray E: jus...@dray.be M: 0433348284 On Wed, Sep 10, 2014 at 8:18 AM, Pablo Lezaeta Reyes prfl...@gmail.com wrote: Since the new java-common come to the repo Is now possible have multiple java, but this bring and open another issue, java naming scheme the guy in jre/jdk[1] and jre-devel and jdk-devel refuse to follow a convention non generic name and the other maintaining jre7/jdk7 [2] and jre7-oracle/jdk7-oracle that do the same [3] refuse to accept or merge jre7-oracle into jre7 for the same reason even if the jre-oracle was merged into jre, this is a chaos. Many packages doing the same in different verion having different name conventions and ALL arguin bein correct. There is need to a conventional standar name scheme or this will be worst, instead to be kiss this is sick. There is a name scheme or name convention to follow? [1] https://aur.archlinux.org/packages/jdk/ [2] https://aur.archlinux.org/packages/jdk7/ [3] https://aur.archlinux.org/packages/jdk7-oracle/ There is also a jdk5-compat. Also mergins as ben posponed until name convention come. -- *Pablo Lezaeta*
Re: [aur-general] Java name guideliness
On Wed, Sep 10, 2014 at 8:18 AM, Pablo Lezaeta Reyes prflr88 at gmail.com wrote: Since the new java-common come to the repo Is now possible have multiple java, but this bring and open another issue, java naming scheme the guy in jre/jdk[1] and jre-devel and jdk-devel refuse to follow a convention non generic name and the other maintaining jre7/jdk7 [2] and jre7-oracle/jdk7-oracle that do the same [3] refuse to accept or merge jre7-oracle into jre7 for the same reason even if the jre-oracle was merged into jre, this is a chaos. Many packages doing the same in different verion having different name conventions and ALL arguin bein correct. There is need to a conventional standar name scheme or this will be worst, instead to be kiss this is sick. There is a name scheme or name convention to follow? First of all, I really *really* urge you to stop using phrases like refusal or this is sick. If that really was the case, it would only split all parties further. It's not refusal to talk something through before doing it. In fact, _nowhere_ do I see anybody refusing to do _anything_. The talk in jdk7[1] is discussion on the appropriate name, and what I told everybody both in there and jdk[2] was my view on things and why I did what I had done (use jdk/java-8-jdk as the name, rather than jdk8-oracle/java-8-oracle). You realise how unbelievably easy it is for me to revert to the jdk8-oracle approach, if that winds up being the consensus? Or if I somehow wouldn't, then how easy would it be to kick me off from maintaining that thing? Enough of that already. Why I chose the java-8-jdk naming comes from the fact that java-8-openjdk sounds like we're trying to do java-major version-project name. The project name of JDK is not Oracle JDK, and that's why I chose it. Now, OpenJDK apparently still calls these projects by their base name[3], but _I_ would still prefer (read: I don't refuse; I prefer) having packages called jdk8-openjdk and jdk that install in /usr/lib/jvm/java-8-openjdk/ and /usr/lib/jvm/java-8-jdk/, respectively. This also means we can currently do: $ man java-openjdk8 $ man java-jdk8 To access the man pages. I really didn't like the following at all: $ man java-openjdk8 $ man java8-oracle [1] = https://aur.archlinux.org/packages/jdk7/ [2] = https://aur.archlinux.org/packages/jdk/ [3] = http://openjdk.java.net/projects/jdk8/ Det
Re: [aur-general] Java name guideliness
Part of the issue here however is that now there are both jre7 and jre7-oracle and so on duplicate packages in the AUR. If someone says 'oh, i need oracle jdk, I can search on the AUR for that.' Well now they have to go and read all of the comments and look around on the wiki/mailing lists/forums to figure out which one they actually want. And it's not even a dispute between different maintainers, 'joschi' is the maintainer for both packages and are seemingly totally different; different groups, different upstream urls, different dependencies, different provides/conflicts. It also appears that jre8-oracle was merged in to jre package recently, so there is another discrepancy in the naming there. I'm not fussed one way or another on the naming, but by having both, I've really got to agree with Pablo; it's far from KISS. Regards, Justin Dray E: jus...@dray.be M: 0433348284 On Wed, Sep 10, 2014 at 12:22 PM, Det nimetonma...@gmail.com wrote: On Wed, Sep 10, 2014 at 8:18 AM, Pablo Lezaeta Reyes prflr88 at gmail.com wrote: Since the new java-common come to the repo Is now possible have multiple java, but this bring and open another issue, java naming scheme the guy in jre/jdk[1] and jre-devel and jdk-devel refuse to follow a convention non generic name and the other maintaining jre7/jdk7 [2] and jre7-oracle/jdk7-oracle that do the same [3] refuse to accept or merge jre7-oracle into jre7 for the same reason even if the jre-oracle was merged into jre, this is a chaos. Many packages doing the same in different verion having different name conventions and ALL arguin bein correct. There is need to a conventional standar name scheme or this will be worst, instead to be kiss this is sick. There is a name scheme or name convention to follow? First of all, I really *really* urge you to stop using phrases like refusal or this is sick. If that really was the case, it would only split all parties further. It's not refusal to talk something through before doing it. In fact, _nowhere_ do I see anybody refusing to do _anything_. The talk in jdk7[1] is discussion on the appropriate name, and what I told everybody both in there and jdk[2] was my view on things and why I did what I had done (use jdk/java-8-jdk as the name, rather than jdk8-oracle/java-8-oracle). You realise how unbelievably easy it is for me to revert to the jdk8-oracle approach, if that winds up being the consensus? Or if I somehow wouldn't, then how easy would it be to kick me off from maintaining that thing? Enough of that already. Why I chose the java-8-jdk naming comes from the fact that java-8-openjdk sounds like we're trying to do java-major version-project name. The project name of JDK is not Oracle JDK, and that's why I chose it. Now, OpenJDK apparently still calls these projects by their base name[3], but _I_ would still prefer (read: I don't refuse; I prefer) having packages called jdk8-openjdk and jdk that install in /usr/lib/jvm/java-8-openjdk/ and /usr/lib/jvm/java-8-jdk/, respectively. This also means we can currently do: $ man java-openjdk8 $ man java-jdk8 To access the man pages. I really didn't like the following at all: $ man java-openjdk8 $ man java8-oracle [1] = https://aur.archlinux.org/packages/jdk7/ [2] = https://aur.archlinux.org/packages/jdk/ [3] = http://openjdk.java.net/projects/jdk8/ Det
Re: [aur-general] Java name guideliness
First of all, I really *really* urge you to stop using phrases like refusal Refusal is what happend when two or more not agree in something I never mention who is refusing who cause both side from the vewpoint of the other is refusing the other side of view. In fact, _nowhere_ do I see anybody refusing to do _anything_. One not want use the other guidelines, so using the bare meaning of refusal that mean not accdept the other. Maybe the way I use the word not is the correct, you knoe false friends in english. or this is sick. Maybe you are overreacting (or I not expresed it corretly), I mean that is no sane (synonimous of ill synonimos of sick) having all the packages with different names, that is simply confusing the user who want install a simple jdk packages (me, I ended more confusin with this). I thing that is bvous that all are java. so why not something like providerjre/jdk-version: openjdk-9 or oraclejdk-7. Note; Using Gmail Note 2: Sorry again if I use a false friend, misswitting, misuse of words, incorrect use of expesions incorrec sytaxis or ambiguous language and my words ended hurting someone, sorry. 2014-09-10 0:08 GMT-03:00 Justin Dray jus...@dray.be: Part of the issue here however is that now there are both jre7 and jre7-oracle and so on duplicate packages in the AUR. If someone says 'oh, i need oracle jdk, I can search on the AUR for that.' Well now they have to go and read all of the comments and look around on the wiki/mailing lists/forums to figure out which one they actually want. And it's not even a dispute between different maintainers, 'joschi' is the maintainer for both packages and are seemingly totally different; different groups, different upstream urls, different dependencies, different provides/conflicts. It also appears that jre8-oracle was merged in to jre package recently, so there is another discrepancy in the naming there. I'm not fussed one way or another on the naming, but by having both, I've really got to agree with Pablo; it's far from KISS. Regards, Justin Dray E: jus...@dray.be M: 0433348284 On Wed, Sep 10, 2014 at 12:22 PM, Det nimetonma...@gmail.com wrote: On Wed, Sep 10, 2014 at 8:18 AM, Pablo Lezaeta Reyes prflr88 at gmail.com wrote: Since the new java-common come to the repo Is now possible have multiple java, but this bring and open another issue, java naming scheme the guy in jre/jdk[1] and jre-devel and jdk-devel refuse to follow a convention non generic name and the other maintaining jre7/jdk7 [2] and jre7-oracle/jdk7-oracle that do the same [3] refuse to accept or merge jre7-oracle into jre7 for the same reason even if the jre-oracle was merged into jre, this is a chaos. Many packages doing the same in different verion having different name conventions and ALL arguin bein correct. There is need to a conventional standar name scheme or this will be worst, instead to be kiss this is sick. There is a name scheme or name convention to follow? First of all, I really *really* urge you to stop using phrases like refusal or this is sick. If that really was the case, it would only split all parties further. It's not refusal to talk something through before doing it. In fact, _nowhere_ do I see anybody refusing to do _anything_. The talk in jdk7[1] is discussion on the appropriate name, and what I told everybody both in there and jdk[2] was my view on things and why I did what I had done (use jdk/java-8-jdk as the name, rather than jdk8-oracle/java-8-oracle). You realise how unbelievably easy it is for me to revert to the jdk8-oracle approach, if that winds up being the consensus? Or if I somehow wouldn't, then how easy would it be to kick me off from maintaining that thing? Enough of that already. Why I chose the java-8-jdk naming comes from the fact that java-8-openjdk sounds like we're trying to do java-major version-project name. The project name of JDK is not Oracle JDK, and that's why I chose it. Now, OpenJDK apparently still calls these projects by their base name[3], but _I_ would still prefer (read: I don't refuse; I prefer) having packages called jdk8-openjdk and jdk that install in /usr/lib/jvm/java-8-openjdk/ and /usr/lib/jvm/java-8-jdk/, respectively. This also means we can currently do: $ man java-openjdk8 $ man java-jdk8 To access the man pages. I really didn't like the following at all: $ man java-openjdk8 $ man java8-oracle [1] = https://aur.archlinux.org/packages/jdk7/ [2] = https://aur.archlinux.org/packages/jdk/ [3] = http://openjdk.java.net/projects/jdk8/ Det -- *Pablo Lezaeta*
[aur-general] 'java-runtime' dependency not working as expected
Hi there. Sudokuki has 'java-runtime' [1] as dependency and I have 'jre7' [2] (from AUR) installed (which 'provides' java-runtime=7)... When I try to compile sudokuki, makepkg warns me: :: jre7-openjdk and jre7 are in conflict (java-runtime). Remove jre7? [y/N] I don't want to install jre7-openjdk [3], as I need jre7. Why java-runtime is not working as expected? How can I make jre7 be recognized as java-runtime ? Thanks in advance, Rafael Ferreira [1] https://aur.archlinux.org/packages/sudokuki/ [2] https://aur.archlinux.org/packages/jre7/ [3] https://www.archlinux.org/packages/extra/x86_64/jre7-openjdk/
Re: [aur-general] 'java-runtime' dependency not working as expected
:: jre7-openjdk and jre7 are in conflict (java-runtime). Remove jre7? [y/N]
JRE != JDK. You need JDK7 to compile Java software.
makedepends=('java-environment')
And it tries to install OpenJDK for you, but it conflicts with your JRE.
Install Oracle JDK if you don't want OpenJDK.
https://aur.archlinux.org/packages/jdk7/
--
Kind regards,
Damian Nowak
StratusHost
www.AtlasHost.eu
Re: [aur-general] 'java-runtime' dependency not working as expected
Rafael Ferreira wrote: Hi there. Sudokuki has 'java-runtime' [1] as dependency and I have 'jre7' [2] (from AUR) installed (which 'provides' java-runtime=7)... When I try to compile sudokuki, makepkg warns me: :: jre7-openjdk and jre7 are in conflict (java-runtime). Remove jre7? :: [y/N] I don't want to install jre7-openjdk [3], as I need jre7. Why java-runtime is not working as expected? How can I make jre7 be recognized as java-runtime ? Because it wants java-environment as makedependency, so it tries to install jdk7-openjdk, which in turn depends on jre7-openjdk. You need to install jdk7 manually (which also provides java-environment) before compiling.
Re: [aur-general] 'java-runtime' dependency not working as expected
It make sense... As soon as I installed jdk7 (replacing jre7), it compiled just fine. Thanks Nowaker and Antonio Rojas 2014-04-23 13:58 GMT-03:00 Antonio Rojas nqn1976l...@gmail.com: Rafael Ferreira wrote: Hi there. Sudokuki has 'java-runtime' [1] as dependency and I have 'jre7' [2] (from AUR) installed (which 'provides' java-runtime=7)... When I try to compile sudokuki, makepkg warns me: :: jre7-openjdk and jre7 are in conflict (java-runtime). Remove jre7? :: [y/N] I don't want to install jre7-openjdk [3], as I need jre7. Why java-runtime is not working as expected? How can I make jre7 be recognized as java-runtime ? Because it wants java-environment as makedependency, so it tries to install jdk7-openjdk, which in turn depends on jre7-openjdk. You need to install jdk7 manually (which also provides java-environment) before compiling.
[aur-general] Java Dependency and Cross-Compilation Questions
So, my new machine is up and running (and I figured out my previous packaging issues!)...so I'm updating my jGnash package (http://www.archlinux.org/packages/community/i686/jgnash/) to the latest release and there is also currently a bug report on the package (http://bugs.archlinux.org/task/16665). The bug report correctly states that jGnash will not run with openjdk6 (jre works just fine), so what is the current policy for handling that fact? I know that no other packages depend on jre directly, and the prefered method is now java-runtime, but doesn't that mean that openjdk6 users will just have this software silently fail? Also, if you're building an i386 package on an x86_64 machine, is there an easy way to test the software to make sure that it's actually working on i386? Thanks in advance... -- Aaron ElasticDog Schaefer
Re: [aur-general] Java Dependency and Cross-Compilation Questions
Am Fri, 6 Nov 2009 00:29:49 -0500 schrieb Eric Bélanger snowmanisc...@gmail.com: I know that no other packages depend on jre directly, and the prefered method is now java-runtime, but doesn't that mean that openjdk6 users will just have this software silently fail? In this case, make it depends on jre. You could put a note in the PKGBUILD to explain this dependency. And, when either openjdk or jgnash release new versions, you could test to see if they work fine together so you could switch back the depends to java-runtime. It would be better to set the dependency to java-runtime instead of jre so that openjdk6 users can install and test jgnash. If jgnash really fails to run with openjdk6 - I hadn't had any problems with openjdk6, yet - then a bug report should be filed to upstream of openjdk6 and/or jgnash. I don't think it's the matter of downstream to restrict the dependency and to force the user using jre instead of openjdk6. So, please, change the dependency to java-runtime. Heiko
Re: [aur-general] Java Dependency and Cross-Compilation Questions
On Fri, Nov 6, 2009 at 1:21 AM, Heiko Baums li...@baums-on-web.de wrote: Am Fri, 6 Nov 2009 00:29:49 -0500 schrieb Eric Bélanger snowmanisc...@gmail.com: I know that no other packages depend on jre directly, and the prefered method is now java-runtime, but doesn't that mean that openjdk6 users will just have this software silently fail? In this case, make it depends on jre. You could put a note in the PKGBUILD to explain this dependency. And, when either openjdk or jgnash release new versions, you could test to see if they work fine together so you could switch back the depends to java-runtime. It would be better to set the dependency to java-runtime instead of jre so that openjdk6 users can install and test jgnash. If jgnash really fails to run with openjdk6 - I hadn't had any problems with openjdk6, yet - then a bug report should be filed to upstream of openjdk6 and/or jgnash. I don't think it's the matter of downstream to restrict the dependency and to force the user using jre instead of openjdk6. So, please, change the dependency to java-runtime. Heiko Yes, these problems should be reported upstream to openjdk6 and/or jgnash. If you change the depends to java-runtime, it might be a good idea to display a warning via a post-upgrade message that there might be problems with openjdk6. So that users won't open bug reports about it.
Re: [aur-general] Java Dependency and Cross-Compilation Questions
On Fri, Nov 6, 2009 at 1:34 AM, Heiko Baums li...@baums-on-web.de wrote: Am Fri, 6 Nov 2009 00:45:06 -0500 schrieb Eric Bélanger snowmanisc...@gmail.com: In this case, make it depends on jre. You could put a note in the PKGBUILD to explain this dependency. Btw., putting a note about a restricted dependency in the PKGBUILD is not the recommended way because the average user doesn't read the PKGBUILD if a binary package can't be installed due to a wrong dependency. Heiko That proposed note was not intended for users but for other TU or devs who might be tempted to fix the dependency by changing it to java-runtime.
Re: [aur-general] Java Dependency and Cross-Compilation Questions
Am Fri, 6 Nov 2009 02:01:36 -0500 schrieb Eric Bélanger snowmanisc...@gmail.com: Yes, these problems should be reported upstream to openjdk6 and/or jgnash. If you change the depends to java-runtime, it might be a good idea to display a warning via a post-upgrade message that there might be problems with openjdk6. So that users won't open bug reports about it. This is the better way of handling this. If you know of a already filed bug report then it would probably be a good idea to add the URL to this bug or the bug tracker and the bug id to this post-upgrade message, too. Heiko
Re: [aur-general] java package has build time deps
Excerpts from Loui Chang's message of Mon Jul 20 17:30:47 -0400 2009: On Tue 21 Jul 2009 01:03 +0400, svoufff wrote: yes the jsampler release version contains them but not jsampler from cvs. Le Mon, 20 Jul 2009 20:56:55 +, Laszlo Papp djsza...@gmail.com a écrit : Is there any package/program which contains this files ? Best Regards, Laszlo Papp On Mon, Jul 20, 2009 at 8:51 PM, svoufff svou...@free.fr wrote: Hi, i'm working on a PKGBUILD for jsampler-cvs.This is a java Stop with the top-posting! Yeah! Death to top-posting! ;) -- Andrei Thorp, Developer: Xandros Corp. (http://www.xandros.com)
Re: [aur-general] java package has build time deps
On Tue, Jul 21, 2009 at 9:11 PM, Andrei Thorpgar...@gmail.com wrote: Excerpts from Loui Chang's message of Mon Jul 20 17:30:47 -0400 2009: On Tue 21 Jul 2009 01:03 +0400, svoufff wrote: yes the jsampler release version contains them but not jsampler from cvs. Le Mon, 20 Jul 2009 20:56:55 +, Laszlo Papp djsza...@gmail.com a écrit : Is there any package/program which contains this files ? Best Regards, Laszlo Papp On Mon, Jul 20, 2009 at 8:51 PM, svoufff svou...@free.fr wrote: Hi, i'm working on a PKGBUILD for jsampler-cvs.This is a java Stop with the top-posting! Yeah! Death to top-posting! ;) how about death to oot? :) -- O ascii ribbon campaign - stop html mail - www.asciiribbon.org
Re: [aur-general] java package has build time deps
In last case, you can take these near the package, like other people do it with patches, install files. Thorp, No Pardon :) Best Regards, Laszlo Papp
Re: [aur-general] java package has build time deps
Excerpts from edogawaconan's message of Tue Jul 21 10:19:44 -0400 2009: On Tue, Jul 21, 2009 at 9:11 PM, Andrei Thorpgar...@gmail.com wrote: Excerpts from Loui Chang's message of Mon Jul 20 17:30:47 -0400 2009: On Tue 21 Jul 2009 01:03 +0400, svoufff wrote: yes the jsampler release version contains them but not jsampler from cvs. Le Mon, 20 Jul 2009 20:56:55 +, Laszlo Papp djsza...@gmail.com a écrit : Is there any package/program which contains this files ? Best Regards, Laszlo Papp On Mon, Jul 20, 2009 at 8:51 PM, svoufff svou...@free.fr wrote: Hi, i'm working on a PKGBUILD for jsampler-cvs.This is a java Stop with the top-posting! Yeah! Death to top-posting! ;) how about death to oot? :) Yeah! Death to oot! ;) -- Andrei Thorp, Developer: Xandros Corp. (http://www.xandros.com)
Re: [aur-general] java package has build time deps
Le Tue, 21 Jul 2009 16:20:26 +0200, Laszlo Papp djsza...@gmail.com a écrit : In last case, you can take these near the package, like other people do it with patches, install files. Thorp, No Pardon :) Best Regards, Laszlo Papp Thanks Laszlo, that's probably what i'll do.However there is another method that would be to put the release version in the source array just to strip the libs out of it...
[aur-general] java package has build time deps
Hi, i'm working on a PKGBUILD for jsampler-cvs.This is a java frontend to Linuxsampler. This app requires 4 more java libraries to be present at build time in a subdir of the source.These are jlscp.jar, juife.jar, swingx.jar and substance.jar.All of these are only needed for build, I ran the program without them installed just to check. What would be the best way to do ? put them in the makedepends array : that means packaging 4 more libs to AUR, forces the user to install these libraries on system, absolutely unneeded for running jsampler, since they are somewhat integrated to jsampler.jar during build.And it would still require to copy them from their install path to the source/subdir of jsampler to be able to build... or put them in the sources array and copy them the source/subdir before building, so they are just used for build and not installed.That works but is it the good way ? or something else ?
Re: [aur-general] java package has build time deps
yes the jsampler release version contains them but not jsampler from cvs. Le Mon, 20 Jul 2009 20:56:55 +, Laszlo Papp djsza...@gmail.com a écrit : Is there any package/program which contains this files ? Best Regards, Laszlo Papp On Mon, Jul 20, 2009 at 8:51 PM, svoufff svou...@free.fr wrote: Hi, i'm working on a PKGBUILD for jsampler-cvs.This is a java frontend to Linuxsampler. This app requires 4 more java libraries to be present at build time in a subdir of the source.These are jlscp.jar, juife.jar, swingx.jar and substance.jar.All of these are only needed for build, I ran the program without them installed just to check. What would be the best way to do ? put them in the makedepends array : that means packaging 4 more libs to AUR, forces the user to install these libraries on system, absolutely unneeded for running jsampler, since they are somewhat integrated to jsampler.jar during build.And it would still require to copy them from their install path to the source/subdir of jsampler to be able to build... or put them in the sources array and copy them the source/subdir before building, so they are just used for build and not installed.That works but is it the good way ? or something else ?
Re: [aur-general] java package has build time deps
On Tue 21 Jul 2009 01:03 +0400, svoufff wrote: yes the jsampler release version contains them but not jsampler from cvs. Le Mon, 20 Jul 2009 20:56:55 +, Laszlo Papp djsza...@gmail.com a écrit : Is there any package/program which contains this files ? Best Regards, Laszlo Papp On Mon, Jul 20, 2009 at 8:51 PM, svoufff svou...@free.fr wrote: Hi, i'm working on a PKGBUILD for jsampler-cvs.This is a java Stop with the top-posting!
Re: [aur-general] java
nathan owe. wrote:
this is confusing we need a easier PKGBUILD example for java. here is
my pkgbuild so far:
/# Contributor: Nathan Owe ndowens04 at gmail
pkgname=jpartialdownloader
pkgver=1.9
pkgrel=1
pkgdesc=
arch=('i686' 'x86_64')
url=
license=('GPL')
groups=()
depends=('openjdk6')
makedepends=('openjdk6')
source=(http://downloads.sourceforge.net/sourceforge/jpd/$pkgname-$pkgver.zip)
md5sums=('86b60156ad7b7ac315b2bf9d11ed9841')
build() {
cd $pkgname-$pkgver
mkdir -p $pkgdir/usr/share/java/$pkgname
cp -rf jpd.jar lib/ logs/ conf/ docs/ ${pkgdir}/usr/share/java/$pkgname/
/
but it has no run script that i can copy to $pkgdir/usr/bin so how do
i do it.
i've been looking at other's pkgbuild but i am not seeing a way yet.
Re: [aur-general] java
On Wed, Jun 17, 2009 at 18:09, nathan owe.ndowen...@gmail.com wrote:
nathan owe. wrote:
this is confusing we need a easier PKGBUILD example for java. here is my
pkgbuild so far:
/# Contributor: Nathan Owe ndowens04 at gmail
pkgname=jpartialdownloader
pkgver=1.9
pkgrel=1
pkgdesc=
arch=('i686' 'x86_64')
url=
license=('GPL')
groups=()
depends=('openjdk6')
makedepends=('openjdk6')
source=(http://downloads.sourceforge.net/sourceforge/jpd/$pkgname-$pkgver.zip)
md5sums=('86b60156ad7b7ac315b2bf9d11ed9841')
build() {
cd $pkgname-$pkgver
mkdir -p $pkgdir/usr/share/java/$pkgname
cp -rf jpd.jar lib/ logs/ conf/ docs/ ${pkgdir}/usr/share/java/$pkgname/
/
but it has no run script that i can copy to $pkgdir/usr/bin so how do i do
it.
i've been looking at other's pkgbuild but i am not seeing a way yet.
One option is to create a shell script named something like 'jpd' with contents:
#!/bin/bash
java -jar /usr/share/java/jpartialdownloader/jpd.jar $@
and copy that into /usr/bin/ in the PKGBUILD.
Sometimes you have to do things yourself.
By the way, you might want to look into using 'java-environment' or
'java-runtime' for your depends instead of 'openjdk6'. I'm not sure
which is correct.
-Marq
Re: [aur-general] java pkgbuild
nathan owe. wrote:
i am trying to find an example java build on arch wiki, also been
looking at the forums. is there no example pkgbuild that i can copy
and put in /usr/share/pacman/
There is none that I know of. Most java packages just dump all their
files in /usr/share/java/${pkgname}/ and add a launcher script to /usr/bin.
Allan
Re: [aur-general] java pkgbuild
Allan McRae wrote:
nathan owe. wrote:
i am trying to find an example java build on arch wiki, also been
looking at the forums. is there no example pkgbuild that i can copy
and put in /usr/share/pacman/
There is none that I know of. Most java packages just dump all their
files in /usr/share/java/${pkgname}/ and add a launcher script to
/usr/bin.
Allan
k thx. i guess i can figure it out. another question. how long normally
does it take to be a TU. my main goal is just contributing to arch but
being a TU would be nice one day
Re: [aur-general] java pkgbuild
On Mon, Jun 15, 2009 at 8:20 AM, nathan owe.ndowen...@gmail.com wrote:
Allan McRae wrote:
nathan owe. wrote:
i am trying to find an example java build on arch wiki, also been looking
at the forums. is there no example pkgbuild that i can copy and put in
/usr/share/pacman/
There is none that I know of. Most java packages just dump all their
files in /usr/share/java/${pkgname}/ and add a launcher script to /usr/bin.
Allan
k thx. i guess i can figure it out. another question. how long normally does
it take to be a TU. my main goal is just contributing to arch but being a TU
would be nice one day
It really depends. Make sure you learn most he packaging tricks and
contribute to AUR. Once you are confident you know most tricks in the
book and you think we are also confident you did, get in contact with
one of the current TUs and ask them to sponsor you.
Alternatively you may ask one at some point what they think you should
improve before you apply to increase your chances.
Ronald
Re: [aur-general] java pkgbuild
On Mon, Jun 15, 2009 at 8:26 AM, Ronald van Harenpre...@gmail.com wrote:
On Mon, Jun 15, 2009 at 8:20 AM, nathan owe.ndowen...@gmail.com wrote:
Allan McRae wrote:
nathan owe. wrote:
i am trying to find an example java build on arch wiki, also been looking
at the forums. is there no example pkgbuild that i can copy and put in
/usr/share/pacman/
There is none that I know of. Most java packages just dump all their
files in /usr/share/java/${pkgname}/ and add a launcher script to /usr/bin.
Allan
k thx. i guess i can figure it out. another question. how long normally does
it take to be a TU. my main goal is just contributing to arch but being a TU
would be nice one day
It really depends. Make sure you learn most he packaging tricks and
* most of the
contribute to AUR. Once you are confident you know most tricks in the
book and you think we are also confident you did, get in contact with
one of the current TUs and ask them to sponsor you.
Alternatively you may ask one at some point what they think you should
improve before you apply to increase your chances.
Ronald
I should proofread *before* I hit send, not after :-p
Ronald
Re: [aur-general] java pkgbuild
Ronald van Haren wrote:
On Mon, Jun 15, 2009 at 8:20 AM, nathan owe.ndowen...@gmail.com wrote:
Allan McRae wrote:
nathan owe. wrote:
i am trying to find an example java build on arch wiki, also been looking
at the forums. is there no example pkgbuild that i can copy and put in
/usr/share/pacman/
There is none that I know of. Most java packages just dump all their
files in /usr/share/java/${pkgname}/ and add a launcher script to /usr/bin.
Allan
k thx. i guess i can figure it out. another question. how long normally does
it take to be a TU. my main goal is just contributing to arch but being a TU
would be nice one day
It really depends. Make sure you learn most he packaging tricks and
contribute to AUR. Once you are confident you know most tricks in the
book and you think we are also confident you did, get in contact with
one of the current TUs and ask them to sponsor you.
Alternatively you may ask one at some point what they think you should
improve before you apply to increase your chances.
Ronald
At the moment i can do programs that use C** programming, of course some
dont compile but if they compile fine i can usually get them to work and
get it pkged correctly according to namcap
Re: [aur-general] java pkgbuild
On Mon, Jun 15, 2009 at 8:28 AM, nathan owe.ndowen...@gmail.com wrote:
Ronald van Haren wrote:
On Mon, Jun 15, 2009 at 8:20 AM, nathan owe.ndowen...@gmail.com wrote:
Allan McRae wrote:
nathan owe. wrote:
i am trying to find an example java build on arch wiki, also been
looking
at the forums. is there no example pkgbuild that i can copy and put in
/usr/share/pacman/
There is none that I know of. Most java packages just dump all their
files in /usr/share/java/${pkgname}/ and add a launcher script to
/usr/bin.
Allan
k thx. i guess i can figure it out. another question. how long normally
does
it take to be a TU. my main goal is just contributing to arch but being a
TU
would be nice one day
It really depends. Make sure you learn most he packaging tricks and
contribute to AUR. Once you are confident you know most tricks in the
book and you think we are also confident you did, get in contact with
one of the current TUs and ask them to sponsor you.
Alternatively you may ask one at some point what they think you should
improve before you apply to increase your chances.
Ronald
At the moment i can do programs that use C** programming, of course some
dont compile but if they compile fine i can usually get them to work and get
it pkged correctly according to namcap
start learning other programs, how to apply patches, make sure all
your packages follow the standards. At some point we'd like to see
that you know how to handle when issues arise. Remember we are a
bleading edge distro, not all things work just out of the box so
simple patches may need to be created.
Ronald
Re: [aur-general] java pkgbuild
nathan owe. schrieb: i am trying to find an example java build on arch wiki, also been looking at the forums. is there no example pkgbuild that i can copy and put in /usr/share/pacman/ Hello, I do not think it is typical but if you want to see a java package witch uses a buildsystem and which does nott only copy files from here to there, have a look at writer2latex in AUR. Regards Stefan
Re: [aur-general] java pkgbuild
On Mon, Jun 15, 2009 at 02:12, nathan owe.ndowen...@gmail.com wrote: i am trying to find an example java build on arch wiki, also been looking at the forums. is there no example pkgbuild that i can copy and put in /usr/share/pacman/ I'd recommend looking around the AUR for good examples (Personally I think my java-smack and scrollrack packages are decent)
Re: [aur-general] java pkgbuild
On Mon, Jun 15, 2009 at 2:12 AM, nathan owe.ndowen...@gmail.com wrote: i am trying to find an example java build on arch wiki, also been looking at the forums. is there no example pkgbuild that i can copy and put in /usr/share/pacman/ this might help: http://wiki.archlinux.org/index.php/Java_Package_Guidelines
Re: [aur-general] Java SDK/Runtime dependencies
On Thu, Feb 5, 2009 at 11:57 AM, Leslie P. Polzer s...@viridian-project.de wrote: Hello everyone, Rorschach has asked me to bring the discussion at http://aur.archlinux.org/packages.php?ID=2033 to this mailing list. Please help us find a consensus. My answer to his last question is: --- Let them install openjdk6 to provide the j2sdk dependency. It's not the Arch philosophy to cut on freedom of choice. By forcing a user to use either a free or proprietary alternative of a PROVIDES we ignore the purpose of this clause (i.e. providing freedom of choice). --- Moreover I don't really see what's controversial here. I'm a free software supporter myself, but I don't like forcing people to use it. provides=j2sdk is the way that will hurt no party. Thanks, Leslie -- LinkedIn Profile: http://www.linkedin.com/in/polzer Xing Profile: https://www.xing.com/profile/LeslieP_Polzer Blog: http://blog.viridian-project.de/ let it depend on java-environment. This is both provided by openjdk6 and the sun jdk package. Ronald
Re: [aur-general] Java SDK/Runtime dependencies
On Thu, Feb 5, 2009 at 12:13 PM, Rorschach r0rsch...@lavabit.com wrote: Is the provides field really doing what you think? Than I didn't understood it right. Could please someone bring some light to this? In general I think that Sun's Java should be kicked out as dependencie in every package where openjdk6 works fine because I think the main goal should be that we use a free java version and not a proprietary one. This topic is also missing in the http://wiki.archlinux.org/index.php/Java_Package_Guidelines. Description provides array from the info page: provides (array) An array of virtual provisions that this package provides. This allows a package to provide dependencies other than its own package name. For example, the dcron package can provide cron, which allows packages to depend on cron rather than dcron OR fcron. Versioned provisions are also possible, in the name=version format. For example, dcron can provide cron=2.0 to satisfy the cron=2.0 dependency of other packages. Provisions involving the and operators are invalid as only specifc versions of a package may be provided. As both openjdk6 and sun jdk provide the same development functions, they are interchangeble. Letting your package depend on java-runtime the user can either choose to use the openjdk one or the sun one. That is what you want right? Ronald
Re: [aur-general] Java SDK/Runtime dependencies
On Thu, Feb 05, 2009 at 11:57:34AM +0100, Leslie P. Polzer wrote: Hello everyone, Rorschach has asked me to bring the discussion at http://aur.archlinux.org/packages.php?ID=2033 to this mailing list. Please help us find a consensus. My answer to his last question is: --- Let them install openjdk6 to provide the j2sdk dependency. It's not the Arch philosophy to cut on freedom of choice. By forcing a user to use either a free or proprietary alternative of a PROVIDES we ignore the purpose of this clause (i.e. providing freedom of choice). --- Moreover I don't really see what's controversial here. I'm a free software supporter myself, but I don't like forcing people to use it. provides=j2sdk is the way that will hurt no party. Thanks, Leslie Hi, I agree with everything you say regarding j2sdk, since both packages provide it, ideally (in packaging terms) this should be the dependency. It would make all users happy. Those using Sun's Java and openjdk ones. Obviously setting the dependency to j2sdk has no disadvantages. If the maintainer of the package doesnt understand that for whatever reason,then just do what an OSS developer would. Fork it. Its not like its binary anyway. Plus its his pakage now, so he can do whatever he wants with it, even if thats opposing the interests of the community. Cause it does. -- Greg what to do and what not to do in public :o) http://linux.sgms-centre.com/misc/netiquette.php
Re: [aur-general] Java SDK/Runtime dependencies
On Thu, 5 Feb 2009 12:07:01 +0100 Ronald van Haren pre...@gmail.com wrote: let it depend on java-environment. This is both provided by openjdk6 and the sun jdk package. Ronald What package gets installed then if the user has until now none of these installed: $ pacman -sS java-environment extra/java-gcj-compat 1.0.78-1 Wrapper package to wrap free tools into a java 1.5.0.0 compatible java environment extra/openjdk6 1.3.1-2 Free Java environment based on OpenJDK 6.0 with IcedTea6 replacing binary plugs. community/jdk 6u11-1 Sun's Java Development Kit Next to that most applications like jondo and i2p don't run with gcj but the java-envrironment will tell that everything is ok. signature.asc Description: PGP signature
Re: [aur-general] Java SDK/Runtime dependencies
On Thu, Feb 5, 2009 at 12:19 PM, Rorschach r0rsch...@lavabit.com wrote: On Thu, 5 Feb 2009 12:07:01 +0100 Ronald van Haren pre...@gmail.com wrote: let it depend on java-environment. This is both provided by openjdk6 and the sun jdk package. Ronald What package gets installed then if the user has until now none of these installed: $ pacman -sS java-environment extra/java-gcj-compat 1.0.78-1 Wrapper package to wrap free tools into a java 1.5.0.0 compatible java environment extra/openjdk6 1.3.1-2 Free Java environment based on OpenJDK 6.0 with IcedTea6 replacing binary plugs. community/jdk 6u11-1 Sun's Java Development Kit Next to that most applications like jondo and i2p don't run with gcj but the java-envrironment will tell that everything is ok. ic, java-gcj-compat should die anyway. Thought we removed it already from the repos. in that case use j2sdk as suggested before. Ronald
Re: [aur-general] Java SDK/Runtime dependencies
On Thu, 5 Feb 2009 12:22:26 +0100 Ronald van Haren pre...@gmail.com wrote: in that case use j2sdk as suggested before. If I use j2sdk as dependencie what package gets installed by pacman if the user has no java already installed? signature.asc Description: PGP signature
Re: [aur-general] Java SDK/Runtime dependencies
On Thu, Feb 5, 2009 at 12:25 PM, Rorschach r0rsch...@lavabit.com wrote: On Thu, 5 Feb 2009 12:22:26 +0100 Ronald van Haren pre...@gmail.com wrote: in that case use j2sdk as suggested before. If I use j2sdk as dependencie what package gets installed by pacman if the user has no java already installed? the first package pacman finds. As the extra repo is specified before the community repo normally, it should install openjdk6 by default. Ronald
Re: [aur-general] Java SDK/Runtime dependencies
2009/2/5 Ronald van Haren pre...@gmail.com: 2009/2/5 Xavier shinin...@gmail.com: On Thu, Feb 5, 2009 at 1:13 PM, Ondřej Kučera ondrej.kuc...@centrum.cz wrote: The correct dependencies now are the following two: - java-runtime - needed for applications written in Java - java-environment - needed for Java development and for applications that need to compile Java classes during their run (e.g. Apache Tomcat) This makes sense to me, so if you are 100% sure, or if someone else can confirm this information, please update the wiki accordingly : http://wiki.archlinux.org/index.php/Java_Package_Guidelines . The whole Dependencies section needs to be fixed and should contain all the information you just gave. yes it is correct. It's just that the gcj one breaks stuff as it is incompatible. Ronald See http://bugs.archlinux.org/task/13125
Re: [aur-general] Java SDK/Runtime dependencies
Hi, yes it is correct. It's just that the gcj one breaks stuff as it is incompatible. Vuze (formerly Azureus) in community has actually the same problem. Works with jre, works with openjdk, doesn't work with gcj. Its site claims that it should work though so maybe a little tweaking of the starting script might do the trick (I gave it about half an hour but didn't get too far...). Ondřej -- Cheers, Ondřej Kučera -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: [aur-general] Java SDK/Runtime dependencies
using java-runtime as dependancy makes pacman install java-gcj-compat wihc seems to broke most of the packages. so before using java-runtime as dependancy one need to get rid off java-gcj-compat ? no ?
Re: [aur-general] Java SDK/Runtime dependencies
On Thu, Feb 05, 2009 at 05:47:16PM +0100, solsTiCe d'Hiver wrote: using java-runtime as dependancy makes pacman install java-gcj-compat wihc seems to broke most of the packages. so before using java-runtime as dependancy one need to get rid off java-gcj-compat ? no ? http://bugs.archlinux.org/task/13125 -- Greg what to do and what not to do in public :o) http://linux.sgms-centre.com/misc/netiquette.php
