On Mon, Jun 26, 2017 at 02:19:42PM -0400, langdon wrote: > 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. Kevin specifically asked about mixing modular and non-modular content. Yes, you can manipulate RPMs directly. I'm not saying you cannot. > > 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. I'm not sure who would be doing mapping between random RPMs and modules that "replace" them. Sounds difficult, dangerous and not really doable at a large scale, especially if there are more variants of the same content available at the same time, which is one of our features. P > > 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@xxxxxxxxxxxxxxxxxxxxxxx > > > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > > > > > > _______________________________________________ > > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > > _______________________________________________ > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
