Re: Bug#438665: Orphaned packages with quite some users
On Thu, Nov 01, 2007 at 07:58:29AM +, Raphael Hertzog wrote: On Thu, 01 Nov 2007, Bart Samwel wrote: Hmmm. I'd require a sponsor for that, as I'm not a DD. Raphael, would you mind sponsoring? Yeah, I can. And you could most probably quickly become DM for those packages given your good work on acpi-support. For wich values of 'quickly'? -- Yves-Alexis Perez -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#438665: Orphaned packages with quite some users
On Thu, 01 Nov 2007, Bart Samwel wrote: Luk Claes wrote: Bart Samwel wrote: 3. Regarding the toshset package: I have a working Toshiba Tecra 8200, one of the models covered by toshset. I may be biased, but as far as I'm concerned the stuff is still useful. :-) Please do adopt the toshutils and toshset packages so people don't need to reiterate the same discussion over and over again as you say yourself. Thanks already for taking care. Hmmm. I'd require a sponsor for that, as I'm not a DD. Raphael, would you mind sponsoring? Yeah, I can. And you could most probably quickly become DM for those packages given your good work on acpi-support. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#438665: Orphaned packages with quite some users
On Thu, 01 Nov 2007, Michael Biebl wrote: Given that acpi-support is going to be deprecated in favor of pm-utils/hal [1] I'd rather see acpi-support removed from the laptop-task completely. [1] https://wiki.ubuntu.com/PMUtilsSpec I'm all for this if this is possible. acpi-support has always meant to be a temporary set of hacks to make things work. Given that it's planned for next LTS release of Ubuntu it should be compatible with the Lenny schedule. Tim, what do you think of the principle ? Would you be ready to prepare such replacements package in experimental (either working directly with Ubuntu or reintegrating their work once they did it) ? Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#438665: Orphaned packages with quite some users
On Thu, Nov 01, 2007 at 03:54:44AM +0100, Bart Samwel wrote: Luk Claes wrote: Bart Samwel wrote: 3. Regarding the toshset package: I have a working Toshiba Tecra 8200, one of the models covered by toshset. I may be biased, but as far as I'm concerned the stuff is still useful. :-) Please do adopt the toshutils and toshset packages so people don't need to reiterate the same discussion over and over again as you say yourself. Thanks already for taking care. Hmmm. I'd require a sponsor for that, as I'm not a DD. Raphael, would you mind sponsoring? Bart, I'd be happy to sponsor you for those packages. As the former maintainer I'm quite familiar with both of them. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: Bug#438665: Orphaned packages with quite some users
[Bart Samwel] 2. What we may actually require is a detection system which triggers the installation of packages at installation time, based on hardware detection. The discover package got the script discover-pkginstall which will do this. I've added mapping from hardware to packages for a few that I know about, but need help to get a more complete coverage. Patches to extend the functionality is most welcome. :) Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#438665: Orphaned packages with quite some users
Bart Samwel wrote: 2. What we may actually require is a detection system which triggers the installation of packages at installation time, based on hardware detection. You should contact Petter Reinholdtsen, who has been working on a new life for the package discover to do exactly that. He gave a talk about it during Debconf: http://meetings-archive.debian.net/pub/debian-meetings/2007/debconf7/high/334_hardware_detection_options_and_solutions.ogg Cheers, FJP -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#438665: Orphaned packages with quite some users
On Thu, 1 Nov 2007 09:11:33 +0100 Raphael Hertzog [EMAIL PROTECTED] wrote: On Thu, 01 Nov 2007, Michael Biebl wrote: Given that acpi-support is going to be deprecated in favor of pm-utils/hal [1] I'd rather see acpi-support removed from the laptop-task completely. [1] https://wiki.ubuntu.com/PMUtilsSpec I'm all for this if this is possible. acpi-support has always meant to be a temporary set of hacks to make things work. Given that it's planned for next LTS release of Ubuntu it should be compatible with the Lenny schedule. Tim, what do you think of the principle ? Would you be ready to prepare such replacements package in experimental (either working directly with Ubuntu or reintegrating their work once they did it) ? I never really looked at acpi-support because for the laptops I have, I had no use for it. pm-utils now, is mostly some glue between HAL and s2disk/s2ram, all be it with possibility to hook in all kind of hacks. Reading the wiki page above, there is some functionality not present in pm-utils (yet). When this is added to pm-utils, of course I'll integrate it. I'm kind of busy right now to pick-up porting acpi-support functionality to pm-utils. And if the Ubuntu people want to do that, I'm all for it;) grts Tim signature.asc Description: PGP signature
Re: Bug#438665: Orphaned packages with quite some users
tag 438665 wontfix merge 438665 445900 thanks Clint Adams wrote: reopen 438665 quit On Wed, Oct 31, 2007 at 06:22:11PM +0100, Luk Claes wrote: That sounds like the Dependens should be a Recommends, if so please file a bug for it. It doesn't look like #438665 was actually fixed. rant OK, then I'll tag it wontfix and merge it with _yet another_ reporting of this same issue (which was also tagged wontfix), instead of closing it. Discussing this issue (including other versions of it reported about every month) has been taking up a significant part of the acpi-support maintainer load for quite some time. Raising the issue _yet again_, especially in such a high-profile forum such as this, will cause much higher-priority issues to be stalled _yet again_. I'm afraid I'll be using my spare time yet again to discuss a tiny amount of disk space instead of fixing people's laptops that don't work. To reiterate the arguments made in the various bug reports: the dependencies are currently _not a bug_, they are a _requirement_, hence the Depends. They are a necessity for the stated goal of the package: to make all laptops just work. The current state of the surrounding infrastructure simply doesn't allow for a different solution. If somebody can come up with a bit of infrastructure to fix this up that doesn't have any drawbacks, be my guest and submit a patch! :-) /rant Sorry if I sound a bit bitter, spend a couple of months in gulag acpi-support and you'll understand. ;-) I'll add a couple of actual technical notes, for those who are interested: 1. In response to this bug report, the dependencies on X clients were reduced significantly to include only the package that contains xset. This was the part of Depends that was actually superfluous, and it reduced the depends load significantly. This was the reason the bug report was closed instead of tagged wontfix. 2. What we may actually require is a detection system which triggers the installation of packages at installation time, based on hardware detection. Something like this was discussed in more detail in #445900. In the absence of a dependable non-overkill (not larger than the packages involved, not a much higher maintenance burden) system that does that, or Recommends which behaves exactly like Depends (like some package managers treat Recommends, but not all), I'd prefer to stay with plain Depends to actually get laptops which just work. Unless somebody comes up with a patch that guarantees that it doesn't break more than 1% of the hardware that we support, of course. 3. Regarding the toshset package: I have a working Toshiba Tecra 8200, one of the models covered by toshset. I may be biased, but as far as I'm concerned the stuff is still useful. :-) Cheers, Bart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#438665: Orphaned packages with quite some users
* Bart Samwel [Wed, 31 Oct 2007 21:32:57 +0100]: Hello Bart. While I understand your reasoning, it may be now the time to revisit it: or Recommends which behaves exactly like Depends (like some package managers treat Recommends, but not all), As announced in [1] and can be seen in [2], apt now will install recommends by default. And I'm not sure off hand, if not demoting your Depends to Recommends would warrant a RC bug. [1] http://lists.debian.org/debian-devel-announce/2007/08/msg0.html [2] http://packages.qa.debian.org/a/apt/news/20071023T154702Z.html HTH, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Russian roulette in bash: ((RANDOM%6)) || rm -rf ~ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#438665: Orphaned packages with quite some users
On Wed, 31 Oct 2007, Adeodato Simó wrote: * Bart Samwel [Wed, 31 Oct 2007 21:32:57 +0100]: Hello Bart. While I understand your reasoning, it may be now the time to revisit it: or Recommends which behaves exactly like Depends (like some package managers treat Recommends, but not all), As announced in [1] and can be seen in [2], apt now will install recommends by default. And I'm not sure off hand, if not demoting your Depends to Recommends would warrant a RC bug. [1] http://lists.debian.org/debian-devel-announce/2007/08/msg0.html [2] http://packages.qa.debian.org/a/apt/news/20071023T154702Z.html The problem is not so much on manually installed package but on initial installation. I'm not sure what would get installed via the laptop task if we made that a Recommends... Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#438665: Orphaned packages with quite some users
Raphael Hertzog wrote: The problem is not so much on manually installed package but on initial installation. I'm not sure what would get installed via the laptop task if we made that a Recommends... d-i can't afford to install recommends by default (best way to change that is to make all uses of recommends sane to be installed by default). So the laptop task would need to track and list the recommends. Doing something smarter like only installing given recommends on laptop hardware that can use them would also be an option. -- see shy jo signature.asc Description: Digital signature
Re: Bug#438665: Orphaned packages with quite some users
Bart Samwel wrote: tag 438665 wontfix merge 438665 445900 thanks Clint Adams wrote: reopen 438665 quit On Wed, Oct 31, 2007 at 06:22:11PM +0100, Luk Claes wrote: That sounds like the Dependens should be a Recommends, if so please file a bug for it. It doesn't look like #438665 was actually fixed. rant OK, then I'll tag it wontfix and merge it with _yet another_ reporting of this same issue (which was also tagged wontfix), instead of closing it. Discussing this issue (including other versions of it reported about every month) has been taking up a significant part of the acpi-support maintainer load for quite some time. Raising the issue _yet again_, especially in such a high-profile forum such as this, will cause much higher-priority issues to be stalled _yet again_. I'm afraid I'll be using my spare time yet again to discuss a tiny amount of disk space instead of fixing people's laptops that don't work. To reiterate the arguments made in the various bug reports: the dependencies are currently _not a bug_, they are a _requirement_, hence the Depends. They are a necessity for the stated goal of the package: to make all laptops just work. The current state of the surrounding infrastructure simply doesn't allow for a different solution. If somebody can come up with a bit of infrastructure to fix this up that doesn't have any drawbacks, be my guest and submit a patch! :-) /rant Sorry if I sound a bit bitter, spend a couple of months in gulag acpi-support and you'll understand. ;-) I'll add a couple of actual technical notes, for those who are interested: 1. In response to this bug report, the dependencies on X clients were reduced significantly to include only the package that contains xset. This was the part of Depends that was actually superfluous, and it reduced the depends load significantly. This was the reason the bug report was closed instead of tagged wontfix. 2. What we may actually require is a detection system which triggers the installation of packages at installation time, based on hardware detection. Something like this was discussed in more detail in #445900. In the absence of a dependable non-overkill (not larger than the packages involved, not a much higher maintenance burden) system that does that, or Recommends which behaves exactly like Depends (like some package managers treat Recommends, but not all), I'd prefer to stay with plain Depends to actually get laptops which just work. Unless somebody comes up with a patch that guarantees that it doesn't break more than 1% of the hardware that we support, of course. 3. Regarding the toshset package: I have a working Toshiba Tecra 8200, one of the models covered by toshset. I may be biased, but as far as I'm concerned the stuff is still useful. :-) Please do adopt the toshutils and toshset packages so people don't need to reiterate the same discussion over and over again as you say yourself. Thanks already for taking care. Cheers Luk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#438665: Orphaned packages with quite some users
Le mercredi 31 octobre 2007 à 18:05 -0400, Joey Hess a écrit : d-i can't afford to install recommends by default (best way to change that is to make all uses of recommends sane to be installed by default). So the laptop task would need to track and list the recommends. Doing something smarter like only installing given recommends on laptop hardware that can use them would also be an option. You may be interested to learn that we plan to downgrade a number of dependencies of the gnome metapackages to Recommends. If this means tracking them later on to be sure that everything needed is installed, maybe we need a way to improve the coordination between tasksel and the gnome uploads. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: Bug#438665: Orphaned packages with quite some users
Luk Claes wrote: Bart Samwel wrote: 3. Regarding the toshset package: I have a working Toshiba Tecra 8200, one of the models covered by toshset. I may be biased, but as far as I'm concerned the stuff is still useful. :-) Please do adopt the toshutils and toshset packages so people don't need to reiterate the same discussion over and over again as you say yourself. Thanks already for taking care. Hmmm. I'd require a sponsor for that, as I'm not a DD. Raphael, would you mind sponsoring? Cheers, Bart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#438665: Orphaned packages with quite some users
Josselin Mouette wrote: You may be interested to learn that we plan to downgrade a number of dependencies of the gnome metapackages to Recommends. If this means tracking them later on to be sure that everything needed is installed, maybe we need a way to improve the coordination between tasksel and the gnome uploads. tasksel doesn't use the gnome-desktop metapackage, if gnome-desktop-environment drops things to recommends I'd have to track that. -- see shy jo signature.asc Description: Digital signature
Re: Bug#438665: Orphaned packages with quite some users
Joey Hess wrote: Raphael Hertzog wrote: The problem is not so much on manually installed package but on initial installation. I'm not sure what would get installed via the laptop task if we made that a Recommends... d-i can't afford to install recommends by default (best way to change that is to make all uses of recommends sane to be installed by default). So the laptop task would need to track and list the recommends. Doing something smarter like only installing given recommends on laptop hardware that can use them would also be an option. I wouldn't mind having the packages installed in the laptop task if that fixes it. However, the laptop task currently uses the task-fields method, which AFAICT means that the dependent packages should list themselves as being part of the laptop task, something that will take quite some effort if we want to do it. That would also be a dependency inversion, with the dependencies basically saying I'm a dependency of acpi-support (and I express this by being in the laptop task). Unfortunately, AFAICT switching away from the task-fields method means explicitly listing *all* of the packages in the laptop task, which is not something we'd want to do either. Is a hybrid task-field/list method possible in tasksel? Cheers, Bart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#438665: Orphaned packages with quite some users
Bart Samwel schrieb: Joey Hess wrote: Raphael Hertzog wrote: The problem is not so much on manually installed package but on initial installation. I'm not sure what would get installed via the laptop task if we made that a Recommends... d-i can't afford to install recommends by default (best way to change that is to make all uses of recommends sane to be installed by default). So the laptop task would need to track and list the recommends. Doing something smarter like only installing given recommends on laptop hardware that can use them would also be an option. I wouldn't mind having the packages installed in the laptop task if that fixes it. However, the laptop task currently uses the task-fields Given that acpi-support is going to be deprecated in favor of pm-utils/hal [1] I'd rather see acpi-support removed from the laptop-task completely. @joeyh: do you prefer a bug against tasksel to track this issue? Cheers, Michael [1] https://wiki.ubuntu.com/PMUtilsSpec -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: Bug#438665: Orphaned packages with quite some users
Bart Samwel wrote: I wouldn't mind having the packages installed in the laptop task if that fixes it. However, the laptop task currently uses the task-fields method, which AFAICT means that the dependent packages should list themselves as being part of the laptop task, something that will take quite some effort if we want to do it. No, Task fields are added via overrides taken from tasksel. -- see shy jo signature.asc Description: Digital signature
