Yes, of course it isn't installable yet. Let's give the other packagers more time to build their packages.

If it was know to be uninstallable, it should not have been built and released.  It is not allowed to have packages in EPEL with unresolved dependencies.

https://docs.fedoraproject.org/en-US/epel/epel-packaging/#package_dependencies

While EPEL 10 hasn't officially launched yet, that doesn't mean the policies can be outright ignored.  "Just wait for other packagers" is not a sufficient answer.  You should file bugs requesting those missing dependencies, and mark this bug as depending on them.  You can also volunteer to co-maintain the dependencies if you're willing, and then build them yourself if added.

https://docs.fedoraproject.org/en-US/epel/epel-package-request/

If this cannot be resolved in a reasonable amount of time (perhaps by the official EPEL 10 launch), this package will be untagged to remove it from the repos.  It's better for the package to not be present than to be present and uninstallable.  It can of course be re-added once all the dependencies are all present.

I would also recommend adding a %check section to the spec file.  Running the upstream test suite can indicate missing run-time dependencies and fail the build.  If running the test suite (even partially) isn't feasible, then it can help to have a basic "smoke test" in %check, such as a module load test.  This is a policy for Python packages, but non-Python packages like this one can also benefit from a similar approach.  Perhaps there are other PHP packages that can serve as a reference for this.

https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#_tests

Carl, your response is completely unhelpful.
You of all people should understand some leeway needs to be given to get new packages bootstrapped into a new branch, which has not been released yet.
No one is ignoring policy. If this branch were released, I'd agree with the position you are taking.

Rest assured, this will get taken care of by EPEL 10 release in Q4. If it is not, then feel free to remove the package.

You are also free to submit a PR for any changes you think are needed. I'll be glad to review them.

> Carl, your response is completely unhelpful.

I clarified the policy, shared the request process, and suggested a remediation plan if it can't be resolved in a reasonable amount of time.  I also suggested the smoke test approach that may prevent this from happening again.  I consider these things helpful.  The only thing I didn't do was file the bugs for you requesting the missing dependencies, which I think is reasonable to expect you to take care of since you pushed the uninstallable update.

> You of all people should understand some leeway needs to be given to get new packages bootstrapped into a new branch, which has not been released yet.

I can understand being a bit more flexible on this until the official launch, which is exactly what I suggested when I offered to let this stay in the current state until the official launch.  What more leeway did you have in mind?  Not filing bugs?  If I hadn't filed this bug, the request bugs for the dependencies wouldn't have been filed, and the most likely outcome would be this staying uninstallable for a much longer time, probably long after the official launch.  No thank you.

> No one is ignoring policy.

Building and releasing this in spite of knowing it doesn't install (which is the impression you're giving me, let me know if I'm misunderstanding you) is ignoring the policy.  We are in a soft launch period, but that does not exempt any packages from the general EPEL policy.  Doing so would be a quick way to start the official launch with multiple policy-breaking packages, because there would be no guarantee the issues would be resolved in time.  There is zero reason to push an update before it's dependencies are ready.  Please don't do that in the future.

> Building and releasing this in spite of knowing it doesn't install (which is the impression you're giving me, let me know if I'm misunderstanding you) is ignoring the policy.

Your argument is based on the assumption that I knowingly added Nextcloud to epel10 with unmet dependencies. This simply isn’t true. So yes, I’d agree this is a misunderstanding. Indeed, the situation we are in, is purely accidental.

On Fri September 6, you made the announcement in the EPEL 10 status update thread we could resume packaging for EPEL 10 (I’m sure I don’t have to provide the link). I understood this to mean the soft launch had ended, and the rest of us (who were not aware of said soft launch) could blaze away…. And blaze away I did. 

I pushed as many packages as I could to koji, as fast as I could. After watching how they failed, I then went back and fixed the issues and/or filed epel10 package requests for missing buildrequires.  

From what I recall, there were a couple things different (not bad, just different) about this launch, from the previous the epel 9 launch:

- Mock configs for el10 were absent on Sept 6. That’s right. The tool we rely on to build and test packages offline was not available. I see they are there now, but at the time I didn’t know if they would be there tomorrow, next week, or next month. Consequently, I did everything with fedpkg/koji.

- Automatic bodhi updates were on, and I didn’t immediately realize that.

I was in such a hurry to get my packages built I will fully admit I did not think through the possible ways my workflow could go wrong.

When I built Nextcloud the first time, I fully expected it to fail… but to my surprise it didn’t. Since updates were automatic, it immediately populated in EPEL10…. So here we are.

Yeah, in hindsight, I should have done scratch builds first. 

The missing runtime requirements for Nextcloud are php packages managed by Remi. The few interactions I’ve had with him, I’ve learned the guy is always on top of his stuff, and if a package isn’t built then there is a good reason for it. He didn’t disappoint. If you look at the bug reports I filed, sure enough all these packages are being held up by this issue, which I know you are aware of:
https://issues.redhat.com/browse/RHEL-55273

This is also complicated by the fact that the travel requirements for my day job are peaking at the moment. Since I do fedora packaging on a volunteer basis, work gets done in-between travels. 

Yes, I did plan to file bug reports in time (despite this bug report here), but due to my own workload and my trust in Remi, it was not a high priority. Feel free to disagree. If instead these were packages from someone I didn’t know or trust, I would have made it a priority.


At this stage, it would seem we can either wait to see how the php rebase plays out, or if you want to release epel10 sooner, feel free to to remove Nextcloud from epel10. I’ll put it back when everything is ready.

I certainly regret the situation we are in, but I hope we can both agree now that pasting links to Fedora policies we both know well, won’t change the situation.

> Your argument is based on the assumption that I knowingly added Nextcloud to epel10 with unmet dependencies. This simply isn’t true. So yes, I’d agree this is a misunderstanding. Indeed, the situation we are in, is purely accidental.

Yes, this was my assumption, based on your immediate response of "of course it isn't installable yet".  I think my assumption was a reasonable one to make based on the response.  To avoid misunderstandings like this in the future, please be explicit if something was an accident, because that was not at all clear in this case.

> On Fri September 6, you made the announcement in the EPEL 10 status update thread we could resume packaging for EPEL 10 (I’m sure I don’t have to provide the link). I understood this to mean the soft launch had ended, and the rest of us (who were not aware of said soft launch) could blaze away…. And blaze away I did.

I started that thread off by stating that the official launch was targeting Q4.  The soft launch period began with the Flock hackfest, and continues until the official launch.  The official launch (i.e. the end of the soft launch period) will be announced in a completely unambiguous way on the Fedora Community blog, and will also be referenced in many other places such as social media, discussions, and the mailing list.  The comment about resuming building was about a temporary pause in builds we had to do for a compose pipeline change, and was in no way an indication that the soft launch period had ended.

> - Mock configs for el10 were absent on Sept 6. That’s right. The tool we rely on to build and test packages offline was not available.

No, that's incorrect.  EPEL 10 mock configs were added to mock-core-configs on August 15th.

https://github.com/rpm-software-management/mock/commit/3802ca348b880d925066124075acec354d56849b
https://rpm-software-management.github.io/mock/Release-Notes-Configs-41.1

> - Automatic bodhi updates were on, and I didn’t immediately realize that.

I understand that this was a mistake, but I do want to be clear that this has been discussed for several months in several places.  About a month before your nextcloud build I posted on both the discussion thread and the mailing list that we had "automatic bodhi updates, similar to rawhide".  There were opportunities for you to be aware of it.  I think what might help us in the future is to create an EPEL package maintainer guide, with a focus on what things are different in the upcoming release.  We can modify the branch request template to include a link to this guide, which will help maintainers who haven't been paying as much attention get caught up to speed.  I may write this myself eventually, but anyone can contribute it via pull request to the EPEL docs if they get to it before I do.

> This is also complicated by the fact that the travel requirements for my day job are peaking at the moment. Since I do fedora packaging on a volunteer basis, work gets done in-between travels.

I appreciate you making time to volunteer with Fedora and EPEL.  Considering your time limitations, I think you should avoid the "blaze away" approach.  It may seem like it's needed to fit the work into your limited volunteer time, but when mistakes like this are made it just means longer periods of brokenness before you can get around to fixing things.  It's much better to take your time to get things right, even if it means a package isn't available for a little while longer.

> At this stage, it would seem we can either wait to see how the php rebase plays out, or if you want to release epel10 sooner, feel free to to remove Nextcloud from epel10. I’ll put it back when everything is ready.

Our plan of record is Q4 like I mentioned, but to be a bit more specific the launch date we are currently targeting is November 19th (not guaranteed).  About a week or two before that we'll be making adjustments like turning off automatic bodhi updates and enabling the testing repo.  Around that time I'll check back on this, and if it's still uninstallable I can untag the nextcloud build to remove it from EPEL 10.

> I certainly regret the situation we are in, but I hope we can both agree now that pasting links to Fedora policies we both know well, won’t change the situation.

If someone replies to me in a manner that indicates that they are unaware of (or outright ignoring) our policies, I will remind them of said polices by linking to them.  It's not personal, it's just a matter of ensuring the overall quality of EPEL.  I can not be expected to inherently know which maintainers know the policies well, and which ones don't.  If you communicate like you don't know them well, then I'm going to reply accordingly.

> About a week or two before that we'll be making adjustments like turning off automatic bodhi updates and enabling the testing repo.  Around that time I'll check back on this, and if it's still uninstallable I can untag the nextcloud build to remove it from EPEL 10.

We're at this point now.

https://discussion.fedoraproject.org/t/epel-10-status-update/124549/13

It's nice to see that most of the dependencies are fixed now, but php-pecl-redis5 remains.  Bug 2314113 was closed as WONTFIX, with indication that this dependency should be migrated to php-pecl-redis6.  But based on bug 2319777 comment 8, it may be several months before that is available.  Due to this long timeline, I went ahead and removed the epel10.0 tag from the nextcloud-29.0.6-1.el10_0 build.  This will remove the package from the next compose, and thus from the repo.  The dist-git branch is still active, so once the situation is resolved nextcloud can be republished by submitting a new bodhi update.