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