[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: semi-virtual packages?



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 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"?

        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. 

> 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.

> 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. 

>> 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?

> 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. 

        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). 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 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.

        Could we be less confrontational, perhaps?

> 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.

        I guess you have succeeded eminently, then.

        manoj

-- 
You are destined to become the commandant of the fighting men of the
department of transportation.
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: