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

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:


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: