[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RFS: avant-window-navigator 0.2.1



On 03/02/2008, Neil Williams wrote:
> > Note that this might still break the build system, but that *is* a
> > good thing.
>
> (Agreed, but is probably easier to fix upstream than in Debian,
> YMMV).

Well, if you're packaging something, basic understanding on what the
code is doing, what submodules exist and so on, is expected. That's
IMHO a very good way to get more and more familiar with upstream's
code. And helping upstream fix this kind of problem is usually very
welcome (beside being part of the maintainer's job — I mean: working
together with upstream).


> but if that extra dependency is genuinely necessary for some other
> application which would almost inevitably be installed alongside the
> package in question, then no harm is done.

I don't buy this “genuinely necessary”. There are some exceptions, but
dependencies between binaries (as in executables and shared objects,
or -data packages are what I call “genuinely necessary”. I'm not going
to second-guess what is then necessary besides that. If there are more
to come, that should be in Depends: anyway (like the -bin of a
library, in addition to ${shlibs:Depends}), or Recommends or whatever.

Blocking (or being blocked for) testing migration still hurts.

> > That's a bit of work, but you'll probably end up with less
> > dependencies (expressed in less Depends:), which is obviously
> > (installed size, testing migration, etc.) a good thing.
>
> Agreed, it is a v.good thing. Not sure it is yet something we should
> be advising on mentors, that's all. It may well be harder than
> expected and the methods are not that user-friendly.

Why? Maintaining a package is not (just) about making lintian happy
and uploading new versions. Getting rid of extra dependencies is IME a
very good learning experience, and I wish it would be the kind of
questions asked during T&S (at least: I'd have been glad to have to
work on this kind of problem).

And it's (still IMHO) a very good occasion to learn about linker
flags, and possibly have a deeper view on how autotools, cmake, scons
(erk) deal with that.

Cheers,

-- 
Cyril Brulebois, still in NM, FWIW.

Attachment: pgp85atDyQCiD.pgp
Description: PGP signature


Reply to: