Hi, Neil,
On Thu, Mar 26, 2020 at 2:41 PM Neal Gompa <ngompa13(a)gmail.com> wrote:
On Thu, Mar 26, 2020 at 7:41 AM Aleksandra Fedorova <alpha(a)bookwar.info> wrote:
>
> On Thu, Mar 26, 2020 at 10:34 AM Vít Ondruch <vondruch(a)redhat.com> 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.
>
In the context of the governmental usage, I can say from my own
experience that having on-disk documentation is valuable when you have
to work in air-gapped environments. Also, when behaviors are patched,
I hope that the docs are patched too to reflect those changes in
behavior.
The problem is not with the docs themselves, but with the tooling
which is used to build them.
Docs are useful, but if upstream decides to use latest JavaScript
framework which has never been packaged or even versioned to build
documentation in 100500 formats, then as downstream(=Fedora) we need
to make amendments to that.
Ideally it needs to be brought all the way upstream, so that it adds
possibility to build docs on different levels. But if it doesn't work
- it is up to us to patch it.
That said, it's not my call whether or not RHEL ships
documentation
for something, I just hope they do because of how often it gets used
in those scenarios.
> 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.
>
Since we can't build anything that exists in RHEL in EPEL, your
conditional doesn't make sense.
Please consider it as a concept: disttag conditionals on top to define
the "profile", and then doc/test flags later in the spec file where it
is needed.
And you might not have known this, but build conditions actually can
be globally flipped. The %bcond_with/%bcond_without macro expands to a
macro that checks for the existence of a macro that flips the behavior
one way or another. Distributions like PLD leverage this property to
use standardized names and inject default settings in their build
targets[1] for everything to use. Since you can define macros in Koji
build tags now, it's possible to implement something like this. And
you've always been able to do this with Mock.
It is doable, but it is not just the tooling question. There is a
process, there is a verification system, there are a lot of policy
things which we would need to consider.
ELN is a good opportunity to try it out in a very small, controlled
setup, which we can manage. We have a lot of experience with this
particular type of conditionals already.
[1]:
http://git.pld-linux.org/?p=packages/rpm-build-tools.git;a=blob;f=bconds....
--
真実はいつも一つ!/ Always, there's only one truth!
_______________________________________________
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
--
Aleksandra Fedorova
bookwar