[gentoo-dev] [RFC] Moving COLLISION_IGNORE (and UNINSTALL_IGNORE?) to profiles/*/make.defaults

[gentoo-dev] [RFC] Moving COLLISION_IGNORE (and UNINSTALL_IGNORE?) to profiles/*/make.defaults

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 992 bytes --]

Hello,

Just a quick one.

Currently, the two listed variables are set in make.globals (installed
by portage ebuild);

COLLISION_IGNORE="/lib/modules/* *.py[co] *\$py.class"
UNINSTALL_IGNORE="/lib/modules/*"

COLLISION_IGNORE specifies files that will be ignored by
FEATURES=collision-protect when they exist but are not owned by any
package. UNINSTALL_IGNORE specifies files that will not be unmerged.

By keeping those two in portage, we're basically binding them to
version of portage installed. If we need to ignore more files, we need
to request our users to upgrade portage.

That's why I'm thinking of moving them to profiles/base/make.defaults.
From what I've tested, the setting there will override make.globals
and therefore the change could be effective from day one, without
the need to upgrade portage.

I feel like those variables are much alike the QA variables that we
keep in the profiles.

What do you think?

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

Re: [gentoo-dev] [RFC] Moving COLLISION_IGNORE (and UNINSTALL_IGNORE?) to profiles/*/make.defaults

[Alexis Ballier]

On Fri, 9 Aug 2013 11:32:12 +0200
Michał Górny <mgorny@gentoo.org> wrote:

> What do you think?

+1

PMS is not an issue here I guess because those are just variables.

Re: [gentoo-dev] [RFC] Moving COLLISION_IGNORE (and UNINSTALL_IGNORE?) to profiles/*/make.defaults

[Ulrich Mueller]

>>>>> On Fri, 9 Aug 2013, Alexis Ballier wrote:

> On Fri, 9 Aug 2013 11:32:12 +0200 Michał Górny <mgorny@gentoo.org>
> wrote:

>> What do you think?

> +1

+1

Some observations (originally from IRC discussion, mgorny has asked me
to post them here for reference):

- As far as we know, these variables are Portage specific, as well as
  FEATURES="collision-protect".
- Variables are _not_ incremental, so assigning them in a profile will
  override make.globals.
- Setting them in make.conf will override both profiles and
  make.globals.

So for users who assign the variables in make.conf the assignment in
profiles will have no effect. But I think one can assume that these
are advanced users who can handle such kind of situations.

Ulrich

Re: [gentoo-dev] [RFC] Moving COLLISION_IGNORE (and UNINSTALL_IGNORE?) to profiles/*/make.defaults

[Zac Medico]

On 08/09/2013 02:32 AM, Michał Górny wrote:
> Hello,
> 
> Just a quick one.
> 
> Currently, the two listed variables are set in make.globals (installed
> by portage ebuild);
> 
> COLLISION_IGNORE="/lib/modules/* *.py[co] *\$py.class"
> UNINSTALL_IGNORE="/lib/modules/*"
> 
> COLLISION_IGNORE specifies files that will be ignored by
> FEATURES=collision-protect when they exist but are not owned by any
> package. UNINSTALL_IGNORE specifies files that will not be unmerged.
> 
> By keeping those two in portage, we're basically binding them to
> version of portage installed. If we need to ignore more files, we need
> to request our users to upgrade portage.
> 
> That's why I'm thinking of moving them to profiles/base/make.defaults.
> From what I've tested, the setting there will override make.globals
> and therefore the change could be effective from day one, without
> the need to upgrade portage.
> 
> I feel like those variables are much alike the QA variables that we
> keep in the profiles.
> 
> What do you think?

I guess it's fine. I would do it like this in order to respect the
portage default setting:

COLLISION_IGNORE="${COLLISION_IGNORE} new stuff"
-- 
Thanks,
Zac

Re: [gentoo-dev] [RFC] Moving COLLISION_IGNORE (and UNINSTALL_IGNORE?) to profiles/*/make.defaults

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1543 bytes --]

Dnia 2013-08-09, o godz. 09:47:38
Zac Medico <zmedico@gentoo.org> napisał(a):

> On 08/09/2013 02:32 AM, Michał Górny wrote:
> > Hello,
> > 
> > Just a quick one.
> > 
> > Currently, the two listed variables are set in make.globals (installed
> > by portage ebuild);
> > 
> > COLLISION_IGNORE="/lib/modules/* *.py[co] *\$py.class"
> > UNINSTALL_IGNORE="/lib/modules/*"
> > 
> > COLLISION_IGNORE specifies files that will be ignored by
> > FEATURES=collision-protect when they exist but are not owned by any
> > package. UNINSTALL_IGNORE specifies files that will not be unmerged.
> > 
> > By keeping those two in portage, we're basically binding them to
> > version of portage installed. If we need to ignore more files, we need
> > to request our users to upgrade portage.
> > 
> > That's why I'm thinking of moving them to profiles/base/make.defaults.
> > From what I've tested, the setting there will override make.globals
> > and therefore the change could be effective from day one, without
> > the need to upgrade portage.
> > 
> > I feel like those variables are much alike the QA variables that we
> > keep in the profiles.
> > 
> > What do you think?
> 
> I guess it's fine. I would do it like this in order to respect the
> portage default setting:
> 
> COLLISION_IGNORE="${COLLISION_IGNORE} new stuff"

Well, the intent was to put the current default in there, and drop it
in next version of portage since it is specific to gx86 eclasses
and ebuilds.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

Re: [gentoo-dev] [RFC] Moving COLLISION_IGNORE (and UNINSTALL_IGNORE?) to profiles/*/make.defaults

[Zac Medico]

On 08/09/2013 11:10 AM, Michał Górny wrote:
> Dnia 2013-08-09, o godz. 09:47:38
> Zac Medico <zmedico@gentoo.org> napisał(a):
> 
>> On 08/09/2013 02:32 AM, Michał Górny wrote:
>>> Hello,
>>>
>>> Just a quick one.
>>>
>>> Currently, the two listed variables are set in make.globals (installed
>>> by portage ebuild);
>>>
>>> COLLISION_IGNORE="/lib/modules/* *.py[co] *\$py.class"
>>> UNINSTALL_IGNORE="/lib/modules/*"
>>>
>>> COLLISION_IGNORE specifies files that will be ignored by
>>> FEATURES=collision-protect when they exist but are not owned by any
>>> package. UNINSTALL_IGNORE specifies files that will not be unmerged.
>>>
>>> By keeping those two in portage, we're basically binding them to
>>> version of portage installed. If we need to ignore more files, we need
>>> to request our users to upgrade portage.
>>>
>>> That's why I'm thinking of moving them to profiles/base/make.defaults.
>>> From what I've tested, the setting there will override make.globals
>>> and therefore the change could be effective from day one, without
>>> the need to upgrade portage.
>>>
>>> I feel like those variables are much alike the QA variables that we
>>> keep in the profiles.
>>>
>>> What do you think?
>>
>> I guess it's fine. I would do it like this in order to respect the
>> portage default setting:
>>
>> COLLISION_IGNORE="${COLLISION_IGNORE} new stuff"
> 
> Well, the intent was to put the current default in there, and drop it
> in next version of portage since it is specific to gx86 eclasses
> and ebuilds.

Well, the /lib/modules/* setting specifically complements portage's
UNINSTALL_IGNORE setting, so that would be one reason to inherit the
portage setting, in case portage changes its default config somehow.
-- 
Thanks,
Zac

Re: [gentoo-dev] [RFC] Moving COLLISION_IGNORE (and UNINSTALL_IGNORE?) to profiles/*/make.defaults

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 2055 bytes --]

Dnia 2013-08-09, o godz. 11:46:17
Zac Medico <zmedico@gentoo.org> napisał(a):

> On 08/09/2013 11:10 AM, Michał Górny wrote:
> > Dnia 2013-08-09, o godz. 09:47:38
> > Zac Medico <zmedico@gentoo.org> napisał(a):
> > 
> >> On 08/09/2013 02:32 AM, Michał Górny wrote:
> >>> Hello,
> >>>
> >>> Just a quick one.
> >>>
> >>> Currently, the two listed variables are set in make.globals (installed
> >>> by portage ebuild);
> >>>
> >>> COLLISION_IGNORE="/lib/modules/* *.py[co] *\$py.class"
> >>> UNINSTALL_IGNORE="/lib/modules/*"
> >>>
> >>> COLLISION_IGNORE specifies files that will be ignored by
> >>> FEATURES=collision-protect when they exist but are not owned by any
> >>> package. UNINSTALL_IGNORE specifies files that will not be unmerged.
> >>>
> >>> By keeping those two in portage, we're basically binding them to
> >>> version of portage installed. If we need to ignore more files, we need
> >>> to request our users to upgrade portage.
> >>>
> >>> That's why I'm thinking of moving them to profiles/base/make.defaults.
> >>> From what I've tested, the setting there will override make.globals
> >>> and therefore the change could be effective from day one, without
> >>> the need to upgrade portage.
> >>>
> >>> I feel like those variables are much alike the QA variables that we
> >>> keep in the profiles.
> >>>
> >>> What do you think?
> >>
> >> I guess it's fine. I would do it like this in order to respect the
> >> portage default setting:
> >>
> >> COLLISION_IGNORE="${COLLISION_IGNORE} new stuff"
> > 
> > Well, the intent was to put the current default in there, and drop it
> > in next version of portage since it is specific to gx86 eclasses
> > and ebuilds.
> 
> Well, the /lib/modules/* setting specifically complements portage's
> UNINSTALL_IGNORE setting, so that would be one reason to inherit the
> portage setting, in case portage changes its default config somehow.

This one is being moved as well. I think we want that globally too.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

[gentoo-dev] Re: [RFC] Moving COLLISION_IGNORE (and UNINSTALL_IGNORE?) to profiles/*/make.defaults

[Martin Vaeth]

Ulrich Mueller <ulm@gentoo.org> wrote:
> - Variables are _not_ incremental, so assigning them in a profile will
>   override make.globals.

How about making them incremental?

It would simplify things for users if they want to modify
specific bits of them and one would not have to mess around
with COLLISSION_IGNORE="${COLLISION_IGNORE} ...." in profiles.

Re: [gentoo-dev] [RFC] Moving COLLISION_IGNORE (and UNINSTALL_IGNORE?) to profiles/*/make.defaults

[Zac Medico]

On 08/09/2013 02:32 AM, Michał Górny wrote:
> Hello,
> 
> Just a quick one.
> 
> Currently, the two listed variables are set in make.globals (installed
> by portage ebuild);
> 
> COLLISION_IGNORE="/lib/modules/* *.py[co] *\$py.class"
> UNINSTALL_IGNORE="/lib/modules/*"
> 
> COLLISION_IGNORE specifies files that will be ignored by
> FEATURES=collision-protect when they exist but are not owned by any
> package. UNINSTALL_IGNORE specifies files that will not be unmerged.
> 
> By keeping those two in portage, we're basically binding them to
> version of portage installed. If we need to ignore more files, we need
> to request our users to upgrade portage.
> 
> That's why I'm thinking of moving them to profiles/base/make.defaults.
> From what I've tested, the setting there will override make.globals
> and therefore the change could be effective from day one, without
> the need to upgrade portage.
> 
> I feel like those variables are much alike the QA variables that we
> keep in the profiles.
> 
> What do you think?
> 

Are we sure that this thing really belongs in the profile, rather than
something that's defined in ebuilds? Or maybe we should have both?

If ebuild devs are forced to use the profile for this, then that global
variable could see a lot of growth in the long-term. OTOH, if it's
defined at the ebuild level, then it keeps the info more encapsulated,
and that may be better particularly for overlay ebuilds.
-- 
Thanks,
Zac

Re: [gentoo-dev] [RFC] Moving COLLISION_IGNORE (and UNINSTALL_IGNORE?) to profiles/*/make.defaults

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1949 bytes --]

Dnia 2013-08-09, o godz. 23:27:41
Zac Medico <zmedico@gentoo.org> napisał(a):

> On 08/09/2013 02:32 AM, Michał Górny wrote:
> > Hello,
> > 
> > Just a quick one.
> > 
> > Currently, the two listed variables are set in make.globals (installed
> > by portage ebuild);
> > 
> > COLLISION_IGNORE="/lib/modules/* *.py[co] *\$py.class"
> > UNINSTALL_IGNORE="/lib/modules/*"
> > 
> > COLLISION_IGNORE specifies files that will be ignored by
> > FEATURES=collision-protect when they exist but are not owned by any
> > package. UNINSTALL_IGNORE specifies files that will not be unmerged.
> > 
> > By keeping those two in portage, we're basically binding them to
> > version of portage installed. If we need to ignore more files, we need
> > to request our users to upgrade portage.
> > 
> > That's why I'm thinking of moving them to profiles/base/make.defaults.
> > From what I've tested, the setting there will override make.globals
> > and therefore the change could be effective from day one, without
> > the need to upgrade portage.
> > 
> > I feel like those variables are much alike the QA variables that we
> > keep in the profiles.
> > 
> > What do you think?
> > 
> 
> Are we sure that this thing really belongs in the profile, rather than
> something that's defined in ebuilds? Or maybe we should have both?

Well, AFAICS we have three cases:

1. kernel modules that all are installed to a common location
and therefore global collision/uninstall ignore setting works fine,

2. Python compiled files that all are installed the same way by the new
eclasses + sys-apps/portage which still ignores the new eclasses
and tries to pretend being one of them,

3. Twisted dropin.cache files that are installed the same way and use
a common eclass.

I think in all three cases, we could move it off the profile to
eclasses. But I don't think it's worth the effort.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

Re: [gentoo-dev] [RFC] Moving COLLISION_IGNORE (and UNINSTALL_IGNORE?) to profiles/*/make.defaults

[Zac Medico]

On 08/10/2013 12:48 AM, Michał Górny wrote:
>> Are we sure that this thing really belongs in the profile, rather than
>> something that's defined in ebuilds? Or maybe we should have both?
> 
> Well, AFAICS we have three cases:
> 
> 1. kernel modules that all are installed to a common location
> and therefore global collision/uninstall ignore setting works fine,
> 
> 2. Python compiled files that all are installed the same way by the new
> eclasses + sys-apps/portage which still ignores the new eclasses
> and tries to pretend being one of them,
> 
> 3. Twisted dropin.cache files that are installed the same way and use
> a common eclass.
> 
> I think in all three cases, we could move it off the profile to
> eclasses. But I don't think it's worth the effort.

Sure, it's convenient now to just throw some variables in the profile
and be done with it. But we should also consider potential long-term
implications. Who knows how big this profile variable will eventually
grow? Will we have make it an "incremental" variable to make it more
manageable as Martin Vaeth suggested? What about ebuilds in overlays
that would like to encapsulate a private COLLISION_IGNORE setting?
-- 
Thanks,
Zac

Re: [gentoo-dev] [RFC] Moving COLLISION_IGNORE (and UNINSTALL_IGNORE?) to profiles/*/make.defaults

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 574 bytes --]

Dnia 2013-08-09, o godz. 11:32:12
Michał Górny <mgorny@gentoo.org> napisał(a):

> Hello,
> 
> Just a quick one.
> 
> Currently, the two listed variables are set in make.globals (installed
> by portage ebuild);
> 
> COLLISION_IGNORE="/lib/modules/* *.py[co] *\$py.class"
> UNINSTALL_IGNORE="/lib/modules/*"

I've committed the following values for now:

COLLISION_IGNORE="/lib/modules/* *.py[co] *\$py.class */dropin.cache"
UNINSTALL_IGNORE="/lib/modules/*"

We can discuss further changes without users suffering.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

Re: [gentoo-dev] [RFC] Moving COLLISION_IGNORE (and UNINSTALL_IGNORE?) to profiles/*/make.defaults

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1632 bytes --]

Dnia 2013-08-10, o godz. 01:14:52
Zac Medico <zmedico@gentoo.org> napisał(a):

> On 08/10/2013 12:48 AM, Michał Górny wrote:
> >> Are we sure that this thing really belongs in the profile, rather than
> >> something that's defined in ebuilds? Or maybe we should have both?
> > 
> > Well, AFAICS we have three cases:
> > 
> > 1. kernel modules that all are installed to a common location
> > and therefore global collision/uninstall ignore setting works fine,
> > 
> > 2. Python compiled files that all are installed the same way by the new
> > eclasses + sys-apps/portage which still ignores the new eclasses
> > and tries to pretend being one of them,
> > 
> > 3. Twisted dropin.cache files that are installed the same way and use
> > a common eclass.
> > 
> > I think in all three cases, we could move it off the profile to
> > eclasses. But I don't think it's worth the effort.
> 
> Sure, it's convenient now to just throw some variables in the profile
> and be done with it. But we should also consider potential long-term
> implications. Who knows how big this profile variable will eventually
> grow? Will we have make it an "incremental" variable to make it more
> manageable as Martin Vaeth suggested? What about ebuilds in overlays
> that would like to encapsulate a private COLLISION_IGNORE setting?

So far, I believe this is mostly a convenience for the migration
period. I would be happy to remove the values that were added for
Python packages as soon as we kill the old eclass.

Is changing/extending the scope of it in the future a problem?

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

Re: [gentoo-dev] [RFC] Moving COLLISION_IGNORE (and UNINSTALL_IGNORE?) to profiles/*/make.defaults

[Zac Medico]

On 08/10/2013 02:22 AM, Michał Górny wrote:
> Dnia 2013-08-10, o godz. 01:14:52
> Zac Medico <zmedico@gentoo.org> napisał(a):
> 
>> On 08/10/2013 12:48 AM, Michał Górny wrote:
>>>> Are we sure that this thing really belongs in the profile, rather than
>>>> something that's defined in ebuilds? Or maybe we should have both?
>>>
>>> Well, AFAICS we have three cases:
>>>
>>> 1. kernel modules that all are installed to a common location
>>> and therefore global collision/uninstall ignore setting works fine,
>>>
>>> 2. Python compiled files that all are installed the same way by the new
>>> eclasses + sys-apps/portage which still ignores the new eclasses
>>> and tries to pretend being one of them,
>>>
>>> 3. Twisted dropin.cache files that are installed the same way and use
>>> a common eclass.
>>>
>>> I think in all three cases, we could move it off the profile to
>>> eclasses. But I don't think it's worth the effort.
>>
>> Sure, it's convenient now to just throw some variables in the profile
>> and be done with it. But we should also consider potential long-term
>> implications. Who knows how big this profile variable will eventually
>> grow? Will we have make it an "incremental" variable to make it more
>> manageable as Martin Vaeth suggested? What about ebuilds in overlays
>> that would like to encapsulate a private COLLISION_IGNORE setting?
> 
> So far, I believe this is mostly a convenience for the migration
> period. I would be happy to remove the values that were added for
> Python packages as soon as we kill the old eclass.

That sounds reasonable.

> Is changing/extending the scope of it in the future a problem?

Probably not much of a problem, if any.
-- 
Thanks,
Zac

Re: [gentoo-dev] [RFC] Moving COLLISION_IGNORE (and UNINSTALL_IGNORE?) to profiles/*/make.defaults

[yac]

[-- Attachment #1: Type: text/plain, Size: 890 bytes --]

There should not be a collision of the dropin.cache in the first place.

By adding the cache files to COLLISION_IGNORE it will just hide the
collision problem and create other one (with obsolette caches), harder
to debug.

On Sat, 10 Aug 2013 11:19:59 +0200
Michał Górny <mgorny@gentoo.org> wrote:

> Dnia 2013-08-09, o godz. 11:32:12
> Michał Górny <mgorny@gentoo.org> napisał(a):
> 
> > Hello,
> > 
> > Just a quick one.
> > 
> > Currently, the two listed variables are set in make.globals
> > (installed by portage ebuild);
> > 
> > COLLISION_IGNORE="/lib/modules/* *.py[co] *\$py.class"
> > UNINSTALL_IGNORE="/lib/modules/*"
> 
> I've committed the following values for now:
> 
> COLLISION_IGNORE="/lib/modules/* *.py[co] *\$py.class */dropin.cache"
> UNINSTALL_IGNORE="/lib/modules/*"
> 
> We can discuss further changes without users suffering.
> 


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] [RFC] Moving COLLISION_IGNORE (and UNINSTALL_IGNORE?) to profiles/*/make.defaults

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1343 bytes --]

No. It will make the migration to owned caches simpler while keeping
track of them.

> By adding the cache files to COLLISION_IGNORE it will just hide the
> collision problem and create other one (with obsolette caches), harder
> to debug.

Yep, that's why I have submitted a patch to portage that prevents
applying COLLISION_IGNORE to owned files.

> There should not be a collision of the dropin.cache in the first place.

First of all, please reply below mails as otherwise reading them is
difficult.

Dnia 2013-08-12, o godz. 13:46:16
yac <yac@gentoo.org> napisał(a):

> On Sat, 10 Aug 2013 11:19:59 +0200
> Michał Górny <mgorny@gentoo.org> wrote:
> 
> > Dnia 2013-08-09, o godz. 11:32:12
> > Michał Górny <mgorny@gentoo.org> napisał(a):
> > 
> > > Hello,
> > > 
> > > Just a quick one.
> > > 
> > > Currently, the two listed variables are set in make.globals
> > > (installed by portage ebuild);
> > > 
> > > COLLISION_IGNORE="/lib/modules/* *.py[co] *\$py.class"
> > > UNINSTALL_IGNORE="/lib/modules/*"
> > 
> > I've committed the following values for now:
> > 
> > COLLISION_IGNORE="/lib/modules/* *.py[co] *\$py.class */dropin.cache"
> > UNINSTALL_IGNORE="/lib/modules/*"
> > 
> > We can discuss further changes without users suffering.
> > 
> 



-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 966 bytes --]