On Fri, Mar 27, 2020 at 11:00 AM Vít Ondruch <vondruch(a)redhat.com> wrote:
Dne 27. 03. 20 v 10:16 Aleksandra Fedorova napsal(a):
> On Fri, Mar 27, 2020 at 9:36 AM Vít Ondruch <vondruch(a)redhat.com> 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(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 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?
There is much more to this.
One think of course is to limit the dependencies. So therefore we didn't
want rubygem-ronn in RHEL. But even if we wanted, it is [1] abandoned
upstream. If Ronn is abandoned upstream, the biggest problem is with its
dependencies, which are officially deprecated upstream. While it is
abandoned upstream, it is still valuable tool, which can easily generate
man pages from markdown. So now on top of the question "should we have
Ronn in RHEL or not" you have suddenly other issues:
* Should we save upstream Ronn? And how to do this if upstream is
unresponsive.
* How to provide the documentation to our users if we don't have Ronn
available.
* Should I go to Fedora and push the Ronn removal out of the package and
possible from all packages, while we still have Ronn in Fedora?
* Should I go to all upstreams and convince them, that they should not
use Ronn, just because I cannot contact Ronn upstream, while the tool
itself is perfectly fine?
* And finally should we just remove the documentation as you framed it?
Thanks for the explanation.
Not mentioning that if we even put the "document removal"
conditional
into the package, that is actually the worst thing we could do, because
if any of the considerations above changes (Ronn gets back to the life,
upstream decided to change tools used to build documentation, there is
high demand for such tool, so we reconsider it inclusion, or there is no
demand and it is removed even from Fedora), there is almost no chance
that somebody would noticed and put the package back into its best
possible shape.
This part I don't understand. If we have a with_docs conditional, we
keep building package with docs in Fedora. And downstream needs to
track on its own when it would like to switch this conditional on for
downstream packages.
I think it is not different from what we have right now, is it?
As you can see, there is much more to this just to "put some conditional
somewhere". There are very complex considerations and a lot of work.
Therefore, I would really like to see you try to replace the patches I
provided by conditions to let you feel how ugly and unmaintainable the
packages become.
There is one point to note here: when I posted example of the
guidelines with those three items, i didn't mean it as a choice, as if
you need to choose one out of three. I meant it as steps: you need to
go through all of them.
And you are skipping one here.
So before we go into conditionals, we should have a discussion: can we
solve it in upstream or Fedora itself. Was it discussed with Fedora
maintainer and the upstream? Do they have a strong opinion on that?
If upstream is not interested in removing dependency on the package,
would they consider _adding_ an option to build a "lightweight"
variant of the documentation without it? As a build flag or something.
Would Fedora maintainer be ok to switch to this lightweight version of the docs?
Then there is a downstream-facing question: Do you really need docs
for this package in downstream so much that it justifies maintaining
the entire source of the documentation files?
In that espeak-ng patch if I understand correctly you replace original
sources for the documentation. In this case instead of adding those
pieces into Fedora spec, I would do it differently: I would have
with_docs condition in Fedora spec, which would disable docs when they
are not needed. And then I would have a separate package, downstream
only, with converted docs, which downstream will maintain.
Now if we still go with direct conditional option, then I would limit
what goes under conditional. So instead of putting the whole thing
from the patch under "if", I would add a patch which allows both
options. Which adds the target to Makefile instead of removing it. And
then only put the switch between them under conditional in the spec
file.
The espeak patch is disruptive currently because it edits things in
place. For example it edits README file, instead of adding the
README.EL part. Or it removes doc files instead of adding them into a
different docs-el subfolder. So the goal here would be refactor the
patch so that version bump can be done in a clean way. And then you
either add some automation for the version bump, so it updates the
docs properly. Or you leave it to the downstream maintainer to watch
for the upstream change and send pull-requests to update this part.
Which will bring downstream developer to the position of the
co-maintainer of this package.
So i am not proposing something like "let's convert every patch into a
conditional". The goal is not to have all RHEL content in Fedora
Rawhide tree. The goal is to search for ways to make it easier to
create EL content out of Fedora tree.
As a bonus, it might be committed without good enough explanation in
commit message to let the future generations share the pain (sorry, this
is snarky remark, but unfortunately this is the reality package
maintainer lives in, the commit message can't never be good enough).
Vít
[1] I just noticed there is now ronn-ng, but it was not at that time.
And since the project has not taken over the former name, it is
naturally its own can of worms.
>
>> 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(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
_______________________________________________
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