PortFile command

[René J.V. Bertin]

On Thursday January 26 2017 23:58:40 Rainer Müller wrote:

> So, there are about 100 lines before lots of subports {} are defined.
> Why can't these be moved to a PortGroup

They could, but that's not code that has any business being made available to every port out there.
Of course that would change if the PortGroup command would also support loading a "private" portgroup from the port directory, but that takes us back to my proposal :)

> referenced from individual Portfiles with normal checksums?

That could be done too, but will make the update process a lot more cumbersome. I have a script that generates the checksums, which is a lot more convenient than having to do 60+ times a manual copy/paste.
Even with all the streamlining I've achieved over the last year it still takes me approx. 2 days to implement an upgrade, and upstream upgrades are pushed about once a month.

> Maybe I am missing something from my quick look, but I do not see the
> advantage of using subports here. The only shared option is the version
> number?

There used to be shared patches, I'm not certain off the top of my head if they're all obsolete by now.
In practice it's really only the length of the file that makes it a bit unwieldy, but much less so than 60+ individual ports. This is personal of course, for the end-user it makes almost no difference.

> This would already cause trouble as this file is not taken into account
> for the modification check (via Portfile checksum) in the statefile.
> Modifications to the checksum file alone would not lead to cleaning of a
> previously created work directory.

No, but that's an advantage for me on my end, and in practice this problem never occurs because the Portfile is always modified during an upgrade.

Modifications to PortGroup files are also not taken into account as far as I know, and that can have more important implications, like during port indexing. 

> This does not convince me that including other files into Portfiles has
> a large benefit, although adding more work in base.

As I said, it was just an idea, no point pursuing it if I'm the only one seeing the benefit.

But about that: wouldn't it simplify things if proc PortGroup stored the full path of each loaded PortGroup in PortInfo(portgroup)? Unless I miss something that ought to save determining the path anew in registry::write.

R