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

Re: [iwj10@cus.cam.ac.uk: Bug#1402: `Packages' file doesn't contain `Provides' fields !!!!]

> Could someone volunteer to fix pdpkg?  I don't have any spare time to
> do it.
>> From: Ian Jackson <iwj10@cus.cam.ac.uk>
>> The Packages file on the FTP site does not contain any of the Provides
>> fields from the packages.
>> This completely breaks dselect's conflict/dependency system - many
>> dependencies are left unsatisfied or are satisfied by only a few
>> packages, because dselect doesn't see the Provides fields.

Unless somebody has hacked my old version to pieces, all you need to
do is add the field to @controlfields in the file "format" in the main
pdpkg directory.  Is this no longer the way it works?

>> In general it would appear that pdpkg, the program used to generate
>> the file, discards data it does not understand, rather than preserving
>> it.  GRRRRR!!!!  This will also break when packages start to use the
>> new names for the related-package fields, namely Suggests (was
>> Optional) and Recommends (was Recommended).

What the heck?  I made a "design" decision for pdpkg when it was meant
to be something completely different from what you all are using it
for now. It was meant to be something to generate up to date
maintainer informaiton, and that was it.  All the other crude was
added piecemeal.  Give me a _complete_ spec on what you want it to do,
and I will rewrite it, otherwise don't complain.  You need to tell me
how it should handle data, what it should do with data it doesn't know
about, what it should check for, yadda, yadda, yadda.


Reply to: