[aur-dev] [AUR2] How to go about official dependencies
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. 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. 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. The databases and sites could still be separate if need be, but it would be great to merge the code. I'm sure a lot of users would prefer to search packages in AUR on the main site as well, but I understand that it may look like AUR is in some way official or supported. Regardless, I'd like your opinion on how to go about this. 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. Table "aur_package" Column | Type | Modifiers ---------------+--------------------------+----------- name | character varying(30) | not null version | character varying(20) | not null release | smallint | not null description | character varying(180) | not null url | character varying(200) | repository_id | integer | not null category_id | integer | not null deleted | boolean | not null outdated | boolean | not null added | timestamp with time zone | not null updated | timestamp with time zone | not null Table "aur_category" Column | Type | Modifiers ---------------+--------------------------+----------- id | integer | not null name | character varying(20) | not null Table "aur_repository" Column | Type | Modifiers ---------------+--------------------------+----------- id | integer | not null name | character varying(20) | not null
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.
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.
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.
Actually, it isn't. You *would* lose modularity, and you would have even tighter coupling. Additionally, remote sql invocation over arbitrary remote networks isn't the greatest idea from both a performance and a security standpoint. The goal of the AUR2 should not be tighter coupling.
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.
With the rearchitecture of the main site, I don't think this is very feasible. I strongly feel that the AUR should remain "it's own app".
participants (2)
-
eliott
-
Sebastian