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

2021-03-22 Thread 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, a

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

2021-03-22 Thread 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 sourc

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

2021-03-22 Thread 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

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

2021-03-22 Thread 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

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

2021-03-22 Thread 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 +

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

2021-03-22 Thread 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 us

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

2021-03-22 Thread 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 initram

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

2021-03-22 Thread 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

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

2021-03-22 Thread 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 provi

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

2021-03-22 Thread 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 ab