[arch-general] NetBeans 9.0 not a drop-in replacement of 8.2
Hello, I'm not sure if this has to be brought up here, please advise. I have had many problems with netbeans package from community, it "upgraded" my old version of the package (was version 8.2), but it is not an adequate replacement. I'm aware of the bugs open in the tracker, and I thank everyone that provided workarounds to get the IDE working at first, then finally installing plugins correctly. However, the "new" version isn't complete yet, it lacks many of the "core" plugins that were available for 8.2, for example PHP (postponed to netbeans 10), JavaScript and C++ language support. I'm wondering what the correct procedure is in this case, if it were a commercial product,it would have reverted to 8.2 until it was ready. I don't have issues using it, I'm keeping it downgraded to 8.2, ignored in pacman.conf, I'm only asking if this is the correct approach for a repository package, since this is not AUR. Thanks, Leandro -- L'ignoranza è un male curabile, è sufficiente la volontà. Please don't print this e-mail if you don't need to!
Agree, NB 9.0 is a complete headache and probably should not be considered an *upgrade* from 8.2. Even upcoming NB 10.0 does not seem to solve all the migration issues. Maybe Apache Netbeans (9.0 and higher) has to be distributed as a different package ("apache-netbeans"), conflicting with old "netbeans" package? This way would allow manual upgrade (by installing "apache-netbeans") from old good NB 8.0 to Apache NB when it will be good enough to replace it. Regards, Danila Kiver.
Monday, November 12, 2018 1:38 PM +03:00 from Leandro Papi via arch-general <arch-general@archlinux.org>:
Hello, I'm not sure if this has to be brought up here, please advise.
I have had many problems with netbeans package from community, it "upgraded" my old version of the package (was version 8.2), but it is not an adequate replacement.
I'm aware of the bugs open in the tracker, and I thank everyone that provided workarounds to get the IDE working at first, then finally installing plugins correctly.
However, the "new" version isn't complete yet, it lacks many of the "core" plugins that were available for 8.2, for example PHP (postponed to netbeans 10), JavaScript and C++ language support.
I'm wondering what the correct procedure is in this case, if it were a commercial product,it would have reverted to 8.2 until it was ready. I don't have issues using it, I'm keeping it downgraded to 8.2, ignored in pacman.conf, I'm only asking if this is the correct approach for a repository package, since this is not AUR.
Thanks, Leandro -- L'ignoranza è un male curabile, è sufficiente la volontà.
Please don't print this e-mail if you don't need to!
On 11/12/18 12:04 PM, Danila Kiver via arch-general wrote:
Agree, NB 9.0 is a complete headache and probably should not be considered an *upgrade* from 8.2. Even upcoming NB 10.0 does not seem to solve all the migration issues.
Maybe Apache Netbeans (9.0 and higher) has to be distributed as a different package ("apache-netbeans"), conflicting with old "netbeans" package?
This way would allow manual upgrade (by installing "apache-netbeans") from old good NB 8.0 to Apache NB when it will be good enough to replace it.
Using inaccurate names is not the solution, if you want the 8.2 version for any given reason then you can submit an AUR package for netbeans8. Because this is how legacy versions of a package are *always* packaged, by using the base name and then suffixing it with the version. It's not exactly entirely unheard of for major new releases of a software to need migration, drop features (and hopefully add new ones), etc. This does *not* mean it is new software entirely, and it should *not* be named something new. -- Eli Schwartz Bug Wrangler and Trusted User
I am asking to get the general idea of how the package versioning works, I don't really know what has changed on NetBeans side. IIRC there are different versions of Java and PostgreSQL on official repos (not on AUR) like jdk8-openjdk for specific version and jdk-openjdk for latest and always-updated version. What do you consider when splitting packages by their versions? On Mon, 12 Nov 2018 at 21:16, Eli Schwartz via arch-general < arch-general@archlinux.org> wrote:
On 11/12/18 12:04 PM, Danila Kiver via arch-general wrote:
Agree, NB 9.0 is a complete headache and probably should not be considered an *upgrade* from 8.2. Even upcoming NB 10.0 does not seem to solve all the migration issues.
Maybe Apache Netbeans (9.0 and higher) has to be distributed as a different package ("apache-netbeans"), conflicting with old "netbeans" package?
This way would allow manual upgrade (by installing "apache-netbeans") from old good NB 8.0 to Apache NB when it will be good enough to replace it.
Using inaccurate names is not the solution, if you want the 8.2 version for any given reason then you can submit an AUR package for netbeans8. Because this is how legacy versions of a package are *always* packaged, by using the base name and then suffixing it with the version.
It's not exactly entirely unheard of for major new releases of a software to need migration, drop features (and hopefully add new ones), etc. This does *not* mean it is new software entirely, and it should *not* be named something new.
-- Eli Schwartz Bug Wrangler and Trusted User
On 11/12/18 1:44 PM, Ali Emre Gülcü via arch-general wrote:
I am asking to get the general idea of how the package versioning works, I don't really know what has changed on NetBeans side. IIRC there are different versions of Java and PostgreSQL on official repos (not on AUR) like jdk8-openjdk for specific version and jdk-openjdk for latest and always-updated version. What do you consider when splitting packages by their versions?
Java is... special, because there's a number of different runtimes that upstream officially supports, all of them are widely used, and none of them are compatible with each other. So, we have jre and jdk, suffixed by their version, then suffixed by "-openjdk" to indicate it is the opensource version, not the oracle builds. Unless there's some compelling reason, we don't typically offer multiple versions of software in the official repos. Compelling reasons may include major language runtime splits like python2/python3, the openssl-1.0 package for software which is not ported to work with the latest version of openssl, the qt4/qt5 split (although hopefully someday soon, all qt4 software will finally be ported to qt5), etc. Notice, these are all typically support libraries used as dependencies for other packages, rather than leaf software. -- Eli Schwartz Bug Wrangler and Trusted User
Am 12.11.18 um 19:44 schrieb Ali Emre Gülcü via arch-general:
I am asking to get the general idea of how the package versioning works, I don't really know what has changed on NetBeans side. [...]
Hi Ali, NetBeans 9.0 needs at least JDK 9, and it works only for Java SE. Besides the move to Apache with all the relicensing issues it has also been changed to be compatible to jigsaw changes and to allow projects using it. Relicensing is why NB is "incomplete", as only modules officially donated by oracle can be included after proper relicensing. And because this is very much work, NB 10.0 will not include JEE, yet. However, people are so busy doing all of it, it's difficult to follow the mailing lists, so have a look at these, if You are missing something. Kind regards Peter
On Mon, 12 Nov 2018 at 21:16, Eli Schwartz via arch-general < arch-general@archlinux.org> wrote:
On 11/12/18 12:04 PM, Danila Kiver via arch-general wrote:
Agree, NB 9.0 is a complete headache and probably should not be considered an *upgrade* from 8.2. Even upcoming NB 10.0 does not seem to solve all the migration issues.
Maybe Apache Netbeans (9.0 and higher) has to be distributed as a different package ("apache-netbeans"), conflicting with old "netbeans" package?
This way would allow manual upgrade (by installing "apache-netbeans") from old good NB 8.0 to Apache NB when it will be good enough to replace it.
Using inaccurate names is not the solution, if you want the 8.2 version for any given reason then you can submit an AUR package for netbeans8. Because this is how legacy versions of a package are *always* packaged, by using the base name and then suffixing it with the version.
It's not exactly entirely unheard of for major new releases of a software to need migration, drop features (and hopefully add new ones), etc. This does *not* mean it is new software entirely, and it should *not* be named something new.
-- Eli Schwartz Bug Wrangler and Trusted User
On 12/11/18, Danila Kiver via arch-general wrote:
Agree, NB 9.0 is a complete headache and probably should not be considered an *upgrade* from 8.2. Even upcoming NB 10.0 does not seem to solve all the migration issues.
Maybe Apache Netbeans (9.0 and higher) has to be distributed as a different package ("apache-netbeans"), conflicting with old "netbeans" package?
This way would allow manual upgrade (by installing "apache-netbeans") from old good NB 8.0 to Apache NB when it will be good enough to replace it.
Regards, Danila Kiver.
Hi Danila, A package mainatainer should not make such decisions for the users. If you don't like it you have the option to not update and stick to the 8.2. If you think that this could benefit others then submit a package in AUR as suggested already. You can use the history of the package to fetch the 8.2 version of PKBUILD [1] and push it to AUR with netbeans8 name (probably conflicts / provides netbeans). Cheers, Leonidas [1]: https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/netbeans&id=bfdf023d7e3506227ffed92abaaa7a5e9e5d107d -- Leonidas Spyropoulos A: Because it messes up the order in which people normally read text. Q: Why is it such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?
On Tue, 13 Nov 2018 at 09:05, Leonidas Spyropoulos via arch-general <arch-general@archlinux.org> wrote:
On 12/11/18, Danila Kiver via arch-general wrote:
Agree, NB 9.0 is a complete headache and probably should not be considered an *upgrade* from 8.2. Even upcoming NB 10.0 does not seem to solve all the migration issues.
Maybe Apache Netbeans (9.0 and higher) has to be distributed as a different package ("apache-netbeans"), conflicting with old "netbeans" package?
This way would allow manual upgrade (by installing "apache-netbeans") from old good NB 8.0 to Apache NB when it will be good enough to replace it.
Regards, Danila Kiver.
Hi Danila,
A package mainatainer should not make such decisions for the users. If you don't like it you have the option to not update and stick to the 8.2. If you think that this could benefit others then submit a package in AUR as suggested already. You can use the history of the package to fetch the 8.2 version of PKBUILD [1] and push it to AUR with netbeans8 name (probably conflicts / provides netbeans).
Cheers, Leonidas
-- Leonidas Spyropoulos
A: Because it messes up the order in which people normally read text. Q: Why is it such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?
As I understand, it's common, and the good way to have NB9.0 in community repository. I have since then put the package in IgnorePkg and kept using the 8.2 version. There are actually AUR packages for NB8.2 [1], and the nightly version of NB9.0 [2] which can be compiled with all the plugins that are not distributable in binary form. Let's suppose I want to create an AUR package to compile the full version of Netbeans 9.0, but I don't want it to conflict the preexisting version installed from community, what is the correct course of action? In which path should I install it? Leandro [1] https://aur.archlinux.org/packages/netbeans8/ [2] https://aur.archlinux.org/packages/netbeans-incubator/ -- L'ignoranza è un male curabile, è sufficiente la volontà. Please don't print this e-mail if you don't need to!
On 13/11/2018 09:18, Leandro Papi wrote:
As I understand, it's common, and the good way to have NB9.0 in community repository. I have since then put the package in IgnorePkg and kept using the 8.2 version.
There are actually AUR packages for NB8.2 [1], and the nightly version of NB9.0 [2] which can be compiled with all the plugins that are not distributable in binary form. Let's suppose I want to create an AUR package to compile the full version of Netbeans 9.0, but I don't want it to conflict the preexisting version installed from community, what is the correct course of action? In which path should I install it?
Leandro
[1] https://aur.archlinux.org/packages/netbeans8/ [2] https://aur.archlinux.org/packages/netbeans-incubator/ -- L'ignoranza è un male curabile, è sufficiente la volontà.
Please don't print this e-mail if you don't need to!
For that use case I would just throw it in $HOME instead of writing a package and putting it on aur.
participants (8)
-
Ali Emre Gülcü
-
Danila Kiver
-
Eli Schwartz
-
Leandro Papi
-
Leandro Papi
-
Leonidas Spyropoulos
-
Mr.Elendig
-
Peter Nabbefeld