[aur-dev] Split package support
Hi, I changed my mind again and I think the next release should be 3.0.0, bringing full meta data and split package support. This is my idea of how split packages should be displayed: * One page per built package. Comments, votes and maintainer information are shared among packages that belong to the same PKGBUILD, though. The delete and merge functions will also operate on package bases, not on built packages. * A new pkgbase field on the package details page that is clickable and starts a package search on all packages belonging to the same base. The AUR already tags packages with properties of the corresponding binary packages (think of dependencies) and people want (need?) this, so this seems like the right thing to do. What do you think of that? Any objections? Regards, Lukas
On Sat, Jan 18, 2014 at 03:16:36PM +0100, Lukas Fleischer wrote:
Hi,
I changed my mind again and I think the next release should be 3.0.0, bringing full meta data and split package support.
Yay! Does this also mean we'll be extending the replies from the RPC API?
This is my idea of how split packages should be displayed:
* One page per built package. Comments, votes and maintainer information are shared among packages that belong to the same PKGBUILD, though. The delete and merge functions will also operate on package bases, not on built packages.
* A new pkgbase field on the package details page that is clickable and starts a package search on all packages belonging to the same base.
What about having detail pages for the pkgbase? Maybe use a new route like /pkgbase/foobase. It could display all the comments, maintainership info, actions, and also have direct links to the corresponding output packages. This would make it easier to refer to packages as a whole. I'm particularly thinking about posting on aur-general for help with merge/delete/orphan requests. Package detail pages could then link back to their pkgbase page.
On Sat, 18 Jan 2014 at 15:38:52, Dave Reisner wrote:
On Sat, Jan 18, 2014 at 03:16:36PM +0100, Lukas Fleischer wrote:
Hi,
I changed my mind again and I think the next release should be 3.0.0, bringing full meta data and split package support.
Yay! Does this also mean we'll be extending the replies from the RPC API?
We should do that, yes!
This is my idea of how split packages should be displayed:
* One page per built package. Comments, votes and maintainer information are shared among packages that belong to the same PKGBUILD, though. The delete and merge functions will also operate on package bases, not on built packages.
* A new pkgbase field on the package details page that is clickable and starts a package search on all packages belonging to the same base.
What about having detail pages for the pkgbase? Maybe use a new route like /pkgbase/foobase. It could display all the comments, maintainership info, actions, and also have direct links to the corresponding output packages. This would make it easier to refer to packages as a whole. I'm particularly thinking about posting on aur-general for help with merge/delete/orphan requests. Package detail pages could then link back to their pkgbase page.
That sounds like an even better idea. So we're making the package pages look like the archweb package pages, with PKGBUILD and tarball links. But do we include comments etc. from the pkgbase there as well? Or rather have the actions and comments on the pkgbase pages only? And when searching, we only return package pages?
On Sat, Jan 18, 2014 at 03:52:09PM +0100, Lukas Fleischer wrote:
On Sat, 18 Jan 2014 at 15:38:52, Dave Reisner wrote:
On Sat, Jan 18, 2014 at 03:16:36PM +0100, Lukas Fleischer wrote:
Hi,
I changed my mind again and I think the next release should be 3.0.0, bringing full meta data and split package support.
Yay! Does this also mean we'll be extending the replies from the RPC API?
We should do that, yes!
This is my idea of how split packages should be displayed:
* One page per built package. Comments, votes and maintainer information are shared among packages that belong to the same PKGBUILD, though. The delete and merge functions will also operate on package bases, not on built packages.
* A new pkgbase field on the package details page that is clickable and starts a package search on all packages belonging to the same base.
What about having detail pages for the pkgbase? Maybe use a new route like /pkgbase/foobase. It could display all the comments, maintainership info, actions, and also have direct links to the corresponding output packages. This would make it easier to refer to packages as a whole. I'm particularly thinking about posting on aur-general for help with merge/delete/orphan requests. Package detail pages could then link back to their pkgbase page.
That sounds like an even better idea. So we're making the package pages look like the archweb package pages, with PKGBUILD and tarball links. But do we include comments etc. from the pkgbase there as well? Or rather have the actions and comments on the pkgbase pages only?
If comments, etc. will be shared amongst all output packages, then it makes sense, to me, to also load them on the pkgbase page.
And when searching, we only return package pages?
Agreed.
On Sat, 18 Jan 2014 at 16:00:50, Dave Reisner wrote:
On Sat, Jan 18, 2014 at 03:52:09PM +0100, Lukas Fleischer wrote: [...]
That sounds like an even better idea. So we're making the package pages look like the archweb package pages, with PKGBUILD and tarball links. But do we include comments etc. from the pkgbase there as well? Or rather have the actions and comments on the pkgbase pages only?
If comments, etc. will be shared amongst all output packages, then it makes sense, to me, to also load them on the pkgbase page.
And when searching, we only return package pages?
Agreed.
So the plan is: * Create a "PackageBases" table with a "Name" column and transfer the following fields from the "Packages" table: - CategoryID (?) - NumVotes - OutOfDateTS - SubmittedTS - ModifiedTS - SubmitterUID - MaintainerUID * Change the foreign key references in PackageVotes, PackageComments and CommentNotify. * Write a migration script that converts the tables accordingly. We probably want to use the package name as pkgbase name for existing packages. * Adjust the package submission script: Create pkgbase and packages on submission (check all packages for conflicts with existing ones, filter all packages using the blacklist, etc.!) * Redesign the UI: Add pkgbase pages that contain links to all packages belonging to the pkgbase and also provide package actions and comments/votes (do we want to add these to non-split packages as well?) The package pages contain links to the corresponding pkgbase pages as well. * Adjust the RPC interface and add missing features/information. Did I miss anything?
participants (2)
-
Dave Reisner
-
Lukas Fleischer