Your message dated Sun, 7 Jun 2026 04:31:47 +0200
with message-id <[email protected]>
and subject line Re: Bug#1131438: Feature request: 'Dpkg -L -R <pkg>' to show 
files from metapackages including dependencies.
has caused the Debian Bug report #1131438,
regarding Feature request: 'Dpkg -L -R <pkg>' to show files from metapackages 
including dependencies.
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)


-- 
1131438: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1131438
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
package: dpkg

Hello, thank you for reading this feature request.



Hopefully the title is self-explanatory, but I will try to make this clear:



#The issue:



User wants to know what files were installed by running 'apt install <package>'



He can run 'dpkg -L <package>' but that only shows files installed by the 
metapackage itself, not its dependencies.



He can also use 'apt-cache depends --recurse', but that produces huge files 
with too much info, not just the files added.



#Backwards Compatibility?:



Yes, fully, currently dpkg -L -R reads out an error, as the options are 
considered incompatible (-R is used for something else, but the option can be 
reused in this separate context).



#Implementation:



I am available to attempt implementing the fix if I can be formally assigned 
the issue with the expectation that in principle there's interest in applying 
the patch to mainstream. 



No general guidance is needed, my approach would be to start by reading the 
Debian New Maintainer's guide, the project specific readmes, building dpkg, 
hacking a recursive solution and integrating it with the main binary when the 
combination of both options is invoked.



The deliverable would of course be in git-patch format.


#Clarification:



I know that these days there's a lot of LLM spam to OS projects, so I'd like to 
clarify of course that this message is not LLM written, and that a patch would 
not include LLM output.



Thank you.

--- End Message ---
--- Begin Message ---
Hi!

On Sun, 2026-03-22 at 04:28:54 +0100, Guillem Jover wrote:
> Control: severity -1 wishlist
> Control: tag -1 moreinfo
> 
> On Sat, 2026-03-21 at 09:42:05 -0300, Tomas wrote:
> > package: dpkg
> 
> > #The issue:
> > 
> > User wants to know what files were installed by running
> > 'apt install <package>'
> 
> I don't think this is a clear enough use case, because this could be
> an interest in only the packages that actually got installed anew,
> and not any already installed dependencies that the system already
> had. What about alternative dependencies (as in "foo | bar")? What
> about dependencies satisfied by virtual packages provided by multiple
> real packages, etc. What about packages which are only Recommended
> but apt might install depending on how it is configured?
> 
> What about the matching query on package removals? (Which dpkg would
> be unable to answer as it would no longer have the list of removed
> files.)
> 
> > He can run 'dpkg -L <package>' but that only shows files installed
> > by the metapackage itself, not its dependencies.
> 
> TBH, it does not seem like this request belongs in dpkg itself, as it
> does not have enough information to properly answer the question that
> is supposedly being asked, as mentioned above, because that depends on
> the previous dpkg state and how a frontend like apt is configured.
> 
> > He can also use 'apt-cache depends --recurse', but that produces huge
> > files with too much info, not just the files added.
> 
> To get only the list of Depends and Pre-depends one can use
> «apt-cache depends --important --recurse», but apt by default will
> install Recommends, so that will depend on how it is configured.
> 
> Given the above, I'm inclined to close this as a wontfix.

Closing this now.

Thanks,
Guillem

--- End Message ---

Reply via email to