how to: meta-package port

Ryan Schmidt ryandesign at macports.org
Sat May 30 03:53:08 PDT 2015


On May 28, 2015, at 11:30 AM, René J.V. Bertin wrote:

> On Thursday May 28 2015 12:27:19 Lawrence Velázquez wrote:
> 
>> Install some dummy files instead of failing. Something like this:
>> 
>>    PortSystem 1.0
>>    name foo
>>    supported_archs noarch
>>    archive_sites
>>    distfiles
>>    use_configure no
>>    build {}
>>    destroot {
>>        system "echo $name is a stub port >${destroot}${prefix}/share/doc/${name}/README"
>>    }
> 
> I thought I'd been told not to override build and/or other phases, a while ago, but use some formula instead.

The above is the currently-accepted method of implementing a stub port, in the absence of a portfile option like "stub yes" which I would prefer because it would make it easier to locate stub ports.

https://lists.macosforge.org/pipermail/macports-dev/2014-September/028120.html

Even introducing a stub portgroup would be preferable to repeating this code everywhere.


In general you should not override phases if there are alternatives. Note in the above that the archivefetch, fetch, checksum, extract, patch and configure phases are not being overridden because alternatives are being used. (archivefetch is skipped because archive_sites is cleared; fetch, checksum and extract are skipped because distfiles is cleared; patch is skipped because patchfiles is empty; configure is skipped because use_configure is set to no (which also disables the universal variant, as does setting supported_archs to noarch).)


I don't like the name "stub port" because it is confusingly similar to "subport" which is a different concept. But not all stub ports are meta ports so we can't just call them meta ports.


> I shouldn't have mentioned raising an error: in fact I want to use the main port to depend on a specific subport by default (sort of like a default subport).

Right, that's done a lot, for example in all the py-*, p5-* and php-* ports. But that's the type of port I think of as not being a meta port. Maybe I'm overthinking the terminology, but I'm differentiating between a port that does nothing but depend on more than one other port for the purpose of making it easier to install a collection of ports (like the gimp port), and a port that does nothing but install a default subport of itself (e.g. the py, p5, php ports, etc.)



More information about the macports-dev mailing list