|
On Tue September 25 2007 09:22:02 am Manoj Srivastava wrote: > 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: [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. > > 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. I think I see where you are getting confused though. On the one hand you seem to be saying there are files that should be orphans (e.g.: /etc/kernel-img.conf), yet you criticize the scheme for not being universal. Why does not being universal "not seem to be much good" if you actually don't want universality because you know of files which shouldn't or can't be owned by a package? You did the same sorta thing earlier. Your initial post seemed to be *faulting* a scheme to append paths to <package>.list for not addressing "the case of a file shared by many packages but really owned by none", yet later on you state: "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". Why should a scheme to add files generated by a package to its own <package>.list need to address the case of files without packages that don't want to be owned? The way I see it, from a logical pov, you can resolve the contradictions by giving up the premise of universality. Once you do that, the opt-in nature of the mechanism takes care of /etc/kernel-img.conf and like, trivially (nothing more trivial than doing nothing, eh). > What use case _is_ "knowing what package a file belongs to" a part of? "dpkg -S" (and any programs which use it) , cruft, idle curiosity, ... > >> 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? status quo > > 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. I knew that. It is just more info which may help resolve the problems. > 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. [ignoring that kernel-img.conf doesn't have to opt-in, so handling that situation could be as it is now] Uhm, that is only a problem if a file is not owned by a package. This thread has been about a mechanism which could add such orphan files to a package so they can be listed, search for, removed, purged, or whatever else one (admin or program) does with that relationship. Maybe this wasn't as clear as I thought: A semi-virtual package is virtual to Debian and real on a user's system, so an admin always has the option of manually remove/purge-ing whatever they end up owning. During normal operation that sort of thing would be handled automatically as the packages Provide:-ing the semi-virtual ones get manipulated. > 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 [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 |