Re: [Patch] Function for getting the value of an arbitrary control field

[David Kalnischkies <kalnischkies+debian@gmail.com>]

Hi Jonathan Thomas,

On Thu, Jan 6, 2011 at 02:28, Jonathan Thomas <echidnaman@gmail.com> wrote:
> I was wondering if there was any interest for a patch to allow an application to get the value of an arbitrary debian/control field via a pkgRecords::Parser object. The usecase would be for obtaining the values of nonstandard fields such as the "Supported" field of Ubuntu packages in main, or any of the several metadata fields that the GStreamer packages have. ("Gstreamer-Decoders", "Gstreamer-Elements", etc)

Thanks! Yes its interesting as at least one front-end uses it (yours). :)
(a quick glance shows that aptitude does it too for e.g. Tags)
So moving it to libapt-pkg directly is not a problem, beside that it adds
virtual methods which manifests directly as an ABI break, so we will
properly wait until more ABI-breaking stuff has accumulated before
committing and therefore introducing these method official, so please
be patient with us. :)


In the meantime:

>    pkgRecords::Parser &rec = d->records->Lookup(ver.FileList());
>    const char *start, *stop;
>    rec.GetRec(start, stop);
>    QString record(start);
>
>    QStringList lines = record.split('\n');
>
>    Q_FOREACH (const QString &line, lines) {
>        if (line.startsWith(name)) {
>            field = line.split(": ").at(1);
>            break;
>        }
>    }

Looks a bit strange to me as it doesn't use the stop pointer.
And in general, wouldn't it be easier to use pkgTagSection
Scan() and Find() instead of this homegrown splitting?
(just trying to understand what will be replaced in the future)


> Please CC me in replies, since I am not subscribed to this list.
Done, but feel free to subscribe - this is far from being a hightraffic
list and you maybe came across something interesting here, who knows…


Best regards

David Kalnischkies