You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Oct 11, 2020. It is now read-only.
Recently the PKGBUILD specification was modified to support split packages (building multiple binary packages from a single PKGBUILD). This is problematic since the database schema doesn't support "sub packages." There are two ways that I can think of to show this information. Having one package per split package, resulting in quite a bit of duplicate data in the database, however without altering the database schema. The other is to have a single package encapsulating the sub-packages (reflecting the PKGBUILD specification). This would require modification of the database schema, search logic (sub packages would need to be searched) and templates.
The first solution is definitely simpler, but a problem arises when deleting or updating a package. The split packages would appear in the listing, potentially confusing users.
The second solution is more elegant, especially to the end-user, but is an order of magnitude more complex to implement.
Recently the PKGBUILD specification was modified to support split packages (building multiple binary packages from a single PKGBUILD). This is problematic since the database schema doesn't support "sub packages." There are two ways that I can think of to show this information. Having one package per split package, resulting in quite a bit of duplicate data in the database, however without altering the database schema. The other is to have a single package encapsulating the sub-packages (reflecting the PKGBUILD specification). This would require modification of the database schema, search logic (sub packages would need to be searched) and templates.
The first solution is definitely simpler, but a problem arises when deleting or updating a package. The split packages would appear in the listing, potentially confusing users.
The second solution is more elegant, especially to the end-user, but is an order of magnitude more complex to implement.