Cristian Le via devel venit, vidit, dixit 2026-02-16 11:31:39: > 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 why? If there are file conflicts then neither EPEL nor COPR will help. If there is no file conflict and users just need to set LESSOPEN to the proper absolute path the package can go into EPEL and Fedora if it makes sense at all to package it - is it merely a single script? > 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. In particular, if the builtin lesspipe is usable, the less package should make no opinionated choice packagaing an external lesspipe.sh and enabling it bt default. > Are there other helpers in there that should be patched to avoid the > same issue in the future? Those like lessecho which are marked "for internal use" should not end up in /usr/bin but some package specific dir, simply for clarity. I'd say this apples to all versions of lesspipe, to. Dunno what lesskeys does. Cheers Michael -- _______________________________________________ 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
