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 have it die in pkg_
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 m
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 d
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 uninstall
> 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 alo
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 like
> 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 think
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?
>
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 g
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 a
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 gut
> 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.
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 unins
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 that
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
Not
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
> bo
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
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. It
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 09409ab1f..cdc8c4043 100644
---
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 a/eclass/kernel-2.eclass b
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
> > ---
> > eclass/kernel-2.eclass | 8 +
21 matches
Mail list logo
