On Feb 25, 2015, at 9:49 PM, MacPorts wrote:
> #38091: alpine @2.00_4: update to 2.11
> ---+--
> Reporter: larryv@… | Owner: john@…
> Type: update| Status: closed
> Priority: Normal| Milestone:
> Component: ports |Ver
On Feb 25, 2015, at 2:38 PM, Artur Szostak wrote:
> The problem with downloading into destroot just like any other file is that
> one ends up with two copied of the data. That is fine for packages of a few
> MB. But for large number of demo data packages of a few GB each this surely
> is a bad
On Feb 25, 2015, at 8:56 AM, Artur Szostak wrote:
> OK, so as I suspected, activation performs the dependency check and triggers
> a deactivation of the older port.
> Not knowing much about the internals of MacPorts, my assumption would have
> been that all, pre-, , pos- groups happen atomicall
Hi,
If someone could apply the patches provided in these tickets I'd be
grateful:
https://trac.macports.org/ticket/46932
https://trac.macports.org/ticket/46933
Best
C
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosfo
> On Feb 25, 2015, at 9:56 AM, Artur Szostak wrote:
> Any better ideas are welcome.
why not just make the demo data a separate port?
--
Daniel J. Luke
++
On Wednesday February 25 2015 13:54:26 Artur Szostak wrote:
I had a very similar question recently, but about the deactivation of the
current version of a port being upgraded. That's the 1st thing that's done
after the new version's destroot, at least when you prepare the destroot
"manually" in
OK, so as I suspected, activation performs the dependency check and triggers a
deactivation of the older port.
Not knowing much about the internals of MacPorts, my assumption would have been
that all, pre-, , pos- groups happen atomically as a
transaction. But apparently that is not the way the
On Wed, Feb 25, 2015 at 8:54 AM, Artur Szostak wrote:
>
> Why does a pre-activate phase happen before a deactivation phase when
> upgrading from an older port revision to a newer one?
My assumption is that deactivating v1 is a requirement (dependency /
prerequisite) of activating v2, so it occu
Hi,
Why does a pre-activate phase happen before a deactivation phase when upgrading
from an older port revision to a newer one?
I would have expected the following order:
...
pre-deactivate v1
deactivate v1
post-deactivate v1
...
pre-activate v2
activate v2
post-activate v2
But
