semi-virtual packages?

[Bruce Sass <bmsass@shaw.ca>]

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:
> >> 21-09-2007, Bruce Sass:
> >> > On Thu September 20 2007 09:25:23 pm Oleg Verych (Gmane) wrote:
> >> >> 19-09-2007, Bruce Sass:
> >> >> > I'm hoping the dpkg "triggers" functionality Ian Jackson has
> >> >> > been working on will help solve that wart though.
> >> >>
> >> >> How exactly?
> >> >
> >> > Exactly? I don't know. I haven't followed what is happening
> >> > close enough.
> >> >
> >> > Basically, it allows a package to toss up a flag saying, `I'm
> >> > here and <something> needs to be done.' It may require some
> >> > convention and a little more infrastructure, but that is close
> >> > to letting a package say, `add these paths to the list of paths
> >> > which I control.'
> >>
> >> Sure. But i thought, we are talking about finding/listing of
> >> generated files.
> >
> > 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.

Is there any situation where ownership has collided, and a virtual 
package is/(could) not (be) Provide:-ed?

[Realizing that discussion about wild ideas is far from sublime, I 
decided to put some thoughts to rhyme, hope it works this time.]

[assuming a, "no", to the above... ya, both question and poetry :D ]

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,
and assuming dpkg triggers can be used for this kind of thing:

A package generating a file which is most properly owned by a virtual 
package it Provides: could trigger, `add these paths to the list of 
paths owned by <virtual package>.' Same game as above, different 
package name.

- dpkg (controlled code) would need to create an entry in the DB (i.e., 
status, info/*, ...) for these semi-virtual packages, and remove/purge 
them when the last package providing a virtual package is 
removed/purged.

- Since these semi-virtual packages would only exist if a real package 
was providing them there should be no problem with respect to 
dependency calculations if they actually exist in the DB.

- I suspect a new Provided-by: field in the DB could help dpkg keep 
track of what's up during failed upgrades, and if not, the frontend 
tools would probably like to be able to convey the info onto users.


- Bruce