Hi, On Thu, Feb 09, 2023 at 03:10:39PM +0100, Patrice Duroux wrote: > Dear Maintainer,
(Disclaimer: I am not an apt-file, but an apt maintainer) > The first is regarding the sub std_release that I add to match the 'apt list' You are not allowed to use 'apt' in a script. We could change its output any second breaking your ad hoc parsing without any qualms. > that gives 'unstable' even if the apt sources.list is using 'sid' and then 'apt list' for some reason prints the 'Suite' value. I suppose it really shouldn't and pick 'Release' (which is what the sources.list includes, which is either 'Suite' or 'Codename' usually). We might change that (q.e.d. previous paragraph). There is no absolute right answer here, it is a question of UI and the specific use case which you prefer. > accordingly the name of the content files. Is there a better way? (apt API? > metadata file?...) I have no idea about perl & libapt-pkg-perl, but I suppose getting a list of installed packages is such a basic task that it should be possible with it. If you really want to parse a program, dpkg would be the better choice here. Accessing the names of files (including the Content files) is a relatively new feature (like ~2 Debian releases old), so I am not sure how much if any is accessible in perl. Command line wise it would be via 'apt-get indextargets'. You will need this as a) Content files have different filenames in different repositories as they have different storage locations (Debian vs Ubuntu mostly). b) are likely compressed, but if and with what is a configuration detail. c) I have plans, but nothing concrete yet to have apt store files elsewhere and with names where your guessing wouldn't work at all. As I am not sure what apt-file does here and what your (perl) code changes, I have no comment on the patch itself and what effects output changes would have. Best regards David Kalnischkies
signature.asc
Description: PGP signature
