On Nov 11, 2006, at 5:07 PM, Alexander Hansen wrote: > Moreover the big reason to have the -shlibs and -dev splitoffs is > ideally to keep from breaking a metric ton of packages if you update a > shared library which happens to be binary incompatible with the prior > version. You can generate -shlibs packages for different libversions > (foo2 alongside foo1) of a package that can coexist while maintainers > switch their packages over from foo2 to foo1; and you need the -dev > packages to point to them.
Alex, Thank you for your reply and all of which I agree with including "Having a centralized database to keep track of your files doesn't suck.". I never meant to imply it sucks. It does not. The point I intended to make is that I don't object to having these packages in Fink or having them installed, but rather having to deal with them when managing fink (as a user). Just install them all and let fink sort it out behind the scenes. I don't care that I have 5 different -shlibs installed and fink somehow figures out which one to use and if at some point i need to optimize disk space I can run a purge command that removes all currently unused versions. I know this is hard for some developers to understand, because for them the variations are all required and easily understood. Actually, the more I though about it (which usually happens just after you hit send) and the more I looked into the reason why I quit using fink for a few packages, it was not user/maintainer complexity (which I don't like) but rather the fact the Fink packages were out of date. For a long time I have not used fink for Firefox, LilyPond, R, Graphviz and others (all of which have maintainers). In the case of LilyPond, there was a period when Matthias Neeracher was not updating the package very regularly and at the same time I was having problems that were being solved by new releases. Once I switched away from fink I never switched back. Later he also improved the frequency of updates. I went to the web site and looked at the packages without maintainers. It was 11 pages long, for a total of 503 packages out of 6435 listed in my install. That is 7.8%, which on the face of it does not seem bad. However, this list is growing fast. The last time I looked, the list had a dozen or so packages. Plus, how many maintainers have not bothered to update their packages to not maintained? It would be interesting to see the number of packages without maintainers graphed over time. So for me the issue is currency. If the package is not current for any reason (lack of maintainer, or latency by the maintainer) then alternatives are used. Some suggestions: 1. Some packages could be updated automatically without maintainer intervention. Especially in unstable. Maybe this should be a different tree. The point being that once a .info file is approved, why should it require maintainer interaction for point upgrades. This becomes even more true with the ability to automatically run the test suites. 2. There should be some way to clean out the junk (old versions) and maintain availability of the old info file should someone want to update it. One option would be another tree for old and unmaintained. Once the fink release is out-of-date the package should be moved. Another option would be better to have an out-of- date flag. This benefits me as a user, but probably does not benefit Fink. But then again what is good for the user is probably also good for Fink in the long run. 3. Have an automated way to test package submissions and approve them with the exception of the MD5. This should only be set by known maintainers. This reduces the work and improves the response time for new maintainers. 4. Find other ways to reduce the amount of time required for maintainers. Fink is an elegant solution. But if Fink packages are not current or if they are a limited quantity then Fink will languish. Which is not my preference. Neil ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
