Re: [Fink-devel] .apps in fink

[Max Horn]

The problem in this discussion is that there are very different basic assumptions made by the various parties. I don't believe that we can get to an agreement, ever. Bill and Ben consider some things for important which I don't consider important at all, and vice versa. I don't actually believe that either of us is right, it's just that, depending on your situation, your set of believes etc., you have a different point of view.

I see no way for us to agree, only maybe a chance to come to a common compromise, though I don't really see that yet.

Moving apps around: you say we should forget it, trust users "not to be so stupid to do it", and that it's not possible to do that in network location / multi user machines anyway. And furthermore, you claim that every Mac is a MU machine nowadays anyway.

I see it completly opposite: Moving applications around is for me an integral part of my Mac user experience which I don't want to miss, and I know many people that share that view. That apps like Mail.app etc. don't allow is IMHO not at all a justification, just like the fact that there are many thieves in the world doesn't mean it's ok for me to steal stuff: Apple made a step backwards there, which I am not happy about it, although I have to live with it.

Most mac users that I know don't use their macs as MU machines; a few use the MU capabilities to host accounts for wives/friends/kids, but in all cases they have the admin rights, while the other accounts don't have.

I know that there are e.g. computer labs that use Macs and they relay on the MU capabilities much more (although I don't know any myself, given the fact that the market share of the mac over here is even lower than in the US, and is about 0% in the education sector, this is not a big surprise).


Nobody is "right" here, it's just two (or more) very different user profiles.



Unix applications and unix ways of thinking are very contrary to Mac apps and ways of thinking. Trying to merge them is something were you have to be careful, or you end up combining the bad parts of the one with the worse parts of the other. This is one reason why I am opposed to e.g. distributing Fire.app with Fink: you get the bad pars of the unix way (not being able to move your application, for example, a reduction of your freedoms) and the non-trivial install/deinstall (normal install: copy to your HD; normal deinstall: move to trash); but what you gain is... what? the ability to compile it yourself? that is already trivial, download it or get it from their CVS, and compile it. And avarage joe user actually isn't interested in compiling it himself, he'll prefer the binary download anyway.

TCL/Tk is on the border: it's mostly interesting because of the libraries anyway. Wish.app is the only app part in it (or it used to be like that, somebody correct me if there is more these days), which should be OK, since normally the user doesn't have to see that anyways

Applications like FilmGimp, should be really ported, that is, ship like mac apps.


Some of you might agree, some may scream in outrage at what I write here. Some will maybe think I am stupid or boneheaded, which is your good right as free man. I, for my part, know that in a complex world as our, different opinions exist, and unlike the nice computer boolean logic which has only true and false, there are not just correct and incorrect positions; indeed it is possible for two diametral opposed opinions to be valid at the same time.


Anyway, this doesn't bring us much nearer to a solution. I don't like the idea of faking moveable apps with symlinks, that's IMHO utterly useless. If we decided to go for Apps, and hope that having them owened by root is sufficient to ensure they stay in place, then we may as well leave it to the user to create symlinks/aliases at their disposition.


It is acceptable to package selected .apps on a case-by-case base today already (otherwise you wouldn't see XDarwin.app and AquaTerm). This might be acceptable for other things, too, on a case-by-case basis. However, I am currently quite strongly opposed to allowing this on a broad basis.


We will never get a solution that makes us all happy, at least either Bill or me will be unsatisfied; we can only work to get to a compromise.

My suggestion is this: you compile a list of applications you think should be package in FInk. We then can go through them in a case by case basis. I am willing to agree to applications being packaged if there is a clear advantage for this compared to normal distribution, and if there is no sever disadvantage of it compared to normal distribution of that app.

This is e.g. the case of XDarwin.app: most of its files are fixed in location anyway, so (almost) nothing is lost); OTOH since its important for so many packages, and since it's easy to update this way, and since we can fine tune it, there are clear advantages for it to be a Fink package.

FinkCommander: I doN't see such a big advantage of having it a FInk package, frankly. No no, not because I doN't use it, that's not the point I want to get to (I am not that egoistic :-). What I mean is: installing it right now is already easy for endusers. What I would think to be much more interesting would be to kind of bundle FinkCommander and Fink, so that users install both of them in one go. For if it was just a Fink package, then users would first have to figure out how to steer Fink manually, so they can install FC. That's IMHO harder for them than to just download it, as it is right now.



Max
--
-----------------------------------------------
Max Horn
Software Developer


-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel