[90178] trunk/dports/textproc/help2man/Portfile

[Jeremy Lavergne]

>> What about just making all the subports conflict (perl5.8 conflicts perl5.10), letting the virtual (versionless) perl package control the default version (macports-wide), and then the user can switch out the whole perl tree using the virtual's package variant (which would conflict with the previous)?
>> 
>> It seems we're almost there: we have the virtual package but it doesn't tightly restrict what version is used.
> 
> That'd be better, but how do you deal with upgrading when a new version
> of perl comes along?

The dependency engine should go "oh, your existing +perl512 is incompatible with +perl514, rebuild perl5." which then goes "oh, p5.12-XXXX is incompat with p5.14-XXX, disabling p5.12-XXX" through the tree. It should work purely based on each version of perl hating the rest of them, which could be done automatically in the portgroup I hope (minimal effort, maybe?).

> When we had only one version of perl, the answer
> was pretty clear: update the perl5 port, and revbump p5-*. With this,
> you'd have to... remove p5.12-*, and manually install the corresponding
> p5.14-* ports? Or maybe force-rebuild the p5-* stub ports? I don't
> think we should require people to manually intervene.

Letting the dependency engine go "everything perl needs uninstalled" is better than issuing a revbump everywhere. Honestly, I'd go for an epoch++ myself but since that doesn't work without revbump we're kinda stuck using revbump anyways. Since it's rpm though, perhaps rev += -1 woudl suffice (0 < 0-1). 

> I'm also not thrilled about supporting multiple versions just on
> maintainability grounds -- who knows what'll break if your only perl is
> v5.8? I doubt anyone tests it. I certainly don't.

Some crazy people somewhere :-) I don't mind keeping it around provided we say you can only use one at a time. Maintainers just need to say "perl" then, and when "perl"'s version changes, everything underneath is silently rebuilt/replaced. I don't know if any non-perl programs would embed perl in some fashion though, but that's a dependency we could find if properly marked or through rev-upgrade.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 8796 bytes
Desc: not available
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20120301/3fb6981c/attachment.bin>