Help > Tips and Tricks
NuTyX equivalent of 'apt-file search <a file>'
bci_:
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/test_strftime.py
python2 usr/lib/python2.7/test/test_strftime.py
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!
Thierry:
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 ;)
Thierry
aus9:
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
http://downloads.nutyx.org/x86_64/rolling/
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
aus9:
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
http://tinycorelinux.net/4.x/x86/provides.db
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
aconnect
alsaloop
alsamixer
SNIP OUT other exes
smixer-ac97.so
smixer-hda.so
smixer-sbase.so
alsactl
Front_Center.wav
SNIP OUT OTHER wav files
amd-dev.tcz
amd_internal.h
amd.h
libamd.a
--- 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 builders.....as 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
freeradius-dev.tcz
zziplib-dev.tcz etc
and so the searcher would research the package description to assess the relevance.
aus9:
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
8188eu
exe1
exe2
--- 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.
Navigation
[0] Message Index
[#] Next page
Go to full version