There's no "htsearch" executable in the htdig package #119

Closed
opened 4 years ago by Ghost · 18 comments
Ghost commented 4 years ago

Some parts of the code in khelpcenter/searchhandlers are looking for an "htsearch" executable, but there is none in the htdig package.

One way around is to change htsearch for htdig where need is required or just remove the extra code related to htsearch.

But an other option might be to keep these parts with a slight tweak since htdig has been forked into hldig.
https://github.com/solbu/hldig

Thanks to TheRealGrogan at LQ for the heads-up.
https://www.linuxquestions.org/questions/slackware-14/wanting-to-compile-the-newest-packages-for-trinity-desktop-but-i%27m-not-sure-what-to-do-4175666032/#post6068544

To be continued...

Some parts of the code in khelpcenter/searchhandlers are looking for an "htsearch" executable, but there is none in the htdig package. One way around is to change htsearch for htdig where need is required or just remove the extra code related to htsearch. But an other option might be to keep these parts with a slight tweak since htdig has been forked into hldig. https://github.com/solbu/hldig Thanks to TheRealGrogan at LQ for the heads-up. https://www.linuxquestions.org/questions/slackware-14/wanting-to-compile-the-newest-packages-for-trinity-desktop-but-i%27m-not-sure-what-to-do-4175666032/#post6068544 To be continued...
Owner

in debian that is part of the htdig package. For reference

https://packages.debian.org/search?keywords=htdig

in debian that is part of the htdig package. For reference<br> https://packages.debian.org/search?keywords=htdig
Ghost commented 4 years ago
Poster

I close this issue, at first glance this does not seem valid.
My system reports two executables, one as /srv/www/cgi-bin/htsearch the other as /var/www/cgi-bin/htsearch ; furthermore the perl script "khc_htsearch.pl" reports the "htsearchpath" variable as the binary "/srv/www/cgi-bin/htsearch".

I close this issue, at first glance this does not seem valid. My system reports two executables, one as /srv/www/cgi-bin/htsearch the other as /var/www/cgi-bin/htsearch ; furthermore the perl script "khc_htsearch.pl" reports the "htsearchpath" variable as the binary "/srv/www/cgi-bin/htsearch".
Ghost closed this issue 4 years ago
selk commented 4 years ago
Collaborator

Hello :-)

Just for reference, the htsearch name in the htdig fork (hldig) is called:
hlsearch

usr/share/man/man1/hlsearch.1
usr/share/hldig/cgi-bin/hlsearch
Hello :-) Just for reference, the htsearch name in the htdig fork (hldig) is called: ``hlsearch`` ``` usr/share/man/man1/hlsearch.1 usr/share/hldig/cgi-bin/hlsearch ```
Ghost commented 4 years ago
Poster

Hi @selk
If you've packaged hldig instead of htdig in Dragora, then feel free to send a PR.

Hi @selk If you've packaged hldig instead of htdig in Dragora, then feel free to send a PR.
selk commented 4 years ago
Collaborator

Hello Gregory,

Yes, I was able to have this packaged in Dragora. What do you mean by PR, where?.

Hello Gregory, Yes, I was able to have this packaged in Dragora. What do you mean by PR, where?.
Ghost commented 4 years ago
Poster

Matías, if you need a fix for Dragora on tdebase, then make a Pull Request (PR).

Matías, if you need a fix for Dragora on tdebase, then make a **P**ull **R**equest (PR).
selk commented 4 years ago
Collaborator

There is no need to modify anything related to htdig on tdebase. Unless the distributions start replacing htdig with the fork (hldig) then it would make sense to look for hldig; it remains to be seen if the hldig maintainer is interested in keeping the fork, and also if it will not be renamed to htdig tomorrow, are some possibilities. For now it is not a big deal as the tdebase build system can be passed on:

-DHTDIG_SEARCH_BINARY=<path_to_hlsearch>

There is no need to modify anything related to htdig on tdebase. Unless the distributions start replacing htdig with the fork (hldig) then it would make sense to look for hldig; it remains to be seen if the hldig maintainer is interested in keeping the fork, and also if it will not be renamed to htdig tomorrow, are some possibilities. For now it is not a big deal as the tdebase build system can be passed on: ``-DHTDIG_SEARCH_BINARY=<path_to_hlsearch>``
selk commented 4 years ago
Collaborator

Good news, the hldig development is active, and there are newer versions: https://github.com/solbu/hldig

Good news, the hldig development is active, and there are newer versions: https://github.com/solbu/hldig
Chris commented 4 years ago
Collaborator

After some investigation I found out that this is not working as expected.

While @selk is right, the path above is really just a path and this path will be used for searching for the htsearch binary. Not for the hlsearch binary. And it seems that is hardcoded into some perl scripts. Also there seems to be need for the htdig and htmerge binaries, which are hldig and hlmerge in the fork.

References:

Also these scripts are looking for the wrong config files. But with some small changes, or some additional CMake rule to define -DWITH_HTDIG, or -DWITH_HLDIG, there could be a second searchhandler and the BS could decide which one to use. Maybe that would be the cleanest solution?

After some investigation I found out that this is not working as expected. While @selk is right, the *path* above is really just a *path* and this path will be used for searching for the *htsearch* binary. Not for the *hlsearch* binary. And it seems that is hardcoded into some perl scripts. Also there seems to be need for the *htdig* and *htmerge* binaries, which are *hldig* and *hlmerge* in the fork. References: * https://mirror.git.trinitydesktop.org/gitea/TDE/tdebase/src/branch/master/khelpcenter/searchhandlers/khc_htdig.pl.in * https://mirror.git.trinitydesktop.org/gitea/TDE/tdebase/src/branch/master/khelpcenter/searchhandlers/khc_htsearch.pl.in Also these scripts are looking for the wrong config files. But with some small changes, or some additional CMake rule to define *-DWITH_HTDIG*, or *-DWITH_HLDIG*, there could be a second *searchhandler* and the BS could decide which one to use. Maybe that would be the cleanest solution?
selk commented 4 years ago
Collaborator

Hm..

IMHO, the simplest solution is for "hldig" to decide to continue as "htdig".

If you want I can ask the maintainer of hldig (solbu), maybe he has contact with the original author of htdig...

Hm.. IMHO, the simplest solution is for "hldig" to decide to continue as "htdig". If you want I can ask the maintainer of hldig (solbu), maybe he has contact with the original author of htdig...
Chris commented 4 years ago
Collaborator

Yes @selk , that would be wonderful, if he would be willing to do that. Maybe they can find consens. In that case, any additional work would be not needed. 👍

Yes @selk , that would be wonderful, if he would be willing to do that. Maybe they can find consens. In that case, any additional work would be not needed. :+1:
selk commented 4 years ago
Collaborator
https://github.com/solbu/hldig/issues/144
selk commented 4 years ago
Collaborator

According to what I understood from Johnny Solbu's words, hldig will not be renamed to htdig, but will continue under the name hLdig.

According to what I understood from Johnny Solbu's words, hldig will not be renamed to htdig, but will continue under the name hLdig.
selk commented 4 years ago
Collaborator

There is the possibility of renaming tdebase stuff to hldig, as well as providing symbolic links compatible with "htdig" on the package side...

Let me know guys what you think.

There is the possibility of renaming tdebase stuff to hldig, as well as providing symbolic links compatible with "htdig" on the package side... Let me know guys what you think.
Chris commented 4 years ago
Collaborator

@selk: Thanks for asking and looking for that.

As I pointed out already, just doing symlinks isn't enough.
The scripts I pointed out, need to be changed too.

So if you want to play with that, just open some PR. 👍

I would be happy to test. 😸

EDIT: Ah, seems I have puzzled that. I find it complicated to start using symlinks on the packaging side. Better would be some build option for using either htdig, or hldig.

@selk: Thanks for asking and looking for that. As I pointed out already, just doing symlinks isn't enough. The scripts I pointed out, need to be changed too. So if you want to play with that, just open some PR. :+1: I would be happy to test. :smile_cat: EDIT: Ah, seems I have puzzled that. I find it complicated to start using symlinks on the packaging side. Better would be some build option for using either htdig, or hldig.
selk commented 4 years ago
Collaborator

According to the words of Solbu, htdig won't be maintained anymore. It is better to migrate and spread the word about hldig, I guess.

P.S: Once I find a free time I will try to look on it and prepare a PR.

According to the words of Solbu, htdig won't be maintained anymore. It is better to migrate and spread the word about hldig, I guess. P.S: Once I find a free time I will try to look on it and prepare a PR.
Ghost commented 4 years ago
Poster

According to the words of Solbu, htdig won’t be maintained anymore.

Matías, can you source those words, here (link)? Because if htdig is no more, then I'll ask Volkerding to either remove htdig or ask him to switch over to hldig for the next Slackware release.

>According to the words of Solbu, htdig won’t be maintained anymore. Matías, can you source those words, here (link)? Because if htdig is no more, then I'll ask Volkerding to either remove htdig or ask him to switch over to hldig for the next Slackware release.
selk commented 4 years ago
Collaborator
@cethyel https://github.com/solbu/hldig/issues/144
Sign in to join this conversation.
No Milestone
No Assignees
4 Participants
Notifications
Due Date

No due date set.

Dependencies

No dependencies set.

Reference: TDE/tdebase#119
Loading…
There is no content yet.