On Fri, Mar 27, 2020 at 9:36 AM Vít Ondruch <vondruch@xxxxxxxxxx> wrote:
>
>
> Dne 26. 03. 20 v 12:39 Aleksandra Fedorova napsal(a):
> > 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 am sorry but you have not passed the test. The test question was "Now
> somebody tell me what it does for what
> purpose and which scenario from the above three should be applied here."
> I would really appreciate, if you could pay attention to the two
> patches I post and what they do. Including careful analysis why they
> were applied and why they were not put into Fedora nor upstreamed.
>
> Hint: They don't disable any documentation.
You put two patches on the thread without context. I assumed that they
remove the fancy dependency needed to build the doc, and instead
create the doc in a more "old-school" ways.
It maybe a wrong assumption. It happens.
Could you then explain the context, and what these patches actually do?
> Thank you.
>
>
> Vít
>
>
> P.S. I really thinking if I should write this and if and how much I am
> offended, because I typically try to remove my feeling from these
> discussions. But really, I and other colleagues have spent quite some
> effort to untangle the whole dependency mess, to provide our users as
> much as we can, to give back to fedora and upstream as much as we can
> and stay sane. That were not easy decisions.
>
> I spent the time to dig out these specific examples of what we did and
> why I think it is important to have branches instead of "just
> conditions", but you don't pay enough attention and you dismiss them as
> "Disabling docs". I am sorry, but this is not fair.
If I were offended every time people don't get my point and the effort
I made to make it, I would give up about 15 years ago.
But that is what discussions are all about: going through a lot of
misunderstanding, trying to actually reach the point where we can
understand each other.
> >
> > 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.
> >
> _______________________________________________
> 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
--
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
