Re: Darwin Version

[Bachsau]

> Am 02.10.2015 um 16:33 schrieb Ryan Schmidt :
> 
> We're trying to make MacPorts into a system that just works, and that means 
> that when we discover common situations where MacPorts fails to work, we try 
> to modify MacPorts so that users are less likely to encounter them. One of 
> the common problems we discovered was when MacPorts is built on one version 
> of OS X and used on another version of OS X. So now we prevent that, via the 
> error message that caused you to begin this thread.

I just want to share my experience with updating MacPorts today. The migration 
page describes that one should install the new base by the using the PKGs and 
AFTER that get list of all installed ports to reinstall them. That led me to 
the conclusion, that updating the base would not result in the package database 
being wiped. So I did just that and ran "port upgrade outdated" afterwards, 
which completed successfully. After all the discussion on this thread I 
understand why the migration steps are described as they are and what problems 
might arise from upgrading that way. However, for me and for this particular 
update, it worked very well. It still rebuild most of the packages though.

smime.p7s
Description: S/MIME cryptographic signature
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Darwin Version

[Rainer Müller]

On 2015-10-04 12:25, William H. Magill wrote:
> As with the “success” above, the answer appears to be with the
> Migration Instructions. The problem is that the visual queues given
> by the “command indent and boxing” are much more emphatic than the
> numbered items. i.e. the Eye overrides RTFM.

Thank you for your input. I tried to improve the Migration wiki page.

Please check again:
http://trac.macports.org/wiki/Migration

> Step one needs to be — download and install the version of MacPorts
> appropriate to the new release found at the top of  the QuickStart
> page, NOT “port -qv”!
> 
> Or put another way, the instructions on the QuickStart page and the
> Migration page need to be better integrated. Step 2 in the Migration
> Procedure is the key.
> 
> Maybe wording like:
> 
> "Reinstall MacPorts base. After updating the development tools,
> install the base MacPorts system  for your new platform, either from
> the appropriate installer (download it from the QuickStart section)
> or from source.”

Users going to the Migration page should already be familiar with
MacPorts itself as they used it on the previous release of OS X.
I don't think they need the QuickStart anymore.

> Similarly, the numbering of the Migration Guide is somewhat
> confusing.
> 
> 2.a should probably be moved to 3.a and the rest of 3 renumbered
> accordingly.

I don't understand that. 2a was the macports.conf update, which is
closer to updating MacPorts base than reinstalling ports. I left this at
step 2.

Rainer
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Darwin Version

[William H. Magill]

> On Oct 9, 2015, at 7:31 AM, Rainer Müller  wrote:
> 
> On 2015-10-04 12:25, William H. Magill wrote:
>> As with the “success” above, the answer appears to be with the
>> Migration Instructions. The problem is that the visual queues given
>> by the “command indent and boxing” are much more emphatic than the
>> numbered items. i.e. the Eye overrides RTFM.
> 
> Thank you for your input. I tried to improve the Migration wiki page.
> 
> Please check again:
> http://trac.macports.org/wiki/Migration

I think that visually, the page is cleaner now. 
Changing the indenting makes a big difference.

>> Step one needs to be — download and install the version of MacPorts
>> appropriate to the new release found at the top of  the QuickStart
>> page, NOT “port -qv”!
>> 
>> Or put another way, the instructions on the QuickStart page and the
>> Migration page need to be better integrated. Step 2 in the Migration
>> Procedure is the key.
>> 
>> Maybe wording like:
>> 
>> "Reinstall MacPorts base. After updating the development tools,
>> install the base MacPorts system  for your new platform, either from
>> the appropriate installer (download it from the QuickStart section)
>> or from source.”
> 
> Users going to the Migration page should already be familiar with
> MacPorts itself as they used it on the previous release of OS X.
> I don't think they need the QuickStart anymore.

This is one of those yes and no answers.  Example.
I have not needed to visit the MacPorts WIKI since the migration to
Yosemite — I forgot. The link simply did not jump out at me.

> Similarly, the numbering of the Migration Guide is somewhat
>> confusing.
>> 
>> 2.a should probably be moved to 3.a and the rest of 3 renumbered
>> accordingly.
> 
> I don't understand that. 2a was the macports.conf update, which is
> closer to updating MacPorts base than reinstalling ports. I left this at
> step 2.

I was just trying to adjust the numbering scheme, but your solution is
cleaner.

> Rainer

T.T.F.N.
William H. Magill
# iMac11,3 Core i7 [2.93GHz - 8 GB 1067MHz] OS X 10.11
# Macmini6,1 Intel Core i5 [2.5 Ghz - 4GB 1600MHz] OS X 10.11

mag...@icloud.com
mag...@mac.com
whmag...@gmail.com








___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Darwin Version

[Richard L. Hamilton]

Unix was originally a name for an operating system, and unofficially for a code 
lineage of variants derived from it.

It is now a trademark that can be granted to any OS meeting the current Single 
Unix Specification testing, and where the OS owner has paid for permission to 
use the trademark.

https://en.wikipedia.org/wiki/Single_UNIX_Specification 


According to that, no Linux implementation has been formally put through the 
tests.  (presumably possible if the $$ were spent, although possibly not 
without some changes)

At least one of the OS's listed (z/OS) as qualified for the Unix trademark, is 
something else entirely in origin, but has had compatibility features added to 
achieve compliance, although MVS (predecessor of z/OS) lineage mainframe 
software that is not remotely written for a Unix OS still exists and can still 
be developed too.

Perhaps more commonly, mainframes running the virtualization host OS z/VM can 
host many Linux guest VMs.

> On Oct 6, 2015, at 05:16, Bachsau  wrote:
> 
> Dominik Reichardt wrote on 06.10.2015 11:10:
>> While it is off topic, why the need to be so rude?
> 
> I'm not rude, just asking. :)
> There is always many discussion about what is a real UNIX, if something was 
> derived or rewritten, if Linux is UNIX and so on... I just don't get what's 
> the reason for these discussions? Just out of personal interest or because 
> people think some systems are "better" than others because of history? For 
> me, it doesn't really matter. There are System which conform to the POSIX 
> standards and those that don't. Some of them being free software, others are 
> not. And I think that are the only important differences.
> ___
> macports-users mailing list
> macports-users@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-users
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Darwin Version

[Dave Horsfall]

On Mon, 5 Oct 2015, Brandon Allbery wrote:

> It was never derived from FreeBSD 4.1.

I may have been thinking of this:

https://en.wikipedia.org/wiki/Berkeley_Software_Distribution

"Also Darwin, the system on which Apple's Mac OS X is built, is a 
derivative of 4.4BSD-Lite2 and FreeBSD."

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Darwin Version

[Bachsau]

Dave Horsfall wrote on 06.10.2015 09:53:

Anyway, "from scratch" => "clean-room implementation" e.g. Unix/Linux,
whereas "evolved" => V5/V6/V7/4.nBSD/BSDI/FreeBSD/OpenBSD/etc.


Is this discussion of any importance? I don't see why.
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Darwin Version

[Dave Horsfall]

On Mon, 5 Oct 2015, Daniel J. Luke wrote:

> > You're saying that Darwin was written from scratch and not evolved 
> > from a modified FreeBSD 4.1, or am I thinking of an earlier MacOS?
> 
> it all depends on what you mean by ‘written from scratch’, ‘evolved 
> from’, and how detailed you care to be with the history.

See next reply.

Anyway, "from scratch" => "clean-room implementation" e.g. Unix/Linux, 
whereas "evolved" => V5/V6/V7/4.nBSD/BSDI/FreeBSD/OpenBSD/etc.

As for how detailed, I doubt we'll ever know the full story, as many 
versions of Unix were developed over the 40 years that I've been using it 
(SYS-III, SYS-V, SunOS, Solaris, Ultrix, IRIX, Xenix, SCO, AIX, etc; I've 
used all those and more).

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Darwin Version

[Bachsau]

Dominik Reichardt wrote on 06.10.2015 11:10:

While it is off topic, why the need to be so rude?


I'm not rude, just asking. :)
There is always many discussion about what is a real UNIX, if something 
was derived or rewritten, if Linux is UNIX and so on... I just don't get 
what's the reason for these discussions? Just out of personal interest 
or because people think some systems are "better" than others because of 
history? For me, it doesn't really matter. There are System which 
conform to the POSIX standards and those that don't. Some of them being 
free software, others are not. And I think that are the only important 
differences.

___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Darwin Version

[Ryan Schmidt]

On Oct 6, 2015, at 10:41 AM, Richard L. Hamilton wrote:

> Unix was originally a name for an operating system, and unofficially for a 
> code lineage of variants derived from it.
> 
> It is now a trademark that can be granted to any OS meeting the current 
> Single Unix Specification testing, and where the OS owner has paid for 
> permission to use the trademark.
> 
> https://en.wikipedia.org/wiki/Single_UNIX_Specification
> 
> According to that, no Linux implementation has been formally put through the 
> tests.  (presumably possible if the $$ were spent, although possibly not 
> without some changes)
> 
> At least one of the OS's listed (z/OS) as qualified for the Unix trademark, 
> is something else entirely in origin, but has had compatibility features 
> added to achieve compliance, although MVS (predecessor of z/OS) lineage 
> mainframe software that is not remotely written for a Unix OS still exists 
> and can still be developed too.
> 
> Perhaps more commonly, mainframes running the virtualization host OS z/VM can 
> host many Linux guest VMs.

Let's let this thread end now. We have explained to the original poster to the 
best of our ability why he encountered the problem he encountered and why 
MacPorts behaves the way it does. And the OS history discussions are off-topic. 
Users subscribe to this list to discuss using MacPorts so let's get back to 
talking about that.

___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Darwin Version

[Brandon Allbery]

On Mon, Oct 5, 2015 at 6:42 PM, Dave Horsfall  wrote:

> On Sat, 3 Oct 2015, Ryan Schmidt wrote:
> > > Remember: under the bonnet (ObUSA: hood) the Mac runs FreeBSD.
> >
> > OS X is underpinned by Darwin, not FreeBSD. Darwin is based on NeXTSTEP,
> > BSD, XNU and other projects, and of course a great deal of independent
> > work by Apple.
>
> You're saying that Darwin was written from scratch and not evolved from a
> modified FreeBSD 4.1, or am I thinking of an earlier MacOS?
>

It was never derived from FreeBSD 4.1.

CMU Mach was a custom-written microkernel, hosting an OS which was a
heavily modified 4.2BSD (the original Berkeley Source Distribution, long
predating FreeBSD). NeXTStep took this and updated it. OS X took that and
updated it again, including replacing much of the userspace that was not
Darwin-specific with FreeBSD-CURRENT as of that time, and periodically
updates those parts of the userspace from the latest FreeBSD-CURRENT. The
kernel, however, is still largely custom. Some subsystems were originally
borrowed from FreeBSD-CURRENT (the original USB stack, for example), but
Apple later rewrote them (and in the case of USB, that was badly needed;
FreeBSD still has significant USB stack issues). The core of the kernel is
not, however, related to FreeBSD except in being a heavily rewritten
version of FreeBSD's ancestor.
-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Darwin Version

[Dave Horsfall]

On Sat, 3 Oct 2015, Ryan Schmidt wrote:

> > Remember: under the bonnet (ObUSA: hood) the Mac runs FreeBSD.
> 
> OS X is underpinned by Darwin, not FreeBSD. Darwin is based on NeXTSTEP, 
> BSD, XNU and other projects, and of course a great deal of independent 
> work by Apple.

You're saying that Darwin was written from scratch and not evolved from a 
modified FreeBSD 4.1, or am I thinking of an earlier MacOS?

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Darwin Version

[Daniel J. Luke]

On Oct 5, 2015, at 6:42 PM, Dave Horsfall  wrote:
> You're saying that Darwin was written from scratch and not evolved from a 
> modified FreeBSD 4.1, or am I thinking of an earlier MacOS?

it all depends on what you mean by ‘written from scratch’, ‘evolved from’, and 
how detailed you care to be with the history. I believe you’re either 
conflating 4.2BSD (1983) and FreeBSD 4.1 (2000) or you’re thinking about 
userspace stuff that got updated in Mac OS X (around 2000 IIRC).

see also:

https://en.wikipedia.org/wiki/History_of_Unix#/media/File:Unix_history-simple.svg

and/or 

http://www.levenez.com/unix/unix_a4.pdf

— 
Daniel J. Luke  
 
++ 
| * dl...@geeklair.net * |  

| *-- http://www.geeklair.net -* |  

++ 
|   Opinions expressed are mine and do not necessarily   |  

|  reflect the opinions of my employer.  |  

++




___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Darwin Version

[William H. Magill]

> On Oct 3, 2015, at 9:35 AM, Jeffrey A. Singleton  wrote:
> 
> As you can see…the very first command run as instructed by the so-called 
> migration steps shows the same error. Basically…nothing anyone has suggested 
> so far even remotely comes close to a solution, and the migration page is 
> useless. All of you making smart-ass comments, that seem to think you know 
> everything need to shut up and let someone that intends to help try to 
> provide a solution to the problem for the masses.
> 
> Since the ‘selfupdate’ process won’t let you upgrade MacPorts, and the 
> migration page assumes you are still using the same version of MacPorts, thus 
> will not work since Apple bumped the platform version to Darwin 15…a very 
> common step they do in almost every OS upgrade. It seems to me that 
> reinstalling MacPorts is the only way around this…
> 
> To reinstall from PKG, we need to assume the package was compile on an El 
> Capitan system so that the correct platform is used. Or if you are like me, 
> and compiled your own MacPorts from source, then all that should be needed is 
> to download the latest source and recompile…after backing up all the 
> configuration files in /opt/local/etc/macports first…then install.
> 
> Success!
> 
> After re-compiling MacPorts from source and confirming any custom 
> configurations were restored…the ‘selfupdate’ process worked flawlessly. 
> Following this with ‘port upgrade outdated’ - order is once again restored in 
> the world.

Ok, here is “my answer.” In updating two systems, the first one generated the 
14 vs 15 error, so I wiped the install and re-installed from the Mac Ports El 
Capitan QuickStart download.

With the second system, I started out by downloading and installing the El 
Capitan QuickStart version of MacPorts — no error message!  — Duh  . . . 

As with the “success” above, the answer appears to be with the Migration 
Instructions.
The problem is that the visual queues given by the “command indent and boxing” 
are much more emphatic than the numbered items. i.e. the Eye overrides RTFM.

Step one needs to be — download and install the version of MacPorts appropriate 
to the new release found at the top of  the QuickStart page, NOT “port -qv”!

Or put another way, the instructions on the QuickStart page and the Migration 
page need to be better integrated.
Step 2 in the Migration Procedure is the key.

Maybe wording like: 

"Reinstall MacPorts base. After updating the development tools, install the 
base MacPorts system  for your new platform, either from the appropriate 
installer (download it from the QuickStart section) or from source.”

Similarly, the numbering of the Migration Guide is somewhat confusing.

2.a should probably be moved to 3.a and the rest of 3 renumbered accordingly.

As with writing all such instructions, the baggage (experience) which is 
brought to the instructions by the person reading them is always different when 
compared to that of the person writing them. There is no one-size-fits-all 
solution. And sadly today, the primary technique is “post first” and re-read 
the instructions later.


T.T.F.N.
William H. Magill
# iMac11,3 Core i7 [2.93GHz - 8 GB 1067MHz] OS X 10.11
# Macmini6,1 Intel Core i5 [2.5 Ghz - 4GB 1600MHz] OS X 10.11

mag...@icloud.com
mag...@mac.com
whmag...@gmail.com








___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Darwin Version

[Richard L. Hamilton]

Presumably keeping normal uses of system programs from being subverted (even if 
they're not running privileged, i.e. setuid/setgid).  There is probably some 
benefit to normal uses, but it's demonstrably trivial to work around if one 
already has full control.

I tend to think they went overboard, and/or this wasn't well designed, although 
I suspect that if number of users benefited vs adversely affected is the only 
measure, it may work as intended.  My impression is that at the very least, 
there are a number of cases of legitimate configuration that aren't supported.  
Fine-grained permissions (an alternative to all-powerful root) in Solaris make 
some sense, for example; this reminds me more of the 3rd party open-source 
"Papillion" module for Solaris, which could lock down or blacklist or restrict 
to user view certain features, but wasn't really comprehensive.

Were I to take a really wild guess, some of the thinking of how to do this (in 
principle, if not detail) may have come from the iOS/OS X cross-pollination.  
But what's appropriate on a mobile device (assuming  you agree they should be 
locked down) isn't necessarily appropriate on a general purpose system.   It 
wouldn't take a lot of change to accommodate doing much better; just allow an 
overriding per-system config file that updates didn't touch, that could add 
exceptions to the directories and files protected by SIP.  If one wanted to be 
paranoid, one could then have that file lock itself down, too, once one had it 
the way one wanted.  That way, nobody would ever have to turn off SIP (except 
temporarily, to set up that file if they wanted it).


> On Oct 4, 2015, at 01:42, Sven Kolja Heinemann  wrote:
> 
> Where is the security benefit from this, that Apple wants to Achieve?
> 
> Am 03.10.2015 um 22:30 schrieb Richard L. Hamilton  >:
> 
>> But it's so easy to test that theory::-)
>> sh-3.2# dtruss /bin/sh
>> dtrace: failed to execute /bin/sh: dtrace cannot control executables signed 
>> with restricted entitlements
>> sh-3.2# dtruss /net/localhost/bin/sh
>> sh-3.2# SYSCALL(args) = return
>> thread_selfid(0x0, 0x0, 0x0)  = 867702 0
>> csops(0x0, 0x0, 0x7FFF563BF720)   = 0 0
>> issetugid(0x0, 0x0, 0x7FFF563BF720)   = 0 0



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Darwin Version

[Richard L. Hamilton]

> On Oct 3, 2015, at 14:41, Brandon Allbery  wrote:
> 
> On Sat, Oct 3, 2015 at 2:39 PM, Clemens Lang  > wrote:
> > Same thing, but as seen in the 2nd case, no com.apple.rootless attribute, no
> > restricted (or hidden) flags. :-)
> 
> Mounts are a nice idea, but not possible without root privileges, and that 
> leaves
> out everybody that uses a user-only installation of MacPorts. So this could 
> only
> be done as an optimization, and I'm not sure it's worth it then. Cache
> invalidation would definitely be easier with it, though…
> 
> ...but at some point the NFS server must access the file, in the original 
> filesystem where all of those exist and will be enforced.

To explain why my trick worked...NFS server doesn't know about execs; at that 
level, it's just getting file read RPCs.  So there's nothing for NFS server to 
enforce.  The client could enforce, but not if the NFS implementation doesn't 
communicate named attributes (and the NFS protocol doesn't support chflags() 
flags).



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Darwin Version

[Ryan Schmidt]

On Oct 3, 2015, at 5:25 AM, Dave Horsfall wrote:

> Remember: under the bonnet (ObUSA: hood) the Mac runs FreeBSD.

OS X is underpinned by Darwin, not FreeBSD. Darwin is based on NeXTSTEP, BSD, 
XNU and other projects, and of course a great deal of independent work by Apple.

___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Darwin Version

[Bachsau]

Jeffrey A. Singleton wrote on 03.10.2015 15:35:

As you can see…the very first command run as instructed by the so-called
migration steps shows the same error. Basically…nothing anyone has
suggested so far even remotely comes close to a solution, and the
migration page is useless.


WTF is going on with you? The migration page clearly states "Reinstall 
MacPorts base.". So whats your problem?


I was somewhat pissed of by the procedure, but my question got answerd, 
besides I was told what's the reason for the recomended procedure and a 
good discussion evolved from this.



I won’t be responding to anything other than mature replies…if you can’t
be smart without being an ass…save your breath.


Yeah, I think we'll all miss you. Just go fuck yourself.
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Darwin Version

[woods . w]

This whole thread has been extremely entertaining… I am amazed by the attitudes 
shown by so many adults. This is FREE software, shit breaks, shit breaks on day 
one of a new os, wow, news flash. Don’t like it 1) Don’t use it  - no one is 
forcing you to 2) Fix it yourself - it IS open 3) wait for the maintainers to 
fix it - they do this in their SPARE time, you are not entitled to a fix 
immediately.

If your need is so immediate that you RELY on something that other people do 
for free in their spare time, I submit you 1) Don’t rely on it or 2) Learn to 
maintain it yourself.

Good Day

> On Oct 3, 2015, at 8:45 AM, Bachsau  wrote:
> 
> Jeffrey A. Singleton wrote on 03.10.2015 15:35:
>> As you can see…the very first command run as instructed by the so-called
>> migration steps shows the same error. Basically…nothing anyone has
>> suggested so far even remotely comes close to a solution, and the
>> migration page is useless.
> 
> WTF is going on with you? The migration page clearly states "Reinstall 
> MacPorts base.". So whats your problem?
> 
> I was somewhat pissed of by the procedure, but my question got answerd, 
> besides I was told what's the reason for the recomended procedure and a good 
> discussion evolved from this.
> 
>> I won’t be responding to anything other than mature replies…if you can’t
>> be smart without being an ass…save your breath.
> 
> Yeah, I think we'll all miss you. Just go fuck yourself.
> ___
> macports-users mailing list
> macports-users@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-users

___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Darwin Version

[Rainer Müller]

On 10/03/2015 03:35 PM, Jeffrey A. Singleton wrote:
> So I go to the migration page as mentioned in the error and begin with Step 1:
> 
> root@minimac ~ #  port -qv installed > myports.txt
> Error: Current platform "darwin 15" does not match expected platform 
> "darwin 14"
> Error: If you upgraded your OS, please follow the migration instructions:
> https://trac.macports.org/wiki/Migration
> Error: /opt/local/bin/port: Failed to initialize MacPorts, OS platform 
> mismatch

This is actually Step *3*. You skipped 1. reinstalling Xcode and 2. reinstalling
MacPorts. It is already a numbered list of steps...

What should we change on the wiki page to make it more clear?
This is an honest question. I am open to suggestions.

Rainer
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Darwin Version

[Jeremy Huddleston Sequoia]

> On Oct 2, 2015, at 06:19, Brandon Allbery  wrote:
> 
> On Fri, Oct 2, 2015 at 9:13 AM, Bachsau  wrote:
> What a crap is this? I've been using Arch Linux before and never needed to 
> recompile any third party software, just because system packages where 
> updated. Software that needs to be reinstalled / recompiled on every little 
> operating system upgrade is bad software.
> 
> Apple does not care what you think. There's a discussion of rootless on the 
> apple-x11 list where the number of OS X users who care about building 
> non-Apple software is stated (by an Apple employee) at around 0.001% --- they 
> aren't going to care what they break for you.

Uh, you are greatly misquoting me.

I said that the number of people who probably want to go and mess around with 
/usr/lib/pam and things like that are around 0.001% of the user base and that 
we specifically went to great lengths to support even that small minority.


> (The message doesn't seem to have been indexed yet, or I'd link it. Should 
> show up at http://lists.apple.com/archives/x11-users/2015/Oct/index.html)
> 
> -- 
> brandon s allbery kf8nh   sine nomine associates
> allber...@gmail.com  ballb...@sinenomine.net
> unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
> ___
> macports-users mailing list
> macports-users@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-users



smime.p7s
Description: S/MIME cryptographic signature
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Darwin Version

[Jeremy Huddleston Sequoia]

> On Oct 2, 2015, at 07:00, Brandon Allbery  wrote:
> 
> I should note that that's just an example; libSystem has only changed that 
> way once, I think.

Do you have a radar or forum post or something regarding this example of where 
libSystem broke in a binary incompatible way (and wasn't seen as a bug and 
wasn't fixed)?  If you notice, we've gone to great lengths to maintain binary 
compatibility which is why we have so many symbol variants for cases where we 
needed to change behavior (eg: for our change to 64bit inodes, for UNIX2003 
conformance changes, etc).

> But the same applies to other Apple-only frameworks, which change more often 
> and more radically. Apple also has no qualms about removing old frameworks 
> they don't care about any more, in which case your old 10.5 programs relying 
> on those frameworks *will* stop working (I think they did that with 
> QuickTime?).

Frameworks are removed from the SDK after a long period of deprecation, but the 
binaries are still shipped long after that for binary compatibility.  Take a 
look, and you will see that /System/Library/Frameworks/QuickTime.framework is 
still there.

> Basically, if Apple cared they could make this stuff work. But they don't, so 
> migration becomes a major hassle.

File radars if you think there are problems.  FWIW, I don't migrate, and I 
don't have problems.

> 
> On Fri, Oct 2, 2015 at 9:52 AM, Brandon Allbery  wrote:
> On Fri, Oct 2, 2015 at 9:31 AM, Bachsau  wrote:
> Maybe. Seems like I'm just not getting what is technically causing these 
> problems. When libraries change, and it breaks a particular application, why 
> can't I recompile just that? And why would the build of a newly installed 
> port fail, just because there are other ports installed that were compiled 
> against older system libraries?
> 
> Dependencies. Port X compiles against new libSystem, depends on port Y that 
> was linked against old libSystem, link fails because it tries to bring in 
> both versions and they conflict. (Keeping around old libSystem versions is 
> how you can still run applications built for 10.5 on 10.10/10.11.)
> 
> This doesn't happen on Linux because glibc is obsessive about maintaining 
> backward compatibility interfaces, so the older program links against the 
> current glibc and uses compatibility interfaces from it; this works even for 
> libraries. Apple doesn't care about backward compatibility enough to do 
> things that way.
> 
> -- 
> brandon s allbery kf8nh   sine nomine associates
> allber...@gmail.com  ballb...@sinenomine.net
> unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
> 
> 
> 
> -- 
> brandon s allbery kf8nh   sine nomine associates
> allber...@gmail.com  ballb...@sinenomine.net
> unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
> ___
> macports-users mailing list
> macports-users@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-users



smime.p7s
Description: S/MIME cryptographic signature
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Darwin Version

[Dave Horsfall]

On Fri, 2 Oct 2015, Ryan Schmidt wrote:

> We're trying to make MacPorts into a system that just works, and that 
> means that when we discover common situations where MacPorts fails to 
> work, we try to modify MacPorts so that users are less likely to 
> encounter them. One of the common problems we discovered was when 
> MacPorts is built on one version of OS X and used on another version of 
> OS X. So now we prevent that, via the error message that caused you to 
> begin this thread.

And with any luck, both MacPorts and FreeBSD-ports will learn from each
other.

Remember: under the bonnet (ObUSA: hood) the Mac runs FreeBSD.

A family exchange, some years back:

Ex: Iain, why did Dave buy a Mac?  I thought he was a Unix person!
Son (in a withering tone): Mum, the Mac *runs* Unix.
Me: That's right, Iain; I wouldn't've bought it otherwise.

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Darwin Version

[Jeremy Huddleston Sequoia]

> On Oct 2, 2015, at 06:18, Dominik Reichardt  wrote:
> 
> Calm down and complain to Apple

Well, complain if you actually have a specific bug to complain about.

For the most part, I'm pretty sure the original reporter is correct and most 
everything that was built against Yosemite will continue to work just fine in 
El Cap.

--Jeremy

>> Am 02.10.2015 um 15:13 schrieb Bachsau :
>> 
>> 
>>> Am 01.10.2015 um 16:08 schrieb Rainer Müller :
>>> 
>>> It may appear to be still working right now, but there is no guarantee
>>> that it will work at all. Even if it seems to be working now, later
>>> updates will cause problems. For example updates will link to a
>>> different set of new system libraries.
>>> 
>>> Although cumbersome, the migration procedure ensures that everything
>>> keeps working after upgrading to a new OS X release.
>> 
>> What a crap is this? I've been using Arch Linux before and never needed to 
>> recompile any third party software, just because system packages where 
>> updated. Software that needs to be reinstalled / recompiled on every little 
>> operating system upgrade is bad software.
>> ___
>> macports-users mailing list
>> macports-users@lists.macosforge.org
>> https://lists.macosforge.org/mailman/listinfo/macports-users
> ___
> macports-users mailing list
> macports-users@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-users



smime.p7s
Description: S/MIME cryptographic signature
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Darwin Version

[Clemens Lang]

Hi Jeremy,

- On 3 Oct, 2015, at 10:56, Jeremy Huddleston Sequoia jerem...@apple.com 
wrote:

>> In theory, we have a solution for this problem: trace mode hides anything 
>> from
>> a port's build system that doesn't come with the system and is not in the 
>> list
>> of dependencies, so *in theory* we could replace migration with
>>  sudo port -t upgrade outdated,
>> and in fact, I successfully tested this during the last OS upgrade. With the
>> upgrade to El Capitan, though, Apple's System Integrity Protection actually
>> breaks trace mode (Yay!), so this not an option, leading us to recommend the
>> migration procedure.
> 
> How does SIP break it?  Do you have a radar or MP ticket?  I'm curious to
> followup on that.

DYLD_ variables are stripped from the environment when executing binaries under
SIP. That no longer allows us to preload our tracing library into lots and lots
of tools we use, such as /bin/sh, /usr/bin/python, /usr/bin/make, 
/usr/bin/clang,
etc.

My impression is that this was a deliberate security decision to make sure the
binary you are executing is actually the one protected by SIP and the exact
version Apple provided. Please correct me if this assumption is wrong.

For now, I think trace mode can be modified to work around this limitation by
keeping a shadow copy of all binaries under SIP it wants to execute; since we
wrap posix_spawn and execve, we can determine whether the executed binary has
SIP enabled, copy it if that's the case, and run the copy instead,
circumventing the security measures.

Btw, what I would actually consider a bug is that running /usr/bin/env (or
printenv) now no longer show any DYLD_* variables that may be set in your
environment. Previously we would ask users to run env | grep DYLD_ to check
for environment variables if they had trouble executing binaries installed
using MacPorts. I guess we'll go with (set -o posix; set) | grep DYLD_ now,
even though that's not the same.

-- 
Clemens Lang
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Darwin Version

[Jeremy Huddleston Sequoia]

> On Oct 2, 2015, at 08:01, Clemens Lang  wrote:
> 
> Hi,
> 
> - On 2 Oct, 2015, at 15:33, Bachsau w...@bachsau.name wrote:
> 
>> Maybe. Seems like I'm just not getting what is technically causing these
>> problems. When libraries change, and it breaks a particular application, why
>> can't I recompile just that? And why would the build of a newly installed 
>> port
>> fail, just because there are other ports installed that were compiled against
>> older system libraries?
> 
> There are changes that can be done by Apple with OS upgrades that will render
> your currently installed libraries useless. Examples for changes that are of
> this nature are:
>  - Apple changing CPU architecture
>  - Apple changing the ABI of a library you link against (e.g. when moving
>to C++11 using libc++)

We haven't changed the ABI.

We've added a new C++ runtime (libc++), but still continue to ship the older 
libstdc++ runtime for binary compatibility.

>  - Apple no longer shipping a certain library

This usually happens very rarely, and I can't even think of an example where 
this has happened other than X11, for which I wrote a transitionary system to 
capture that usage and direct users to XQuartz.  Usually when it happens is for 
new platforms or architectures (eg: some things were dropped in the transition 
to 64bit or in the transition to Intel).

> This can leave you with binaries or libraries that no longer work. If a build
> system now picks up one of these broken binaries or libraries (that does 
> happen,
> especially with missing architectures from universal binaries or missing
> libraries), your binary will crash during the build or the build will fail to
> link against a library. This will make your rebuild fail.
> 
> Of course, anything that is needed for a build should be in the list of
> dependencies of a port, and should thus get rebuilt before the port in 
> question,
> avoiding the problem. Reality is different, however: build systems like cmake
> and autotools look for optional dependencies all over the place and try to use
> them if found, even if they are not in the list of dependencies, which leads 
> to
> these problems.
> 
> In theory, we have a solution for this problem: trace mode hides anything from
> a port's build system that doesn't come with the system and is not in the list
> of dependencies, so *in theory* we could replace migration with
>  sudo port -t upgrade outdated,
> and in fact, I successfully tested this during the last OS upgrade. With the
> upgrade to El Capitan, though, Apple's System Integrity Protection actually
> breaks trace mode (Yay!), so this not an option, leading us to recommend the
> migration procedure.

How does SIP break it?  Do you have a radar or MP ticket?  I'm curious to 
followup on that.

> So yes, careful thought has been given to the problem at hand, I agree it's
> annoying, but given the way Apple handles things, there are currently no other
> options.
> 
> -- 
> Clemens Lang
> ___
> macports-users mailing list
> macports-users@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-users



smime.p7s
Description: S/MIME cryptographic signature
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Darwin Version

[Ryan Schmidt]

On Oct 3, 2015, at 8:45 AM, Bachsau wrote:

> Jeffrey A. Singleton wrote on 03.10.2015 15:35:
>> As you can see…the very first command run as instructed by the so-called
>> migration steps shows the same error. Basically…nothing anyone has
>> suggested so far even remotely comes close to a solution, and the
>> migration page is useless.
> 
> WTF is going on with you? The migration page clearly states "Reinstall 
> MacPorts base.". So whats your problem?
> 
> I was somewhat pissed of by the procedure, but my question got answerd, 
> besides I was told what's the reason for the recomended procedure and a good 
> discussion evolved from this.
> 
>> I won’t be responding to anything other than mature replies…if you can’t
>> be smart without being an ass…save your breath.
> 
> Yeah, I think we'll all miss you. Just go fuck yourself.

Let's all of us please keep a civil tone on the MacPorts communication 
channels. Thanks.


___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Darwin Version

[Joshua Root]

Jeremy Huddleston Sequoia  wrote:
>> On Oct 2, 2015, at 08:01, Clemens Lang  wrote:
>> There are changes that can be done by Apple with OS upgrades that will render
>> your currently installed libraries useless. Examples for changes that are of
>> this nature are:
>>  - Apple changing CPU architecture
>>  - Apple changing the ABI of a library you link against (e.g. when moving
>>to C++11 using libc++)
> 
> We haven't changed the ABI.
> 
> We've added a new C++ runtime (libc++), but still continue to ship the older 
> libstdc++ runtime for binary compatibility.

You are technically correct of course, but making the distinction may be
muddying the waters. Binary compatibility only applies where an
executable and the libraries it uses are all built for the same target.

Yes, if you upgrade the OS, all your installed ports will generally work
fine--to start with. But if we didn't require a rebuild for ports that
were built for a different OS version, something like this would happen:

X 1.0 uses libstdc++ and links with libY 1.0 which also uses libstdc++
User updates OS to a version where the compiler defaults to libc++
libY is updated to 1.1 and is now using libc++
X is now broken.

- Josh
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Darwin Version

[Jeremy Huddleston Sequoia]

> On Oct 3, 2015, at 06:02, Clemens Lang  wrote:
> 
> Hi Jeremy,
> 
> - On 3 Oct, 2015, at 10:56, Jeremy Huddleston Sequoia jerem...@apple.com 
> wrote:
> 
>>> In theory, we have a solution for this problem: trace mode hides anything 
>>> from
>>> a port's build system that doesn't come with the system and is not in the 
>>> list
>>> of dependencies, so *in theory* we could replace migration with
>>> sudo port -t upgrade outdated,
>>> and in fact, I successfully tested this during the last OS upgrade. With the
>>> upgrade to El Capitan, though, Apple's System Integrity Protection actually
>>> breaks trace mode (Yay!), so this not an option, leading us to recommend the
>>> migration procedure.
>> 
>> How does SIP break it?  Do you have a radar or MP ticket?  I'm curious to
>> followup on that.
> 
> DYLD_ variables are stripped from the environment when executing binaries 
> under
> SIP. That no longer allows us to preload our tracing library into lots and 
> lots
> of tools we use, such as /bin/sh, /usr/bin/python, /usr/bin/make, 
> /usr/bin/clang,
> etc.

Ah, that, yes.

> My impression is that this was a deliberate security decision to make sure the
> binary you are executing is actually the one protected by SIP and the exact
> version Apple provided. Please correct me if this assumption is wrong.

This was unfortunate fallout from the hardening effort and is something that 
we're aware of and looking into.

> For now, I think trace mode can be modified to work around this limitation by
> keeping a shadow copy of all binaries under SIP it wants to execute; since we
> wrap posix_spawn and execve, we can determine whether the executed binary has
> SIP enabled, copy it if that's the case, and run the copy instead,
> circumventing the security measures.
> 
> Btw, what I would actually consider a bug is that running /usr/bin/env (or
> printenv) now no longer show any DYLD_* variables that may be set in your
> environment. Previously we would ask users to run env | grep DYLD_ to check
> for environment variables if they had trouble executing binaries installed
> using MacPorts. I guess we'll go with (set -o posix; set) | grep DYLD_ now,
> even though that's not the same.

Yes, that's basically the same issue.  The DYLD_ environment variables are 
stripped out when executing system binaries.  /usr/bin/env, /bin/bash, etc are 
system binaries.




smime.p7s
Description: S/MIME cryptographic signature
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Darwin Version

[Jeffrey A. Singleton]

So I just read through this whole thread and it appears not a single person
understands the problem

After upgrading to El CapitanŠthen proceeding to do Œport selfupdate¹ I am
show the error reported by the original poster.

> root@minimac ~ #  port -v selfupdate
> Error: Current platform "darwin 15" does not match expected platform "darwin
> 14"
> Error: If you upgraded your OS, please follow the migration instructions:
> https://trac.macports.org/wiki/Migration
> OS platform mismatch
> while executing
> "mportinit ui_options global_options global_variations"
> Error: /opt/local/bin/port: Failed to initialize MacPorts, OS platform
> mismatch

So I go to the migration page as mentioned in the error and begin with Step
1:

> root@minimac ~ #  port -qv installed > myports.txt
> Error: Current platform "darwin 15" does not match expected platform "darwin
> 14"
> Error: If you upgraded your OS, please follow the migration instructions:
> https://trac.macports.org/wiki/Migration
> Error: /opt/local/bin/port: Failed to initialize MacPorts, OS platform
> mismatch

As you can seeŠthe very first command run as instructed by the so-called
migration steps shows the same error. BasicallyŠnothing anyone has suggested
so far even remotely comes close to a solution, and the migration page is
useless. All of you making smart-ass comments, that seem to think you know
everything need to shut up and let someone that intends to help try to
provide a solution to the problem for the masses.

Since the Œselfupdate¹ process won¹t let you upgrade MacPorts, and the
migration page assumes you are still using the same version of MacPorts,
thus will not work since Apple bumped the platform version to Darwin 15Ša
very common step they do in almost every OS upgrade. It seems to me that
reinstalling MacPorts is the only way around thisŠ

To reinstall from PKG, we need to assume the package was compile on an El
Capitan system so that the correct platform is used. Or if you are like me,
and compiled your own MacPorts from source, then all that should be needed
is to download the latest source and recompileŠafter backing up all the
configuration files in /opt/local/etc/macports firstŠthen install.

Success!

After re-compiling MacPorts from source and confirming any custom
configurations were restoredŠthe Œselfupdate¹ process worked flawlessly.
Following this with Œport upgrade outdated¹ - order is once again restored
in the world.

I won¹t be responding to anything other than mature repliesŠif you can¹t be
smart without being an assŠsave your breath.

J

On 10/3/15, 8:02 AM, "Clemens Lang"

wrote:

> Hi Jeremy,
> 
> - On 3 Oct, 2015, at 10:56, Jeremy Huddleston Sequoia jerem...@apple.com
> wrote:
> 
>>>  In theory, we have a solution for this problem: trace mode hides anything
>>> from
>>>  a port's build system that doesn't come with the system and is not in the
>>> list
>>>  of dependencies, so *in theory* we could replace migration with
>>>   sudo port -t upgrade outdated,
>>>  and in fact, I successfully tested this during the last OS upgrade. With
>>> the
>>>  upgrade to El Capitan, though, Apple's System Integrity Protection actually
>>>  breaks trace mode (Yay!), so this not an option, leading us to recommend
>>> the
>>>  migration procedure.
>>  
>>  How does SIP break it?  Do you have a radar or MP ticket?  I'm curious to
>>  followup on that.
> 
> DYLD_ variables are stripped from the environment when executing binaries
> under
> SIP. That no longer allows us to preload our tracing library into lots and
> lots
> of tools we use, such as /bin/sh, /usr/bin/python, /usr/bin/make,
> /usr/bin/clang,
> etc.
> 
> My impression is that this was a deliberate security decision to make sure the
> binary you are executing is actually the one protected by SIP and the exact
> version Apple provided. Please correct me if this assumption is wrong.
> 
> For now, I think trace mode can be modified to work around this limitation by
> keeping a shadow copy of all binaries under SIP it wants to execute; since we
> wrap posix_spawn and execve, we can determine whether the executed binary has
> SIP enabled, copy it if that's the case, and run the copy instead,
> circumventing the security measures.
> 
> Btw, what I would actually consider a bug is that running /usr/bin/env (or
> printenv) now no longer show any DYLD_* variables that may be set in your
> environment. Previously we would ask users to run env | grep DYLD_ to check
> for environment variables if they had trouble executing binaries installed
> using MacPorts. I guess we'll go with (set -o posix; set) | grep DYLD_ now,
> even though that's not the same.
> 
> -- 
> Clemens Lang
> ___
> macports-users mailing list
> macports-users@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-users
> 


___

Re: Darwin Version

[Bachsau]

Clemens Lang wrote on 03.10.2015 15:02:

such as /bin/sh, /usr/bin/python, /usr/bin/make, /usr/bin/clang,
etc.


All of which are also part of macports, so can't you just use this or 
create shadowcopies yourself?

___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Darwin Version

[Clemens Lang]

- On 3 Oct, 2015, at 15:47, Bachsau w...@bachsau.name wrote:

> Clemens Lang wrote on 03.10.2015 15:02:
>> such as /bin/sh, /usr/bin/python, /usr/bin/make, /usr/bin/clang,
>> etc.
> 
> All of which are also part of macports, so can't you just use this or
> create shadowcopies yourself?

Yes, we could provide copies of bash, python, make and clang ourselves
and use them instead. So far, we have always relied on Apple's toolchain
but you're right that we don't really have to.

However, remember that it's not just 3-4 binaries we're talking about
here. Lots and lots of smaller tools would also be needed, such as ar,
as, arch, awk, base64, bc, bison, bzip2, chgrp, chown, cpio, curl, diff,
du, grep, fmt, gzip, ...

We're currently re-using some of those from /usr/bin to reduce the
footprint of our build dependencies. MacPorts is already being
criticized for using too much storage and "downloading the internet"
before installing what you initially requested, and a change such as
this would make things even worse.

-- 
Clemens Lang
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Darwin Version

[Richard L. Hamilton]

> 
> Btw, what I would actually consider a bug is that running /usr/bin/env (or
> printenv) now no longer show any DYLD_* variables that may be set in your
> environment. Previously we would ask users to run env | grep DYLD_ to check
> for environment variables if they had trouble executing binaries installed
> using MacPorts. I guess we'll go with (set -o posix; set) | grep DYLD_ now,
> even though that's not the same.


Hmm, I'm not seeing that:

13:34:19[800]lapple:/Users/rlhamil> echo $0
/bin/ksh
13:34:23[801]lapple:/Users/rlhamil> /usr/bin/env|grep DYLD
DYLD_FORCE_FLAT_NAMESPACE=1
DYLD_INSERT_LIBRARIES=/Users/rlhamil/lib/use_editres.dylib

(that's something I had done years ago to enable editres support on X11 Xt 
based programs in cases where neither Xt nor the program explicitly enabled 
editres support...by wrapping a couple of libXt functions; although oddly, it 
doesn't seem necessary anymore; maybe libXt was built more recently, with 
editres enabled?)



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Darwin Version

[Brandon Allbery]

On Sat, Oct 3, 2015 at 2:39 PM, Clemens Lang  wrote:

> > Same thing, but as seen in the 2nd case, no com.apple.rootless
> attribute, no
> > restricted (or hidden) flags. :-)
>
> Mounts are a nice idea, but not possible without root privileges, and that
> leaves
> out everybody that uses a user-only installation of MacPorts. So this
> could only
> be done as an optimization, and I'm not sure it's worth it then. Cache
> invalidation would definitely be easier with it, though…


...but at some point the NFS server must access the file, in the original
filesystem where all of those exist and will be enforced.

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Darwin Version

[Clemens Lang]

- On 3 Oct, 2015, at 20:41, Brandon Allbery allber...@gmail.com wrote:

> ...but at some point the NFS server must access the file, in the original
> filesystem where all of those exist and will be enforced.

But that's not really a problem. As I said earlier, we work around the
limitation of DYLD_* variables being removed by working with a copy of the
binaries. Going through NFS is basically just a way to work on a copy
without actually needing the additional disk space.

-- 
Clemens Lang
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Darwin Version

[Richard L. Hamilton]

> On Oct 3, 2015, at 14:41, Brandon Allbery  wrote:
> 
> On Sat, Oct 3, 2015 at 2:39 PM, Clemens Lang  > wrote:
> > Same thing, but as seen in the 2nd case, no com.apple.rootless attribute, no
> > restricted (or hidden) flags. :-)
> 
> Mounts are a nice idea, but not possible without root privileges, and that 
> leaves
> out everybody that uses a user-only installation of MacPorts. So this could 
> only
> be done as an optimization, and I'm not sure it's worth it then. Cache
> invalidation would definitely be easier with it, though…
> 
> ...but at some point the NFS server must access the file, in the original 
> filesystem where all of those exist and will be enforced.
> 


But it's so easy to test that theory::-)
sh-3.2# dtruss /bin/sh
dtrace: failed to execute /bin/sh: dtrace cannot control executables signed 
with restricted entitlements
sh-3.2# dtruss /net/localhost/bin/sh
sh-3.2# SYSCALL(args)= return
thread_selfid(0x0, 0x0, 0x0) = 867702 0
csops(0x0, 0x0, 0x7FFF563BF720)  = 0 0
issetugid(0x0, 0x0, 0x7FFF563BF720)  = 0 0



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Darwin Version

[Eric A. Borisch]

On Saturday, October 3, 2015, Clemens Lang  wrote:

>
>
> - On 3 Oct, 2015, at 15:47, Bachsau w...@bachsau.name 
> wrote:
>
> > Clemens Lang wrote on 03.10.2015 15:02:
> >> such as /bin/sh, /usr/bin/python, /usr/bin/make, /usr/bin/clang,
> >> etc.
> >
> > All of which are also part of macports, so can't you just use this or
> > create shadowcopies yourself?
>
> Yes, we could provide copies of bash, python, make and clang ourselves
> and use them instead. So far, we have always relied on Apple's toolchain
> but you're right that we don't really have to.
>
> However, remember that it's not just 3-4 binaries we're talking about
> here. Lots and lots of smaller tools would also be needed, such as ar,
> as, arch, awk, base64, bc, bison, bzip2, chgrp, chown, cpio, curl, diff,
> du, grep, fmt, gzip, ...
>
> We're currently re-using some of those from /usr/bin to reduce the
> footprint of our build dependencies. MacPorts is already being
> criticized for using too much storage and "downloading the internet"
> before installing what you initially requested, and a change such as
> this would make things even worse.
>

 Is there something clever that could be done with mounts or hard
(directory) links here?

  - Eric
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Darwin Version

[Richard L. Hamilton]

> On Oct 3, 2015, at 13:26, Eric A. Borisch  wrote:
> 
> On Saturday, October 3, 2015, Clemens Lang  > wrote:
> 
> 
> - On 3 Oct, 2015, at 15:47, Bachsau w...@bachsau.name  
> wrote:
> 
> > Clemens Lang wrote on 03.10.2015 15:02:
> >> such as /bin/sh, /usr/bin/python, /usr/bin/make, /usr/bin/clang,
> >> etc.
> >
> > All of which are also part of macports, so can't you just use this or
> > create shadowcopies yourself?
> 
> Yes, we could provide copies of bash, python, make and clang ourselves
> and use them instead. So far, we have always relied on Apple's toolchain
> but you're right that we don't really have to.
> 
> However, remember that it's not just 3-4 binaries we're talking about
> here. Lots and lots of smaller tools would also be needed, such as ar,
> as, arch, awk, base64, bc, bison, bzip2, chgrp, chown, cpio, curl, diff,
> du, grep, fmt, gzip, ...
> 
> We're currently re-using some of those from /usr/bin to reduce the
> footprint of our build dependencies. MacPorts is already being
> criticized for using too much storage and "downloading the internet"
> before installing what you initially requested, and a change such as
> this would make things even worse.
> 
>  Is there something clever that could be done with mounts or hard (directory) 
> links here?

An NFS mount of self might work - the Mac NFS implementation doesn't seem to 
pass named attributes, and NFS protocol doesn't pass flags.  Thus:

sh-3.2$ ls -ldO@ /bin /net/localhost/bin
drwxr-xr-x@ 42 root  wheel  restricted,hidden 1428 Oct  2 04:41 /bin
com.apple.FinderInfo  32
com.apple.rootless 0
drwxr-xr-x  42 root  wheel  - 1428 Oct  2 04:41 
/net/localhost/bin


Same thing, but as seen in the 2nd case, no com.apple.rootless attribute, no 
restricted (or hidden) flags. :-)




signature.asc
Description: Message signed with OpenPGP using GPGMail
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Darwin Version

[Clemens Lang]

- On 3 Oct, 2015, at 19:53, Richard L. Hamilton rlha...@smart.net wrote:

>>  Is there something clever that could be done with mounts or hard (directory)
>>  links here?

Hard links will only work on the same filesystem, which is not necessarily the
case for all MacPorts installations. Additionally, they also link file metadata,
and thus the restricted flag.


> An NFS mount of self might work - the Mac NFS implementation doesn't seem to
> pass named attributes, and NFS protocol doesn't pass flags.  Thus:
> 
> sh-3.2$ ls -ldO@ /bin /net/localhost/bin
> drwxr-xr-x@ 42 root  wheel  restricted,hidden 1428 Oct  2 04:41 /bin
>   com.apple.FinderInfo  32
>   com.apple.rootless 0
> drwxr-xr-x  42 root  wheel  - 1428 Oct  2 04:41
> /net/localhost/bin
> 
> 
> Same thing, but as seen in the 2nd case, no com.apple.rootless attribute, no
> restricted (or hidden) flags. :-)

Mounts are a nice idea, but not possible without root privileges, and that 
leaves
out everybody that uses a user-only installation of MacPorts. So this could only
be done as an optimization, and I'm not sure it's worth it then. Cache
invalidation would definitely be easier with it, though…

-- 
Clemens Lang
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Darwin Version

[Dave Horsfall]

On Sat, 3 Oct 2015, Rainer Müller wrote:

> What should we change on the wiki page to make it more clear?
> This is an honest question. I am open to suggestions.

You cannot force the sheeple to read the instructions.

"Warning: this gun will blow your foot off if you point it that way."

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Darwin Version

[Sven Kolja Heinemann]

Where is the security benefit from this, that Apple wants to Achieve?

> Am 03.10.2015 um 22:30 schrieb Richard L. Hamilton :
> 
> But it's so easy to test that theory::-)
> sh-3.2# dtruss /bin/sh
> dtrace: failed to execute /bin/sh: dtrace cannot control executables signed 
> with restricted entitlements
> sh-3.2# dtruss /net/localhost/bin/sh
> sh-3.2# SYSCALL(args)  = return
> thread_selfid(0x0, 0x0, 0x0)   = 867702 0
> csops(0x0, 0x0, 0x7FFF563BF720)= 0 0
> issetugid(0x0, 0x0, 0x7FFF563BF720)= 0 0
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Darwin Version

[Brandon Allbery]

I should note that that's just an example; libSystem has only changed that
way once, I think. But the same applies to other Apple-only frameworks,
which change more often and more radically. Apple also has no qualms about
removing old frameworks they don't care about any more, in which case your
old 10.5 programs relying on those frameworks *will* stop working (I think
they did that with QuickTime?).

Basically, if Apple cared they could make this stuff work. But they don't,
so migration becomes a major hassle.

On Fri, Oct 2, 2015 at 9:52 AM, Brandon Allbery  wrote:

> On Fri, Oct 2, 2015 at 9:31 AM, Bachsau  wrote:
>
>> Maybe. Seems like I'm just not getting what is technically causing these
>> problems. When libraries change, and it breaks a particular application,
>> why can't I recompile just that? And why would the build of a newly
>> installed port fail, just because there are other ports installed that were
>> compiled against older system libraries?
>
>
> Dependencies. Port X compiles against new libSystem, depends on port Y
> that was linked against old libSystem, link fails because it tries to bring
> in both versions and they conflict. (Keeping around old libSystem versions
> is how you can still run applications built for 10.5 on 10.10/10.11.)
>
> This doesn't happen on Linux because glibc is obsessive about maintaining
> backward compatibility interfaces, so the older program links against the
> current glibc and uses compatibility interfaces from it; this works even
> for libraries. Apple doesn't care about backward compatibility enough to do
> things that way.
>
> --
> brandon s allbery kf8nh   sine nomine
> associates
> allber...@gmail.com
> ballb...@sinenomine.net
> unix, openafs, kerberos, infrastructure, xmonad
> http://sinenomine.net
>



-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Darwin Version

[Ryan Schmidt]

On Oct 2, 2015, at 8:13 AM, Bachsau wrote:
> 
> Am 01.10.2015 um 16:08 schrieb Rainer Müller:
> 
>> It may appear to be still working right now, but there is no guarantee
>> that it will work at all. Even if it seems to be working now, later
>> updates will cause problems. For example updates will link to a
>> different set of new system libraries.
>> 
>> Although cumbersome, the migration procedure ensures that everything
>> keeps working after upgrading to a new OS X release.
> 
> What a crap is this? I've been using Arch Linux before and never needed to 
> recompile any third party software, just because system packages where 
> updated. Software that needs to be reinstalled / recompiled on every little 
> operating system upgrade is bad software.

A few things:

The migration steps only need to be followed on major OS upgrades, i.e. when 
the second number in the version number changes, e.g. OS X 10.10 Yosemite 
upgraded to 10.11 El Capitan. It is not needed for "every little operating 
system upgrade"; security updates and minor version number upgrades usually 
cause no problems for MacPorts.

We're trying to make MacPorts into a system that just works, and that means 
that when we discover common situations where MacPorts fails to work, we try to 
modify MacPorts so that users are less likely to encounter them. One of the 
common problems we discovered was when MacPorts is built on one version of OS X 
and used on another version of OS X. So now we prevent that, via the error 
message that caused you to begin this thread.

The way that MacPorts is built is similar to a lot of other unix software: 
first, a configuration program is run that determines how things are done on 
your OS. Then, the program is compiled, using that configuration. Then the 
program is installed. If you then later upgrade to a different major version of 
OS, the determinations made at configure time may no longer be true, so the 
program that was built may no longer work on your new OS. I can think of two 
cases when this has happened to MacPorts in the past. MacPorts uses OS X's curl 
library. I think it was in OS X 10.4 that Apple shipped a newer version of the 
curl library, and no longer shipped the older version that MacPorts used when 
it was built on OS X 10.3 or earlier. Therefore users upgrading from 10.3 to 
10.4 could no longer use MacPorts, because it tried to load a library that no 
longer existed. Another case occurred in OS X 10.9, when Apple stopped 
including the /usr/bin/gnutar program in OS X. MacPorts checks for a tar 
program at configure time, so MacPorts built on 10.8 or earlier would use 
/usr/bin/gnutar, but after upgrading to 10.9, that no longer exists, so 
MacPorts would fail to extract anything. The solution to both issues is to 
re-run the MacPorts configure-build-install process, or run selfupdate which 
does that for you, or download our pre-compiled installer package for your OS X 
version. These types of problems are the reason why MacPorts now checks whether 
the runtime OS X version matches the build-time OS X version, and refers you to 
the migration page if not.

The preceding examples concerned MacPorts itself, but since a lot of other unix 
software (the type of software that we distribute in MacPorts) builds itself in 
a similar way, this type of problem could easily be encountered in the ports we 
distribute as well. In addition, new versions of OS X offer new features. Some 
software may check for those features at build time and enable them if found. 
By using software built on an older OS X, you might therefore be missing out on 
some features. These are the kinds of reasons why MacPorts will check whether 
the runtime version of OS X matches the version of OS X that was in use when 
the port was installed, and considers the port outdated (i.e. a candidate to be 
rebuilt) if not.

When I said we want to make a system that just works, that also includes us 
wanting to reduce the amount of time we spend on technical support. So you are 
free to do what you like with MacPorts, and if you don't follow the migration 
instructions when we say you have to, it may work, but if it doesn't, and you 
ask us for help, we will not provide support for that configuration.


___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Darwin Version

[Chris Jones]

> On 2 Oct 2015, at 2:33 p.m., Bachsau  wrote:
> 
> 
>> Am 02.10.2015 um 15:24 schrieb Brandon Allbery :
>> 
>> If you don't like it, don't use OS X, because Apple is not going to change. 
>> It will break stuff as it sees fit. This is the price of living in Apple's 
>> world.
> 
> 
> Maybe. Seems like I'm just not getting what is technically causing these 
> problems. When libraries change, and it breaks a particular application, why 
> can't I recompile just that? And why would the build of a newly installed 
> port fail, just because there are other ports installed that were compiled 
> against older system libraries?

Oh sure, there may well be some ports, or combination of ports that could carry 
on working just fine. Its just the 'clean slate' approach as per the migration 
instructions are the only way to make sure all the potential issues are removed.

Frankly i do not see what the issue is with following the migration guide. Even 
on my old late 2008 MBPro it only took a few hours or so to do the complete 
rebuild. 

Chris

> ___
> macports-users mailing list
> macports-users@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-users
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Darwin Version

[Bachsau]

> Am 01.10.2015 um 16:08 schrieb Rainer Müller :
> 
> It may appear to be still working right now, but there is no guarantee
> that it will work at all. Even if it seems to be working now, later
> updates will cause problems. For example updates will link to a
> different set of new system libraries.
> 
> Although cumbersome, the migration procedure ensures that everything
> keeps working after upgrading to a new OS X release.

What a crap is this? I've been using Arch Linux before and never needed to 
recompile any third party software, just because system packages where updated. 
Software that needs to be reinstalled / recompiled on every little operating 
system upgrade is bad software.

smime.p7s
Description: S/MIME cryptographic signature
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Darwin Version

[Dominik Reichardt]

Calm down and complain to Apple

> Am 02.10.2015 um 15:13 schrieb Bachsau :
> 
> 
>> Am 01.10.2015 um 16:08 schrieb Rainer Müller :
>> 
>> It may appear to be still working right now, but there is no guarantee
>> that it will work at all. Even if it seems to be working now, later
>> updates will cause problems. For example updates will link to a
>> different set of new system libraries.
>> 
>> Although cumbersome, the migration procedure ensures that everything
>> keeps working after upgrading to a new OS X release.
> 
> What a crap is this? I've been using Arch Linux before and never needed to 
> recompile any third party software, just because system packages where 
> updated. Software that needs to be reinstalled / recompiled on every little 
> operating system upgrade is bad software.
> ___
> macports-users mailing list
> macports-users@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-users
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Darwin Version

[Brandon Allbery]

On Fri, Oct 2, 2015 at 9:13 AM, Bachsau  wrote:

> What a crap is this? I've been using Arch Linux before and never needed to
> recompile any third party software, just because system packages where
> updated. Software that needs to be reinstalled / recompiled on every little
> operating system upgrade is bad software.


Apple does not care what you think. There's a discussion of rootless on the
apple-x11 list where the number of OS X users who care about building
non-Apple software is stated (by an Apple employee) at around 0.001% ---
they aren't going to care what they break for you.

(The message doesn't seem to have been indexed yet, or I'd link it. Should
show up at http://lists.apple.com/archives/x11-users/2015/Oct/index.html)

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Darwin Version

[Brandon Allbery]

On Fri, Oct 2, 2015 at 9:19 AM, Brandon Allbery  wrote:

> On Fri, Oct 2, 2015 at 9:13 AM, Bachsau  wrote:
>
>> What a crap is this? I've been using Arch Linux before and never needed
>> to recompile any third party software, just because system packages where
>> updated. Software that needs to be reinstalled / recompiled on every little
>> operating system upgrade is bad software.
>
>
> Apple does not care what you think.
>

Also note that Homebrew spent last of year learning this the hard way,
after making the same assumption that this was some stupidity MacPorts came
up with just to make people's lives miserable.

Apple doesn't care; Apple doesn't have to care. If you don't like it, don't
use OS X, because Apple is not going to change. It will break stuff as it
sees fit. This is the price of living in Apple's world.

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Darwin Version

[Brandon Allbery]

On Fri, Oct 2, 2015 at 9:31 AM, Bachsau  wrote:

> Maybe. Seems like I'm just not getting what is technically causing these
> problems. When libraries change, and it breaks a particular application,
> why can't I recompile just that? And why would the build of a newly
> installed port fail, just because there are other ports installed that were
> compiled against older system libraries?


Dependencies. Port X compiles against new libSystem, depends on port Y that
was linked against old libSystem, link fails because it tries to bring in
both versions and they conflict. (Keeping around old libSystem versions is
how you can still run applications built for 10.5 on 10.10/10.11.)

This doesn't happen on Linux because glibc is obsessive about maintaining
backward compatibility interfaces, so the older program links against the
current glibc and uses compatibility interfaces from it; this works even
for libraries. Apple doesn't care about backward compatibility enough to do
things that way.

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Darwin Version

[Bachsau]

> Am 02.10.2015 um 15:24 schrieb Brandon Allbery :
> 
> If you don't like it, don't use OS X, because Apple is not going to change. 
> It will break stuff as it sees fit. This is the price of living in Apple's 
> world.


Maybe. Seems like I'm just not getting what is technically causing these 
problems. When libraries change, and it breaks a particular application, why 
can't I recompile just that? And why would the build of a newly installed port 
fail, just because there are other ports installed that were compiled against 
older system libraries?

smime.p7s
Description: S/MIME cryptographic signature
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Darwin Version

[Bachsau]

Brandon Allbery wrote on 02.10.2015 15:52:

Dependencies. Port X compiles against new libSystem, depends on port Y
that was linked against old libSystem, link fails because it tries to
bring in both versions and they conflict. (Keeping around old libSystem
versions is how you can still run applications built for 10.5 on
10.10/10.11.)

This doesn't happen on Linux because glibc is obsessive about
maintaining backward compatibility interfaces, so the older program
links against the current glibc and uses compatibility interfaces from
it; this works even for libraries. Apple doesn't care about backward
compatibility enough to do things that way.



Thanks for this detailed answer. I might have been somewhat rude because 
I just didn't fully understand what the problem is. One reason I don't 
like the idea of recompiling everything is time, the other one being 
that I did some things to integrate macports into my system, like 
setting my shell to its bash and prefering it in /etc/paths, probably 
some other things I don't remember yet. I just wanted to avoid some trouble.

___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Darwin Version

[Clemens Lang]

Hi,

- On 2 Oct, 2015, at 15:33, Bachsau w...@bachsau.name wrote:

> Maybe. Seems like I'm just not getting what is technically causing these
> problems. When libraries change, and it breaks a particular application, why
> can't I recompile just that? And why would the build of a newly installed port
> fail, just because there are other ports installed that were compiled against
> older system libraries?

There are changes that can be done by Apple with OS upgrades that will render
your currently installed libraries useless. Examples for changes that are of
this nature are:
  - Apple changing CPU architecture
  - Apple changing the ABI of a library you link against (e.g. when moving
to C++11 using libc++)
  - Apple no longer shipping a certain library
This can leave you with binaries or libraries that no longer work. If a build
system now picks up one of these broken binaries or libraries (that does happen,
especially with missing architectures from universal binaries or missing
libraries), your binary will crash during the build or the build will fail to
link against a library. This will make your rebuild fail.

Of course, anything that is needed for a build should be in the list of
dependencies of a port, and should thus get rebuilt before the port in question,
avoiding the problem. Reality is different, however: build systems like cmake
and autotools look for optional dependencies all over the place and try to use
them if found, even if they are not in the list of dependencies, which leads to
these problems.

In theory, we have a solution for this problem: trace mode hides anything from
a port's build system that doesn't come with the system and is not in the list
of dependencies, so *in theory* we could replace migration with
  sudo port -t upgrade outdated,
and in fact, I successfully tested this during the last OS upgrade. With the
upgrade to El Capitan, though, Apple's System Integrity Protection actually
breaks trace mode (Yay!), so this not an option, leading us to recommend the
migration procedure.

So yes, careful thought has been given to the problem at hand, I agree it's
annoying, but given the way Apple handles things, there are currently no other
options.

-- 
Clemens Lang
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Darwin Version

[William H. Magill]

> On Oct 2, 2015, at 10:33 AM, Ryan Schmidt  wrote:
> 
> On Oct 2, 2015, at 8:13 AM, Bachsau wrote:
>> 
>> Am 01.10.2015 um 16:08 schrieb Rainer Müller:
>> 
>>> It may appear to be still working right now, but there is no guarantee
>>> that it will work at all. Even if it seems to be working now, later
>>> updates will cause problems. For example updates will link to a
>>> different set of new system libraries.
>>> 
>>> Although cumbersome, the migration procedure ensures that everything
>>> keeps working after upgrading to a new OS X release.
>> 
>> What a crap is this? I've been using Arch Linux before and never needed to 
>> recompile any third party software, just because system packages where 
>> updated. Software that needs to be reinstalled / recompiled on every little 
>> operating system upgrade is bad software.
> 
> A few things:
> 
> The migration steps only need to be followed on major OS upgrades, i.e. when 
> the second number in the version number changes, e.g. OS X 10.10 Yosemite 
> upgraded to 10.11 El Capitan. It is not needed for "every little operating 
> system upgrade"; security updates and minor version number upgrades usually 
> cause no problems for MacPorts.
> 
> We're trying to make MacPorts into a system that just works, and that means 
> that when we discover common situations where MacPorts fails to work, we try 
> to modify MacPorts so that users are less likely to encounter them. One of 
> the common problems we discovered was when MacPorts is built on one version 
> of OS X and used on another version of OS X. So now we prevent that, via the 
> error message that caused you to begin this thread.
> 
> The way that MacPorts is built is similar to a lot of other unix software: 
> first, a configuration program is run that determines how things are done on 
> your OS. Then, the program is compiled, using that configuration. Then the 
> program is installed. If you then later upgrade to a different major version 
> of OS, the determinations made at configure time may no longer be true, so 
> the program that was built may no longer work on your new OS. I can think of 
> two cases when this has happened to MacPorts in the past. MacPorts uses OS 
> X's curl library. I think it was in OS X 10.4 that Apple shipped a newer 
> version of the curl library, and no longer shipped the older version that 
> MacPorts used when it was built on OS X 10.3 or earlier. Therefore users 
> upgrading from 10.3 to 10.4 could no longer use MacPorts, because it tried to 
> load a library that no longer existed. Another case occurred in OS X 10.9, 
> when Apple stopped including the /usr/bin/gnutar program in OS X. MacPorts 
> checks for a tar program at configure time, so MacPorts built on 10.8 or 
> earlier would use /usr/bin/gnutar, but after upgrading to 10.9, that no 
> longer exists, so MacPorts would fail to extract anything. The solution to 
> both issues is to re-run the MacPorts configure-build-install process, or run 
> selfupdate which does that for you, or download our pre-compiled installer 
> package for your OS X version. These types of problems are the reason why 
> MacPorts now checks whether the runtime OS X version matches the build-time 
> OS X version, and refers you to the migration page if not.
> 
> The preceding examples concerned MacPorts itself, but since a lot of other 
> unix software (the type of software that we distribute in MacPorts) builds 
> itself in a similar way, this type of problem could easily be encountered in 
> the ports we distribute as well. In addition, new versions of OS X offer new 
> features. Some software may check for those features at build time and enable 
> them if found. By using software built on an older OS X, you might therefore 
> be missing out on some features. These are the kinds of reasons why MacPorts 
> will check whether the runtime version of OS X matches the version of OS X 
> that was in use when the port was installed, and considers the port outdated 
> (i.e. a candidate to be rebuilt) if not.
> 
> When I said we want to make a system that just works, that also includes us 
> wanting to reduce the amount of time we spend on technical support. So you 
> are free to do what you like with MacPorts, and if you don't follow the 
> migration instructions when we say you have to, it may work, but if it 
> doesn't, and you ask us for help, we will not provide support for that 
> configuration.

I’m now retired after 30+ years “playing” in the Unix(tm) vineyards at a major 
research university - DEC, UNIVAC, ATT, Compaq, HP, IBM, Apple, OSF/1, System 
V, and too many versions of Linux to name, just to name a few.  Every version 
of Unix(tm) from every vendor has had and has this release problem.

Some vendors mad “backwards compatibility a priority. Most did not — upgrade 
the OS, switch vendors, work cross-platform - you were on your own.

> On Oct 2, 2015, at 10:00 AM, Brandon Allbery  

Re: Darwin Version

[Bachsau]

William H. Magill wrote on 02.10.2015 17:21:

Some vendors mad “backwards compatibility a priority. Most did not — upgrade 
the OS, switch vendors, work cross-platform - you were on your own.


Sadly this this is true, even though it wouldn't have to.


It’s Apple’s way or the highway. They know what is best for you.


True, but it wouldn't be better without it, as you know by yourself. It 
has some downsides, but on the other hand, Apple enforces a clear line 
so everything inside their universe works smoothly together. Microsoft 
for a long time didn't, and as we can see nothing worked together. Every 
software does everything on it's own. Every Mailer and Messenger has its 
own contact list and bookmarks. Everything uses its own protocol. 
Nothing is in sync. Same applies to Linux, especialy in times when 
freedesktop.org didn't exist to propose some standards.



Without MacPorts, you would have to figure out why XXX suddenly no longer 
worked and then try to fix it all by yourself.
And that utterly ignores the fact that you would have had to have ported the 
software to your situation all by yourself.


You are also right on this. When I began to use a mac, I thought that 
Apple would care more about the unix base and compatibillity. As an 
everyday Linux user, I'm used to do much things through a command line. 
It would be almost impossible for me to get everything I used to work 
with working on my Mac's console without macports.

___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Darwin Version

[Dave Horsfall]

On Fri, 2 Oct 2015, Dominik Reichardt wrote:

> Calm down and complain to Apple

I've found that Penguin/OS users have a rather blinkered view of the real 
world; they seem to think that they invented Unix, for example.

Personally, I'm a BSD bigot; at least the Mac is FreeBSD-based.

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."
  Yet another mass shooting in America; turning now to other news...
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Darwin Version

[Rainer Müller]

On 2015-10-01 15:43, Bachsau wrote:
> Hi, could anyone please tell me where MacPorts saves on which
> operating system version it was installed, so i can bump it? It says
> "Current platform 'darwin 15' does not match expected platform
> 'darwin 14'". I read the Migration instructions, but sorry. No. It is
> idiotic to reinstall all of my stuff. I'm pretty sure that if I could
> get rid of that useless message, everything would work pretty well.

It may appear to be still working right now, but there is no guarantee
that it will work at all. Even if it seems to be working now, later
updates will cause problems. For example updates will link to a
different set of new system libraries.

Although cumbersome, the migration procedure ensures that everything
keeps working after upgrading to a new OS X release.

Rainer
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Darwin Version

[Bachsau]

Hi, could anyone please tell me where MacPorts saves on which operating system 
version it was installed, so i can bump it? It says "Current platform 'darwin 
15' does not match expected platform 'darwin 14'". I read the Migration 
instructions, but sorry. No. It is idiotic to reinstall all of my stuff. I'm 
pretty sure that if I could get rid of that useless message, everything would 
work pretty well.

smime.p7s
Description: S/MIME cryptographic signature
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Darwin Version

[Brandon Allbery]

On Thu, Oct 1, 2015 at 9:43 AM, Bachsau  wrote:

> sorry. No. It is idiotic to reinstall all of my stuff.


If you like random incomprehensible link failures, sure, fake it all you
want, it's in the registry. Don't be surprised when things break, since you
chose to let them break.

The Migration instructions are there for a reason. Ignore them at your
peril.
Apple changes system libraries as it chooses, not as how MacPorts would
prefer. This means things DO break on OS upgrades, by Apple's whim.

To be clear: compiled programs still work. Apple is careful to let that
work. Libraries are another story entirely, the next thing you try to
compile will almost certainly fail because the system libraries are
different from what they were built against.

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users