same time, we should change MacPorts' behavior to be
consistent. I think the method from port(1) is better than the one
from macports.tcl, since it's the only one in which we can guarantee
upgrades correctly--even if it does force an extra line of cruft to
hang around in Portfiles with epochs
poch cannot
>be removed; this is the only case in which we can currently guarantee
>consistent behavior.
>
>At the same time, we should change MacPorts' behavior to be
>consistent. I think the method from port(1) is better than the one
>from macports.tcl, since it's the
rom macports.tcl, since it's the only one in which we can guarantee
upgrades correctly--even if it does force an extra line of cruft to
hang around in Portfiles with epochs (all 20 of 'em!)
Chris
___
macports-dev mailing list
macpor
>On Jan 11, 2008, at 16:51, [EMAIL PROTECTED] wrote:
>
>> - If an epoch is used it must must never be
>> decreased or reset
>> - to zero, because this would always cause a port version
>> comparison
>> - to be incorrect after a port upgrade.
>> + An epoch is not needed for most ports. If an epoch
>
On Thu, December 13, 2007 6:03 pm, [EMAIL PROTECTED] wrote:
> I was refining the guide part about epochs, and after gleaning information
> from the FreeBSD ports collection documentation I followed their lead and
> wrote the final part below for our guide. But do we consider th
I was refining the guide part about epochs, and after gleaning information
from the FreeBSD ports collection documentation I followed their lead and
wrote the final part below for our guide. But do we consider this a good
practice? Or is it only a FreeBSD thing?
"An epoch is not neede
