Re: Modularity: The Official Complaint Thread

[Dominik 'Rathann' Mierzejewski]

On Tuesday, 10 December 2019 at 13:38, Miro Hrončok wrote:
> On 05. 11. 19 21:17, Stephen Gallagher wrote:
> > I'm sure there are other pain points and I encourage you to share
> > them. Please adhere to the guidelines about objectively measurable
> > issues, though.
> 
> M5. Modular packages are less secure than the nonmodular packages, because
> known security  vulnerabilities (CVEs) are not properly tracked within
> modules.
> 
> Reported as https://pagure.io/modularity/issue/169

Wow. That's serious.

How does Red Hat track these in RHEL8 and what's preventing Fedora from
doing the same?

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Modularity: The Official Complaint Thread

[Miro Hrončok]

On 05. 11. 19 21:17, Stephen Gallagher wrote:

I'm sure there are other pain points and I encourage you to share
them. Please adhere to the guidelines about objectively measurable
issues, though.


M5. Modular packages are less secure than the nonmodular packages, because known 
security  vulnerabilities (CVEs) are not properly tracked within modules.


Reported as https://pagure.io/modularity/issue/169

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Modularity: The Official Complaint Thread

[Aleksandra Fedorova]

Hi, Vit,

On Fri, Nov 15, 2019 at 10:57 AM Vít Ondruch  wrote:
>
>
> Dne 14. 11. 19 v 16:13 Stephen Gallagher napsal(a):
> > On Thu, Nov 14, 2019 at 9:19 AM Vít Ondruch  wrote:
> >> I wonder who is doing to clean up all the mess in dist-git we have due
> >> to modularity. specifically, I wonder about all these branches:
> >>
> >> https://src.fedoraproject.org/modules/nodejs/branches?branchname=master
> >>
> >> https://src.fedoraproject.org/rpms/nodejs/branches?branchname=master
> >>
> >>
> >> What is their state?
> >>
> > Fedora has a policy of never removing branches from dist-git because
> > legal obligations make it prohibitively difficult to determine when it
> > is safe to do so. As a result, Fedora just disallows removing them in
> > all cases.
>
>
> Sure, no problem with that. However, it used to be clear which branches
> are maintained. Nobody can tell now. We already have process for retired
> packages, something similar should be used for all retired branches.
>
> @Aleksandra this is a case where technology is definitely ahead of policy.

Not really :)

I am not sure if this case maps well on technology vs policy
statement. Probably it is just a too vague concept to be useful
anyway.
But I see it as a problem with the tooling (dist-git) which we use to
implement the policy (preserving old branches).
And I think Modularity is not relevant to this conversation,

I filed the issue for Fedora Infrastructure [1] with the proposal how
I think we can fix it.

[1] https://pagure.io/fedora-infrastructure/issue/8390

-- 
Aleksandra Fedorova
bookwar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Modularity: The Official Complaint Thread

[John M. Harris Jr]

On Saturday, November 16, 2019 12:17:10 PM MST Matthew Miller wrote:
> On Thu, Nov 14, 2019 at 12:52:21PM -0500, Neal Gompa wrote:
> 
> > That said, we *do* need to improve things and find new ways to make
> > Fedora appealing to more people, especially newer-generation infra
> > types and software developers. Otherwise, we'll lose the pipeline of
> > fresh blood into the project and eventually stagnate like Debian has.
> 
> 
> Yes, absolutely. And of course, ultimately that's what we _want_
> modularity to do, both for users and contributors. (See again the list
> of goals.)

In my opinion, there's nothing about Modularity that is more appealing to 
"newer-generation infra types and software developers" than traditional 
packages. Ultimately, these people just want something that works.
-- 
John M. Harris, Jr.
Splentity

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Modularity: The Official Complaint Thread

[Matthew Miller]

On Thu, Nov 14, 2019 at 12:52:21PM -0500, Neal Gompa wrote:
> That said, we *do* need to improve things and find new ways to make
> Fedora appealing to more people, especially newer-generation infra
> types and software developers. Otherwise, we'll lose the pipeline of
> fresh blood into the project and eventually stagnate like Debian has.

Yes, absolutely. And of course, ultimately that's what we _want_
modularity to do, both for users and contributors. (See again the list
of goals.)


-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Modularity: The Official Complaint Thread

[Tomas Orsava]

On 11/14/19 10:52 PM, Stephen Gallagher wrote:



On Thu, Nov 14, 2019 at 4:49 PM Miro Hrončok > wrote:


On 14. 11. 19 22:30, Stephen Gallagher wrote:
> On Thu, Nov 14, 2019 at 4:24 PM Miro Hrončok
mailto:mhron...@redhat.com>> wrote:
>
>> Easy is subjective. I don't consider this easy. I consider it
seriously
>> overcomplicated. The idea that going modular will somehow help
with current
>> problems in modularity is exactly what happened to eclipse.
>
> No, what happened to Eclipse is that the maintainers of maven
and ant
> ran ahead without asking for input, created an environment that
caused
> problems for Eclipse and Eclipse got backed into a corner.
>
> As for overcomplicated, I think we can simplify it quite a lot,
but I
> think I'm doing a poor job of explaining it over email. Perhaps we
> could do a Google Hangout tomorrow and discuss it real-time?

Sure thing. Please contact me off-list to discuss when to do this.
I'm not
entirely sure it can be tomorrow. I would like to have other
Python maintainers
there, especially those who have been involved in RHEL 8 Python
modularization
and Petr Viktorin (the team-lead) is on vacation tomorrow.


After tomorrow, I’m out of the office for two weeks. So I may see if I 
can brain-dump to Petr and have him meet with you folks.



A meeting sounds good, I cleaned out my calendar for next week.

Tomas




>> I'm not going to do this. I guess that after the RHEL 8
experience, neither are
>> the remaining Python maintainers.
>
> Please defer judgement until we've talked out the whole idea.
That's all I ask.

I will try to do that, but I'm seriously biased here. I try not to
be, but it's
getting harder with every modularity thread on this list.


I understand. It’s been a rough road and it’s easy to get discouraged. 
I really feel like we are approaching the finish line and shouldn’t 
give up just yet!


Thank you for keeping an open mind. Your help and feedback has been 
invaluable.




-- 
Miro Hrončok

--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org

To unsubscribe send an email to
devel-le...@lists.fedoraproject.org

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@lists.fedoraproject.org

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Modularity: The Official Complaint Thread

[Nicolas Mailhot via devel]

Hi Igor


On Fri, Nov 15, 2019, 10:03 Nicolas Mailhot via devel
 wrote:


Le 2019-11-14 22:01, Stephen Gallagher a écrit :



wrote:


On 14. 11. 19 21:32, Stephen Gallagher wrote:

I proposed earlier around the major
upgrade rebuilds (letting us set other modules as

`buildrequires:` of

`python: [ ]` for stream expansion) without actually having to

build

the complete python stack in the modules. That might be a

really

convenient strategy, honestly.


How is that different, exactly, from letting packagers use a normal 
dep syntax like

(foo with module(modulename))
whenever they want to express they want the module version of a
particular dep?


Le 2019-11-15 10:11, Igor Gnatenko a écrit :

Except that modular packages shadow non-modular so instead of getting
proper package you will have broken dependency.


What I tried to express is that I do not understand what all those 
special module constructs (shadowing, module objects, private packages, 
etc) buy us over just expressing module appartenance in normal rpm 
module provides


It seems to me, naively, that all the problems modularity is 
encountering are generated by those special constructs and those special 
module-only management rules, and that the past years have been spent 
giving up progressively on unmanageable module-object-specific 
behaviors.


Once we’ve gone all the way, and forbade all the special overriding 
characteristics that modularity shown did not work, what will be left 
over just a very weird and awkward way to express Provides?


If the only sane way we find to achieve modularity, is to use something 
very close to module provides, can’t we just drop the special thinguies 
and just do it that way? And declare the module-only things a successful 
experiment, that helped define the problem space, just not the boring 
and reliable way we end up doing it long term?


Regards,

--
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Modularity: The Official Complaint Thread

[Vít Ondruch]

Dne 14. 11. 19 v 16:13 Stephen Gallagher napsal(a):
> On Thu, Nov 14, 2019 at 9:19 AM Vít Ondruch  wrote:
>> I wonder who is doing to clean up all the mess in dist-git we have due
>> to modularity. specifically, I wonder about all these branches:
>>
>> https://src.fedoraproject.org/modules/nodejs/branches?branchname=master
>>
>> https://src.fedoraproject.org/rpms/nodejs/branches?branchname=master
>>
>>
>> What is their state?
>>
> Fedora has a policy of never removing branches from dist-git because
> legal obligations make it prohibitively difficult to determine when it
> is safe to do so. As a result, Fedora just disallows removing them in
> all cases.


Sure, no problem with that. However, it used to be clear which branches
are maintained. Nobody can tell now. We already have process for retired
packages, something similar should be used for all retired branches.

@Aleksandra this is a case where technology is definitely ahead of policy.


Vít

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Modularity: The Official Complaint Thread

[Igor Gnatenko]

Except that modular packages shadow non-modular so instead of getting
proper package you will have broken dependency.

On Fri, Nov 15, 2019, 10:03 Nicolas Mailhot via devel <
devel@lists.fedoraproject.org> wrote:

> Le 2019-11-14 22:01, Stephen Gallagher a écrit :
> > On Thu, Nov 14, 2019 at 4:00 PM Miro Hrončok 
> > wrote:
> >>
> >> On 14. 11. 19 21:32, Stephen Gallagher wrote:
> >> >I proposed earlier around the major
> >> > upgrade rebuilds (letting us set other modules as `buildrequires:` of
> >> > `python: [ ]` for stream expansion) without actually having to build
> >> > the complete python stack in the modules. That might be a really
> >> > convenient strategy, honestly.
> >>
> >> Convenient to achieve what exactly?
> >>
> >
> > To achieve an easy way to deal with modular rebuilds for new Python 3
> > versions.
>
> How is that different, exactly, from adding a
> Provides: module(modulename)
> for in-module packages
>
> and letting packagers use a normal dep syntax like
> (foo with module(modulename))
> whenever they want to express they want the module version of a
> particular dep?
>
> Except for adding the opaque module object to the mix that obscures all
> dependency chain checks?
>
> Regards,
>
> --
> Nicolas Mailhot
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 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@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Modularity: The Official Complaint Thread

[Nicolas Mailhot via devel]

Le 2019-11-14 22:01, Stephen Gallagher a écrit :
On Thu, Nov 14, 2019 at 4:00 PM Miro Hrončok  
wrote:


On 14. 11. 19 21:32, Stephen Gallagher wrote:
>I proposed earlier around the major
> upgrade rebuilds (letting us set other modules as `buildrequires:` of
> `python: [ ]` for stream expansion) without actually having to build
> the complete python stack in the modules. That might be a really
> convenient strategy, honestly.

Convenient to achieve what exactly?



To achieve an easy way to deal with modular rebuilds for new Python 3 
versions.


How is that different, exactly, from adding a
Provides: module(modulename)
for in-module packages

and letting packagers use a normal dep syntax like
(foo with module(modulename))
whenever they want to express they want the module version of a 
particular dep?


Except for adding the opaque module object to the mix that obscures all 
dependency chain checks?


Regards,

--
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Modularity: The Official Complaint Thread

[Kevin Kofler]

Stephen Gallagher wrote:
> I really feel like we are approaching the finish line and shouldn’t give
> up just yet!

Unfortunately, the feeling that I get is that what looks like a finish line 
to you is actually the edge of a deep cliff. ;-)

To explain my metaphore: I think the biggest trouble and chaos has yet to 
come and is unavoidable with the way Modularity works, unless we put some 
very strong policy restrictions on it (which you are not going to like). 
E.g., I fear that desktop Fedora may end up splittered into a KDE/Plasma 
module, a GNOME module, an Xfce module, etc. all shipping different versions 
of some shared (freedesktop.org etc.) libraries, and that all desktop 
applications would end up depending on one of those modules and no longer 
being installable for users of any other desktop.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Modularity: The Official Complaint Thread

[Kevin Kofler]

Stephen Gallagher wrote:
> You're assuming that parallel-install is a thing that everyone needs
> from every package on their system. Our research and surveys
> determined that this was not in fact the case for the overwhelming
> majority of real-world deployments. Most[1] deployments function with
> a "one app per VM/container" mentality. In such cases,
> parallel-installability is at best unnecessary and (such as with SCLs)
> actively annoying to them. Modules offers the availability of multiple
> streams of software like SCLs does, but it sacrifices the ability to
> install them in parallel for the ability to install them in the
> standard locations on disk so that other software doesn't need to
> adapt to alternate locations (the number-one complaint received about
> SCLs).
> 
> [1] Yes, I realize that "most" may not include you. Every environment
> is unique, but we have to try and optimize our efforts for the largest
> set of consumers possible. We reasoned that containers were a
> sufficient workaround for the cases not following the "one app per
> VM/container" approach.

That may be true for RHEL, but I do not see how that would be the case in 
Fedora (or even CentOS), at all. It is also a very server-centric view: I do 
not know any desktop user working that way.

I would really like to know where your data comes from exactly, whom you 
surveyed, and how you counted the deployments.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Modularity: The Official Complaint Thread

[Kevin Kofler]

Stephen Gallagher wrote:
> On Wed, Nov 13, 2019 at 5:29 PM Kevin Kofler 
> wrote:
>> What about libgit2, was that not a default stream?
> 
> It was not. It was a dependency of other modules.

So it looks like we really also (in addition to the proposed ban on default 
streams) need a ban on non-leaf modules. It would also fix the version 
conflict issue.

You have stated yourself: "If you have a library that can be installed in 
parallel, make a compat package. Modularity is not the correct solution for 
that case". And any library can be installed with parallel given sufficient 
packaging skills.

>> And what we are missing here is a list of modular packages with no
>> default version at all (i.e., neither an ursine build nor a default
>> stream), a state which is completely broken (but which seems to currently
>> exist in Fedora, unfortunately).
> 
> Could you define "broken"? Because I have no idea what you're talking
> about here. If it is module-only and has no default stream, it means
> it's effectively invisible unless you enable a stream knowingly.

That is exactly what I mean by "broken": The packages are not discoverable 
unless you enable some module first, and they are not installable without 
opting in to the potential replacement of arbitrary system libraries (or 
"frameworks") (e.g., Django getting downgraded by the ReviewBoard module), 
which may or may not actually be possible without conflicts on the specific 
installation.

I should be able to just dnf install the packages that I want (or 
point&click-install them in Dnfdragora) and get some version (which may or 
may not be the latest) that works with the distribution libraries (which 
also may or may not be the latest). If the application does not work with 
the default version of the library, if no version of the application that 
works with it is available, and if the application cannot be patched to port 
it to the system version of the library, a compatibility version of the 
library is needed. This also holds for programming language interpreters 
(such as Node.js), sets of libraries (such as the Node.js packages), or 
"frameworks" (such as Django, which are really just one of the preceding or 
a combination thereof). I consider it the whole point of a distribution to 
package the software in such a way. If I get to deal myself with 
incompatible version requirements, I may just as well install the 
applications directly from upstream.

>> (Please note that I also read those 2 points as implicitly banning
>> filtering packages from modules, but if that is not obvious to someone,
>> then it should be added as a separate rule.)
> 
> It does not implicitly ban filtering packages. It implicitly bans
> filtering out *sub*-packages. It still think it's acceptable to filter
> out *all* produced subpackages of a component that is used only at
> build-time.

I do not see how that makes a difference, considering that banning some or 
all subpackages behaves exactly the same way. In both cases, the filter will 
interfere with versions of that component packaged elsewhere (see the 
complaints about the filters in RHEL). In both cases, you are deliberately 
hiding a component that you packaged from users and making it hard to 
obtain. In both cases, you are hindering cooperation and risk introducing 
conflicts (when other maintainers will do the logical thing and repackage 
that component elsewhere because you won't let them use the version you 
packaged).

And both violate the rules I am proposing ("1. any package that exists in a 
module MUST have a default version and 2. that version MUST be packaged in 
the ursine/non-modular repository, not as a default stream") in exactly the 
same way (because those subpackages or entire packages definitely do EXIST 
in a module, even if you are hiding them).

> This is literally the entire point of a distribution. We provide an
> opinionated collection of software packaged for people to use.

I think the point of the collection of software packaged in a distribution 
is not to be opinionated, but to be consistent and interoperable. That it 
sometimes ends up being opinionated is an unfortunate side effect (mostly 
caused by upstreams refusing to listen to user requests, forcing the 
distribution maintainer to make a decision on which side to irritate). It 
should NOT be the goal. Being consistent and interoperable should. And that 
is exactly what Modularity is endangering.


The remainder of your message (your last 3 paragraphs) has been answered 
quite well by John M. Harris, Jr. already, so I am not going to repeat the 
same thing.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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://l

Re: Modularity: The Official Complaint Thread

[Neal Gompa]

On Thu, Nov 14, 2019 at 8:19 PM Kevin Kofler  wrote:
>
> Stephen Gallagher wrote:
> > Modular packages without defaults makes sense if they have
> > dependencies on a non-default stream. For example: ReviewBoard depends
> > on the Django:1.6 stream because of complicated upstream reasons. I
> > have to choose between "modular without a default stream" or "not
> > available on Fedora", because we have agreed on a prohibition on
> > default streams with dependencies on non-default streams.
>
> The right fix would be to package Django 1.6 as a parallel-installable
> compatibility package instead. I don't see why I cannot install ReviewBoard
> together with another Django web app on the same web server (without
> containers/VMs). (Admittedly a hypothetical example because I am running
> neither ReviewBoard nor another Django app on a server I maintain. I also do
> not run Fedora on a server. But if I were faced with this issue as a server
> administrator, I would curse loudly at Fedora and switch the server to a
> distribution that does not get in my way that way.)
>

The only really reasonable ways to do that would be to support a
mechanism to package virtualenvs or do mutations to vendor it with the
app. Either way is uglier than the modules mechanism.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Modularity: The Official Complaint Thread

[Miro Hrončok]

On 15. 11. 19 2:18, Kevin Kofler wrote:

Stephen Gallagher wrote:

Modular packages without defaults makes sense if they have
dependencies on a non-default stream. For example: ReviewBoard depends
on the Django:1.6 stream because of complicated upstream reasons. I
have to choose between "modular without a default stream" or "not
available on Fedora", because we have agreed on a prohibition on
default streams with dependencies on non-default streams.


The right fix would be to package Django 1.6 as a parallel-installable
compatibility package instead. I don't see why I cannot install ReviewBoard
together with another Django web app on the same web server (without
containers/VMs). (Admittedly a hypothetical example because I am running
neither ReviewBoard nor another Django app on a server I maintain. I also do
not run Fedora on a server. But if I were faced with this issue as a server
administrator, I would curse loudly at Fedora and switch the server to a
distribution that does not get in my way that way.)


And I would use pip or pipenv to do this. Obviously, people have different 
workflows and different opinions. However, since neither me or you use 
ReviewBoard, but it also stays out of our way, why don't we focus on the problem 
at hand and leave non-default modular streams exist?


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Modularity: The Official Complaint Thread

[Kevin Kofler]

Stephen Gallagher wrote:
> Modular packages without defaults makes sense if they have
> dependencies on a non-default stream. For example: ReviewBoard depends
> on the Django:1.6 stream because of complicated upstream reasons. I
> have to choose between "modular without a default stream" or "not
> available on Fedora", because we have agreed on a prohibition on
> default streams with dependencies on non-default streams.

The right fix would be to package Django 1.6 as a parallel-installable 
compatibility package instead. I don't see why I cannot install ReviewBoard 
together with another Django web app on the same web server (without 
containers/VMs). (Admittedly a hypothetical example because I am running 
neither ReviewBoard nor another Django app on a server I maintain. I also do 
not run Fedora on a server. But if I were faced with this issue as a server 
administrator, I would curse loudly at Fedora and switch the server to a 
distribution that does not get in my way that way.)

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Modularity: The Official Complaint Thread

[Stephen Gallagher]

On Thu, Nov 14, 2019 at 4:49 PM Miro Hrončok  wrote:

> On 14. 11. 19 22:30, Stephen Gallagher wrote:
> > On Thu, Nov 14, 2019 at 4:24 PM Miro Hrončok 
> wrote:
> >
> >> Easy is subjective. I don't consider this easy. I consider it seriously
> >> overcomplicated. The idea that going modular will somehow help with
> current
> >> problems in modularity is exactly what happened to eclipse.
> >
> > No, what happened to Eclipse is that the maintainers of maven and ant
> > ran ahead without asking for input, created an environment that caused
> > problems for Eclipse and Eclipse got backed into a corner.
> >
> > As for overcomplicated, I think we can simplify it quite a lot, but I
> > think I'm doing a poor job of explaining it over email. Perhaps we
> > could do a Google Hangout tomorrow and discuss it real-time?
>
> Sure thing. Please contact me off-list to discuss when to do this. I'm not
> entirely sure it can be tomorrow. I would like to have other Python
> maintainers
> there, especially those who have been involved in RHEL 8 Python
> modularization
> and Petr Viktorin (the team-lead) is on vacation tomorrow.
>

After tomorrow, I’m out of the office for two weeks. So I may see if I can
brain-dump to Petr and have him meet with you folks.


> >> I'm not going to do this. I guess that after the RHEL 8 experience,
> neither are
> >> the remaining Python maintainers.
> >
> > Please defer judgement until we've talked out the whole idea. That's all
> I ask.
>
> I will try to do that, but I'm seriously biased here. I try not to be, but
> it's
> getting harder with every modularity thread on this list.
>

I understand. It’s been a rough road and it’s easy to get discouraged. I
really feel like we are approaching the finish line and shouldn’t give up
just yet!

Thank you for keeping an open mind. Your help and feedback has been
invaluable.



> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 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@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Modularity: The Official Complaint Thread

[Miro Hrončok]

On 14. 11. 19 22:30, Stephen Gallagher wrote:

On Thu, Nov 14, 2019 at 4:24 PM Miro Hrončok  wrote:


Easy is subjective. I don't consider this easy. I consider it seriously
overcomplicated. The idea that going modular will somehow help with current
problems in modularity is exactly what happened to eclipse.


No, what happened to Eclipse is that the maintainers of maven and ant
ran ahead without asking for input, created an environment that caused
problems for Eclipse and Eclipse got backed into a corner.

As for overcomplicated, I think we can simplify it quite a lot, but I
think I'm doing a poor job of explaining it over email. Perhaps we
could do a Google Hangout tomorrow and discuss it real-time?


Sure thing. Please contact me off-list to discuss when to do this. I'm not 
entirely sure it can be tomorrow. I would like to have other Python maintainers 
there, especially those who have been involved in RHEL 8 Python modularization 
and Petr Viktorin (the team-lead) is on vacation tomorrow.



I'm not going to do this. I guess that after the RHEL 8 experience, neither are
the remaining Python maintainers.


Please defer judgement until we've talked out the whole idea. That's all I ask.


I will try to do that, but I'm seriously biased here. I try not to be, but it's 
getting harder with every modularity thread on this list.


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Modularity: The Official Complaint Thread

[Stephen Gallagher]

On Thu, Nov 14, 2019 at 4:24 PM Miro Hrončok  wrote:

> Easy is subjective. I don't consider this easy. I consider it seriously
> overcomplicated. The idea that going modular will somehow help with current
> problems in modularity is exactly what happened to eclipse.

No, what happened to Eclipse is that the maintainers of maven and ant
ran ahead without asking for input, created an environment that caused
problems for Eclipse and Eclipse got backed into a corner.

As for overcomplicated, I think we can simplify it quite a lot, but I
think I'm doing a poor job of explaining it over email. Perhaps we
could do a Google Hangout tomorrow and discuss it real-time?

> I'm not going to do this. I guess that after the RHEL 8 experience, neither 
> are
> the remaining Python maintainers.

Please defer judgement until we've talked out the whole idea. That's all I ask.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Modularity: The Official Complaint Thread

[Miro Hrončok]

On 14. 11. 19 22:01, Stephen Gallagher wrote:

On Thu, Nov 14, 2019 at 4:00 PM Miro Hrončok  wrote:


On 14. 11. 19 21:32, Stephen Gallagher wrote:

On Thu, Nov 14, 2019 at 3:28 PM Miro Hrončok  wrote:


On 14. 11. 19 21:15, Stephen Gallagher wrote:

Now, python3:3.7 vs. python3:3.8 might be a more interesting question...


The way Python is designed, 3.7 and 3.8 is parallel installable by default.

The only things that conflict are:

- package names, such as python3 or python3-pytest
- executable names, such as /usr/bin/python3 or /usr/bin/pytest

By having the python3 modules with 3.7 and 3.8 streams, we would kill this
feature of Python while gaining a very little benefit (such as that users/admins
might select a stream to determine what version /usr/bin/python3 is).

Not to mention that dnf itself depends on Python, so we would need to have dnf
in those modules, or rewrite dnf in Rust or use mcirodnf or have
/usr/libexec/platform-python for dnf.


I was actually thinking more along the lines of: leave the actual
python packages as
non-modular but have a module that acts like the old `alternatives`
tool to set up which binaries should own the main executable names. It
would allow us to do the thing I proposed earlier around the major
upgrade rebuilds (letting us set other modules as `buildrequires:` of
`python: [ ]` for stream expansion) without actually having to build
the complete python stack in the modules. That might be a really
convenient strategy, honestly.


Convenient to achieve what exactly?



To achieve an easy way to deal with modular rebuilds for new Python 3 versions.


Easy is subjective. I don't consider this easy. I consider it seriously 
overcomplicated. The idea that going modular will somehow help with current 
problems in modularity is exactly what happened to eclipse.


I'm not going to do this. I guess that after the RHEL 8 experience, neither are 
the remaining Python maintainers.


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Modularity: The Official Complaint Thread

[Charalampos Stratakis]

- Original Message -
> From: "Stephen Gallagher" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Thursday, November 14, 2019 9:32:30 PM
> Subject: Re: Modularity: The Official Complaint Thread
> 
> On Thu, Nov 14, 2019 at 3:28 PM Miro Hrončok  wrote:
> >
> > On 14. 11. 19 21:15, Stephen Gallagher wrote:
> > > Now, python3:3.7 vs. python3:3.8 might be a more interesting question...
> >
> > The way Python is designed, 3.7 and 3.8 is parallel installable by default.
> >
> > The only things that conflict are:
> >
> >   - package names, such as python3 or python3-pytest
> >   - executable names, such as /usr/bin/python3 or /usr/bin/pytest
> >
> > By having the python3 modules with 3.7 and 3.8 streams, we would kill this
> > feature of Python while gaining a very little benefit (such as that
> > users/admins
> > might select a stream to determine what version /usr/bin/python3 is).
> >
> > Not to mention that dnf itself depends on Python, so we would need to have
> > dnf
> > in those modules, or rewrite dnf in Rust or use mcirodnf or have
> > /usr/libexec/platform-python for dnf.
> 
> I was actually thinking more along the lines of: leave the actual
> python packages as
> non-modular but have a module that acts like the old `alternatives`
> tool to set up which binaries should own the main executable names. It
> would allow us to do the thing I proposed earlier around the major
> upgrade rebuilds (letting us set other modules as `buildrequires:` of
> `python: [ ]` for stream expansion) without actually having to build
> the complete python stack in the modules. That might be a really
> convenient strategy, honestly.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 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@lists.fedoraproject.org
> 

While that is an interesting approach I really don't see any benefit on doing 
that (apart from maybe a staging environment to experiment).

-- 
Regards,

Charalampos Stratakis
Software Engineer
Python Maintenance Team, Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Modularity: The Official Complaint Thread

[Charalampos Stratakis]

- Original Message -
> From: "Stephen Gallagher" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Thursday, November 14, 2019 9:15:38 PM
> Subject: Re: Modularity: The Official Complaint Thread
> 
> On Thu, Nov 14, 2019 at 2:04 PM John M. Harris Jr 
> wrote:
> >
> > On Thursday, November 14, 2019 11:45:22 AM MST Stephen Gallagher wrote:
> > > You're assuming that parallel-install is a thing that everyone needs
> > > from every package on their system.
> >
> > I'm not. However, if you're going to bring up 'the recommended solution for
> > doing "parallel-install" with modules', it makes sense to address this.
> >
> > > Our research and surveys determined that this was not in fact the case
> > > for
> > > the overwhelming majority of real-world deployments. Most[1] deployments
> > > function with a "one app per VM/container" mentality.
> >
> > This isn't surprising to me, as that's just an extension of what is done
> > with
> > physical hosts as well, when serving important services. The physical host
> > or
> > VM is often dedicated to said service, often at the recommendation of the
> > software itself, for example FreeIPA recommends this.
> >
> > > In such cases, parallel-installability is at best unnecessary and (such
> > > as
> > > with SCLs) actively annoying to them.
> >
> > Only if actually implemented as SCLs, in my opinion, but that is definitely
> > an
> > opinion.
> >
> 
> I phrased that wrong. It should have read: "_sometimes_ (such as with SCLs)".
> 
> > > Modules offers the availability of multiple streams of software like SCLs
> > > does, but it sacrifices the ability to install them in parallel for the
> > > ability to install them in the standard locations on disk so that other
> > > software doesn't need to adapt to alternate locations (the number-one
> > > complaint received about SCLs).
> >
> > So, are modules are meant to replace SCLs? If so, surely the inability to
> > install multiple versions invalidates that?
> >
> 
> They aren't incompatible technologies. If there is a case where
> parallel-installability is valuable, an SCL can still be made. But for
> the common case, we (Red Hat) determined that parallel-availability
> was more valuable and common.
> 
> > For example, one of the issues I'm trying to resolve at work is providing
> > both
> > Python 2.7 and Python 3.5 on RHEL 6.
> 
> Python 2 and 3 are effectively separate tools and (given that they are
> built with parallel-installability in mind) should absolutely not be
> streams of the same module.
> 
> Now, python3:3.7 vs. python3:3.8 might be a more interesting question...

That is actually a non-issue, they are parallel installable if you exclude the 
main python3 binary.

> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 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@lists.fedoraproject.org
> 

-- 
Regards,

Charalampos Stratakis
Software Engineer
Python Maintenance Team, Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Modularity: The Official Complaint Thread

[Stephen Gallagher]

On Thu, Nov 14, 2019 at 4:00 PM Miro Hrončok  wrote:
>
> On 14. 11. 19 21:32, Stephen Gallagher wrote:
> > On Thu, Nov 14, 2019 at 3:28 PM Miro Hrončok  wrote:
> >>
> >> On 14. 11. 19 21:15, Stephen Gallagher wrote:
> >>> Now, python3:3.7 vs. python3:3.8 might be a more interesting question...
> >>
> >> The way Python is designed, 3.7 and 3.8 is parallel installable by default.
> >>
> >> The only things that conflict are:
> >>
> >>- package names, such as python3 or python3-pytest
> >>- executable names, such as /usr/bin/python3 or /usr/bin/pytest
> >>
> >> By having the python3 modules with 3.7 and 3.8 streams, we would kill this
> >> feature of Python while gaining a very little benefit (such as that 
> >> users/admins
> >> might select a stream to determine what version /usr/bin/python3 is).
> >>
> >> Not to mention that dnf itself depends on Python, so we would need to have 
> >> dnf
> >> in those modules, or rewrite dnf in Rust or use mcirodnf or have
> >> /usr/libexec/platform-python for dnf.
> >
> > I was actually thinking more along the lines of: leave the actual
> > python packages as
> > non-modular but have a module that acts like the old `alternatives`
> > tool to set up which binaries should own the main executable names. It
> > would allow us to do the thing I proposed earlier around the major
> > upgrade rebuilds (letting us set other modules as `buildrequires:` of
> > `python: [ ]` for stream expansion) without actually having to build
> > the complete python stack in the modules. That might be a really
> > convenient strategy, honestly.
>
> Convenient to achieve what exactly?
>

To achieve an easy way to deal with modular rebuilds for new Python 3 versions.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Modularity: The Official Complaint Thread

[Miro Hrončok]

On 14. 11. 19 21:32, Stephen Gallagher wrote:

On Thu, Nov 14, 2019 at 3:28 PM Miro Hrončok  wrote:


On 14. 11. 19 21:15, Stephen Gallagher wrote:

Now, python3:3.7 vs. python3:3.8 might be a more interesting question...


The way Python is designed, 3.7 and 3.8 is parallel installable by default.

The only things that conflict are:

   - package names, such as python3 or python3-pytest
   - executable names, such as /usr/bin/python3 or /usr/bin/pytest

By having the python3 modules with 3.7 and 3.8 streams, we would kill this
feature of Python while gaining a very little benefit (such as that users/admins
might select a stream to determine what version /usr/bin/python3 is).

Not to mention that dnf itself depends on Python, so we would need to have dnf
in those modules, or rewrite dnf in Rust or use mcirodnf or have
/usr/libexec/platform-python for dnf.


I was actually thinking more along the lines of: leave the actual
python packages as
non-modular but have a module that acts like the old `alternatives`
tool to set up which binaries should own the main executable names. It
would allow us to do the thing I proposed earlier around the major
upgrade rebuilds (letting us set other modules as `buildrequires:` of
`python: [ ]` for stream expansion) without actually having to build
the complete python stack in the modules. That might be a really
convenient strategy, honestly.


Convenient to achieve what exactly?

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Modularity: The Official Complaint Thread

[Stephen Gallagher]

On Thu, Nov 14, 2019 at 3:28 PM Miro Hrončok  wrote:
>
> On 14. 11. 19 21:15, Stephen Gallagher wrote:
> > Now, python3:3.7 vs. python3:3.8 might be a more interesting question...
>
> The way Python is designed, 3.7 and 3.8 is parallel installable by default.
>
> The only things that conflict are:
>
>   - package names, such as python3 or python3-pytest
>   - executable names, such as /usr/bin/python3 or /usr/bin/pytest
>
> By having the python3 modules with 3.7 and 3.8 streams, we would kill this
> feature of Python while gaining a very little benefit (such as that 
> users/admins
> might select a stream to determine what version /usr/bin/python3 is).
>
> Not to mention that dnf itself depends on Python, so we would need to have dnf
> in those modules, or rewrite dnf in Rust or use mcirodnf or have
> /usr/libexec/platform-python for dnf.

I was actually thinking more along the lines of: leave the actual
python packages as
non-modular but have a module that acts like the old `alternatives`
tool to set up which binaries should own the main executable names. It
would allow us to do the thing I proposed earlier around the major
upgrade rebuilds (letting us set other modules as `buildrequires:` of
`python: [ ]` for stream expansion) without actually having to build
the complete python stack in the modules. That might be a really
convenient strategy, honestly.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Modularity: The Official Complaint Thread

[Miro Hrončok]

On 14. 11. 19 21:15, Stephen Gallagher wrote:

Now, python3:3.7 vs. python3:3.8 might be a more interesting question...


The way Python is designed, 3.7 and 3.8 is parallel installable by default.

The only things that conflict are:

 - package names, such as python3 or python3-pytest
 - executable names, such as /usr/bin/python3 or /usr/bin/pytest

By having the python3 modules with 3.7 and 3.8 streams, we would kill this 
feature of Python while gaining a very little benefit (such as that users/admins 
might select a stream to determine what version /usr/bin/python3 is).


Not to mention that dnf itself depends on Python, so we would need to have dnf 
in those modules, or rewrite dnf in Rust or use mcirodnf or have 
/usr/libexec/platform-python for dnf.


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Modularity: The Official Complaint Thread

[Stephen Gallagher]

On Thu, Nov 14, 2019 at 3:17 PM Miro Hrončok  wrote:
>
> On 06. 11. 19 8:29, Miro Hrončok wrote:
> > M2.
> >
> > For traditional packages, it was consistent and easy to find package
> > dependencies in Fedora. For a proven packager, Fedora Packaging Committee 
> > member
> > or generally for anybody doing a System Wide Change, being able to run 
> > queries
> > like:
> >
> > $ repoquery --repo=rawhide --whatrequires 'libpython3.8.so.1.0()(64bit)'
> >
> > is trivial. Arguably, there are some quirks already (for example it doesn't
> > properly work with boolean (rich?) deps).
> >
> > Witch modules,  I still don't remember how to do this, but I know it 
> > requires
> > more than 1 easy repoquery over rawhide.
>
> This is also currently complicated by the fact that when Fedora N branches, 
> the
> modules are not there on Fedora N+1 until they are rebuilt.
>

Until they are *successfully* rebuilt, specifically. We do a
mass-rebuild for Fedora N+1 when Fedora N branches from Rawhide. If a
module (such as scala, right now) fails to build successfully at the
Branched mass-rebuild, it doesn't appear in the Rawhide composes. This
*should* be a quick way to notice things are not working, but scala
has been broken for a while now.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Modularity: The Official Complaint Thread

[Stephen Gallagher]

On Thu, Nov 14, 2019 at 2:04 PM John M. Harris Jr  wrote:
>
> On Thursday, November 14, 2019 11:45:22 AM MST Stephen Gallagher wrote:
> > You're assuming that parallel-install is a thing that everyone needs
> > from every package on their system.
>
> I'm not. However, if you're going to bring up 'the recommended solution for
> doing "parallel-install" with modules', it makes sense to address this.
>
> > Our research and surveys determined that this was not in fact the case for
> > the overwhelming majority of real-world deployments. Most[1] deployments
> > function with a "one app per VM/container" mentality.
>
> This isn't surprising to me, as that's just an extension of what is done with
> physical hosts as well, when serving important services. The physical host or
> VM is often dedicated to said service, often at the recommendation of the
> software itself, for example FreeIPA recommends this.
>
> > In such cases, parallel-installability is at best unnecessary and (such as
> > with SCLs) actively annoying to them.
>
> Only if actually implemented as SCLs, in my opinion, but that is definitely an
> opinion.
>

I phrased that wrong. It should have read: "_sometimes_ (such as with SCLs)".

> > Modules offers the availability of multiple streams of software like SCLs
> > does, but it sacrifices the ability to install them in parallel for the
> > ability to install them in the standard locations on disk so that other
> > software doesn't need to adapt to alternate locations (the number-one
> > complaint received about SCLs).
>
> So, are modules are meant to replace SCLs? If so, surely the inability to
> install multiple versions invalidates that?
>

They aren't incompatible technologies. If there is a case where
parallel-installability is valuable, an SCL can still be made. But for
the common case, we (Red Hat) determined that parallel-availability
was more valuable and common.

> For example, one of the issues I'm trying to resolve at work is providing both
> Python 2.7 and Python 3.5 on RHEL 6.

Python 2 and 3 are effectively separate tools and (given that they are
built with parallel-installability in mind) should absolutely not be
streams of the same module.

Now, python3:3.7 vs. python3:3.8 might be a more interesting question...
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Modularity: The Official Complaint Thread

[Miro Hrončok]

On 06. 11. 19 8:29, Miro Hrončok wrote:

M2.

For traditional packages, it was consistent and easy to find package 
dependencies in Fedora. For a proven packager, Fedora Packaging Committee member 
or generally for anybody doing a System Wide Change, being able to run queries 
like:


$ repoquery --repo=rawhide --whatrequires 'libpython3.8.so.1.0()(64bit)'

is trivial. Arguably, there are some quirks already (for example it doesn't 
properly work with boolean (rich?) deps).


Witch modules,  I still don't remember how to do this, but I know it requires 
more than 1 easy repoquery over rawhide.


This is also currently complicated by the fact that when Fedora N branches, the 
modules are not there on Fedora N+1 until they are rebuilt.


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Modularity: The Official Complaint Thread

[Nicolas Mailhot via devel]

Le jeudi 14 novembre 2019 à 13:45 -0500, Stephen Gallagher a écrit :
> On Thu, Nov 14, 2019 at 1:33 PM John M. Harris Jr <
> joh...@splentity.com> wrote:
> > On Thursday, November 14, 2019 11:15:15 AM MST Stephen Gallagher
> > wrote:
> > > I'm not sure what you're asking here. I thought it was pretty
> > > clear
> > > from the paragraph you quoted that containers are the recommended
> > > solution for doing "parallel-install" with modules. Also, the
> > > relationship goes both ways; Modules provide a trusted source of
> > > software to run in containers (as opposed to running an image
> > > that
> > > someone uploaded to a public registry).
> > 
> > Well, containers are currently the only "supported" way to have
> > parallel
> > installation of any Fedora packages. In essence, we don't have a
> > solution for
> > parallel installation at all. If Modules are supposed to go with
> > containers,
> > why not tack them onto Silverblue instead of the main distro? From
> > what I've
> > read, it seems they would fit that usecase much better than a
> > traditional
> > distribution, and we wouldn't need to address the issues that come
> > from
> > modules overriding non-modular packages.
> > 
> 
> You're assuming that parallel-install is a thing that everyone needs
> from every package on their system. Our research and surveys
> determined that this was not in fact the case for the overwhelming
> majority of real-world deployments.

In any way the core problem is not parallel install (I completely agree
parallel install is a marginal case), or building multiple versions of
the same thing (that has been possible to do in rpm since forever). The
problem is *selecting* the correct version, for build, install or
update, once several are available, and maintaining a working conflict-
less dependency graph.

So, my own conclusion from the past years of module experiments, is
that something that wanted to achieve the original objectives of
modules, would need to invest heavily in dependency graph analysis,
instead of trying to create separate module objects we have no clue on
how to manage sanely.

The module layer has not made any natural self-evident way to handle
competing version streams appear. On the contrary, the segregation in
module silos makes it harder to identify, diagnose and heal conflicts.

If someone manages to define a working solver and a working conflict
resolution strategy, I'm more and more certain that the changes needed
in packages themselves, to provide the additionnal info required by
this solver, will turn out to be minimal.

Without a working solver multiple version streams won’t work out,
upstream has not more clue (and quite often a lot less clue) on what
the dep graph should be, that’s why it constantly creates piles of
bundled unmaintainable and unmaintained code, and handwaves the
maintainership problem to someone else.

Regards,

-- 
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Modularity: The Official Complaint Thread

[John M. Harris Jr]

On Thursday, November 14, 2019 11:45:22 AM MST Stephen Gallagher wrote:
> You're assuming that parallel-install is a thing that everyone needs
> from every package on their system.

I'm not. However, if you're going to bring up 'the recommended solution for 
doing "parallel-install" with modules', it makes sense to address this.

> Our research and surveys determined that this was not in fact the case for
> the overwhelming majority of real-world deployments. Most[1] deployments
> function with a "one app per VM/container" mentality.

This isn't surprising to me, as that's just an extension of what is done with 
physical hosts as well, when serving important services. The physical host or 
VM is often dedicated to said service, often at the recommendation of the 
software itself, for example FreeIPA recommends this.

> In such cases, parallel-installability is at best unnecessary and (such as 
> with SCLs) actively annoying to them.

Only if actually implemented as SCLs, in my opinion, but that is definitely an 
opinion.

> Modules offers the availability of multiple streams of software like SCLs
> does, but it sacrifices the ability to install them in parallel for the
> ability to install them in the standard locations on disk so that other
> software doesn't need to adapt to alternate locations (the number-one
> complaint received about SCLs).

So, are modules are meant to replace SCLs? If so, surely the inability to 
install multiple versions invalidates that?

For example, one of the issues I'm trying to resolve at work is providing both 
Python 2.7 and Python 3.5 on RHEL 6.

-- 
John M. Harris, Jr.
Splentity

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Modularity: The Official Complaint Thread

[Stephen Gallagher]

On Thu, Nov 14, 2019 at 1:33 PM John M. Harris Jr  wrote:
>
> On Thursday, November 14, 2019 11:15:15 AM MST Stephen Gallagher wrote:
> > I'm not sure what you're asking here. I thought it was pretty clear
> > from the paragraph you quoted that containers are the recommended
> > solution for doing "parallel-install" with modules. Also, the
> > relationship goes both ways; Modules provide a trusted source of
> > software to run in containers (as opposed to running an image that
> > someone uploaded to a public registry).
>
> Well, containers are currently the only "supported" way to have parallel
> installation of any Fedora packages. In essence, we don't have a solution for
> parallel installation at all. If Modules are supposed to go with containers,
> why not tack them onto Silverblue instead of the main distro? From what I've
> read, it seems they would fit that usecase much better than a traditional
> distribution, and we wouldn't need to address the issues that come from
> modules overriding non-modular packages.
>

You're assuming that parallel-install is a thing that everyone needs
from every package on their system. Our research and surveys
determined that this was not in fact the case for the overwhelming
majority of real-world deployments. Most[1] deployments function with
a "one app per VM/container" mentality. In such cases,
parallel-installability is at best unnecessary and (such as with SCLs)
actively annoying to them. Modules offers the availability of multiple
streams of software like SCLs does, but it sacrifices the ability to
install them in parallel for the ability to install them in the
standard locations on disk so that other software doesn't need to
adapt to alternate locations (the number-one complaint received about
SCLs).


[1] Yes, I realize that "most" may not include you. Every environment
is unique, but we have to try and optimize our efforts for the largest
set of consumers possible. We reasoned that containers were a
sufficient workaround for the cases not following the "one app per
VM/container" approach.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Modularity: The Official Complaint Thread

[John M. Harris Jr]

On Thursday, November 14, 2019 11:15:15 AM MST Stephen Gallagher wrote:
> I'm not sure what you're asking here. I thought it was pretty clear
> from the paragraph you quoted that containers are the recommended
> solution for doing "parallel-install" with modules. Also, the
> relationship goes both ways; Modules provide a trusted source of
> software to run in containers (as opposed to running an image that
> someone uploaded to a public registry).

Well, containers are currently the only "supported" way to have parallel 
installation of any Fedora packages. In essence, we don't have a solution for 
parallel installation at all. If Modules are supposed to go with containers, 
why not tack them onto Silverblue instead of the main distro? From what I've 
read, it seems they would fit that usecase much better than a traditional 
distribution, and we wouldn't need to address the issues that come from 
modules overriding non-modular packages.

-- 
John M. Harris, Jr.
Splentity

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Modularity: The Official Complaint Thread

[Stephen Gallagher]

On Thu, Nov 14, 2019 at 12:24 PM John M. Harris Jr  wrote:
> > Yes, we acknowledge that with multiple versions comes the risks of
> > introducing more conflicts. We balanced that out by acknowledging that
> > the container space is now mature enough that separating userspaces
> > when you need to run conflicting apps on the same machine is a
> > reasonable solution to that problem. You've asserted elsewhere that
> > you don't like containers as a technology because it's duplication of
> > content and doesn't espouse your view of the ideal distribution of
> > "everything uses the same (latest) version of the library". I
> > understand that, but containers are here to stay and Modules help us
> > provide trustworthy content for them.
>
> What do containers have to do with Modularity? Is this a Silverblue project
> now?
>

I'm not sure what you're asking here. I thought it was pretty clear
from the paragraph you quoted that containers are the recommended
solution for doing "parallel-install" with modules. Also, the
relationship goes both ways; Modules provide a trusted source of
software to run in containers (as opposed to running an image that
someone uploaded to a public registry).
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Modularity: The Official Complaint Thread

[Neal Gompa]

On Thu, Nov 14, 2019 at 12:23 PM John M. Harris Jr  wrote:
>
> > Believe me, I wish that the ideal distribution was possible too. The
> > reality is that the world has gone in a different direction and Fedora
> > needs to adapt to that. Holding the line and refusing to budge just
> > means people will go around us and stop considering us relevant.
>
> This is simply not true. Debian is another clear example of this.
>

Unfortunately, Debian is pretty much the reason why things have swung
away from distributions. They operate in an extreme with a somewhat
hostile contribution model with aging, yet horrible tooling and a
culture for inaction. Their policies, tooling, and culture are
essentially antithetical to what people generally want. If you look at
a large swath of things using Debian as a base, they often *ignore*
what Debian provides and put their own stuff on top. There's almost no
real reuse from Debian, and that's the great tragedy.

Fedora has some advantages over Debian: our policies and culture is
generally favorable to those with a bias for action. Our tooling is
nowhere near as crufty as Debian's (though it's still not as nice as
openSUSE's in some cases). And our community is pretty well-engaged
compared to most, and we're not generally seeing a downward trend in
contributors (based on what Matthew said at Flock). And most
obviously, our software is much more up to date on a regular basis
than most other distributions.

That said, we *do* need to improve things and find new ways to make
Fedora appealing to more people, especially newer-generation infra
types and software developers. Otherwise, we'll lose the pipeline of
fresh blood into the project and eventually stagnate like Debian has.


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Modularity: The Official Complaint Thread

[John M. Harris Jr]

On Thursday, November 14, 2019 6:51:05 AM MST Stephen Gallagher wrote:
> What you are saying is that *you* don't like what you are hearing
> about modules. And that's fine; some of your feedback has been
> constructive and we're taking it into account. But assuming that you
> represent the whole of the user community is somewhat of an
> overstatement. As I discussed in the blog post I wrote, this was
> designed with users in mind.

It seems that a large portion of the community, at least those vocal on this 
thread, do agree with Miro, at least as surface value, myself included.


> Yes, we acknowledge that with multiple versions comes the risks of
> introducing more conflicts. We balanced that out by acknowledging that
> the container space is now mature enough that separating userspaces
> when you need to run conflicting apps on the same machine is a
> reasonable solution to that problem. You've asserted elsewhere that
> you don't like containers as a technology because it's duplication of
> content and doesn't espouse your view of the ideal distribution of
> "everything uses the same (latest) version of the library". I
> understand that, but containers are here to stay and Modules help us
> provide trustworthy content for them.

What do containers have to do with Modularity? Is this a Silverblue project 
now?

> Believe me, I wish that the ideal distribution was possible too. The
> reality is that the world has gone in a different direction and Fedora
> needs to adapt to that. Holding the line and refusing to budge just
> means people will go around us and stop considering us relevant.

This is simply not true. Debian is another clear example of this.

-- 
John M. Harris, Jr.
Splentity

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Modularity: The Official Complaint Thread

[Stephen Gallagher]

On Thu, Nov 14, 2019 at 9:19 AM Vít Ondruch  wrote:
>
> I wonder who is doing to clean up all the mess in dist-git we have due
> to modularity. specifically, I wonder about all these branches:
>
> https://src.fedoraproject.org/modules/nodejs/branches?branchname=master
>
> https://src.fedoraproject.org/rpms/nodejs/branches?branchname=master
>
>
> What is their state?
>

Fedora has a policy of never removing branches from dist-git because
legal obligations make it prohibitively difficult to determine when it
is safe to do so. As a result, Fedora just disallows removing them in
all cases.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Modularity: The Official Complaint Thread

[Vít Ondruch]

I wonder who is doing to clean up all the mess in dist-git we have due
to modularity. specifically, I wonder about all these branches:

https://src.fedoraproject.org/modules/nodejs/branches?branchname=master

https://src.fedoraproject.org/rpms/nodejs/branches?branchname=master


What is their state?


Vít


Dne 05. 11. 19 v 21:17 Stephen Gallagher napsal(a):
> Last week, I put out a blog post and fedora-devel thread describing
> the problems that we wanted to solve with Modularity. That thread was
> not ultimately as successful as I had hoped.
>
> My intention was to provide some scope to the problem, because it
> seemed that a lot of alternatives being floated were not seeing some
> of the more subtle cases that we were trying to address. However, the
> biggest problem is that nearly every email to the list has been
> started with a "Begging the Question" Fallacy. People have started
> from the premise that "Modularity is Bad" and all of the rest of the
> conversation has continued from there. I'd like to provide an
> opportunity for us as a community to *constructively* state our
> grievances with Modularity. The fundamental root cause of some of the
> miscommunication is, I believe, that Modularity has problems and that
> people have assumed that they are fundamental and unfixable.
>
> I'd like to gather a constructive list of the actual use-cases that
> you feel Modularity is causing problems for, with the following
> stipulations: Any *subjective* problems will be ignored. "I think
> writing YAML is harder than writing a spec file" is an example of a
> subjective opinion. Similarly, "change inevitably results in some
> learning curve" is a basic maxim of innovation and is not in and of
> itself an argument not to change. "Modularity requires me to write
> both a spec file and a YAML file, thereby increasing the total work"
> is an *objective* observation (and a valid one; I'm going to include
> it below in my own starter list). If you aren't sure if it's
> objective, a useful question is "is it quantitatively measurable?"
> (AKA "Can I assign a number to it and see that number increase or
> decrease when changing something about the implementation?")
>
> So, in the interest of highlighting some specific cases where the
> current, deployed[1] implementation (in no particular order):
>
> 1. Once enabled, a module stream is never changed on behalf of the
> user. While this adds some strong guarantees to those who want to run
> applications built from those streams, the presence of default streams
> changes the expected upgrade behavior for users. Traditionally, at
> upgrade a user would get the new release's most-updated version of all
> packages currently on their system. With Modularity, if one of their
> packages comes from a default stream and that stream is not the
> default for the next release, they will stay on the current stream (or
> be blocked from upgrading, if the current stream is unavailable on the
> next release). [2]
>
> 2. Packages moved out of traditional Fedora and into a default module
> stream are not available to the non-modular buildroot. [3]
>
> 3. Insufficient guidelines and rules have resulted in some modules
> being shipped in a state that makes it difficult or impossible to
> build other software for the distribution. In particular, the 'ant'
> and 'maven' modules have default streams that own the namespace of
> several of their dependencies that have been configured for private
> use rather than public to the rest of the distrtibution. [4]
>
> 4. Documentation of how to create a module stream is comprehensive but
> daunting. There is a lot of available information, but what is really
> lacking is a basic walkthrough for converting a single package to a
> module stream.
>
> 5. There is no specification defined for dropping a default or enabled
> module stream and returning to non-modular packages.
>
> 6. We don't provide a direct solution for parallel-installability.
> This is an intentional design decision, but it *is* arguably a
> regression from SCL functionality, so I'll include it here.
>
> 7. The implementation in DNF occurs in libdnf rather than at the
> libsolv layer, which makes it difficult to reimplement for other
> packaging or build tools (such as GNOME Software and OBS, resp.)
>
> 8. The YAML format for modulemd is complex and can be difficult to get
> started with. [5] [6]
>
> 9. We don't have a good document on how to MBS generates modules and
> their repositories. This makes it hard for other build-systems to
> replicate the behavior. [7]
>
> 10. The MBS has performance issues which make official builds take a
> long time. [8]
>
> 11. "Module Stream API" when used in a default stream causes package
> incompatibilities and unsupportable configurations. [4]
>
> 12. Packaging a module requires writing both a spec file and a
> modulemd YAML file, which increases the total amount of work I need to
> do. [5]
>
>
> I'm sure there are other pain points and I encourag

Re: Modularity: The Official Complaint Thread

[Vít Ondruch]

Dne 13. 11. 19 v 21:48 Stephen Gallagher napsal(a):
> On Wed, Nov 13, 2019 at 1:34 PM Kevin Kofler  wrote:
>> Aleksandar Kurtakov wrote:
>>> Here you seem to be missing the third option packager may choose -
>>> maintain none of them and say bye to Fedora. Which IMHO is the most likely
>>> outcome of all this.
>> "Say bye to Fedora" is what I am going to do if this forced modularity
>> madness is not going to stop, and I will be taking my 51 packages with me.
>>
>> A distribution that does not allow me to install 2 completely unrelated
>> applications just because they happen to transitively depend on different
>> versions of some library deep in the stack is entirely useless to me.
>>
> You keep repeating this statement as if I haven't said several times
> now: "If you have a library that can be installed in parallel, make a
> compat package. Modularity is not the correct solution for that case".


The problem is that no matter how often you said this, there will come
inquires such as:

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/O4NZVLFCZAUMPGGJ5ALM5X33MN2L7PPQ/

And this is probably still good case, because the intention was unveiled
on ML. There will be others which will sneak into Fedora unnoticed.


Vít


>
> You don't want to do that for libraries in general. Rather, it makes
> more sense if you need to swap out a framework of tightly
> interdependent packages. (Node.js or Django would be reasonable
> examples here). Another example that would make sense is... KDE.
> Instead of doing a mass-upgrade in the middle of a release, you could
> make the Plasma Workstation packages into a module with KDE release
> number as the stream. Then people could switch voluntarily to the next
> version if they want to do so mid-release or they can wait until an
> upgrade to the next release moves them over.
>
> Now, I realize we have some technical issues that prevent you from
> doing this today (the previously-acknowledged upgrade bugs). But if
> those were fixed, wouldn't it be *really convenient* to update the
> packages and then kick off a single build that would build for all
> active Fedora (and/or EPEL) releases? You'd only need to manage the
> single module build of all the components once, rather than a build
> per-component for each release you want to support. That's the
> usability goal we're working towards in Modularity. We've had a bit of
> trouble hitting our target for ease-of-use, but that's mostly because
> we encountered more edge-cases (and resistance) than we expected and
> have thus been dealing with the higher-priority issues first.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 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@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Modularity: The Official Complaint Thread

[Stephen Gallagher]

On Wed, Nov 13, 2019 at 6:09 PM Miro Hrončok  wrote:
>
> On 13. 11. 19 23:27, Kevin Kofler wrote:
> > So I guess the proposal is underspecified. What I really propose, and how I
> > read Miro's proposal as well (Miro, please correct me if that is not what
> > you intend), is that 1. any package that exists in a module MUST have a
> > default version and that 2. that version MUST be packaged in the ursine/non-
> > modular repository, not as a default stream.
> >
> > Point 1. is essential, as otherwise, point 2. alone will just lead to people
> > not declaring a default version at all, which is a completely broken state
> > and so even worse than the situation with the default stream, despite all
> > the issues with default streams.
>
> While I agree that this is what we should desire, it was deliberately left out
> of my proposal. My idea was to keep the ability of modular only packages, for
> the maintainers who decided that this is what they want to do things. For
> basically 2 reasons:
>
> 1. I don't see a reason for modular only packages without defaults, it doesn't
> mean there is none.
>

Modular packages without defaults makes sense if they have
dependencies on a non-default stream. For example: ReviewBoard depends
on the Django:1.6 stream because of complicated upstream reasons. I
have to choose between "modular without a default stream" or "not
available on Fedora", because we have agreed on a prohibition on
default streams with dependencies on non-default streams.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Modularity: The Official Complaint Thread

[Stephen Gallagher]

On Wed, Nov 13, 2019 at 5:29 PM Kevin Kofler  wrote:
>
> Aleksandra Fedorova wrote:
> > 1) there are exactly 6 default streams in Fedora rawhide
> >
> > dwm
> > avocado
> > scala
> > ant
> > gimp
> > maven
> >
> > and eclipse is being discussed.
>
> What about libgit2, was that not a default stream?
>

It was not. It was a dependency of other modules.

> And what we are missing here is a list of modular packages with no default
> version at all (i.e., neither an ursine build nor a default stream), a state
> which is completely broken (but which seems to currently exist in Fedora,
> unfortunately).
>

Could you define "broken"? Because I have no idea what you're talking
about here. If it is module-only and has no default stream, it means
it's effectively invisible unless you enable a stream knowingly.

> >> > Anyway, default streams is just one side of a story. It did get into
> >> > the critical path of Fedora and did create upgrade problems and
> >> > certain UX issues, but I think we can restrict and resolve it.
> >>
> >> And what is wrong with the obvious solution, which is to just not use
> >> default streams at all?
> >
> > The "obvious solution" does not solve anything for the Java stack in
> > Fedora and four Java modules currently having default stream.
>
> So I guess the proposal is underspecified. What I really propose, and how I
> read Miro's proposal as well (Miro, please correct me if that is not what
> you intend), is that 1. any package that exists in a module MUST have a
> default version and that 2. that version MUST be packaged in the ursine/non-
> modular repository, not as a default stream.
>
> Point 1. is essential, as otherwise, point 2. alone will just lead to people
> not declaring a default version at all, which is a completely broken state
> and so even worse than the situation with the default stream, despite all
> the issues with default streams.
>

Again, you can't just say "it's broken" and leave it at that. Some
clarity as to what you think is wrong there is critical.

> (Please note that I also read those 2 points as implicitly banning filtering
> packages from modules, but if that is not obvious to someone, then it should
> be added as a separate rule.)
>

It does not implicitly ban filtering packages. It implicitly bans
filtering out *sub*-packages. It still think it's acceptable to filter
out *all* produced subpackages of a component that is used only at
build-time.

> >> Why can the default version not be shipped in the
> >> tried and true non-modular way, so that people who do not need or want
> >> modules are not forced to use them against their will?
> >
> > This is a question to package maintainers who want to enable the default
> > stream. But by using your "will" as an argument against their "will" we
> > are not going anywhere in this conversation.
>
> We should cater to our users' needs, not let a handful individual packagers
> unilaterally dictate their personal preferences to thousands of users.
>

This is literally the entire point of a distribution. We provide an
opinionated collection of software packaged for people to use. This is
no different than RPMs. As a packager, I can decide arbitrarily to
ship a different default configuration than upstream does if I think
it makes more sense for the users we are serving. I can opt not to
build some features of a package if doing so would require pulling in
a huge set of dependencies, etc.

All of that is dictating the packager's preferences on our users.

What you are saying is that *you* don't like what you are hearing
about modules. And that's fine; some of your feedback has been
constructive and we're taking it into account. But assuming that you
represent the whole of the user community is somewhat of an
overstatement. As I discussed in the blog post I wrote, this was
designed with users in mind.

Yes, we acknowledge that with multiple versions comes the risks of
introducing more conflicts. We balanced that out by acknowledging that
the container space is now mature enough that separating userspaces
when you need to run conflicting apps on the same machine is a
reasonable solution to that problem. You've asserted elsewhere that
you don't like containers as a technology because it's duplication of
content and doesn't espouse your view of the ideal distribution of
"everything uses the same (latest) version of the library". I
understand that, but containers are here to stay and Modules help us
provide trustworthy content for them.

Believe me, I wish that the ideal distribution was possible too. The
reality is that the world has gone in a different direction and Fedora
needs to adapt to that. Holding the line and refusing to budge just
means people will go around us and stop considering us relevant.

> There are several practical reasons for not wanting to use modules, as I
> have already mentioned elsewhere in this thread. Please read my other
> replies, I do not want to repeat myself.
___

Re: Modularity: The Official Complaint Thread

[Miro Hrončok]

On 13. 11. 19 23:27, Kevin Kofler wrote:

So I guess the proposal is underspecified. What I really propose, and how I
read Miro's proposal as well (Miro, please correct me if that is not what
you intend), is that 1. any package that exists in a module MUST have a
default version and that 2. that version MUST be packaged in the ursine/non-
modular repository, not as a default stream.

Point 1. is essential, as otherwise, point 2. alone will just lead to people
not declaring a default version at all, which is a completely broken state
and so even worse than the situation with the default stream, despite all
the issues with default streams.


While I agree that this is what we should desire, it was deliberately left out 
of my proposal. My idea was to keep the ability of modular only packages, for 
the maintainers who decided that this is what they want to do things. For 
basically 2 reasons:


1. I don't see a reason for modular only packages without defaults, it doesn't 
mean there is none.


2. As long as the modular packages "stay away" they are not blocking anyone to 
maintain the same packages in non-modular Fedora. While I'd rather have the 
modular maintainers maintain the package in non-modular Fedora, we cannot force 
anybody to maintain what they don't want to maintain.


As a side note, I hope that if we actually abandon the idea of default modular 
streams, packagers who want their packages in "default" Fedora will only have 
one obvious way how to do it instead of the current situation, where there are 
basically 2 options.


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Modularity: The Official Complaint Thread

[Kevin Kofler]

Stephen Gallagher wrote:
> I'm wondering what you mean by "module mangling bits" here, because
> what you described here is pretty much *exactly what module builds
> do*.

I think Neal means the special treatment the modules get on the client (DNF) 
end.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Modularity: The Official Complaint Thread

[Kevin Kofler]

Aleksandra Fedorova wrote:
> 1) there are exactly 6 default streams in Fedora rawhide
> 
> dwm
> avocado
> scala
> ant
> gimp
> maven
> 
> and eclipse is being discussed.

What about libgit2, was that not a default stream?

And what we are missing here is a list of modular packages with no default 
version at all (i.e., neither an ursine build nor a default stream), a state 
which is completely broken (but which seems to currently exist in Fedora, 
unfortunately).

>> > Anyway, default streams is just one side of a story. It did get into
>> > the critical path of Fedora and did create upgrade problems and
>> > certain UX issues, but I think we can restrict and resolve it.
>>
>> And what is wrong with the obvious solution, which is to just not use
>> default streams at all?
> 
> The "obvious solution" does not solve anything for the Java stack in
> Fedora and four Java modules currently having default stream.

So I guess the proposal is underspecified. What I really propose, and how I 
read Miro's proposal as well (Miro, please correct me if that is not what 
you intend), is that 1. any package that exists in a module MUST have a 
default version and that 2. that version MUST be packaged in the ursine/non-
modular repository, not as a default stream.

Point 1. is essential, as otherwise, point 2. alone will just lead to people 
not declaring a default version at all, which is a completely broken state 
and so even worse than the situation with the default stream, despite all 
the issues with default streams.

(Please note that I also read those 2 points as implicitly banning filtering 
packages from modules, but if that is not obvious to someone, then it should 
be added as a separate rule.)

>> Why can the default version not be shipped in the
>> tried and true non-modular way, so that people who do not need or want
>> modules are not forced to use them against their will?
> 
> This is a question to package maintainers who want to enable the default
> stream. But by using your "will" as an argument against their "will" we
> are not going anywhere in this conversation.

We should cater to our users' needs, not let a handful individual packagers 
unilaterally dictate their personal preferences to thousands of users.

There are several practical reasons for not wanting to use modules, as I 
have already mentioned elsewhere in this thread. Please read my other 
replies, I do not want to repeat myself.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Modularity: The Official Complaint Thread

[Kevin Kofler]

Stephen Gallagher wrote:
> You don't want to do that for libraries in general.

Well yes. But the thing is, I am not convinced that this is universally 
agreed on, unfortunately.

What I really worry about is a scenario where, say, the KDE module includes 
NetworkManager version x, and the GNOME module includes NetworkManager 
version y (y≠x), making it impossible to install both desktops, or even just 
applications from the foreign desktop that happen to be included in and/or 
depend on that desktop's module.

> Rather, it makes more sense if you need to swap out a framework of tightly
> interdependent packages. (Node.js or Django would be reasonable examples
> here).

That still means that if there are 2 unrelated web apps based on a different 
version of Node.js or of Django, those web apps cannot be installed on the 
same web server, which is a quite unfortunate restriction.

Node.js and Django are really just (sets of) libraries, too!

> Another example that would make sense is... KDE. Instead of doing a
> mass-upgrade in the middle of a release, you could make the Plasma
> Workstation packages into a module with KDE release number as the stream.
> Then people could switch voluntarily to the next version if they want to
> do so mid-release or they can wait until an upgrade to the next release
> moves them over.

Given that "KDE" is actually Plasma Workspaces, KDE Applications, and KDE 
Frameworks, which release on separate schedules (there have no longer been 
monolithic "KDE" releases for several years now!), but where newer Plasma 
and Applications often require newer Frameworks too, and given that there 
are also third-party applications using the KDE Frameworks, modularizing the 
KDE software stack is not as straightforward as you seem to think.

I think at least the KDE Frameworks will always need to be updated distro-
wide, i.e., ursinely. For one, they are libraries (see the discussion 
above). And they maintain backwards compatibility, but of course not 
forwards. In addition, upstream do not maintain separate bugfix branches of 
KDE Frameworks, one is just expected to always upgrade to the latest monthly 
release (and point releases are only made in the rare event an intermediate 
release is needed). So one is normally always better off with the latest 
version.

But the KDE Applications bundle also ships a handful libraries, which 
typically do not maintain backwards compatibility (which is usually the 
reason they are not in Frameworks), and on which some external applications 
may depend, and there can also be external packages depending on the Plasma 
Workspaces. Hence, there may be packages that need to be rebuilt together 
with KDE Applications and/or Plasma Workspaces and would have to be added to 
their modules (if we were to make them modules), too.

And finally, I am not convinced what value that would really bring us over 
the existing solutions (Copr on one hand and official ursine updates on the 
other hand, on a case by case basis).

> But if those were fixed, wouldn't it be *really convenient* to update the
> packages and then kick off a single build that would build for all
> active Fedora (and/or EPEL) releases?

I don't think this is ever going to work that easily. Building once on one 
release and shipping for all is not going to work (that might be workable 
for Rust code, but definitely not for C++ code), and building for all 
releases separately at the same time means dealing with the errors specific 
to different releases (and also with the release-independent errors) all at 
the same time. This means that it will take longer to get new builds out for 
Rawhide, because the maintainer will be stuck also fixing the errors on 
Fedora n and even Fedora n-1 before being able to proceed with the Rawhide 
build.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Modularity: The Official Complaint Thread

[Stephen Gallagher]

On Wed, Nov 13, 2019 at 4:01 PM Neal Gompa  wrote:
>
> On Wed, Nov 13, 2019 at 3:49 PM Stephen Gallagher  wrote:
> >
> > On Wed, Nov 13, 2019 at 1:34 PM Kevin Kofler  wrote:
> > >
> > > Aleksandar Kurtakov wrote:
> > > > Here you seem to be missing the third option packager may choose -
> > > > maintain none of them and say bye to Fedora. Which IMHO is the most 
> > > > likely
> > > > outcome of all this.
> > >
> > > "Say bye to Fedora" is what I am going to do if this forced modularity
> > > madness is not going to stop, and I will be taking my 51 packages with me.
> > >
> > > A distribution that does not allow me to install 2 completely unrelated
> > > applications just because they happen to transitively depend on different
> > > versions of some library deep in the stack is entirely useless to me.
> > >
> >
> > You keep repeating this statement as if I haven't said several times
> > now: "If you have a library that can be installed in parallel, make a
> > compat package. Modularity is not the correct solution for that case".
> >
> > You don't want to do that for libraries in general. Rather, it makes
> > more sense if you need to swap out a framework of tightly
> > interdependent packages. (Node.js or Django would be reasonable
> > examples here). Another example that would make sense is... KDE.
> > Instead of doing a mass-upgrade in the middle of a release, you could
> > make the Plasma Workstation packages into a module with KDE release
> > number as the stream. Then people could switch voluntarily to the next
> > version if they want to do so mid-release or they can wait until an
> > upgrade to the next release moves them over.
> >
> > Now, I realize we have some technical issues that prevent you from
> > doing this today (the previously-acknowledged upgrade bugs). But if
> > those were fixed, wouldn't it be *really convenient* to update the
> > packages and then kick off a single build that would build for all
> > active Fedora (and/or EPEL) releases? You'd only need to manage the
> > single module build of all the components once, rather than a build
> > per-component for each release you want to support. That's the
> > usability goal we're working towards in Modularity. We've had a bit of
> > trouble hitting our target for ease-of-use, but that's mostly because
> > we encountered more edge-cases (and resistance) than we expected and
> > have thus been dealing with the higher-priority issues first.
>
> Could we have those parts without the module mangling bits? Having a
> definition to orchestrate the creation of the SRPMs, then order them
> correctly for a chain build, then push them into a defined side-tag
> would be glorious. Making it so that works across multiple releases
> for the same commit would be nirvana.
>
> Then we'd be talking about a reduced form of the yaml that controls
> the creation of side-tags, builds the RPMs into there, then lets you
> use the output side tag as an input for submitting a large update to
> Bodhi.

I'm wondering what you mean by "module mangling bits" here, because
what you described here is pretty much *exactly what module builds
do*.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Modularity: The Official Complaint Thread

[Neal Gompa]

On Wed, Nov 13, 2019 at 3:49 PM Stephen Gallagher  wrote:
>
> On Wed, Nov 13, 2019 at 1:34 PM Kevin Kofler  wrote:
> >
> > Aleksandar Kurtakov wrote:
> > > Here you seem to be missing the third option packager may choose -
> > > maintain none of them and say bye to Fedora. Which IMHO is the most likely
> > > outcome of all this.
> >
> > "Say bye to Fedora" is what I am going to do if this forced modularity
> > madness is not going to stop, and I will be taking my 51 packages with me.
> >
> > A distribution that does not allow me to install 2 completely unrelated
> > applications just because they happen to transitively depend on different
> > versions of some library deep in the stack is entirely useless to me.
> >
>
> You keep repeating this statement as if I haven't said several times
> now: "If you have a library that can be installed in parallel, make a
> compat package. Modularity is not the correct solution for that case".
>
> You don't want to do that for libraries in general. Rather, it makes
> more sense if you need to swap out a framework of tightly
> interdependent packages. (Node.js or Django would be reasonable
> examples here). Another example that would make sense is... KDE.
> Instead of doing a mass-upgrade in the middle of a release, you could
> make the Plasma Workstation packages into a module with KDE release
> number as the stream. Then people could switch voluntarily to the next
> version if they want to do so mid-release or they can wait until an
> upgrade to the next release moves them over.
>
> Now, I realize we have some technical issues that prevent you from
> doing this today (the previously-acknowledged upgrade bugs). But if
> those were fixed, wouldn't it be *really convenient* to update the
> packages and then kick off a single build that would build for all
> active Fedora (and/or EPEL) releases? You'd only need to manage the
> single module build of all the components once, rather than a build
> per-component for each release you want to support. That's the
> usability goal we're working towards in Modularity. We've had a bit of
> trouble hitting our target for ease-of-use, but that's mostly because
> we encountered more edge-cases (and resistance) than we expected and
> have thus been dealing with the higher-priority issues first.

Could we have those parts without the module mangling bits? Having a
definition to orchestrate the creation of the SRPMs, then order them
correctly for a chain build, then push them into a defined side-tag
would be glorious. Making it so that works across multiple releases
for the same commit would be nirvana.

Then we'd be talking about a reduced form of the yaml that controls
the creation of side-tags, builds the RPMs into there, then lets you
use the output side tag as an input for submitting a large update to
Bodhi.


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Modularity: The Official Complaint Thread

[Stephen Gallagher]

On Wed, Nov 13, 2019 at 1:34 PM Kevin Kofler  wrote:
>
> Aleksandar Kurtakov wrote:
> > Here you seem to be missing the third option packager may choose -
> > maintain none of them and say bye to Fedora. Which IMHO is the most likely
> > outcome of all this.
>
> "Say bye to Fedora" is what I am going to do if this forced modularity
> madness is not going to stop, and I will be taking my 51 packages with me.
>
> A distribution that does not allow me to install 2 completely unrelated
> applications just because they happen to transitively depend on different
> versions of some library deep in the stack is entirely useless to me.
>

You keep repeating this statement as if I haven't said several times
now: "If you have a library that can be installed in parallel, make a
compat package. Modularity is not the correct solution for that case".

You don't want to do that for libraries in general. Rather, it makes
more sense if you need to swap out a framework of tightly
interdependent packages. (Node.js or Django would be reasonable
examples here). Another example that would make sense is... KDE.
Instead of doing a mass-upgrade in the middle of a release, you could
make the Plasma Workstation packages into a module with KDE release
number as the stream. Then people could switch voluntarily to the next
version if they want to do so mid-release or they can wait until an
upgrade to the next release moves them over.

Now, I realize we have some technical issues that prevent you from
doing this today (the previously-acknowledged upgrade bugs). But if
those were fixed, wouldn't it be *really convenient* to update the
packages and then kick off a single build that would build for all
active Fedora (and/or EPEL) releases? You'd only need to manage the
single module build of all the components once, rather than a build
per-component for each release you want to support. That's the
usability goal we're working towards in Modularity. We've had a bit of
trouble hitting our target for ease-of-use, but that's mostly because
we encountered more edge-cases (and resistance) than we expected and
have thus been dealing with the higher-priority issues first.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Modularity: The Official Complaint Thread

[Kevin Kofler]

Aleksandar Kurtakov wrote:
> Here you seem to be missing the third option packager may choose -
> maintain none of them and say bye to Fedora. Which IMHO is the most likely
> outcome of all this.

"Say bye to Fedora" is what I am going to do if this forced modularity 
madness is not going to stop, and I will be taking my 51 packages with me.

A distribution that does not allow me to install 2 completely unrelated 
applications just because they happen to transitively depend on different 
versions of some library deep in the stack is entirely useless to me.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Modularity: The Official Complaint Thread

[Nicolas Mailhot via devel]

Le mardi 12 novembre 2019 à 16:09 -0500, Stephen John Smoogen a écrit :
> On Tue, 12 Nov 2019 at 15:36, Stephen Gallagher 
> wrote:
> > On Tue, Nov 12, 2019 at 12:40 PM Stephen John Smoogen <
> > smo...@gmail.com> wrote:
> > > 
> > The technology allows you to do this. The policy can restrict this.
> > Of
> > course, this particular example can be true of a non-modular RPM
> > too;
> > you don't *have* to build the X-devel subpackage.
> > 
> 
> I am asking these questions this way because of 20 years of RPM
> fights
> of people arguing over things because a spec file is a combination of
> a policy document and a technical document but people like to treat
> it
> as one or the other in the conversations. Getting it clear when you
> are speaking about the technical implementation of policy or the
> political implementation of technology up front gets that out of the
> way. Not being clear is where people start building their own mind
> castles to send armies of strawmen against.

I don’t think it’s that easy to distingish tech from policy.

No one wants a broken policy. Therefore, a successful policy is
intrinsically linked to the implementation that makes it work.

More often than not, what people call policy, is the human part of the
implementation. Automate this part one way or another, and people will
claim it's a tech artefact.

A whole (human + tech) works or not. Trying to define where the
frontier is within this whole does not bring a lot of value. The two
parts are two faces of the same coin (see also: Conway's law).

More generally, that means that trying to rip rpm from the Fedora
project, or the Fedora project from rpm, is doomed to failure. Creating
a new project around rpm will evolve into something very close to
Fedora/Suse/etc. Creating a new deployment tech within Fedora will
evolve into something very close to rpm (different implementation, same
behaviour).

Changing either Fedora or rpm requires making both the org, and the
tech, evolve gently in lockstep.

Regards,

-- 
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Modularity: The Official Complaint Thread

[Aleksandra Fedorova]

On Wed, Nov 13, 2019 at 1:25 AM Kevin Kofler  wrote:
>
> Aleksandra Fedorova wrote:
> > 1) I don't think Modularity is about being LTS and "enterprisy".
> > Lifecycle differences are not the only feature Modularity provides.
> >
> > I see Modularity as a tool which bridges the gap between container
> > world and a packaged distribution.
> >
> > Without modularity we have a base system with its limitations and the
> > explosion of containerized solutions which currently go through their
> > teen-age phase, denying the good old known practices and reinventing
> > wheels in terms of packaging, sharing, deduplication of effort and
> > security audit.
>
> This is not a property of not using modularity, but of using containers.
> Generating containers from modular repositories also only partly solves
> these issues. In particular, you still have to regenerate the entire
> container for a security fix in any included library.
>
> The best approach to avoid the drawbacks of containers is not to start using
> modules, but to stop using containers. :-)
>
> In addition, due to their non-parallel-installable nature, modules actually
> push more container use, and thus more duplication, more complex security
> updates, etc. So I think they actually have the opposite effect than what
> you claim.
>
> > Modularity allows us to use packaging approaches in a more flexible
> > but still controlled and maintained way. It creates building blocks
> > for containerized environments.
> > I think it is the way to go for Flatpacks, cloud images and other
> > layered solutions to use runtimes built on top of packaged streams,
> > rather than custom configurations.
>
> I also don't see why the containers cannot simply be built from a common
> tested platform (a non-modular Fedora release) rather than from arbitrarily
> mixed together streams. If your goal is sharing and deduplication of
> efforts, then that should actually be the goal. Adding module streams to the
> mix actually goes the opposite way.

Deduplication plays against flexibility, with fully packaged system on
one side and completely custom containerized environment on the other.

In my understanding, from the point of Fedora user adding module
streams is a small step towards being flexible(and therefore harder to
manage). From the point of view of containers it is a giant leap
towards deduplication, updates, security and all other nice things
which make container lifecycle so much easier.

> > And I think it is in scope of Fedora to drive this process to
> > normalize the currently chaotic container world.
>
> I think Fedora would be better off avoiding the container world altogether.
> It is a horribly inefficient way to deliver software compared to RPM
> packages.

I think we have to just disagree on that.

I believe that "containers are Linux", they have their uses and their
users, and we shouldn't be fighting against containerization, rather
should explain the benefits of packaged components as they can be used
in containers as well.

> > 2) I don't think Modularity is a failure in its current state.
> >
> > Yes, we do have a problem of default streams. There are several
> > reasons for that.
> >
> > One thing i find interesting is that: we were very cautious on tech
> > implementation side, delaying certain technical tools and solutions,
> > while we were not cautious enough on the process and policy.
> > And it feels like we should have done it the opposite way: iterate
> > (and sometimes fail) on the tooling faster, but have a much more
> > restrictive approach to the policy.
>
> Well yes, allowing people to abuse stable Fedora releases as a place on
> which to experiment with modules was a huge mistake. Those experiments
> should have been done in an optional opt-in repository. (And I would even
> argue that modules should always remain optional and opt-in, but in their
> current state, that is most definitely the case.)
>
> > And now we are trying to evaluate Modularity without actually giving
> > it a chance to be implemented _for real_.
>
> That is the part I disagree with. Already too much was implemented in
> production releases. We are seeing exactly the failure modes that I had
> already warned about right after reading the design documents.

To clarify, the current state of things:

1) there are exactly 6 default streams in Fedora rawhide

dwm
avocado
scala
ant
gimp
maven

and eclipse is being discussed.

2) we don't add new default modules;
3) we allowed tooling (Ursa Prime) which adds modular packages in
Fedora buildroot;
4) we allowed exactly two modules to be added in Fedora buildroot via
Ursa Prime: dwm and avocado;
5) the upgrade issue for modules is set to be a Beta Blocker.

> > Anyway, default streams is just one side of a story. It did get into
> > the critical path of Fedora and did create upgrade problems and
> > certain UX issues, but I think we can restrict and resolve it.
>
> And what is wrong with the obvious solution, which is to just no

Re: Modularity: The Official Complaint Thread

[Nicolas Mailhot via devel]

Le 2019-11-13 10:14, Aleksandra Fedorova a écrit :


Exactly the same way as "stay away" won't work for automatic
BuildRequires generator feature, which we voted for in this cycle.


Sure you can, automated BRs are a specific section in the spec file, 
staying away no more complex that not filling this section (of course, 
if you take someone else’s spec and it depends on this section, you get 
to define BRs manually if you void it)


Regards

--
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Modularity: The Official Complaint Thread

[Fabio Valentini]

On Wed, Nov 13, 2019 at 10:04 AM Fabio Valentini  wrote:
>
> On Wed, Nov 13, 2019 at 6:18 AM Aleksandar Kurtakov  
> wrote:
> >
> >
> >
> > On Wed, Nov 13, 2019 at 3:17 AM Kevin Kofler  wrote:
> >>
> >> Aleksandar Kurtakov wrote:
> >> > So people would prefer no packages at all over packages in modules?
> >>
> >> I see 2 reasons so far why some packages are module-only:
> >> 1. because a dependency of the package is module-only. That is exactly what
> >>we want to prevent by proposing a ban on module-only packages.
> >> 2. because the maintainer wants to maintain only one version and chose the
> >>modular one. Banning module-only packages will hopefully get the
> >>maintainer to either maintain the non-modular version instead or to
> >>maintain both versions after all.
> >
> >
> > Here you seem to be missing the third option packager may choose - maintain 
> > none of them and say bye to Fedora. Which IMHO is the most likely outcome 
> > of all this.
>
> Hi Aleksandar,
>
> I agree that this has not gone well for both eclipse and its
> maintainers in fedora.
>
> I'm also a bit surprised that none of the current eclipse maintainers
> has approached the Stewardship SIG and asked for help.
> I think we could have prevented the worst problems for non-modular
> eclipse (at least the core packages), but we just didn't know what to
> do (and nobody told us).
>
> While it might be too late now, an offer to help with making
> non-modular eclipse packages work again (if that's even wanted
> anymore) is on the table.
> Right now, we just don't have the knowledge and manpower to do that
> alone and without input from eclipse maintainers.
>
> We probably should also start looking into the derelict Java SIG -
> starting with pruning of members that are now AWOL, and updating the
> Wiki page to actually reflect the current state. I think there
> definitely *are* people who are interested in keeping (non-modular)
> eclipse packages working, but - like us - they probably don't even
> know where to start. Reviving the Java SIG might be a way to herd the
> cats into the right direction.
>
> Fabio

And, while I'm here, I should also raise some complaints (this is the
Complaint Thread, after all) ;)

The situation where both modular and non-modular versions of a package
exist are  problematic.

user-system problems:
- It's not always clear which incarnation of a package will get
installed on a user's system. do they have to explicitly enable a
module, or can that happen silently?
- It's unfair to maintainers of "ursine" branches, since their
beautiful, up-to-date, packages that are filled with security patches
will just get shadowed by modular versions, regardless of package
versions.
- What if the modular and non-modular branches have made incompatible
changes since the branches diverged? For example, the modular branch
has disabled some features that are still enabled in the ursine
branches because other ursine packages rely on them. I assume the
modular version will trump here and break ursine packages?
- What if modular (or ursine, direction doesn't matter) branches
include major version upgrades, which necessitate either other package
updates or patches in other packages? Will this lead to conflicts, or
broken packages?

development / build-time problems:
- What if a package is provided as both ursine and modular package,
and Ursa Prime is enabled for a module that contains this package?
- Will the modular version of the package always override the ursine
one, regardless of package version?
- What about incompatible divergence, major version differences, or
"System-Wide Changes" (same problem as on user systems explained
above)?

I've raised most of these concerns now multiple times over the past
few years, but I never got a complete answer, or no answer at all.

Fabio


> >>
> >>
> >> > I ask this as the traditional rpm way of doing is simply not working and
> >> > that's the reason why many of us (old time Java packagers) just gave up,
> >> > it's purely impossible to satisfy the needs of multiple "major" packages
> >> > with same set of dependencies.
> >>
> >> It is very much possible, just ship parallel-installable compatibility
> >> packages. For Java JARs, you can simply ship the non-default versions as
> >> name-version.jar (which is actually how most upstreams ship their binaries
> >> as well) rather than just name.jar, then they won't conflict. (Of course,
> >> the package name has to be suffixed with the version as well, as for all
> >> compatibility packages.)
> >>
> >> Using modules for that purpose is broken by design because you are just
> >> pushing the problem from the packager to the end user, who will not be able
> >> to install the 2 unrelated packages on the same machine due to conflicting
> >> dependencies.
> >>
> >> Kevin Kofler
> >> ___
> >> devel mailing list -- devel@lists.fedoraproject.org
> >> To unsubscribe send an email to 

Re: Modularity: The Official Complaint Thread

[Aleksandra Fedorova]

On Wed, Nov 13, 2019 at 12:00 AM Miro Hrončok  wrote:
>
> On 12. 11. 19 18:25, Aleksandra Fedorova wrote:
> > On Tue, Nov 12, 2019 at 5:10 PM Miro Hrončok  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.
>
> Ursa Prime effort puts module sin the buildroot. I'm still waiting to hear 
> about
> how it deals with conflicts with non-modular packages, how it works with mock
> and what it actually does.
>
> Not getting those answers was one of the many reasons I voted against the 
> change
> proposal. Yet every time I point out my reasons, people seem to only see the 
> one
> that says I think we should not have default streams at all. And I kinda get
> that, but the other reasons are equally important.
>
> Before I get the answers, I cannot agree or disagree with you, because I don't
> know what it achieves or not.
>
> However, and I speculate here, IMHO it only gives me the ability to 
> buildrequire
> a modular (meeting certain criteria) package from a non-modular package. It
> doesn't give me a "stay away" card. I still need to deal with modules if my
> package depends on them or if they depend on my package.
>
> As an example, if I choose to depend on module and the modular maintainer
> chooses not to care about the module,  it gets broken or insecure and I have 
> no
> way to fix it other than learning how to do modules.

Yes, the "stay away" wouldn't work in case you would like to
co-maintain or unorphan the modularized package.

Exactly the same way as "stay away" won't work for automatic
BuildRequires generator feature, which we voted for in this cycle.

If you are not familiar with the concept, then to adopt the package,
which is using it, you are going to need to learn the concept first.
And (at least for me) the modules metadata file which describes group
of _standard_ RPM packages is a much easier concept to grasp.

> As an example, I've asked months ago what should I do with modules when we do
> mass Python 3.8 rebuilds. The answer was... it's complicated. (I can search 
> the
> devel list if you want details.)
>
> As an example, if I want to see what requires python2 on rawhide, I don't see
> any modules there (this was couple months ago, the situation may have changed
> now but will repeat when f32 branches).

This is not relevant to the "make modules non-viral" goal.

> So, no, I don't believe Ursa Prime achieves the goal. But I might just be not
> informed well, because the Ursa Prime change proposal is not informational
> enough in this regard. In that case, sorry for spreading panic.

Ursa Prime is not an ultimate answer to everything, it is a tool which
provides a specific functionality.
As I mentioned earlier, blocking the development of a tooling leads to
a deadlock: we can not have a good solution because there are no tools
for it, and there are no tools for it because we don't have a good
solution.

> > 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".
>
> And I think it needs to change to: no default modular streams.
> Yes, once all the concerns that I and our community members I choose to
> represent have are settled, we can revisit this. But that doesn't mean we 
> should
> explicitly treat it as a temporary policy.
>
> > 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.
>
> The _technical_ difference is that it's built differently, from a different
> place, in a different way, with different rules. And if we "fix" that, we no
> longer have default modular streams.
>
> To clarify: Another _technical_ difference are broken upgrades, but that can 
> be
> fixed, so I treat that behavior as a bug and will not use it as an argument.
> However, if it is proven that we are not able to fix it, it may become an
> argument as well.
>
> > It
> > is the same rpm spec from the same dis

Re: Modularity: The Official Complaint Thread

[Fabio Valentini]

On Wed, Nov 13, 2019 at 6:18 AM Aleksandar Kurtakov  wrote:
>
>
>
> On Wed, Nov 13, 2019 at 3:17 AM Kevin Kofler  wrote:
>>
>> Aleksandar Kurtakov wrote:
>> > So people would prefer no packages at all over packages in modules?
>>
>> I see 2 reasons so far why some packages are module-only:
>> 1. because a dependency of the package is module-only. That is exactly what
>>we want to prevent by proposing a ban on module-only packages.
>> 2. because the maintainer wants to maintain only one version and chose the
>>modular one. Banning module-only packages will hopefully get the
>>maintainer to either maintain the non-modular version instead or to
>>maintain both versions after all.
>
>
> Here you seem to be missing the third option packager may choose - maintain 
> none of them and say bye to Fedora. Which IMHO is the most likely outcome of 
> all this.

Hi Aleksandar,

I agree that this has not gone well for both eclipse and its
maintainers in fedora.

I'm also a bit surprised that none of the current eclipse maintainers
has approached the Stewardship SIG and asked for help.
I think we could have prevented the worst problems for non-modular
eclipse (at least the core packages), but we just didn't know what to
do (and nobody told us).

While it might be too late now, an offer to help with making
non-modular eclipse packages work again (if that's even wanted
anymore) is on the table.
Right now, we just don't have the knowledge and manpower to do that
alone and without input from eclipse maintainers.

We probably should also start looking into the derelict Java SIG -
starting with pruning of members that are now AWOL, and updating the
Wiki page to actually reflect the current state. I think there
definitely *are* people who are interested in keeping (non-modular)
eclipse packages working, but - like us - they probably don't even
know where to start. Reviving the Java SIG might be a way to herd the
cats into the right direction.

Fabio

>>
>>
>> > I ask this as the traditional rpm way of doing is simply not working and
>> > that's the reason why many of us (old time Java packagers) just gave up,
>> > it's purely impossible to satisfy the needs of multiple "major" packages
>> > with same set of dependencies.
>>
>> It is very much possible, just ship parallel-installable compatibility
>> packages. For Java JARs, you can simply ship the non-default versions as
>> name-version.jar (which is actually how most upstreams ship their binaries
>> as well) rather than just name.jar, then they won't conflict. (Of course,
>> the package name has to be suffixed with the version as well, as for all
>> compatibility packages.)
>>
>> Using modules for that purpose is broken by design because you are just
>> pushing the problem from the packager to the end user, who will not be able
>> to install the 2 unrelated packages on the same machine due to conflicting
>> dependencies.
>>
>> Kevin Kofler
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> 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@lists.fedoraproject.org
>
>
>
> --
> Alexander Kurtakov
> Red Hat Eclipse Team
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 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@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Modularity: The Official Complaint Thread

[Nicolas Mailhot via devel]

Le 2019-11-13 07:39, Nicolas Mailhot a écrit :

Le mercredi 13 novembre 2019 à 06:43 +0100, Nicolas Mailhot via devel a



And anyway, if anyone feels the module design is actually needed (I
don’t, because the problems are elsewhere), it could have been *easily*
implemented within existing tools, without adding new infra to the mix,
just with


Make that:
1. in-module packages are named modulename-module
2. they include the following call after the Name: line
%module modulename

With %module defined as
%module(v) %{lua:
  local fedora = require "fedora.common"
  localverbose = (rpm.expand("%{-v}") ~= "")
  local modulename = rpm.expand("%1")
  localpkgname = string.gmatch(rpm.expand(%{name}, "^" .. modulename 
.. "-", ""))

  fedora.safeset("modulename", modulename, verbose)
  print(rpm.expand(
"Provides: module(" .. modulename .. ")\n" ..
"Provides: " .. pkgname .. " = %{version}-%{release}\n"))
 -- add epoch if you really like it
}

3. in-module (Build)deps are declared as
(Build)Requires: (usual-depname with module(modulename))

(the with dep filtering is an optimization that should be done in rpm 
with or without modules if it’s not already the case: filter-out foo req 
if (foo with bar) also exists)


All the rest of the module complexity could have been provided as 
syntactic sugar in dnf+libdnf (maybe, with some work on indexes to 
optimize things a bit), without impacting the Fedora packager workflow 
and tooling in any way.


And "all the rest" is, with hindsight, quite complex to define (what to 
do when modules conflict).


But, none of the MBS & module-only yaml descriptors actually help here. 
Those things are a distraction. The complexity was always to define sane 
management policies. It was never in rpm technical limitations.


Regards,
--
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Modularity: The Official Complaint Thread

[Miro Hrončok]

On 13. 11. 19 6:17, Aleksandar Kurtakov wrote:



On Wed, Nov 13, 2019 at 3:17 AM Kevin Kofler > wrote:


Aleksandar Kurtakov wrote:
 > So people would prefer no packages at all over packages in modules?

I see 2 reasons so far why some packages are module-only:
1. because a dependency of the package is module-only. That is exactly what
    we want to prevent by proposing a ban on module-only packages.
2. because the maintainer wants to maintain only one version and chose the
    modular one. Banning module-only packages will hopefully get the
    maintainer to either maintain the non-modular version instead or to
    maintain both versions after all.


Here you seem to be missing the third option packager may choose - maintain none 
of them and say bye to Fedora. Which IMHO is the most likely outcome of all this.


It is certainly a valid case.

However, using the same logic, doing the module-only thing might have driven 
other maintainers away as well. Already.


In my opinion, we better ban default modular streams sooner, when the number of 
maintainers who are affected is low. And we must be very very careful to explain 
ourselves to them. To apologies to them. To coordinate with them. To make them 
feel like they are part of this project. We would not be doing this because we 
don't want them. We should be doing this, because retrospectively, going to 
modular-only was not a good decision. Something that might not be clear to them 
at the beginning, when all the messaging was about how modularity is good and 
when the voices of naysayers were drown out by the cheering for the new thing.


We are in an unfortunate situation. And we may activate a contingency plan that 
is indeed not ideal for everybody. Or we may choose to ignore this and continue 
to make the situation worse. Every step forward we take makes the contingency 
more painful in the future.


I'm so sorry.

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Modularity: The Official Complaint Thread

[Nicolas Mailhot via devel]

Le mercredi 13 novembre 2019 à 06:43 +0100, Nicolas Mailhot via devel a
écrit :
> 
> Fedora modules are an horrifically complex way to pretend those basic
> three constrains  do not exist, while actually implementing them
> (except in a broken non-working way, because the *pretence* is that
> the constrains do not exist).

And anyway, if anyone feels the module design is actually needed (I
don’t, because the problems are elsewhere), it could have been *easily*
implemented within existing tools, without adding new infra to the mix,
just with

1. packages contained in modulename are named -usual-name

2.  packages contained in modulename should include in their spec

%global module modulename 

3. in-module (Build)deps are declared with

(Build)Requires: (usual-depname with module(modulename))

and then you add some rather trivial logic in rpm to provide
module(modulename)
when the module variable is declared, and to inhibit
auto(Build)Requires for foo
when the same is already present as
(Build)Requires (foo module(modulename))

There are *no* drawbacks, except forcing packagers to be explicit about
modules, to think about what they want to take in a module and what
they want to take elsewhere, to think about conflicts.

Not thinking about all those parts is why current Fedora modules do not
play well with one another or with the rest of the distribution. The
module system can not invent info packagers didn't provide explicitely.

But no, people wanted to play with a NiH start-from-scratch design.

Regards,

-- 
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Modularity: The Official Complaint Thread

[Nicolas Mailhot via devel]

Le mercredi 13 novembre 2019 à 06:43 +0100, Nicolas Mailhot via devel a
écrit :
> 
> The native Go component format (also, confusingly, named
> module) handles those 3 constrains and won't present any core
> difficulty in rpm packaging once it is finished upstream.

And, BTW, we added auto-builderequires in rpm 4.15 so you can automate
the mapping between well-behaved language component systems and rpm,
and individual packagers do not have to care about this mapping in each
and every package, when upstream has already made the effort to manage
its component versionning.

It effectively gives us the same capabilities as modules in rpm proper,
in a working reliable way, without all the tech complexity invented
module-side.

-- 
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Modularity: The Official Complaint Thread

[Nicolas Mailhot via devel]

Le mercredi 13 novembre 2019 à 00:19 +0200, Aleksandar Kurtakov a
écrit :
> 
> 
> On Wed, Nov 13, 2019 at 12:02 AM John M. Harris Jr <
> joh...@splentity.com> wrote:
> > On Tuesday, November 12, 2019 9:02:07 AM MST Aleksandra Fedorova
> > wrote:
> > > Again, no one forces you or any other packager to use modularity
> > > tooling right now.
> > 
> > This is not actually the case. We have several major packages which
> > are ONLY 
> > available as modules, for example.
> 
> So people would prefer no packages at all over packages in modules? I
> ask this as the traditional rpm way of doing is simply not working
> and that's the reason why many of us (old time Java packagers) just
> gave up, it's purely impossible to satisfy the needs of multiple
> "major" packages with same set of dependencies. This is not Java
> problem only for sure - look at Rust, Go, etc. 

Having spend a lot of time Go-side this past year, there is *no* way in
which traditional rpm packaging limits us.

Traditional rpm packaging has always permitted packaging as many
component versions as was needed.

It *does* require that an ecosystem that can not settle down on a
single component version, actually tracks what version each build uses.

It *does* require defining an upgrade path once multiple versions are
allowed to exist.

It *does* require that multiple versions, expected to exist
simultaneously on the filesystem, use different file paths (and thus
requires defining those paths to be sure they do not collide).

All of those are inescapable consequences of multi-versionning and
parallel install.

The native Go component format (also, confusingly, named
module) handles those 3 constrains and won't present any core
difficulty in rpm packaging once it is finished upstream.

Fedora modules are an horrifically complex way to pretend those basic
three constrains  do not exist, while actually implementing them
(except in a broken non-working way, because the *pretence* is that the
constrains do not exist).

And, having spent a lot of time packaging Java software 20 years ago, I
can tell you that the Java language is no different from Go.

*However* the Java ecosystem has spent a lot of time and energy,
refusing to ackowledge it needs to track component versions, refusing
to ackowledge  it needs to define upgrade paths, refusing to
ackowledge it needs to define version-specific file paths.

*That* is your core problem, not packaging tech (rpm, module, maven
osgi, or anything else).

The reason you’re attracted to modules is that on *short* deployment
time windows, you can pretend the constrains do not exist, and just use
whatever component version is available. That is why ignoring the
constrains works dev-side – everything is ephemeral, nothing is
supposed to survive long after a dev build., nothing is shared with
other builds. And modules allowed you to get rid of the past, ie reduce
the time window, for a short while.

The reason the result fell over, in rpm, and in modules, is that on
*long* distro-scale deployment time windows, you can *not* ignore those
constrains.

Anything you do in modules, containers, or whatever, without taking the
long-term versioning constrains into account, will only work for a
short period of time.

Unicorns do not exist in real life.

Regards,

-- 
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Modularity: The Official Complaint Thread

[Aleksandar Kurtakov]

On Wed, Nov 13, 2019 at 3:17 AM Kevin Kofler  wrote:

> Aleksandar Kurtakov wrote:
> > So people would prefer no packages at all over packages in modules?
>
> I see 2 reasons so far why some packages are module-only:
> 1. because a dependency of the package is module-only. That is exactly what
>we want to prevent by proposing a ban on module-only packages.
> 2. because the maintainer wants to maintain only one version and chose the
>modular one. Banning module-only packages will hopefully get the
>maintainer to either maintain the non-modular version instead or to
>maintain both versions after all.
>

Here you seem to be missing the third option packager may choose - maintain
none of them and say bye to Fedora. Which IMHO is the most likely outcome
of all this.


>
> > I ask this as the traditional rpm way of doing is simply not working and
> > that's the reason why many of us (old time Java packagers) just gave up,
> > it's purely impossible to satisfy the needs of multiple "major" packages
> > with same set of dependencies.
>
> It is very much possible, just ship parallel-installable compatibility
> packages. For Java JARs, you can simply ship the non-default versions as
> name-version.jar (which is actually how most upstreams ship their binaries
> as well) rather than just name.jar, then they won't conflict. (Of course,
> the package name has to be suffixed with the version as well, as for all
> compatibility packages.)
>
> Using modules for that purpose is broken by design because you are just
> pushing the problem from the packager to the end user, who will not be
> able
> to install the 2 unrelated packages on the same machine due to conflicting
> dependencies.
>
> Kevin Kofler
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 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@lists.fedoraproject.org
>


-- 
Alexander Kurtakov
Red Hat Eclipse Team
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Modularity: The Official Complaint Thread

[Kevin Kofler]

Stephen Gallagher wrote:
> Modular builds have metadata that can indicate to consumers which
> subpackages in this module should be considered "API". If a module
> produces a package artifact and does not list it thusly, it is meant
> to be treated as an internal implementation detail of the module (and
> that the maintainer is not committing to maintaining that particular
> package for any purpose other than supporting the API content of this
> module).
> 
> We also have "filters" which are intended for allowing module
> packagers to build and use build-time-only packages. They are built
> and added to the module buildroot as part of the build process, but
> they are filtered out so they don't end up in the final composed
> repository. (This is useful if, for example, your package used a small
> subset of some other package only at build-time and you don't want to
> have to maintain that package for everyone in the distro just to build
> yours).

Both of these should be equally disallowed by policy in Fedora (and in ALL 
module streams, not just in default streams). Filtering packages is even 
worse than declaring them non-API. It even interferes with installing non-
modular versions of the filtered packages (reportedly a common issue on 
RHEL). And it is just an anti-social thing to do and against the goals of 
Fedora (it conflicts with at least the following ideals that I would have 
believed we all share: transparency, cooperation rather than duplication, 
self-hosting). If your build-time dependency does not logically belong into 
your module, then you should get it into Fedora proper and ask for 
comaintainers, not take it private by filtering it from your module.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Modularity: The Official Complaint Thread

[Kevin Kofler]

Aleksandar Kurtakov wrote:
> So people would prefer no packages at all over packages in modules?

I see 2 reasons so far why some packages are module-only:
1. because a dependency of the package is module-only. That is exactly what
   we want to prevent by proposing a ban on module-only packages.
2. because the maintainer wants to maintain only one version and chose the
   modular one. Banning module-only packages will hopefully get the
   maintainer to either maintain the non-modular version instead or to
   maintain both versions after all.

> I ask this as the traditional rpm way of doing is simply not working and
> that's the reason why many of us (old time Java packagers) just gave up,
> it's purely impossible to satisfy the needs of multiple "major" packages
> with same set of dependencies.

It is very much possible, just ship parallel-installable compatibility 
packages. For Java JARs, you can simply ship the non-default versions as
name-version.jar (which is actually how most upstreams ship their binaries 
as well) rather than just name.jar, then they won't conflict. (Of course, 
the package name has to be suffixed with the version as well, as for all 
compatibility packages.)

Using modules for that purpose is broken by design because you are just 
pushing the problem from the packager to the end user, who will not be able 
to install the 2 unrelated packages on the same machine due to conflicting 
dependencies.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Modularity: The Official Complaint Thread

[Kevin Kofler]

Aleksandar Kurtakov wrote:
> The way Eclipse is treated makes me really sad and kind of regret the time
> spent on Fedora over the years! Being forced to be a module but blocked to
> be default stream by FESCo arguing over whether it wants modularity
> (sorry, this is how it looks) is the best way for Fedora to show to
> project and people they are not wanted in the community!

You should not blame the people arguing over whether more and more default 
streams are a good thing for your trouble, but the people who caused your 
trouble to begin with by modularizing the Java stack.

Java needs to be demodularized. Completely. As a platform (i.e., a 
programming language and/or a set of libraries, Java is both), it is 
absolutely not suited for modules, because they are version conflicts 
waiting to happen. Platforms need to be treated the traditional way, 
shipping one system version, and if that is not enough, parallel-installable 
compatibility packages in addition.

The lack of parallel installability makes modules only suitable for leaf 
packages.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Modularity: The Official Complaint Thread

[Kevin Kofler]

Stephen Gallagher wrote:

> On Tue, Nov 12, 2019 at 12:31 PM Aleksandra Fedorova 
> wrote:
>> Ursa Prime effort achieves the same goal. It removes the "viral" part
>> of Modularity I think.
> 
> That is absolutely its purpose. If we fall short of that, it's a bug
> and we will fix it as soon as possible.

Unfortunately, Ursa Prime is a build-time-only workaround and does not help 
end users at all.

>> 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.
> 
> I'll acknowledge that there may be subtle differences (such as the
> different "release" tag), but none (offhand) that should have a
> meaningful impact as long as other policy is in place.

There are major technical differences in how DNF processes the package 
(which is technically mostly related to repository metadata rather than to 
the RPM itself, which is indeed not all that different, but that changes 
nothing for the end user), when it comes to choice of preferred version, 
upgrade paths, etc. And the behavior for ursine repositories is much more 
user-friendly than the one for modules (where the default stream trumps even 
local packages, ignoring the EVR entirely, where the upgrade path from 
release to release is still an unsolved problem, where you can only choose a 
version to upgrade or downgrade to for the entire module vs. individual 
packages, where a module can hard-require a version of the entire 
distribution, forcing its removal when you upgrade Fedora, independently of 
the actual package-level dependencies, etc.).

If you were to implement something like Ursa Prime for the end user repos 
and enable the resulting non-modular repository by default instead of 
fedora-modular (i.e., Miro's alternate proposal), I would probably complain 
a lot less about Modularity. But as it stands, I support Miro's preferred 
proposal, i.e., to simply stop using default streams, which I think gives us 
essentially the same effect with much less efrort.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Modularity: The Official Complaint Thread

[Kevin Kofler]

Igor Gnatenko wrote:
> You say we need to improve tooling and iterate fast, fine. But why then
> https://pagure.io/releng/issue/7662 is still not implemented? I understand
> that it is opensource And everyone can contribute, but the fact is that
> people who work on Modularity tooling is entirely paid by RH and those
> people are "responsible" to bring it to Fedora and make it work. However,
> as written in the ticket "it is not a priority for that team".

Building a module on Fedora n and shipping it on Fedora m (where n≠m) is 
something that should not be allowed to begin with. We don't do that for 
normal packages for a reason.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Modularity: The Official Complaint Thread

[Kevin Kofler]

Aleksandra Fedorova wrote:
> 1) I don't think Modularity is about being LTS and "enterprisy".
> Lifecycle differences are not the only feature Modularity provides.
> 
> I see Modularity as a tool which bridges the gap between container
> world and a packaged distribution.
> 
> Without modularity we have a base system with its limitations and the
> explosion of containerized solutions which currently go through their
> teen-age phase, denying the good old known practices and reinventing
> wheels in terms of packaging, sharing, deduplication of effort and
> security audit.

This is not a property of not using modularity, but of using containers. 
Generating containers from modular repositories also only partly solves 
these issues. In particular, you still have to regenerate the entire 
container for a security fix in any included library.

The best approach to avoid the drawbacks of containers is not to start using 
modules, but to stop using containers. :-)

In addition, due to their non-parallel-installable nature, modules actually 
push more container use, and thus more duplication, more complex security 
updates, etc. So I think they actually have the opposite effect than what 
you claim.

> Modularity allows us to use packaging approaches in a more flexible
> but still controlled and maintained way. It creates building blocks
> for containerized environments.
> I think it is the way to go for Flatpacks, cloud images and other
> layered solutions to use runtimes built on top of packaged streams,
> rather than custom configurations.

I also don't see why the containers cannot simply be built from a common 
tested platform (a non-modular Fedora release) rather than from arbitrarily 
mixed together streams. If your goal is sharing and deduplication of 
efforts, then that should actually be the goal. Adding module streams to the 
mix actually goes the opposite way.

> And I think it is in scope of Fedora to drive this process to
> normalize the currently chaotic container world.

I think Fedora would be better off avoiding the container world altogether. 
It is a horribly inefficient way to deliver software compared to RPM 
packages.

> 2) I don't think Modularity is a failure in its current state.
> 
> Yes, we do have a problem of default streams. There are several
> reasons for that.
> 
> One thing i find interesting is that: we were very cautious on tech
> implementation side, delaying certain technical tools and solutions,
> while we were not cautious enough on the process and policy.
> And it feels like we should have done it the opposite way: iterate
> (and sometimes fail) on the tooling faster, but have a much more
> restrictive approach to the policy.

Well yes, allowing people to abuse stable Fedora releases as a place on 
which to experiment with modules was a huge mistake. Those experiments 
should have been done in an optional opt-in repository. (And I would even 
argue that modules should always remain optional and opt-in, but in their 
current state, that is most definitely the case.)

> And now we are trying to evaluate Modularity without actually giving
> it a chance to be implemented _for real_.

That is the part I disagree with. Already too much was implemented in 
production releases. We are seeing exactly the failure modes that I had 
already warned about right after reading the design documents.

> Anyway, default streams is just one side of a story. It did get into
> the critical path of Fedora and did create upgrade problems and
> certain UX issues, but I think we can restrict and resolve it.

And what is wrong with the obvious solution, which is to just not use 
default streams at all? Why can the default version not be shipped in the 
tried and true non-modular way, so that people who do not need or want 
modules are not forced to use them against their will?

> For that we need to focus on the issue, which is, from my point of
> view: default streams and their differences from the ursine packages.
> 
> One is caused by the lack of Ursa Prime, another is the upgrade
> functionality,

And both are complex technical mechanisms, which will certainly come with 
their own bugs and drawbacks, all just to emulate a world without default 
streams while shipping default streams. I see no practical benefits 
whatsoever of that approach over the straightforward KISS approach of just 
not using default streams anymore.

> and I guess the third one is the non-api and filtered packages in the
> module.

That one is something that just needs to be banned in Fedora altogether.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedora

Re: Modularity: The Official Complaint Thread

[Nico Kadel-Garcia]

You mean like quota-devel?

Sent from my iPhone

> On Nov 12, 2019, at 4:14 PM, Dominik 'Rathann' Mierzejewski 
>  wrote:
> 
> On Tuesday, 12 November 2019 at 22:07, Stephen Gallagher wrote:
>>> On Tue, Nov 12, 2019 at 4:03 PM Dominik 'Rathann' Mierzejewski
>>>  wrote:
>>> 
 On Tuesday, 12 November 2019 at 21:15, Stephen Gallagher wrote:
>>> [...]
 I agree with Aleksandra here. And we *did* establish that our policy
 going forward is that we will forbid any default stream from providing
 non-API content. (Filtered out packages are orthogonal to this.)
>>> 
>>> What does that even mean?
>>> 
>> 
>> Modular builds have metadata that can indicate to consumers which
>> subpackages in this module should be considered "API". If a module
>> produces a package artifact and does not list it thusly, it is meant
>> to be treated as an internal implementation detail of the module (and
>> that the maintainer is not committing to maintaining that particular
>> package for any purpose other than supporting the API content of this
>> module).
>> 
>> We also have "filters" which are intended for allowing module
>> packagers to build and use build-time-only packages. They are built
>> and added to the module buildroot as part of the build process, but
>> they are filtered out so they don't end up in the final composed
>> repository. (This is useful if, for example, your package used a small
>> subset of some other package only at build-time and you don't want to
>> have to maintain that package for everyone in the distro just to build
>> yours).
> 
> OK. Let's say one of those is a static library that doesn't get exposed
> in the final composed repository. Suppose there's a security bug in that
> exact version but that bug doesn't occur in the traditionally-maintained
> package in Fedora (perhaps because the vulnerable version was skipped).
> How do you detect that and know which packages (modules?) need to be
> rebuilt?
> 
> Regards,
> Dominik
> -- 
> Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
> There should be a science of discontent. People need hard times and
> oppression to develop psychic muscles.
>-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 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@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Modularity: The Official Complaint Thread

[Lukas Ruzicka]

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.
>

Well, noone forces you *right now. *That is an important thing to notice.
Someone will force you to use it later.
And, by the way, some people were forced to use it, because they installed
an application whose dependencies were
modularized, so they were force onto modularity without wishing for it.

I, personally, do not have anything against modularity except that *it is
forced upon us. *
My preference is that anybody could choose whether they want to go modular
or stay ursine -
do I really want that much, when I want that Fedora is for everybody?


FEDORA QE, RHCE

Red Hat



Purkyňova 115

612 45 Brno - Královo Pole

lruzi...@redhat.com
TRIED AND PERSONALLY TESTED, ERGO TRUSTED. 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Modularity: The Official Complaint Thread

[Miro Hrončok]

On 12. 11. 19 18:25, Aleksandra Fedorova wrote:

On Tue, Nov 12, 2019 at 5:10 PM Miro Hrončok  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.


Ursa Prime effort puts module sin the buildroot. I'm still waiting to hear about 
how it deals with conflicts with non-modular packages, how it works with mock 
and what it actually does.


Not getting those answers was one of the many reasons I voted against the change 
proposal. Yet every time I point out my reasons, people seem to only see the one 
that says I think we should not have default streams at all. And I kinda get 
that, but the other reasons are equally important.


Before I get the answers, I cannot agree or disagree with you, because I don't 
know what it achieves or not.


However, and I speculate here, IMHO it only gives me the ability to buildrequire 
a modular (meeting certain criteria) package from a non-modular package. It 
doesn't give me a "stay away" card. I still need to deal with modules if my 
package depends on them or if they depend on my package.


As an example, if I choose to depend on module and the modular maintainer 
chooses not to care about the module,  it gets broken or insecure and I have no 
way to fix it other than learning how to do modules.


As an example, I've asked months ago what should I do with modules when we do 
mass Python 3.8 rebuilds. The answer was... it's complicated. (I can search the 
devel list if you want details.)


As an example, if I want to see what requires python2 on rawhide, I don't see 
any modules there (this was couple months ago, the situation may have changed 
now but will repeat when f32 branches).


So, no, I don't believe Ursa Prime achieves the goal. But I might just be not 
informed well, because the Ursa Prime change proposal is not informational 
enough in this regard. In that case, sorry for spreading panic.



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".


And I think it needs to change to: no default modular streams.
Yes, once all the concerns that I and our community members I choose to 
represent have are settled, we can revisit this. But that doesn't mean we should 
explicitly treat it as a temporary policy.



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.


The _technical_ difference is that it's built differently, from a different 
place, in a different way, with different rules. And if we "fix" that, we no 
longer have default modular streams.


To clarify: Another _technical_ difference are broken upgrades, but that can be 
fixed, so I treat that behavior as a bug and will not use it as an argument. 
However, if it is proven that we are not able to fix it, it may become an 
argument as well.



It
is the same rpm spec from the same dist-git sources, which is built by
the same rpmbuild command.


It is some kind of spec file, build from some arbitrary dist-git branch built by 
the same rpmbuild command in an alien environment.



Thus I think it is a process/policy
difference, which we should resolve.


It is. And you know what I think the policy should be. No default modular 
streams.


And I will support a hard block on creating new default streams, until
it is resolved.


We don't agree on what "is resolved" means here.


(With the exception of eclipse probably, which is in a broken state
already, and for which we need to find a solution.)


As a hypothetical example, if we grant eclipse an exception based on the fact 
that it is broken and eclipse gets a modular default stream and another software 
is broken by the same way eclipse was broken because of that, do we give it an 
exception as well? And another? And another?


As a second (even more) hypothetical example, if a maintainer decides they 
really really want their default modular stream, could they just choose to not 
solve all the FTBFS bugzillas and orphan their packages and ask for default 
modular stream based on the fact th

Re: Modularity: The Official Complaint Thread

[Zbigniew Jędrzejewski-Szmek]

> On Tue, Nov 12, 2019 at 10:26 AM Igor Gnatenko
>  wrote:
> > You say we need to improve tooling and iterate fast, fine. But why then
> > https://pagure.io/releng/issue/7662 is still not implemented?

On Tue, Nov 12, 2019 at 03:15:06PM -0500, Stephen Gallagher wrote:
> To be clear, the team that rejected that was the Bodhi team, not the
> Modularity team. We do need to re-examine that; it just kind of fell
> off the radar due to higher-priority issues.

Actually, I think it is OK that this is not implemented, at least when
we're discussing producing packages *in and for Fedora*. While it is might seem
attractive to have "build-once-install-everywhere" packages, I think it
an important part of our process that we build packages for each release
separately, even if they have the same sources and they even might
happen to be binary identical. Rust packages are special in this regard
because of the very tight ecosystem, for most other packages we do want
to rebuild them for each release.

If we turn to the bigger picture and look at externally produced packages,
build-once-run-everywhere is more useful. But still, I think copr-like
send-once-build-everywhere mode is better. If it can be combined with
automatic rebuilds when new releases of Fedora come into being (not
sure if copr implements that today), and a bit of tooling around that,
that would give the best of both worlds: freshly built packages with the
latest toolchain, with no extra work from the packagers (as long as the
packages do build everywhere).

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Modularity: The Official Complaint Thread

[John M. Harris Jr]

On Tuesday, November 12, 2019 3:19:59 PM MST Aleksandar Kurtakov wrote:
> So people would prefer no packages at all over packages in modules? I ask
> this as the traditional rpm way of doing is simply not working and that's
> the reason why many of us (old time Java packagers) just gave up, it's
> purely impossible to satisfy the needs of multiple "major" packages with
> same set of dependencies. This is not Java problem only for sure - look at
> Rust, Go, etc. I would being proved wrong but modularity at least gives an
> option for RPMs to continue to be viable option. With all it's weirdness so
> far no one gave better solution working to that extend at least.

I'm sorry, but I don't know the exact issue you're describing here. I'd be 
glad to give a go at solving this particular issue, using traditional RPMs 
alone.

-- 
John M. Harris, Jr.
Splentity

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Modularity: The Official Complaint Thread

[Aleksandar Kurtakov]

On Wed, Nov 13, 2019 at 12:02 AM John M. Harris Jr 
wrote:

> On Tuesday, November 12, 2019 9:02:07 AM MST Aleksandra Fedorova wrote:
> > Again, no one forces you or any other packager to use modularity
> > tooling right now.
>
> This is not actually the case. We have several major packages which are
> ONLY
> available as modules, for example.
>

So people would prefer no packages at all over packages in modules? I ask
this as the traditional rpm way of doing is simply not working and that's
the reason why many of us (old time Java packagers) just gave up, it's
purely impossible to satisfy the needs of multiple "major" packages with
same set of dependencies. This is not Java problem only for sure - look at
Rust, Go, etc. I would being proved wrong but modularity at least gives an
option for RPMs to continue to be viable option. With all it's weirdness so
far no one gave better solution working to that extend at least.


>
> --
> John M. Harris, Jr.
> Splentity
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 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@lists.fedoraproject.org
>


-- 
Alexander Kurtakov
Red Hat Eclipse Team
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Modularity: The Official Complaint Thread

[James Cassell]

On Tue, Nov 12, 2019, at 3:35 PM, Stephen Gallagher wrote:
> On Tue, Nov 12, 2019 at 12:40 PM Stephen John Smoogen  
> wrote:
> >
> > On Tue, 12 Nov 2019 at 12:26, Aleksandra Fedorova  
> > wrote:
> > > 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?
> 
> The technology allows you to do this. The policy can restrict this. Of
> course, this particular example can be true of a non-modular RPM too;
> you don't *have* to build the X-devel subpackage.
> 
> > 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?
> >
> 
> That would be a technical difference. Your statement, however, is not
> entirely true. You can trivially override it by using RPM instead of
> DNF to update it. Or you can run `createrepo_c` and then add
> `module_hotfix = 1` to the repo file you add to DNF.
> 

I've been following the discussion, and this compels me to jump in.  If you're 
installing things using RPM rather than DNF, you're bypassing the DNF database, 
and that's completely broken in my opinion.  I've been teaching folks that you 
should only ever use YUM/DNF to perform package transactions, except for very 
special cases such as `rpm --setugids` or other very special RPM commands.  I 
also can't (with clear conscience) start teaching folks to run createrepo_c 
just to install an updated RPM.

(Side note: you still can't properly query the DNF database like you can with 
the YUM database; this is still broken from the YUM->DNF transition.)


V/r,
James Cassell
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Modularity: The Official Complaint Thread

[John M. Harris Jr]

On Tuesday, November 12, 2019 9:02:07 AM MST Aleksandra Fedorova wrote:
> Again, no one forces you or any other packager to use modularity
> tooling right now.

This is not actually the case. We have several major packages which are ONLY 
available as modules, for example.

-- 
John M. Harris, Jr.
Splentity

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Modularity: The Official Complaint Thread

[John M. Harris Jr]

On Tuesday, November 12, 2019 7:49:06 AM MST Vít Ondruch wrote:
> > 1) I don't think Modularity is about being LTS and "enterprisy".
> > Lifecycle differences are not the only feature Modularity provides.
> > 
> > I see Modularity as a tool which bridges the gap between container
> > world and a packaged distribution.
> > 
> > Without modularity we have a base system with its limitations and the
> > explosion of containerized solutions which currently go through their
> > teen-age phase, denying the good old known practices and reinventing
> > wheels in terms of packaging, sharing, deduplication of effort and
> > security audit.

I must disagree. As I see it, Red Hat sees this as a potential solution to 
some perceived issue that their customers have, whether that issue actually 
exists or not.

I honestly have no issue with Modules having a place in Fedora as well, and 
maybe that's actually the best place for them: As an optional repository that 
must be enabled before it can be used, and nothing more.

Perhaps we could:
1) Disallow default modules, require that all defaults must be traditional 
packages.

2) Have modules disabled by default, with the option to enable them if you 
wish, perhaps even transparently by installing package:moduleversion?

-- 
John M. Harris, Jr.
Splentity

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Modularity: The Official Complaint Thread

[Stephen Gallagher]

On Tue, Nov 12, 2019 at 4:17 PM Dominik 'Rathann' Mierzejewski <
domi...@greysector.net> wrote:

> On Tuesday, 12 November 2019 at 22:07, Stephen Gallagher wrote:
> > On Tue, Nov 12, 2019 at 4:03 PM Dominik 'Rathann' Mierzejewski
> >  wrote:
> > >
> > > On Tuesday, 12 November 2019 at 21:15, Stephen Gallagher wrote:
> > > [...]
> > > > I agree with Aleksandra here. And we *did* establish that our policy
> > > > going forward is that we will forbid any default stream from
> providing
> > > > non-API content. (Filtered out packages are orthogonal to this.)
> > >
> > > What does that even mean?
> > >
> >
> > Modular builds have metadata that can indicate to consumers which
> > subpackages in this module should be considered "API". If a module
> > produces a package artifact and does not list it thusly, it is meant
> > to be treated as an internal implementation detail of the module (and
> > that the maintainer is not committing to maintaining that particular
> > package for any purpose other than supporting the API content of this
> > module).
> >
> > We also have "filters" which are intended for allowing module
> > packagers to build and use build-time-only packages. They are built
> > and added to the module buildroot as part of the build process, but
> > they are filtered out so they don't end up in the final composed
> > repository. (This is useful if, for example, your package used a small
> > subset of some other package only at build-time and you don't want to
> > have to maintain that package for everyone in the distro just to build
> > yours).
>
> OK. Let's say one of those is a static library that doesn't get exposed
> in the final composed repository. Suppose there's a security bug in that
> exact version but that bug doesn't occur in the traditionally-maintained
> package in Fedora (perhaps because the vulnerable version was skipped).
> How do you detect that and know which packages (modules?) need to be
> rebuilt?
>

A few points:

* Static libraries are forbidden by Fedora policy already.

* If you are bundling into one of the produced RPMs, the same “Provides:
bundled(foo)” rule applies as it would for a non-modular RPM.

* The build artifacts are still present in Koji, they just don’t end up in
the final composed repos. So we can always query Koji for the version
corresponding to a module build.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Modularity: The Official Complaint Thread

[Dominik 'Rathann' Mierzejewski]

On Tuesday, 12 November 2019 at 22:07, Stephen Gallagher wrote:
> On Tue, Nov 12, 2019 at 4:03 PM Dominik 'Rathann' Mierzejewski
>  wrote:
> >
> > On Tuesday, 12 November 2019 at 21:15, Stephen Gallagher wrote:
> > [...]
> > > I agree with Aleksandra here. And we *did* establish that our policy
> > > going forward is that we will forbid any default stream from providing
> > > non-API content. (Filtered out packages are orthogonal to this.)
> >
> > What does that even mean?
> >
> 
> Modular builds have metadata that can indicate to consumers which
> subpackages in this module should be considered "API". If a module
> produces a package artifact and does not list it thusly, it is meant
> to be treated as an internal implementation detail of the module (and
> that the maintainer is not committing to maintaining that particular
> package for any purpose other than supporting the API content of this
> module).
> 
> We also have "filters" which are intended for allowing module
> packagers to build and use build-time-only packages. They are built
> and added to the module buildroot as part of the build process, but
> they are filtered out so they don't end up in the final composed
> repository. (This is useful if, for example, your package used a small
> subset of some other package only at build-time and you don't want to
> have to maintain that package for everyone in the distro just to build
> yours).

OK. Let's say one of those is a static library that doesn't get exposed
in the final composed repository. Suppose there's a security bug in that
exact version but that bug doesn't occur in the traditionally-maintained
package in Fedora (perhaps because the vulnerable version was skipped).
How do you detect that and know which packages (modules?) need to be
rebuilt?

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Modularity: The Official Complaint Thread

[Stephen John Smoogen]

On Tue, 12 Nov 2019 at 15:36, Stephen Gallagher  wrote:
>
> On Tue, Nov 12, 2019 at 12:40 PM Stephen John Smoogen  
> wrote:
> >
> > On Tue, 12 Nov 2019 at 12:26, Aleksandra Fedorova  
> > wrote:
> > > 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?
>
> The technology allows you to do this. The policy can restrict this. Of
> course, this particular example can be true of a non-modular RPM too;
> you don't *have* to build the X-devel subpackage.
>

I am asking these questions this way because of 20 years of RPM fights
of people arguing over things because a spec file is a combination of
a policy document and a technical document but people like to treat it
as one or the other in the conversations. Getting it clear when you
are speaking about the technical implementation of policy or the
political implementation of technology up front gets that out of the
way. Not being clear is where people start building their own mind
castles to send armies of strawmen against.

I have 0 interest for or against modularity. It is a technology which
tries to solve a problem and has good sides and negatives. What I have
an interest is getting people to be clear where they have
disagreements versus spending their time talking past each other and
getting more and more pissed because of it.

-- 
Stephen J Smoogen.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Modularity: The Official Complaint Thread

[Stephen Gallagher]

On Tue, Nov 12, 2019 at 4:03 PM Dominik 'Rathann' Mierzejewski
 wrote:
>
> On Tuesday, 12 November 2019 at 21:15, Stephen Gallagher wrote:
> [...]
> > I agree with Aleksandra here. And we *did* establish that our policy
> > going forward is that we will forbid any default stream from providing
> > non-API content. (Filtered out packages are orthogonal to this.)
>
> What does that even mean?
>

Modular builds have metadata that can indicate to consumers which
subpackages in this module should be considered "API". If a module
produces a package artifact and does not list it thusly, it is meant
to be treated as an internal implementation detail of the module (and
that the maintainer is not committing to maintaining that particular
package for any purpose other than supporting the API content of this
module).

We also have "filters" which are intended for allowing module
packagers to build and use build-time-only packages. They are built
and added to the module buildroot as part of the build process, but
they are filtered out so they don't end up in the final composed
repository. (This is useful if, for example, your package used a small
subset of some other package only at build-time and you don't want to
have to maintain that package for everyone in the distro just to build
yours).
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Modularity: The Official Complaint Thread

[Dominik 'Rathann' Mierzejewski]

On Tuesday, 12 November 2019 at 21:15, Stephen Gallagher wrote:
[...]
> I agree with Aleksandra here. And we *did* establish that our policy
> going forward is that we will forbid any default stream from providing
> non-API content. (Filtered out packages are orthogonal to this.)

What does that even mean?

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Modularity: The Official Complaint Thread

[Stephen Gallagher]

On Tue, Nov 12, 2019 at 3:29 PM Neal Gompa  wrote:
>
> On Tue, Nov 12, 2019 at 3:20 PM Stephen Gallagher  wrote:
> >
> > On Tue, Nov 12, 2019 at 11:10 AM Neal Gompa  wrote:
> > >
> > > On Tue, Nov 12, 2019 at 11:03 AM Aleksandra Fedorova  
> > > wrote:
> > > >
> > > > Again, no one forces you or any other packager to use modularity
> > > > tooling right now.
> > > >
> > >
> > > This is not true. Once content is modularized, things that were able
> > > to depend on it in the normal form can no longer do so unless they too
> > > modularize.
> >
> > This is true *currently*, but as I've been saying for months now: this
> > is only true because we've not been allowed to land Ursa Prime (and,
> > before that, Ursa Major) to allow us to have modules in the buildroot.
> >
> > That *finally* started to change with FESCo's decision yesterday. They
> > gave us permission to put two reasonably-contained modules into the
> > available buildroot to prove it out.
> >
>
> I am watching that experiment carefully. I'm doing something similar
> for my own work as an experiment into pulling in modular content into
> my build environments...
>
> > > This is an important consequence that I think people
> > > championing for modularity keep forgetting. Everything from how the
> > > build system works to how DNF implements modularity makes it so that
> > > modular and non-modular content do not have an even footing. If they
> > > did, I think we'd have less problems.
> >
> > I think "even footing" is a poor choice of words, because it implies
> > that one is "higher" than the other. It's true that things are built
> > and managed *differently*. We've been trying to close that gap as much
> > as possible.
>
> Technically, one is "higher" than the other. Modular content
> automatically disables the non-modular counterparts. You don't have
> the ability to select to install and follow content fron the
> non-modular source instead of the modular one, especially with
> fedora-modular enabled by default.
>
> If there is a path for me to freely switch back and forth between
> equivalent modular and non-modular variants, I'd definitely be
> happier, personally.

`dnf module disable foo` *should* be able to do this. If that doesn't
work in all cases, there are bugs. I just tested myself that I could
do `dnf module disable meson && dnf downgrade meson` and I got the
non-modular package on my F31 system. (If the non-modular one had been
a higher ENVR, I would have been able to do `dnf update meson`.)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Modularity: The Official Complaint Thread

[Stephen Gallagher]

On Tue, Nov 12, 2019 at 1:32 PM Aleksandra Fedorova  wrote:
>
> On Tue, Nov 12, 2019 at 7:03 PM Aleksandar Kurtakov  
> wrote:
> >
> >
> >
> > On Tue, Nov 12, 2019 at 7:55 PM Aleksandra Fedorova  
> > wrote:
> >>
> >> Hi, Aleksandar,
> >>
> >> On Tue, Nov 12, 2019 at 6:40 PM Aleksandar Kurtakov  
> >> wrote:
> >> >
> >> >
> >> >
> >> > On Tue, Nov 12, 2019 at 7:31 PM Aleksandra Fedorova  
> >> > wrote:
> >> >>
> >> >> On Tue, Nov 12, 2019 at 5:10 PM Miro Hrončok  
> >> >> 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.
> >> >>
> >> >> And I will support a hard block on creating new default streams, until
> >> >> it is resolved.
> >> >> (With the exception of eclipse probably, which is in a broken state
> >> >> already, and for which we need to find a solution.)
> >> >
> >> >
> >> > The way Eclipse is treated makes me really sad and kind of regret the 
> >> > time spent on Fedora over the years! Being forced to be a module but 
> >> > blocked to be default stream by FESCo arguing over whether it wants 
> >> > modularity (sorry, this is how it looks) is the best way for Fedora to 
> >> > show to project and people they are not wanted in the community!
> >> > The net effect for me personally is to totally move my eyes away as I 
> >> > get really pissed off.
> >>
> >> I am sorry that it looks this way for you, but you are misinterpreting it.
> >>
> >> FESCo was willing to enable the default stream for eclipse the moment
> >> it was requested given by the fact that it actually solves the
> >> problem. But it wasn't the case.
> >
> >
> > Would you please elaborate how this was not the case? There was the 
> > glassfish package provided by two streams issue which has been fixed in 
> > maven module but eclipse still is not approved as default package. What am 
> > I missing?
>
> You can check the logs from the FESCo meeting.
>
> To make a proper decision FESCo needs to understand which problem we
> are solving, what is the proposed solution what is the impact of this
> solution and what are the alternatives.
> The IRC meeting format is not the best way to discuss complex things
> that is why it usually needs a preparation in advance in a form of
> ticket to FESCo via Pagure which provides a common context for the
> conversation.
>
> The previous decision on eclipse was
>
>   AGREED: Drop the unmaintained eclipse from the non-modular
> repositories and ship module streams of eclipse. Whenever the
> conflicts are resolved later, we can make a default stream available
> (+6, 0, 0)
>   zbyszek to add eclipse to fedora-obsolet-packages
>   mbooth to drive the retirement of non-modular eclipse
>   The bug about eclipse not being installable is approved as FESCo FE (+6, 0, 
> 0)
>
> To move forward we need at least to get a status update on it.
>
> 1) status of retirement of non-modular eclipse packages
> 2) status of conflict between maven and eclipse modules
> 3) status of the module - is it verified that enabling eclipse module
> explicitly now solves the problem?
> - will "dnf install eclipse" work on new Fedora with all updates?
> - will "dnf install eclipse" work on Fedora with updates and maven
> module installed previously?
> - .. maybe some other cases?
>
> We didn't get all of this information during the meeting, there wa

Re: Modularity: The Official Complaint Thread

[Stephen Gallagher]

On Tue, Nov 12, 2019 at 12:40 PM Aleksandar Kurtakov
 wrote:
> The way Eclipse is treated makes me really sad and kind of regret the time 
> spent on Fedora over the years! Being forced to be a module but blocked to be 
> default stream by FESCo arguing over whether it wants modularity (sorry, this 
> is how it looks) is the best way for Fedora to show to project and people 
> they are not wanted in the community!
> The net effect for me personally is to totally move my eyes away as I get 
> really pissed off

Eclipse has definitely had a rough ride here. There's no question
about that. And while it may be small comfort to the Eclipse
maintainers, it has been invaluable in showing us which policies we
need to put in place to avoid making the same mistakes in the future.
Being "forced to be a module" was somewhat outside our control, as the
Java team went running off and delivered their version of a finished
product and you got caught in the crossfire. We are doing everything
we can to sort this out.

I do apologize for how hard your project has gotten hit. It was unfair
to the Eclipse team.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Modularity: The Official Complaint Thread

[Stephen Gallagher]

On Tue, Nov 12, 2019 at 12:40 PM Stephen John Smoogen  wrote:
>
> On Tue, 12 Nov 2019 at 12:26, Aleksandra Fedorova  wrote:
> > 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?

The technology allows you to do this. The policy can restrict this. Of
course, this particular example can be true of a non-modular RPM too;
you don't *have* to build the X-devel subpackage.

> 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?
>

That would be a technical difference. Your statement, however, is not
entirely true. You can trivially override it by using RPM instead of
DNF to update it. Or you can run `createrepo_c` and then add
`module_hotfix = 1` to the repo file you add to DNF.


> 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.]

Let's leave it at "technical differences are things where the inputs
and outputs of packaging differ" and "policy is what we as Fedora have
decided to allow, disallow or mandate".
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Modularity: The Official Complaint Thread

[Stephen Gallagher]

On Tue, Nov 12, 2019 at 12:31 PM Aleksandra Fedorova  wrote:
>
> On Tue, Nov 12, 2019 at 5:10 PM Miro Hrončok  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.
>

That is absolutely its purpose. If we fall short of that, it's a bug
and we will fix it as soon as possible.

> 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".
>

I'm fine with that.

> 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.
>

I'll acknowledge that there may be subtle differences (such as the
different "release" tag), but none (offhand) that should have a
meaningful impact as long as other policy is in place.

> And I will support a hard block on creating new default streams, until
> it is resolved.
> (With the exception of eclipse probably, which is in a broken state
> already, and for which we need to find a solution.)

This is already in place.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Modularity: The Official Complaint Thread

[Neal Gompa]

On Tue, Nov 12, 2019 at 3:20 PM Stephen Gallagher  wrote:
>
> On Tue, Nov 12, 2019 at 11:10 AM Neal Gompa  wrote:
> >
> > On Tue, Nov 12, 2019 at 11:03 AM Aleksandra Fedorova  
> > wrote:
> > >
> > > Again, no one forces you or any other packager to use modularity
> > > tooling right now.
> > >
> >
> > This is not true. Once content is modularized, things that were able
> > to depend on it in the normal form can no longer do so unless they too
> > modularize.
>
> This is true *currently*, but as I've been saying for months now: this
> is only true because we've not been allowed to land Ursa Prime (and,
> before that, Ursa Major) to allow us to have modules in the buildroot.
>
> That *finally* started to change with FESCo's decision yesterday. They
> gave us permission to put two reasonably-contained modules into the
> available buildroot to prove it out.
>

I am watching that experiment carefully. I'm doing something similar
for my own work as an experiment into pulling in modular content into
my build environments...

> > This is an important consequence that I think people
> > championing for modularity keep forgetting. Everything from how the
> > build system works to how DNF implements modularity makes it so that
> > modular and non-modular content do not have an even footing. If they
> > did, I think we'd have less problems.
>
> I think "even footing" is a poor choice of words, because it implies
> that one is "higher" than the other. It's true that things are built
> and managed *differently*. We've been trying to close that gap as much
> as possible.

Technically, one is "higher" than the other. Modular content
automatically disables the non-modular counterparts. You don't have
the ability to select to install and follow content fron the
non-modular source instead of the modular one, especially with
fedora-modular enabled by default.

If there is a path for me to freely switch back and forth between
equivalent modular and non-modular variants, I'd definitely be
happier, personally.




--
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Modularity: The Official Complaint Thread

[Stephen Gallagher]

On Tue, Nov 12, 2019 at 11:10 AM Neal Gompa  wrote:
>
> On Tue, Nov 12, 2019 at 11:03 AM Aleksandra Fedorova  
> wrote:
> >
> > Again, no one forces you or any other packager to use modularity
> > tooling right now.
> >
>
> This is not true. Once content is modularized, things that were able
> to depend on it in the normal form can no longer do so unless they too
> modularize.

This is true *currently*, but as I've been saying for months now: this
is only true because we've not been allowed to land Ursa Prime (and,
before that, Ursa Major) to allow us to have modules in the buildroot.

That *finally* started to change with FESCo's decision yesterday. They
gave us permission to put two reasonably-contained modules into the
available buildroot to prove it out.

> This is an important consequence that I think people
> championing for modularity keep forgetting. Everything from how the
> build system works to how DNF implements modularity makes it so that
> modular and non-modular content do not have an even footing. If they
> did, I think we'd have less problems.

I think "even footing" is a poor choice of words, because it implies
that one is "higher" than the other. It's true that things are built
and managed *differently*. We've been trying to close that gap as much
as possible.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Modularity: The Official Complaint Thread

[Stephen Gallagher]

On Tue, Nov 12, 2019 at 10:26 AM Igor Gnatenko
 wrote:
>
> The question arises, what people are supposed to do when they modularized 
> content because modularity is (was?) good tool to have "buildroot-only 
> packages," "separate lifecycle from Fedora" and "no difference from normal 
> packages."
>
> Second was rightfully prohibited by FESCo, first is making people not happy. 
> Third one is not true.
>
> I basically had to go back, remove 28 out of 52 Fedora modules because 
> tooling is not improving and policies are being more restrictive.
>
> You say we need to improve tooling and iterate fast, fine. But why then 
> https://pagure.io/releng/issue/7662 is still not implemented? I understand 
> that it is opensource And everyone can contribute, but the fact is that 
> people who work on Modularity tooling is entirely paid by RH and those people 
> are "responsible" to bring it to Fedora and make it work. However, as written 
> in the ticket "it is not a priority for that team".
>

To be clear, the team that rejected that was the Bodhi team, not the
Modularity team. We do need to re-examine that; it just kind of fell
off the radar due to higher-priority issues.

> So is it really about making tooling (writing new, or making existing better) 
> or about making those people to implement Fedora needs?
>
>> For that we need to focus on the issue, which is, from my point of
>> view: default streams and their differences from the ursine packages.
>>
>> One is caused by the lack of Ursa Prime, another is the upgrade
>> functionality, and I guess the third one is the non-api and filtered
>> packages in the module.
>>
>> P.S. I am not a member of Modularity team.

I agree with Aleksandra here. And we *did* establish that our policy
going forward is that we will forbid any default stream from providing
non-API content. (Filtered out packages are orthogonal to this.)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Modularity: The Official Complaint Thread

[Aleksandra Fedorova]

On Tue, Nov 12, 2019 at 7:03 PM Aleksandar Kurtakov  wrote:
>
>
>
> On Tue, Nov 12, 2019 at 7:55 PM Aleksandra Fedorova  
> wrote:
>>
>> Hi, Aleksandar,
>>
>> On Tue, Nov 12, 2019 at 6:40 PM Aleksandar Kurtakov  
>> wrote:
>> >
>> >
>> >
>> > On Tue, Nov 12, 2019 at 7:31 PM Aleksandra Fedorova  
>> > wrote:
>> >>
>> >> On Tue, Nov 12, 2019 at 5:10 PM Miro Hrončok  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.
>> >>
>> >> And I will support a hard block on creating new default streams, until
>> >> it is resolved.
>> >> (With the exception of eclipse probably, which is in a broken state
>> >> already, and for which we need to find a solution.)
>> >
>> >
>> > The way Eclipse is treated makes me really sad and kind of regret the time 
>> > spent on Fedora over the years! Being forced to be a module but blocked to 
>> > be default stream by FESCo arguing over whether it wants modularity 
>> > (sorry, this is how it looks) is the best way for Fedora to show to 
>> > project and people they are not wanted in the community!
>> > The net effect for me personally is to totally move my eyes away as I get 
>> > really pissed off.
>>
>> I am sorry that it looks this way for you, but you are misinterpreting it.
>>
>> FESCo was willing to enable the default stream for eclipse the moment
>> it was requested given by the fact that it actually solves the
>> problem. But it wasn't the case.
>
>
> Would you please elaborate how this was not the case? There was the glassfish 
> package provided by two streams issue which has been fixed in maven module 
> but eclipse still is not approved as default package. What am I missing?

You can check the logs from the FESCo meeting.

To make a proper decision FESCo needs to understand which problem we
are solving, what is the proposed solution what is the impact of this
solution and what are the alternatives.
The IRC meeting format is not the best way to discuss complex things
that is why it usually needs a preparation in advance in a form of
ticket to FESCo via Pagure which provides a common context for the
conversation.

The previous decision on eclipse was

  AGREED: Drop the unmaintained eclipse from the non-modular
repositories and ship module streams of eclipse. Whenever the
conflicts are resolved later, we can make a default stream available
(+6, 0, 0)
  zbyszek to add eclipse to fedora-obsolet-packages
  mbooth to drive the retirement of non-modular eclipse
  The bug about eclipse not being installable is approved as FESCo FE (+6, 0, 0)

To move forward we need at least to get a status update on it.

1) status of retirement of non-modular eclipse packages
2) status of conflict between maven and eclipse modules
3) status of the module - is it verified that enabling eclipse module
explicitly now solves the problem?
- will "dnf install eclipse" work on new Fedora with all updates?
- will "dnf install eclipse" work on Fedora with updates and maven
module installed previously?
- .. maybe some other cases?

We didn't get all of this information during the meeting, there was no
feedback in the relevant BZ with the verification either, and the
attempt to verify the solution during the meeting provided
contradicting results. Thus we asked to provide the data
asynchronously via FESCo ticket.

--
Aleksandra Fedorova
bookwar
___
d

Re: Modularity: The Official Complaint Thread

[Aleksandra Fedorova]

Hi Stephen,

On Tue, Nov 12, 2019 at 6:40 PM Stephen John Smoogen  wrote:
>
> On Tue, 12 Nov 2019 at 12:26, Aleksandra Fedorova  wrote:
> >
> > On Tue, Nov 12, 2019 at 5:10 PM Miro Hrončok  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.]

You are right, I am using the terms very loosely here.

I don't really plan to have a detailed discussion on default modules
in this thread, so I am hand-waiving to set the context for that
discussion.

What I'd like to see is a separate thread or probably better a
separate document where we list all differences between ursine package
and a package coming from default stream and identify which
differences we want to have and which we need to restrict by the
policy.

And once we have this restricted policy we may recheck again, if we
actually have package maintainers, who would like to use default
streams under those restrictions, and what are their use cases.

-- 
Aleksandra Fedorova
bookwar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Modularity: The Official Complaint Thread

[Aleksandar Kurtakov]

On Tue, Nov 12, 2019 at 7:55 PM Aleksandra Fedorova 
wrote:

> Hi, Aleksandar,
>
> On Tue, Nov 12, 2019 at 6:40 PM Aleksandar Kurtakov 
> wrote:
> >
> >
> >
> > On Tue, Nov 12, 2019 at 7:31 PM Aleksandra Fedorova 
> wrote:
> >>
> >> On Tue, Nov 12, 2019 at 5:10 PM Miro Hrončok 
> 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.
> >>
> >> And I will support a hard block on creating new default streams, until
> >> it is resolved.
> >> (With the exception of eclipse probably, which is in a broken state
> >> already, and for which we need to find a solution.)
> >
> >
> > The way Eclipse is treated makes me really sad and kind of regret the
> time spent on Fedora over the years! Being forced to be a module but
> blocked to be default stream by FESCo arguing over whether it wants
> modularity (sorry, this is how it looks) is the best way for Fedora to show
> to project and people they are not wanted in the community!
> > The net effect for me personally is to totally move my eyes away as I
> get really pissed off.
>
> I am sorry that it looks this way for you, but you are misinterpreting it.
>
> FESCo was willing to enable the default stream for eclipse the moment
> it was requested given by the fact that it actually solves the
> problem. But it wasn't the case.
>

Would you please elaborate how this was not the case? There was the
glassfish package provided by two streams issue which has been fixed in
maven module but eclipse still is not approved as default package. What am
I missing?


> So the delay of the decision on Eclipse has nothing to do with the
> generic Modularity trouble, it is based solely on the fact that we
> need a working solution, and there was a certain miscommunication and
> lack of coordination in providing it.
>
> And this is exactly what I said in my previous mail. We treat eclipse
> as exceptional case and it is not affected by this conversation.
>
> --
> Aleksandra Fedorova
> bookwar
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 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@lists.fedoraproject.org
>


-- 
Alexander Kurtakov
Red Hat Eclipse Team
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Modularity: The Official Complaint Thread

[Aleksandra Fedorova]

Hi, Aleksandar,

On Tue, Nov 12, 2019 at 6:40 PM Aleksandar Kurtakov  wrote:
>
>
>
> On Tue, Nov 12, 2019 at 7:31 PM Aleksandra Fedorova  
> wrote:
>>
>> On Tue, Nov 12, 2019 at 5:10 PM Miro Hrončok  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.
>>
>> And I will support a hard block on creating new default streams, until
>> it is resolved.
>> (With the exception of eclipse probably, which is in a broken state
>> already, and for which we need to find a solution.)
>
>
> The way Eclipse is treated makes me really sad and kind of regret the time 
> spent on Fedora over the years! Being forced to be a module but blocked to be 
> default stream by FESCo arguing over whether it wants modularity (sorry, this 
> is how it looks) is the best way for Fedora to show to project and people 
> they are not wanted in the community!
> The net effect for me personally is to totally move my eyes away as I get 
> really pissed off.

I am sorry that it looks this way for you, but you are misinterpreting it.

FESCo was willing to enable the default stream for eclipse the moment
it was requested given by the fact that it actually solves the
problem. But it wasn't the case.
So the delay of the decision on Eclipse has nothing to do with the
generic Modularity trouble, it is based solely on the fact that we
need a working solution, and there was a certain miscommunication and
lack of coordination in providing it.

And this is exactly what I said in my previous mail. We treat eclipse
as exceptional case and it is not affected by this conversation.

-- 
Aleksandra Fedorova
bookwar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Modularity: The Official Complaint Thread

[Aleksandar Kurtakov]

On Tue, Nov 12, 2019 at 7:31 PM Aleksandra Fedorova 
wrote:

> On Tue, Nov 12, 2019 at 5:10 PM Miro Hrončok  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.
>
> And I will support a hard block on creating new default streams, until
> it is resolved.
> (With the exception of eclipse probably, which is in a broken state
> already, and for which we need to find a solution.)
>

The way Eclipse is treated makes me really sad and kind of regret the time
spent on Fedora over the years! Being forced to be a module but blocked to
be default stream by FESCo arguing over whether it wants modularity (sorry,
this is how it looks) is the best way for Fedora to show to project and
people they are not wanted in the community!
The net effect for me personally is to totally move my eyes away as I get
really pissed off
 .

>
> --
> Aleksandra Fedorova
> bookwar
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 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@lists.fedoraproject.org
>


-- 
Alexander Kurtakov
Red Hat Eclipse Team
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Modularity: The Official Complaint Thread

[Stephen John Smoogen]

On Tue, 12 Nov 2019 at 12:26, Aleksandra Fedorova  wrote:
>
> On Tue, Nov 12, 2019 at 5:10 PM Miro Hrončok  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.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Modularity: The Official Complaint Thread

[Aleksandra Fedorova]

On Tue, Nov 12, 2019 at 5:10 PM Miro Hrončok  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.

And I will support a hard block on creating new default streams, until
it is resolved.
(With the exception of eclipse probably, which is in a broken state
already, and for which we need to find a solution.)

-- 
Aleksandra Fedorova
bookwar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Modularity: The Official Complaint Thread

[Nicolas Mailhot via devel]

Le mardi 12 novembre 2019 à 17:02 +0100, Aleksandra Fedorova a écrit :
> Hi, Igor,
> 
> On Tue, Nov 12, 2019 at 4:20 PM Igor Gnatenko
>  wrote:
> > > 
> > > On Tue, Nov 12, 2019 at 10:50 AM Dominik 'Rathann' Mierzejewski
> > >  wrote:
> > > > 
> > So is it really about making tooling (writing new, or making
> > existing better) or about making those people to implement Fedora
> > needs?
> 
> "those people implementing Fedora needs" is a really bad way to put
> it. The fact that people are paid by Red Hat doesn't exclude them
> (us) from Fedora community. We are working on Fedora needs
> altogether, even when we disagree what those needs exactly are.

The intrinsic difficulty of internal Red Hat projects, is that they
don’t need strong community buy-in to get into the distribution.

While that saves time, and insures dev funding, it also means it is
easier to go full power on things that end up requiring deep changes to
get non Red Hat adoption.

It's not anyone's fault, it's the inherent nature of internal and
external dev paths.

Regards,

-- 
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Modularity: The Official Complaint Thread

[Miro Hrončok]

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.


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Modularity: The Official Complaint Thread

[Neal Gompa]

On Tue, Nov 12, 2019 at 11:03 AM Aleksandra Fedorova  wrote:
>
> Again, no one forces you or any other packager to use modularity
> tooling right now.
>

This is not true. Once content is modularized, things that were able
to depend on it in the normal form can no longer do so unless they too
modularize. This is an important consequence that I think people
championing for modularity keep forgetting. Everything from how the
build system works to how DNF implements modularity makes it so that
modular and non-modular content do not have an even footing. If they
did, I think we'd have less problems.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Modularity: The Official Complaint Thread

[Aleksandra Fedorova]

Hi, Igor,

On Tue, Nov 12, 2019 at 4:20 PM Igor Gnatenko
 wrote:
>
> On Tue, Nov 12, 2019, 14:13 Aleksandra Fedorova  wrote:
>>
>> Hi,
>>
>> On Tue, Nov 12, 2019 at 10:50 AM Dominik 'Rathann' Mierzejewski
>>  wrote:
>> >
>> > Hi.
>> > I've been silent so far, while mostly agreeing with the "let's just drop
>> > Modularity" proposal. This post hit a nerve, so I felt compelled to reply.
>> >
>> > On Monday, 11 November 2019 at 19:24, Stephen Gallagher wrote:
>> > > On Mon, Nov 11, 2019 at 1:15 PM Robbie Harwood  
>> > > wrote:
>> > [...]
>> > > > It's really frustrating to be repeatedly told we're not arguing in good
>> > > > faith and then see things like this (from today's fesco meeting [1]):
>> > > >
>> > > > 15:48:07  Can we please stop pretending like "start over
>> > > > from scratch" is a real option?
>> > > >
>> > > > Starting from scratch should be an option.  Removing modularity 
>> > > > entirely
>> > > > should be an option.  Of course, so should be using modularity as it
>> > > > exists (or modifying it), but if we don't have those first two as
>> > > > options when there are proponents, this isn't a real technical
>> > > > discussion.
>> > >
>> > > That quote is not fully in context, but that's entirely fair because I
>> > > didn't include enough context during the FESCo meeting. I apologize
>> > > for that. (Also, as you can tell from the rest of the log, I was
>> > > getting frustrated by that point).
>> > >
>> > > When I said it's not a real option, I did not include any of my
>> > > reasoning (thus Begging the Question as you rightly point out). My
>> > > reasoning is basically this:
>> > >
>> > > * Everyone on the Modularity Team is being paid by Red Hat to work on
>> > > Modularity.
>> > > * Red Hat Enterprise Linux 8 shipped with Modularity.
>> > > * The Modularity Team is responsible for maintaining that in RHEL 8
>> > > regardless of what happens in Fedora.
>> >
>> > None of the above should matter for the purpose of selecting the best
>> > technical solution to the current issues, even if it means admitting
>> > that Modularity as currently implemented is causing too many issues that
>> > can't be fixed in reasonable time and abandoning it altogether.
>> >
>> > > * A full redesign in Fedora is not realistically possible with the
>> > > people and resources we have available to us while also maintaining
>> > > the current implementation for ten years.
>> >
>> > Then just drop it. SCLs are an example of a Red Hat-only solution.
>> > Modularity tried to do better and failed in Fedora, so let it remain Red
>> > Hat-only, too, while an even better solution is invented. Or, perhaps,
>> > as various folks have been saying, maybe Fedora just doesn't need SCLs,
>> > Modularity or any similar solutions. Let Red Hat cater to its corporate
>> > customers and experiment with Red Hat-specific solutions in CentOS and
>> > let Fedora not be constrained by what makes sense only in a LTS enterprise
>> > distribution.
>> >
>> > > * Therefore we are focused on trying to get the current implementation
>> > > into better shape (and/or finding a safe migration strategy to a new
>> > > solution) rather than start from an entirely green field.
>> >
>> > If you mean "we, the Modularity team" then I can understand, but still
>> > the option to just drop the whole thing from Fedora looks more appealing
>> > than just wasting more time and effort on piling up technical debt.
>> > Sound arguments were made against some of the stated goals of Modularity
>> > like private buildroot packages and the rest can be implemented using
>> > the existing tools. I fail to see what advantages Modularity has brought
>> > us so far, while the disadvantages are pretty clear.
>>
>> I am going to disagree on several points here:
>>
>> 1) I don't think Modularity is about being LTS and "enterprisy".
>> Lifecycle differences are not the only feature Modularity provides.
>>
>> I see Modularity as a tool which bridges the gap between container
>> world and a packaged distribution.
>>
>> Without modularity we have a base system with its limitations and the
>> explosion of containerized solutions which currently go through their
>> teen-age phase, denying the good old known practices and reinventing
>> wheels in terms of packaging, sharing, deduplication of effort and
>> security audit.
>>
>> Modularity allows us to use packaging approaches in a more flexible
>> but still controlled and maintained way. It creates building blocks
>> for containerized environments.
>> I think it is the way to go for Flatpacks, cloud images and other
>> layered solutions to use runtimes built on top of packaged streams,
>> rather than custom configurations.
>>
>> And I think it is in scope of Fedora to drive this process to
>> normalize the currently chaotic container world.
>>
>> 2) I don't think Modularity is a failure in its current state.
>>
>> Yes, we do have a problem of default streams. There are several
>> reasons for that.
>>
>> One thing i