Hi Ryan,
On 08 Oct 2016, at 10:04 , Ryan Schmidt wrote:
>> kmymoney4-devel: increase version suffix, as that seems to be needed for the
>> port to pick up the previously added patch file
>
> No, that's not the case.
When I committed that revbump I was already unsure whether I am mistaken. I s
On Tuesday October 11 2016 22:53:33 Marko Käning wrote:
Hi,
> Hi René,
>
> what can you respond here?
Well, the code is C++11 everywhere of course, it's the PortGroup that does
Darwin-specific things.
> Begin forwarded message:
>
> > From: Ryan Schmidt
> >> +platform darwin {
> >> +
On 2016-10-11 16:38, René J.V. Bertin wrote:
> This does work though:
>
> {{{
> proc macports::normalize { filename } {
> # normalise the user-specified prefix. The test file under $prefix need
> not exist for that:
> set nprefix [file dirname [file normalize "${macports::prefix}/foo"]]
>
On Tuesday October 11 2016 16:33:26 Rainer Müller wrote:
>I cannot reproduce these claims. 'port provides' works for symlinks as
>expected. Note that file normalize does not resolve symlinks in the last
>component.
Actually, it was a question, and yes, after verification the answer is "no"
becau
On Tuesday October 11 2016 16:04:21 René J.V. Bertin wrote:
>{{{
>proc macports::normalize { filename } {
>set nprefix [file dirname [file normalize "${macports::prefix}/foo"]]
>return [string map {${nprefix} ${macports::prefix}} [file normalize
> $filename]]
>}
>}}}
For some reason [str
On 2016-10-11 10:43, René J.V. Bertin wrote:
> To come back to action_provides: if the registry saves a port's
> "intended" paths (the ones stored in the software image tarball), why
> do a lookup of the actual/resolved path? That would make it
> impossible to check which port installs a symlink (t
On Oct 11, 2016, at 10:04 AM, René J.V. Bertin wrote:
> On Tuesday October 11 2016 09:21:09 Daniel J. Luke wrote:
>
>> one way to handle it could be:
>> +# don't normalize absolute paths
>
> See my previous message about why normalisation might be used here;
> completing a relative path
On Tuesday October 11 2016 09:21:09 Daniel J. Luke wrote:
>one way to handle it could be:
>+# don't normalize absolute paths
See my previous message about why normalisation might be used here; completing
a relative path is clearly another reason.
I wonder a bit why `port provides` suppo
On Tuesday October 11 2016 09:07:05 Daniel J. Luke wrote:
>https://lists.macosforge.org/pipermail/macports-dev/2014-May/026728.html
>which I linked to the last time you brought this up.
Funny (not so), I can't remember that at all...
I used to have a similar configuration, but have since gone bac
one way to handle it could be:
% svn diff
Index: port.tcl
===
--- port.tcl(revision 153771)
+++ port.tcl(working copy)
@@ -2389,7 +2389,12 @@
return 1
}
foreach filename $portlist {
-set file [file n
see also:
https://lists.macosforge.org/pipermail/macports-dev/2014-May/026728.html
which I linked to the last time you brought this up.
(no one replied to that original post).
I expect no regular base contributor cares enough about that unsupported
configuration to work on it - which means som
Hi,
I'd like to understand a bit better why the base layer does path normalisation
in a number of places where its use isn't immediately obvious to me, like for
instance the action_provides procedure in the port script. If that's not so
broad of a question that it cannot be answered with a sing
12 matches
Mail list logo
