Dne 27. 03. 20 v 12:48 Aleksandra Fedorova napsal(a): > On Fri, Mar 27, 2020 at 11:00 AM Vít Ondruch <vondruch@xxxxxxxxxx> 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@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? >> >> 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? Yes, that is not different from what we have right now and then the question is what would be the benefit of your proposal. I see just downsides. I would need to do what I do + on top of that, there would be conditionals in Fedora to have it working in ELN. The benefit of branch would be that at minimum, we would do it publicly + with all the CI, we would know that something in Fedora broke our future RHEL package. > >> 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. I am sorry, which one? > > 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? Of course we did all these steps. While the question "Do you really need docs for this package in downstream" should not be asked at all". This is doing disservice to our users, to our support and also disservice to upstream. > > 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. We might disagree, but while this is probably possible, it is nowhere close to be maintainable. Moving this into separate package means 1) I (and users) have one more package to take care 2) There is higher chance that the documentation does not reflect the state of the package. On top of that, you might perceive failed build due to not applicable patch as a problem, I see it as benefit. It is feedback that something has changed upstream and I should pay attention. > > 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. You can touch Makefile only in the simplest projects. I cannot imagine I should touch Makefile in Ruby for example, which has thousands of lines, nobody wants to do that. > 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. There is not .EL part as far as I know, there documentation is 1:1 to upstream AFAIK, the only change is the format change from .ronn to .md > 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. If you do just version bump, the patch will likely apply cleanly. Ok, currently, there is updated release and changelog, but if these were two commits (or if there was automation or release and changelog bumps), the rebase of this package would be done by git just fine. > 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. Now I am lost, who is upstream and who downstream. But anyway, ideal state is when RHEL/Fedora/Upstream is one person. If there was chance to have it like RHEL/ELN/Fedora/Upstream, that would be even better. But you can't reasonably have this with conditional but without branch. Because the requirements for RHEL and Fedora are from time to time different. And I am speaking here with both hats, as a RHEL developer as well as Fedora developer. IOW I am doing different decisions for Fedora and RHEL. > > 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. Sorry, definitely not for me, speaking again with both hats. > The goal is to search for ways to make it easier to > create EL content out of Fedora tree. That is indeed noble goal which I support and why I am involved in this discussion. However, the means you are intend to provide are so far not acceptable. Vít _______________________________________________ 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
