Re: Inital Deb Filter

["Kevin Kubasik" <kevin kubasik net>]

On 4/23/06, D Bera <dbera web gmail com> wrote:
> > 1) Do we not want to index any dependency information at all? ATM I
> > was planning on leaving in the code in the deb filter that extracted
> > and stored all the dependencies, which might be a nice UI
> > feature/something that someone who writes a 'Package Backend' would
> > need.
>
> Dependencies add a certain level of complication, you need the name as
> well as version of packages. For the time being store the dependencies
> directly in FilterDeb; I will have a look at what I can extract about
> dependencies from RPM files push everything to FilterPackage. Showing
> a loooooooong list of dependencies (e.g. that of beagle ;- ) ) might
> not be easy in beagle-search :-D
>
> Just another thought, computing dependencies of a  package is
> complicated; there can be direct dependencies and then recersively one
> can compute many more indirect ones. Package-managers/installers are
> best trained to compute/show dependencies. Even if beagle can show the
> direct dependencies it probably wont (and shouldnt) try to compute and
> show the whole dependency tree.
>

Agreed, were not trying to be package managers here, I was just
thinking direct dependency info might be nice to display, but stopping
to thing, I'm hard pressed to come up with a situation where I would
be unhappy without that info when searching...

> > 2) Are we making the description a property or the text. In the debian
> > world, the Description of a package is 2-6 paragraphs detailing the
> > packages function. Which seems much more like something we should
> > treat as text (ie AppendText()) as opposed to a huge property.
> > Especially since debian package descriptions can be very long, we
> > would want to have the option of snippeting the descriptions, not
> > displaying the whole thing in the UI. (Hence why I have SnippetMode =
> > true).
>
> Ok. I agree with you. I will change description to be stored as text.
>
> > 3) ATM the FilterPackage class includes some information that Debian
> > archives do not include (ie license and homepage being the primary
> > culprits) Those fields can be left blank, but since the information is
> > not available in all packages, shouldn't it be just in the FilterRPM
> > class?
>
> Ahh.. I took the common intersection of Ebuild and RPM filters :)
> Yeah. Those should be removed and made specific to ebuild/rpm as appropriate.
> (Why doesnt debian store copyright information :O ?)

Debian doesn't store copyright info in a way accessible by dpkg-deb.
If the package is installed, then the COPYRIGHT.Debian file contains
that info. It didn't seem worth the effort of extracting, but it could
be done.

Also, with regards to homepage, should I store the maintainers e-mail
address there? (perhaps as a mailto: ?) debian does not encourage the
use of web pages as references since they can be transient. (although,
e-mails seem to be about the same, but w/e)
> I will fix filterrpm, filterebuild/filterpackage within the next few days.
>
> - dBera
>
> --
> -----------------------------------------------------
> Debajyoti Bera @ http://dbera.blogspot.com
> beagle / KDE fan
> Mandriva / Inspiron-1100 user
>


--
Cheers,
Kevin Kubasik
http://blog.kubasik.net/