On 06/26/2017 01:29 PM, 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.
Essentially, this ^^ is exactly the plan. The DNF folks will have to
weigh in on exactly how the priorities will work. I also would like to
see some UX testing around your last point. As in, I am not sure the
user gets what they expect if it replaces the tmux-rpm with the
tmux-module without any hint.
For example, even if we had an httpd module, mod_ssl may not be there in
the default-install. However, it would still be available and we are
trying to make it essentially "dnf install mod_ssl" (apologies if I am
misremembering the exact package names) to add in that function. The
modular aspect just indicates the stream the mod_ssl comes from, e.g.
httpd 2.4 vs httpd 2.2.
Apologies, but I was talking about "available in the Fedora Server
repo". Specifically, we have a lofty goal that everything in that repo
would have a module wrapped around it. We may not get there which
triggers the choices above.
Hopefully, that makes more sense.
Langdon
PS: the problems with communicating when you are very close to something
for a long time.
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.
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
