devel/git-core is missing a dependency on perl/p5-error

[easye]

devel/git-core is missing a dependency on perl/p5-error manifested when attempting to run 'git remote status'. Error involves the

use Error qw(:try)

in Git.pm

I'm probably just noticing this as I don't really have much other Perl installed from MacPorts.

[simon@…]

CCing maintainers so they can review your problem.

[mgrimes@…]

Can someone please test moving port:perl and port:p5-error from the svn variant to the main depends_run? Primarily since git-remote requires a bloated perl installation to support this single recurring use case. I'm just unsure if p5-term-readkey or p5-libwww-perl have any requirement outside of git-svn. I have wanted to work this issue in the past but haven't had the means being a throw-away test box light these days. -- The machines I rely on always have git-core installed on intel and ppc with the svn variant enabled (partly due to using MacPorts et al under git) which taints my visibility of the problem due to the extra perl module placement.

[bryan@…]

this is a duplicate of Ticket #12089. I did testing of a variety of scenarios for that Ticket.

To summarize: the git Makefile is set up to install Error.pm when it isn't installed already. If we want this behaviour, we should patch it to install it into a place that actually works. Of course, if the user only has Apple Perl installed, the only places that will work are outside of /opt/local, and this would be exceedingly rude, if it is even allowed at all...

I'm trying to find the last e-mail discussion I had with somebody with commit access. I'm fairly sure we agreed that we should just go ahead and make port:perl and port:p5-error a requirement for everybody since nobody had the time to go in and figure out what needed to be done to do it properly.

Of course, it appears even that didn't get done.

[mgrimes@…]

Wow. As a maintainer of the port you are welcome to submit patches that you've personally tested and would like to see committed. It would sure be more productive and concise than hand-waving discussion and complaining about what others aren't doing for your port when you've obviously conducted several tests on how to solve the issue. I've previously mentioned this is a use case I cannot / have not been able to test so I've dropped the ball on the issue -- I'd hope people aren't just settling with a broken port that they themselves have solved the problem out of band to MacPorts but yet complain turn around to complain about it in Trac when their email address gets spammed.

[mgrimes@…]

port:perl and port:p5-error extracted from svn variant and added to main depends_run in r28705. Can we consider this issue closed now?

[bryan@…]

[ second comment by mgrimes added while I was typing. Reposting comment so it doesn't get lost again. ]

Oh yes, it's certainly my fault that I didn't follow up on the issue once the hard work was done.

We know what the problem is, the question is, how do we solve it? There are at least 3 alternatives:

1) split off git remote into an optional variant just like we did with git-svn.

2) require MacPort's Perl for everything even though git works fine with Apple Perl and the Error.pm that comes with git. Perl takes hours to build and takes up a lot of space, so that's a very costly solution.

3) patch the git Makefile so that it puts it's Error.pm in a correct location and then (if necessary) patch git-remote so that it looks in the right place.

I'm neither a Perl nor a MacPorts expert, so #3 would be a lot of work for me. It wouldn't take long for somebody who is; I can point them at the places that need modification.

Is #1 a viable option? It appears that variants aren't visible with some users, so this may be problematic. Otherwise, it's certainly the quickest and cleanest solution.

Since nothing has happened in so long, I'll go ahead and start testing #2. I'll go ahead and set up a virgin MacPorts, that'll take a few hours.

[bryan@…]

One other note: if the main variant includes perl, we've lost a lot of the motivation for having a -svn variant. I know that at least one user has run into trouble because they did not notice the variant and were surprised that git-svn didn't work. Merging the -svn variant into main will remove this problem at the cost of installation time and hard drive space for everybody who doesn't need svn support. (but probably less time & space than the perl requirement just added).

[mgrimes@…]

Your depiction of the what is the "hard work" is debatable. I can't commit discussion for you. I won't fix things I can't test because it is a waste of time. The half-baked solution is in place now to shunt the further tickets on the same issue -- it'd be nice if someone said, yes this fix works though, regardless of how straightforward it seems so I can definitively close the tickets. Software testing is good practice so I'm told.

1. Are you saying that you can functionally do every day to day task with a git tree and never need git-remote? I thought this was core functionality -- at least when I read the manpage this looks pretty essential. If this is essential I'd say no way jose, otherwise I'd say let's make it a default variant like +doc, that way people can still opt out.

2. I really don't like the idea of having git rely on Apple's Perl and git +svn rely on MacPort's Perl. It would have to be this way because there are other perl modules needed to support git-svn... these perl modules were not originally in place when I came over to work on git-core with you and due to this git-svn broken in many different ways.

3. Where is the correct location? If you are implying that MacPorts actually reaches outside /opt and dumps things in /Library/Perl I'd hesitate to think any other port does this. At worst the aqua ports install to /Applications/MacPorts but any variation of this jailing scheme without directly writing to Apple specific locations would not fit inside the bounds of the @INC. What a mess Perl is...

We have very good reason to keep the svn variant due to the long subversion dependency chain.

So far I like #1 best, but maybe you can convince me that git-remote is not really a necessary part of maintaining a git repository that you are hosting somewhere.

Otherwise I'd prefer we deal with the Perl dependency, after all how many times do you build Perl on a given box? It's a lot of discussion to have over an event that doesn't happen often especially in light of other solutions about how we are going to attempt to avoid this rare event by really jacking up the variants.

[(none)]

Milestone Port Bugs deleted

[maccheck@…]

I think this bug is obsolete as we have path:bin/perl:perl5 and port:p5-error in the general depends_run.

Or am I missing a point here?

[jmroot (Joshua Root)]

OK, closing.