Re: [gentoo-osx] The road ahead?

[Nathan]

On 11/1/05, dirk.schoenberger@×××××××××.de
<dirk.schoenberger@×××××××××.de> wrote:
>
> >> I see this as an advantage above e.g. Fink, with its own namespace. The
> >> namespace variant implies that I have to fudge around with PATH
> >> variables
> >> and other CLI stuff, in order to get the apps working. I still have no
> >> real MacOSX integration, with App folder and GUI starter elements (which
> >> would be my biggest feature request)
> >
> > I see not trashing the existing system software as far more important
> > than the minor configuration of your path.  This is Gentoo!  What "App
> > folder" are you expecting?  KDE menus, Gnome menus, etc. are basically
> > fancy widgets that execute CLI commands when you click on them.
>
> Sorry, but this attitude firmly belong into the "a GUI is just a frontend
> to the CLI" camp, where I don't really subscribe too. A CLI has its place,
> but a GUI does so, too, and both are not dependent upon.
> KDE / GNOME .desktop entries doesn't really compare to Apple's app
> folders, because .desktop entries are really just start scripts. 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.

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.  The .app concept is great, but
you'll be on your own to go to every separate pre-existing project and
convince them to port it so that it install itself into .app
organization and runs.  The whole .app thing has to be addressed by
the people who code the applications, and can't be imposed by portage.
 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.

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.  Creating an Apple-style app seems to be
painful enough that most OSS projects will fork into separate regular
and app-oriented projects rather than support the .app structure in
the main line.

> > If you need something to click on for your own sanity, the logical thing
> > for you to do would be to create some scripts in /Applications that
> > call the X apps you use when you click on them, assuming you got the X
> > apps installed in the first place. I wouldn't be surprised if someone
> > came up with a fink-commander-like project for OS X (to install and
> > run stuff) if the prefixed-installs-hurdle ever gets passed.
>
> 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.

> >> 2) packages which clash with MacOS provided packages, things like python
> >> or automake spring to mind
> >
> > And bash, ls, grep, emacs, vi, vim, gcc, perl, python, tcl/tk, apache,
> > etc. etc. etc.
>
> python and automake are the cases which really annoy me, but naturally you
> are correct about the other packages, too. If possible I would like to use
> an Apple provided gcc, so this package is disputable.

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.

> >> The biggest problem is obiously the packages in 2)
> >
> > Which prefixed installs will solve.  When portage fully supports
> > prefixed installs, then:
> > (1) A base system gets created by devs by whatever means (hopefully
> > the only step with mandatory dependencies on Apple tools)
> > (2) Regular users install the prefix-enabled base system into a prefix
> > (and add $PREFIX/bin, $PREFIX/sbin, etc. to .bashrc)
> > (3) 'emerge mypackage' uses the gentoo system in $PREFIX to build
> > 'mypackage' and install in into
> > $PREFIX/regular/gentoo/path/for/the/package
> > (4) USERS REJOICE!
> > (5) At this point, I'm sure someone will start a 'fink-commander'-like
> > project for people who aren't comfortable with the command-line
> >
>
> Maybe I am just not in possession of all the facts, so I will stop
> expressing an opinion about this as long as there are no visible results.

Opinions are fine.  I'm trying to clarify facts as much as I can and
as far as I understand them.  The more gentoo users/devs/supporters,
the better, because then I will have an easier time getting 'my stuff'
to work. :-)

> > Manually "install" packages whose dependencies won't install?  I think
> > you have missed the concept that the dependencies are necessary to
> > both compile and run the package.
>
> 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.

-- 
gentoo-osx@g.o mailing list