[Mageia-dev] Proposal for bugzilla

andre999 andr55 at laposte.net
Sat Dec 25 12:02:18 CET 2010

Maarten Vanraes a écrit :
> Op zaterdag 25 december 2010 10:18:17 schreef andre999:
>> Maarten Vanraes a écrit :
>>> Op donderdag 23 december 2010 22:23:56 schreef Ahmad Samir:
>>>> On 23 December 2010 22:01, Samuel Verschelde<stormi at laposte.net>   wrote:
>>>>> I remember some years ago you could choose the exact version of the
>>>>> package for which you reported a bug, from a list. I agree that
>>>>> improving the UI side helpers could be useful.
>>>>> Regards
>>>>> Samuel Verschelde
>>>> As was said by dmorgan, listing each SRPM slowed down bugzilla a lot;
>>>> the distro has a lot of SRPMS...
>>> an ajax search is better; it doesn't add much and only gets searched if
>>> you enter at least 2 chars, or something like that.
>>> if such an ajax is wanted, i can write that if i can use app-mageia-db or
>>> similar as a list.
>> OK, I did a little search on Ajax, and I think that I understand now.
>> It seems that you're proposing autocompletion on the text typed in the
>> field - and only matches will be downloaded.
>> But if it starts with 2 characters, there could be still 1000's of names
>> downloaded.
>> I would suggest that we would need at least 5 characters to restrict the
>> names downloaded to a reasonable number.
>> Also, there is another factor.  If we are looking for srpm names, but
>> the user enters binary rpm names, there will not necessarily be a match,
>> particularly if the srpm results in more than one binary rpm.
>> So in some cases this will not work.
>> But I have another idea.
>> Maybe we could have separate (binary) rpm and srpm fields.
>> There is a button on the page, which will invoke the command to give the
>> srpms associated with the binary rpms.
>> Would this be workable ?
>> Something that would execute
>>    $ rpm -q --qf '{sourcerpm}' {pkg-name}
>> and would automatically enter the result in the srpm field, or at least
>> display it so it could be typed in.
>> Of course, this would have to be done by the user experiencing the
>> problems, to ensure having the correct version.
>> We would also have to deal with the cases where more than one rpm has
>> the bug.
>> If we can automate this, we can dispense with the potential problems
>> associated with a list of srpms.  And it would be (at least somewhat)
>> more efficient both server and client side, as well.
>> Just an idea
>> André
> this is no more than sort of TAB completion on the urpmi commands.

That part I understand.
Only these values will be downloaded, so some online traffic.

> averagely 2 characters have ~600 possibilities; meaning that 2 chars give
> average 25 srpm results. in practice this can be 150 results or something

Your numbers are right.  Obviously I had one too many zeros.

> consider also the fact that these are src.rpm , so huge lib**** and the fact
> that we won't be starting with everything...

I was thinking of lib*, which is why I said more than 3 characters.

> imho instead of destroying an idea you don't know much about; why don't i
> implement it and then you can evaluate if it's bad or not.

Actually, I was trying brainstorming.  We all know that such ideas don't 
necessarily lead anywhere.
It is certain that your idea is a lot better than it first appeared.

However, invoking the rpm command has certain advantages.
Most importantly, if done on the system of the user finding the bug, it 
reports exactly the correct version of the srpm.

For example, on my system, if I type in the console exactly :

rpm -q --qf '%{sourcerpm}' binutils

_without_ the version, it returns :


_with_ the version, which is exactly what we want.

So I have a suggestion.
With your Ajax skills, I imagine that you would be capable of setting a 
button which automatically invokes that command on a binary rpm field, 
to fill a srpm field ?
Could you try that as well ?
If it works, then I think we would have a better solution.

I could try it, but my html/javascript skills are quite limited.
Just a suggestion.



More information about the Mageia-dev mailing list