On 13. 11. 19 18:31, Stephen Gallagher wrote:
Sorry for the long overdue reply here. Answers to your questions are inline.
Thank you.
On Wed, Oct 9, 2019 at 6:46 PM Miro Hrončok <mhroncok@xxxxxxxxxx> wrote:
...
What I miss in the description is:
1. How does this thing actually work? is there an additional repository composed
from the default streams available in Koji only?
An additional repository is composed from the default streams
(including the module metadata) and is merged with the standard
buildroot using Koji's new "bare" mode. This buildroot will be
available for non-Koji purposes (such as mock).
Will this buildroot repository be mirrored or will it be more like the current
"local" repository defined in mock configs?
For reference, this is currently in the rawhide mock config:
[local]
name=local
baseurl=https://kojipkgs.fedoraproject.org/repos/rawhide/latest/$basearch/
cost=2000
enabled=0
skip_if_unavailable=False
My concern is that using the "local" repository for mock builds is quite slow
and IIRC puts Koji under unnecessary load.
2. How are conflicts between packages from the default streams and ursine
package be handled?
As long as the module metadata is present, an artifact with a given
name from an enabled or default module will effectively "hide" the
non-modular version.
I have a hard time to understand this. Could you please dive into the details?
"As long"? What does that mean? When they are not present and when they are present?
"an enabled or default module"? Who enables a module in the buildroot? Is it
releng? The packager? Somebody else? Is it an explicit or implicit action?
Suppose we put maven:3.5 into the buildroot (I know we don't do that, but that
was the idea origianlly). How do I as a a maintainer of an ursine maven-foo
package BuildRequire the ursine maven package?
Unless you mean "conflicts" in some other sense, in which case I think
RPM-level conflicts should handle it.
You understood "conflicts" exactly as I've meant it here, sorry for not being
more explicit.
3. What is the local experience if the packager is using mock. What if they are
using rpmbuild directly?
For mock, if it's pointed at the Koji-hosted buildroot repository, it
will work exactly as Koji does (with no local changes required).
Makes sense, however, the information I miss is: Will it be pointed to the
Koji-hosted buildroot repository by default or not? My point was that this
should be part of the proposal before it was approved.
If
it's pointed at the public mirrors, it will need to have the Modular
repos enabled and it will have whatever is in the standard buildroot
plus default streams available there.
Will it be pointed to the public mirrors with the Modular repos enabled?
It previously was like that for a while and it was reverted as a wrong behavior.
One purpose of this Change is to
reconcile those two cases so they are the same.
If the cases are the same, isn't it actually what was originally proposed as
Ursa Major? I am seriously confused here, because I understood this change as it
is explicitly doing a different thing, a nonmodular repository composed of the
modular content. So that our downstreams can consume it "traditionally" without
adapting their tooling.
What you are describing here sounds like we are doing Ursa Major, renamed to
Ursa Prime, because Ursa Prime was a no-go. Because I don't assume ill intent, I
am absolutely sure that there is something I'm not getting here, but it it very
hard to figure out what.
Could you please, in great detail describe the differences between the two and
how this approved change addresses all the reasons that the previous attempt was
forbidden?
Right now, the Koji
buildroot will be slightly different from the one mock would see
because FESCo asked us to only allow two modules in the Koji buildroot
for testing.
Why would mock "see" different things based on restrictions FESCo asked to do?
My primary concern is that by default, mock sees what Koji sees.
By this change and by what was approved by FESCo (to clarify: I voted against
this), we are adding new things to what Koji sees. So I am really not sure what
actually happens to what mock sees:
1. Do we add only the 2 FESCo approved modules to what mock sees?
2. Do we add all default modular streams to what mock sees?
3. Do we keep mock to only see ursine content?
My opinion:
1. is ideal, but was not approved nor documented in the change proposal
2. is not ideal and was not approved nor documented in the change proposal
3. is not ideal, but is status quo, hence requires no approval/change
Prior to this Change, the Koji buildroot would have only
the non-modular content.
Correct.
4. How are we handling default streams with dependencies on non-default streams
of other modules?
Throughout these discussions, it has been made clear that the best
option for now will be to disallow default streams from depending on
non-default streams in Fedora. This *can* (but may not) change in the
future once we have worked out the explicit-vs-implicit enablement and
upgrade questions. But for now, it seems reasonable to put that policy
constraint on it.
I agree. Let's make that happen **before** we actually start doing Ursa
Prime/Major/...?
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
