On Sun September 23 2007 11:00:58 am Manoj Srivastava wrote: > On Sun, 23 Sep 2007 04:13:41 -0600, Bruce Sass <[EMAIL PROTECTED]> said: > > On Sat September 22 2007 10:21:43 pm Manoj Srivastava wrote: > >> On Sat, 22 Sep 2007 03:46:26 -0600, Bruce Sass <[EMAIL PROTECTED]> said: > >> > On Sat September 22 2007 12:16:18 am Oleg Verych (Gmane) wrote: > >> > > >> > It is not feasible (imo) to automatically find files created by > >> > maintainer scripts. Having packages append <package>.list > >> > themselves would (afaict) require they know too much about > >> > dpkg's internal operation, and all packages generating files > >> > would need to implement the algorithm. > >> > > >> > However, maintainer scripts can easily pass a list of generated > >> > paths on to a shared piece of code which dpkg controls. > >> > "triggers" looks like it could be the mechanism by which a > >> > package flags that it has generated files, and by which dpkg > >> > exerts control. > >> > >> But this does not address the case of a file shared by many > >> packages but really owned by none. > > > > True, but... Since such a file is owned by none, it can not be > > owned by anyone. The same solution would apply, if we could create > > a package for it on the fly. > > We can create any number of dummy packages on the fly, but > what is the use case we are trying to solve here? Why are we adding a > virtual package, having package provide the virtual package, given > that this virtual package does not provide any functionality, and so > no other package is going to depend on it?
Why are you asking that. You provided the use case---"a file shared by many packages but really owned by none." I have written nothing about "adding a virtual package", and the functionality of the existing virtual packages which I would manifest is obvious---provide a home for the files "shared by many packages but really owned by none." > > Perhaps virtual packages need to have a real presence on the system > > when such a situation exists. > > > > If you are willing to go for that, > > I might be willing to go for that if there was a clear > statement of benefit gained, what use case we are satisfying, and if > there were convincing arguments that other solutions are not a better > fit than trying to shoe horn dpkg -L to be the solution to whatever > use case we are attempting to solve (this is no longer the original > use case presented -- I-do-not-know-where-the-documentation-is). Huh. You provided the case, and the benefit should be obvious---and if it is not then why did you bring up addressing, "the case of a file shared by many packages but really owned by none"? WTF does "shoe horn dpkg -L" have to do with what I wrote? That sounds a lot like the wedging we used to do back in the early 80's when the OS was in ROM and it wasn't practical to rewrite it. I would hope Debian can do better than such hacks. Ya, this is different from "I-do-not-know-where-the-documentation-is", but then that should not be surprising since I'm not addressing that. I did not even realize that is what the thread's originator was asking until he clarified by answering someone who appears to have had the same misunderstanding as I about what he was asking. > So, can we start over, and have a clear problem statement, > alternate solutions (does this move into tripwire space?), and then > decide what the preferred solution is? "tripwire", again, WTF. What I mentioned no more moves into "tripwire space" than installing or upgrading any other package does. So, it would be handled by whatever mechanism currently does that. Surely you don't think the OS should cater to whatever deficiencies some app running on it has. I don't see any need for myself to start over. I answered Oleg's question, and addressed your case. You, on the other hand: seem to have forgotten what you wrote; failed to answer the one question I asked; and brought up irrelevant stuff like, "shoe horn dpkg -L", and "tripwire space." I think you need to start over. Ya know, I thought that if I was really very lucky there was an outside chance of getting a, `posts on -devel rarely make me smile, but yours seems to have walked that mile', but if you really want to be pissy and obtuse... I can do that too. - Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
