Matthew S. Hallacy wrote: > What would you rather have, extremely outdated packages (Yes, it's 6/2002 > now!), or the hassle of dropping those rpm's into a directory somewhere > and typing: Making such statements on such corner applications is so misleading I don't feel the need to argue about this, however... I'll be happy to avoid rpms flaws in dependencies. (file deps, versioned deps that might be asking for something in a different dist, thank god mandrake renames their versions to make their end of the pool sane) Some people really dont care that theres a bleeding edge package out now, but that what they are using is considered non-crack by the maintainer. If its true that the current revision is non-crack and should be packaged, file a bug. If the maintainer doesn't give a rats ass and can't seem to care, find someone else to package it or do it yourself. If none of those work, it shouldn't be packaged in the first place for lack of interest. If you cant find one DD to care enough about it and you can't find one user who can't volunteer some time, oh well. Yes, we know the devlopment cycle sucks right now. This will be a major topic later this week in Toronto I'm guessing. Many proposals want targets of 6-12 months without making major infrastructure changes. I'm personally up for point releases with unchanged base and many end-user-application updates, with major releases having the big infrastructure changes. (new dpkg, new init system, etc.) The nasty problem about this is that the debian development infrastructure does not lend itself to this sort of development. I'm not exactly sure yet how to attack that issue yet other than create infrastructure outside of debian to experiment. -- Scott Dier <dieman at ringworld.org> http://www.ringworld.org/