On 2015-1-21 06:22 , Lawrence Velázquez wrote:
> On Jan 20, 2015, at 7:08 AM, René J.V. Bertin wrote:
>
>>> Single-dash single-letter flags like "-f" are "global" and have no effect
>>> unless placed after the word "port" and before the command verb (e.g. "sudo
>>> port -f uninstall"). Double-d
On Tuesday January 20 2015 15:38:17 Lawrence Velázquez wrote:
> > Eh? Activating a newly installed version always deactivates the old port,
> > if present, no?
>
> I don't know, off the top of my head. Maybe.
Well, in any case *installing* a new version (which is what I should have
written) de
On Jan 20, 2015, at 3:18 PM, René J.V. Bertin wrote:
> On Tuesday January 20 2015 14:34:30 Lawrence Velázquez wrote:
>
>> `port upgrade --force` is basically a `port install` that's interrupted
>> between the install and activate phases by the deactivation of the old port.
>
> Eh? Activating a
On Tuesday January 20 2015 15:27:56 Lawrence Velázquez wrote:
> I don't really understand where the state file comes into this. We are
> talking about rebuilding and reinstalling a port that is already installed.
Indeed, but in my workflow that usually means incremental rebuilds.
% # whatever
On Jan 20, 2015, at 3:15 PM, René J.V. Bertin wrote:
> On Tuesday January 20 2015 14:22:23 Lawrence Velázquez wrote:
>
>> And `port upgrade` preserves the variant selection of the
>> currently-installed port, while the other subcommands do not.
>
> Hmm, how? By looking at the registry or by lo
On Tuesday January 20 2015 14:29:10 Lawrence Velázquez wrote:
> We should not implement needlessly fine-grained persistent preferences for
> every possible behavior. I expect that very few users (besides you,
> apparently) would use this preference.
Fair enough, if I'm the only one with memory
Hi Ryan,
On 20 Jan 2015, at 10:08 , Marko Käning wrote:
> ok, I have contacted upstream…
the developer wants to come out with a 1.9.0 for Qt5 soonish, but searches at
the moment for more testers.
Interested?
>> Could the portgroups be enhanced to create this directory, in a pre-destroot
>> b
On Tuesday January 20 2015 14:34:30 Lawrence Velázquez wrote:
> `port upgrade --force` is basically a `port install` that's interrupted
> between the install and activate phases by the deactivation of the old port.
Eh? Activating a newly installed version always deactivates the old port, if
pre
On Tuesday January 20 2015 14:22:23 Lawrence Velázquez wrote:
> On Jan 20, 2015, at 7:08 AM, René J.V. Bertin wrote:
>
> > Does `upgrade` work like `install` would if you have just done a manual
> > destroot?
>
> `port destroot` does not actually install anything, so no.
Sorry, using "if" imp
On Jan 20, 2015, at 7:08 AM, René J.V. Bertin wrote:
> On Tuesday January 20 2015 00:08:42 Ryan Schmidt wrote:
>
>> "sudo port -n upgrade --force" is the invocation you're looking for.
>> "--force" forces the upgrade, even if MacPorts thinks the port is up to date
>> while "-n" prevents MacPor
On Jan 20, 2015, at 7:05 AM, René J.V. Bertin wrote:
> What's bad about asking for confirmation when that's an option the user has
> to activate in macports.conf? Heck, the request could even be skipped when
> doing `port upgrade` so that common workflows continue to flow without
> interventio
On Tuesday January 20 2015 12:25:32 Michael Dickens wrote:
> but that's ugly & cumbersome. There has got to be a better way. Any
> advice on a robust yet concise way to do this? Thanks! - MLD
Hi Michael,
I suppose you're not supporting any random swig version, so how about doing
what the python
On Jan 20, 2015, at 7:08 AM, René J.V. Bertin wrote:
> Does `upgrade` work like `install` would if you have just done a manual
> destroot?
`port destroot` does not actually install anything, so no. And `port upgrade`
preserves the variant selection of the currently-installed port, while the
o
On Jan 20, 2015, at 12:25 PM, Michael Dickens wrote:
> I've been working on getting a "swig-devel" port up and running, and it
> works locally for me. But in order to use it (e.g.,
> "swig-python-devel"), I need to specify dependencies using a wildcard
> because we don't know the SWIG version. Fo
I've been working on getting a "swig-devel" port up and running, and it
works locally for me. But in order to use it (e.g.,
"swig-python-devel"), I need to specify dependencies using a wildcard
because we don't know the SWIG version. For example, something like:
{{{
depends-build-append path:share/
On Tuesday January 20 2015 10:35:54 Daniel J. Luke wrote:
> it's generally considered rude to redirect private mail to a mailing list.
Different cultures, different considerations of what's rude.
It also didn't occur to you apparently that I may not have been able to test
things myself because
> On Jan 20, 2015, at 10:20 AM, René J.V. Bertin wrote:
> On Tuesday January 20 2015 10:13:53 Daniel J. Luke wrote:
>>> Question: what happens if you invoke ports when ${portdbpath} is offline?
>>> Does if fail gracefully?
>>
>> it would have taken less time to test that than it did to send the
On 20 Jan 2015, at 12:21, Mojca Miklavec wrote:
> A slight disadvantage of xz is that many users still don't know how to
> decompress such files, but this argument doesn't apply here since
> "port" would do everything automatically for the user.
I fully support Mojca’s proposal!
Vincent
__
(was: /opt/local/macports/software)
I'm switching to the developers mailing list – I believe the
discussion belongs there more than to the users' list.
On Tue, Jan 20, 2015 at 10:46 AM, Chris Jones wrote:
> On 20/01/15 02:37, Joshua Root wrote:
>> Daniel J. Luke wrote:
On Jan 19, 2015, at 6:
Hi Ryan,
On 20 Jan 2015, at 02:10 , Ryan Schmidt wrote:
> Commit aca5faf6 is a year and a half newer than version 1.8.0. You should not
> claim that it is version 1.8.0.
ok, I have contacted upstream...
> When subport is not equal to ${name}-qt5,
> -DBIN_INSTALL_DIR:PATH=${qt_apps_dir} is b
20 matches
Mail list logo
