p5-app-ack: Rename to ack

[raimue (Rainer Müller)]

The p5-app-ack port does not provide a perl module but an application. Currently there are several ports where each installs a different ack-5.XY. Subports work for modules targeting multiple versions of perl5, but this is not useful for an application.

This port should be available as plain ack.

[mschout@…]

Replying to raimue@…:

The p5-app-ack port does not provide a perl module but an application. Currently there are several ports where each installs a different ack-5.XY. Subports work for modules targeting multiple versions of perl5, but this is not useful for an application.

This port should be available as plain ack.

It *is* available as plain ack. You just need to set your path properly. If you prefer version 5.14 of perl for example, your path needs to have /opt/local/libexec/perl5.14 in it. This is how macports handles bin scripts for multiple versions of perl.

[raimue (Rainer Müller)]

Please apply the patch like this to record the copy information properly:

trunk/dports $ svn cp perl/p5-app-ack devel/ack
trunk/dports $ svn patch /tmp/ack-rename.diff

[raimue (Rainer Müller)]

Replying to mschout@…:

It *is* available as plain ack. You just need to set your path properly. If you prefer version 5.14 of perl for example, your path needs to have /opt/local/libexec/perl5.14 in it. This is how macports handles bin scripts for multiple versions of perl.

In my opinion, for modules it's important to have them available for all available versions of perl. But this does not make sense for a tool like ack. Why do I have to choose from these different versions? Why do I have to change my PATH to use this tool?

[mschout@…]

I do not know why macports does things this way.

Honestly this is why I prefer perlbrew for things like this.

[raimue (Rainer Müller)]

See also this thread on macports-dev: ​https://lists.macosforge.org/pipermail/macports-dev/2013-January/021485.html

[cooljeanius (Eric Gallager)]

Cc Me!

[redpola (Neil Brewitt)]

User expectation is that I type "port install p5-app-ack" and can then type "ack foobar" to use the tool I just installed.

Telling me on some trac page that I had difficulty finding that I need to update my path after installing p5-app-ack to get the "ack" command is really not acceptable.

I'd rather install the tool from source, which is probably not one of the aims of macports.

[redpola (Neil Brewitt)]

Cc Me!

[mschout@…]

I don't disagree with anything here, but I have no idea how, or if its even possible, to fix this in the current macports infrastructure. I don't really have any idea how this could be fixed in the port. If anyone wants to take a stab at it, patches are welcome.

[raimue (Rainer Müller)]

Well, what about the patch I attached here? Why is it even called p5-app-ack? I just want the tool ack and I don't care which language it is written in.

[mschout@…]

Replying to raimue@…:

Well, what about the patch I attached here? Why is it even called p5-app-ack? I just want the tool ack and I don't care which language it is written in.

But your patch does not install 'ack' It installs /opt/local/bin/ack-5.12. This hardly seems like an improvement other than the name of the port is changed. I'd rather see this fixed in a way that you get /opt/local/bin/ack installed from the port, but as said above, I have no idea if thats even possible within the constraints of macports perl build system.

[raimue (Rainer Müller)]

You could always add an additional symlink. I have not checked whether the perl port group allows to leave out the version suffix with some option.

[ryandesign (Ryan Carsten Schmidt)]

Replying to raimue@…:

I have not checked whether the perl port group allows to leave out the version suffix with some option.

It does; set perl5.link_binaries_suffix to empty. Perl app ports are expected to do this.

[ryandesign (Ryan Carsten Schmidt)]

Fixed in r123593. Thanks Rainer for the patch.