[arch-general] [extra] package depending on [community] package
Wasn't there a guideline somewhere against this? Should I raise bugs when I see this is taking place? Specific example that I just noticed is mpd, because libnfs in community updated. Of course, mpd was updated within 12 hours or so, and I understand packages are mostly best maintained by those who actually know/care about the project, hence I just want to ask the question, is this considered a bug or not?
On 11 February 2015 at 03:39, Oon-Ee Ng <ngoonee.talk@gmail.com> wrote:
Wasn't there a guideline somewhere against this? Should I raise bugs when I see this is taking place?
Specific example that I just noticed is mpd, because libnfs in community updated. Of course, mpd was updated within 12 hours or so, and I understand packages are mostly best maintained by those who actually know/care about the project, hence I just want to ask the question, is this considered a bug or not?
It seems to be an increasingly common occurrence -- the latest integrity check[1] reported 50 x86_64 extra/ packages that depend on community packages, whereas a year ago the same check found only 29[2]. I *think* the general rule is that core/ can depend on extra/, and extra/ can depend on community/, but core/ cannot depend on community/. I could only find one post supporting this theory, however. [3] [1] https://lists.archlinux.org/pipermail/arch-dev-public/2015-February/026973.h... [2] https://lists.archlinux.org/pipermail/arch-dev-public/2014-February/025862.h... [3] https://lists.archlinux.org/pipermail/arch-dev-public/2011-May/020396.html
We are talking about runtime dependencies here, not build or test. core/ should be selfcontained, packages in core/ only depend on other core/ packages. All packages can depend on /core since its considered mandatory. Hence the name, you can run arch with just this repo. extra/ is maintained by arch devs and contains additional software that is "considered crucial to the distribution." [1] /community is maintained by TUs and contains even more additional but not-so-crucial software. And AUR is the free-for-all for everything else. Only AUR packages can depend in AUR packages, nothing else. /extra and /community are both considered safe and cross-dependencies should be fine, but imho /extra shouldn't depend on /community. But this would mean that our beloved arch devs will have to adopt every single dependency (which sounds like quite a bit of additional work), or to disable certain features to prevent such dependencies. There is afaik no rule that prevents /extra packages from depending on /community, but the number should be kept small. [1] <https://wiki.archlinux.org/index.php/Official_repositories#community> https <https://wiki.archlinux.org/index.php/Official_repositories#community> :// <https://wiki.archlinux.org/index.php/Official_repositories#community> wiki.archlinux.org <https://wiki.archlinux.org/index.php/Official_repositories#community>/ <https://wiki.archlinux.org/index.php/Official_repositories#community> index.php <https://wiki.archlinux.org/index.php/Official_repositories#community>/ <https://wiki.archlinux.org/index.php/Official_repositories#community> Official_repositories <https://wiki.archlinux.org/index.php/Official_repositories#community># <https://wiki.archlinux.org/index.php/Official_repositories#community> community <https://wiki.archlinux.org/index.php/Official_repositories#community> Am 12.02.2015 11:54 schrieb "WorMzy Tykashi" <wormzy.tykashi@gmail.com>:
On 11 February 2015 at 03:39, Oon-Ee Ng <ngoonee.talk@gmail.com> wrote:
Wasn't there a guideline somewhere against this? Should I raise bugs when I see this is taking place?
Specific example that I just noticed is mpd, because libnfs in community updated. Of course, mpd was updated within 12 hours or so, and I understand packages are mostly best maintained by those who actually know/care about the project, hence I just want to ask the question, is this considered a bug or not?
It seems to be an increasingly common occurrence -- the latest integrity check[1] reported 50 x86_64 extra/ packages that depend on community packages, whereas a year ago the same check found only 29[2].
I *think* the general rule is that core/ can depend on extra/, and extra/ can depend on community/, but core/ cannot depend on community/. I could only find one post supporting this theory, however. [3]
[1] https://lists.archlinux.org/pipermail/arch-dev-public/2015-February/026973.h... [2] https://lists.archlinux.org/pipermail/arch-dev-public/2014-February/025862.h... [3] https://lists.archlinux.org/pipermail/arch-dev-public/2011-May/020396.html
On Thu, Feb 12, 2015 at 9:48 PM, Marko Hauptvogel <marko.hauptvogel@googlemail.com> wrote:
There is afaik no rule that prevents /extra packages from depending on /community, but the number should be kept small.
As long as there is no rule (and don't get me wrong, I'm not in favour of unnecessary bureaucracy) then there's no issue here. As packages from [extra] depend on those in [community] I wonder whether it would make sense for TUs and devs to coordinate rebuilds. I understand that in the case of [core]/[extra] most devs updating a library just simply trigger a pkgrel update for rebuilding since they have the proper access rights, but obviously TUs don't for [core]/[extra]. Using [community-testing] and [testing] for this purpose also comes down to the same issue as I don't think TUs can move packages from [testing].
On Fri, 13 Feb 2015 10:31:44 +0800 Oon-Ee Ng <ngoonee.talk@gmail.com> wrote:
On Thu, Feb 12, 2015 at 9:48 PM, Marko Hauptvogel <marko.hauptvogel@googlemail.com> wrote:
There is afaik no rule that prevents /extra packages from depending on /community, but the number should be kept small.
As long as there is no rule (and don't get me wrong, I'm not in favour of unnecessary bureaucracy) then there's no issue here. As packages from [extra] depend on those in [community] I wonder whether it would make sense for TUs and devs to coordinate rebuilds. I understand that in the case of [core]/[extra] most devs updating a library just simply trigger a pkgrel update for rebuilding since they have the proper access rights, but obviously TUs don't for [core]/[extra]. Using [community-testing] and [testing] for this purpose also comes down to the same issue as I don't think TUs can move packages from [testing].
TUs can create rebuild todo lists the same as devs can. In this case, it was simply missed. It happens. Doug
TUs can create rebuild todo lists the same as devs can. In this case, it was simply missed. It happens.
Thanks, does the final move from [testing] and [community-testing] need to be done by a dev though?
On 11 February 2015 at 09:39, Oon-Ee Ng <ngoonee.talk@gmail.com> wrote:
Wasn't there a guideline somewhere against this? Should I raise bugs when I see this is taking place?
Specific example that I just noticed is mpd, because libnfs in community updated. Of course, mpd was updated within 12 hours or so, and I understand packages are mostly best maintained by those who actually know/care about the project, hence I just want to ask the question, is this considered a bug or not?
Optional deps can be in a repo lower in the hierarchy. I don't know when folks started leaving runtime deps in a lower repo, but ideally that should not happen. The rationale for this is simple: choose to disable [community], and see if any package breaks. Likewise, choose to disable [extra], and see if any package from [core] breaks. This is about the only functional requirement that needs to be met, and any practice that violates this is bad practice. -- GPG/PGP ID: C0711BF1
participants (5)
-
Doug Newgard
-
Marko Hauptvogel
-
Oon-Ee Ng
-
Rashif Ray Rahman
-
WorMzy Tykashi