On Monday April 04 2016 07:34:32 Clemens Lang wrote:
>What kind of information are we talking about here? Compiler flags?
>Paths?
Typically paths defined through variables indeed, or configure settings, plus
the occasional pre- or post- block. And dependency info, of course (e.g.
declaring a de
On 2016-04-04 10:42, René J.V. Bertin wrote:
> On Monday April 04 2016 07:34:32 Clemens Lang wrote:
>> That would potentially cause ports to build different depending on
>> which packages you have installed in your environment, which is
>> not reproducible.
>
> Yes, but that is already the case wh
Dear Ryan and Mojca,
OK. So I see that this is not the problem of the port.
I don’t have a solution at this time,
but I hope that the manually specified variants
and default_variants should be treated equally
in the future.
Regards,
Takeshi
-
Takeshi Enomoto
take...@macports.org
__
On Monday April 04 2016 16:22:27 Rainer Müller wrote:
>A user already installed port A with the official port group foo-1.0.
>Then they add a new source, overriding the port group foo-1.0, which
>redefines some paths. This will not cause A to be outdated and no
>rebuild of A will be triggered. Now
On 2016-04-04 17:13, René J.V. Bertin wrote:
> On Monday April 04 2016 16:22:27 Rainer Müller wrote:
> This should *not* be the case if the current lookup rules for
> _resources continue to be applied, but a higher priority central
> location (var/macports/sources/PortGroups) is added where copies
> On Apr 3, 2016, at 2:31 AM, René J.V. Bertin wrote:
>
> Hi,
>
> I just went through a bit of a hairy exercise. With a bit too much
> distraction and hurry going on I did a `port upgrade --force` of a port I'd
> just rebuilt from source so I forgot both the -s and the (crucial) -n
> options.
On Monday April 04 2016 17:59:11 Rainer Müller wrote:
> As Clemens said, PortGroups need to be available to parse a port. They
> cannot be installed with a port. You would have to keep one version in
> the ports tree and then another one that is installed by a port. That
Yes, that's what I am now
Bradley Giesbrecht wrote:
> Did you keep a copy of the registry? If so, try opening it with the sqlite
> client.
Thanks for the suggestion. Curiously that went just fine, but it also seems to
contradict the previous claim that any interaction with an sqlite3 db modifies
it. I did a .dump which
> On Apr 4, 2016, at 9:42 AM, René J. V. Bertin wrote:
>
> Bradley Giesbrecht wrote:
>
>> Did you keep a copy of the registry? If so, try opening it with the sqlite
>> client.
>
> Thanks for the suggestion. Curiously that went just fine, but it also seems
> to
> contradict the previous claim
Hi,
On Mon, Apr 04, 2016 at 10:42:16AM +0200, René J.V. Bertin wrote:
> Typically paths defined through variables indeed, or configure
> settings,
Paths and flags should be part of configuration files installed by a
port, e.g. CMake config files or pkg-config files.
> plus the occasional pre- or
On Mon, Apr 04, 2016 at 06:42:24PM +0200, René J. V. Bertin wrote:
> Thanks for the suggestion. Curiously that went just fine, but it also
> seems to contradict the previous claim that any interaction with an
> sqlite3 db modifies it.
No, any writing interaction modifies it (that should be obvious
> On Apr 4, 2016, at 9:45 AM, Bradley Giesbrecht wrote:
>
>> On Apr 4, 2016, at 9:42 AM, René J. V. Bertin wrote:
>>
>> Bradley Giesbrecht wrote:
>>
>>> Did you keep a copy of the registry? If so, try opening it with the sqlite
>>> client.
>>
>> Thanks for the suggestion. Curiously that went
On Monday April 04 2016 18:52:08 Clemens Lang wrote:
>However, now I'm interested why the backup worked flawlessly, but
>MacPorts failed to open the registry. Maybe there was something wrong
>with one of the indexes in the database (which wouldn't be used when
>doing a full dump or backup, but are
On Monday April 04 2016 18:47:03 Clemens Lang wrote:
Hi,
>Paths and flags should be part of configuration files installed by a
>port, e.g. CMake config files or pkg-config files.
They aren't always ... esp. not if those very files were hidden away by the
port. The paths can also be to executabl
I'd like to second that. I think many issues of variant dependencies are
helped by passing down both manually specified and default variants.
David
On Mon, Apr 4, 2016 at 10:44 AM, Takeshi Enomoto
wrote:
> Dear Ryan and Mojca,
>
> OK. So I see that this is not the problem of the port.
> I don’t
Hi,
On Mon, Apr 04, 2016 at 07:04:46PM +0200, René J.V. Bertin wrote:
> How would one check that (without putting my whole install at risk)?
http://serverfault.com/questions/8048/how-can-i-verify-that-a-sqlite-db3-file-is-valid-consistent
See also
https://trac.macports.org/browser/trunk/base/src
Hi,
On Mon, Apr 04, 2016 at 08:17:55PM +0200, René J.V. Bertin wrote:
> > > There's only one way to enforce the reproducible build principle
> > > all the way, and that's to remove the whole possibility of
> > > building from source so that users can only install official,
> > > binary packages.
I think the OCC part should probably stay a variant because OCC is
relatively heavy, and won't be necessary for a lot of netgen users, but
making nglib as part of the normal install seems reasonable to me. -Ian-
On 5/04/2016 10:04 am, "MacPorts" wrote:
> #50687: netgen @5.3.1 Add nglib and occ v
18 matches
Mail list logo
