Hi, Andres Loeh wrote:
> Probably, renaming to python3 is the most pragmatic option available. > > But in general, I think this is due to the actually rather > short-sighted assumption that upgrades are desired from a package > pkg-m to a package pkg-n if an only if m<n. > > This is, in general, not true. The python situation is a case where > installing python-3 over python-2 automatically is almost never > desired. However, there are other situations where the assumption is > incorrect as well, the most frequent being renames of packages, but > also random changes in the version numbering scheme. In such cases, we > might suddenly want to upgrade from pkg-17.3 to gkp-4.5. This is possible by marking the higher version as low priority (lowPrio), which should cover most use cases. The "priority" meta-attribute here plays a role similar to the "epoch" in RPM packages. > It would be absolutely amazing if the Nix expression language would > just let us specify how the directed set of version upgrades should > look like. Add a "meta.versionComparator" attribute specifying a comparison function? :-) > I.e., we'd need a way to specify that a package constitutes > an upgrade for another even if the names are unrelated. I've been wanting to add a meta-attribute to support package renames for a long time. E.g. to rename the current "MPlayer" package to "mplayer", we'd change the name attribute to "mplayer-<version>", and add a meta attribute like this: meta.upgrades = [ "MPlayer" ]; -- Eelco Dolstra | http://www.st.ewi.tudelft.nl/~dolstra/ _______________________________________________ nix-dev mailing list [email protected] https://mail.cs.uu.nl/mailman/listinfo/nix-dev
