Koji feature proposals

[Oliver Falk]

Mike Bonnet wrote:
> On Tue, 2009-01-06 at 21:51 +0100, Oliver Falk wrote:
>> Hi Mike!
>>
>> Mike Bonnet schrieb:
>>> I've just created tickets for a few Koji features that I've been wanting
>>> to implement for a while (as well as updated an old one), and I'm
>>> planning to devote some time to in the near future.  If you have any
>>> comments on these features feel free to post to the tickets, or talk to
>>> me at FUDCon this weekend.  Just figured people might want to see the
>>> direction that Koji is headed.  The future is now! :)
>> [ ... ]
>>
>>> drop the rpmfiles and rpmdeps tables: https://fedorahosted.org/koji/ticket/124
>> -1
>> Only if you provide the same functionality using another approach :-)
> 
> Yes, the plan is to query the information directly from the rpms rather
> than from the database.

You'll likely need to cache the list of files somewhere. Just to mention 
it: Using yum metadata isn't enough, as you'll only query the latest pkgs...

 > The content on the rpminfo page in the web UI
> should not change at all from the user perspective.

Good.

>> *I* do use it quite often; Find out which file belongs to which pkg(s).
>>
>> However, this was quite slow and now doesn't even seem to work in 
>> koji.fpo. :-(
> 
> Hmmm, it should be.  In what way is it not working?

Query for Files (eg. /bin/ls):

Mod_python error: "PythonHandler mod_python.publisher"

Traceback (most recent call last):

   File "/usr/lib/python2.4/site-packages/mod_python/apache.py", line 
299, in HandlerDispatch
     result = object(req)

   File "/usr/lib/python2.4/site-packages/mod_python/publisher.py", line 
213, in handler
     published = publish_object(req, object)

   File "/usr/lib/python2.4/site-packages/mod_python/publisher.py", line 
412, in publish_object
     return publish_object(req,util.apply_fs_data(object, req.form, 
req=req))

   File "/usr/lib/python2.4/site-packages/mod_python/util.py", line 439, 
in apply_fs_data
     return object(**args)

   File "/usr/share/koji-web/scripts/index.py", line 1680, in search
     start=start, dataName='results', prefix='result', order=order)

   File "/usr/share/koji-web/lib/kojiweb/util.py", line 123, in 
paginateMethod
     totalRows = getattr(server, methodName)(*args, **kw)

   File "/usr/lib/python2.4/site-packages/koji/__init__.py", line 1133, 
in __call__
     return self.__func(self.__name,args,opts)

   File "/usr/lib/python2.4/site-packages/koji/__init__.py", line 1378, 
in _callMethod
     raise err

Fault:

>>> noarch subpackage support: https://fedorahosted.org/koji/ticket/125
>> Duh? We do have already (at least one) packages that build arch-specific 
>> and noarch pkgs -> kernel or do we use some *hack* in the kernel.spec?
> 
> We use a hack in the kernel specfile and in the build system.  The
> noarch subpackage support in rpm is much more generic and flexible, and
> we need to support it without build system hacks.

OK. I wasn't quite sure how it's working now... However, now that I know 
I do understand.

>> And regarding your point: '... different arches build noarch subpackage 
>> with different contents'. Well, then it's definitly not *noarch*, is't 
>> it? :-)
> 
> True, but it's still possible, and we may need to check for this case
> and handle is appropriately (possibly by failing the build).

Yet another post install section processing script (YAPISPS) :-)

And yes, if it's not really noarch, it should fail. But shouldn't rpm 
itself check that? I mean, if someone writes a script to check that it 
should possibly go directly into rpm upstream sources...

-of