From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.50) id 1EX1yV-0007kX-Ai for garchives@archives.gentoo.org; Tue, 01 Nov 2005 19:39:15 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.5/8.13.5) with SMTP id jA1JbqIp018484; Tue, 1 Nov 2005 19:37:52 GMT Received: from smtp.sz-online.de (smtp.sz-online.de [193.98.117.121]) by robin.gentoo.org (8.13.5/8.13.5) with SMTP id jA1Jbpwj022032 for ; Tue, 1 Nov 2005 19:37:51 GMT Received: (qmail 6696 invoked from network); 1 Nov 2005 19:35:25 -0000 Received: from smtp.sz-online.de (HELO mail.sz-online.de) (193.98.117.121) by smtp.sz-online.de with SMTP; 1 Nov 2005 19:35:25 -0000 Received: from 84.179.3.188 (SquirrelMail authenticated user dirk.schoenberger) by mail.sz-online.de with HTTP; Tue, 1 Nov 2005 20:35:25 +0100 (CET) Message-ID: <62160.84.179.3.188.1130873725.squirrel@mail.sz-online.de> Date: Tue, 1 Nov 2005 20:35:25 +0100 (CET) Subject: Re: [gentoo-osx] The road ahead? From: dirk.schoenberger@sz-online.de To: "gentoo-osx@lists.gentoo.org" User-Agent: SquirrelMail/1.4.2 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-osx@gentoo.org Reply-to: gentoo-osx@lists.gentoo.org MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal X-Archives-Salt: 25297beb-cc13-476b-a776-22a5e7b795b2 X-Archives-Hash: d00b36f5ab4a5cad3247d04bbcdc10e9 > > 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@gentoo.org mailing list