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
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 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.
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 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 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 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 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 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:
> 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 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 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
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 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_
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_prerm.
What portage does is *appear* to crash, but then continue along
15 matches
Mail list logo
