I am unable to find a clear answer or policy for the following items regarding packages bundled with modules. My concerns are based around the recent issue with protobuf being bundled in the eclipse module.
1) Are modules allowed to bundle packages that are provided by the base system and maintained there? What policy exists around that? Are there any restrictions (e.g., can a module bundle glibc)?
2) Using protobuf as an example, if a bug is found by a user and they happen to deduce that the error is in protobuf, how do they file a bug? Do they file the bug against protobuf if the bundled one from the module has the issue? What maintainer is on the hook for handling that bug report? My assumption here is that the module maintainer is ultimately responsible for everything they bundle. Another concern I see here is we are opening ourselves up for N+1 different builds of protobuf where N is the number of modules installed on a system and all of them could have protobuf bundled.
3) If a user files a bug against a module and the module maintainer triages that to a bundled package, how is that handled? Who is maintaining the bundled build of that package? Who is responsible for fixing it?
4) How can users determine what packages are installed from a module and how can you see what module "owns" a package? I have been unable to determine how to do this from dnf.
I'm not sure a ticket is the best place to discuss this. I know devel is noisy, but might be better there...
The word 'bundle' might be confusing here... usually packagers think of 'bundle' as 'something included in the same package' not 'something from a seperate branch included in a module. Not sure how better to say that though... aside from 'included in a module'
I'd defer to the modularity working group here, but from what I know, anyone making a module could add a stream branch to an existing package.
IMHO, they should file the bug on the module, but I am unsure how they would know to do that. If they file on the package, the maintainer should see it's the stream branch version of it in the module and move the bug there.
I would think the module owner, unless the maintainer(s) wish to help out.
Good question. You can do 'dnf module repoquery --installed ' to list everything installed from modulename. I suppose with 'dnf module list --enabled' you could find out which module each was in?
Please, move this to the devel list. There is nothing FESCo can do over those topics. Unless you have a specific proposals for answers and you want them ratified. In that case, please move your proposals to devel list as well first.
I have my opinions on the topic and would love to share them, but I don't think this is the place.
Please, move this to the devel list.
+1
I don't think it is confusing. Essentially, it's the same thing in both cases: "taking an older or customized version of some public package and delivering it as part of your [delivery artifact]". In one case it's included in another rpm, and in the other case it forms an rpm on its own, but that is just an implementation detail.
There is a small detail (sorry, got tempted): when you bundle in your RPM, usually you don't break other RPMs. Arguably, you can bundle glibc in /usr/lib64/libc-2.30.so and break everything. However with traditional bundling, that would be considered bad. With modularity, design.
OK, I'll move this to the devel list.
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/HHRFEX7UVEY7NOMLAC4ABH52KZ5YZ2EF/
Metadata Update from @churchyard: - Issue close_status updated to: Duplicate - Issue status updated to: Closed (was: Open)