#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)
Change History (7)
Changed 13 years ago by mtalexander (Mike Alexander)
Attachment: | extract.patch added |
---|
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:5 Changed 12 years ago by raimue (Rainer Müller)
Resolution: | → fixed |
---|---|
Status: | new → closed |
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: | base → ports |
---|---|
Milestone: | MacPorts Future |
Port: | git-core added |
Patch to set all the extract.? variables whenever use_? is specified in a port file