howarth at bromo.med.uc.edu
Fri Jan 21 17:32:37 PST 2011
On Fri, Jan 21, 2011 at 05:25:46PM -0800, Bradley Giesbrecht wrote:
> On Jan 21, 2011, at 5:09 PM, Jeremy Lavergne wrote:
>>> Well it is there at...
>>> however that note should be enhanced to make the second point that
>>> retention of local portfiles will
>>> block the proper updating from the rsync.
>> What is the intended behavior? Some may want their local ports of
>> identical version/revision to be the ones used--replacing available
>> ports, whereas others just expect their local ports to be included
>> along with the rsync ones--expanding the available list of ports.
>> Since it's usually just devs working at that level, it was assumed (I
>> assume) that the local files being worked on should be used. This
>> means, rather than assuming that local revision X is newer than the
>> ever-changing rsync version, it will always be used regardless of
>> versioning. This is because it would otherwise be possible while in
>> the middle of working on their portfile, the revisions may have
>> changed in rsync. The rsync files would then take precedence and stop
>> showing the local changes--without warning!
> Putting your local repository ahead of rsync in sources.conf provides a
> valuable method of preventing software from being upgraded.
That would be a valuable method if MacPorts had the version dependency
checking at the package level to prevent breakage like I witnessed with
pymol vs libpng. Currently it is more of a high risk strategy as it leaves
you open to soversion mismatches.
> To me, this is a well document "in sources.conf" feature.
> macports-dev mailing list
> macports-dev at lists.macosforge.org
More information about the macports-dev