Re: dpkg-checkbuilddeps to generate a frontend friendly package list
> George Danchev wrote:
> >> 2: If the list is passed to some package tool, I see no reason to
> >> introduce/depend on some another functionality by dpkg.
> >
> > The hard dependency of libapt-pkg-perl could be avoided by a run-time
> > check in the script itself, and the installation of that package is only
> > suggested if the relevant functionality is to be used. Does that sound
> > sane enough?
> >
> > if ($frontend) {
> > eval { require AptPkg };
> > if ( $@ ) {
> > die "-f requires libapt-pkg-perl package to be installed\n";
> > }
> > }
>
> For me personally that still sounds as an unnecessary middle-level layer as
> I "have" an example implementation without it. But am I not a dpkg
> developer and YMMV.
If you want to perform sensible actions wrt package availability and versions
comparisons as frontends do, then it would make sense to engage some of their
functionality, that best being implemented on demand of course. Hence I would
really want to hear dpkg developers' opinion, hopefully they can find some time
to review it along with the options I gave in my initial mail. I updated the
patch to cope with AptPkg as a run-time dependency:
http://people.debian.org/~danchev/tmp/
P.S. and by the way I just don't fly such plains like "I have example shell
implementation", it is neither frontend feature-reusable, nor flexible. That
being my personal opinion of course.
--
pub 4096R/0E4BD0AB <people.fccf.net/danchev/key pgp.mit.edu>
Reply to: