On 06/26/2017 01:44 PM, Petr Šabata wrote:
On Mon, Jun 26, 2017 at 11:29:08AM -0600, Kevin Fenzi wrote:
On 06/26/2017 11:04 AM, Langdon White wrote:
We talked about this with the server wg and decided for F27 server we would
try to avoid an "everything else" module and figure out how to solve this
problem more nicely between now and release. We have multiple options here
including : generating modules for everything, making an extra repo of
stuff available, leaving non-modules out, and, finally, the everything else
module.
So there is never going to be any mixing of modules and non modules? I
would think another way to solve this issue might be to get dnf to
prefer modules, but still operate on either rpms or modules, so if you
ran 'dnf install tmux' it would look for a tmux module, if it finds it
great, it uses that. If it doesn't then it looks for the rpm and uses that.
Then if later you do 'dnf update' and there is now a tmux module it
uninstalls the rpm and intalls the module, etc.
This question is kinda like "so there is never going to be any
mixing of Fedora and Mageia RPMs?".
Module content is built separately and while the sources are
often the same or close to what was used to build traditional
composes, the modular content is not guaranteed to be 100%
binary compatible.
Petr, I think you are jumping to the worst case scenario version of this
question. Specifically, that the "arbitrary rpms" in question here are
coming from an arbitrary repo. Yes, your concerns are valid if we are
adding in arbitrary stuff from arbitrary sources. However, like I said
in my email which crossed in the ether, that doesn't mean we can't
manipulate RPMs directly from DNF. We just don't want people pulling
arbitrary rpms from non-modular sources.
Enhancing dnf with a feature with a potential to unexpectedly
explode users' systems doesn't sound like a reasonable thing
to do.
I think this is a matter of UX testing. If the tmux-rpm was silently
replaced with the tmux-module it may be a good thing assuming it does
what the user expects. I, personally, struggle with the
"uninstall/reinstall" portion of this but if we could find a way to just
add stream information without actually replacing the rpm, the user
could just follow the "tmux-before-it-was-a-module" stream until they
are ready to switch then be give the "real" module-stream options.
Langdon
Definitely a recognized issue, but not sure we are decided on the answer
(or answers). We would like the module guidelines to address the use cases
with recommendations but it is tough to iron this out.
yeah, there definitely could be some complex interactions here, but I
think it's important to have the ability to install local rpms or things
that are not (yet) modularized.
That can be done. And if those local RPMs were built against
the modular platform, even better.
P
Unrelated question: We will still be making the server repo and
netinstall so people can install the legacy server setup with rpms, right?
kevin
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
