[gentoo-dev] [RFC] New GLEP: file installation masks

[gentoo-dev] [RFC] New GLEP: file installation masks

[Michał Górny]

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

Hello,

Sometime around a year ago, I started working on extending INSTALL_MASK
to support well-defined locations. The work was never finished, and I
just found my old specification for it. I've cleaned it up a bit,
and extended it into a complete GLEP covering INSTALL_MASK [1].

Please review the specification provided. The basic goal is to provide
an ability to use INSTALL_MASK alike USE flags -- with path groups that
are well-defined and described in the repository.

[1]:https://wiki.gentoo.org/wiki/User:MGorny/GLEP:INSTALL_MASK

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

Re: [gentoo-dev] [RFC] New GLEP: file installation masks

[Michael Orlitzky]

On 05/20/2016 10:01 AM, Michał Górny wrote:
> 
> Please review the specification provided. The basic goal is to provide
> an ability to use INSTALL_MASK alike USE flags -- with path groups that
> are well-defined and described in the repository.
> 
> [1]:https://wiki.gentoo.org/wiki/User:MGorny/GLEP:INSTALL_MASK
> 

I like the idea. INSTALL_MASK is currently pretty flaky, and that's what
we tell people to use to block e.g. systemd units. Here's what I gather:

  1. The INSTALL_MASK-like feature should support fnmatch() wildcards.

  2. Binary packages are not be affected (there's another feature for
     that)

  3. We can define groups of paths to make certain things (bash
     completions, locales, etc.) easy to mask.

All of those are good, but are the details of what actually goes in
INSTALL_MASK left up to the implementation? How would I mask all bash
completions (the bash-completion group) using INSTALL_MASK?

Can you make the spec say that we should be able to mask files whose
names contain spaces? Or is that implicit in the fnmatch() clause?

For the portage implementation, it may be time to ditch the variable and
move to something like /etc/portage/install.mask:

  $ cat /etc/portage/install.mask
  [bash-completion]
  /etc/logrotate.d
  read me.txt

With one pattern per line, the spaces thing is easy to deal with. But
this makes me wonder, how is portage supposed to know I want to block
the bash-completion group and not all files named "[bash-completion]"?

Re: [gentoo-dev] [RFC] New GLEP: file installation masks

[Michał Górny]

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

On Fri, 20 May 2016 11:12:02 -0400
Michael Orlitzky <mjo@gentoo.org> wrote:

> On 05/20/2016 10:01 AM, Michał Górny wrote:
> > 
> > Please review the specification provided. The basic goal is to provide
> > an ability to use INSTALL_MASK alike USE flags -- with path groups that
> > are well-defined and described in the repository.
> > 
> > [1]:https://wiki.gentoo.org/wiki/User:MGorny/GLEP:INSTALL_MASK
> >   
> 
> I like the idea. INSTALL_MASK is currently pretty flaky, and that's what
> we tell people to use to block e.g. systemd units. Here's what I gather:
> 
>   1. The INSTALL_MASK-like feature should support fnmatch() wildcards.
> 
>   2. Binary packages are not be affected (there's another feature for
>      that)
> 
>   3. We can define groups of paths to make certain things (bash
>      completions, locales, etc.) easy to mask.
> 
> All of those are good, but are the details of what actually goes in
> INSTALL_MASK left up to the implementation? How would I mask all bash
> completions (the bash-completion group) using INSTALL_MASK?

Yes. Configuration and implementation is left to implementation.
The spec only says that it should be possible to somehow enable
inclusive/exclusive filtering of specific files, and the end result
should be as if they weren't installed in the first place.

Getting into implementation details, I'd probably go for:

  INSTALL_MASK="@bash-completion"

but the exact syntax is left for various package managers. Paludis
and pkgcore would probably prefer a proper configuration file.

> Can you make the spec say that we should be able to mask files whose
> names contain spaces? Or is that implicit in the fnmatch() clause?

Well, this should be implicit in fnmatch() for repo-defined paths.
However, we leave this undefined for INSTALL_MASK itself, so custom
paths will probably have to be declared in install-mask.conf-alike
in /etc/portage.

> For the portage implementation, it may be time to ditch the variable and
> move to something like /etc/portage/install.mask:
> 
>   $ cat /etc/portage/install.mask
>   [bash-completion]
>   /etc/logrotate.d
>   read me.txt
> 
> With one pattern per line, the spaces thing is easy to deal with. But
> this makes me wonder, how is portage supposed to know I want to block
> the bash-completion group and not all files named "[bash-completion]"?

I'd leave this for Portage people to decide. Though I'd prefer
if /etc/portage had file with the same or similar syntax to repo file.

--
Best regards,
Michał Górny

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

Re: [gentoo-dev] [RFC] New GLEP: file installation masks

[Michael Orlitzky]

On 05/20/2016 11:21 AM, Michał Górny wrote:
> 
> ...
> 
> Getting into implementation details, I'd probably go for:
> 
>   INSTALL_MASK="@bash-completion"
> 
> but the exact syntax is left for various package managers. Paludis
> and pkgcore would probably prefer a proper configuration file.
> 

Ok, thanks.

Isn't "@bash-completion" a well-defined path[0]? Since the reference
implementation is TODO, I'm wary of specifying something that may be
unworkable.


[0] I think -- it would be helpful to define "well-defined path"
    and "direct path".

Re: [gentoo-dev] [RFC] New GLEP: file installation masks

[Michał Górny]

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

On Fri, 20 May 2016 11:30:59 -0400
Michael Orlitzky <mjo@gentoo.org> wrote:

> On 05/20/2016 11:21 AM, Michał Górny wrote:
> > 
> > ...
> > 
> > Getting into implementation details, I'd probably go for:
> > 
> >   INSTALL_MASK="@bash-completion"
> > 
> > but the exact syntax is left for various package managers. Paludis
> > and pkgcore would probably prefer a proper configuration file.
> > 
> 
> Ok, thanks.
> 
> Isn't "@bash-completion" a well-defined path[0]? Since the reference
> implementation is TODO, I'm wary of specifying something that may be
> unworkable.
> 
> 
> [0] I think -- it would be helpful to define "well-defined path"
>     and "direct path".

I'd make '@' signify group names, like we do for sets. This would have
the side limitation that it would make it impossible to filter
filenames starting with '@' with the currently supported
path-or-filename syntax.

--
Michał Górny

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

Re: [gentoo-dev] [RFC] New GLEP: file installation masks

[Michael Orlitzky]

On 05/20/2016 11:44 AM, Michał Górny wrote:
> 
> I'd make '@' signify group names, like we do for sets. This would have
> the side limitation that it would make it impossible to filter
> filenames starting with '@' with the currently supported
> path-or-filename syntax.
> 

That may be the best we can do, but in that case it's only fair to
mention the exception in the GLEP. I know you don't want implementation
details in there, but if *nobody* can come up with an implementation
that doesn't invalidate some well-defined paths, then we should
weasel-word the spec so that we don't wind up with zero fully-compliant
package managers =)

The @set notation isn't as much of a problem since it doesn't collide
with package atoms... which gives me an idea. If we make "/" illegal in
group names, then "@dir/*.*" can be interpreted as a path. That's a
little better.

Or, if we specify that the fnmatch pattern is applied to the absolute
path, I think you can stick a leading "/*" on any pattern without loss
of generality. So if you wanted to block all PDF files beginning with an
"@", then instead of "@*.pdf" you could do "/*@*.pdf".

Re: [gentoo-dev] [RFC] New GLEP: file installation masks

[Michał Górny]

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

On Fri, 20 May 2016 12:15:36 -0400
Michael Orlitzky <mjo@gentoo.org> wrote:

> On 05/20/2016 11:44 AM, Michał Górny wrote:
> > 
> > I'd make '@' signify group names, like we do for sets. This would have
> > the side limitation that it would make it impossible to filter
> > filenames starting with '@' with the currently supported
> > path-or-filename syntax.
> >   
> 
> That may be the best we can do, but in that case it's only fair to
> mention the exception in the GLEP. I know you don't want implementation
> details in there, but if *nobody* can come up with an implementation
> that doesn't invalidate some well-defined paths, then we should
> weasel-word the spec so that we don't wind up with zero fully-compliant
> package managers =)

That's not a case since GLEP doesn't define how it is configured.
And it's invalid to reference other groups in path=s of a defined
group.


-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

Re: [gentoo-dev] [RFC] New GLEP: file installation masks

[Michael Orlitzky]

On 05/20/2016 12:48 PM, Michał Górny wrote:
> 
> That's not a case since GLEP doesn't define how it is configured.
> And it's invalid to reference other groups in path=s of a defined
> group.
> 

I'm just playing language lawyer. The spec does say,

  A Package Manager implementing this specification must provide an
  ability for user to configure installed path filtering. User must be
  allowed to at least select well-defined paths.

But "@bash-completion" is a well-defined path, and if we use the set
notation, Portage users can't select it for masking.

If "/" is made illegal in group names, then I could write
"/*@bash-completion" instead. But we would still need to change the
wording a bit to acknowledge the fact that some paths are invalid.
Something like,

  The package manager may treat some well-defined paths as invalid,
  as long as an equivalent valid path exists and is accepted.

Re: [gentoo-dev] [RFC] New GLEP: file installation masks

[Michał Górny]

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

On Fri, 20 May 2016 13:34:37 -0400
Michael Orlitzky <mjo@gentoo.org> wrote:

> On 05/20/2016 12:48 PM, Michał Górny wrote:
> > 
> > That's not a case since GLEP doesn't define how it is configured.
> > And it's invalid to reference other groups in path=s of a defined
> > group.
> >   
> 
> I'm just playing language lawyer. The spec does say,
> 
>   A Package Manager implementing this specification must provide an
>   ability for user to configure installed path filtering. User must be
>   allowed to at least select well-defined paths.

I will update it to use 'path groups' or another term like it :-P.

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

Re: [gentoo-dev] [RFC] New GLEP: file installation masks

[Daniel Campbell]

[-- Attachment #1.1: Type: text/plain, Size: 1752 bytes --]

On 05/20/2016 07:01 AM, Michał Górny wrote:
> Hello,
> 
> Sometime around a year ago, I started working on extending INSTALL_MASK
> to support well-defined locations. The work was never finished, and I
> just found my old specification for it. I've cleaned it up a bit,
> and extended it into a complete GLEP covering INSTALL_MASK [1].
> 
> Please review the specification provided. The basic goal is to provide
> an ability to use INSTALL_MASK alike USE flags -- with path groups that
> are well-defined and described in the repository.
> 
> [1]:https://wiki.gentoo.org/wiki/User:MGorny/GLEP:INSTALL_MASK
> 
I'm totally in favor of this. The '@' prefix idea from your other mail
makes sense, too. Having the repo config file in addition to a custom
/etc/portage/install.mask file (for creating your own groups) is the
most robust way to do this imo. How would we handle namespace clashes,
though? For example, let's say the repo has this:

[bash-completion]
path=/usr/share/bash-completion/*
desc=bash completion files

...and the user has this in their install.mask file:

[bash-completion]
path=/some/other/path
desc=some other description

...then their make.conf has INSTALL_MASK="-@bash-completion" or something.

Should the package manager add the user-supplied path to the existing
"bash-completion" mask group? Should it output an error? Prefix every
group name in the user's install.mask with "user_"?

Otherwise this is a fantastic idea. I'm new to hacking on Portage but if
you have the time and/or patience I'd like to take part in hacking on this.

-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [gentoo-dev] [RFC] New GLEP: file installation masks

[Michael Orlitzky]

On 05/20/2016 11:34 AM, Daniel Campbell wrote:
> 
> ...and the user has this in their install.mask file:
> 
> [bash-completion]
> path=/some/other/path
> desc=some other description
> 

I don't think that's allowed; the groups are specified by each
repository's metadata/install-mask.conf, not by the users.

Although, you can ask the same question about overlays that have
group-name clashes. Is that an error, or would we use the one from the
overlay?

Re: [gentoo-dev] [RFC] New GLEP: file installation masks

[Michał Górny]

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

On Fri, 20 May 2016 11:40:39 -0400
Michael Orlitzky <mjo@gentoo.org> wrote:

> On 05/20/2016 11:34 AM, Daniel Campbell wrote:
> > 
> > ...and the user has this in their install.mask file:
> > 
> > [bash-completion]
> > path=/some/other/path
> > desc=some other description
> > 
> 
> I don't think that's allowed; the groups are specified by each
> repository's metadata/install-mask.conf, not by the users.
> 
> Although, you can ask the same question about overlays that have
> group-name clashes. Is that an error, or would we use the one from the
> overlay?

Oh, you are correct. Originally I planned to handle that, and I forgot
about it.

Since there can be multiple paths, we have two options: either
override, or amend like systemd does with *.d files. I think the former
would be less surprising.

Override is simple -- entry from next file overrides previous,
and discards all data.

Amending is harder. Description from next file overrides former, but
paths are appended. But there is special 'path=' (empty) that discards
all previous values and starts over. I don't think that's really a good
idea for repos.

--
Michał Górny

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

Re: [gentoo-dev] [RFC] New GLEP: file installation masks

[Ian Stakenvicius]

[-- Attachment #1.1: Type: text/plain, Size: 1445 bytes --]

On 20/05/16 11:49 AM, Michał Górny wrote:
> On Fri, 20 May 2016 11:40:39 -0400
> Michael Orlitzky <mjo@gentoo.org> wrote:
> 
>> On 05/20/2016 11:34 AM, Daniel Campbell wrote:
>>>
>>> ...and the user has this in their install.mask file:
>>>
>>> [bash-completion]
>>> path=/some/other/path
>>> desc=some other description
>>>
>>
>> I don't think that's allowed; the groups are specified by each
>> repository's metadata/install-mask.conf, not by the users.
>>
>> Although, you can ask the same question about overlays that have
>> group-name clashes. Is that an error, or would we use the one from the
>> overlay?
> 
> Oh, you are correct. Originally I planned to handle that, and I forgot
> about it.
> 
> Since there can be multiple paths, we have two options: either
> override, or amend like systemd does with *.d files. I think the former
> would be less surprising.
> 
> Override is simple -- entry from next file overrides previous,
> and discards all data.
> 
> Amending is harder. Description from next file overrides former, but
> paths are appended. But there is special 'path=' (empty) that discards
> all previous values and starts over. I don't think that's really a good
> idea for repos.


I'd vote override, simply because it would match the same behaviour
seen with eclasses and we could leverage the same 'masters =' in
repos.conf to manage order when dealing with multiple repos.




[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 213 bytes --]

Re: [gentoo-dev] [RFC] New GLEP: file installation masks

[Michał Górny]

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

On Fri, 20 May 2016 16:00:38 -0400
Ian Stakenvicius <axs@gentoo.org> wrote:

> On 20/05/16 11:49 AM, Michał Górny wrote:
> > On Fri, 20 May 2016 11:40:39 -0400
> > Michael Orlitzky <mjo@gentoo.org> wrote:
> >   
> >> On 05/20/2016 11:34 AM, Daniel Campbell wrote:  
> >>>
> >>> ...and the user has this in their install.mask file:
> >>>
> >>> [bash-completion]
> >>> path=/some/other/path
> >>> desc=some other description
> >>>  
> >>
> >> I don't think that's allowed; the groups are specified by each
> >> repository's metadata/install-mask.conf, not by the users.
> >>
> >> Although, you can ask the same question about overlays that have
> >> group-name clashes. Is that an error, or would we use the one from the
> >> overlay?  
> > 
> > Oh, you are correct. Originally I planned to handle that, and I forgot
> > about it.
> > 
> > Since there can be multiple paths, we have two options: either
> > override, or amend like systemd does with *.d files. I think the former
> > would be less surprising.
> > 
> > Override is simple -- entry from next file overrides previous,
> > and discards all data.
> > 
> > Amending is harder. Description from next file overrides former, but
> > paths are appended. But there is special 'path=' (empty) that discards
> > all previous values and starts over. I don't think that's really a good
> > idea for repos.  
> 
> 
> I'd vote override, simply because it would match the same behaviour
> seen with eclasses and we could leverage the same 'masters =' in
> repos.conf to manage order when dealing with multiple repos.

I thought about this more and decided we can't accept collisions
at all, since INSTALL_MASK is defined globally and not per ebuild. We
don't want the same mask to mean different things in different
repositories after all, do we? ;-)

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

[gentoo-dev] Re: [RFC] New GLEP: file installation masks

[Ulrich Mueller]

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

>>>>> On Fri, 20 May 2016, Michał Górny wrote:

> Sometime around a year ago, I started working on extending
> INSTALL_MASK to support well-defined locations. The work was never
> finished, and I just found my old specification for it. I've cleaned
> it up a bit, and extended it into a complete GLEP covering
> INSTALL_MASK [1].

> Please review the specification provided. The basic goal is to
> provide an ability to use INSTALL_MASK alike USE flags -- with path
> groups that are well-defined and described in the repository.

Sorry, I am late in the game. (Or maybe not, since the GLEP doesn't
yet have a number.)

The GLEP says that path groups always apply globally. So the
install-mask.conf file is not "alike layout.conf" (as the GLEP claims)
because its scope is not restricted to the repository where it is
stored. And in turn this can lead to name collisions ("Duplicate
groups [...] are considered an error").

Therefore I think that repository metadata is the wrong place for
storing the install-mask.conf file. It is configuration, specific to
Portage (but not to the repository), so /usr/share/portage/config/
would be a better location to store it. 

Ulrich

> [1]:https://wiki.gentoo.org/wiki/User:MGorny/GLEP:INSTALL_MASK

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

Re: [gentoo-dev] Re: [RFC] New GLEP: file installation masks

[Michał Górny]

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

On Wed, 8 Jun 2016 07:26:21 +0200
Ulrich Mueller <ulm@gentoo.org> wrote:

> >>>>> On Fri, 20 May 2016, Michał Górny wrote:  
> 
> > Sometime around a year ago, I started working on extending
> > INSTALL_MASK to support well-defined locations. The work was never
> > finished, and I just found my old specification for it. I've cleaned
> > it up a bit, and extended it into a complete GLEP covering
> > INSTALL_MASK [1].  
> 
> > Please review the specification provided. The basic goal is to
> > provide an ability to use INSTALL_MASK alike USE flags -- with path
> > groups that are well-defined and described in the repository.  
> 
> Sorry, I am late in the game. (Or maybe not, since the GLEP doesn't
> yet have a number.)
> 
> The GLEP says that path groups always apply globally. So the
> install-mask.conf file is not "alike layout.conf" (as the GLEP claims)
> because its scope is not restricted to the repository where it is
> stored. And in turn this can lead to name collisions ("Duplicate
> groups [...] are considered an error").
> 
> Therefore I think that repository metadata is the wrong place for
> storing the install-mask.conf file. It is configuration, specific to
> Portage (but not to the repository), so /usr/share/portage/config/
> would be a better location to store it. 

...which would mean we have to re-release Portage every time it
changes, which in turn means we can't do anything without having shout
at users to upgrade Portage, and upgrade, and upgrade...

systemd uses new path? Upgrade Portage. We support a new localization?
Upgrade Portage. We failed horribly and your system no longer boots?
Upgrade Portage.

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

Re: [gentoo-dev] Re: [RFC] New GLEP: file installation masks

[Ulrich Mueller]

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

>>>>> On Wed, 8 Jun 2016, Michał Górny wrote:

> On Wed, 8 Jun 2016 07:26:21 +0200
> Ulrich Mueller <ulm@gentoo.org> wrote:

>> Therefore I think that repository metadata is the wrong place for
>> storing the install-mask.conf file. It is configuration, specific to
>> Portage (but not to the repository), so /usr/share/portage/config/
>> would be a better location to store it.

> ...which would mean we have to re-release Portage every time it
> changes, which in turn means we can't do anything without having
> shout at users to upgrade Portage, and upgrade, and upgrade...

> systemd uses new path? Upgrade Portage. We support a new
> localization? Upgrade Portage. We failed horribly and your system
> no longer boots? Upgrade Portage.

Even now not all files in /usr/share/portage/config/ are owned by
sys-apps/portage. So if you expect path groups to change such
frequently, create a subdirectory install-mask/ (similar to sets/)
there and have packages install their configuration files in it.

Alternatively, one could think about placing the path groups file in
profiles/ which would still be better than repository metadata which
looks totally wrong to me.

Another question, how are path groups supposed to work in Prefix?
The GLEP doesn't address this.

Ulrich

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

Re: [gentoo-dev] Re: [RFC] New GLEP: file installation masks

[Michał Górny]

Dnia 8 czerwca 2016 09:17:06 CEST, Ulrich Mueller <ulm@gentoo.org> napisał(a):
>>>>>> On Wed, 8 Jun 2016, Michał Górny wrote:
>
>> On Wed, 8 Jun 2016 07:26:21 +0200
>> Ulrich Mueller <ulm@gentoo.org> wrote:
>
>>> Therefore I think that repository metadata is the wrong place for
>>> storing the install-mask.conf file. It is configuration, specific to
>>> Portage (but not to the repository), so /usr/share/portage/config/
>>> would be a better location to store it.
>
>> ...which would mean we have to re-release Portage every time it
>> changes, which in turn means we can't do anything without having
>> shout at users to upgrade Portage, and upgrade, and upgrade...
>
>> systemd uses new path? Upgrade Portage. We support a new
>> localization? Upgrade Portage. We failed horribly and your system
>> no longer boots? Upgrade Portage.
>
>Even now not all files in /usr/share/portage/config/ are owned by
>sys-apps/portage. So if you expect path groups to change such
>frequently, create a subdirectory install-mask/ (similar to sets/)
>there and have packages install their configuration files in it.
>
>Alternatively, one could think about placing the path groups file in
>profiles/ which would still be better than repository metadata which
>looks totally wrong to me.

I though the goal was to rid profiles/ of files other than profiles.

I can change the GLEP to have paths apply with masters logic if you want. That shouldn't cause much trouble, considering that the mask is evaluated per package anyway.

>
>Another question, how are path groups supposed to work in Prefix?
>The GLEP doesn't address this.

Hmm... I would say the obvious solution is to apply the paths relatively to EPREFIX, wouldn't it?

>
>Ulrich


-- 
Best regards,
Michał Górny (by phone)

Re: [gentoo-dev] Re: [RFC] New GLEP: file installation masks

[Ulrich Mueller]

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

>>>>> On Wed, 08 Jun 2016, Michał Górny wrote:

> I though the goal was to rid profiles/ of files other than profiles.

Thinking about it, putting it into profiles would make a lot of sense.
For example, one would want to define any systemd paths only in
non-systemd profiles.

> I can change the GLEP to have paths apply with masters logic if you
> want. That shouldn't cause much trouble, considering that the mask
> is evaluated per package anyway.

That doesn't change the fact that the file isn't repository metadata.

Ulrich

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

Re: [gentoo-dev] Re: [RFC] New GLEP: file installation masks

[Michał Górny]

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

On Wed, 8 Jun 2016 10:33:45 +0200
Ulrich Mueller <ulm@gentoo.org> wrote:

> >>>>> On Wed, 08 Jun 2016, Michał Górny wrote:  
> 
> > I though the goal was to rid profiles/ of files other than profiles.  
> 
> Thinking about it, putting it into profiles would make a lot of sense.
> For example, one would want to define any systemd paths only in
> non-systemd profiles.

If you put it like this, it indeed makes some sense. So should it be
fully profile-oriented (i.e. profiles/base being the base) or
profiles+top profile directory for all repos?

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 949 bytes --]