On Thu, Aug 31, 2006 at 06:04:29PM +0100, Helge Kreutzmann wrote: > severity 385146 wishlist > thanks > > I've never used trac, but saw your report and felt a little strange. > You blame a Debian version which version requirements are perfectly > fullfilled (as you say, trac works with stable subversion) as shipped > by Debian for a > system you created by installing software not shipped in Debian. > Moreover, trac broke because a *dependency* changed. How do you think > the author of trac should have estimated this before the release of > Sarge? > > I think you can do one or more of the following: > a) complain against the person who installed the backported subversion > for breaking your setup > b) backport a more recent trac > c) check if tracs depencency in *sid* are correct; if they are not, > then update this bug with that info > d) point out which part of Debian policy is violated by your > combination of a Debian release with your own software packages > e) provide a solution how to avoid such situation in the future > f) explain what in your opinion should happen now: stable is only > updated with "severe" bugs (e.g. security, read the www.debian.org > or d-d-a for details), certainly not to fix some random dependency > for a backport
Hi Helge. That was a very defensive response, so I'd like to clarify first of all that I'm not _blaming_ _anyone_. It's an open source project, people contribute their efforts for free, how could I complain or blame anyone? I'm trying to help make things slightly better by correcting what I see as a problem that could impact other people. It's already impacted on me, so I've got nothing left to gain personally by having things changed. In reverse order, for no apparent reason: f) the stability of debian systems and packages should refer to the packages themselves, a policy in place for good and sensible reasons, but not necessary to remedial fixes to their metadata. e) I would advocate updating package dependencies if they are found to be incorrect. I don't necessarily advocate providing an updated package number for this, as the package itself hasn't changed, but that's debatable. d) I'm interested in things being correct and working reliably, giving the end user a positive and consistent experience. That's why I work very hard to get debian, rather than redhat, into every environment I work in. It's hard work, but ultimately worth it mainly because debian's packaging and dependency subsystem enables me to run a better service as a result. I'd like debian to be as reliable as possible, and backports are a part of life when providing a service to a technical team - nobody is going to accept a bug riddled version of software from a year ago because it's "stable"; that argument won't wash. If you're going to quote policy over correctness, and dismiss an issue because it's not "supported" (I've got a support contract!? Nice!) then I might as well talk to redhat, because at least they'll be apologetic while doing the wrong thing. c) I can't imagine that being an issue, because that version of trac will have been compiled against a sid system. The issue is that the dependencies for stable trac are misstated and as such are too loose. b) That's my department's plan, as it happens, but this will take a little while due to the schema for trac (against which one writes reports within the tool) being fairly fluid. As I said, my concern isn't about _me_ and I can change the package on my system with ease, but I don't believe that people should be able to install conflicting or incompatible packages from any combinations of distribution. As Steve points out, this will be a problem when mixing pure debian distributions as well. a) I installed it. That's why I'm raising this issue that I encountered. Backports usually work flawlessly, but what's happened in this case is that they've not realised there's a problem because the dependencies specified by trac allow the system to install incompatible packages without warning. That's nobody's _fault_, but it _is_ something that isn't as good as it could be, given a small, low-impact change. Ta, Mike. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
