Igor Gnatenko wrote:
> On Wed, Oct 23, 2019 at 2:52 PM Petr Šabata <contyk@xxxxxxxxxx> wrote:
>> While these issues are being resolved, we are considering temporarily
>> disallowing default streams in Fedora. I don’t want to abandon the
>> idea completely, as doing so reduces the motivation to actually build
>> modules and reap the benefits they might provide.
>
> This basically makes modularity not useful for many things:
>
> 1. People will have to have different workflows between "default"
> version (standard workflow, as we have today) and "modular" version.
> Also that means, on the distribution upgrade maintainers will have to
> do many things to remove modular stream, add old one and upgrade
> non-modular version. This is also not only about maintainers, but end
> users too:
>
> FXX: fish 3.x is non-modular, stream 4.x exists
> FXX+1: fish 4.x is non-modular, stream 3.x exists
>
> * If user wants to stay on 3.x, he needs to enable stream explicitly
> *after* upgrade and then downgrade the package (which is actually
> unsupported).
> * If user wants to stay on 4.x, he needs to enable stream explicitly
> during FXX (which is totally fine), but after upgrade he has to
> explicitly disable it.
I think the right approach would just be to have both fish 3.x and 4.x as
module streams for all releases, independently of what they ship:
> Obviously you can have 3.x stream for FXX and 4.x for FXX+1, but that
> means:
>
> * Maintainer has to maintain that version *twice* (modular and
> non-modular version)
It should just be a matter of git merge (usually a fast forward) and fedpkg
build.
> * Nobody can guarantee that those will be compatible
If they are built from the same specfile and against the same libraries (the
distro defaults, not other modules, but that would be the default if you do
not specificially specify otherwise in your module metadata), why would they
not?
But of course, there is no *guarantee* that a module stream is compatible
with the default, non-modular version. That is why they are alternate
streams to begin with.
> 2. In Rust we use modularity to build bunch of packages, filter
> buildroot-only packages and ship only one user-facing RPM. If we
> remove default stream, people won't be ever able to do `dnf install
> ripgrep'. This is worst UX we can provide.
This means that the packaging guidelines for Rust need to be improved. If
you need a build-time dependency to build the package, it needs to be
shipped, so that users can reproduce the build and so that they can compile
other Rust software.
> I think problems with modularity is not about packager experience or
> some missing features (e.g. I'm waiting for some features for 1+
> years, but that's not crucial). The problem is that we don't have
> well-defined *user* experience.
>
> Do you think you will be able to come up with some exhaustive
> documentation how installation/upgrades/downgrades/switches/whatnot
> should look like in modularity? I would imagine you need at least 70
> "test-cases" for simple things.
That part, I mostly agree with. I think the packager experience is also
lacking and that this cannot be neglected either, but the worst is indeed
the end-user experience. (The promise that users would not notice the
default streams at all just does not work out. The difference shows in the
form of upgrade path issues, differences in handling retired packages (due
to the possible hard dependency on a distro/platform version), performance
regressions, etc.)
> After last few years with modularity, I don't think it is improving
> but it definitely causes some problems.
>
> While I would like to achieve goals you stated in the beginning, I
> don't think we are ready to introduce modularity to our users and
> packagers yet. I would like to see it getting back to whiteboard,
> together with our community define behaviors and implement it outside
> of our main infrastructure. Give it feedback for 1-2 releases and if
> it makes sense for people here, get it in here.
> Yes, that means that people who enjoy modularity will have to start
> maintaining non-modular packages again and experiment with modularity
> somewhere else but I don't think it is bad iddea.
That is actually a more radical change than disallowing default streams. It
would basically disallow default streams too, or allow them only in a
non-default repository (which means that you still have to maintain the
non-modular version).
I would personally be OK with either approach (just disallowing default
streams or reverting/externalizing Modularity entirely), I am fine with
everything that makes modules fully optional again, but I guess the former
would be easier to get consensus on and implement.
Kevin Kofler
_______________________________________________
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
