[prev in list] [next in list] [prev in thread] [next in thread]
List: fedora-devel-list
Subject: Re: Modularity and the system-upgrade path
From: Lukas Ruzicka <lruzicka () redhat ! com>
Date: 2019-11-16 8:35:56
Message-ID: CALpnPk7JnVTLmn7Ziy_fMUJ9JQws5byFH89Ayo5=nBuAu1qUWw () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
Either the strategy should be:
>
> "We offer alternate Perl versions for containers etc. they conflict with
> the
> default Perl version and with the non-modular apps. That is known and
> accepted."
>
> Or the strategy should be:
>
> "We build all our Perl applications for all our Perl versions, so users
> who
> choose their Perl stream can still keep their applications from the
> distribution."
>
>
Exactly. While I am thinking that the *first strategy is easily achievable*,
even with what we already have,
the *second strategy is very complicated* to achieve, because we cannot
predict what applications
users want to install and in which versions. They all would have to work in
Fedora, otherwise the distro
does not make sense any more. Let me explain.
If I know that installing an alternative version of Perl could break Perl
bindings to other applications, I can
create a container to use that alternative version of Perl and be happy,
having actually the standard Perl in the
system and another version in the container, or I just install a system
with that, because I only need
to have one purpose operating system, such as LAMP or other servers. That's
fine.
For desktop users, however, this is not good because you place limitations
on them. While I believe it is fairly ok
to build a server solution around containers (or even virtual machines),
this is overly complicated for Desktop.
I do not understand why we would like to make Desktop complicated, when the
majority of Red Hat use Fedora as
their desktop solution. Also, there are spins that basically are
Workstations (or other desktops) that have certain
packages pre-installed and we expect them to work flawlessly.
The questions is: *With modularity ... can we make sure that everything
works with everything as it does nowadays?*
I believe that having non-modular defaults will make sure the distro works
in its entirety, while having alternative versions
in modules will help developers and sysadmins to install what they want and
need, if it is not the default. For me, this is a win win situation.
I understand that it is more work for the packager, but it is more
convenient for the users and we should think about the users
in the first place.
I have been following this discussion since it started and all I am getting
is "We are having issues, but we are working on them.",
but nobody has ever explained why it is bad to use Miro's approach.
--
Lukáš Růžička
FEDORA QE, RHCE
Red Hat
<https://www.redhat.com>
Purkyňova 115
612 45 Brno - Královo Pole
lruzicka@redhat.com
TRIED AND PERSONALLY TESTED, ERGO TRUSTED. <https://redhat.com/trusted>
[Attachment #5 (text/html)]
<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex">
Either the strategy should be:<br>
<br>
"We offer alternate Perl versions for containers etc. they conflict with the \
<br> default Perl version and with the non-modular apps. That is known and \
accepted."<br> <br>
Or the strategy should be:<br>
<br>
"We build all our Perl applications for all our Perl versions, so users who <br>
choose their Perl stream can still keep their applications from the \
distribution."<br> <br></blockquote><div><br></div><div>Exactly. While I am \
thinking that the <b>first strategy is easily achievable</b>, even with what we \
already have,</div><div>the <b>second strategy is very complicated</b> to achieve, \
because we cannot predict what applications</div><div>users want to install and in \
which versions. They all would have to work in Fedora, otherwise the \
distro</div><div>does not make sense any more. Let me \
explain.</div><div><br></div><div>If I know that installing an alternative version of \
Perl could break Perl bindings to other applications, I can</div><div>create a \
container to use that alternative version of Perl and be happy, having actually the \
standard Perl in the</div><div>system and another version in the container, or I just \
install a system with that, because I only need</div><div>to have one purpose \
operating system, such as LAMP or other servers. That's \
fine.</div><div><br></div><div>For desktop users, however, this is not good because \
you place limitations on them. While I believe it is fairly ok</div><div>to build a \
server solution around containers (or even virtual machines), this is overly \
complicated for Desktop.</div><div>I do not understand why we would like to make \
Desktop complicated, when the majority of Red Hat use Fedora as</div><div>their \
desktop solution. Also, there are spins that basically are Workstations (or other \
desktops) that have certain <br></div><div>packages pre-installed and we expect them \
to work flawlessly.<br></div><div><br></div><div>The questions is: <b>With modularity \
... can we make sure that everything works with everything as it does \
nowadays?</b></div><div><b><br></b></div><div>I believe that having non-modular \
defaults will make sure the distro works in its entirety, while having alternative \
versions</div><div>in modules will help developers and sysadmins to install what they \
want and need, if it is not the default. For me, this is a win win \
situation.</div><div>I understand that it is more work for the packager, but it is \
more convenient for the users and we should think about the users <br></div><div>in \
the first place.</div><div><br></div><div>I have been following this discussion since \
it started and all I am getting is "We are having issues, but we are working on \
them.",</div><div>but nobody has ever explained why it is bad to use Miro's \
approach.</div><div><br></div><br clear="all"></div><br>-- <br><div dir="ltr" \
class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div \
dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div \
dir="ltr"><div> <p style="font-weight:bold;margin:0px;padding:0px;font-size:14px;text-transform:uppercase"><span>Lukáš</span> \
<span>Růžička</span></p> <p style="font-weight:normal;font-size:10px;margin:0px \
0px 4px;text-transform:uppercase"><span>FEDORA QE</span><span \
style="color:rgb(204,204,204)">, <span \
style="font-weight:normal;color:rgb(170,170,170);margin:0px">RHCE</span></span></p> \
<p style="font-weight:normal;margin:0px;font-size:10px;color:rgb(153,153,153)"><a \
style="color:rgb(0,136,206);font-size:10px;margin:0px;text-decoration:none;font-family:"overpass",sans-serif" \
href="https://www.redhat.com" target="_blank">Red Hat <span><br><br></span></a></p> \
<span style="font-size:10px;margin:0px;color:rgb(153,153,153)"><p \
style="font-size:10px;margin:0px">Purkyňova 115</p></span> <span><p \
style="font-size:10px;margin:0px;color:rgb(153,153,153)">612 45 Brno - Královo \
Pole</p></span> <p style="font-weight:normal;margin:0px 0px \
6px;font-size:10px;color:rgb(153,153,153)"><span style="margin:0px;padding:0px"> <a \
style="color:rgb(0,136,206);font-size:10px;margin:0px;text-decoration:none;font-family:"overpass",sans-serif" \
href="mailto:lruzicka@redhat.com" target="_blank">lruzicka@redhat.com</a> </span>
</p>
<table border="0"><tbody><tr><td width="100px"><img \
src="https://fedoraproject.org/w/uploads/2/2d/Logo_fedoralogo.png" width="96" \
height="29"> </td> <td style="font-weight:normal;font-size:10px">
<div><a href="https://redhat.com/trusted" \
style="text-decoration:none;color:rgb(204,0,0);font-weight:bold" \
target="_blank"><span style="color:rgb(61,133,198)">TRIED</span> <span \
style="color:rgb(0,0,0)">AND PERSONALLY</span> <span \
style="color:rgb(61,133,198)">TESTED</span><span style="color:rgb(0,0,0)">, \
ERGO</span> <span style="color:rgb(61,133,198)">TRUSTED</span>.</a></div>
</td></tr></tbody></table>
</div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div>
[Attachment #6 (text/plain)]
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-leave@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
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic