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<[email protected]>   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 :

binutils-2.19.51.0.2-1mnb2.src.rpm

_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.

Regards

André

Reply via email to