Re: Possibility for dependencies against specific kernel modules
On Sat, Nov 01, 2008 at 07:29:16PM -0400, Filipus Klutiero wrote: | Package: test | Depends: test-modules | test-source | | Package: test-modules | Depends: linux-image-2.6.26-1-powerpc | linux-image-2.6.26-1-powerpc64 | | Package: test-source Both apt and aptitude would always try to install test-modules. The problem is that neither apt nor aptitude are smart enough to find the best solution in the dependency tree, both only evaluate deps of depth 1 at one time. I don't understand why APT would always try to install test-modules. Suppose you're on lenny and you have speex installed, then APT won't propose to install vorbis-tools when you request to install abcde, despite its dependency on vorbis-tools (= 1.0beta4-1) | lame | flac | bladeenc | speex Are you saying there's a difference in your example? If so, what is it? Yes. You have speex already installed and is therefor prefered to resolve the dependency. My example was for a fresh installation without anything installed yet. Bastian -- You! What PLANET is this! -- McCoy, The City on the Edge of Forever, stardate 3134.0 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Possibility for dependencies against specific kernel modules
On Sat, Nov 01, 2008 at 09:37:50PM +0100, Frans Pop wrote: For a really neat and complete solution you'd IMO still need something like I proposed though to make the vbox ABI visible in package names, but that can probably be postponed until after Lenny. Well it is, namely the upstream version number. To be honest I'm not sure whether the ABI really changes, we might get away by relaxing the test made by the software, but that would require us to check for every update which doesn't seem a good idea either. Consequence would be that we'll need uploads of both l-m-e (to remove the vbox-modules package) and this new package. Right. *If* we can be sure that for Lenny there will not be any vbox ABI changes (which I'd think is a certainty), we could also for lenny go for a pragmatic solution: just reupload l-m-e once now (built against new vbox source) and let that migrate to testing. Which exactly happened at about the same time I send my email. So forget about the Lenny consequences for this new package. A final solution for Lenny could be to reupload 1.6.2-dfsg-6 (with epoch and possibly with added backported fixes). Given that we now have 1.6.6 modules in Sid I don't think we have to discuss this alternative anymore. The upload of the new upstream to unstable really wasn't a very good idea, and neither was requesting it to migrate to testing... See the discussion about this before. At the very least we have a strong backing from upstream to use 1.6.6 which is a bugfix release over 1.6.2. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use PostgreSQL! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re: Possibility for dependencies against specific kernel modules
On Sat, Nov 01, 2008 at 07:29:16PM -0400, Filipus Klutiero wrote: | Package: test | Depends: test-modules | test-source | | Package: test-modules | Depends: linux-image-2.6.26-1-powerpc | linux-image-2.6.26-1-powerpc64 | | Package: test-source Both apt and aptitude would always try to install test-modules. The problem is that neither apt nor aptitude are smart enough to find the best solution in the dependency tree, both only evaluate deps of depth 1 at one time. I don't understand why APT would always try to install test-modules. Suppose you're on lenny and you have speex installed, then APT won't propose to install vorbis-tools when you request to install abcde, despite its dependency on vorbis-tools (= 1.0beta4-1) | lame | flac | bladeenc | speex Are you saying there's a difference in your example? If so, what is it? Yes. You have speex already installed and is therefor prefered to resolve the dependency. My example was for a fresh installation without anything installed yet. Bastian Hum, if the problem is APT's behavior when no test* package is installed, I don't understand what problem you're talking about. Could you give an example of a non-optimal solution? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Possibility for dependencies against specific kernel modules
On Fri, Oct 31, 2008 at 07:48:41PM +0100, Frans Pop wrote: I guess one solution could be to have virtualbox-ose not depend on virtualbox-modules, but on virtualbox-ose-modules-$ABI. Building vbox modules from lme makes no real sense to me because lme is not supposed to be reupped for each new version of virtualbox. On the other hand building them with virtualbox-ose makes no sense because vbos is not supposed to be reupped for each new kernel. How about adding a new package, virtualbox-ose-modules-2.6, mirroring lme only for the virtualbox modules? This package could be handled by teh virtualbox team? I spend enough time debugging that I know lme quite well and Panthera is a member of both teams, so technically this shouldn't be a problem. I CCed debian-release to learn whether this is okay for Lenny. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use PostgreSQL! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Possibility for dependencies against specific kernel modules
Michael Meskes wrote: On Fri, Oct 31, 2008 at 07:48:41PM +0100, Frans Pop wrote: I guess one solution could be to have virtualbox-ose not depend on virtualbox-modules, but on virtualbox-ose-modules-$ABI. Building vbox modules from lme makes no real sense to me because lme is not supposed to be reupped for each new version of virtualbox. On the other hand building them with virtualbox-ose makes no sense because vbos is not supposed to be reupped for each new kernel. Sounds like a good plan. Only disadvantage is that for ABI-changing kernel updates in stable this will mean one more package to track for whoever handles those, but I'd guess that is acceptable. For a really neat and complete solution you'd IMO still need something like I proposed though to make the vbox ABI visible in package names, but that can probably be postponed until after Lenny. How about adding a new package, virtualbox-ose-modules-2.6, mirroring lme only for the virtualbox modules? This package could be handled by the virtualbox team? I spend enough time debugging that I know lme quite well and Panthera is a member of both teams, so technically this shouldn't be a problem. Consequence would be that we'll need uploads of both l-m-e (to remove the vbox-modules package) and this new package. *If* we can be sure that for Lenny there will not be any vbox ABI changes (which I'd think is a certainty), we could also for lenny go for a pragmatic solution: just reupload l-m-e once now (built against new vbox source) and let that migrate to testing. This would get rid of the current skew and still ensure that when the kernel ABI changes, vbox modules will be properly updated. As l-m-e would need to be uploaded anyway, this seems like a reasonable option to me. The cleaner repackaging could then be done early in the Squeeze cycle. A final solution for Lenny could be to reupload 1.6.2-dfsg-6 (with epoch and possibly with added backported fixes). The upload of the new upstream to unstable really wasn't a very good idea, and neither was requesting it to migrate to testing... Cheers, FJP signature.asc Description: This is a digitally signed message part.
Re: Possibility for dependencies against specific kernel modules
On Sat, Nov 01, 2008 at 08:41:46PM +0100, Michael Meskes wrote: On Fri, Oct 31, 2008 at 07:48:41PM +0100, Frans Pop wrote: I guess one solution could be to have virtualbox-ose not depend on virtualbox-modules, but on virtualbox-ose-modules-$ABI. Building vbox modules from lme makes no real sense to me because lme is not supposed to be reupped for each new version of virtualbox. On the other hand building them with virtualbox-ose makes no sense because vbos is not supposed to be reupped for each new kernel. You are solving problem 2 before problem 1. I CCed debian-release to learn whether this is okay for Lenny. You forgot -security. Bastian -- You can't evaluate a man by logic alone. -- McCoy, I, Mudd, stardate 4513.3 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Possibility for dependencies against specific kernel modules
Hi folks Because of some recent events, I thought about the possibility for packages to depend against kernel module packages. As we don't want to dictate the usage of Debian provided kernels, we need a last resort fallback to the modules source. My first solution was something like the following: | Package: test | Depends: test-modules | test-source | | Package: test-modules | Depends: linux-image-2.6.26-1-powerpc | linux-image-2.6.26-1-powerpc64 | | Package: test-source Both apt and aptitude would always try to install test-modules. The problem is that neither apt nor aptitude are smart enough to find the best solution in the dependency tree, both only evaluate deps of depth 1 at one time. I don't understand why APT would always try to install test-modules. Suppose you're on lenny and you have speex installed, then APT won't propose to install vorbis-tools when you request to install abcde, despite its dependency on vorbis-tools (= 1.0beta4-1) | lame | flac | bladeenc | speex Are you saying there's a difference in your example? If so, what is it? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Possibility for dependencies against specific kernel modules
Le vendredi 31 octobre 2008 à 12:44 +0100, Bastian Blank a écrit : Because of some recent events, I thought about the possibility for packages to depend against kernel module packages. As we don't want to dictate the usage of Debian provided kernels, we need a last resort fallback to the modules source. I think this is something good to have, but I’m skeptical about the fallback to the source. It will, in unstable and sometimes in testing or even stable, to situations where the modules are not available for a while, and the source will get installed, leaving the system in a broken state. Unless the source can use DKMS or a similar mechanism to automatically generate modules, this is not very reliable. -- .''`. : :' : 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: Possibility for dependencies against specific kernel modules
On Friday 31 October 2008 22:20:26 Josselin Mouette wrote: Le vendredi 31 octobre 2008 à 12:44 +0100, Bastian Blank a écrit : Because of some recent events, I thought about the possibility for packages to depend against kernel module packages. As we don't want to dictate the usage of Debian provided kernels, we need a last resort fallback to the modules source. I think this is something good to have, but I’m skeptical about the fallback to the source. It will, in unstable and sometimes in testing or even stable, to situations where the modules are not available for a while, and the source will get installed, leaving the system in a broken state. Unless the source can use DKMS or a similar mechanism to automatically generate modules, this is not very reliable. fwiw, I have tried to address the issue of having $module-source packages have their binary product built and installed rather transparently, you may look at the initial hackwork at: http://svn.berlios.de/svnroot/repos/fullstory/dmakms/trunk/ http://svn.berlios.de/svnroot/repos/fullstory/dmakms/trunk/debian/README.Debian It's the start of a solution for: #299727 dmakms has got technical flaws, I know, but it works well enough for my current needs (without patching existing tools such as module-assistant, which could probably do with some lovin'), maybe it could be extended and fixed up to be technically better and useful for others. Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Possibility for dependencies against specific kernel modules
Bastian Blank wrote: Because of some recent events, I thought about the possibility for packages to depend against kernel module packages. As we don't want to dictate the usage of Debian provided kernels, we need a last resort fallback to the modules source. Exactly because of the option of using custom built kernels, virtualbox does not depend on the Debian modules packages, but only recommends them (which IMO is correct: the Debian module package will be installed by default, but you can skip/remove it if you don't need it). I don't see how adding source as a fallback serves any real purpose in this particular case as you always have the option of installing source and building the module manually. But IMO we do want to have standard modules for virtualbox available in stable for the Debian kernels and not force end users to build their own kernel modules. Whether those modules should be built as part of l-m-e or not is a separate issue. Cheers, FJP signature.asc Description: This is a digitally signed message part.
Re: Possibility for dependencies against specific kernel modules
On Fri, Oct 31, 2008 at 05:07:44PM +0100, Frans Pop wrote: Bastian Blank wrote: Because of some recent events, I thought about the possibility for packages to depend against kernel module packages. As we don't want to dictate the usage of Debian provided kernels, we need a last resort fallback to the modules source. Exactly because of the option of using custom built kernels, virtualbox does not depend on the Debian modules packages, but only recommends them (which IMO is correct: the Debian module package will be installed by default, but you can skip/remove it if you don't need it). No, it is not. Recommends are only tried during the first installation, but this relation is version dependant. Bastian -- He's dead, Jim. -- McCoy, The Devil in the Dark, stardate 3196.1 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Possibility for dependencies against specific kernel modules
Bastian Blank wrote: On Fri, Oct 31, 2008 at 05:07:44PM +0100, Frans Pop wrote: Exactly because of the option of using custom built kernels, virtualbox does not depend on the Debian modules packages, but only recommends them (which IMO is correct: the Debian module package will be installed by default, but you can skip/remove it if you don't need it). No, it is not. Recommends are only tried during the first installation, but this relation is version dependant. I guess one solution could be to have virtualbox-ose not depend on virtualbox-modules, but on virtualbox-ose-modules-$ABI. But I'd really hate for any solution to this to force me to install packages I don't use or need on the system. Maybe virtualbox could also build some empty dummy modules package that has a provides which always satisfies the virtualbox-ose-modules-$ABI. signature.asc Description: This is a digitally signed message part.
