On Tue, Dec 17, 2019 at 05:21:36PM -0700, John M. Harris Jr wrote:
On Tuesday, December 17, 2019 1:57:09 PM MST David Cantrell wrote:
With regard to the recent protobuf package issue and the eclipse module, I
started wondering how bugs work with packages bundled in modules. That is,
packages that exist outside modules (e.g., protobuf) that end up bundled
with some module.
NOTE: It is very easy for module posts to quickly balloon out in to all
sorts of topics and stories. I would prefer that we keep this thread
related to the Subject above. Thanks.
The following are policy questions I came up with after the protobuf issue
happened:
1) Are modules allowed to bundle packages that are provided by and
currently maintained in the base system? Are there are restrictions to
what a module can bundle (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, if any, module "owns" a package? I have been unable
to determine how to do this from dnf.
5) How are CVEs handled for packages that are also bundled with a module?
I have read as much as I can find about how things work right now with
modules, but that has been mostly the "how" and nothing around policy.
I also have to wonder whether or not there should be a policy for modules
providing the same package names, or at least a policy such that two different
default default modules cannot provide the same package.
That is a reasonable question. If modules ultimately provide a repo to dnf
for depsolving, then through the repodata and repo cost values, I would expect
dnf to be able to resolve that down to one package to install. But that
requires coordination among all the bundled packages, their version numbers,
and their release numbers.
I can see the current situation easily leading to a module deciding to bump
the Epoch value on a bundled package to ensure that's the one that gets
installed on the system. That's not a good solution or a solution at all.
Thanks,
--
David Cantrell <dcantr...@redhat.com>
Red Hat, Inc. | Boston, MA | EST5EDT
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
