On Mar 10, 2021, at 05:26, joerg van den hoff wrote:
> On 09.03.21 18:41, Ryan Schmidt wrote:
>> On Mar 9, 2021, at 11:34, joerg van den hoff wrote:
>>> so I find this strange: seemingly everything is just fine (macports user
>>> and its home dir exists etc.) but I get that "cannot change owner: no
>>> macports user" warning nonetheless. so this looks like OSX had not a
>>> consistent view of the state of affairs across different utilities at that
>>> point? notably `dscl' knowing that user is not sufficient? what, then, is
>>> the reliable/correct way to decide whether a user account "really" exists?
>>> but whatever ...
>> I'm sorry, I don't know and I can't completely explain what you've observed.
>>> understood. will try to recall the procedure in due time when doing another
>>> migration to a new machine...
>> No need to recall anything since it's documented in
>> https://trac.macports.org/wiki/Migration. That document is geared toward
>> migrating from one OS version or architecture to another, but it could be
>> enhanced to address the case of migrating from one machine to another while
>> keeping the same OS version and architecture. If you'd like to make those
>> enhancements feel free; anyone can edit the wiki.
>
> well, I might try that. at least it seems not true that for said type of
> migration (same OS/arch) one needs to first nuke the macports installation.
> from the current migration page: "Note: If you move from one Mac to another
> Mac using ​Migration Assistant, you have to do it ["it" meaning uninstall
> MacPorts] first."
That sentence is meant to be taken in context of the rest of the page, which is
currently all about the need to reinstall MacPorts and ports when migrating
from one OS version or arch to another.
If you're moving from one Mac to another where both have the same OS version
and arch, then you don't need to do anything to fix MacPorts; your existing
MacPorts installation will work just fine if you copy everything correctly. For
example, using a cloning utility like Carbon Copy Cloner copies everything
correctly.
Migration Assistant does not copy everything correctly. It does not preserve
the correct home directory location of the macports user nor of any of the user
accounts that MacPorts ports might create. So if you use Migration Assistant,
then you will have to take additional steps afterward. Either you have to
exclude those accounts from migration and recreate them afterward, or if you
did not exclude the user accounts then you have to fix their home directories
afterward.
> OTOH I am not quite sure _what_ to recommend: my "strategy" was
>
> 1. migrate everything offered by Migration Assistant _except_ the macports
> user's account.
>
> 2. reinstall MacPorts from dmg image
>
> so I could write something to that extent into the wiki if it helps...
>
> but I am not at all sure what would have happened if I had done it the way
> you suspect to be better:
You misread me. I agreed with you that *not* migrating the macports user was
the easiest way to do it, provided that you recreate the user later by
re-running the MacPorts installer.
If you instead *did* migrate the macports user, then Migration Assistant will
have messed it up and it would need to be fixed.
> 1. migrate everything offered by Migration Assistant _including_ the macports
> user's account (whose home dir than is moved apparently to /Users in the
> process)
>
> 2. mv macport home dir back into the /opt/local tree
>
> open questions would be: how exactly? with what permissions? does that really
> yield a working MacPorts installation or would the same warning result I have
> seen ("no macports user") and which necessitated reinstall of MacPorts from
> the dmg image?
If you tell Migration Assistant to migrate a user account, it will migrate the
user account. That means the user account and its home directory will exist on
the new system. Migration Assistant will relocate the user's home directory
into /Users, which is inappropriate for the macports user and all of the user
accounts that ports might create, therefore you will need to undo those changes
manually later. To do that, for each affected user account, you need to:
1. mv the home directory from /Users/whatever to where it was supposed to be,
and
2. use the dscl command to fix the user's NSHomeDirectory entry to match where
the home directory now is.
For the macports user this is easy enough since we know that its home directory
is /opt/local/var/macports/home. But for all of the other user accounts, you
would need to read that port's Portfile to figure out where its home directory
is supposed to be.
If you tell Migration Assistant *not* to migrate a user account, it will not
migrate the user account. That means the user account will not exist on the new
system. I am not certain whether the user's home directory would be copied. It
seems like it should not be, but I can't test it right now.
I think it would be a good idea if the migration wiki page specifically
mentioned this problem of the Migration Assistant. I would probably have the
page recommend not to migrate MacPorts-related user accounts and instead
recreate them after migration. To recreate the macports user, re-run the
MacPorts installer. To recreate users and home directories created by any port,
reinstall that port (sudo port -n upgrade --force portname). Users might want
to look into the home directories of each MacPorts-created user before
migration to make sure there's nothing important in there in case it does not
get copied.
Many users will not be aware of the problem until after migration is complete,
so we should also describe how to recover from a migration where the user
accounts were migrated and relocated.
`port diagnose` should probably be modified so that it detects any home
directories that were misrelocated to /Users and warns the user about it,
perhaps referring them to the future version of the Migration page for help in
fixing it.
Maybe an even nicer idea: Whenever MacPorts creates a user account, it could
record its home directory in a new table in the registry. `port diagnose` could
check if any home directory doesn't match what we recorded and offer a way to
set it back. Or this could become part of the unfinished `port migrate` command
(https://trac.macports.org/ticket/56019) (or maybe it already includes this; I
don't know).
