Jeremy Lavergne wrote: > For "port list" specifically, I would expect a listing of package > names and package versions with an indication that it's out of date > --- much like port outdated. I suggest we then throw in an additional > third column indicating the status of that specific version. Here's > an example:
So you only want to see installed packages, right? > xorg-xproto 7.0.14_1 < 7.0.15_0 (active) > xorg-xproto 7.0.14_0 < 7.0.15_0 (inactive) This is basically 'port outdated'. What would be the use of this if it is so similar? The duplicated ports and active/inactive status could be shown with an additional flag for 'port outdated' if you think this is useful. 'port installed' already lists active/inactive status. > [...] > As for what's confusing, I feel we have too many commands available > that overlap on naming. No commands overlap on naming. You have to differentiate between commands and pseudo-ports, which are much more powerful. Some commands have the same name as a pseudo-port, which is probably what you mean. But I don't think we can do anything against this. > [...] I think it would be a good idea to either > consolidate or rename these functions. Since I'm talking about > mimicking other port systems (for better or worse) I would expect > "list" to provide the basic listings we provide from other functions > as submethods: > list all > list available > list updates > list installed > list extras > list obsoletes > list recent list all is the same as list available, pseudo-port 'all' exists for all commands already. list updates sounds like our existing outdated command. list installed is covered by the installed command and the pseudo-port 'installed'. list obsoletes was added to trunk by me as a pseudo-port, 'obsolete' list extras and list recent, I have no idea what is meant by those. If this is all under the list command, I would expect the same consistent output for all of them. But for installed I would like to see the version which is installed, for outdated I would like to see the new and old version. I don't like sub-commands of commands. 'port <cmd> [--options] [args]' is enough already. > I would expect the searching ability to included on all these (e.g., > list updates foo*). This is already possible for existing commands which accept lists of ports. Additionally, the use of pseudo-ports is possible, which can also be combined using logical operators. These allows to make complicated queries which is unique to MacPorts as far as I know. As we have such a feature I also don't think we can simply adopt commands from other systems, these just wouldn't fit. Note that the command echo exists to test such expansions: port echo depends:expat and 'a*' Gives you a list of all ports that depend on expat and start with the character 'a'. If you are concerned that new users who are already familiar with different packagement systems have a hard time to get used to 'port', we could create a wiki section which lists equivalent commands for other systems. Rainer _______________________________________________ macports-dev mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
