PortGroup directory hierarchy/priority

[René J.V. Bertin]

On Monday April 04 2016 18:47:03 Clemens Lang wrote:

Hi,

>Paths and flags should be part of configuration files installed by a
>port, e.g. CMake config files or pkg-config files.

They aren't always ... esp. not if those very files were hidden away by the port. The paths can also be to executables, and the flags could depend on a variant that is to be available to all dependent ports (cf. +universal).

>> There's only one way to enforce the reproducible build principle all
>> the way, and that's to remove the whole possibility of building from
>> source so that users can only install official, binary packages.
>
>No, that's (a) not true and (b) actually prevents one of the goals of

I can see (b) but not (a)?

>Sure, let's assume you change the github 1.0 PortGroup, because you need
>an additional feature… that could change how other ports fetch, and thus
>the source that is being built be other ports.

Hmm, indeed - and that PortGroup would be a reasonable candidate for installation by a custom git port, as well as for blacklisting that would make it impossible to override the official file via an integrated mechanism.
However, my argument still stands that the developer of that port and PortGroup would be subject to the same thing.
There's indeed a trust issue there, but one that goes both ways. 

>The whole installation idea does not work with the current codebase. If
>a PortGroup changes, the information in the PortIndex needs to be
>updated, but the PortIndex uses the modification date of Portfiles to
>determine whether the information is current.

So no PortGroup is taken into account?

>You can not change how a port behaves without touching the Portfile. See
>the above rationale on the PortIndex.

And that doesn't apply to copying PortGroups manually into _resources?

>I think most of this discussion could be solved by merging your changes
>into the main port tree, couldn't it? I think that's what we should be

Yes, that's true. There is testing underway to that end, but only 2 or 3 port developers have stepped up to help here, and there's barely any activity on the corresponding trac tickets.

R.