How does this work for modules that might conflict or you might not want in the same repos like different versions of the same library?

How does this work for modules that might conflict or you might not want in the same repos like different versions of the same library?

Sorry, could you be more specific? I'm not sure what sort of conflict you are asking about. Also, it might be better to have architectural discussions on devel@ rather than in this ticket.

@sgallagh Current bodhi supports module update pushes. So what exactly are you expecting from this?

Also, pinging @puiterwijk to give us high level idea on how module pushes work in bodhi currently, probably we wont need to work on this.

@mohanboddu

We're asking for a new set of repositories that is supplemental to the Everything set (colloquially, fedora, updates and updates-testing). We will want Bodhi to push module updates only to the modular-updates and modular-updates-testing repositories, while non-module updates should continue to go to updates and updates-testing.

@pbrobinson We expect multiple versions of the same library to be in this repo. Modularity-aware DNF can handle this situation. This is why it is easiest to have it be a separate repo — people who want to ignore that or are using tools that can't cope can just not use this repo.

Currently, we have a tree that looks like this (with many other branches I'm leaving out for clarity):

fedora/linux/releases/27/Everything/x86_64/os/Packages
fedora/linux/updates/27/x86_64/Packages
fedora/linux/updates/testing/27/x86_64/Packages

We're asking for:

fedora/linux/releases/28/Everything/x86_64/os/Packages
fedora/linux/releases/28/Everything/x86_64/modular/Packages
fedora/linux/updates/28/x86_64/os/Packages
fedora/linux/updates/28/x86_64/modular/Packages
fedora/linux/updates/testing/28/x86_64/os/Packages
fedora/linux/updates/testing/28/x86_64/modular/Packages

(Note new "os" subdir for "traditional" updates repo.)

The exact structure isn't important, but I hope this illustrates the request (and I think it's a scheme that makes sense).

Another approach would be to leave the existing paths exactly as is, and use

fedora/linux/modular/releases/
fedora/linux/modular/updates/

but making that not a full "variant" but just the location for these repos — so:

 fedora/linux/modular/releases/27/x86_64/Packages
 fedora/linux/modular/updates/27/x86_64/Packages
 fedora/linux/modular/updates/testing/27/x86_64/Packages

But I don't like this for a number of reasons:

1. In the new scheme, modular releases are exactly correlated to base OS releases. Separating them out implies a division that doesn't really exist.
2. We want mirrors to pick up the modular content without needing to reconfigure for a new rsync module (yay overloaded terms!)
3. In this scheme, updates are available in two areas very far from each other on the tree, which I think is confusing.
4. In this scheme, we have a directory called "Everything" which does not, actually, contain everything. This is aesthetic, but kind of hurts my heart. :) And @ausil says that renaming Everything is a big risk. So, let's just use Everything.

I prefer the first plan(https://pagure.io/releng/issue/7227#comment-486716).

@mattdm and @sgallagh Thanks for answering my questions.

@tmlcoch @lsedlar how is this being implemented in pungi?

The paths generated by pungi can be customized by providing a python module that implements a Paths class (from here). However there is something else that is modifying them, as updates/27/x86_64/Packages path is not coming from Pungi. Could that code handle this request?

If the new repos are going to be purely modular and no depsolving will be run for them - i.e. these new repos don't need to use original Fedora repos as lookaside repositories during compose process, then the new modular repos could be added as regular variants or add-ons to the current composes.

This would require Pungi that supports so called "hybrid composes". With this feature, Pungi can generate a compose that contains modular and non-modular variants or even combine modular and non-modular content into a single variant (although the latter is an experimental feature that doesn't have a well defined behavior and even support in client tooling (dnf) is currently missing).

If the modular repos are defined as add-ons, then modification of the {{Paths}} class, mentioned by Lubos, shoudn't be necessary.

Note that if depsolving is enabled for add-on it could cause extra packages to appear in a variant variant the add-on is based on - This shouldn't happen if the add-on is modular, however this have never been tested yet and it might needs some devel work on Pugi.

Ability to do compose with modular and non-modular variant is not available in upstream Pungi yet.

It's being merged piece by piece by Pungi developers.

The blob of all the patches that are being merged step-by-step is:
https://pagure.io/pungi/pull-request/830 (do not merge this PR!)

@ausil, got pinged by @sgallagh, they would like to have the available somewhere.

Is it possible to setup a new compose for that (a new Bikeshed for AppStream)?

Jan 12 09:44:50 <lsedlar> mboddu, question about https://pagure.io/releng/issue/7227 new repositories for modular[-updates[-testing]]: what is the pungi work needed? meeting minutes says there should be something in progress, but I'm not aware of anything
Jan 12 09:44:57 <fm-releng> pungi.compose.status.change -- pungi-koji compose of Fedora-26-updates-testing-20180112.0 started https://kojipkgs.fedoraproject.org/compose/updates/Fedora-26-updates-testing-20180112.0
Jan 12 09:45:23 <fm-releng> pungi.compose.status.change -- pungi-koji compose of Fedora-27-updates-testing-20180112.0 started https://kojipkgs.fedoraproject.org/compose/updates/Fedora-27-updates-testing-20180112.0
Jan 12 09:45:36 <+mboddu> lsedlar: puiterwijk told me about it
Jan 12 09:45:45 «--- praiskup (praiskup@nat/redhat/x-monfxamldrtsaagv) has Quit (Quit: Leaving)
Jan 12 09:45:49 <+mboddu> puiterwijk: ^ any idea?
Jan 12 09:46:14 »» +mboddu wonders if I understood it wrong and goes back and checks
Jan 12 09:46:24 <puiterwijk> lsedlar: I was told by dgilmore that the modularity folks are working on new patches to make mixed traditional/modular repos
Jan 12 09:48:39 <lsedlar> puiterwijk, thanks, I know about the mixing work, just did not realize it would be a solution for this ticket
Jan 12 09:49:05 <puiterwijk> lsedlar: Well, it wasmore that if we want to build new repo contents, we need a tool to generate those repos.
Jan 12 09:49:17 <puiterwijk> I'm not going to build repos by hand...
Jan 12 09:49:57 <fm-releng> pagure.issue.new -- sharkcz opened a new ticket releng#7264: "failed composes due content of the ppc64/ppc64le installer image bigger than 2GB" https://pagure.io/releng/issue/7264
Jan 12 09:50:03 <lsedlar> puiterwijk, my initial understanding was that it should use the existing modular composes, just ship them to a different location
Jan 12 09:50:15 ---» jamesturner246 (~jamesturn@lancing.inf.susx.ac.uk) has Joined #fedora-releng
Jan 12 09:50:33 <puiterwijk> lsedlar: oh. That isn't the feeling I got from when Matthew explained it, so I might've misunderstood things there
Jan 12 09:50:47 <puiterwijk> Basically, they said they wanted it mixed in with the standard repos.
Jan 12 09:51:16 <puiterwijk> lsedlar: So what you're saying is that they want the xact same repos that Bodhi's been able to generate for a while now, just in a different location?
Jan 12 09:52:13 <lsedlar> puiterwijk, maybe not, I don't know; the way you describe it would also be possibility
Jan 12 09:52:40 <puiterwijk> If they want the same repos as we have just in a different place, that's trivial.
Jan 12 09:52:59 <puiterwijk> And actually, looking at the examples Matthew provided, that might be what they want...
Jan 12 09:53:01 <puiterwijk> fedora/linux/releases/28/Everything/x86_64/os/Packages
Jan 12 09:53:03 <puiterwijk> fedora/linux/releases/28/Everything/x86_64/modular/Packages
Jan 12 09:53:28 <jkaluza> puiterwijk: they need to get some RPMs from classic fedora koji_tag and on top of that use some RPMs from a module
Jan 12 09:53:33 <jkaluza> modules
Jan 12 09:53:42 <puiterwijk> jkaluza: in the same yum repos? Or to the side?
Jan 12 09:53:43 <jkaluza> puiterwijk: those from modules should replace the ones which are in fedora koji tag
Jan 12 09:53:48 <jkaluza> puiterwijk: in the same repo
Jan 12 09:53:54 <puiterwijk> jkaluza: okay, then we need the pungi work
Jan 12 09:53:58 <jkaluza> contyk: ^ am I right?
Jan 12 09:54:19 <puiterwijk> Since right now we can only generate fully-traditional or fully-modular repos, nothing with "traditional except where it's in a module"
Jan 12 09:54:29 <jkaluza> not a true I think, there is that hybrid compose
Jan 12 09:54:44 <jkaluza> but according to contyk there are some problems with it, but I already forgot what exactly
Jan 12 09:54:59 »» contyk reads the backlog
Jan 12 09:55:02 <puiterwijk> Is there? I was under the impression that because of how you guys abused the variants file, it totally ignores the entire koji tag in the pungi config
Jan 12 09:55:21 <puiterwijk> (ab)used (my personal opinion/feeling from having to do bodhi+pungi)
Jan 12 09:55:39 <lsedlar> jkaluza, the patches for hybrid composes are not yet in upstream, so there is still more work to do
Jan 12 09:55:57 <puiterwijk> Right. Thatis the work I was talking about, and that's what I'd heard
Jan 12 09:55:59 <contyk> I don't think we want a hybrid compose in Fedora
Jan 12 09:56:00 <jkaluza> lsedlar: ah, I thought they are upstream
Jan 12 09:56:10 <contyk> the /os dir should be pure rpms, /modular should be just modules
Jan 12 09:56:15 <puiterwijk> contyk: but... that seems to be what was asked?
Jan 12 09:56:17 <puiterwijk> Huh.
Jan 12 09:56:25 <contyk> puiterwijk: where exactly?
Jan 12 09:56:30 <jkaluza> contyk: then please correct me, because from what we have discussed last week it seemed like you want to have single repo :)
Jan 12 09:56:32 <puiterwijk> jkaluza, contyk: can I ask to fight this out amongst eachother?
Jan 12 09:56:36 <puiterwijk> contyk: look at jkaluza's statement
Jan 12 09:56:48 <contyk> oh, sorry, right, the paths... it's technically a single repo
Jan 12 09:56:50 <puiterwijk> 3. 2. 1. FIGHT!
Jan 12 09:56:56 <contyk> but two separate dirs
Jan 12 09:57:08 »» jkaluza is starting to be lost
Jan 12 09:57:16 <puiterwijk> contyk: but they can be generated in two different composes? Or do they come from the same pungi run?
Jan 12 09:57:16 <contyk> and I think we discussed that we would do two separate composes and then merge them
Jan 12 09:57:24 <contyk> puiterwijk: ^
Jan 12 09:57:33 <contyk> if that's possible
Jan 12 09:57:34 <jkaluza> contyk: should we have single repodata containing both classic RPMs + modules on top of them?
Jan 12 09:57:52 <fm-releng> pagure.git.receive -- lsedlar pushed 21 commits to fork/lsedlar/pungi (pkgset-tag-refactor) https://pagure.io/fork/lsedlar/pungi/branch/pkgset-tag-refactor
Jan 12 09:57:55 <jkaluza> contyk: classic RPMs == RPMs coming from f2x koji_tag
Jan 12 09:57:55 <puiterwijk> contyk: okay. So you want a traditional compose, a modular compose (just like we have now), and just shove the output of the modular one aside the traditional one, in a way that the repodata and Packages are not overlapping but close?
Jan 12 09:58:23 <puiterwijk> i.e.:
Jan 12 09:58:25 <puiterwijk> fedora/linux/releases/28/Everything/x86_64/os/Packages
Jan 12 09:58:27 <puiterwijk> fedora/linux/releases/28/Everything/x86_64/os/repodata
Jan 12 09:58:29 <puiterwijk> fedora/linux/releases/28/Everything/x86_64/modular/Packages
Jan 12 09:58:31 <puiterwijk> fedora/linux/releases/28/Everything/x86_64/modular/repodata
Jan 12 09:58:33 <puiterwijk> Is that what you want?
Jan 12 09:58:35 <fm-releng> pagure.pull-request.comment.added -- lsedlar commented on PR #798 on pungi https://pagure.io/pungi/pull-request/798#comment-42758
Jan 12 09:58:38 »» jkaluza understands that he does not want this
Jan 12 09:58:39 <contyk> I think so, yes
Jan 12 09:58:49 <jkaluza> ok, I've been wrong all the time then :)
Jan 12 09:58:53 <fm-releng> pagure.pull-request.comment.added -- lsedlar commented on PR #798 on pungi https://pagure.io/pungi/pull-request/798#comment-42759
Jan 12 09:58:54 <fm-releng> pagure.pull-request.closed -- lsedlar closed (without merging) pull request #798 on pungi https://pagure.io/pungi/pull-request/798
Jan 12 09:58:58 <jkaluza> but fortunately did not talk with anyone about this :)
Jan 12 09:59:00 <puiterwijk> jkaluza: okay, so you're saying that what contyk says is correct?
Jan 12 09:59:04 <contyk> the motivation is that you should be able to disable modules and use traditional Fedora
Jan 12 09:59:29 <puiterwijk> Okay. In that case, it's literally just a syncing destination path difference... That's simple enough to do
Jan 12 09:59:40 <contyk> personally I would be fine with two separate composes but I wasn't behind this proposal
Jan 12 09:59:46 <contyk> yeah
Jan 12 09:59:47 <puiterwijk> contyk: I am going to guess we won't get a fedora/linux/releases/28/Workstation/x86_64/modular/repodata?
Jan 12 09:59:48 <jkaluza> puiterwijk: contyk is the leader here, I was just discussing that with him over the coffee last week and had an impresion that we were discussing he wants to merge those two repositories together
Jan 12 10:00:06 <puiterwijk> jkaluza: okay. Thanks for confirming that you lost :P
Jan 12 10:00:06 <jkaluza> puiterwijk: but he probably just wants them to appear in single compose, but still as two repositories
Jan 12 10:00:12 <jkaluza> puiterwijk: yes :)
Jan 12 10:00:22 <puiterwijk> jkaluza: oh? He just said he's expecting two composes merged?
Jan 12 10:00:25 <contyk> jkaluza: we do but not necessarily in Fedora context :)
Jan 12 10:01:20 <contyk> you guys are confusing me
Jan 12 10:01:22 <contyk> :P
Jan 12 10:02:04 <jkaluza> that's what I'm goot at
Jan 12 10:02:07 <jkaluza> good
Jan 12 10:02:12 <contyk> I think we want to be shipping a single compose
Jan 12 10:02:20 <contyk> this single compose could be created by merging two separate composes
Jan 12 10:02:26 <contyk> one modular, one traditional
Jan 12 10:02:55 <contyk> the two parts should probably have separate repodata so that you can disable modules and use non-modular tools to work with your RPMs
Jan 12 10:03:14 <contyk> does that make sense?
Jan 12 10:03:29 <jkaluza> yes
Jan 12 10:03:40 <jkaluza> it's what puiterwijk showed in his example, I think
Jan 12 10:04:37 <fm-releng> pagure.git.receive -- lsedlar pushed 33 commits to fork/lsedlar/pungi (mixed-variant) https://pagure.io/fork/lsedlar/pungi/branch/mixed-variant
Jan 12 10:06:16 <puiterwijk> contyk: not exactly. Do you want two composes but in the same output dir, or actually one pungi run? In my terminology, one "pungi run" == "one compose"
Jan 12 10:06:23 <fm-releng> pungi.compose.status.change -- pungi-koji compose of Fedora-Epel-7-updates-testing-20180112.0 just finished https://kojipkgs.fedoraproject.org/compose/updates/Fedora-Epel-7-updates-testing-20180112.0
Jan 12 10:06:35 «--- asamalik (asamalik@nat/redhat/x-aoeqpdtaieqmuwnu) has Quit (Ping timeout: 240 seconds)
Jan 12 10:07:04 <contyk> puiterwijk: two repos under one dir
Jan 12 10:07:12 <contyk> puiterwijk: two pungi runs at least
Jan 12 10:07:21 <contyk> puiterwijk: three if the merge is another pungi run, two if not
Jan 12 10:07:28 <puiterwijk> Okay.
Jan 12 10:07:33 <puiterwijk> The merge won't be done by Pungi
Jan 12 10:07:36 <puiterwijk> Just a crude python script :)

Whew, long quote. :) I want to call out specifically:

Jan 12 10:02:12 <contyk> I think we want to be shipping a single compose
Jan 12 10:02:20 <contyk> this single compose could be created by merging two separate composes
Jan 12 10:02:26 <contyk> one modular, one traditional
Jan 12 10:02:55 <contyk> the two parts should probably have separate repodata so that you can disable modules and use non-modular tools to work with your RPMs

This is correct, but "should" is actually MUST. This is an essential requirement of the new modularity proposal.

Also:

• We eventually want it so that packages from module streams marked as "default" land in the non-modular repo.
  • This is so packagers don't need duplicate work with both f27/f28/f29/rawhide branches and package-4/package-5 (or whatever) branches.
  • It is okay if these packages happen to land in both repositories. (In this case, it's definitely important for there to be a unified compose so that the metadata stays in sync.)
• I don't think we care about Workstation/x86_64/modular/repodata and similar, at least until sometime in the future where editions might choose to ship with a non-default stream. But that's probably F30 timeframe or so.

@mattdm @psabata

I guess we got different views from you.

@mattdm wants a single compose which means we need to make changes to pungi
@psabata wants to have two composes(traditional and modular) and merge them together(which can be done by a python script) which doesn't require pungi changes.

Can you please discuss on this and let us know what you want?

@mohanboddu Is there a reason we can't do it the way you describe @psabata's approach for right now and then consider a single-compose approach as an optimization later? If the end-result looks like the same content on-disk, I don't know if we truly care if the sausage is ground by hand or with an electric mixer.

@mohanboddu Sorry, I wasn't clear. I absolutely do not care about the number of composes, as long as what goes out to mirrors stays in sync.

That part that I was emphasizing differently from @psabata is that the modular repo must have separate repodata, because users must be able to disable it and still function with the base repo.

[13:48:58] 04<mattdm?04>?04 mboddu: number of distinct composes is not important to me -- just the output

We discussed today in the releng meeting.

Looks like the pungi functionality has been submitted for review:

https://pagure.io/pungi/pull-request/830

We discussed today in the releng meeting.
Looks like the pungi functionality has been submitted for review:
https://pagure.io/pungi/pull-request/830

Looks like Dennis merged that on Friday. What's the next step?

So, I think what we still need is this:

• fedora-repos needs .repo files for the modular, modular-updates and modular-updates-testing repositories. I suggest that this should probably be a subpackage that individual Editions can choose to include or not, since we committed to F28 Modularity being optional.[1]
• Bodhi configuration needs to be updated to point at these new repos for module updates.
• We need to work out how to handle mirrors [2]
• pungi-fedora needs a pungi config and variants.xml file against which the Modularity WG can submit PRs to include new module streams.

I think that describes the remaining work. Please comment if I missed anything. (Paging @ausil @lsedlar ).

[1] As discussed in person with @ausil at DevConf.cz, the requirement is for the modular repository to exist. We don't actually care where in the filesystem hierarchy on the mirrors it appears so long as the repo files can address them. So if this means doing multiple composes to generate the repositories, that's fine. If it's easier to make it a single compose, that's fine too.

[2] As far as I'm concerned, I don't really care if we temporarily ship repo files that point at a baseurl instead of a mirrorlist as long as people who install it can get access to the content. However, I understand that this can cause problems if people manually edit those files since they won't pick up corrections without manually merging them after that.

On [1], I care a little bit for aesthetic reasons and more than a little bit for "let's make sure it's within the normal rsync module" reasons.

We had a conversation in the release engineering channel today.

The next step to move this forward is to get a build of pungi that contains the required commit that was recently merged.

@lsedlar - please advise when we can receive that build and work with Fedora infrastructure to test and then deploy it into production.

Release engineering can work on the configurations but the new pungi is required for them to be useful.

@kellin That would be pungi-4.1.22-3:
F27 build: https://koji.fedoraproject.org/koji/buildinfo?buildID=1024242
I opened pungi-fedora#512 as a suggestion of what the config might look like (mostly for syntactic reasons, not the actual content).

@ausil, can you please review this ticket? @mattdm told me this is blocking modularity. I'd like to understand what the next action is and who is taking it. Thanks.

@syeghiay met with @ausil and he provided the to-do list as follows:

1a. Releng needs to update pungi.
1b. Releng needs appropriate compose configuration changes.
2. Infrastructure need changes to mirror manager written, tested, pushed to production.
3. Releng needs to make changes in Fedora repos.

Do we know who from infrastructure is on point 2? Is there a ticket for that?

@mattdm: I do not see a ticket to request this from infra at https://github.com/fedora-infra/mirrormanager2/issues, no.

Can someone who knows exactly what the request is file that ticket, please? I see in ./mirrormanager2/lib/repomap.py there's a section like:

[...]
isAtomic = u'atomic' in path
isEverything = u'Everything' in path
isFedora = u'Fedora' in path
isServer = u'Server' in path
isModular = u'modular' in path

... and then a little bit of conditional logic after that. Is the required change just updating that, or is there something more?

@mattdm all the existing Modular code needs removed, and we need to map the new paths, it is in that area though

@ausiil So, I guess the next step is to finalize the planned new paths, so we can file that ticket?

https://github.com/fedora-infra/mirrormanager2/issues/236

Thanks @ausil !

Timeline update: In order to keep the Change on track, we need this to be done by next week. Is that going to be possible?

Once this is complete, we will need to also deal with "how to change", see https://pagure.io/releng/issue/7316

As I understand the mirror manager change, that needs to be in place eventually for this to work, but does not actually block the other items. What is the status of the other things?

Breaking that down a little bit more from the above:

1a. Releng needs to update pungi.

This is this update, right? Currently waiting in batched (and presumably could be pulled in from updates-testing).

1b. Releng needs appropriate compose configuration changes.

That's https://pagure.io/pungi-fedora/pull-request/512, right?

\2. Infrastructure need changes to mirror manager written, tested, pushed to production.

https://github.com/fedora-infra/mirrormanager2/issues/236 — I think that's waiting on path names to be finalized, but also I think does not block items in 1 or 3 in this list. (Right?)

\3. Releng needs to make changes in Fedora repos.

Not sure.

pungi has been updated on rawhide-composer
pungi-fedora#512 has been merged along with pungi-fedora#528 to sync the content to the mirrors
https://github.com/fedora-infra/mirrormanager2/pull/237 has been submitted to update mirrormanager for the new content.

Tomorrow I will look at the fedora-repos changes needed. the compose for 2018-02-21 has been moved 5 hours early so that we can see how things go and make any needed adjustments and kick off a new rawhide compose if needed.

@ausil any update? or need any help?

Hard to tell from the incomplete composes but the Modular variant seems to include a very strange set of packages and none of them feature the typical modular dist tags. I think something's going wrong.

The current status is that we have pungi updated, the compose is configured. The composes however have been failing for unrelated issues, there is patches for mirrormanager but they need content to test against. we then need to make the fedora-repos updates.

Thanks Dennis. That sounds mostly positive, except for the "it doesn't actually work" part. Are there links to or tickets for the other issues, or some other way I can easily follow what's going on?

There has been active discussion on the various issues that have been causing composes to fail in #fedora-releng @adamwill, @dustymabe, @puiterwijk and @kevin have all been playing whackamole in fixing the compose issues.

fedora-repos changes submitted in fedora-repos#62 that should all match up with the mirrormanager changes. once we have a compose working again

Thanks again Dennis. Are we expecting this to basically just start working at this point once the general compose issues are sorted?

we need to get fedora-repos built with the changes, mirrormanager code tested and deployed, once that's all done, yes it should just work.

We now have http://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/Modular/ the mirrormanager changes are being tested in stage, it will be deployed to prod as soon as its tested, then we can get the fedora-repos update merged, built and in. I beleiev we will have this in place this week

We now have http://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/Modular/ the mirrormanager changes are being tested in stage, it will be deployed to prod as soon as its tested, then we can get the fedora-repos update merged, built and in. I beleiev we will have this in place this week

I just took a look at that repository... it is definitely not carrying the expected content. I'm not sure where it's getting its manifest from, but it's not the set of available modules. (It actually looks like it may be including all of the content from the Everything compose, but I haven't done a full comparison).

Who is looking into that? @mohanboddu, @ausil ?

@mattdm: I checked in with @lsedlar this morning. There are patches in flight to fix it (there are apparently two related issues). @kellin is going to fire off another compose once they land, so we should know before the end of the day if this is fixed.

Awesome, thanks!

@mattdm We looked at rawhide failure today and we already fixed it, so once we have the @lsedlar changes, we will fire off another compose.

@mohanboddu How did that compose go? Do we have modular repos with the proper content now?

FYI https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org/message/NPVJTNAIFM2YSSXYXDFWGMBRS6H6PPN5/:wine_glass:

• Correctly handle Fedora 28 modular layout

Why is it that modules are allowed in regular repositories? e.g. see nodejs package -> https://kojipkgs.fedoraproject.org/compose/branched/Fedora-28-20180303.n.1/compose/Everything/x86_64/os/Packages/n/ ?

same I found in http://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/Everything/x86_64/os/Packages/n/

I thought we are getting separate repository for modularity packages.

@mattdm We got composes with modules enabled but its taking a long time to compose. I filed an issue with pungi(https://pagure.io/pungi/issue/860) which is fixed by PR(https://pagure.io/pungi/pull-request/861) but it will save a ton of time but still we might see a delay compose completion time. @lsedlar is working on it but according to him its going to take some time.

ATM, currently waiting on https://koji.fedoraproject.org/koji/taskinfo?taskID=25519590 to complete and once done, we will update our compose boxes.

@pnemade As discussed on irc, it is partly caused by https://pagure.io/pungi/issue/860 and more info on https://pagure.io/pungi/issue/862

So, I'm trying to figure out how this is going now.

I see

https://dl.fedoraproject.org/pub/fedora/linux/development/28/Modular/x86_64/

which has some stuff in it under https://dl.fedoraproject.org/pub/fedora/linux/development/28/Modular/x86_64/os/ which looks like what we want.

I also see we have https://dl.fedoraproject.org/pub/fedora/linux/updates/testing/28/ with new "Everything" and "Modular" paths.

@sgallagh, is the stuff landing there correct?

I also see that the main Modular tree has iso and isolinux directories. As discussed previously, this is not a new "variant" from a user standpoint — it is not a separate Edition or Spin. I'm concerned that this will cause significant confusion. Can we block creation of these? In addition to end-user confusion, that must also be adding unnecessarily to compose time.

I reported this same issue few days back to @puiterwijk but that time just the initial push to Fedora 28 testing repo was going on so that need to wait till this push completed. But yes finally the path is different now compared to previous Fedora releases testing repository.

Another thing, why the new f28-u-t fedora-repo package update which installed Fedora Modular repositories are enabled by default? I am a bit confused here, will not this pull modular package update from Fedora Modular repo also? I mean like reported above nodejs got update as a modular package update when it got wrongly added in normal repository. Now I have both normal and modular updates-testing repo enabled, will I get package update from any available repository?

Last thing, the naming of the modular repo file is also confusing. Good if we have followed fedora-modular-updates-testing.repo instead of fedora-updates-testing-modular.repo file name.

Another thing, why the new f28-u-t fedora-repo package update which installed Fedora Modular repositories are enabled by default? I am a bit confused here, will not this pull modular package update from Fedora Modular repo also? I mean like reported above nodejs got update as a modular package update when it got wrongly added in normal repository. Now I have both normal and modular updates-testing repo enabled, will I get package update from any available repository?

The modular repositories have special metadata that will make them mostly invisible to clients unless they have enabled that particular module (or it is set to be enabled by default, but that isn't fully implemented yet, so you shouldn't need to worry about it). The issue with the nodejs package ending up in the main repo was a compose bug that got fixed (it ended up in the main repo simply because we were accidentally doing a repomerge that included the modular repo and the nodejs module had packages with higher NVR than in the base repo).

That said, the modular repos were originally planned to be a subpackage that could be installed (or not) at the discretion of the individual Editions/Spins for F28. It appears that they are part of the main package and enabled by default which is a bit more than we intended and we may need to change that for Final (but I'd actually be pretty happy for that to stay the case in Beta as it will lead to more testing).

OK, I'm changing my statement in my last comment. I just learned from Neal Gompa that having the modular repositories enabled by default is breaking dnfdaemon and dnfdragora at the moment, so we pretty much have to move to having it an optional subpackage and pull it in only to those Editions and Spins that want it for F28.

@otaylor @dustymabe : Can you guys poll the Workstation and Atomic WGs about whether they want it? Server WG voted months ago that we want it by default in our edition.

Once the subpackage exists, I'll update comps.

Who is working on making that subpackage? Is that @ausil ?

Who is working on making that subpackage? Is that @ausil ?

I put together a PR that was merged this morning: https://pagure.io/fedora-repos/pull-request/67

Looks like @mohanboddu built it and submitted it for Bodhi sometime since I last looked, so I guess I should get that comps.xml change made.

@mattdm Could you poll the various Editions and Spins and find out which ones besides Server want to enable the Modular repos? Make sure they understand that non-DNF package management tools don't work properly with the Modular repos at the moment.

@sgallagh I think at this point, let's just make it the default on Server. People on other editions or spins can opt in individually if they like.

@sgallagh Just checking if https://kojipkgs.fedoraproject.org/compose/branched/Fedora-28-20180314.n.2/compose/ is what you are expecting it to be?

@mohanboddu I see that there are still iso directories and images under that, as well as boot (isolinux, EFI) stuff in os. Is that still expected?

@mattdm Not exactly, we are skipping buildinstall phase on modular variant, but the PR got merged just today, so it will be applied in tonights compose.

If its something that you want see today, I can re-run the compose.

@mohanboddu Tomorrow is just fine — no need to rerun just for that. I just wanted to make sure that wasn't overlooked.

@sgallagh Well, we got a new compose https://kojipkgs.fedoraproject.org/compose/branched/Fedora-28-20180315.n.0/ which is actually "FINISHED". But, it still has the same issue as what @mattdm mentioned above. You can take a look at both of the composes and let us know what do you think.

Thanks.

@sgallagh Can you verify today's compose from https://kojipkgs.fedoraproject.org/compose/branched/Fedora-28-20180319.n.0/ which has normal rpms in Everything repo and modular rpms in modular repo.

Also, with disabled buildinstall for modular variant.

CC: ^ @mattdm

@mohanboddu Looks great! Thanks!

@mohanboddu That all looks correct to me. Thanks!