> > If om gets kicked out of the archive, ingen could very easially have a > > > > Provides: om > > > > line, which has mostly the same effect as a dummy package. Dummy packages > > are best avoided if not really needed. > > Surely this would only pull in om/ingen if another package depends on > it. The only app that might fall into that category would be Smack drum > machine, which is not packaged AFAIK. (? I may be confused about this ?)
I tried a quick test with the "Provides: ladspa-plugin" : # aptitude install ladspa-plugin Reading package lists... Done Building dependency tree Reading state information... Done Reading extended state information Initializing package states... Done Reading task descriptions... Done Building tag database... Done No packages will be installed, upgraded, or removed. 0 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded. Need to get 0B of archives. After unpacking 0B will be used. Reading package lists... Done Building dependency tree Reading state information... Done Reading extended state information Initializing package states... Done Reading task descriptions... Done Building tag database... Done # apt-get install ladspa-plugin Reading package lists... Done Building dependency tree Reading state information... Done Package ladspa-plugin is a virtual package provided by: vcf 0.0.5-5 tap-plugins 0.7.0-2 swh-plugins 0.4.15-0.1 omins 0.2.0-5 mcp-plugins 0.3.0-4 ladspa-sdk 1.1-6 cmt 1.15-3.1 caps 0.4.2-1 blop 0.2.8-5 You should explicitly select one to install. E: Package ladspa-plugin has no installation candidate It looks like apt-get looks at the provides, and aptitude does not. Joost -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
