Java packaging issue on EPEL7

[Vitaly Zaitsev]

Hello.

Found a strange RPM autodeps issue, related to Java packaging, only on 
EPEL7.

EPEL7 package contains additional auto-detected strict dependencies: 
osgi(com.github.jnr.jffi) and osgi(com.sun.jna). That's why the package 
cannot be installed due to lack of dependencies on RHEL/CentOS 7:

Error: Package: pycharm-community-2021.1.3-1.el7.x86_64 (phracek-PyCharm)
            Requires: osgi(com.github.jnr.jffi)
  You could try using --skip-broken to work around the problem
  You could try running: rpm -Va --nofiles --nodigest

EPEL7 package:
Requires: /bin/sh /usr/bin/env libc.so.6()(64bit) 
libc.so.6(GLIBC_2.14)(64bit) libc.so.6(GLIBC_2.2.5)(64bit) 
libc.so.6(GLIBC_2.3)(64bit) libc.so.6(GLIBC_2.4)(64bit) 
osgi(com.github.jnr.jffi) osgi(com.sun.jna) rtld(GNU_HASH)

EPEL8 package (uses the same pre-built binaries):
Requires: /bin/sh /usr/bin/python3.6 libc.so.6()(64bit) 
libc.so.6(GLIBC_2.14)(64bit) libc.so.6(GLIBC_2.2.5)(64bit) 
libc.so.6(GLIBC_2.3)(64bit) libc.so.6(GLIBC_2.4)(64bit) rtld(GNU_HASH)

Fedora:
Requires: /usr/bin/python3 /usr/bin/sh libc.so.6()(64bit) 
libc.so.6(GLIBC_2.14)(64bit) libc.so.6(GLIBC_2.2.5)(64bit) 
libc.so.6(GLIBC_2.3)(64bit) libc.so.6(GLIBC_2.4)(64bit) rtld(GNU_HASH)

Downstream issue:
https://github.com/phracek/pycharm-community-edition/issues/62

SPEC file:
https://github.com/phracek/pycharm-community-edition/blob/master/pycharm-...

How I can fix this?

-- 
Sincerely,
   Vitaly Zaitsev (vitaly(a)easycoding.org)

[Nico Kadel-Garcia]

On Mon, Jul 19, 2021 at 1:31 PM Vitaly Zaitsev via devel
<devel(a)lists.fedoraproject.org&gt; wrote:
>  Fedora:
>  Requires: /usr/bin/python3 /usr/bin/sh libc.so.6()(64bit)
>  libc.so.6(GLIBC_2.14)(64bit) libc.so.6(GLIBC_2.2.5)(64bit)
>  libc.so.6(GLIBC_2.3)(64bit) libc.so.6(GLIBC_2.4)(64bit) rtld(GNU_HASH)
>
>  Downstream issue:
>  https://github.com/phracek/pycharm-community-edition/issues/62
>
>  SPEC file:
>  https://github.com/phracek/pycharm-community-edition/blob/master/pycharm-...
>
>  How I can fix this? 
You've got other problems. Those .spec files are not building from
source, they're pulling in pre-compiled binary tarballs and plugging
them into RPMs. If you're going to to that, please reflect it in the
name of your packages, say as pycharm-community_bin. Source code for
pycharm is apparently available: if you'd like to get that into EPEL
or Fedora, I'd suggest you start from source.

[Vitaly Zaitsev]

On 20/07/2021 05:03, Nico Kadel-Garcia wrote:
>  Source code for
>  pycharm is apparently available: if you'd like to get that into EPEL
>  or Fedora, I'd suggest you start from source. 
I know, but Java stack on Fedora is completely broken. PyCharm CE cannot 
be completely built from sources, that's why we uses COPR instead of the 
main Fedora repository.

>  If you're going to to that, please reflect it in the
>  name of your packages, say as pycharm-community_bin. 
We're not on Arch Linux.

-- 
Sincerely,
   Vitaly Zaitsev (vitaly(a)easycoding.org)

[Nico Kadel-Garcia]

On Tue, Jul 20, 2021 at 4:49 AM Vitaly Zaitsev via devel
<devel(a)lists.fedoraproject.org&gt; wrote:
>  On 20/07/2021 05:03, Nico Kadel-Garcia wrote:
>  > Source code for
>  > pycharm is apparently available: if you'd like to get that into EPEL
>  > or Fedora, I'd suggest you start from source.
>
>  I know, but Java stack on Fedora is completely broken. PyCharm CE cannot
>  be completely built from sources, that's why we uses COPR instead of the
>  main Fedora repository.
>
>  > If you're going to to that, please reflect it in the
>  > name of your packages, say as pycharm-community_bin.
>
>  We're not on Arch Linux. 
You're violating the bundling and naming practices that EPEL and
Fedora have used for years, especially their insistence that they
build from source, not repackaging bundled binaries from someone else
into an RPM. There are a whole stack of security reasons to discourage
that, and assuring the original source code and build tools are
available for others to modify is vital to "free software" in the GPL
sense.

To quote you: "PyCharm CE cannot be completely built from sources". If
that were completely true, it could not be built on COPR. If it's
broken on Fedora, please, work with *that*, and I suspect that
resolving that will resolve the missing dependency issue.

[Vitaly Zaitsev]

On 20/07/2021 11:18, Nico Kadel-Garcia wrote:
>  You're violating the bundling and naming practices that EPEL and
>  Fedora have used for years, especially their insistence that they
>  build from source, not repackaging bundled binaries from someone else
>  into an RPM. 
This is not a Fedora package. This is a COPR package.

COPR guidelines allows usage of pre-built binaries if they don't violate 
the Fedora Legal guidelines[1]: "You do not need to comply with 
Packaging Guidelines".

>  There are a whole stack of security reasons to discourage
>  that, and assuring the original source code and build tools are
>  available for others to modify is vital to "free software" in the GPL
>  sense. 
PyCharm CE binaries are licensed under the terms of the Apache 2.0 
license, which is completely free and opensource.

>  To quote you: "PyCharm CE cannot be completely built from
> sources". If
>  that were completely true, it could not be built on COPR. 
That's why we use pre-built binaries.

>  If it's
>  broken on Fedora, please, work with *that*, and I suspect that
>  resolving that will resolve the missing dependency issue. 
Java SIG tried to revive the Java stack on Fedora several times. It's 
still dead.

When the Java stack will be operational again, we will switch to 
building from sources.

[1]: 
https://docs.pagure.org/copr.copr/user_documentation.html#what-i-can-buil...

-- 
Sincerely,
   Vitaly Zaitsev (vitaly(a)easycoding.org)

[Stephen John Smoogen]

On Tue, Jul 20, 2021 at 06:29 Vitaly Zaitsev via devel <
devel(a)lists.fedoraproject.org&gt; wrote:

>  On 20/07/2021 11:18, Nico Kadel-Garcia wrote:
>  > You're violating the bundling and naming practices that EPEL and
>  > Fedora have used for years, especially their insistence that they
>  > build from source, not repackaging bundled binaries from someone else
>  > into an RPM.
>
>  This is not a Fedora package. This is a COPR package.
>  
Your wording in your initial emails made it sound like this was a package
either in EPEL or going to be in EPEL. In a very rare case, I was in
agreement with Nico and going to say the same things they did. Thank you
for clarifying this but it was confusing.




>  COPR guidelines allows usage of pre-built binaries if they don't
> violate
>  the Fedora Legal guidelines[1]: "You do not need to comply with
>  Packaging Guidelines".
>
>  > There are a whole stack of security reasons to discourage
>  > that, and assuring the original source code and build tools are
>  > available for others to modify is vital to "free software" in the GPL
>  > sense.
>
>  PyCharm CE binaries are licensed under the terms of the Apache 2.0
>  license, which is completely free and opensource.
>
>  > To quote you: "PyCharm CE cannot be completely built from sources". If
>  > that were completely true, it could not be built on COPR.
>
>  That's why we use pre-built binaries.
>
>  > If it's
>  > broken on Fedora, please, work with *that*, and I suspect that
>  > resolving that will resolve the missing dependency issue.
>
>  Java SIG tried to revive the Java stack on Fedora several times. It's
>  still dead.
>
>  When the Java stack will be operational again, we will switch to
>  building from sources.
>
>  [1]:
>
>  https://docs.pagure.org/copr.copr/user_documentation.html#what-i-can-buil...
>
>  --
>  Sincerely,
>     Vitaly Zaitsev (vitaly(a)easycoding.org)
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct:
>  https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
>  https://lists.fedoraproject.org/archives/list/[e-mail]
>  Do not reply to spam on the list, report it:
>  https://pagure.io/fedora-infrastructure
>  
-- 
Stephen J Smoogen.
I've seen things you people wouldn't believe. Flame wars in
sci.astro.orion. I have seen SPAM filters overload because of Godwin's Law.
All those moments will be lost in time... like posts on  BBS... time to
reboot.

[Nico Kadel-Garcia]

On Tue, Jul 20, 2021 at 7:24 AM Stephen John Smoogen <smooge(a)gmail.com&gt; wrote:
>  On Tue, Jul 20, 2021 at 06:29 Vitaly Zaitsev via devel
> <devel(a)lists.fedoraproject.org&gt; wrote:
> >
> > On 20/07/2021 11:18, Nico Kadel-Garcia wrote:
> > > You're violating the bundling and naming practices that EPEL and
> > > Fedora have used for years, especially their insistence that they
> > > build from source, not repackaging bundled binaries from someone else
> > > into an RPM.
> >
> > This is not a Fedora package. This is a COPR package.
>
>  Your wording in your initial emails made it sound like this was a package either in EPEL
> or going to be in EPEL. In a very rare case, I was in agreement with Nico and going to say
> the same things they did. Thank you for clarifying this but it was confusing. 
I didn't see COPR mentioned either. The title referred to EPEL 7.

> > COPR guidelines allows usage of pre-built binaries if they
> don't violate
> > the Fedora Legal guidelines[1]: "You do not need to comply with
> > Packaging Guidelines". 
Even if COPR guidelines allow it, Vitaly, it's a bad idea. I'm
startled that the jar files can compile in COPR if they don't compile
in the normal Fedora environment. I suspect they can't, the .spec file
in the git repo you mentioned doesn't pull source. It pulls a
pre-compiled tarball from

In theory, Java provides "write once, run everywhere". In practice,
especially cross-linked with other libraries such as the libffi
packages for C data structures.... not so much, as you've just
encountered.

[Vitaly Zaitsev]

On 22/07/2021 00:02, Nico Kadel-Garcia wrote:
>  Even if COPR guidelines allow it, Vitaly, it's a bad idea.
Yes, I know. Even Flathub uses pre-built binaries[1].

>  I'm
>  startled that the jar files can compile in COPR if they don't compile
>  in the normal Fedora environment. I suspect they can't, the .spec file
>  in the git repo you mentioned doesn't pull source. It pulls a
>  pre-compiled tarball from 
Kotlin compiler is required to build IDEA/PyCharm CE. Currently missing 
on Fedora/EPEL.

[1]: 
https://github.com/flathub/com.jetbrains.PyCharm-Community/blob/master/co...

-- 
Sincerely,
   Vitaly Zaitsev (vitaly(a)easycoding.org)

[Nico Kadel-Garcia]

On Thu, Jul 22, 2021 at 6:28 AM Vitaly Zaitsev via devel
<devel(a)lists.fedoraproject.org&gt; wrote:
>  On 22/07/2021 00:02, Nico Kadel-Garcia wrote:
>  > Even if COPR guidelines allow it, Vitaly, it's a bad idea.
>
>  Yes, I know. Even Flathub uses pre-built binaries[1]. 
Aaaggh. While I sympathize with your difficulty as someone confronted
with dependency stacks from other projects, I hope you see why it's a
problem.

>  > I'm
>  > startled that the jar files can compile in COPR if they don't compile
>  > in the normal Fedora environment. I suspect they can't, the .spec file
>  > in the git repo you mentioned doesn't pull source. It pulls a
>  > pre-compiled tarball from
>
>  Kotlin compiler is required to build IDEA/PyCharm CE. Currently missing
>  on Fedora/EPEL. 
OK, I see that IntelliJ and the Kotlin compiler creating "snaps",
which looks like yet another modularized software packaging
infrastructure.... Let's just say that the while approach of
re-inventing software packaging yet again for your particular software
suite is a popular hobby and burns through a great deal of developer
time. Right now, it's been burning yours: I see no trace that pycharm,
or the build tool kotlin, have been successfully compiled by anyone
outside the particular IntelliJ developers who wrote those tarballs.
Do you?

[Mikolaj Izdebski]

On Mon, Jul 19, 2021 at 7:31 PM Vitaly Zaitsev via devel
<devel(a)lists.fedoraproject.org&gt; wrote:
>  Hello.
>
>  Found a strange RPM autodeps issue, related to Java packaging, only on
>  EPEL7.
>
>  EPEL7 package contains additional auto-detected strict dependencies:
>  osgi(com.github.jnr.jffi) and osgi(com.sun.jna). That's why the package
>  cannot be installed due to lack of dependencies on RHEL/CentOS 7:
>
>  Error: Package: pycharm-community-2021.1.3-1.el7.x86_64 (phracek-PyCharm)
>              Requires: osgi(com.github.jnr.jffi)
>    You could try using --skip-broken to work around the problem
>    You could try running: rpm -Va --nofiles --nodigest 
[...]

>  How I can fix this? 
You can disable osgi requires generator or filter osgi requires (with
eg. __requires_exclude or __requires_exclude_from macros).

--
Mikolaj Izdebski

>  --
>  Sincerely,
>     Vitaly Zaitsev (vitaly(a)easycoding.org)
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail]
>  Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure

[Vitaly Zaitsev]

On 22/07/2021 05:18, Mikolaj Izdebski wrote:
>  You can disable osgi requires generator or filter osgi requires
> (with
>  eg. __requires_exclude or __requires_exclude_from macros). 
Only EPEL7 has an osgi
requirement. EPEL8 and Fedora - don't.

Already applied filters:

%global __provides_exclude_from ^%{_javadir}/%{name}/jbr/.*$
%global __requires_exclude_from ^%{_javadir}/%{name}/jbr/.*$

-- 
Sincerely,
   Vitaly Zaitsev (vitaly(a)easycoding.org)