On 11/12/06, Neil Tiffin <[EMAIL PROTECTED]> wrote: > > 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. >
Yeah, this is a major annoyance. I added the "updated revision of existing" and "updated version of existing" categories in the tracker for just this reason--small changes should be quickly implemented. It is sometimes necessary to run a test case on a new _version_, though. IMO the tracker isn't the best place to handle this, necessarily. The maintainer should continue to be involved--a quick note on fink-devel with a diff or list of small changes to make. It's better that the maintainer check for upstream updates than to put it on the core developers (who won't bother, as they have other things to worry about) > 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. > The problem here is that we don't have an automatic way to check with the upstream sites to see what the most current version is--nor do their repositiories necessarily have an alias to point to the current version. How would you implement this? > 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. > We've got some automated tools. We just don't have a build box, or interface for users, or... > 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 > -- Alexander K. Hansen Fink Documenter (still) Got job? http://akhmac.blogdns.net/~hansen/akh_cv/ ------------------------------------------------------------------------- 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
