Re: semi-virtual packages?
On Tue, 25 Sep 2007 02:36:24 -0600, Bruce Sass <bmsass@shaw.ca> said:
> 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...
Sorry, that was not clear to me.
>> > 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.
Could you please elaborate what you mean, since I obviously have
not understood you?
> 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?
Sure. /etc/kernel-img.conf, if it exists, does not belong to
anyone.
> 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".
No, that is not what I meant. What I meant was that my use case
was that there are circumstances where it is useful to have a number of
packages read a configuration file -- but none of them really wants to
own it.
> 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.
Think, for instance, of kernel image packages. Kernel image
packages come and go -- each new upstream kernel creates a whole slew
of packages. Now, if any package owned the file, and the image package
was purged -- the file would go with it. So, kernel-img.conf exists
outside of any package -- and is created by some image package postinst
in certain rare conditions, and abandoned.
>> >> > 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'
Well, the misunderstanding is with what I was presenting as my
use case (need for files to not belong to any package, in the absence
of any virtual package to tack the file on to).
You were talking of something else entirely -- I think you are
talking about upgrading a free floating conf file to a different
format, or something like that (I am still not sure)
> 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
nope.
> - the implication that benefits should be obvious to you, since you
> provided the case
nope.
> - is it an answer to the question itself, even though the answer
> should be in the form of an explanation
Err, I don't think I follow. I was asking for the benefits of
knowing which package a file belongs to, but my use case was about not
having a file belong to any package. What answer could I give?
> - 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..."
> ?????
nope.
I presented a use case "Utility of a free floating conf file"
You present a case " need to know what package file belongs to"
How does the utility of you use case get tied to the utility of
my use case?
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.
For someone complaining about lack of explanations, you are not
very forthcoming with your own.
>>
>> > 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.
Actually not. My use case is about the need of a free floating
conf file. This is not what you are describing.
> The scheme I described was under the written assumption there
> are no such situations which would not already have a virtual package.
Ah. That assumption turns out to be incorrect.
> 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?
I am not sure how to answer that. I assumed that the scheme
under discussion was going to be universal (or else it does not seem to
be much good, really -- it would still leave files around that are not
associated with anything).
> 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.
I was not aware we were talking of programs that do not handle a
system upgrade. I just thought that tripwire keeps trzck of files that
are corrupt; and wanting to know which package a file belongs to could
have been part of a systems integrity checking use case -- but that is
merely speculation on my part. What use case _is_ "knowing what package
a file belongs to" a part of?
>> 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.
And in case there is no virtual package?
> 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>.
Ah. This is not anything I was talking to.
But I see the problem: if anything were to depend on a changed
format of /etc/kernel-img.conf; there would be no pre-defined way to
manage that. No matter what you purge, that file does not go away.
What I would end up doing in that instance was to create a
Version variable in the file; and look to see if the file had a version
I could deal with, and produce a diagnostic if I did not know about
the version on disk.
In other words, the program that read the file would have to be
> 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.
Ok
> - 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.
Umm. Not if no package can take ownership.
> - 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.
If the file was meant to be lying around, it would remain so.
> - 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.
I am not sure how many there are. I am aware of one that my
packages create. I assume there might be others.
> - 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.
So you _are_ talking about creating virtual packages in some
cases?
>> 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.
If a file does not belong to any package, then it should not
> 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".
Except in this case there is no virtual package that anyone
depends on.
manoj
--
"Maybe we can get together and show off to each other sometimes."
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: