Documentation > Tips and Tricks

NuTyX equivalent of 'apt-file search <a file>'

(1/2) > >>

I've been looking through the man page for cards, and found the command 'cards query <a file>', which lets me
see in which of my installed packages appears a given file; for example,

--- Code: ---$ cards query strftime
Retrieve info about the 481 packages: 100 %
Package  File
bash     usr/lib/bash/strftime
python   usr/lib/python3.8/test/__pycache__/test_strftime.cpython-38.opt-1.pyc
python   usr/lib/python3.8/test/__pycache__/test_strftime.cpython-38.opt-2.pyc
python   usr/lib/python3.8/test/__pycache__/test_strftime.cpython-38.pyc
python   usr/lib/python3.8/test/
python2  usr/lib/python2.7/test/
python2  usr/lib/python2.7/test/test_strftime.pyc
python2  usr/lib/python2.7/test/test_strftime.pyo

--- End code ---

Not bad; but I'd like to be able to do this with packages that live in the NuTyX package database, as I would in Debian with the 'apt-file' program. (For example, I may be trying to install something, and the installation process complains there's a certain C header missing; I'd then run apt-file on that C header, and then in turn install the corresponding package.) Though, my current case is a bit more mundane than that; I just notice that I'm missing some man pages:

--- Code: ---$ man 3 printf
No manual entry for printf in section 3
$ man 3 strftime
No manual entry for strftime in section 3

--- End code ---

Usually, if I know which package I'm dealing with, I can just do

--- Code: ---get <package>.man

--- End code ---

and I'm done; but this time I don't know what the package is!

Hello bc1_

That's a very intersting post.

short answer:

Not possible

Long answer

Not implemented on purpose:

1. cards sync would take longer
2. Redundant info in a meta file and in the archive itself, that exactly what I want to avoid as much as possible with cards. For this reason dependencies are only in the archive (as an example), cards deal with that.
3. It was not clear for me, do we really need that feature.

And now.

If this feature, you think is a must, I would need to really think how to implement it in a smart way ;)


Rather than start a new post, I would like to add my 2 cents worth.

I know a little about Tinycore linux gui package manager called Apps. It has a pull down search function called provides
a user would search for an executable name or shared object name or header name. That repo has a provides.db database file.

post has been EDITTED

so my suggestion would be.....for new packages.....downstream maintainers would need to produces a file list of the new package
for repo maintainer.....they would add these file listings to a database file

To avoid adding a new feature to the gui cards.....members who need to search would find the latest database file at
(relevant to the arch) eg

members would search using their web browser

EDIT ..downstreamer script now 2 posts down

For the Repo maintainer, I guess each new/updated package  list would be "catted" to the most reason database file

upload to replace older one And I suggest it only be asked for .....for new packages or updated packages.

thanks for reading

Ok I can not find a more recent 64 bit provides.db but an example is clickable if interested, and I will show a snippet

The structure has package name, then relevant contents. To save you clicking  link here is a snippet of a package called alsa and amd-dev.tcz as it has example of header file

--- Quote ---alsa.tcz
SNIP OUT other exes
SNIP OUT OTHER wav files

--- End quote ---

strictly speaking....the member does not care if the executable is in /usr/local  or /usr/bin or /sbin etc.....they just want to know what package to install for a specific executable

ditto the shared object executables and headers.

This helps package they are looking for missing shared objects or headers.
Naturally, you can have duplicate header names in different packages
eg searchterm=autoconf.h gives multiple hits including
zziplib-dev.tcz etc
and so the searcher would research the package description to assess the relevance.

ok I have bodgied up a simple script. I have made up some file under /usr/bin for example purposes.
The package maintainer would know where the files are generated. Let me use 8188eu as starting point
script might have

--- Code: ---P=8188eu
# the package assumed built in a dir called /tmp/$P
cd /tmp/$P/usr/bin
echo $P > /tmp/$P.list
ls >> /tmp/$P.list

# below not a part of script but would show up in database
cat /tmp/$P.list
--- End code ---

and the downstreamer would  change dir into other dirs only if needed to list shared objects, headers and to help OP,
man pages but not need to list licences.

The database could be called database.txt and would be searchable using a standard web browser.


[0] Message Index

[#] Next page

Go to full version