Re: [gentoo-portage-dev] [PATCH] Support @profile package set for bug #532224

[Zac Medico]

On 12/12/2014 08:01 AM, Rick "Zero_Chaos" Farina wrote:
> On 12/11/2014 03:38 AM, Zac Medico wrote:
>> On 12/11/2014 12:25 AM, Michał Górny wrote:
>>> Dnia 2014-12-10, o godz. 18:08:00
>>> Zac Medico <zmedico@g.o> napisał(a):
>>>
>>>> Add support for a new @profile set which allows the profile to pull
>>>> in additional packages that do not belong to the @system set.
>>>>
>>>> The motivation to have @profile separate from @system is that
>>>> @system packages may have incomplete dependency specifications
>>>> (due to long-standing Gentoo policy), and incomplete dependency
>>>> specifications have deleterious effects on the ability of emerge
>>>> --jobs to parallelize builds. So, unlike @system, packages added to
>>>> @profile do not hurt emerge --jobs parallelization.
>>>>
>>>> Packages are added to the @profile set in the same way that they are
>>>> added to the @system set, except that atoms in the @profile set are
>>>> not preceded with a '*' character. Also, the @profile package set
>>>> is only supported when 'profile-set' is listed in the layout.conf
>>>> profile-formats field of the containing repository.
>>>
>>> PMS says PMs ought to ignore atoms without '*'. This means we can't use
>>> it without profile EAPI change, or other PMs will start losing packages.
>
> I have to agree, any chance we can get this into EAPI 6?

Yes, that would be nice.

>>
>> It's hidden behind a layout.conf profile-formats flag, so it's beyond
>> the scope of PMS. Package managers should reject the profile if they
>> don't recognize the profile-formats flags that it declares.
>>
> Yes, but that still makes this change incompatible with other package
> managers, no?

I'm not sure that "incompatible" is the best word. It's an extension,
and the general nature of extensions is that software needs to be
updated in order to support them. Other package managers are welcome to
implement this extension, but they are under no obligation to.

> If we remove the leading * from a package to signify that
> it can safely be built in parallel that would mean all non-portage
> package managers would just plain lose the package, if they didn't shit
> themselves because the file had an invalid line.

It depends on the package manager's profile-formats implementation. If a
package manager rejects profiles with unrecognized profile-formats
flags, then it should simply give an error message about the profile
having unsupported profile-formats extensions.

Existing releases of portage only produce a warning if profile-formats
has unrecognized extensions. The advantage of this approach is that it's
feasible to enable profile-set on existing profiles, and it's still
possible for existing deployments that use those profiles to upgrade
from older portage to a new version that supports the profile-set extension.

I would not recommend to enable the profile-set extension in the
"gentoo" repository for a couple of reasons:

1) Other supported package managers don't support the profile-set
extension yet.

2) We don't have a stable-keyworded version of sys-apps/portage
supporting the profile-set extension yet, so stable users will not be
able to use the this extension with current versions of stable-keyworded
sys-apps/portage.

However, the above issues are not necessarily relevant to repositories
other than "gentoo", so it may be feasible for them to utilize the
profile-set extension immediately.

> We need to make this EAPI dependant or we are going to break things, and
> QA doesn't like it when things this big break.  I love where this is
> going, but I do not see a better solution here than making it EAPI
> dependent.

Making it EAPI dependent is not mutually exclusive from the
profile-formats approach. We can certainly do both. I would recommend to
use the EAPI approach for the "gentoo" repository. Other repositories
can enable the profile-set extension immediately, as long as the
mentioned issues are irrelevant to their consumers.
-- 
Thanks,
Zac