Ticket #29707 (closed defect: fixed)
git-core 1.7.5.3 fails to install doc if build and destroot run as separate commands
| Reported by: | mta@… | Owned by: | macports-tickets@… |
|---|---|---|---|
| Priority: | Normal | Milestone: | |
| Component: | ports | Version: | 1.9.99 |
| Keywords: | Cc: | raimue@…, snc@… | |
| 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
Change History
Changed 2 years ago by mta@…
- Attachment extract.patch added
comment:1 Changed 2 years ago by mta@…
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 2 years ago by raimue@…
- Cc raimue@… added
- Port git-core deleted
- Milestone set to MacPorts Future
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 2 years ago by mta@…
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?


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