"Adam D. Barratt" <adam@adam-barratt.org.uk> writes:
> As I mentioned to Sune on IRC last night, the quilt tag's severity was
> copied from the equivalent dpatch tag (which was originally implemented
> as a warning and then moved to minor/certain during the transition).
>
> I've no problem with downgrading the severity, although we should make a
> corresponding change to the dpatch tag at the same time, unless there's
> some reason it's particularly worse for a dpatch to be missing a
> description.
I think they're equivalent cases. Personally, I vote for downgrading them
both. Unless there are any objections, I'll do that in a bit.
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
12-04-2008, 08:04 PM
"Adam D. Barratt"
Possibly excessive lintian warnings
On Thu, 2008-12-04 at 12:51 -0800, Russ Allbery wrote:
> "Adam D. Barratt" <adam@adam-barratt.org.uk> writes:
>
> > As I mentioned to Sune on IRC last night, the quilt tag's severity was
> > copied from the equivalent dpatch tag (which was originally implemented
> > as a warning and then moved to minor/certain during the transition).
> >
> > I've no problem with downgrading the severity, although we should make a
> > corresponding change to the dpatch tag at the same time, unless there's
> > some reason it's particularly worse for a dpatch to be missing a
> > description.
>
> I think they're equivalent cases. Personally, I vote for downgrading them
> both.
I agree...
> Unless there are any objections, I'll do that in a bit.
... and did that an hour ago. Apologies for not waiting a little longer
for objections / consensus.
Adam
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
12-04-2008, 08:09 PM
Russ Allbery
Possibly excessive lintian warnings
"Adam D. Barratt" <adam@adam-barratt.org.uk> writes:
> ... and did that an hour ago. Apologies for not waiting a little longer
> for objections / consensus.
Oh, no, it's no problem. I was being too conservative. Thank you!
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
12-04-2008, 08:12 PM
Russ Allbery
Possibly excessive lintian warnings
Sune Vuorela <nospam@vuorela.dk> writes:
> No. it actually wouldn't work.
>
> In kde, for example kdepim, contains applications like
> - korganizer
> - kaddressbook
> - kmail
> - kpilot
>
> With a -dbg package depending on all apps, the user will have to install
> all apps just for getting a backtrace for one application.
That's why the recommendation (which Lintian currently doesn't talk about;
will fix that) is that the debug package depend on the all of the
corresponding packages as alternatives. (korganizer | kaddressbook
| kmail ...) That way, you still get the checking that the version of the
debug package matches the version of the package for which it has debug
symbols, without the problem you cite. This is what I've done for other
packages and it seems to work reasonably well.
(Lintian may still be confused due to the lack of similarity between the
package name and the debug package name, but we may be able to fix that.)
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
12-04-2008, 09:21 PM
Russ Allbery
Possibly excessive lintian warnings
Sune Vuorela <nospam@vuorela.dk> writes:
> How would OR'ed depends work?
>
> let us look at a example:
>
> package: kdepim-dbg
> depends: korganizer (= ${binary:Version})|kaddressbook (=${binary:version})
> version: 4.1.3-1
>
> now, I install korganizer 4.1.3-1 and kdepim-dbg.
> later, 4.1.3-2 gets uploadde and I install kaddressbook.
> korganizer still fulfills the kdepim-dbg version.
> thus, the user is not anywhere better satisfied than before.
>
> The only thing that would work would be if dpkg and apt supported
> Conflicts: korganizer (!= $binary:Version), but that is as far as I can
> read in policy not valid, so I also don't expect the tools to support
> it.
Your case is somewhat unusual in that you're providing debugging symbols
for a bunch of packages that are otherwise fairly unrelated and can be
installed with a mix of version numbers. Most of the time, this is not
the case. In your case, this is only marginally useful; it does ensure
that the user has at least one relevant package installed, but no more
than that.