[arch-general] NetBeans 9.0 not a drop-in replacement of 8.2

[Leandro Papi via arch-general]

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!

[Danila Kiver via arch-general]

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.

Post by Leandro Papi via arch-general
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

[Eli Schwartz via arch-general]

Post by Danila Kiver via arch-general
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.

[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. 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 <

Post by Danila Kiver via arch-general

Post by Danila Kiver via arch-general
Agree, NB 9.0 is a complete headache and probably should not be

considered

Post by Danila Kiver via arch-general
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

Post by Danila Kiver via arch-general
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

[Eli Schwartz via arch-general]

Post by 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. 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

[Peter Nabbefeld]

Post by 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

Post by Ali Emre Gülcü via arch-general
On Mon, 12 Nov 2018 at 21:16, Eli Schwartz via arch-general <

Post by Danila Kiver via arch-general

Post by Danila Kiver via arch-general
Agree, NB 9.0 is a complete headache and probably should not be

considered

Post by Danila Kiver via arch-general
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

Post by Danila Kiver via arch-general
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

[Leonidas Spyropoulos via arch-general]

Post by Danila Kiver via arch-general
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

[Leandro Papi]

On Tue, 13 Nov 2018 at 09:05, Leonidas Spyropoulos via arch-general

Post by Leonidas Spyropoulos via arch-general

Post by Danila Kiver via arch-general
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?

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!

[Mr.Elendig]

Post by Leandro Papi
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.