Re: [gentoo-osx] The road ahead?

> > An app folder contains starting scripts and the related resources /
libraries
> > in an all in one package. The idea is that you can copy an app folder
> > around in your local file system or to another file system (thing .dmg
here),
> > while the application still remains runnable. So you have to include any
> > library, beside the Apple provided ones.

> Two problems with your logic:

> 1) The affirmation that all the libraries every .app needs are
> included in .app folders is false.  Check out /Library and
> /usr/lib--you will find that they are not even close to empty.  .app's
> depend heavily on having a relatively stable OS X system out there to
> support it.  Try dragging Mail.app from a Tiger installation onto a
> Jaguar installation and see if it works.

You are right about that not everything is included. SO I still think
there must exist a set of libraries which are shared across several MacOS
version.
The question is if these set is somewhere documented, and how reliable
this portability is.
But it still is possible to create .app folders which run on several
MacOSX versions. Apple Mail may or maybe not a shining example for this.

> 2) I think you dragged out the "GUI is/isn't just a frontend to the
> CLI" issue to try to argue for app-like organization of files.
> They're not the same issue.  Let's face it: one of the main reason's
> portage exists is to easily manage compiling/installing packages in a
> nice orderly way without going upstream to all the projects you are
> using and somehow forcing them all to recode their projects so they
> work in an app-like organization.

- Yes, both issues are separate
- No, I don't think any Gentoo package is suited for an app folder.
- Yes, normally I am fine with a global namespace, too. However, there exist
  reasons that I would like to create an .app folder for special
applications.
- In fact the "GUI is/isn't just a frontend to the CLI" argument I see
more as a
  problem for the prefixed approach. If I am able to start an application
from
  the GUI / Finder, I cannot be sure which .{shell}rc is executed, and so
which
  non-standard places are accessible to an application starter. When I try to
  start an application which tries to load its libraries from e.g.
/sw/lib, I am not
  quite sure about the results
- From what I understood, .app folder don't really need much work from the
  upstream developers. It should be sufficient to specify the correct
paths, at
  least if a proper build tool is used. I am not quite sure, but I think .app
  folders mostly work because of linker magic, i.e.  some conventions about
  where libraries are places relatively to the app folder root.

>  Even assuming you DID get portage to force things into .app
> structures and work perfectly, the moment you dragged it to another
> system without the exact same versions of compiled gentoo libraries,
> you're hosed.

I thought that was the reason for some magic concept like source and
especially binary compatibility for a given library?

> Don't get me wrong, I think the whole app idea is awesome.  .app's can
> and have been created for OSS (Carbon Emacs, for example), but if
> you're going to go to all the trouble to create a real .app, there's
> no need for a special package manager (portage) just to copy it into
> your /Applications folder.

I think the use cases are different. A pure portage based system is fine
as long as you have a running Gentoo system, or you are willing to take
the plunge.
An app folder is fine if you want to deploy an emerged application to a
system which has no Gentoo running (an example would be the Mac system of
my parents. I would really like being able to show off some recent version
of, say, Abiword compiled for MacOS, without having to download a special
version from the Abiword developer's site)

> > From what I see, fink-commander is a frontend to fink, i.e. to the
> > packages, not to the actual applications. Last time I checked, a
gentoo or
> > fink package has no concept about which are the actual executables.

> Splitting hairs.  If you make it, then have it do what you want it to do.

I don't think such a system which automatically creates startable
applications, would be possible right now in Gentoo. There is too much
missing metadata in the Gentoo system for such a task.

> You are free to use Apple gcc -- that's what it's on your system for.
> However, gentoo stuff specifically depends on the features, quirks,
> and even bugs in its own supported toolchain, including gcc.  Once
> there is a "stable, working" version of gentoo-osx, don't expect a lot
> of sympathy from gentoo devs if you're not going to use standard
> gentoo toolchain.  I certainly wouldn't object if a way was found to
> use any of Apple's tools, especially if they are better in some way,
> but I'm not going to hold my breath.

While I may agree about special Apple tools like Xcode (vs Gentoo
./configure/make/make install), I don't think this applies for the actual
C compiler. I think even in the stock Gentoo toolchain there is the
distinction between gcc-3 and gcc-4, where each individual Gentoo
installation decides which version too use. Apple's gcc-4 is (or should
be?) just another option for a C compiler, at least as long as no Apple
specific features are used (think e.g. support for ObjectiveC++ support)

> > No. manually installing the packages which are needed to emerge the
> > actual wanted packages. The latter are still emerged via Gentoo.

> Portage exists to automate (and customize) manual installs.  If you
> can find a way to manually install it correctly, and the ebuild in
> portage can't, then the solution is to fix the ebuild so that it works
> for everyone.

As long as I can coerce Gentoo to actually emerge a package, everything is
fine. The problems start if this is not possible (for a variety of
reasons)

Regards
Dirk






-- 
gentoo-osx@g.o mailing list