On Thu, Mar 26, 2020 at 10:34 AM Vít Ondruch <vondruch@xxxxxxxxxx> wrote:
>
>
> Dne 25. 03. 20 v 20:22 James Cassell napsal(a):
> > On Wed, Mar 25, 2020, at 1:18 PM, Vít Ondruch wrote:
> >> Dne 25. 03. 20 v 18:06 Vít Ondruch napsal(a):
> >>> Dne 25. 03. 20 v 17:33 Aleksandra Fedorova napsal(a):
> > [snip]
> >>>> We can come up with guidelines, for example:
> >>>>
> >>>> 1) Try to find a way to resolve the issue without any conditionals first.
> >>>>
> >>>> There should be a reason why package X needs a dependency Y in Fedora
> >>>> and there should be a reason why it is a required dependency and not a
> >>>> recommended one. So why in that case downstream wants it differently?
> >>>> The first approach is just to talk through it. I can assume cases
> >>>> where downstream adds a dependency, as well as Fedora package removing
> >>>> them.
> >>>>
> >>>> Note that bloated dependency trees is a common problem for all binary
> >>>> distributions, it is not an "EL-thing" and we can work on that
> >>>> together.
> >>>>
> >>>> Nicolas has pointed out to another reason why we would get
> >>>> EL-conditionals: the outdated rpm stack in RHEL. But we don't have
> >>>> this problem with ELN, as we are building Rawhide, and rpm stack is
> >>>> going to be the Rawhide rpm stack as well.
> >>>>
> >>>> 2) Minimize and isolate the conditional, and track the reason.
> >>>>
> >>>> As ELN SIG we need to have a place where we collect known reasons for
> >>>> such conditionals. The overall goal is to reduce this set, not to grow
> >>>> indefinitely. As Stephen said we expect it to be about couple of
> >>>> hundred packages. We will be able to track each one of them. (We have
> >>>> rpminspect to run package diffs for us).
> >>>>
> >>>> 3) In complex cases - bring it to community and FESCo.
> >>>>
> >>>> We don't know what those complex cases might be, one of the goals is
> >>>> to find them. So we keep it as an option to bring individual case to a
> >>>> wider audience. To ask for help and to decide on it.
> >>>>
> >>> It seems there are missing real life examples of what we sometimes do in
> >>> RHEL, so please see attached patch. This patch is coming from RHEL
> >>> version of the espeak-ng. Now somebody tell me what it does for what
> >>> purpose and which scenario from the above three should be applied here.
> >>>
> >>>
> >>> Vít
> >>>
> >> And here is another example for the curious.
> >>
> > Both of these examples have to do with docs generation and trying to reduce dependencies for that process. "Process the man page using kramdown and remove the ronn dependency."
>
>
> The point is that these types of changes are not upstreamable. And the
> conditions would also be awful. Having these changes in separate branch
> would be much preferable IMO, because honestly, I would like every
> Fedora maintainer save from this cruft not because I would like to hide
> something, but for their own sanity.
I disagree actually.
Disabling docs to reduce dependencies makes sense. And it is not a
RHEL-only thing.
I had the conversation at the latest Devconf with people who are
aiming to build Linux distribution with a reduced buildroot footprint
for security purposes. So that they can audit the content of the
buildroot, and get to a certain level of certification with it.
I think It can not be done directly in Fedora, but if we add the
flexibility into our builds (with conditionals), then we could
eventually get a new downstream supported by a certain governmental
entity.
What we should avoid is using conditionals randomly and inconsistently.
So let's agree that we are not scattering "%if 0%{?rhel} && (!
0%{?epel})" all over the spec file, but rather define it once at the
top of the spec file:
%if 0%{?rhel} && (! 0%{?epel})
%bcond_with docs
%else
%bcond_without docs
%endif
And use later in a form
...
%if %{with doc}
%package doc
...
%endif
Yes, for now we would go with a "%if 0%{?rhel} && (! 0%{?epel})" in
the header of the affected spec file. But eventually we can think
about adding a USE-flag like functionality to the build process, and
create a global profile for the build system.
This is a very much forward-looking statement, but idea is already
making its round by the dnf team.
So there are some interesting ways how this approach can be developed
further, if we can make it work for a smaller subset first.
--
Aleksandra Fedorova
bookwar
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
