Updating macports.conf
Hello, Currently on selfupdate macports.conf is not updated in any way if it already existed. This "hides" new options from long time users. An up-to-date macports.conf provides a good overview over all options and contains short documentation lines. I have two proposals how this could be changed to make it more easy for users to follow HOWTOs and/or tutorials. 1) Add macports.conf.dist Place a file named macports.conf.dist right beside macports.conf. It would be the same file as the install process would have generated if no macports.conf file exists. Then the user can copy & paste new options over to macports.conf. Advantages: * Easy to implement Disadvantages: * User still has to do it him/herself. 2) Parse macports.conf and regenerate it Parse the existing macports.conf and rewrite it completely. This takes takes all options already present and writes a new macports.conf (by also keeping a backup). Advantages: * macports.conf is always up-to-date * Does not require work by user Disadvantages: * More work to implement this. * Users will loose their formatting or comments, if they customized it. Any comments on this appreciated. Rainer
Hi Rainer, On Feb 15, 2008, at 6:01 PM, Rainer Müller wrote:
Currently on selfupdate macports.conf is not updated in any way if it already existed. This "hides" new options from long time users. An up-to-date macports.conf provides a good overview over all options and contains short documentation lines.
How about make the default behavior of selfupdate to move the old macports.conf and replace it if it has NOT been modified since the last time? -- Ernie P.
On Feb 15, 2008, at 6:01 PM, Rainer Müller wrote:
Currently on selfupdate macports.conf is not updated in any way if it already existed. This "hides" new options from long time users.
Yep. Very common problem with configuration files!
An up-to-date macports.conf provides a good overview over all options and contains short documentation lines. [ ... ] 1) Add macports.conf.dist
Yes, at a minimum, you need an updated reference config file available at all times, though I dislike the .dist approach. If it's just a passive reference, then you need to either write a merge utility (like FreeBSD's "mergemaster") or dump the entire problem of merging in the user's lap, neither solution bringing much happiness. A better approach is FreeBSD's /etc/defaults - a set of shadow files you keep up to date, making the primary configuration file an override. You can still get stale data lingering in the user configuration file, keeping an option on or off when the default has changed, but sometimes that's a feature. This is, in any case, how I'd handle this one. Always install a macports.conf.default and add some logic to load the two in order (macports.conf should, in fact, be optional). - Jordan
Place a file named macports.conf.dist right beside macports.conf. It would be the same file as the install process would have generated if no macports.conf file exists. Then the user can copy & paste new options over to macports.conf.
Advantages: * Easy to implement Disadvantages: * User still has to do it him/herself.
2) Parse macports.conf and regenerate it Parse the existing macports.conf and rewrite it completely. This takes takes all options already present and writes a new macports.conf (by also keeping a backup).
Advantages: * macports.conf is always up-to-date * Does not require work by user Disadvantages: * More work to implement this. * Users will loose their formatting or comments, if they customized it.
Any comments on this appreciated.
Rainer _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
On Feb 15, 2008, at 22:26, Jordan K. Hubbard wrote:
On Feb 15, 2008, at 6:01 PM, Rainer Müller wrote:
Currently on selfupdate macports.conf is not updated in any way if it already existed. This "hides" new options from long time users.
Yep. Very common problem with configuration files!
An up-to-date macports.conf provides a good overview over all options and contains short documentation lines. [ ... ] 1) Add macports.conf.dist
Yes, at a minimum, you need an updated reference config file available at all times, though I dislike the .dist approach. If it's just a passive reference, then you need to either write a merge utility (like FreeBSD's "mergemaster") or dump the entire problem of merging in the user's lap, neither solution bringing much happiness. A better approach is FreeBSD's /etc/defaults - a set of shadow files you keep up to date, making the primary configuration file an override. You can still get stale data lingering in the user configuration file, keeping an option on or off when the default has changed, but sometimes that's a feature.
This is, in any case, how I'd handle this one. Always install a macports.conf.default and add some logic to load the two in order (macports.conf should, in fact, be optional).
Great, and after we solve this, we'll do the same for all the software one could install using MacPorts, right? :-D
On Feb 15, 2008, at 8:39 PM, Ryan Schmidt wrote:
This is, in any case, how I'd handle this one. Always install a macports.conf.default and add some logic to load the two in order (macports.conf should, in fact, be optional).
Great, and after we solve this, we'll do the same for all the software one could install using MacPorts, right? :-D
Sure, absolutely, we'll get right on that. Let's start with just one configuration file though, shall we? :-) - Jordan
Jordan K. Hubbard wrote:
An up-to-date macports.conf provides a good overview over all options and contains short documentation lines. [ ... ] 1) Add macports.conf.dist
Yes, at a minimum, you need an updated reference config file available at all times, though I dislike the .dist approach. If it's just a passive reference, then you need to either write a merge utility (like FreeBSD's "mergemaster") or dump the entire problem of merging in the user's lap, neither solution bringing much happiness.
Ok, the file would not necessarily be called like this. It could also go into share/doc/macports or anywhere else. And yes, the merging is the big disadvantage of this approach.
A better approach is FreeBSD's /etc/defaults - a set of shadow files you keep up to date, making the primary configuration file an override. You can still get stale data lingering in the user configuration file, keeping an option on or off when the default has changed, but sometimes that's a feature.
This is, in any case, how I'd handle this one. Always install a macports.conf.default and add some logic to load the two in order (macports.conf should, in fact, be optional).
This sounds like a good solution. Although it does not make the documentation lines visible to the user. Rainer
This is, in any case, how I'd handle this one. Always install a macports.conf.default and add some logic to load the two in order (macports.conf should, in fact, be optional).
Great, and after we solve this, we'll do the same for all the software one could install using MacPorts, right? :-D
Sure, why not - other package systems do it already... ? http://trac.macports.org/projects/macports/ticket/12797 http://trac.macports.org/projects/macports/ticket/2365 --anders
participants (5)
-
Anders F Björklund
-
Ernest Prabhakar
-
Jordan K. Hubbard
-
Rainer Müller
-
Ryan Schmidt