Thanks for writing this post Langdon! On Tue, 2019-11-05 at 12:55 -0500, langdon wrote: > * The two most promising candidates, Gentoo's slots (etc) and nix > both > require a substantial user experience change both as a command line > person and in how / where things land in the OS. We believe this to > be > an insurmountable change for Fedora users. Also, Gentoo's slots are > more > sophisticated than they were ~5 years ago when we started this > project > so they definitely appear more "tempting" now. I haven't used Nix before, so I can't comment on that one, but in what way would Gentoo's solution require a substantial user experience change? When Gentoo added it, the only user experience change for me was when I wanted to pick a non-default slot (or as we call it, stream). If I wasn't doing that, things just kept working they way they had for years before that. It's still like that to this day - I only have to know about Gentoo slots if I am trying to opt-in to some version that isn't the default (the default in Gentoo is typically the latest stable version). Actually, even if you don't opt in you are likely to end up with a few packages parallel installing due to dependencies pulling in different versions of things. It seems to me that modularity requires a similar interaction from the user when defaults are enabled. The user needs to learn how to use the set of dnf module subcommands. I see that as a pretty equivalent amount of user experience change between the two. Is there something more than this you are referring to with Gentoo? > * alternatives infra (for lack of a better name): doesn't really > solve > the problem of parallel availability without massive name mangling > and, > potentially, fragile symlinking around the system. I'm not familiar with this - could you describe it? > * many repos: considered to be non-performant in dnf (although that > has > gotten *much* better), very confusing for users, not discoverable. I suppose that Copr might fit into this category. I can't comment about performance other than I agree that all the repo metadata syncing could get slow, but for discoverability there is a dnf copr search subcommand. Curiously, I don't see a dnf module search subcommand, but I do see a list subcommand, which I suppose could be used with grep if there start to be too many. > * compat-libs (or compat lib style): not discoverable, name mangling Yeah I don't love this either. > * language specific lib management (e.g. rvm, virtualenv): > completely > different by language, preferred tool changing over time, led by > language communities (vs the distro) +1 > there are definitely others that I am not thinking of at the moment. > However, I wanted to try to get this out quickly. > > Basically, everything we looked at either, a) was a massive user > experience shift for Fedora users (way more than even some of the > broken > things we have in modularity). Could we get some expansion on this? It's not clear to me how adding slots to the RPM spec file to denote "streams" would necessarily result in a significantly different user experience in comparison to the user experience we have today with modularity (in terms of dnf commands - or are you thinking of other things when you say user experience?). To avoid the word "slot", what I'm saying is why not just add a "Stream" field to the RPM spec file (so, instead of NEVR, it's NESVR), and provide a way for users to specify which streams they want to follow? > Or, b) solved the problem in the "wrong" > part of the stack (in my opinion), meaning we should be able to do > this > in the package manager or "in the OS." I think the "Stream" field could be done in dnf, but you were probably referring to some of the other solutions considered. > However, Stephen's blog post > about the requirements is a way better treatise on the reasons why > the > alternatives didn't work. I am glad Stephen wrote that blog post, it was helpful. However, my reaction after reading it is still that adding a "Stream" field to the RPM Spec file could work and would be simpler for implementors and packagers. > We (Stephen Gallagher and I) discussed me writing a blog post to > revisit > these past questions when Zbigniew raised the question the other > day. > However, I haven't written it yet. +1 Suggestion: could it be done as a page in the modularity documentation instead of (or in addition to) a blog post? That would make it easier to discover later if people wonder about these things. Extra suggestion: Stephen's requirements blog post would also be excellent to archive in the modularity docs. Stephen, if you don't have the time or inclination, I'd be happy to try to figure out how to get it in there for you.
Attachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ 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
