Re: semi-virtual packages?
Someone wrote: If you actually need to make this sort of response, could you do the rest of us a favor and not do so publicly? Ya, you're right. Sorry. My frustration got the better of me. - Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: semi-virtual packages?
On Wed, 26 Sep 2007 04:04:33 -0600, Bruce Sass [EMAIL PROTECTED] said: On Tue September 25 2007 09:22:02 am Manoj Srivastava wrote: On Tue, 25 Sep 2007 02:36:24 -0600, Bruce Sass [EMAIL PROTECTED] said: On Sun September 23 2007 03:08:59 pm Manoj Srivastava wrote: On Sun, 23 Sep 2007 14:26:29 -0600, Bruce Sass [EMAIL PROTECTED] said: [I've cut a lot of duplication. If I cut something which doesn't get addressed below, feel free to bring it back.] 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. Haha. There is nothing wrong with the assumption. That is kinda like saying pylint is incorrect for spitting out errors when given a correct perl program. You ignored a sign which would have taken you down a different path, and now appear to be complaining because the path you ended up on took you to the wrong place---neither the sign or paths are incorrect, you just didn't pay attention and got lost. Hmm? You assumed, and I quote there are no such situations which would not already have a virtual package. Since there are situations where there is no virtual package, it certainly seems to me that the assumption you made is invalid. If your assumption is correct, then I have missed something somewhere. 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 see why it would need to be universal, one size stuff often doesn't fit anyone very well and it is not like being universal is pervasive and this would stand out as a wart. If we are not talking about a policy to be made, and you are only talking about an opt in scheme for some orphan files, then indeed, I have nothing to add to the conversation. manoj -- algorithm, n.: Trendy dance for hip programmers. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: semi-virtual packages?
On Thu September 27 2007 01:33:21 am Manoj Srivastava wrote: On Wed, 26 Sep 2007 04:04:33 -0600, Bruce Sass [EMAIL PROTECTED] said: Hmm? You assumed, and I quote there are no such situations which would not already have a virtual package. Since there are situations where there is no virtual package, it certainly seems to me that the assumption you made is invalid. That is not correct, what I assumed was: a, no, to the above [question] What you quoted is not a primary assumption (as you've been treating it as), it is based on a condition having been met. If your assumption is correct, then I have missed something somewhere. The bit you're still missing is the first part of the question you didn't answer: Is there any situation where ownership has collided IOW: if the file shared by many packages isn't having ownership problems there is no need to consider it (no point trying to fix something that is not broken, eh). I don't see why it would need to be universal, one size stuff often doesn't fit anyone very well and it is not like being universal is pervasive and this would stand out as a wart. If we are not talking about a policy to be made, and you are only talking about an opt in scheme for some orphan files, then indeed, I have nothing to add to the conversation. s/some/all but a few/I suspect - Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: semi-virtual packages?
On Thu, 27 Sep 2007 08:08:49 -0600, Bruce Sass [EMAIL PROTECTED] said: The bit you're still missing is the first part of the question you didn't answer: Is there any situation where ownership has collided IOW: if the file shared by many packages isn't having ownership problems there is no need to consider it (no point trying to fix something that is not broken, eh). The start of this thread was a rant about not loose files floating around in /etc; not necessarily about whether these files in themselves had ownership problems (whtever that means). Here is the original context. Note how you say the problem (actually, design flaw) is about current tools do not catch files created by Maintainer scripts? Nice to see the design flaw has become stuff that is not broken and does not have to be fixed. That is all I cared about, really. manoj On Fri, 21 Sep 2007 03:25:23 + (UTC), Oleg Verych (Gmane) [EMAIL PROTECTED] said: 19-09-2007, Bruce Sass: [] I like this too. Finding what a package has just installed is one of the biggest holes in Debian right now, IMO. I have to use dpkg -L to figure this out, and that's just too crude to be a real solution. Too crude? That's a simple command, easily found in a relevant manpage. In true Unix fashion, its output can be easily piped to other commands. What's crude about it? It doesn't catch files created by Maintainer scripts? This is the design flaw in those scripts (even in whole package management). -- You know how to win a victory, Hannibal, but not how to use it. Maharbal Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: semi-virtual packages?
On Thu September 27 2007 05:38:53 pm Manoj Srivastava wrote: On Thu, 27 Sep 2007 08:08:49 -0600, Bruce Sass [EMAIL PROTECTED] said: The bit you're still missing is the first part of the question you didn't answer: Is there any situation where ownership has collided IOW: if the file shared by many packages isn't having ownership problems there is no need to consider it (no point trying to fix something that is not broken, eh). The start of this thread was a rant about not loose files floating around in /etc; not necessarily about whether these files in themselves had ownership problems (whtever that means). Here is the original context. Note how you say the problem (actually, design flaw) is about current tools do not catch files created by Maintainer scripts? Nice to see the design flaw has become stuff that is not broken and does not have to be fixed. That is all I cared about, really. Oleg considers it a design flaw, I have stated no such opinion and didn't even include his statement to that effect in my reply. Why would you bring it up... grasping at straws, perhaps. The original context I was responding to, and which you jumped in on, is this: - On Sat, 22 Sep 2007 03:46:26 -0600, Bruce Sass [EMAIL PROTECTED] 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. manoj - You then proceeded to demonstrate that you: have trouble reading, following arguments, keeping track of what your own use case actually is, and using logic. You are now finishing up with misquotes and misrepresentation of anothers position. Do you wonder why you get in so many fights and pointless arguments. :-/ Bye-bye, and I wish you luck in whatever little fantasy world you've constructed for yourself. - Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: semi-virtual packages?
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 [you forgot to finish this thought, sorry if I miss the point...] Packages would need to manage their own creations, just as it is now. What would change is that if a script triggers the addition of a generated path to a package's .list, it will no longer need to manually remove that path when it gets purged. So, a little less work for most(?) Maintainer scripts which generate files! 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. no harm, no foul? - 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. A good thing, ya? - 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. Probably, but since you don't want yours (/etc/kernel-img.conf, I'm assuming) to be owned by a package it is immaterial wrt to deciding if the scheme is feasible or not. The only ones which count are those which would want to be owned except an owner can not be determined. - 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? No. The package would be real, the only difference would be that instead of being downloaded it would be created locally. 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 [I suspect that is a much stronger statement than you intended, or perhaps an incomplete thought. If taken as written, assuming the only thing missing is a period, it flies in the face of history (see: http://lists.debian.org/debian-policy/1998/04/msg00089.html) and at least a few bugs (#85960, #213907, #359203)... it borders on absurdity, imo.] If a package wants a file it creates to be an orphan it can continue to do so,... 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. ...if a file has no choice but to be an orphan then, shrug, at least it is no worse off than it was. The only problem I see wrt what cases are being properly handled is if there are a lot of files which want to be owned but for some reason can't be assign ownership. That would indicate the solution isn't good enough, at least on its own. - Bruce
Re: semi-virtual packages?
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 [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
semi-virtual packages?
On Sat September 22 2007 10:21:43 pm Manoj Srivastava wrote: On Sat, 22 Sep 2007 03:46:26 -0600, Bruce Sass [EMAIL PROTECTED] 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: semi-virtual packages?
On Sun September 23 2007 11:00:58 am Manoj Srivastava wrote: On Sun, 23 Sep 2007 04:13:41 -0600, Bruce Sass [EMAIL PROTECTED] said: On Sat September 22 2007 10:21:43 pm Manoj Srivastava wrote: On Sat, 22 Sep 2007 03:46:26 -0600, Bruce Sass [EMAIL PROTECTED] 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? Why are you asking that. You provided the use case---a file shared by many packages but really owned by none. 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? 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. 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. 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. 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. 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. 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. - Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: semi-virtual packages?
On Sun, 23 Sep 2007 14:26:29 -0600, Bruce Sass [EMAIL PROTECTED] 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 [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
