Hi all.

While working on my overlay, I stumbled on an issue where qfile refused
to acknowledge an installed file as being part of my package.


Looking into q's implementation (portage-utils-0.1.29), I see:

amit0 portage-utils-0.1.29 # grep -A 2 next_entry ./libq/vdb_get_next_dir.c
next_entry:
ret = readdir(dir);
if (ret == NULL) {
--
goto next_entry;
if (strchr(ret->d_name, '-') == NULL)
if ((strcmp(ret->d_name, "virtual")) != 0)
goto next_entry;

I encountered this since I used a new category, which only contained a
single word. Adding a hyphen and a 2nd token solved my issue, and now
qfile knows the file's association.


Is this assumption, that category should be "stringA-stringB" documented
somewhere?


10x,
Amit

On Monday 16 March 2009 14:35:15 Ned Ludd wrote:
> On Mon, 2009-03-16 at 18:34 +0200, Amit Dor-Shifer wrote:
> > Hi all.
> >
> > While working on my overlay, I stumbled on an issue where qfile refused
> > to acknowledge an installed file as being part of my package.
> >
> > Looking into q's implementation (portage-utils-0.1.29), I see:
> >
> > amit0 portage-utils-0.1.29 # grep -A 2 next_entry
> > ./libq/vdb_get_next_dir.c next_entry:
> > ret = readdir(dir);
> > if (ret == NULL) {
> > --
> > goto next_entry;
> > if (strchr(ret->d_name, '-') == NULL)
> > if ((strcmp(ret->d_name, "virtual")) != 0)
> > goto next_entry;
> >
> > I encountered this since I used a new category, which only contained a
> > single word. Adding a hyphen and a 2nd token solved my issue, and now
> > qfile knows the file's association.
> >
> > Is this assumption, that category should be "stringA-stringB" documented
> > somewhere?
>
> We made that assumption for portage-utils as they can be used on a
> device which has no $PORTDIR at all. So when there is no categories file
> that exists we fell back to the rules that have been working well for
> the past %d years.
>
> We changed that behavior however a while ago. I thought this was in the
> tree. But I guess not if you are hitting it.
>
> http://sources.gentoo.org/viewcvs.py/gentoo-projects/portage-utils/libq/vdb
>_get_next_dir.c?r1=1.2&r2=1.3

we should do a new release already
-mike

On Monday 16 March 2009 18:49:04 Ned Ludd wrote:
> On Mon, 2009-03-16 at 17:05 -0400, Mike Frysinger wrote:
> > On Monday 16 March 2009 14:35:15 Ned Ludd wrote:
> > > On Mon, 2009-03-16 at 18:34 +0200, Amit Dor-Shifer wrote:
> > > > Hi all.
> > > >
> > > > While working on my overlay, I stumbled on an issue where qfile
> > > > refused to acknowledge an installed file as being part of my package.
> > > >
> > > > Looking into q's implementation (portage-utils-0.1.29), I see:
> > > >
> > > > amit0 portage-utils-0.1.29 # grep -A 2 next_entry
> > > > ./libq/vdb_get_next_dir.c next_entry:
> > > > ret = readdir(dir);
> > > > if (ret == NULL) {
> > > > --
> > > > goto next_entry;
> > > > if (strchr(ret->d_name, '-') == NULL)
> > > > if ((strcmp(ret->d_name, "virtual")) != 0)
> > > > goto next_entry;
> > > >
> > > > I encountered this since I used a new category, which only contained
> > > > a single word. Adding a hyphen and a 2nd token solved my issue, and
> > > > now qfile knows the file's association.
> > > >
> > > > Is this assumption, that category should be "stringA-stringB"
> > > > documented somewhere?
> > >
> > > We made that assumption for portage-utils as they can be used on a
> > > device which has no $PORTDIR at all. So when there is no categories
> > > file that exists we fell back to the rules that have been working well
> > > for the past %d years.
> > >
> > > We changed that behavior however a while ago. I thought this was in the
> > > tree. But I guess not if you are hitting it.
> > >
> > > http://sources.gentoo.org/viewcvs.py/gentoo-projects/portage-utils/libq
> > >/vdb _get_next_dir.c?r1=1.2&r2=1.3
> >
> > we should do a new release already
>
> Why yes.. Yes you should

if you dont do it before me, i'll probably try and do it this weekend. btw, i
went through the bug reports and saw qcache crashes ... are those still
relevant ?
-mike

On Tuesday 17 March 2009 12:59:58 Ned Ludd wrote:
> There is also a bug with atom parsing iirc on 32bit platforms. gradm was
> the test case. Think we need to change from int to long.

the code is documented as having 64bit limitations for any specific component.
the last release doesnt have the updated work i did in qatom to handle the
latest atom spec though, and that includes moving from 32bit to 64bit for
components ...

> Maybe another with -rX parsing.

if you're thinking of the open bug, that's an eprefix specific extension.
they turned the X in -rX into a floating point #. which isnt supported
currently.
-mike