https://bugzilla.redhat.com/show_bug.cgi?id=2263790

Cristian Le <[email protected]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
              Flags|needinfo?([email protected]) |needinfo?([email protected]
                   |                            |om)



--- Comment #36 from Cristian Le <[email protected]> ---
You guys pretty much covered all of the comments I would have and more :D, so
unless @[email protected] takes it on, I can see it through as well.

I only have some minor random comments:
- how will `%{_sbindir}/alternatives` work w.r.t. sbin/bin merger.
- from what I can see xq-golang is similar with the `xq` provided here, so it
should do the same Conflicts/Alternatives

I can go either way w.r.t. Conflicts vs Alternatives. And I guess the main
thing we should do here is to discuss which one to go for:

Ultimately these tools have completely different approaches, where python-yq
calls `jq` internally, while golang ones are completely self-contained, but I
don't think that is evident enough for the user to make a decision on which
version to go with.

Personally I would choose the python version since it seems to be just a thin
wrapper against the python "standard" libraries (ignoring the question of which
yaml library is used), so I can see this as more stable, but then the golang
parsers can potentially be faster.

If it was possible to add some description about each alternatives, I would
vote for Alternatives, but right now I am split between these two options.

Can someone also play the devil's advocate for the Conflicts case?


-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
https://bugzilla.redhat.com/show_bug.cgi?id=2263790

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-spam&short_desc=Report%20of%20Bug%202263790%23c36
--
_______________________________________________
package-review mailing list -- [email protected]
To unsubscribe send an email to [email protected]
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/[email protected]
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Reply via email to