Re: semi-virtual packages?
On Sun, 23 Sep 2007 04:13:41 -0600, Bruce Sass <bmsass@shaw.ca> said:
> On Sat September 22 2007 10:21:43 pm Manoj Srivastava wrote:
>> On Sat, 22 Sep 2007 03:46:26 -0600, Bruce Sass <bmsass@shaw.ca> 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?
> 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).
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?
manoj
--
If you ever drop your keys into a river of molten lava, let'em go,
because, man, they're gone.
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Reply to: