On Tue, Dec 17, 2019 at 11:21:45PM +0100, Miro Hrončok wrote:
On 17. 12. 19 21:57, David Cantrell wrote:
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)?
I am not aware of any policy against modularizing existing packages.
Modular maintainers can module-bundle glibc. OTOH I don't know all the
policies.
There is a policy for making a default modular stream: if it overrides
existing non-modular packages, it requires FESCo approval. So far this
has not been retroactive and the ant and maven default modular streams
do that.
See also https://pagure.io/modularity/issue/170
I feel there should be some restrictions around this bundling. glibc is a
good example, but I am also concerned about the ability for modules to bundle
security-libraries which could lead to a system with multiple different
versions of a shared library on a system.
With protobuf as the example again, we saw that the eclipse module's bundled
protobuf took the lead in depsolving and dnf upgraded systems to that
regardless of whether or not they had the module installed. So the multiple
shared library scenario is only a concern in a world where we do parallel
installability. Putting that aside for the moment, I'd like to refine the
above concern:
We should have some restrictions about packages that can and cannot be bundled
with modules. This may require defining some sort of criteria or a set of
core packages or some other test. Likewise, packages like openssl need some
thought because while we do not currently do parallel installability, even
having parallel availability still means we could have multiple different
builds of an openssl package. There should be a plan around that because
having that be unbounded sets us up for a lot of panic mode work should there
be something like Heartbleed happen again.
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.
I would assume they file it in protobuf. They haven't opted for any
module and they don't know it's modular, really. The non-modular
maintainer may deduce from the NERVA that it is modular build and do
some nontrivial digging to figure out where is this package coming
from - if they can, they will reassign the bug report to that module
component.
I agree that the modular maintainers are ultimately responsible for
everything they bundle.
I share your concerns.
Filing against protobuf makes sense, but then we get to the maintainers. The
protobuf maintainer did not know eclipse bundled protobuf. Without being
involved in that decision, I think it's unfair to expect package maintainers
to be the triage point for all incoming bugs, either regular packages or
bundled packages. That's just not going to really scale very well and will
result in frustration among package maintainers and users.
Maybe if a module bundles a package, the module maintainer also becomes a
co-maintainer on the bundled package?
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?
The modular maintainer or somebody else who he modular maintainer made
a deal with. As far as possible in a community supported distribution,
I think the modular maintainer should be responsible.
I agree. The reporting and ownership story needs some more work. The way we
have Bugzilla set up right now does not make it obvious to me how a bug could
be distinguished between the regular package and the bundled package in a module.
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.
They don't. If they are well informed about how Fedora is developed,
they might guess from the release tag and then do some detective work.
See also https://pagure.io/modularity/issue/171
From a user experience standpoint, I feel this is unsufficient. Users should
be able to determine where packages came from. Whether or not that happens
through dnf does not matter to me, but we need some sort of tool that allows
for that information to be discovered.
5) How are CVEs handled for packages that are also bundled with a module?
I don't think they are reported properly. Hence they are handled on
the modular maintainer's discretion.
See also https://pagure.io/modularity/issue/169
I would like to see modules have a stronger policy around tracking and
handling CVEs. At the very least, what Fedora already does for regular
packages.
Thanks,
--
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
