On Wed, Dec 18, 2019 at 01:00:03PM +0100, Vít Ondruch wrote:
Dne 17. 12. 19 v 21:57 David Cantrell napsal(a):
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?
These are two very interesting points.
Just FTR, for Red Hat Software Collections, we are (ab)using "Version"
BZ field to track the SCL version (e.g. [1]), which in module
terminology resembles stream. Maybe we could reuse something similar for
modules in Fedora.
I think Fedora would have to do something like that to indicate module
ownership in a bug. The Version field requires BZ maintenance for that list
which could mean that each module version would need a new entry in that
list. At least that's how I understand that BZ field the last time I looked
at it.
We could come up with syntax and place it in one of the Whiteboard fields.
Something like module=eclipse;ver=X.Y.Z
That would probably get ugly real fast.
Also, it is interesting that AFAIK, we have not yet dealt with issue
like this (i.e. reporting issues against specific streams) for RHEL8 yet.
Vít
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1757842
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.
Thanks,
_______________________________________________
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
--
David Cantrell <dcantrell@xxxxxxxxxx>
Red Hat, Inc. | Boston, MA | EST5EDT
_______________________________________________
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
