On Wednesday, September 21, 2016 12:16:39 PM CEST buildsys@fedoraproject.org wrote:
vim-syntastic has broken dependencies in the rawhide tree: On aarch64: vim-syntastic-lisp-3.7.0-6.fc26.noarch requires clisp On aarch64: vim-syntastic-cs-3.7.0-6.fc26.noarch requires mono-core On aarch64: vim-syntastic-d-3.7.0-6.fc26.noarch requires ldc On armhfp: vim-syntastic-d-3.7.0-6.fc26.noarch requires ldc Please resolve this as soon as possible.
What's should packager do in such case? Recap: noarch package depends on arch-dependant package, which is not available everywhere.
Pavel
On Wed, Sep 21, 2016 at 11:32 AM, Pavel Raiskup praiskup@redhat.com wrote:
On Wednesday, September 21, 2016 12:16:39 PM CEST buildsys@fedoraproject.org wrote:
vim-syntastic has broken dependencies in the rawhide tree: On aarch64: vim-syntastic-lisp-3.7.0-6.fc26.noarch requires clisp On aarch64: vim-syntastic-cs-3.7.0-6.fc26.noarch requires mono-core On aarch64: vim-syntastic-d-3.7.0-6.fc26.noarch requires ldc On armhfp: vim-syntastic-d-3.7.0-6.fc26.noarch requires ldc Please resolve this as soon as possible.
What's should packager do in such case? Recap: noarch package depends on arch-dependant package, which is not available everywhere.
ldc 1.0.0 supports ARM properly and has preliminary support for AArch64[1]. Upgrading to ldc 1.0.0 should solve that dependency issue.
Not sure how to solve clisp and mono-core...
[1]: https://github.com/ldc-developers/ldc/releases/tag/v1.0.0
"PR" == Pavel Raiskup praiskup@redhat.com writes:
PR> What's should packager do in such case? Recap: noarch package PR> depends on arch-dependant package, which is not available PR> everywhere.
Then the package is not noarch. Make it archful, add ExcludeArch: appropriately.
- J<
On Wednesday, September 21, 2016 11:37:09 AM CEST Jason L Tibbitts III wrote:
"PR" == Pavel Raiskup praiskup@redhat.com writes:
PR> What's should packager do in such case? Recap: noarch package PR> depends on arch-dependant package, which is not available PR> everywhere.
Then the package is not noarch. Make it archful, add ExcludeArch: appropriately.
Here comes the same argument as with ExclusiveArch .. I don't want to, because this _is_ noarch package and _is_ expected to work on all arches, at some point.
If I blacklist some arches today, I'll likely never enable the package for the blacklisted architectures.
Is it wrong to simply let things as are? Does it hurt some process in Fedora (except for additional traffic in my INBOX)?
Pavel
"PR" == Pavel Raiskup praiskup@redhat.com writes:
PR> Here comes the same argument as with ExclusiveArch .. I don't want PR> to, because this _is_ noarch package and _is_ expected to work on PR> all arches, at some point.
It's not noarch, sorry. It doesn't work on all architectures, regardless of whether it has any compiled code.
PR> If I blacklist some arches today, I'll likely never enable the PR> package for the blacklisted architectures.
Nothing technical prevents you from doing so. If the issue is whether you'll remember, I'm not sure what to suggest. I have the same problem, but it's unrelated to packaging, so....
PR> Is it wrong to simply let things as are? Does it hurt some process PR> in Fedora (except for additional traffic in my INBOX)?
Yes, people using those architectures will have a package they cannot install. We don't permit such broken dependencies in the distribution.
There has been talk before of some hack to make packages like this still pretend to be noarch, but since the proper solution is so simple (remove BuildArch: noarch and add ExclusiveArch:) there's not really been much incentive to implement it.
I do see this become more of an issue with every new arch bringup unless they have rather complete coverage. The mere presence of some minor architecture shouldn't force a bunch of packages to suddenly become archful. Feel free to talk to the buildsys and releng folks about it (again). But the solution in your case is pretty obvious.
- J<
On Wednesday, September 21, 2016 11:57:06 AM CEST Jason L Tibbitts III wrote:
"PR" == Pavel Raiskup praiskup@redhat.com writes:
PR> Here comes the same argument as with ExclusiveArch .. I don't want PR> to, because this _is_ noarch package and _is_ expected to work on PR> all arches, at some point.
It's not noarch, sorry. It doesn't work on all architectures, regardless of whether it has any compiled code.
Argh, yes. I've updated my noarch definition. "noarch" is not about content.
Sounds like there are two types of such noarch-looking non-noarch packages :), first which is expected to work everywhere at some point and the second where we know immediately that it will never work by it's definition.
For the first type of package, using ExclusiveArch is really just ugly work-around and additional work for packagers.
PR> If I blacklist some arches today, I'll likely never enable the PR> package for the blacklisted architectures.
Nothing technical prevents you from doing so. If the issue is whether you'll remember, I'm not sure what to suggest. I have the same problem, but it's unrelated to packaging, so....
Taking into account how easy (and consistent) is to remove that (sub)package, I tend to do that instead now. And that is :( in general, because that package could be useful to someone.
I don't think this point is unrelated to packaging though ... packaging tools should protect packagers from doing mistakes.
PR> Is it wrong to simply let things as are? Does it hurt some process PR> in Fedora (except for additional traffic in my INBOX)?
Yes, people using those architectures will have a package they cannot install. We don't permit such broken dependencies in the distribution.
Understood why _usually_ do not permit them, but the fact we _never_ permit them sounds like not-yet-fixed design issue.
There has been talk before of some hack to make packages like this still pretend to be noarch, but since the proper solution is so simple (remove BuildArch: noarch and add ExclusiveArch:) there's not really been much incentive to implement it.
That is not that trivial in case of this particular package, though. Removing the (sub)package is easier for me... The "hack" you talk about ..
I do see this become more of an issue with every new arch bringup unless they have rather complete coverage. The mere presence of some minor architecture shouldn't force a bunch of packages to suddenly become archful. Feel free to talk to the buildsys and releng folks about it (again).
.. would be about not tagging such packages into repos of affected architectures (that sounds wrong ..)? Can you point me to that discussion(s)?
Thanks, Pavel
First off, the guidelines have: https://fedoraproject.org/wiki/Packaging:Guidelines#Noarch_with_unported_dep...
I've been assuming that you're talking about the BuildRequires: case. If you're just talking about the case where you can build it anywhere because you're just copying files around, but it just won't install, then you can try doing the noarch/ExclusiveArch: trick. To be fair, I have no idea if it still works; I recall that some people really didn't like it. Of course if it doesn't work then I'll remove that bit from the guidelines. I've sent out a couple of questions to folks who should know better than I.
"PR" == Pavel Raiskup praiskup@redhat.com writes:
PR> Understood why _usually_ do not permit them, but the fact we _never_ PR> permit them sounds like not-yet-fixed design issue.
I can't imagine a situation where it would be acceptable for a user to type "dnf install foo" for something that's purely in Fedora and be greeted with an unsatisfied dependency error. I just can't.
PR> That is not that trivial in case of this particular package, though. PR> Removing the (sub)package is easier for me... The "hack" you talk PR> about ..
I have a difficult time believing that it would take longer than a minute to remove some BuildArch: statements and add ExclusiveArch: where necessary.
PR> .. would be about not tagging such packages into repos of affected PR> architectures (that sounds wrong ..)?
You still have to make sure that the packages are actually built on machines which can actually build the packages. That's actually not the same set of machines as the set of machines where the package would run. That's just something that needs to happen in the buildsystem.
PR> Can you point me to that discussion(s)?
The discussion has happened at various places over the history of the project, back to when PPC or somesuch was added and had no JVM support. In fact, I recall having a discussion about the true meaning of "noarch" back in the FC2-timeframe, but I just don't have references going back that far. Again, feel free to raise it with the buildsys people; I wouldn't be surprised if they have a canned response by now.
- J<
On Wednesday, September 21, 2016 12:55:48 PM CEST Jason L Tibbitts III wrote:
First off, the guidelines have: https://fedoraproject.org/wiki/Packaging:Guidelines#Noarch_with_unported_dep...
I've been assuming that you're talking about the BuildRequires: case. If you're just talking about the case where you can build it anywhere because you're just copying files around, but it just won't install, then you can try doing the noarch/ExclusiveArch: trick. To be fair, I have no idea if it still works; I recall that some people really didn't like it. Of course if it doesn't work then I'll remove that bit from the guidelines. I've sent out a couple of questions to folks who should know better than I.
Thanks a lot for this discussion. I'll go (probably) the hacky ExclusiveArch way, just because I want to give it a try. Once this becomes too tiring (because the package has non-trivial amount of run-time-only dependencies), I'll talk to releng team.
"PR" == Pavel Raiskup praiskup@redhat.com writes:
PR> Understood why _usually_ do not permit them, but the fact we _never_ PR> permit them sounds like not-yet-fixed design issue.
I can't imagine a situation where it would be acceptable for a user to type "dnf install foo" for something that's purely in Fedora and be greeted with an unsatisfied dependency error. I just can't.
Yeah, me neither. The thing is that it is unlikely anybody is going to install that package there ... but yes, that might happen.
The design issue (probably hard to solve) is that there is no automatic way to _not_ include such package into particular ARCH yum repo; and we rather bother packagers.
Thanks, Pavel
"PR" == Pavel Raiskup praiskup@redhat.com writes:
PR> The design issue (probably hard to solve) is that there is no PR> automatic way to _not_ include such package into particular ARCH yum PR> repo; and we rather bother packagers.
I'm not entirely sure how the compose tools would that a particular dependency issue is intentional. I guess it could take a complete set of all packages which have any ExcludeArch: or ExclusiveArch: tags and chase the dependency tree of each backwards to see if it hits any of those. Which is certainly a nontrivial thing but I guess if someone really wanted to write it....
- J<
On Thursday, September 22, 2016 12:45:32 PM CEST Pavel Raiskup wrote:
Thanks a lot for this discussion. I'll go (probably) the hacky ExclusiveArch way, just because I want to give it a try. Once this becomes too tiring (because the package has non-trivial amount of run-time-only dependencies), I'll talk to releng team.
The approach is here: http://pkgs.fedoraproject.org/cgit/rpms/vim-syntastic.git/commit/?id=8f4bf0f...
One issue happened to me during the first build attempt -- aarch64 builder was used while aarch64 was _not_ in all _sub_packages' ExclusiveArch: http://koji.fedoraproject.org/koji/taskinfo?taskID=15918394
The second attempt on x86_64 has been successful: http://koji.fedoraproject.org/koji/taskinfo?taskID=15918430
Is this related to? https://pagure.io/koji/issue/19
What is the work-around? Do I have to specify 'BuildArch: noarch' for all subpackages (would that help)? Do I have to try re-building until I get the right machine?
Pavel
On Monday, October 3, 2016 8:12:50 AM CEST Pavel Raiskup wrote:
On Thursday, September 22, 2016 12:45:32 PM CEST Pavel Raiskup wrote:
Thanks a lot for this discussion. I'll go (probably) the hacky ExclusiveArch way, just because I want to give it a try. Once this becomes too tiring (because the package has non-trivial amount of run-time-only dependencies), I'll talk to releng team.
The approach is here: http://pkgs.fedoraproject.org/cgit/rpms/vim-syntastic.git/commit/?id=8f4bf0f...
One issue happened to me during the first build attempt -- aarch64 builder was used while aarch64 was _not_ in all _sub_packages' ExclusiveArch: http://koji.fedoraproject.org/koji/taskinfo?taskID=15918394
The second attempt on x86_64 has been successful: http://koji.fedoraproject.org/koji/taskinfo?taskID=15918430
Is this related to? https://pagure.io/koji/issue/19
What is the work-around? Do I have to specify 'BuildArch: noarch' for all subpackages (would that help)? Do I have to try re-building until I get the right machine?
Even more interesting, %arm is not on ExclusiveArch list for 'vim-syntastic-d' package, while the build on arm machine succeeded: http://koji.fedoraproject.org/koji/taskinfo?taskID=15919447
What is the reason to fail on aarch64 then?
Pavel
On Monday, October 3, 2016 8:53:41 AM CEST Pavel Raiskup wrote:
On Monday, October 3, 2016 8:12:50 AM CEST Pavel Raiskup wrote:
On Thursday, September 22, 2016 12:45:32 PM CEST Pavel Raiskup wrote:
Thanks a lot for this discussion. I'll go (probably) the hacky ExclusiveArch way, just because I want to give it a try. Once this becomes too tiring (because the package has non-trivial amount of run-time-only dependencies), I'll talk to releng team.
The approach is here: http://pkgs.fedoraproject.org/cgit/rpms/vim-syntastic.git/commit/?id=8f4bf0f...
One issue happened to me during the first build attempt -- aarch64 builder was used while aarch64 was _not_ in all _sub_packages' ExclusiveArch: http://koji.fedoraproject.org/koji/taskinfo?taskID=15918394
The second attempt on x86_64 has been successful: http://koji.fedoraproject.org/koji/taskinfo?taskID=15918430
Is this related to? https://pagure.io/koji/issue/19
What is the work-around? Do I have to specify 'BuildArch: noarch' for all subpackages (would that help)? Do I have to try re-building until I get the right machine?
Even more interesting, %arm is not on ExclusiveArch list for 'vim-syntastic-d' package, while the build on arm machine succeeded: http://koji.fedoraproject.org/koji/taskinfo?taskID=15919447
What is the reason to fail on aarch64 then?
Heh, here it comes :)
| vim-syntastic has broken dependencies in the rawhide tree: | On aarch64: | vim-syntastic-lisp-3.7.0-8.fc26.noarch requires clisp | On aarch64: | vim-syntastic-d-3.7.0-8.fc26.noarch requires ldc | On armhfp: | vim-syntastic-d-3.7.0-8.fc26.noarch requires ldc | On aarch64: | vim-syntastic-cs-3.7.0-8.fc26.noarch requires mono-core | Please resolve this as soon as possible.
Seems like the ExclusiveArch for subset of sub-packages did not help at all.
Pavel
On Wednesday, September 21, 2016 12:55:48 PM CET Jason L Tibbitts III wrote:
First off, the guidelines have: https://fedoraproject.org/wiki/Packaging:Guidelines#Noarch_with_unported_dep...
I've been assuming that you're talking about the BuildRequires: case. If you're just talking about the case where you can build it anywhere because you're just copying files around, but it just won't install, then you can try doing the noarch/ExclusiveArch: trick. To be fair, I have no idea if it still works; I recall that some people really didn't like it. Of course if it doesn't work then I'll remove that bit from the guidelines. I've sent out a couple of questions to folks who should know better than I.
To close this for fedora-devel too, the ExclusiveArch trick probably doesn't work at least in my case [1] because:
- I set ExclusiveArch for set of sub-packages only - I've added 'noarch' into ExclusiveArch, because of the bug 1298668 Orion mentioned.
Can this be somehow reflected in guidelines [2]? I don't really know how, but at least in case of vim-syntastic -> I'm against adding ExclusiveArch into vim-syntastic (that means if single _sub_package doesn't work on say aarch64, every other sub-package will be excluded from aarch64).
[1] https://pagure.io/pungi-fedora/issue/87 [2] https://fedoraproject.org/wiki/Packaging:Guidelines
Pavel
packaging@lists.fedoraproject.org
-
Jason L Tibbitts III -
Neal Gompa -
Pavel Raiskup