[aur-dev] [AUR2] How to go about official dependencies

Sebastian xilonmu at gmail.com
Tue Jan 1 02:53:21 EST 2008


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

The database servers don't need to be on the same host in order to
connect to them. It's possible to make use of the database without
losing any modularity on AUR2's part.
I was talking with Dan about "standardising" the main site and AUR,
mainly in terms of Django models, because the two sites are so
similar. AUR could easily simply be a Django app that the main site
uses. It's a bit off-topic, but I don't think integrating the sites in
some way (at least to be able to duplicate code easily) would be a bad
move.

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

In order to do it that way we'd need to add another field like
"official_deps" to the Packages relation. It would be a foreign key to
an official_dependency relation holding only the name of the package
(and possibly the url). Not a great solution, but possibly the
quickest to implement.




More information about the aur-dev mailing list