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 Select Expand


$ 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


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 Select Expand


$ man 3 printf
No manual entry for printf in section 3
$ man 3 strftime
No manual entry for strftime in section 3


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

Code Select Expand


get <package>.man


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

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

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 Select Expand

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

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.

[aus9]

OP

In the meantime a suggestion on how to resolve missing man pages
go to
https://packages.debian.org/index

find the input box for Search the contents of packages
input your man page names and then check cards search searchterm.

I suggest they might be coreutils and bash. Debian package name appears to be bash-builtins ....YMMV

[Thierry]

Hmmm,

I'm a bit lost now. All I can say:

To find a package just go to:

https://www.nutyx.org/en/packages

You can query for any package in 32/64/All bits and in Rolling/Testing/All releases.

By clicking on the respective link, you can find:

- The Arch of the package links to the git <arch> project
- The Branch of the package links to the branch of the git project
- The Collection of the package links to the collection of the branch of the <arch> git project
- The Name of the package links to the name of the package from the ollection of the branch of the <arch> git project
- The Version of the package links to the history of the package
- The Description of the package links to the upstream URL
- The Update of the package links to the final depot directory and shows the UTC building time of the package and sub-packages.

All those features are possible because the nutyx.org website is powered by cards itself.

Still something missing?

BR,
Thierry