On 12/29/07, Sebastian <xilonmu@gmail.com> wrote:
I'm having a problem figuring out how to cleanly handle dependencies that exist in the official repositories. I have implemented tracking dependencies that are within AUR, but since we don't have access to the main site database it's hard to manage the packages that depend on official packages.
The way the current AUR handles this seems to be by simply linking to a search for that package, but that requires some messy alterations the current AUR2 database structure. It is one of the solutions, though probably a last resort.
It doesn't. You just use a defined url structure. http://some/url?q=<pkgname> There is no need to store the url in the database. Simply make it a setttings.py configuration value, something like OFFSITE_DEP_URL or some such...
Another solution would be to have some sort of inter-process communication (XML, JSON, whatever) so that AUR2 could get some information about the official packages and store them in the database. This of course brings about redundancy and again it's quite ugly.
I agree. Seems a bit ugly to me too.
The best solution would be to actually get access to the database and be able to easily reference those packages. If we had this access we could also work on improving and merging the code, since there is a lot of redundancy at the moment.
I don't think this is viable. Remember, the AUR was (should continue to be) designed in such a way that it could be run by someone not on the arch server. Direct database access to the main arch repository would be a huge step in the wrong direction for this, in my opinion.
Here's the schema for the package, category and repository relations, in case you'd like more insight into the database structure. As you will see it would be a little difficult to make a record with just the URL pointing to a search on the main site.
{% for dep in pkg.deps %} <a href="http://archlinux.org/packages/search/?q={{ dep }}">{{ dep }}</a><br /> {% endfor %} or whatever.. The main site search functionality returns the details page if there is a single match. This isn't quite "optimal", as for packages like vim, it will return a list. A better solution may be to add an additional search argument to the search page, such that 'exact' matches are only attempted instead. eg a seach on vim would only return details on the vim package itself, instead of a list of packages with "vim" in the name.