On Tue, Sep 11, 2007 at 03:22:35PM +0200, Frank Lichtenheld wrote:
> On Tue, Sep 11, 2007 at 02:17:57PM +0200, Bas Wijnen wrote:
> > On Tue, Sep 11, 2007 at 02:02:15PM +0200, Frank Lichtenheld wrote:
> > > On Tue, Sep 11, 2007 at 12:41:21PM +0200, Bas Wijnen wrote:
> > > > It would be nice if lintian would complain about improper or missing
> > > > dependencies for -data packages. That is, if both $package and
> > > > $package-data are defined in debian/control, $package should have
> > > > Depends: $package-data (= ${source:version})
> > >
> > > Huh? May it should or maybe not. There is really no way to tell...
> >
> > Well, by convention -data packages are just the arch: all parts of the
> > package. In general, there is a hard dependency on it. Perhaps not
> > always, but then the packages are at least confusingly named. And if
> > there is a good reason, it is so rare (I expect) that an override is in
> > order. Or do you see "normal" cases where such a depends is not needed?
>
> The only common reason I see to use a = dependency
Oh, the = was just because I expect it to be safest. That is, the
package was likely only tested (by the maintainer) with the data package
of the same version. The point wasn't really the version, but the fact
that there should be a dependency.
> is a shared /usr/share/doc repository (and that is for legal reasons,
> not really for technical ones). Most other -data packages could
> probably happily live with some kind of >= dependency. And I would
> oppose encouraging maintainers to use overly strict dependencies.
Well, upstream may change formats of data files. Of course it would be
possible to add Conflicts from new data packages with old program
packages, but that is easily forgotten. I don't really see any harm in
requiring to have the data from the same source as the program, but I
don't have much problem with not warning about that. My request was
really for a check on the dependency, I didn't expect anyone to disagree
on how the dependency should look.
> Maybe a check for _any_ Dependency (i.e. a Depends, Recommends, or Suggests)
> on the -data package would be useful,
It makes sense that a Recommends or Suggests on the -data package is a
concious decision of the maintainer to not use a Depends, and so
shouldn't trigger the warning. I'd still prefer if maintainers would
express this in the form of an override, though.
> but anything else sounds very prone to produce _harmful_ false
> positives.
I don't see what sort of harm you're expecting. Do you consider it
harmful if users need to download a new version of a data package (which
is available), when a new release is made? This is only a problem for
people who upgrade the program, but put the data package on hold. With
such a setup, I think they're asking for trouble. It _should_ be
supported, but you can't expect it to be tested at all, and IMO a good
way to solve this is by automatically holding the program package as
well.
Note that because it's the source version, binNMUs are happily accepted.
Only when a new package is built, with a new data package, is the
dependency auto-upgraded to require that new data package. I don't see
any harm in that. In fact, as I explained, I expect it to have positive
effects (that it's harder to get buggy package combinations on your
system).
> > > > Perhaps there should also be a warning if $package-data does not have
> > > > Recommends: $package
> > > > (with any version, I suppose.)
> > >
> > > Why not Suggests? Why any at all?
> >
> > Assuming still that the -data package just contains arch: all parts of
> > the other one, it is useless without the other one. So it will only be
> > installed without it in very unusual situations, which is what
> > Recommends is for.
>
> Fair enough. I still wouldn't issue a warning if there is a Suggests on
> the package.
As above, I agree in the sense that this is like an override by the
developer. I still wouldn't mind a warning, because I don't see any
situation where the Recommends would be incorrect, and the package names
aren't chosen wrongly.
Thanks,
Bas
--
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://pcbcn10.phys.rug.nl/e-mail.html
Attachment:
signature.asc
Description: Digital signature