>> Joey Hess <[EMAIL PROTECTED]> writes: > Jason Gunthorpe wrote: > > Tasks are bettered handled through some kind of non-package means. I've > > long said we need to determine some kind of meta-package scheme (a > > 'package' whose only purpose is to logically group other packages). > > How is introducing some basterdized form of package (perhaps it's just > an entry in the Packages file or something), going to allow us to > address problems like aj was talking about, where one of the things it > depends on is removed from debian, and it needs to be updated?
in the one bit you trimmed out, Jason said: > Logically, the way to represent this is to have package declare > their membership in a grouping. This could be done via the override > file so as to maintain a centralized authority like we have no with > the task packages. Groups and user preferences about them could be > stored seperate to the status file. This wouldn't be that difficult. Just add a 'Task:' field to the packages. Have the default be non-existant (empty). In order to add information to the overrides file (and not put the load on the ftp people's shoulders) have a 'maintained overrides', that is, a bit of the overrides file maintianed just like a normal package (e.g., task-games.overrides). In this way you satisfy aj's concerns (changing this would be as short as editing a text file, signing and uploading) and provide the functionality of task-packages, provided UI tools support this field. One problem here is that sooner or later someone will start thinking of such sick things as 'local overrides'. Marcelo