Re: Updating macports.conf
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. ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: Updating macports.conf
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 ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: Updating macports.conf
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 ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: Updating macports.conf
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 ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: Updating macports.conf
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 ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: Updating macports.conf
>> 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 ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
