Re: Proposed Modular Policy for Fedora ELN
by Miro Hrončok
On 21. 08. 20 16:38, Stephen Gallagher wrote:
> On Fri, Aug 21, 2020 at 9:41 AM Miro Hrončok <mhroncok(a)redhat.com> wrote:
>> I want a policy for Fedora (and I see ELN as part of Fedora) that says: "Default
>> streams are not allowed."
>>
>> We already have that policy. In the IRC meeting line you quoted I expressed my
>> feeling that the policy also applies (and should continue to apply) to ELN,
>> because ELN **is** Fedora.
>>
>> This has been my view on this topic since the original FESCo ticket.
>>
>> I don't understand how should I be more ingenuous.
>
> If my previous email was not clear enough: I accept complete
> responsibility for my misunderstanding and I apologize for my
> accusation of disingenuousness. I understand your position properly
> now and will proceed accordingly.
Thank you.
> That said, I (obviously) disagree with the assertion that ELN must not
> have default streams and I stand by this proposal as a reasonable way
> of defining and controlling how that will work.
I would not expect anything different.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
3 years, 8 months
Re: Proposed Modular Policy for Fedora ELN
by Miro Hrončok
On 21. 08. 20 10:07, Zbigniew Jędrzejewski-Szmek wrote:
>> Josh listed some of the key reasons behind default streams: that
>> enterprise customers don't like to learn new commands. So default
>> streams allowed us to package content with shorter-than-RHEL-lifetime
>> and still `yum install foo` would install something the customer could
>> use.
> I guess that "shorter-than-RHEL-lifetime" is the big differentiator, i.e.
> normal rpms cannot be yanked from the distribution, but a module can be.
Actually AFAIK modules shipped at GA cannot be yanked from the distribution
either. Certainly not in Fedora.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
3 years, 8 months
Re: Proposed Modular Policy for Fedora ELN
by Petr Pisar
On Fri, Aug 21, 2020 at 07:55:57PM +0200, Miro Hrončok wrote:
> On 21. 08. 20 10:07, Zbigniew Jędrzejewski-Szmek wrote:
> > > Josh listed some of the key reasons behind default streams: that
> > > enterprise customers don't like to learn new commands. So default
> > > streams allowed us to package content with shorter-than-RHEL-lifetime
> > > and still `yum install foo` would install something the customer could
> > > use.
> > I guess that "shorter-than-RHEL-lifetime" is the big differentiator, i.e.
> > normal rpms cannot be yanked from the distribution, but a module can be.
>
> Actually AFAIK modules shipped at GA cannot be yanked from the distribution
> either. Certainly not in Fedora.
>
Modules are not removed from RHEL repositories either. The difference is that
in RHEL they stop being supported. That's something what Fedora has not yet
experienced.
Bedides EPEL. I think that packages in EPEL are sometimes rebased to
incompatible versions and what happen with the unneded dependencies of the old
versions is not clear to me. I think they are marked as a dead package in
dist-git and blocked from Koji. But do they disappear from the repository? If
the stable repository is based on Koji blocked status, then then should the
removed.
-- Petr
3 years, 7 months
Re: Proposed Modular Policy for Fedora ELN
by Stephen Gallagher
On Fri, Aug 21, 2020 at 1:57 PM Miro Hrončok <mhroncok(a)redhat.com> wrote:
>
> On 21. 08. 20 10:07, Zbigniew Jędrzejewski-Szmek wrote:
> >> Josh listed some of the key reasons behind default streams: that
> >> enterprise customers don't like to learn new commands. So default
> >> streams allowed us to package content with shorter-than-RHEL-lifetime
> >> and still `yum install foo` would install something the customer could
> >> use.
> > I guess that "shorter-than-RHEL-lifetime" is the big differentiator, i.e.
> > normal rpms cannot be yanked from the distribution, but a module can be.
>
> Actually AFAIK modules shipped at GA cannot be yanked from the distribution
> either. Certainly not in Fedora.
That is correct; the modules cannot be removed from the distribution,
but the encapsulation of them in a separate delivery mechanism enables
the support *policy* to be different. (In particular, it's acceptable
from a technical perspective for customers of RHEL to keep using an
EOL module if they cannot transition in time; they just have to accept
the risks.)
3 years, 7 months
Re: Proposed Modular Policy for Fedora ELN
by Neal Gompa
On Mon, Aug 24, 2020 at 10:17 AM Zbigniew Jędrzejewski-Szmek
<zbyszek(a)in.waw.pl> wrote:
>
> We use fedora-obsolete-packages to remove packages from end-user systems.
> Users can opt-out of installation of fedora-obsolete-packages and retain
> packages that would be obsoleted [*].
>
> The same mechanism could be used RHEL, for example by having 'rhel-is-up-to-date.rpm'
> installed by default, with newer versions doing the obsoletes for packages
> that have been dropped. Users *may* stop the upgrade of rhel-is-up-to-date,
> but then they know their system is using outdated packages. DNF will even
> nicely tell them which ones.
>
> This is: a) simple, b) well-understood, c) already implemented.
>
> Zbyszek
>
> [*] Right now fedora-obsolete-packages has Provides:libsolv-self-destruct-pkg(),
> so this muddies the situation a bit. Let's assume that the packages in RHEL
> would not have that set.
Note that exclusion should also work even with the self-destruct
property, since exclusion means it no longer gets computed in solver
transactions at all.
--
真実はいつも一つ！/ Always, there's only one truth!
3 years, 7 months
Re: The Future of the Java Stack (also regarding ELN and RHEL)
by Tomasz Torcz
On Thu, Sep 10, 2020 at 04:03:46PM +0200, Petr Pisar wrote:
> In non-modular Fedora all packages that we have in Fedora build system (Koji)
> are tagged into Fedora repositories and made available to all users on their
> computers for any purpose. That implies that all packages in Fedora build system
> must be fully supported including addressing all security issues.
>
> In modular Fedora that's (effectively) not true. Packages that only exist
> for the sake of building other packages (i.e. build-only dependencies) can be
> retained in the Fedora build system and never left it. That means those
> packages are never made available to Fedora users and thus a service level for
> them is significantly lower. E.g. no security fixes, not bug fixes, no
> integration, not tests, no API/ABI stability. The only requirement is that
> they can be built and used for building other packages.
So, if user wants to locally rebuild the package, they won't be able to
do it? Because BuildRequired packages won't be available?
--
Tomasz Torcz “Funeral in the morning, IDE hacking
tomek(a)pipebreaker.pl in the afternoon and evening.” - Alan Cox
3 years, 7 months
Re: The Future of the Java Stack (also regarding ELN and RHEL)
by Mikolaj Izdebski
On Thu, Sep 10, 2020 at 4:35 PM Tomasz Torcz <tomek(a)pipebreaker.pl> wrote:
>
> On Thu, Sep 10, 2020 at 04:03:46PM +0200, Petr Pisar wrote:
> > In non-modular Fedora all packages that we have in Fedora build system (Koji)
> > are tagged into Fedora repositories and made available to all users on their
> > computers for any purpose. That implies that all packages in Fedora build system
> > must be fully supported including addressing all security issues.
> >
> > In modular Fedora that's (effectively) not true. Packages that only exist
> > for the sake of building other packages (i.e. build-only dependencies) can be
> > retained in the Fedora build system and never left it. That means those
> > packages are never made available to Fedora users and thus a service level for
> > them is significantly lower. E.g. no security fixes, not bug fixes, no
> > integration, not tests, no API/ABI stability. The only requirement is that
> > they can be built and used for building other packages.
>
>
> So, if user wants to locally rebuild the package, they won't be able to
> do it? Because BuildRequired packages won't be available?
Modules can be built locally with "fedpkg module-build-local", which
downloads required dependencies from Koji and installs them in mock
chroot. These packages are not installed directly (outsides of chroot)
on users systems.
>
>
> --
> Tomasz Torcz “Funeral in the morning, IDE hacking
> tomek(a)pipebreaker.pl in the afternoon and evening.” - Alan Cox
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)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
3 years, 7 months
Re: The Future of the Java Stack (also regarding ELN and RHEL)
by Vitaly Zaitsev
On 10.09.2020 16:10, Aleksandar Kurtakov wrote:
> Flatpak is way better suited for our use case and in addition gives us
> access to a way bigger install base.
Flathub is a third-party repository and not related to Fedora at all.
> And the involvement on Java packaging in Fedora is so low that we literally have to maintain whole other stacks including jetty, lucene and etc. - not feasible work in any way.
Fedora Modularity team destroyed the entire Java stack in Fedora after
moving ant/maven to modules.
I think FESCo should completely forbid modules without packaged
non-modular versions.
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
3 years, 7 months
Re: The Future of the Java Stack (also regarding ELN and RHEL)
by Aleksandar Kurtakov
On Thu, Sep 10, 2020 at 5:54 PM Vitaly Zaitsev via devel <
devel(a)lists.fedoraproject.org> wrote:
> On 10.09.2020 16:10, Aleksandar Kurtakov wrote:
> > Flatpak is way better suited for our use case and in addition gives us
> > access to a way bigger install base.
>
> Flathub is a third-party repository and not related to Fedora at all.
>
> > And the involvement on Java packaging in Fedora is so low that we
> literally have to maintain whole other stacks including jetty, lucene and
> etc. - not feasible work in any way.
>
> Fedora Modularity team destroyed the entire Java stack in Fedora after
> moving ant/maven to modules.
>
As I've been involved in ant/maven packaging for a decade or so I would
dare to say that this is not the truth. It just exposed the fact that less
and less people were actively maintaining things as most of the people that
used to do it moved on to other things and the number of new people that
joined is quite low. So the burden on people left is bigger and bigger.
>
> I think FESCo should completely forbid modules without packaged
> non-modular versions.
>
> --
> Sincerely,
> Vitaly Zaitsev (vitaly(a)easycoding.org)
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)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
3 years, 7 months
Re: The Future of the Java Stack (also regarding ELN and RHEL)
by Guido Aulisi
> Il giorno 10 set 2020, alle ore 16:53, Vitaly Zaitsev via devel <devel(a)lists.fedoraproject.org> ha scritto:
>
> On 10.09.2020 16:10, Aleksandar Kurtakov wrote:
>> Flatpak is way better suited for our use case and in addition gives us
>> access to a way bigger install base.
>
> Flathub is a third-party repository and not related to Fedora at all.
>
>> And the involvement on Java packaging in Fedora is so low that we literally have to maintain whole other stacks including jetty, lucene and etc. - not feasible work in any way.
>
> Fedora Modularity team destroyed the entire Java stack in Fedora after
> moving ant/maven to modules.
>
> I think FESCo should completely forbid modules without packaged
> non-modular versions.
I totally agree
> --
> Sincerely,
> Vitaly Zaitsev (vitaly(a)easycoding.org)
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)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
Ciao
Guido
3 years, 7 months
