[arch-dev-public] Repo Hierarchy for Makedepends
Do we care about makedepends being in repos lower down the hierarchy? The current Integrity Check email lists >170 issues in this category. If these are never going to be addressed, I suggest we remove it from the output so that the more important errors are focused on. Allan
Am 10.05.2012 03:28, schrieb Allan McRae:
Do we care about makedepends being in repos lower down the hierarchy?
The current Integrity Check email lists >170 issues in this category. If these are never going to be addressed, I suggest we remove it from the output so that the more important errors are focused on.
It is impossible to respect these unless you want to considerably blow up [core].
On Thu, May 10, 2012 at 7:44 AM, Thomas Bächler <thomas@archlinux.org> wrote:
Am 10.05.2012 03:28, schrieb Allan McRae:
Do we care about makedepends being in repos lower down the hierarchy?
The current Integrity Check email lists >170 issues in this category. If these are never going to be addressed, I suggest we remove it from the output so that the more important errors are focused on.
It is impossible to respect these unless you want to considerably blow up [core].
We can always make an exception for the [core] packages, especially if the makedepends have other (make)depends in extra/community. If we do something about it, we need to decide if the [core] repo can have makedepends in [community] or just in [extra]. If we move packages from community to core/extra, we need to be sure that it will have a maintainer (like the maintainer of the packages which makedepends on it, for example). It wouldn't make sense to move packages currently maintained by a TU in community to another repo where it will remain orphaned.
On 10 May 2012 18:48, Eric Bélanger <snowmaniscool@gmail.com> wrote:
On Thu, May 10, 2012 at 7:44 AM, Thomas Bächler <thomas@archlinux.org> wrote:
Am 10.05.2012 03:28, schrieb Allan McRae:
Do we care about makedepends being in repos lower down the hierarchy?
The current Integrity Check email lists >170 issues in this category. If these are never going to be addressed, I suggest we remove it from the output so that the more important errors are focused on.
It is impossible to respect these unless you want to considerably blow up [core].
We can always make an exception for the [core] packages, especially if the makedepends have other (make)depends in extra/community. If we do something about it, we need to decide if the [core] repo can have makedepends in [community] or just in [extra].
If we move packages from community to core/extra, we need to be sure that it will have a maintainer (like the maintainer of the packages which makedepends on it, for example). It wouldn't make sense to move packages currently maintained by a TU in community to another repo where it will remain orphaned.
We should have some sort of policy. Like this one for e.g.: If there is no other (make)depend in that repo you might want to promote it for the package that needs it in a higher repo, provided that there will be a maintainer in the new repo. Personally, I'd like it if each repo were made to be 'self-sufficient' (that is, include pkgs required at build time). -- GPG/PGP ID: C0711BF1
On Thu, May 10, 2012 at 3:28 AM, Allan McRae <allan@archlinux.org> wrote:
Do we care about makedepends being in repos lower down the hierarchy?
The current Integrity Check email lists >170 issues in this category. If these are never going to be addressed, I suggest we remove it from the output so that the more important errors are focused on.
My two cents: We should let core makedepend on extra. We should not let anything makedepend on AUR (I know we currently have optdepends on AUR, but I don't have an opinion on that). If possible, we should avoid makedepends from core/extra to community, but I don't know if this would cause a lot of problems. It is definitely better to have a package maintained in community than unmaintained in extra. Cheers, Tom
participants (5)
-
Allan McRae
-
Eric Bélanger
-
Rashif Ray Rahman
-
Thomas Bächler
-
Tom Gundersen