On 2026/02/15 14:05, Michael J Gruber wrote:
Andreas Haupt venit, vidit, dixit 2026-02-15 09:30:08:
Unfortunately, as it uses the same concept like less' built-in preprocessor,
it conflicts with its lesspipe.sh script. Therefore I just moved stuff into
/usr/libexec/lesspipe in order to avoid naming conflicts. This works well,
but Christian Le pointed out in the review, it might cause user trouble in
some cases.
Which problems? It's not clear to me from the review. Users of less and
LESSOPEN should be technically versed enough to set LESSOPEN in the
environment of all process which they want to use it.
I was mostly concerned of the out-of-box experience when installing the
package and the fact that `lesspipe` itself is already packaged within
`less`.
That being said, the "less" package in Fedora already ships
"lesspipe.sh" from an external source (not the builtin) and puts that
and things like "lessecho" (which are for internal less usage only) into
/usr/bin. I don't think this is a good choice; less could use some
restructuring.
Yes, the structure here is the main thing that gets in the way
`lesspipe` is not a separate package, so
we cannot use `Provides`/`Obsoloetes` here. And the original issue was
about supporting EPEL, which
gets more complicated that we cannot fix this even if we restructure
`less` on rawhide :(
How are similar cases handled in other packages? Any pointers would be very
helpful and appreciated.
Either separate conflicting subpackages, or separate non-conflicting
install paths so that users can choose by setting LESSOPEN accordingly.
I think for Andreas' case, best would be the design in the package
review, but hosted on a copr repo
or epel-only package and require the users to manually opt-in to this.
But for long-term, it would be
better if `lesspipe` could be split out of `less`, unless there is some
other reasons why these need to
be in the same repo.
Are there other helpers in there that should be patched to avoid the
same issue in the future?
Also CC-ing the less maitainers to chime in a bit here.
--
_______________________________________________
devel 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://forge.fedoraproject.org/infra/tickets/issues/new
