Opened 13 years ago

Closed 12 years ago

Last modified 12 years ago

#29707 closed defect (fixed)

git-core 1.7.5.3 fails to install doc if build and destroot run as separate commands

Reported by: mtalexander (Mike Alexander) Owned by: macports-tickets@…
Priority: Normal Milestone:
Component: ports Version: 1.9.99
Keywords: Cc: raimue (Rainer Müller), nerdling (Jeremy Lavergne)
Port: git-core

Description

If you run "sudo port build git-core +doc" and then "sudo port install git-core +doc" the documentation won't be installed. This is because the post_destroot code in the portfile uses ${extract.cmd} but it is not set in any given execution of the port command unless the extract phase is run in that execution. I will attach a patch that fixes this.

Attachments (1)

extract.patch (3.2 KB) - added by mtalexander (Mike Alexander) 13 years ago.
Patch to set all the extract.? variables whenever use_? is specified in a port file

Download all attachments as: .zip

Change History (7)

Changed 13 years ago by mtalexander (Mike Alexander)

Attachment: extract.patch added

Patch to set all the extract.? variables whenever use_? is specified in a port file

comment:1 Changed 13 years ago by mtalexander (Mike Alexander)

I didn't remove the code in portextract::extract_start which sets these variables. It is now redundant and probably could be removed but to be safe I left it in.

comment:2 Changed 13 years ago by raimue (Rainer Müller)

Cc: raimue@… added
Milestone: MacPorts Future
Port: git-core removed

I agree that this is a bug. Thank you for catching this.

I am not quite happy yet with the solution in the patch. I would remove the redundancy in fetch/extract. Defining options like this at multiple places will lead to diversity. A future developer might not be aware of the redundancy at all. I am also not convinced of moving the definition of the extract.* options to fetch as they do not belong there.

A better solution could be developed using lazy evaluation as we do it for the configure phase:

default extract.cmd            {[portextract::extract_get_cmd]}

This will be evaluated when extract.cmd will be read the first time.

comment:3 Changed 13 years ago by mtalexander (Mike Alexander)

I agree that setting things in two places is a bad idea, but that was already happening before my patch. portfetch was already processing the various use_xxx settings but it only set extract.suffix, not the other extract.xxx variables. I simply changed it to set the others. The other variables were being set as a side effect of starting the extract phase. Yes, it's wrong to set them there too, but I didn't remove that code partly to keep the patch small and partly to avoid any unknown side effects. Go ahead and remove the code in portextract that sets the other "extract.xxx" variables, it is redundant if they are set correctly when "use_xxx" is processed.

It seems to me to make more sense to set all the "extract.xxx" variables in one place when the "use_xxx" command is processed rather than set one of them there and the rest when the extract phase is started (if ever).

Are you suggesting that the default line you give above would be put in any port file that uses extract.cmd? If so this seems like at least as error prone as my proposed fix. Or am I not understanding what you intend?

comment:4 Changed 13 years ago by nerdling (Jeremy Lavergne)

Cc: snc@… added

Cc Me!

comment:5 Changed 12 years ago by raimue (Rainer Müller)

Resolution: fixed
Status: newclosed

The git-core port is now fixed in r96028.

No changes have been applied to base regarding this. extract.cmd is only valid during the extract phase.

comment:6 Changed 12 years ago by jmroot (Joshua Root)

Component: baseports
Milestone: MacPorts Future
Port: git-core added
Note: See TracTickets for help on using tickets.