Re: semi-virtual packages?
On Sun September 23 2007 03:08:59 pm Manoj Srivastava wrote:
> On Sun, 23 Sep 2007 14:26:29 -0600, Bruce Sass <bmsass@shaw.ca> said:
> > On Sun September 23 2007 11:00:58 am Manoj Srivastava wrote:
> >> 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."
>
> Yup, I provided that use case. I see no reason to create a
> virtual package to implement the use case I provided.
>
> I ask again, do you have a use case which led you down the
> path of proposing a virtual package?
I say again, I have not proposed creating any virtual packages...
> > 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."
...what I did mention was:
> >> > Perhaps virtual packages need to have a real presence on the
> >> > system when such a situation exists.
I ask again, with slightly different words:
Is there any "case of a file shared by many packages but really owned by
none" which does not already have a virtual package associated with it?
Unfortunately, "I see no reason to create a virtual package to implement
the use case I provided.", sounds like a "yes" but it doesn't really
answer the question. I can't find a case so I can not demonstrate
something which doesn't exist, you think you've found a case so you
should be able to describe it more fully than "I see no reason".
Everything I described after that point was under: assuming a, "no".
If you would have answered "yes" to that question then you should have
ignored (at least from the perspective of solving the case you
mentioned) everything after that point because it was clearly not
applicable to your use case.
It would have then been a good idea to describe why your use case
results in a "yes" because I was, equally clearly, not able to think of
a situation including your use case which should not already involve a
virtual package. If it was otherwise I would not have assumed "no", ya.
> >> > 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"?
>
> No, my use case merely says that we should be able to have a
> situation where we have a configuration file that does not belong to
> a package. And yes, I see the benefits of this use case immediately.
<aside>
it is stuff like this which tends to act like `pee in my cornflakes'
What does the "No" you wrote connect with:
- the fact that you provided the use case,
in spite of your, "Yup, I provided that use case.", statement
- the implication that benefits should be obvious to you,
since you provided the case
- is it an answer to the question itself,
even though the answer should be in the form of an explanation
- is it a denial of your own words,
which I quoted verbatim
- a claim that I've twisted the meaning of the quote somehow,
even though the only thing missing is: "But this does not address..."
?????
<shrug>
</aside>
OK. So you should be pleased I have not said anything which would take
that possibility away, or force an action from abstainers. If a
Maintainer script wants to create an orphan file it would simply
neglect to trigger after creating it.
> > 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.
>
> I do not follow.
I noticed.
>
> > 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.
>
> I ask again, what use case are you addressing? The use case I
> proposed does not need a virtual package.
Yours. The scheme I described was under the written assumption there are
no such situations which would not already have a virtual package.
Why would you think any of that scheme was applicable to the case you
were thinking of if it is a case in which there is no virtual package?
> >> 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.
>
> Again?
having trouble following again, OK...
In the "dpkg -L" instance you are apparently criticizing the scheme
based on some fantasy implementation you have which involves, "trying
to shoe horn dpkg -L". Now, since I never mentioned any implementation
details, and especially not "dpkg -L"'s code ('cause that like a sounds
pretty hack-ish way to go about it, imo), my first response is WTF is
he going on about.
In the "tripwire" instance, you should re-read the rest of the
paragraph. I don't think I can explain it any better than that. If you
still have trouble understanding why bringing up apparently irrelevant
concerns would cause someone to think "WTF"... <shrug>
[but this may become clearer later on, so hang on a minute]
> > 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.
>
> What are these deficiencies? I see a situation, currently,
> where some files belong to a particular package. They are shipped in
> the .deb. Other files do not belong to the package, and are handled
> separately.
I don't know, you are the one who seems to think tripwire could be a
concern. I am simply pointing out that any program which would be a
concern because it can't handle a system upgrade must somehow be
deficient, and they should find their own solution.
> Now, I suppose you are only worried about files in /etc and
> sch; and not files under /var (no way to associate a lot of those
> files with the packages that contain the entities that created them).
I wasn't worried at all about where the files created by Maintainer
scripts would reside, just that they were being created and there was a
virtual package which could be given a real presence to claim ownership
of them via info/<package>.list.
I had considered that files under /etc which are owned by a semi-virtual
package may need special handling, but could not think of a case for
which simply not-purging the previous version before upgrading to the
next wouldn't be an adequate solution. Since that is how dpkg currently
behaves I saw no need to bring it up. The same would apply to files
under (say) /usr/share/doc/<semi-virtual package>.
With respect to the, "no way to associate", problem:
I looked at it from the other direction, so-to-speak.
- New installations would be fine.
- Upgrades should naturally result in ownership of orphan files getting
sorted out as the Maintainer scripts which manage them do their thing.
Although it may be desirable to force the issue even though the code to
do so may need to be kept around for a couple of releases.
- Whether or not it "was desirable to force" would depend on how many
orphan files were expected to be left lying around after a release
cycle. Too many and Maintainer scripts should go out of their way to
ensure everything assignable to a semi-virtual package gets assigned.
- Any orphan files still left kicking around would need to be handled on
a case-by-case basis. Too many of those, "no way to associate" =
case-by-case, files and the semi-virtual package idea is likely not
good enough.
- However, since the only files I could imagine being left out of the
above transition are ones which arrive with the initial installation of
Debian, there should not be many of them.
i.e.: afaict, it probably isn't much of a problem
Whether it would be worth creating a semi-virtual package for them would
depend on how easy it was to keep track of them at creation time, or
automatically find them afterwards, I suppose. I mean, if the
infrastructure is there because it makes sense otherwise, may as well
do it even though it is just icing.
> The question is, why are we trying to assign parentage to the files
> created by maintainer scripts? Curiosity? or something else? Is the
> benefit gained worth the cost of the solution? (a virtual package
> that provides no services, and no package ever depends on, and is
> only there to have a dpkg -L listing of files).
I figured it was mostly so that "dpkg -S" would always spit out a
result, but having "dpkg -L" be as accurate as possible is desirable
too. For me those would be good enough reasons.
dpkg-repack is an interesting case.
It appears to rely on "dpkg -L" and conffiles so could miss generated
files. It is no big deal because they should be regenerated if the
repack is re-installed, but perhaps some non-conffile configs are lost
and some reconfiguration would be eliminated if they were included.
A somewhat similar situation exists with wishlist bug #359203, instead
of generated files not being saved in the repack the submitter wants to
include, "conf files non present in the original package"
(presumably /etc/*conf.d kinda stuff). A mechanism for appending paths
to a package's .list file could satisfy the request.
With both of those cases, dpkg-repack's ability to, "store the current
state of a package before you upgrade it" would be enhanced by a more
accurate "dpkg -L".
The interesting part, imo, is if any scripts will horribly break if a
file they want to generate already exists when the repack gets
re-installed ("horribly break" as in: needing a bottom up rewrite to
accommodate the new paradigm). I don't know if that is something to
worry about though.
Cruft should also benefit from packages (or admins, ala #359203) being
able to append to <package>.list (which cruft looks at directly),
fewer "unexplained files" or perhaps simpler "explain" scripts.
So, I guess we can say that in the least it would remove a couple dpkg
warts, and improve a couple other packages.
If the only or main costs as you see them are:
- a virtual package that provides no services,
- and no package ever depends on,
- and is only there to have a dpkg -L listing of files
No virtual packages being created, the semi-virtual packages will be
depended upon by the same packages which depend on the virtual package,
and having a more accurate "dpkg -L" would be be more than
simply "nice".
> Could we be less confrontational, perhaps?
I hope so.
- Bruce
Reply to: