On Sun, 2008-02-03 at 21:21 +0100, Cyril Brulebois wrote: > On 03/02/2008, Neil Williams wrote: > > 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”. What I meant was if dependencyA appears in the dpkg-shlibdeps list of "not needed" linkages for 'foo' but foo is nearly always installed alongside bar which uses symbols from dependencyA (i.e. dpkg-shlibdeps doesn't complain about dependencyA in the build of bar), then foo probably doesn't need to be altered. It's no absolutely necessary for foo to Depend on dependencyA but it doesn't hurt in the majority of cases. There are also cases where dpkg-shlibdeps reports an extra linkage where the library concerned is already packaged alongside a library that does need to be linked against the package - libdl is the most common. Until such time as Debian packages this library outside libc[0-9], then the warning from dpkg-shlibdeps just has to be ignored because no benefit arises from removing -dl. > 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. dpkg-shlibdeps is providing a more fine grained approach that can detect when a Depends: created using dh_shlibdeps is actually unnecessary. By "genuinely necessary" I was thinking of linkages that do not trigger this warning - i.e. the ones that we need to retain after trimming (whichever method is used for the trimming itself). > Blocking (or being blocked for) testing migration still hurts. Agreed. > > > 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. Well, it's not something I am doing for my own packages, yet, so I don't want to push it onto those maintainers whom I sponsor when I am not comfortable getting it to work on my own packages. I'm experimenting with a few things upstream where the upstream ./configure asks for the pkg-config data but then either does some parsing of it or substitutes a (shorter) replacement but pkg-config exists for a good reason and (IMHO) -Wl,as-needed isn't a complete solution to the problem (with or without zdefs). The complication is that tinkering with pkg-config data like this can trip up porters and cross builders and as my main workload is cross building, I'm not about to break my own work. :-) Now I'm all in favour of reducing spurious dependencies - as anyone would expect whilst working on making Debian small enough for embedded devices - but not at the cost of making more work for myself when cross building the same package. I just want to be sure the changes actually work before recommending them to others. IMHO, -Wl,--as-needed -Wl,zdefs is not at that stage, yet. A better solution, (probably) would be for big library packages to become more modular so that several pkg-config files are provided and applications are free to select libfoo-mini.pc or libfoo-default.pc or libfoo-extra.pc - lengthening the pkgconfig --libs data in each one. (The "missing" libs would migrate into Libs.private:) Getting that to work means creating decent management tools for the pc files for use upstream. Changing things just in Debian is not a long-term solution, IMHO (and will dramatically complicate the lives of those who are migrating Debian to new environments like embedded but also existing ones like Ubuntu et al). -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
signature.asc
Description: This is a digitally signed message part