Option to mark a port for installation when the port is fixed

[dylanryan]

This is a request for a feature that I think might be useful. First, some background.

Both when installing Lion, and more recently Mountain Lion, after finding a bunch of broken ports, I decided it would be easier to do a clean re-install (to clear out any old cruft that had accumulated). However, after both system upgrades, I (naturally) found several ports I wanted that would not install on the new system. I then had to keep track of what ports I still needed to install, and periodically check to see if they had been fixed yet.

Other times, ports have broken on me, and after wrestling with them a while, I tend to uninstall them and wait for them to get fixed, so that I can get that port with a clean install later. I know I could just deactivate them, but I prefer knowing I have a clean start, that it isn't some left over configuration file somewhere that is messing up the build.

Anyway, in both cases, I have to manually keep track of a list of ports (and variants) that I want to install later, and then watch for changes, and then go install them when the ports are updated.

What would be nice is if port could do this automatically. I am thinking something along the lines of

port watch someBrokenPort +someVariant

(where "watch" is just a placeholder name for the command, it could probably be renamed something better)

The idea is, this would tell MacPorts to record the current-at-the-time-that-is-executed version of that port in it's database somewhere (along with any variants that were specified), and then watch it. On subsequent self-updates, it would check the new version of that port, and if it is later, tell the user something like "The watched port someBrokenPort has been updated. To install, run port install someBrokenPort +someVariant". Then, when successfully installing any port, clear any watches on that port automatically. If any install fails, and the port is being watched, update the watched version to this version (so that this version doesn't get tried again). (this might get tricky if a watched port only fails because a dependency fails, so it might be best to make the watch command itself automatically watch any broken dependencies)

This way, after an OS update or whatever breaks some ports (lets face it, this is likely going to be a yearly issue just on the OS side, plus GCC updates sometimes break other ports, etc), users can just tell the system to watch ports for them (even though they are not currently installed), and it will alert them when a new version is ready to try. If the next install also fails, it will still be watched and the NEXT update will remind the user. Basically - if a port breaks on a system install, the user is probably thinking about it then, so knows what variants they want, etc, whereas on a subsequent self-update a week or 2 later, they might not be thinking as clearly (they might just remember "Oh, yeah, I wanted to install somePort" but they might not remember what variants off hand). So, by letting the user specify things like variants when they watch it, port can remind them of that, as well. It reduces the user's book keeping needs.

( There would also have to be a port unwatch command to manually remove from the list, of course. And maybe options to the watch command to automatically try and install when the port is updated )

[ryandesign (Ryan Carsten Schmidt)]

Note that watching for the version (and/or revision and/or epoch) to change is not necessarily useful, because someone fixing the port won't necessarily increase the revision; often there is no reason to do so. Sure, if the problem is upsteam and a new version is released to fix the problem, then that would help, but it could just as easily be an error in the portfile that is unique to MacPorts and could be fixed without changing the version. So instead of checking a particular epoch+version+revision, the best we could probably do would be to just notice when a portfile is changed at all (by recording a checksum of the portfile, just like we already do to decide whether to resume a build or clean and start over). Even that wouldn't catch all fixes, for example if the problem is due to a bad or missing patchfile and all that's needed to fix the problem is to change or add the patchfile.

[dylanryan]

Replying to ryandesign@…

What does "outdated" measure/react to (as in port outdated)? I don't think I ever have had a broken port that got fixed without showing up in port outdated, though I could be wrong (especially since I usually uninstall after a while). Because that is basically what I would like - something akin to "port outdated" that works with ports that are NOT installed, (primarily due to being broken). Though the portfile checksum idea sounds like a good idea, and even if it just caught most of the scenarios, that is better than having to save a text file manually somewhere to remind myself what ports I need after a new OS install. There's no facility already in place to get a checksum of all the files that are in the port (i.e. portfile + patches + whatever else there is)?

A less useful but still helpful option would just be a "wishlist" type thing, so that at least instead of writing it down in a text file that I have to not lose, I can just tell port that, sometime, I want to install some given port (and automatically clear the wishlist when it does get installed). That isn't as useful as trying to notice when a port might be fixed, but at least it keeps everything together. I could just type "port wishlist" to see what things I want, rather than having to write it down somewhere. Though I guess that isn't significantly more convenient than using a text file....

[ryandesign (Ryan Carsten Schmidt)]

"port outdated" looks at the epoch+version+revision. And yes, absolutely, ports do get fixed all the time without the epoch, version or revision getting increased. The revision is only increased if the change would alter the files that a port installs.

Another problem with this suggestion is that what you're asking for is a way to be notified when a port is fixed, but we already have a mechanism in place for that: this issue tracker. If a port is broken, you need to file a ticket in this issue tracker (or verify that one has already been filed) so that we are made aware of the problem and someone can begin working on it. You will receive email notification when the ticket is resolved, or if further information is required of you in order to resolve it.