Re: [gentoo-dev] [RfC] Supporting Maven/Gradle build systems by installing to a local maven repository

[Henning Sudbrock]

> It looks pretty straightforward at a first glance, but I think it
> would require
> other components because you are not providing any information of
> the direct dependencies of the java packages/artifacts, which
> means it might have to consult other sources (probably a remote repo)
> first, and then attempts to resolve to a local JAR from your
> WorkspaceReader.

Hm, not sure I understand your point. A WorkspaceReader provides the
information about direct dependencies just like a Maven repository does,
i.e., via POM artifacts (just like Maven resolves POM artifacts from a
local/remote Maven repository, Maven would also resolve POM artifacts
via a WorkspaceReader).

> Have you tested this with --offline and the local maven cache (~/.m2)
> cleared beforehand to see if your extension can actually work in a
> sandboxed environment?

I have tested it so far to see that both POM and JAR artifacts are
resolved via the WorkspaceReader (also in combination with the --offline
flag and the local maven cache cleared, yes).

> It seems that having a local maven repository is the only
> straightforward
> and easy solution which doesn't involve much heavy patching of build
> files or deep understanding of the infrastructure with a large amount
> of effort in order to maintain the project.

I guess it's also an option to first start with a local maven
repository, and to extend it later - if needed - with a WorkspaceReader
for Maven builds (using a WorkspaceReader to, e.g., configure
ebuild-specifics for artifact resolution, and having the local maven
repository as the default to which Maven would fall back if the
WorkspaceReader does not provide any artifact for given Maven coordinates).

-- Henning Sudbrock


On 23.03.21 06:02, Kaibo Ma wrote:

 >What do you think about this alternative idea?

It looks pretty straightforward at a first glance, but I think it would
require
other components because you are not providing any information of
the direct dependencies of the java packages/artifacts, which
means it might have to consult other sources (probably a remote repo)
first, and then attempts to resolve to a local JAR from your
WorkspaceReader.

Have you tested this with --offline and the local maven cache (~/.m2)
cleared beforehand to see if your extension can actually work in a
sandboxed environment? XMvn does make use of this but it does
more than just this, it generates full POMs which might be very hard
to tackle.

Another thing is for gradle. It does not expose public API for custom
repositories. It does have the API for it, but it is not documented and
it is subject to change. XMvn has a gradle connector, but it is already
outdated and would only work for older gradle versions. I have tried
to create a gradle plugin with a custom repository, but the internal API
was very confusing, and it wasn't clear what I should do.

It seems that having a local maven repository is the only straightforward
and easy solution which doesn't involve much heavy patching of build
files or deep understanding of the infrastructure with a large amount of
effort in order to maintain the project.

Kaibo Ma

Re: [gentoo-dev] [RfC] Supporting Maven/Gradle build systems by installing to a local maven repository

[Kaibo Ma]

>What do you think about this alternative idea?

It looks pretty straightforward at a first glance, but I think it would
require
other components because you are not providing any information of
the direct dependencies of the java packages/artifacts, which
means it might have to consult other sources (probably a remote repo)
first, and then attempts to resolve to a local JAR from your
WorkspaceReader.

Have you tested this with --offline and the local maven cache (~/.m2)
cleared beforehand to see if your extension can actually work in a
sandboxed environment? XMvn does make use of this but it does
more than just this, it generates full POMs which might be very hard
to tackle.

Another thing is for gradle. It does not expose public API for custom
repositories. It does have the API for it, but it is not documented and
it is subject to change. XMvn has a gradle connector, but it is already
outdated and would only work for older gradle versions. I have tried
to create a gradle plugin with a custom repository, but the internal API
was very confusing, and it wasn't clear what I should do.

It seems that having a local maven repository is the only straightforward
and easy solution which doesn't involve much heavy patching of build
files or deep understanding of the infrastructure with a large amount of
effort in order to maintain the project.

Kaibo Ma

Re: [gentoo-dev] timezone configuration - why copying, not symlinking /etc/localtime ?

[Andreas Sturmlechner]

On Monday, 22 March 2021 21:18:32 CET Lars Wendler wrote:
> With enough motivation we can carry that revert for a very long time. I
> know that because I still carry reverts in my udev packages from when
> it was devoured by systemd.

It is 11.2 KiB worth of patch that at least I know I won't take responsibility 
over.

signature.asc
Description: This is a digitally signed message part.

[gentoo-dev] [PATCH 2/2] eclass/mate.eclass: Add EAPI 7 support

[Adam Feldman]

---
 eclass/mate.eclass | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/eclass/mate.eclass b/eclass/mate.eclass
index 34d5e47acc22..a3b4cfd0b602 100644
--- a/eclass/mate.eclass
+++ b/eclass/mate.eclass
@@ -7,7 +7,7 @@
 # @AUTHOR:
 # Authors: NP-Hardass  based upon the gnome2
 # and autotools-utils eclasses
-# @SUPPORTED_EAPIS: 6
+# @SUPPORTED_EAPIS: 6 7
 # @BLURB: Provides phases for MATE based packages.
 # @DESCRIPTION:
 # Exports portage base functions used by ebuilds written for packages using the
@@ -16,7 +16,7 @@
 
 # Check EAPI only
 case "${EAPI:-0}" in
-   6) ;;
+   6|7) ;;
*) die "EAPI=${EAPI:-0} is not supported" ;;
 esac
 
@@ -26,8 +26,12 @@ esac
 # @DESCRIPTION:
 # Available values for MATE_LA_PUNT:
 # - "no": will not clean any .la files
+# - In EAPI < 7:
 # - "yes": will run prune_libtool_files --modules
 # - If it is not set, it will run prune_libtool_files
+# - In EAPI 7:
+# - Any non-"no" value will run
+#  find "${ED}" -name '*.la' -delete || die
 # MATE_LA_PUNT is a stub to GNOME2_LA_PUNT
 MATE_LA_PUNT=${MATE_LA_PUNT:-""}
 GNOME2_LA_PUNT="${MATE_LA_PUNT}"
@@ -35,7 +39,7 @@ GNOME2_LA_PUNT="${MATE_LA_PUNT}"
 inherit gnome2 autotools mate-desktop.org
 
 case "${EAPI:-0}" in
-   6) EXPORT_FUNCTIONS src_prepare src_configure src_install pkg_preinst 
pkg_postinst pkg_postrm ;;
+   6|7) EXPORT_FUNCTIONS src_prepare src_configure src_install pkg_preinst 
pkg_postinst pkg_postrm ;;
*) die "EAPI=${EAPI:-0} is not supported" ;;
 esac
 
-- 
2.26.2

[gentoo-dev] [PATCH 1/2] eclass/mate-desktop.org.eclass: Add EAPI 7 support

[Adam Feldman]

---
 eclass/mate-desktop.org.eclass | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/eclass/mate-desktop.org.eclass b/eclass/mate-desktop.org.eclass
index 418f3f8ce076..740751066d0a 100644
--- a/eclass/mate-desktop.org.eclass
+++ b/eclass/mate-desktop.org.eclass
@@ -6,7 +6,7 @@
 # m...@gentoo.org
 # @AUTHOR:
 # Authors: NP-Hardass  based upon the gnome.org eclass.
-# @SUPPORTED_EAPIS: 6
+# @SUPPORTED_EAPIS: 6 7
 # @BLURB: Helper eclass for mate-desktop.org hosted archives
 # @DESCRIPTION:
 # Provide a default SRC_URI and EGIT_REPO_URI for MATE packages as well as
@@ -14,7 +14,7 @@
 
 # EAPIs < 6 are banned.
 case "${EAPI:-0}" in
-   6) ;;
+   6|7) ;;
*) die "EAPI=${EAPI:-0} is not supported" ;;
 esac
 
@@ -22,7 +22,7 @@ if [[ ${PV} ==  ]]; then
inherit git-r3
 fi
 
-inherit versionator
+[[ ${EAPI:-0} -eq 6 ]] && inherit eapi7-ver
 
 # @ECLASS-VARIABLE: MATE_TARBALL_SUFFIX
 # @INTERNAL
@@ -47,7 +47,7 @@ inherit versionator
 # @DESCRIPTION:
 # Major and minor numbers of the version number, unless live.
 # If live ebuild, will be set to ''.
-: ${MATE_BRANCH:=$(get_version_component_range 1-2)}
+: ${MATE_BRANCH:=$(ver_cut 1-2)}
 
 # Set SRC_URI or EGIT_REPO_URI based on whether live
 if [[ ${PV} ==  ]]; then
-- 
2.26.2

Re: [gentoo-dev] timezone configuration - why copying, not symlinking /etc/localtime ?

[Andreas K. Huettel]

> > Council decided years ago that we don't support separate /usr without
> > an initramfs, but we haven't completed that transition yet.
> 
> Which doesn't imply that we deliberately break things.

That's right. Though we should at some point start thinking about an end of 
support for separate usr without initramfs.

Why? Because the number of required hacks and complexity will only increase, as 
will the number of uncooperative upstreams. It's called a strategic retreat. :D

My suggestion would be that the next profile version (21? 22?) declares 
separate /usr a broken configuration, and explicitly encourages devs to 
introduce all ebuild simplifications that are made possible by this. (Like this 
symlink - no more conditional code.) No more discussions about "not breaking 
things" at that point.

(Or to put it another way, I think we should stop wasting time and effort here 
just to be able to live in the past.)

-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer
(council, toolchain, base-system, perl, libreoffice)

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] timezone configuration - why copying, not symlinking /etc/localtime ?

[Lars Wendler]

On Mon, 22 Mar 2021 09:59:11 +0100 Andreas Sturmlechner wrote:

>On Sonntag, 21. März 2021 08:58:34 CET James Le Cuirot wrote:
>> How about making emerge --config dynamic, copying if it's on a
>> different partition and symlinking if it's not? You can't accurately
>> determine the use of an initramfs but at least this is closer to what
>> we want.
>
>We will not be able to carry the revert for Qt5Core forever. I suspect
>it will be gone with Qt6, and then all we can do is ewarn users that
>their clock will be broken if their localtime is not a symlink.
>
>Keeping it as a file would mean convincing upstream(s) that the
>symlink is a systemd-ism, not a standard.
>
>Regards

With enough motivation we can carry that revert for a very long time. I
know that because I still carry reverts in my udev packages from when
it was devoured by systemd.

-- 
Lars Wendler
Gentoo package maintainer
GPG: 21CC CF02 4586 0A07 ED93  9F68 498F E765 960E 9B39


pgpAZvyBvjeAP.pgp
Description: Digitale Signatur von OpenPGP

[gentoo-dev] Last-rites: oasis.eclass

[Sam James]

oasis.eclass: mark as @DEAD (last-rite eclass)

Removal on 2021-04-05 when the rest of the Oasis packages, including
Oasis (dev-ml/oasis) is removed.

There's no point in keeping the eclass when Oasis itself is gone and nothing
should be able to use this right now anyway due to the large number of packages
which have been removed and conflicts with e.g. jbuilder and Dune.

(Even if something IS using this, they *really* shouldn't be by now, and the 
vast
majority - if not all - of their packages would have been from outside ::gentoo,
as Oasis and friends have not been usable in the tree for at least a year.)

Please port to newer opam or dune.

Bug: https://bugs.gentoo.org/775785
Bug: https://bugs.gentoo.org/497044
Bug: https://bugs.gentoo.org/637826


signature.asc
Description: Message signed with OpenPGP

Re: [gentoo-dev] [RfC] Supporting Maven/Gradle build systems by installing to a local maven repository

[Henning Sudbrock]

Hi Kaibo,

I'd like to suggest an alternative to using a local Maven repository for
making Portage-built artifacts available to Maven builds.

Maven also makes it possible to use a "Maven extension" for providing
artifacts that do not come from a remote Maven repository. If a Maven
extension provides an implementation of a "WorkspaceReader", Maven will
query that implementation for artifacts before checking any repository
for the artifacts. (An example of such an extension is used by
M2Eclipse, the Maven integration for the Eclipse IDE, which provides
artifacts built from Java projects within Eclipse.)

Using such a Maven extension would provide greater flexibility than a
local Maven repository, because ebuilds could modify artifact resolution
for their Maven builds by configuring the extension. (I believe that
this would be trickier when using a local Maven repository, in
particular with multiple ebuilds running in parallel.)

I don't know what a similar mechanism in Gradle would be, but I'd guess
that Gradle provides similar extension points.

When thinking about Java builds within portage some weeks ago, I
actually wrote a very simple such extension, to see if this approach
actually works (see
https://github.com/hsudbrock/portage-maven-workspace-reader), and it did
work fine. (This extension resolves artifacts that were "registered" by
other ebuilds by putting a file in a specific directory, where the file
contains the location of the artifact on the hard disk - but this is
just a very simple "proof of concept".)

What do you think about this alternative idea?

Best wishes,
Henning

On 15.03.21 14:02, Kaibo Ma wrote:

Hi all,
This is an RFC copied from a bug (https://bugs.gentoo.org/776007
), and I have added a new section
because I realized maven local would not be a good destination for
system-wide packages.

-

0. Motivation

Java packaging has become more difficult on Gentoo because maven/Gradle,
the two main build systems for java, is unsupported. When java packages
migrated from their ant builds to maven/Gradle, most of the packages
have not been updated since. I know that in Java overlay, the packaging
practices in general is to patch the pom.xml files to work with local
jars, but it does not work with Gradle and can be difficult when working
with large projects.

1. Challenges

  - maven modules/artifacts do not work well with java-config. They
generally have a group, which resolves name collisions, but java-config
currently does not have a group variable.

  - it will be hard to reinvent the wheel. If the solution was to
rewrite pom.xml/build.gradle files, it would have to resolve the
dependencies correctly with all the version constraints instead of
relying on the build system. Currently, for java-config packages can
only depend on a specific slot of a library, but some might work with
newer versions of their dependencies.

  - plugins are also hard to create in Gradle. Custom resolution of
dependencies or specifying a custom repository is not easy because it
involves "internal" API without much documentation. Fedora's XMvn
project can be used as a starting point but at the time of writing, XMvn
is outdated and missing some implementations for newly added interface
methods in Gradle's API.

2. Proposed idea

Maven/Gradle both have an offline mode which restricts them from
fetching online files. For java libraries, they will be published to the
local maven repository, which makes it available for other java programs
using maven/gradle that depends on the library.

Packages that still use java-pkg-simple.eclass can be kept because they
are generally not available in maven, so it is rare for other packages
to depend on them. The eclass and java-config should be updated for some
packages that depend on other packages that get published to mavenLocal,
but this seems like a rare case. Those packages can also just get
converted to a maven/project using patches.

For applications, the launcher scripts should also be changed to parse
local artifacts with POM files.
If this were to be implemented, newer (revisions/subslots? Or old slots
with -new at the end?) packages would be incompatible with older
versions of packages.

3. ERRATA

The local maven repository would not be a good fit since it is on a
per-user basis (~/.m2). The correct way would be to define a path for
installing (such as /usr/share/.m2), and pass that to build tools as a
URL (file:///usr/share/.m2).

Feel free to reply if you have any questions or improvements.
Kaibo Ma

Re: [gentoo-dev] timezone configuration - why copying, not symlinking /etc/localtime ?

[Andreas Sturmlechner]

On Sonntag, 21. März 2021 08:58:34 CET James Le Cuirot wrote:
> How about making emerge --config dynamic, copying if it's on a
> different partition and symlinking if it's not? You can't accurately
> determine the use of an initramfs but at least this is closer to what
> we want.

We will not be able to carry the revert for Qt5Core forever. I suspect it will 
be gone with Qt6, and then all we can do is ewarn users that their clock will 
be broken if their localtime is not a symlink.

Keeping it as a file would mean convincing upstream(s) that the symlink is a 
systemd-ism, not a standard.

Regards

signature.asc
Description: This is a digitally signed message part.