You can subscribe to this list here.
2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(182) |
Nov
(548) |
Dec
(347) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
(695) |
Feb
(397) |
Mar
(438) |
Apr
(544) |
May
(367) |
Jun
(273) |
Jul
(160) |
Aug
(247) |
Sep
(204) |
Oct
(308) |
Nov
(467) |
Dec
(406) |
2003 |
Jan
(795) |
Feb
(532) |
Mar
(355) |
Apr
(375) |
May
(352) |
Jun
(312) |
Jul
(290) |
Aug
(157) |
Sep
(130) |
Oct
(261) |
Nov
(532) |
Dec
(480) |
2004 |
Jan
(445) |
Feb
(433) |
Mar
(323) |
Apr
(259) |
May
(126) |
Jun
(175) |
Jul
(219) |
Aug
(286) |
Sep
(178) |
Oct
(144) |
Nov
(141) |
Dec
(133) |
2005 |
Jan
(148) |
Feb
(263) |
Mar
(224) |
Apr
(186) |
May
(283) |
Jun
(243) |
Jul
(138) |
Aug
(124) |
Sep
(109) |
Oct
(90) |
Nov
(295) |
Dec
(164) |
2006 |
Jan
(201) |
Feb
(221) |
Mar
(221) |
Apr
(157) |
May
(87) |
Jun
(131) |
Jul
(97) |
Aug
(93) |
Sep
(174) |
Oct
(112) |
Nov
(208) |
Dec
(166) |
2007 |
Jan
(188) |
Feb
(140) |
Mar
(121) |
Apr
(105) |
May
(95) |
Jun
(131) |
Jul
(131) |
Aug
(72) |
Sep
(152) |
Oct
(116) |
Nov
(222) |
Dec
(237) |
2008 |
Jan
(160) |
Feb
(106) |
Mar
(266) |
Apr
(263) |
May
(150) |
Jun
(140) |
Jul
(224) |
Aug
(119) |
Sep
(105) |
Oct
(103) |
Nov
(71) |
Dec
(52) |
2009 |
Jan
(67) |
Feb
(39) |
Mar
(73) |
Apr
(171) |
May
(113) |
Jun
(90) |
Jul
(160) |
Aug
(129) |
Sep
(270) |
Oct
(117) |
Nov
(88) |
Dec
(97) |
2010 |
Jan
(105) |
Feb
(59) |
Mar
(219) |
Apr
(157) |
May
(128) |
Jun
(168) |
Jul
(87) |
Aug
(100) |
Sep
(95) |
Oct
(50) |
Nov
(61) |
Dec
(31) |
2011 |
Jan
(78) |
Feb
(158) |
Mar
(85) |
Apr
(95) |
May
(50) |
Jun
(37) |
Jul
(66) |
Aug
(24) |
Sep
(50) |
Oct
(79) |
Nov
(79) |
Dec
(51) |
2012 |
Jan
(75) |
Feb
(53) |
Mar
(59) |
Apr
(71) |
May
(78) |
Jun
(90) |
Jul
(83) |
Aug
(74) |
Sep
(82) |
Oct
(35) |
Nov
(10) |
Dec
(22) |
2013 |
Jan
(34) |
Feb
(35) |
Mar
(17) |
Apr
(6) |
May
(27) |
Jun
(53) |
Jul
(27) |
Aug
(19) |
Sep
(23) |
Oct
(58) |
Nov
(68) |
Dec
(24) |
2014 |
Jan
(29) |
Feb
(5) |
Mar
(22) |
Apr
(47) |
May
(73) |
Jun
(75) |
Jul
(13) |
Aug
(76) |
Sep
(40) |
Oct
(78) |
Nov
(53) |
Dec
(28) |
2015 |
Jan
(76) |
Feb
(113) |
Mar
(41) |
Apr
(94) |
May
(48) |
Jun
(41) |
Jul
(15) |
Aug
(8) |
Sep
(62) |
Oct
(67) |
Nov
(28) |
Dec
(5) |
2016 |
Jan
(20) |
Feb
(18) |
Mar
(18) |
Apr
(2) |
May
(10) |
Jun
(46) |
Jul
(11) |
Aug
(34) |
Sep
(10) |
Oct
(33) |
Nov
(30) |
Dec
(1) |
2017 |
Jan
(24) |
Feb
(1) |
Mar
(10) |
Apr
(9) |
May
(8) |
Jun
(5) |
Jul
(9) |
Aug
(17) |
Sep
(13) |
Oct
(23) |
Nov
(16) |
Dec
(14) |
2018 |
Jan
(8) |
Feb
(1) |
Mar
(7) |
Apr
(7) |
May
|
Jun
(3) |
Jul
(10) |
Aug
|
Sep
(2) |
Oct
|
Nov
|
Dec
|
2019 |
Jan
|
Feb
(2) |
Mar
|
Apr
(5) |
May
(1) |
Jun
(3) |
Jul
(5) |
Aug
(16) |
Sep
(3) |
Oct
(8) |
Nov
(3) |
Dec
(3) |
2020 |
Jan
(14) |
Feb
(4) |
Mar
(13) |
Apr
(25) |
May
(11) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(10) |
Dec
(1) |
2021 |
Jan
(5) |
Feb
|
Mar
(2) |
Apr
(11) |
May
(14) |
Jun
(17) |
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2022 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(11) |
2023 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
(3) |
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2024 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(4) |
Oct
|
Nov
|
Dec
|
From: Max H. <ma...@qu...> - 2001-11-17 10:35:49
|
At 23:29 Uhr -0500 16.11.2001, Kyle Moffett wrote: >Can someone please tell me what Pre-Depends means? I looked at the >field in the docs on the web site, but it didn't tell the exact >checking system for that, and I am not sufficiently advanced to look >in the fink source code. I'd say it is something you really should never have to worry about. Just forget it and never use it :) Anyway, the answer, as usual, is in the docs. Just read them! http://fink.sourceforge.net/doc/packaging/reference.php Max -- ----------------------------------------------- Max Horn Software Developer email: <mailto:ma...@qu...> phone: (+49) 6151-494890 |
From: Max H. <ma...@qu...> - 2001-11-17 10:32:45
|
Jan, I think I have my point clear, in previous mails. Likewise did Finlay and Christoph and some others. You fail to address a single of the concerns we uttered, but just repeat the old arguments. Do you really think that will change any oppinion? Max -- ----------------------------------------------- Max Horn Software Developer email: <mailto:ma...@qu...> phone: (+49) 6151-494890 |
From: Finlay D. <fin...@bt...> - 2001-11-17 10:22:47
|
On Saturday, November 17, 2001, at 02:46 am, Kyle Moffett wrote: > Has anybody thought about creating a GUI for Fink, some kind of > Fink.app. It would not even need to replicate code. It could just run > commands internally and parse fink's output. I would be willing to > work on this in my spare time. I just think that having a scrollable > list with packages in it would be very helpful. I could even add a > .info file editor later No, nobody has ever thought of this, despite the fact it has been discussed multiple times on the lists (including yesterday) and there is an open feature request for it that has been sitting around for the past 6 months or more! :-P http://sourceforge.net/tracker/index.php?func=detail&aid=416825&group_id=17203& atid=367203 I had a quick go at it a while back, see the fink-gui module in CVS, but it's not terribly good and has awful architecture. > If anybody is interested, please email me. Actually, the other way round: If anybody is interested, please email ME! :-) -- Finlay |
From: Finlay D. <fin...@bt...> - 2001-11-17 10:19:30
|
On Saturday, November 17, 2001, at 01:06 am, Michael Maibaum wrote: > making a new passwd package that adds postfix I should hopefully get around to tackling this sometime this weekend. > making the passwd package assign homes like /var/something or /tmp or > /dev/notanexistingplace, Hmm... I'm not really sure why this is necessary. What do other platforms do? What does the MySQL readme suggest? > picking some uids less than 100 should be possible (though we run into > danger from apple stomping on them one day) Why would want to do this? What difference does it make? > but, updating existing passwd installations is rather more non trivial. > I believe I could do the above steps, but I'm not at all confident with > this one. First of all we need to agree on what we're going to to! :-) -- Finlay |
From: Max H. <ma...@qu...> - 2001-11-17 10:15:17
|
At 20:04 Uhr -0500 16.11.2001, Chris Turkel wrote: >has anyone taken a crack at gphoto to work? I've gotten it to >configure but it doesn't recognize the USB system of Darwin, which >kinda defeats the purpose. How should it detect the Darwin USB system unless you write a special driver/plugin/whatever gphoto uses? No way. Max -- ----------------------------------------------- Max Horn Software Developer email: <mailto:ma...@qu...> phone: (+49) 6151-494890 |
From: Kyle M. <mrm...@ma...> - 2001-11-17 04:43:10
|
I have been looking at creating a DHCP package for fink, but there is one major problem, the entire build system doesn't use autoconf, make, or any of the standard build tools. I am looking at patching the installer script. Does anybody have any suggestions? If I get it to work, I'll post it to the package submission tracker. Thanks, Kyle M. |
From: Kyle M. <mrm...@ma...> - 2001-11-17 04:29:19
|
Can someone please tell me what Pre-Depends means? I looked at the field in the docs on the web site, but it didn't tell the exact checking system for that, and I am not sufficiently advanced to look in the fink source code. Thanks, Kyle M. |
From: Kyle M. <mrm...@ma...> - 2001-11-17 02:46:45
|
Has anybody thought about creating a GUI for Fink, some kind of Fink.app. It would not even need to replicate code. It could just run commands internally and parse fink's output. I would be willing to work on this in my spare time. I just think that having a scrollable list with packages in it would be very helpful. I could even add a .info file editor later If anybody is interested, please email me. Thanks, Kyle M. |
From: Michael M. <mi...@ma...> - 2001-11-17 01:06:58
|
OK, there are a number of issues here, making a new passwd package that adds postfix making the passwd package assign homes like /var/something or /tmp or /dev/notanexistingplace, picking some uids less than 100 should be possible (though we run into danger from apple stomping on them one day) but, updating existing passwd installations is rather more non trivial. I believe I could do the above steps, but I'm not at all confident with this one. Michael On Fri, Nov 16, 2001 at 03:25:33PM -0800, Daniel Parks wrote: > Oh, one more thing about the passwd package... > > Perhaps any new users could have uid<100? > > Daniel > > -- > Moderation in all things, but most importantly, moderation. > > My PGP public key: http://mwdesign.dyndns.org/~daniel/publickey.txt > Don't use PGP? Check out http://www.pgpi.org/doc/whypgp/en/ > > > > > >_______________________________________________ > >Fink-devel mailing list > >Fin...@li... > >https://lists.sourceforge.net/lists/listinfo/fink-devel > > > > > _______________________________________________ > Fink-devel mailing list > Fin...@li... > https://lists.sourceforge.net/lists/listinfo/fink-devel -- Michael Maibaum ma...@co... CPMC Research Institute (415) 561-1682 Stern Building 2330 Clay Street San Francisco CA, 94117 GNUPG public key <http://www.maibaum.org/Michael/mmgpgpubkey> |
From: Chris T. <zi...@ad...> - 2001-11-17 01:05:30
|
has anyone taken a crack at gphoto to work? I've gotten it to configure but it doesn't recognize the USB system of Darwin, which kinda defeats the purpose. cheers chris |
From: Crunky <cru...@ya...> - 2001-11-17 00:18:25
|
> > On Friday, November 16, 2001, at 11:34 pm, Max Horn wrote: > > Fink was made and designed to handle various things that are typical > for getting Unix apps running on OS X. Many of these don't apply at all > to native MacOS X apps. > > I think it would be much better idea to come up with a system that is > more tailored towards the needs for OS X apps... but again, feel free > to do what you want - I just can't fully understand your reasons :) My reason is that I want GIMP on Mac OS X. I want it to be a nice OS X app. But gimp will not run without X11, gtk, glib and lots of other really complicated libraries. There are two options. One is to package up *everything* into the .app, and that is what MacGimp has done. I think it is better for GIMP.app to depend on fink, that way when people install GIMP.app, they get the libraries they need transparently. In addition, they can get into low level fink stuff if they choose. But if they don't want to deal with that, then they can just use the GIMP and not be aware of all the fink/dpkg stuff that brought this enabled application to get to their desktops. Also, using fink means that I can make a Gnumeric.app that depends on the same libraries as GIMP. > > Exactly -- I think that the VTAUS project would be more deserving of > your efforts in this respect :-) > I haven't heard of this project. Do you have a URL for this? I didn't find anything with google search. Begin forwarded message: > From: Finlay Dobbie <fin...@bt...> > Date: Fri Nov 16, 2001 03:43:53 PM US/Pacific > To: Max Horn <ma...@qu...> > Cc: bb...@ma..., fin...@li... > Subject: Re: [Fink-devel] OSX .apps in Fink > > > On Friday, November 16, 2001, at 11:34 pm, Max Horn wrote: > >> Fink was made and designed to handle various things that are typical >> for getting Unix apps running on OS X. Many of these don't apply at >> all to native MacOS X apps. >> >> I think it would be much better idea to come up with a system that is >> more tailored towards the needs for OS X apps... but again, feel free >> to do what you want - I just can't fully understand your reasons :) > > Exactly -- I think that the VTAUS project would be more deserving of > your efforts in this respect :-) > > -- Finlay > > > _______________________________________________ > Fink-devel mailing list > Fin...@li... > https://lists.sourceforge.net/lists/listinfo/fink-devel > |
From: Jan de L. <de...@st...> - 2001-11-16 23:57:52
|
I am not sure I understand this discussion. Obviously CLI, X11, Aqua are all OS X applications. Some are linked with the X11 libraries, some with the Cocoa frameworks. You can start shell scripts from the Aqua interface and Aqua programs from the command line. If you run OroborusX in rootless mode, then X11 and Aqua live peacefully and almost indistinguishably together. This type of integration is the main reason why we love OS X, right ? We are not interested in owning an overpriced Linux box. Also, some people seem to argue that fink is limited to unix applications (?). But aren't all OS X applications unix applications ? Surely if Aqua applications are not unix applications, then X11 applications are not unix applications either. It seems to me that as long as the package is open source, and the configure/compile/install process can be done by fink, it's a candidate to be installed in /sw. It also seems to me that Cocoa wrappers around former CLI applications are potentially a huge class (currently TeXShop, Emacs.app, MacScheme48, Chaitin Lisp -- I can easily imagine Python, Perl, Ruby, R, Clisp, octave, scilab done in the same way), and that Apple, after some initial hesitation, is now pushing this way of rapid application development. === Jan de Leeuw; Professor and Chair, UCLA Department of Statistics; US mail: 9432 Boelter Hall, Box 951554, Los Angeles, CA 90095-1554 phone (310)-825-9550; fax (310)-206-5658; email: de...@st... homepage: http://www.stat.ucla.edu/~deleeuw ======================================================== No matter where you go, there you are. --- Buckaroo Banzai http://www.stat.ucla.edu/~deleeuw/sounds/nomatter.au ======================================================== |
From: Crunky <cru...@ya...> - 2001-11-16 23:56:40
|
This was meant for the list... Begin forwarded message: > From: Crunky <cru...@ya...> > Date: Fri Nov 16, 2001 03:04:03 PM US/Pacific > To: Max Horn <ma...@qu...> > Subject: Re: [Fink-devel] fink and OS X .app's > > > On Friday, November 16, 2001, at 02:46 PM, Max Horn wrote: >> >> If we install OS X apps with fink, we have to prevent the user from >> moving them to prevent messup, we have to make sure we don't override >> already installed copies. etc. >> >> > > Can someone clarify why we must keep track of the applications? > > For normal unix stuff, you have to be very precise about who owns which > files and so on. That's that what fink/dpkg is all about. But Mac OS > X applications are specifically designed to be standalone, movable > bundles. > > So let's walk through an example. I have QuickTime installed on my > system. It includes a lot of Components and Frameworks, and an > application called QuickTime Player, which is installed in > /Applications. I can do anything I want to player. I can move it, > rename it, copy it, and/or duplicate it. I can have 5 different copies > on my system if I want. > > Now, when I install a *new* version of quicktime, the installer doesn't > get all precise about trying to figure out all the stupid user stuff I > may have done with the player. It simply checks to see if it is > installed in /Applications, and if it is it deletes that copy before > installing the new version. > > Now, that new copy of QuickTime Player in /Applications is obviously > the only one that is guaranteed to work, because a new version of > QuickTime.framework has been installed. But most likely the *old* > QuickTime Player.apps will *still* work because Apple takes care that > new frameworks (libraries) don't break old applications. > > Now I know that such care is not always taken in the unix/open source > world. My point is simply that if a user moves or deletes and > application, it's no big deal, fink/dpkg shouldn't worry about it. The > new application can get installed if the person has said "fink update > "The Gimp.app"", it will get installed in a known location > (/sw/Applications perhaps). > > That said, I appreciate the points put forward in the previous posts. > It's sounds like most people don't want applications in Fink. That's > fine, and I'm OK with having a separate project that focuses on > creating applications that depend on Fink. I've got some ideas for > it. Basically I'm going to package up The Gimp so that it will go > ahead and install fink if the user doesn't have it installed already. > These applications will have a facility that enables them to be updated > with to the latest version by the user just clicking and "update" > button somewhere. > > -Jesse > |
From: Christoph P. <cp...@ch...> - 2001-11-16 23:48:46
|
One side that I think is suspiciously missing from this whole discussion is technical requirements and user expectations. Traditional Unix apps and OS X .app bundles are different worlds, with different needs and different expectations. Traditional Unix software is made up of a lot of separate files scattered throughout a directory hierarchy, held together by (more or less) hardcoded paths. This arrangement is vulnerable; it is critical that all files belonging to an application are installed, removed and updated at the same time, as one entity. Also, the files can not be moved around and must be protected from tampering by casual users. The common solutions to these problems are 1) installing software using an administrative account (root) and give users just read-only rights and 2) using package managers such as dpkg and rpm, which provide for the required atomic, transaction-like installation of whole packages. OS X .app bundles are different. They are specifically designed to be self-sufficient, sealed entities that carry all required resources inside. They are designed to be moved around; users are encouraged to do so and rightfully expect to be able to do this with any .app they encounter. At the same time, the inside enjoys some protection from the user. Packaging schemes designed to handle traditional Unix software (like dpkg) are not necessary for .app bundles and neither are they equipped to handle them properly. [And then there's always the issue of Mac OS's special file system stuff, like type and creator codes, resource forks, and bundle bits. Apple tries to get rid of this, but Carbon apps still use it to some extent...] What would be useful for handling normal .app packages (say, OmniWeb) would be a tool that simply treats .app bundles as the entities they are. Such a tool would have to be equipped to track apps as they are moved around the file system or change permissions, and would have to deal with per-user, system-wide and network-wide installation (i.e. ~/Applications, /Applications and /Network/Applications). On the other hand, it doesn't need all the sophisticated bells and whistles dpkg has (e.g. configuration file handling). [dselect and apt work on an abstract level and could probably be adapted to this new tool with some work, but as Max pointed out, you're looking for something with an Aqua GUI here...] Now, the real trouble starts when Unix apps are ported to OS X proper and gain a .app part that still depends on the other Unix innards to work - packages like XFree86 come to mind (although it makes a bad example). One solution is to move everything into the .app bundle after making it position-independent and self-sufficient (potentially very hard); that basically puts the package outside of Fink's scope as explained above. Other solutions are easier as far as coding is concerned, but amount to a packaging nightmare, as one can see from the current XFree86 packages. Putting .app's in /sw/Applications may eliminate the need to check for prior installs, but doesn't really get rid of the other problems, namely user tampering. dpkg doesn't exactly like it when files under its control get removed or updated by the user. If a user wants the application elsewhere, the other choice is to copy it, but then the copy won't get updated automatically by dpkg. I also don't like the idea of users navigating to /sw/Applications and getting the idea that they could tamper with /sw/bin or whatever on the way. [There is a reason that /usr and friends are invisible from the Finder...] All that said, I think a daemonic-style solution (like already suggested) is probably the best we can do for the cases where it actually makes sense (an Aqua port of an Unix app that still depends on other Unix stuff), and especially for wrappers for apps like The GIMP. The idea goes like this: Packages install a description file in a designated location in /sw. A special program turns those into an .app wrapper and installs it in a location of the user's choice, e.g. /Applications or /Applications/Fink when it is writable, and ~/Applications otherwise. As long as the wrapper stays in a well-known location, it could be updated automatically from the postinst script when the package is updated. The .app would consist on an icon, a small generic shim, and a description file that tells the shim where to look for the real binary (i.e. /sw/bin/something or /sw/lib/package/appexecutable). The shim would look for that file and exec it, possibly after setting some environment variables or after launching XFree86/Xtools if required. If the file is no longer there, the user can be informed via a dialog box. With some hacking and some more features, this scheme might even be applied to difficult packages like XFree86... More random thoughts: The shim could check with the original description file to see if it is still up to date. I'm not sure if the above makes sense for real Aqua ports involving dialog resources and so on. Ah, time to put an end to this mail, I'm drifting off into endless possibilities again... -chrisp -- chrisp a.k.a. Christoph Pfisterer "Any sufficiently advanced cp...@ch... - http://chrisp.de bug is indistinguishable PGP key & geek code available from a feature." |
From: Finlay D. <fin...@bt...> - 2001-11-16 23:48:22
|
On Friday, November 16, 2001, at 11:34 pm, Max Horn wrote: > Fink was made and designed to handle various things that are typical > for getting Unix apps running on OS X. Many of these don't apply at all > to native MacOS X apps. > > I think it would be much better idea to come up with a system that is > more tailored towards the needs for OS X apps... but again, feel free > to do what you want - I just can't fully understand your reasons :) Exactly -- I think that the VTAUS project would be more deserving of your efforts in this respect :-) -- Finlay |
From: delmar w. <de...@me...> - 2001-11-16 23:39:48
|
Finlay Dobbie wrote: > > why remain on "archaic" installation techniques when we can > > move to something better.... > > archaic? like drag and drop? wow, THAT WAS DIFFICULT TO INSTALL! Yes, actually, DnD *IS* a difficult way to install compared to dselect, IMHO. Why should I hunt for an application, download it, untar/mount/both it, *THEN* DnD it to a location? In Debian with dselect, installing an app is as easy as: apt-get install foo or if I need to search for its name or select MANY apps to install, I go into dselect and within a few seconds have access to the newest stuff (and the older stuff is updated for me), with a nice interface to everything. I assumed that the reason everyone is using Fink is that they see the value in dselect versus hunting for an application, downloading it, untarring it, make && make install. The value of Fink and dselect is in its simple interface for installing anything instead of a more "Slackware" approach to manually doing something that we can do a better way. Odd that I should have to point this out... I thought the main contention was whether or not Fink's charter should extend to the next obvious stage by integrating with any OS apps that want to have an automated install/update... I guess I misunderstood the character of the debate. > > maybe Apple will get the hint one day and > > have something like Fink for non-OS apps. > > why on earth should this be Apple's responsibility? Because if Apple had an elegant way, like a GUI dselect bundled with the OS, to easily get software... maybe even commercial software via the 'net, then it would be head-and-shoulders above other OSes (say WINDOWS) because it would finally be easy to get software on a machine. The reason I use Debian most of the time is because of this awesome feature. I can get a Debian box up and running and EXACTLY how I want it in about 1/5th the time it takes me to do it by hand on OSX or Win2k. > Why do people always have such trouble with the name Dobbie? Doobie, > Dobie, Dobbin, I mean come on, it's hardly Krijgsman or Prawer-Jhabvalah > or anything! > Dobbin is a house-elf in Harry Potter, IIRC, which could be why some > people get confused :-D I am terribly, horribly sorry. I completely misread your name. Please accept my deepest apologies. I don't know how many times I have been called, "Delmer" so I can sympathize. |
From: Max H. <ma...@qu...> - 2001-11-16 23:36:55
|
You are certainly free to do whatever you like, Bill, but I wonder why you are so insisten on using fink for the foundation of this... I think that is not the best choice for such a project at all! Fink was made and designed to handle various things that are typical for getting Unix apps running on OS X. Many of these don't apply at all to native MacOS X apps. I think it would be much better idea to come up with a system that is more tailored towards the needs for OS X apps... but again, feel free to do what you want - I just can't fully understand your reasons :) Max -- ----------------------------------------------- Max Horn Software Developer email: <mailto:ma...@qu...> phone: (+49) 6151-494890 |
From: Daniel P. <da...@mw...> - 2001-11-16 23:26:33
|
Oh, one more thing about the passwd package... Perhaps any new users could have uid<100? Daniel -- Moderation in all things, but most importantly, moderation. My PGP public key: http://mwdesign.dyndns.org/~daniel/publickey.txt Don't use PGP? Check out http://www.pgpi.org/doc/whypgp/en/ > > > _______________________________________________ > Fink-devel mailing list > Fin...@li... > https://lists.sourceforge.net/lists/listinfo/fink-devel > |
From: Justin H. <ju...@ca...> - 2001-11-16 23:10:30
|
this is totally true. It would be like Helix Code and debian. Helix isn't part of it at all but you can add it to your tree. bb...@ma... writes: >I don't understand why this is even an issue... It would be trivial to >add >a 'osxapps/' parallel to crypto/ and main/ in the package description >tree. > It would be optional and turned off by default-- to enable, simply >add >'stable/osxapps' to your fink.conf. > >I would actually like to see this and would use it to package up binaries >of all the apps I consider to be a part of the baseline of an OSX box. >This would save a lot of time as the system ages-- i.e. upgrades and >rebuilds would become relatively effortless. > >And installing into /sw/Applications (or wherever the fink root is) is no >big deal -- as of 10.1, the system handles this fairly gracefully. > >However and before I get yelled at, let me add that I don't necessarily >think that the osxapps/ tree should be directly a part of fink at all. >It >certainly doesn't need to be and creating binary only packages is >certainly not a part of Fink's charter. But that doesn't mean that Fink >can't be used as the foundation upon which we install the osxapps package >descriptions and let Fink handle the installation in the same fashion as >it does with the binary distribution now. ¸.·´^`·.,][JFH][`·.,¸¸.·´][JFH][¸.·´^`·., Justin F. Hallett CAISnet Inc. 2nd Floor, 11635 - 160 Street Edmonton, AB, Canada T5M 3Z3 Phone: (780)-408-3094 Fax: (780)-454-3200 E-Mail: ju...@ca... http://www.caisnet.com/ ¸.·´^`·.,][JFH][`·.,¸¸.·´][JFH][¸.·´^`·., |
From: Finlay D. <fin...@bt...> - 2001-11-16 23:03:12
|
On Friday, November 16, 2001, at 10:34 pm, delmar watkins wrote: > It would not be a GENERAL app installer, just an OpenSource application > installer... for OpenSource stuff, why NOT make it as easy as Debian to > install? I still don't agree that all opensource OS X apps should be plonked into Fink. They do not need porting, so there's point (1) of Fink's goals eradicated. They don't really need any special package management, drag and drop is good enough for most, so there's point (2) of Fink's goals eradicated. They even come in binary form, so you don't need to have a binary distribution or anything. > why remain on "archaic" installation techniques when we can > move to something better.... archaic? like drag and drop? wow, THAT WAS DIFFICULT TO INSTALL! Also note that any apps installed with fink would be owned by root which may cause permissions problems therefore more work (chgrp'ing them to admin, for example). > maybe Apple will get the hint one day and > have something like Fink for non-OS apps. why on earth should this be Apple's responsibility? > However, just to retain peace within the community, I will be contacting > Mr. Dobbins to see about a front-end to Fink that may have its own .app > functionality. Why do people always have such trouble with the name Dobbie? Doobie, Dobie, Dobbin, I mean come on, it's hardly Krijgsman or Prawer-Jhabvalah or anything! Dobbin is a house-elf in Harry Potter, IIRC, which could be why some people get confused :-D -- Finlay |
From: <bb...@ma...> - 2001-11-16 23:02:49
|
I don't understand why this is even an issue... It would be trivial to add a 'osxapps/' parallel to crypto/ and main/ in the package description tree. It would be optional and turned off by default-- to enable, simply add 'stable/osxapps' to your fink.conf. I would actually like to see this and would use it to package up binaries of all the apps I consider to be a part of the baseline of an OSX box. This would save a lot of time as the system ages-- i.e. upgrades and rebuilds would become relatively effortless. And installing into /sw/Applications (or wherever the fink root is) is no big deal -- as of 10.1, the system handles this fairly gracefully. However and before I get yelled at, let me add that I don't necessarily think that the osxapps/ tree should be directly a part of fink at all. It certainly doesn't need to be and creating binary only packages is certainly not a part of Fink's charter. But that doesn't mean that Fink can't be used as the foundation upon which we install the osxapps package descriptions and let Fink handle the installation in the same fashion as it does with the binary distribution now. I'll even star the ball rolling by packaging Xmanview (which has dependencies on rman, btw) and Podestal in this fashion. I will also ask Andy Stone if he would be willing to distribute the Stone Studio apps as debian packages, as well as his current distribution style. As this is outside of the context of the Fink project, please reply to me directly if you are interested and we can determine how best to proceed-- likely, create a separate source forge project? b.bum |
From: Finlay D. <fin...@bt...> - 2001-11-16 22:59:31
|
On Friday, November 16, 2001, at 08:58 pm, Daniel Parks wrote: >> Well, if we, as I suggested, create a tree for Mac OS X applications, >> we could, for example, have an essential package that: >> 1) checks if we're running on Mac OS X somehow > > What we really need are OS-version sensitive patches and scripts. But > maybe I'm beating a dead horse. Well, I don't really see why. >> 2) provides a symlink from %p/Applications to /Applications/Fink (or >> not, depending on user interfaction, I guess). > > A daemonic-like app to handle .app's would be better. (Cleaner, easier > to update, potentially corss-platform.) I would be willing to do some > work on that, except that I have to much other stuff to do right now. Not with you on that one... > I think that we need to be more flexible about Fink's goals. Why do we > just want to target OS X users; Well, we target Darwin too AFAIK. > why do we only want "UNIX" software? I think it makes sense to have > .apps in the tree too, as long as it's clear that they're .apps. > Perhaps making .apps go in a separate tree would be a good idea just > for that. Well, I mean, why not implement support in Fink for making cups of tea as well? I think it makes sense to be careful that we don't try to do too much with Fink. I mean, we're already doing a lot (more than the current team can handle it would seem: just look at the backlog on the package submission tracker), why do we want more work? > OK, changing my mind here. A separate tree would be nice, if it was > like the crypto subtree (as opposed to main.) In other words it would > always be there, but I could turn it off if I wanted. -- Finlay |
From: Max H. <ma...@qu...> - 2001-11-16 22:46:29
|
At 14:34 Uhr -0800 16.11.2001, delmar watkins wrote: >"David R. Morrison" wrote: >> >> In spite of this, there are going to be a small handful of GUI apps which >> are heavily dependent on a UNIX piece that could/should be installed by >> fink. Aqua-emacs is one example, XDarwin and TeXShop are others. For >> these apps, maintaining some kind of /sw/Applications tree seems reasonable. > >I agree with this > >> >> I would say that one of the criteria should be: is the app open source? >> Can we have fink download the source and compile? (Even if it has to use >> ProjectBuilder to do so?) > >I agree with this, too. I disagree with both. More below >The several applications I end up re-installing >are almost all OpenSource (XonX, OroborusX, VNC <--is that OS?). There >is no reason that we shouldn't have OpenSource native OSX apps in the >tree. This is, of course, an option and on other UNIX platforms we >could build separate trees for native OS apps on those platforms, too. First off, XDarwin.app is really a special case. And we want it in the same place as the binary XDarwin distro from the XonX team puts it. We need XDarwin.app, because it is required for the X11 package. That's the only reason I feel it is tolerable. The Aqua.app thingy from gnuplot falls into the same category, it support gnuplot, giving it some features that you can't get withouth. But I don't think we should package TeXShop, or any other "pure" OS X app, even if it depends on some unix software. There are so many open source MacOS X apps out there, and yeah, we could package them all, but IMHO that is not the purpose of fink. OS X apps are supposed to consist of mainly of one file, that can be moved anywhere. Fink packages OTOH are fixed to one specific location, and can't (or at least: shouldn't) be moved after install. If we install OS X apps with fink, we have to prevent the user from moving them to prevent messup, we have to make sure we don't override already installed copies. etc. So I still don't like the idea. > > But all in all, I agree with Max. Even though dpkg/apt have many >> advantages over the apple installer, we should concentrate on fink's >> strengths rather than expand to a general app installer. > >It would not be a GENERAL app installer, just an OpenSource application >installer... for OpenSource stuff, why NOT make it as easy as Debian to >install? why remain on "archaic" installation techniques when we can >move to something better.... maybe Apple will get the hint one day and >have something like Fink for non-OS apps. Because I don't think that most people want a terminal based installer for graphical apps; and because the fink system is not really suited for (moveable) OS X apps. and because it is besides the actual goal of fink. > >However, just to retain peace within the community, I will be contacting >Mr. Dobbins to see about a front-end to Fink that may have its own .app >functionality. Sure, feel free to do anything. Also, let me clarify: I don't want to argue or get into a flamewwar or anything, just want to explain my POV. Rest assured I am reading and considering what you write - but so far, I just haven't heard convincing arguments, but OTOH see quite convincing arguments opposing this idea. Max -- ----------------------------------------------- Max Horn Software Developer email: <mailto:ma...@qu...> phone: (+49) 6151-494890 |
From: Justin H. <ju...@ca...> - 2001-11-16 22:35:51
|
OH /sw isn't hidden by default, i hid it. Cause it confuses other ppl that sometimes use my system and i don't want ppl in there. fin...@bt... writes: > >> A symlink /Applications/Fink -> /sw/Applications would let someone >> using the Finder click on the Fink directory within Applications and >> be taken to fink's /sw/Applications directory, while confining all of >> fink's activity to within /sw. > >Also would work if you installed into /usr/local/fink or whatever, as >some people seem to like doing. ¸.·´^`·.,][JFH][`·.,¸¸.·´][JFH][¸.·´^`·., Justin F. Hallett CAISnet Inc. 2nd Floor, 11635 - 160 Street Edmonton, AB, Canada T5M 3Z3 Phone: (780)-408-3094 Fax: (780)-454-3200 E-Mail: ju...@ca... http://www.caisnet.com/ ¸.·´^`·.,][JFH][`·.,¸¸.·´][JFH][¸.·´^`·., |
From: delmar w. <de...@me...> - 2001-11-16 22:35:38
|
"David R. Morrison" wrote: > > In spite of this, there are going to be a small handful of GUI apps which > are heavily dependent on a UNIX piece that could/should be installed by > fink. Aqua-emacs is one example, XDarwin and TeXShop are others. For > these apps, maintaining some kind of /sw/Applications tree seems reasonable. I agree with this > > I would say that one of the criteria should be: is the app open source? > Can we have fink download the source and compile? (Even if it has to use > ProjectBuilder to do so?) I agree with this, too. The several applications I end up re-installing are almost all OpenSource (XonX, OroborusX, VNC <--is that OS?). There is no reason that we shouldn't have OpenSource native OSX apps in the tree. This is, of course, an option and on other UNIX platforms we could build separate trees for native OS apps on those platforms, too. > But all in all, I agree with Max. Even though dpkg/apt have many > advantages over the apple installer, we should concentrate on fink's > strengths rather than expand to a general app installer. It would not be a GENERAL app installer, just an OpenSource application installer... for OpenSource stuff, why NOT make it as easy as Debian to install? why remain on "archaic" installation techniques when we can move to something better.... maybe Apple will get the hint one day and have something like Fink for non-OS apps. However, just to retain peace within the community, I will be contacting Mr. Dobbins to see about a front-end to Fink that may have its own .app functionality. |