I've been thinking about removing packages from fink and its seeming more and more like a bad idea, but I'm still all for making system-foo packages.
On Samstag, Juli 26, 2003, at 02:02 Uhr, John Davidorff Pell wrote:
Here's my rationale for wanting some fink packages to be removed (or a system-foo package created??):Hello.
While I appreciate all the effort you made to list those packages I do not quite understand which reasoning is behind _removing_ them? To offer additional packages where one might choose to stay with the system packages is surely an enhancement one can think about. Sometimes Apple failed to provide shared libraries one can link against and since I have not seen Panther yet, I have no idea if that has been fixed.
There are like 10 diff auto* package sin fink, all diff versions. since they're so small it makes little diff, but I was thinking that a few packages could be eliminated (but it would be pointless if we make system-autofoo packages) by removing the ones provided by the system.Devel:Auto Tools are a very tricky thing. Some packages require older auto tools, thus messing with those should be avoided, not to mention that most auto tools are tiny, so I see no benefit in adding a systems package.
AutoConf2.5: version 2.57 is provided by panther, obviously the other autoconf packages would remain for compatibility. :-)
I totally understand that, I do the same things sometimes too. :-) but i've noticed that the only packages that i've seen depend on bash doesn't need the enhancements, also how do I (as a fink user) choose which enhancements I get in fink's bash? I would end up compiling it again myself anyway, depending on what I want. ;-)AutoMake1.6: version 1.6.1 is provided by panther, the current fink version is 1.6.3.It might sound stupid, but why not? M4 is not exactly huge and while I cab agree, that we might wish for a system- package, there is no reason at all to remove it.
M4: version 1.4 is provided by panther (dev tools), do we need a fink version?Because some people, like me, like to build their bash with a few enhacements ;)
Shells:
Bash: version 2.05b is provided by panther and i really can't see any reason to have a package for it to begin with, but ...
already? its been out for like a week! ;-)Tcsh: version 6.12.00 is provided by panther and ditto the above from bash...Because I use features that are in 6.2 :=)
Zsh: version 4.0.4 is provided by panther, the current fink version is 4.0.6
Editors:
Emacs: version 21.2.1 is provided by panther, current fink version is 21.3
VIM: version 6.1 is provided by panther, current (just released) fink version is 6.2
then let's keep it! :-)Yes, some coding I do relies on 5.3 and I am sure I am not the only one.
Base:
Gzip: version 1.2.4 is provided by panther, is there a real need?
libiconv: version 1.8 is provided by panther, (?? newer than fink's in the tree...??)
Ncurses: version 5.2-20020209 is provided by panther, the current fink version is 5.3-?
What I'm suggesting is that any packages that need it figure out if they need the *latest* version or not. postfix isn't as small as auto* or m4. make a system-postfix package.Tar: version 1.13.25 is provided by pantherYou wish to replace an _older_ version with a newer one? What kinda strategy is that ? :)
Libs:
Libxml2: version 2.5.4 is provided by panther, the current fink version is 2.5.6
X11:
X11 in panther and freetype2 and all that fun stuff, but you already know about it... :-)
<snip>
Net:
postfix-release: version 2.0.7 is provided by panther, it has replaced sendmail (I'm sure everyone knows already...) the current fink version is 2.0.10
Personally I'm all for having the latest version, but not for something I hardly use and for a package which isn't small by any standards, unless you compare it to kde or mozilla. This isn't simply an option of replacing 0.9.6i w/ 0.9.7a, but of keeping 0.9.6i and *adding* 0.9.7a. the space might not make a diff on newer systems, but on my system I have limited space and I don't like having many copies of the same thing around, albeit diff versions.
Crypto:This is incorrect. 097 behaves differently, there have been symbol changes and even significant algorithmic changes. Therefore it is important to some (as you pointed out not many) packages what they link against. For example xmlsec needs 097 for proper AES support.
Openssl: version 0.9.6i is provided by panther (not 0.9.7x). Most packages that link against openssl don't care whether its 0.9.6i or 0.9.7a or whatever, i think that the move to defaulting to openssl097 was a bad idea. I think that packages should depend on openssl and only 097 if needed. openssl097 'provides' openssl so if john doe wants 097, just install 097 and everything will link against it.
Having packages which do not care and are frshly added to the tree depend on openssl 0.97 is very smart in my opinion because 097 introduces not only speed benefits, but security fixes and vast enhancements over the 0.96 tree.
I'm actually a little scetchy when it comes to making packages. I generally cannibalize someone else's. :-)
This is what I've seen so far, I realize that some packages should remain because of fink-specific changes or new versions or whatever, but some can be removed and some should have system-foo packages created for them. Some packages will be updated (i hope) b4 the public release of panther.Please do. as soon as they are in the tracker we can still consider putting them in, no ? ;)
I'd be happy to submit my own system-whatever packages if you're willing to use some of them (then again, its prob a better idea to have someone better than me write them...) :-)
--snip--
JP
------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 _______________________________________________ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
