On Tue, 12 Nov 2019 at 12:26, Aleksandra Fedorova <alpha(a)bookwar.info> wrote:
On Tue, Nov 12, 2019 at 5:10 PM Miro HronĨok <mhroncok(a)redhat.com> wrote:
>
> On 12. 11. 19 17:02, Aleksandra Fedorova wrote:
> > Again, no one forces you or any other packager to use modularity
> > tooling right now.
> >
> > As Fedora developer you have a choice to join the effort, bring your
> > input and use cases, try and test (and revert if it doesn't work) or
> > you can stay away from it and keep using same tools as before.
>
>
> Unfortunately, this is not true. It is not possible to ignore modularity, if the
> dependencies are modularized. It is not possible to ignore modularity, if the
> dependents are modularized. It is not possible to ignore modularity, if the
> packages I wish to use are modularized.
>
> I wish Fedora packagers and users cold "stay away". But that is currently
not
> possible. My proposal to keep all defaults as non-modular packages would make it
> exactly so.
Ursa Prime effort achieves the same goal. It removes the "viral" part
of Modularity I think.
As well as policy which restricts the set of default modules, which I
think we need to change from "FESCo approves new default modules" to
"each request for new default module should be treated as a
System-Wide Change".
Again I fail to see the _technical_ difference between the ursine rpm
package and a package which was built as a part of default stream. It
is the same rpm spec from the same dist-git sources, which is built by
the same rpmbuild command. Thus I think it is a process/policy
difference, which we should resolve.
Do you view provides/requires/conflicts in an RPM spec and their
equivalent in modules to be technical or policy differences. If wrote
a policy which says I built X and X-devel but only want to ship X in
the module.. is that a policy difference or a technical one? If the
policy says I can't even install a newer X/X-devel that I built with
NEVR because modules always win and it isn't a module.. is that a
technical difference or a policy one?
I can see where those are technical because it is built into the
technology of modules/dnf/etc and I can also see it as policy as the
'spec' file is more about setting up policies for a package needing
certain things and including/excluding other things.
[I am asking this because if we spend a lot of time arguing because
people think X is technical and others think it is policy.. the
argument will spiral for hundreds of messages about definitions that
people thought they agreed on and not about the change itself.]
--
Stephen J Smoogen.