Thanks for the response - we'll leave this in the hands of the maintainer now and stop wittering at people :-)
I thought I'd selected "normal" severity (the default for M-x debian-bug). If I did something dopey like raise it as "serious" (I can just about see me doing that because it talks about policy rather than the package itself, which is sort of where this problem falls) then I apologise, and please feel free to downgrade it. Ta, Mike. -----Original Message----- From: Helge Kreutzmann [mailto:[EMAIL PROTECTED] Sent: 01 September 2006 14:28 To: Mike Ashton Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Bug#385146: Not a supported combination Hello Mike, On Fri, Sep 01, 2006 at 12:10:59PM +0100, Mike Ashton wrote: > > 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 Point taken, I should'nt have used such strong words. I guess I looked too long on the not-lowering numbers of RC bugs. > 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. Ok, thanks for reporting then. I simply saw no way a Debian developer could act on this report, and it was not filed important or lower but with an RC severity (for Etch). > 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. Yes, I agree. > 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. There you'll have to talk to the stable RMs. I can't remember an update for such a reason, though. But in principle it should be possible. I don't know if they read this bug log, you might ask on Debian release if an update in the next point release is possible. > d) I'm interested in things being correct and working reliably, > giving the end user a positive and consistent experience. That's Thanks. Debian cares for its users as well. > 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. There you misunderstood me. The Debian developers work hard to get their system in shape and to ensure, that stable is "stable" (including that security issues found are fixed). That is the support I was taking about. I am happy, of course, if a developer also spends time ensuring that non standard configurations are supported (e.g. conflicts with non-debian packages, support for backports (which quite a few packages provide)) and grateful, but *I* would consider it a nice request, but no a relase critical bug (for Etch). And yes, I've done backports and found similar errors to yours as well. And sorry to hear that a "bug riddled" version was frozen in Sarge. Maybe you can ask your technical team to help ensure that this does not happen again for Etch? But being in Debian, stable always is frozen to a certain version (think how old Woody was at the end) which is part of the philosophy of Debian. > 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. Well, as you said this bug was RC, and Etch is close to release, it seems only logical that error reports like this should happen against the sid (or testing) version. > 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. Sorry, I haven't received Steves response (will check the bug track later) but this almost impossible as this would require the trac maintainer know how the subversion package will develop. Maybe he does and forgot to update the dependencies before the release, but I know that it is sometimes even hard to know once own upstream, let alone all dependencies. If indeed stable RMs start to accept changes like the one requested here into stable, then of course maintainers could monitor in situ the development of their dependencies and could update their package if necessary in stable, but without this option any maintainer without a glass ball before release will loose. (This is not to say, that they might provide updated packages as extra service from their own repository). > 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. Yes. But *I* would have filed a bug as wishlist or minor asking the developer if he can find a way, retrospectivly updating the dependency or otherwise helping people backporting because a depenceny is "bug riddled" as you say. Please note that I am not a DD and have no affiliation with either trac nor subversion. Anyway, thanks for helping improving Debian and sorry if I sounded too harsh. As stated, I'll leave it up to the maintainer how to handle this bug (including the severity). Greetings Helge -- Dr. Helge Kreutzmann [EMAIL PROTECTED] Dipl.-Phys. http://www.helgefjell.de/debian.php 64bit GNU powered gpg signed mail preferred Help keep free software "libre": http://www.ffii.de/ http://www.bbc.co.uk/ This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this.
