Re: [gentoo-dev] Re: [PATCH] eclass/kernel-2.eclass: Remove use of tr in global scope

W dniu śro, 30.08.2017 o godzinie 21∶51 -0400, użytkownik Jonathan Callen napisał: > On 08/30/2017 08:02 PM, Mike Pagano wrote: > > As per PMS remove calls to external command 'tr' in global scope > > See bug #629106 > > > > Signed-off-by: Mike Pagano > > --- > >

[gentoo-dev] Re: [PATCH] eclass/kernel-2.eclass: Remove use of tr in global scope

On 08/30/2017 08:02 PM, Mike Pagano wrote: > As per PMS remove calls to external command 'tr' in global scope > See bug #629106 > > Signed-off-by: Mike Pagano > --- > eclass/kernel-2.eclass | 8 +--- > 1 file changed, 5 insertions(+), 3 deletions(-) > > diff --git

[gentoo-dev] [PATCH] eclass/kernel-2.eclass: Remove use of tr in global scope

As per PMS remove calls to external command 'tr' in global scope See bug #629106 Signed-off-by: Mike Pagano --- eclass/kernel-2.eclass | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/eclass/kernel-2.eclass b/eclass/kernel-2.eclass index

Re: [gentoo-dev] Re: Categories for GUI stuff x11 and wayland

On Wed, 30 Aug 2017 19:37:09 + (UTC) Duncan <1i5t5.dun...@cox.net> wrote: > > That could be a lot of package-move churn. It arguably might make > sense to keep the current names "for legacy reasons". (Or not. Just > speculating here.) For sure it would require touching lots of packages.

Re: [gentoo-portage-dev] [PATCH] ebuild.sh: Explicitly ban get_libdir in global scope

On 08/30/2017 01:31 PM, Michał Górny wrote: > W dniu śro, 30.08.2017 o godzinie 10∶48 -0700, użytkownik Zac Medico > napisał: >> On 08/30/2017 02:06 AM, Michał Górny wrote: >>> The value of get_libdir depends on the profile, and so it is not useful >>> for dependency calculations. Furthermore, it

Re: [gentoo-portage-dev] [PATCH] ebuild.sh: Explicitly ban get_libdir in global scope

W dniu śro, 30.08.2017 o godzinie 10∶48 -0700, użytkownik Zac Medico napisał: > On 08/30/2017 02:06 AM, Michał Górny wrote: > > The value of get_libdir depends on the profile, and so it is not useful > > for dependency calculations. Furthermore, it seems that Portage does > > not handle defining

Re: [gentoo-dev] [RFC] Addition of a new field to metadata.xml

On 01.06.2017 23:18, Jonas Stein wrote: > 2. Specification > > A space separated list of the corresponding debian packages should be > written in the field > > > It should be NONE, if debian has no corresponding package. > UNSET or no field, if the creator of the ebuild did not

[gentoo-dev] Re: Categories for GUI stuff x11 and wayland

William L. Thomson Jr. posted on Wed, 30 Aug 2017 14:01:08 -0400 as excerpted: > This is more food for thought to start a discussion on new category > names. With Wayland becoming more of a reality every day. I think some > of the x11-* categories may need to change. Stuff in there may not be >

[gentoo-dev] Categories for GUI stuff x11 and wayland

This is more food for thought to start a discussion on new category names. With Wayland becoming more of a reality every day. I think some of the x11-* categories may need to change. Stuff in there may not be bound to X and can run on Wayland or X. Examples x11-libs/gtk+ x11-terms/terminology

Re: [gentoo-portage-dev] [PATCH] ebuild.sh: Explicitly ban get_libdir in global scope

On 08/30/2017 10:52 AM, Ulrich Mueller wrote: >> On Wed, 30 Aug 2017, Zac Medico wrote: > >> It's possible that there are working ebuilds that call get_libdir in >> global scope. > > How could that be possible when get_libdir() is defined in > phase-helpers.sh? During an "normal" ebuild

Re: [gentoo-portage-dev] [PATCH] ebuild.sh: Explicitly ban get_libdir in global scope

> On Wed, 30 Aug 2017, Zac Medico wrote: > It's possible that there are working ebuilds that call get_libdir in > global scope. How could that be possible when get_libdir() is defined in phase-helpers.sh? > Have we done an analysis of the ebuilds in the gentoo repository? > Obviously, it

Re: [gentoo-portage-dev] [PATCH] ebuild.sh: Explicitly ban get_libdir in global scope

On 08/30/2017 02:06 AM, Michał Górny wrote: > The value of get_libdir depends on the profile, and so it is not useful > for dependency calculations. Furthermore, it seems that Portage does > not handle defining it in global scope well due to EAPI checking magic. > Ban it completely where it is

Re: [gentoo-dev] Of death and prerm

On 08/30/2017 10:24 AM, Michael Orlitzky wrote: > On 08/30/2017 10:10 AM, Ian Stakenvicius wrote: >> >> I wonder though, per the original idea, wouldn't it make more sense to >> allow uninstallation to continue and just very verbosely >> warn/log/document what the package removal didn't do, so

Re: [gentoo-dev] Of death and prerm

W dniu śro, 30.08.2017 o godzinie 09∶15 -0400, użytkownik Michael Orlitzky napisał: > On 08/30/2017 05:25 AM, Michał Górny wrote: > > > > This package does not belong in Gentoo. We do packaging, not some ugly > > malware that prevents users from uninstalling itself. Every package must > > be

Re: [gentoo-dev] Of death and prerm

> On Wed, 30 Aug 2017, Ian Stakenvicius wrote: > For adding this to FEATURES and RESTRICT, are we moving into PMS > modification territory? Not necessarily. Or rather, we could proceed without modifying it, because "Package managers may recognise other tokens" [1]. FEATURES is Portage only.

Re: [gentoo-dev] Of death and prerm

On 08/30/2017 10:10 AM, Ian Stakenvicius wrote: > > I wonder though, per the original idea, wouldn't it make more sense to > allow uninstallation to continue and just very verbosely > warn/log/document what the package removal didn't do, so that it can > be done later by hand as needed? > My

Re: [gentoo-dev] Of death and prerm

On 30/08/17 10:04 AM, Michael Orlitzky wrote: > On 08/30/2017 09:46 AM, Ian Stakenvicius wrote: >> >> For adding this to FEATURES and RESTRICT, are we moving into PMS >> modification territory? And if so, is this something we want to do >> just for this? >> > > The new RESTRICT value would need

Re: [gentoo-dev] Of death and prerm

On 08/30/2017 09:46 AM, Ian Stakenvicius wrote: > > For adding this to FEATURES and RESTRICT, are we moving into PMS > modification territory? And if so, is this something we want to do > just for this? > The new RESTRICT value would need a PMS update, but the "just for this" part is where it

Re: [gentoo-dev] Of death and prerm

On 30/08/17 09:40 AM, Ulrich Mueller wrote: >> On Wed, 30 Aug 2017, Michael Orlitzky wrote: > >>> This rather sounds like a case for package manager support with >>> some property like RESTRICT="uninstall". > >> Would it still be possible to override with >> I_KNOW_WHAT_I_AM_DOING=yes then?

Re: [gentoo-dev] Of death and prerm

> On Wed, 30 Aug 2017, Michael Orlitzky wrote: >> This rather sounds like a case for package manager support with >> some property like RESTRICT="uninstall". > Would it still be possible to override with > I_KNOW_WHAT_I_AM_DOING=yes then? No. If this was to be implemented in Portage, I

Re: [gentoo-dev] Of death and prerm

On 08/30/2017 09:26 AM, Ulrich Mueller wrote: > >> 1a. If you try to uninstall a user package, it should die(), because >> calling userdel can be a security risk if the user still owns >> files. > > This rather sounds like a case for package manager support with > some property

Re: [gentoo-dev] Of death and prerm

> On Wed, 30 Aug 2017, Michael Orlitzky wrote: > I've been working on the user packages GLEP that I started and then > forgot about sometime at the beginning of the year. I'm trying to finish > up the reference implementation. > When it comes to removing users, everyone's suggestions were

Re: [gentoo-dev] Of death and prerm

On 08/30/2017 05:25 AM, Michał Górny wrote: > > This package does not belong in Gentoo. We do packaging, not some ugly > malware that prevents users from uninstalling itself. Every package must > be uninstallable. Even if it destroys my system, developers have no > right to prevent valid

Re: [gentoo-dev] Of death and prerm

On 08/30/2017 04:04 AM, Alexis Ballier wrote: > > Is there any point in dying in any phase after (or during) > pkg_postinst ? > files are already live by then; what would this achieve ? > I was hoping that die() called in pkg_prerm would have a similar effect as pressing Ctrl-C when portage is

Re: [gentoo-dev] Of death and prerm

W dniu wto, 29.08.2017 o godzinie 16∶38 -0400, użytkownik Michael Orlitzky napisał: > What should happen if an ebuild calls "die" in pkg_prerm? Horrible things, I suppose. If something started uninstalling, and failed during uninstall the system integrity is compromised and user needs to perform

[gentoo-portage-dev] [PATCH] ebuild.sh: Explicitly ban get_libdir in global scope

The value of get_libdir depends on the profile, and so it is not useful for dependency calculations. Furthermore, it seems that Portage does not handle defining it in global scope well due to EAPI checking magic. Ban it completely where it is defined as EAPI function to let developers catch their

Re: [gentoo-dev] Of death and prerm

On Tue, 29 Aug 2017 16:38:15 -0400 Michael Orlitzky wrote: > What should happen if an ebuild calls "die" in pkg_prerm? > > The issue arose while trying to create a package that could not be > uninstalled except as part of an upgrade. The first thing that came to > mind was to