Re: Debian packages for Mac-on-Linux in incoming
Hi,
Ethan Benson writes:
> in this case presuming you ask the user via debconf where thier
> macos partition is and you manage to copy the ROM over yourself, and
> be sure to remove it on package removal (--purge?) then /usr/lib/mol
> would be fine.
That's what I had in mind. As for the details ...
> 1) ask user where their MacOS partition is
> 2) try to determine whether its HFS or HFS+ (this could be hard since
> HFS+ is wrapped in HFS)
> 3) use hfsutils (HFS) to copy :System\ Folder:Mac\ OS\ ROM to
> /usr/lib/mol, or hfsputils to copy :System\ Folder:Mac\ OS\ ROM to
> /usr/lib/mol.
... there are a few pitfalls in each of these steps. I'm working on
them. In the meantime, the package will simply ask for the location
of an already extracted Mac OS ROM file in the Linux filesystem.
> hfsputils are the HFS+ versions of hfsutils (not yet debian packaged
> AFAIK) they currently work ok for simple read-only operations so it
> may be sufficient if you packaged and depended on them.
I packaged and uploaded them as hfsplus, libhfsp0 and libhfsp-dev a
while ago. I'm reluctant to make mol dependent on them, because there
are people not using HFS+ for their startup volumes. Recommendation
might be fine, though.
> this isn't foolproof since MacOS does allow the user to move or rename
> the System\ Folder to whatever/wherever the hell they feel like it,
> though i have known very few who actually do that.
Actually, the System Folder has a different name for each localised
version of MacOS. The name Mac OS ROM for the image is always the
same. And the ultimate way of locating the thing is the tbxi/chrp
type/creator. Unfortunately, searching for type/creator on a whole
volume is pretty messy with existing Linux programs.
I'll put `write a tool to grab all tbxi/chrp files from an HFS/HFS+
volume' onto my TODO list ...
> there is also the issue of MacOS upgrades, if MacOS is upgraded and
> its ROM replaced it will crash the next time mol is run since it
> deals with mismatched ROMs very poory.
> ultimatly the user just has to know about this
We could at least warn her.
Regards, Jens.
--
J'qbpbe, le m'en fquz pe j'qbpbe!
Le veux aimeb et mqubib panz je pézqbpbe le djuz tqtaj!
Reply to: