Keeping local modifications
Hey, I'm keeping some local modifications to some portfiles to keep them working with a bunch of local modifications to the system. In order to do this, I copy the ports I modify to a local dports dir and make the changes there so they won't be lost when I do a selfupdate. Is there some way that I can make my locally modified ports totally replace the official ones? Just adding a Revision tag makes them impossible to distinguish in the list and I also see both versions. Is anyone else doing this and how do you usually do it? -- kent
On 2006-10-22 13:33:46 -0700, Kent Karlsson wrote:
I'm keeping some local modifications to some portfiles to keep them working with a bunch of local modifications to the system. In order to do this, I copy the ports I modify to a local dports dir and make the changes there so they won't be lost when I do a selfupdate.
I do that too.
Is there some way that I can make my locally modified ports totally replace the official ones? Just adding a Revision tag makes them impossible to distinguish in the list and I also see both versions.
I don't understand. They have the precedence over the official ones (as given in the $prefix/etc/ports/sources.conf file). The official port still appears in "port list", but this isn't much a problem. -- Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/> Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
Vincent Lefevre wrote:
On 2006-10-22 13:33:46 -0700, Kent Karlsson wrote:
I'm keeping some local modifications to some portfiles to keep them working with a bunch of local modifications to the system. In order to do this, I copy the ports I modify to a local dports dir and make the changes there so they won't be lost when I do a selfupdate.
I do that too.
Is there some way that I can make my locally modified ports totally replace the official ones? Just adding a Revision tag makes them impossible to distinguish in the list and I also see both versions.
I don't understand. They have the precedence over the official ones (as given in the $prefix/etc/ports/sources.conf file). The official port still appears in "port list", but this isn't much a problem.
This partly goes to the discussion I raised about default revisions of 1: http://lists.macosforge.org/pipermail/macports-dev/2006-October/000095.html But it would be nice for the precedence be done by (version, revision) tuple and not by location of the Portfile, so you can have local modifications be outdated when a new official port comes out. Regards, Blair
On Oct 23, 2006, at 12:44 PM, Blair Zajac wrote:
This partly goes to the discussion I raised about default revisions of 1:
http://lists.macosforge.org/pipermail/macports-dev/2006-October/ 000095.html
But it would be nice for the precedence be done by (version, revision) tuple and not by location of the Portfile, so you can have local modifications be outdated when a new official port comes out.
Except that the new 'official' port (probably) won't have whatever local changes in it that were important enough for you to set up a local port. -- Daniel J. Luke +========================================================+ | *---------------- dluke@geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+
Daniel J. Luke wrote:
On Oct 23, 2006, at 12:44 PM, Blair Zajac wrote:
This partly goes to the discussion I raised about default revisions of 1:
http://lists.macosforge.org/pipermail/macports-dev/2006-October/000095.html
But it would be nice for the precedence be done by (version, revision) tuple and not by location of the Portfile, so you can have local modifications be outdated when a new official port comes out.
Except that the new 'official' port (probably) won't have whatever local changes in it that were important enough for you to set up a local port.
Not true. What I commonly do is build the local port, say for the new Python 2.4.4 that just came out, tweak the port and any patches to get it working, then submit the patch into Trac. Then hopefully, my local port becomes the official port. It's very rare that I have any local changes in my ports that I wouldn't want to see or would be inappropriate for all MacPorts users. Regards, Blair
On Oct 23, 2006, at 5:48 PM, Blair Zajac wrote:
Except that the new 'official' port (probably) won't have whatever local changes in it that were important enough for you to set up a local port.
Not true. What I commonly do is build the local port, say for the new Python 2.4.4 that just came out, tweak the port and any patches to get it working, then submit the patch into Trac. Then hopefully, my local port becomes the official port.
It's very rare that I have any local changes in my ports that I wouldn't want to see or would be inappropriate for all MacPorts users.
Then it seems to me that a local repository is not what you want. The way I do it is to point macports to a svn (or svk) checkout. I don't get 'port sync' anymore, but I do get easy access to revision control (and port sync could probably be patched to do 'svn up' if you really wanted it to). -- Daniel J. Luke +========================================================+ | *---------------- dluke@geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+
On 2006-10-23 14:48:11 -0700, Blair Zajac wrote:
It's very rare that I have any local changes in my ports that I wouldn't want to see or would be inappropriate for all MacPorts users.
But sometimes, a new version may be more buggy than an old one (possibly with local modifications). So, it may be useful to have a location that has the precedence over the (version, revision). However, what would be fine, is to have both. For instance, each URL of the sources.conf file could be tagged by a rank (default: 0), and the highest (-rank, version, revision) should have the precedence. -- Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/> Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
I work in an unindexed ports tree to maintain my ports. If a portfile is in the current working directory, the port command can act on that port as if it were any other port by using the port command without naming the port to be installed/uninstalled etc. The only command that does not work in this fashion is "upgrade," however, the command "port upgrade x" is functionally equivalent to "port deactivate x ; port install x" On 23 Oct 2006, at 21:04, Vincent Lefevre wrote:
On 2006-10-23 14:48:11 -0700, Blair Zajac wrote:
It's very rare that I have any local changes in my ports that I wouldn't want to see or would be inappropriate for all MacPorts users.
But sometimes, a new version may be more buggy than an old one (possibly with local modifications). So, it may be useful to have a location that has the precedence over the (version, revision).
However, what would be fine, is to have both. For instance, each URL of the sources.conf file could be tagged by a rank (default: 0), and the highest (-rank, version, revision) should have the precedence.
-- Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/ blog/> Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS- Lyon) _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
Randall Wood rhwood@mac.com "The rules are simple: The ball is round. The game lasts 90 minutes. All the rest is just philosophy."
participants (5)
-
Blair Zajac
-
Daniel J. Luke
-
Kent Karlsson
-
Randall Wood
-
Vincent Lefevre