Hi Stephan;Before I forget, I noticed today that the package category codes are upper case which I did not mean to do and I'm going to swap those to lower case soon. Sorry for any inconvenience around that.
There is one thing I am wondering about, and it’s to do with package architectures. When invoking the getPkg method, I know the architecture of the package I am asking. When using getBulkPkg, there is only one architecture field for all requested packages. It appears that all the _source packages are not found by the web app, and I am thinking it may be due to the architecture („any“ ?) they provide (and I am asking for „x86_gcc2“). In theory, I could try to do bulk transfers grouped by architecture, but of course that would make the code more complicated. I wonder why the architecture has to be provided at all. Isn’t the web-app connected to a single repository, so the names should be already unique. Even if there are multiple repositories later, package names should never clash and if two repositories have packages of the same name, they should be a single entry in the web app anyway. In the web-app, it’s somewhat similar - why do we have to select the architecture, instead of - for example - filtering by architecture? One could see all architectures mixed in the list by default.
In short; I guess it will be possible with some re-work time (actual and elapsed) to change it to be a filter. I'll take a look into this in the next week or two, but it will be a breaking change on the API so we had better wait to get that sorted out before 'announcing' the system to a larger audience.
Yes, there are "any" and "source" pseudo-architectures. I have just checked and the "any" packages should come through regardless of which architecture you request. This applies to both the search as well as bulk API methods. I just updated the integration tests here to check this and it seems to be working.
Listing "source" packages is more tricky because there's no proper notion of "latest". For example, for "x86_gcc2", the latest GCC sources are 2.x and for "x86" the latest is 4.x. I'd suggest that listing source packages might not be a good idea -- maybe you (and I) would be better to check for the presence of a corresponding source package when somebody views a given actual binary package and indicate that sources are available on the package detail view. What are your thoughts on that?
I also have some suggestion for working with the web app interface. I think it would be great to see small icons (or letters in the first
Might be a good idea; I was wondering if I might try to provide some sort of a report (CSV etc...) in the future. That might be an easier way to digest that data because you could fiddle it around in a spreadsheet.
I am also wondering whether providing some info could be done with less layers. The icon could be set by drag & drop into the browser
Yes a good idea; I did think about this too, but it's basically a time thing. I'll probably have to stick with this for the time being and come back to it later.
I didn’t have any problems with navigation anymore, and it’s a nice
Thanks -- I think the last bug you raised around 'back button' behavior is still there although it may be quite hard to resolve owing to the way that the back-button works. I don't think that was a terribly serious one though.
cheers. -- Andrew Lindesay
