Re: Bug#273734: education-common: con't fulfill the Recommends on !i386
On Mon, Oct 04, 2004 at 11:04:05PM -0400, Kevin Mark wrote: > Hi Adrian, > if 'boot-loader' was not a real package (not sure if it requires a new > catagory or if it fits under meta or virtual) and then when you did: > apt-get install boot-loader > it (dpkg or apt -- not sure) checked your ARCH and then install the one that > 'provides: boot-loader' and matches your ARCH > where > Package: lilo > Provides: boot-loader > Architecture: i386 and > Package: silo > Provides: boot-loader > Architecture: sparc > > And would install lilo on i386 and silo on sparc. The idea is that they > both provide similar functionality but are arch dependant. > > Not sure what to do if more than one package can satisfy the 'provides'. The problem in this specific case was, that a binary-all package wanted to have grub installed instead of lilo. Yes, you can solve some problems using virtual packages like boot-loader. No, you can't solve all problems using virtual packages like boot-loader. > Hope this is not too OT but I'm trying to understand under the hood. > -Kev cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Re: Bug#273734: education-common: con't fulfill the Recommends on !i386
Steve Langasek wrote: > > - Getting the packages into testing, which was previously apparently > > impossible. > > - Avoiding the common problem with task packages that if you remove > > one package in the task, you have to remove the task package as > > well, since its dependecies are then broken. > > - As part of the phasing out of the old reason for the old-type task > > packages; selection of the packages in these tasks are not handled at > > the tasksel level by recommends fields ayway, but by tasksel package > > lists in the education-tasks package. The new task packages will > > mostly be useful for post-install sysadmin and upgrade purposes. > > The first two of these advantages would no longer be present if britney > treated Recommends the same way as it treats Depends, which is why I > ask. No, only the first point could be affected by changes to britney. In the second point I'm talking about removing a package from an installed system. > I'm confused about your third point, here; the current debian-edu > package represents the "new"-style task packages? The current debian-edu packages are something of a midway point between how task packages were traditionally done and how I hope they'll be done in the future. > What is clear to me is that the intended semantics of the > education-common are that it install the Recommends: if available, and > ignore them if they're not. Yep. -- see shy jo signature.asc Description: Digital signature
Re: Bug#273734: education-common: con't fulfill the Recommends on !i386
On Mon, Oct 04, 2004 at 05:17:50PM +0200, Adrian Bunk wrote: > On Sun, Oct 03, 2004 at 11:16:56PM -0400, Kevin Mark wrote: > > On Mon, Oct 04, 2004 at 12:03:48AM +0200, Adrian Bunk wrote: > > > > > > Assume a package would recommend grub which is only available on i386. > > > There are two cases: > > > - grub is required only on i386 > > > Recommends: grub | not+i386 > > > (or some similar treatment during package building) > > > - grub is really required > > > in this case, the pacakge should be available only on i386 > > > > > > > Gruesse, > > > > > > cu > > > Adrian > > > > > Hi, would a virtual package help? > > grub=i386 silo=sun > > boot-loader=grub|silo > > where boot-loader is a virtual package > > and grub and silo are packages that fulfill the requirement of > > boot-loader > > No. > > E.g. this wouldn't solve the problem from #273734 since lilo is also a > boot-loader. > > > -Kev > > cu > Adrian Hi Adrian, if 'boot-loader' was not a real package (not sure if it requires a new catagory or if it fits under meta or virtual) and then when you did: apt-get install boot-loader it (dpkg or apt -- not sure) checked your ARCH and then install the one that 'provides: boot-loader' and matches your ARCH where Package: lilo Provides: boot-loader Architecture: i386 and Package: silo Provides: boot-loader Architecture: sparc And would install lilo on i386 and silo on sparc. The idea is that they both provide similar functionality but are arch dependant. Not sure what to do if more than one package can satisfy the 'provides'. Hope this is not too OT but I'm trying to understand under the hood. -Kev -- (__) (oo) /--\/ / ||| * /\---/\ ~~ ~~ "Have you mooed today?"... signature.asc Description: Digital signature
Re: Bug#273734: education-common: con't fulfill the Recommends on !i386
On Mon, Oct 04, 2004 at 07:56:06AM +0200, Andreas Barth wrote: > * Steve Langasek ([EMAIL PROTECTED]) [041004 00:40]: > > On Sun, Oct 03, 2004 at 02:53:57PM -0400, Joey Hess wrote: > > > We would still list everything in recommends. There were many reasons why > > > I > > > moved all contents of these tasks to the recommends field, including: > > > - Getting the packages into testing, which was previously apparently > > > impossible. > > > - Avoiding the common problem with task packages that if you remove > > > one package in the task, you have to remove the task package as > > > well, since its dependecies are then broken. > > > - As part of the phasing out of the old reason for the old-type task > > > packages; selection of the packages in these tasks are not handled at > > > the tasksel level by recommends fields ayway, but by tasksel package > > > lists in the education-tasks package. The new task packages will > > > mostly be useful for post-install sysadmin and upgrade purposes. > > The first two of these advantages would no longer be present if britney > > treated Recommends the same way as it treats Depends, which is why I > > ask. > I think missing Recommends should _not_ be tracked by britney, but > "just" being RC-buggy (about the same level as missing build > dependencies). Britney's job is to help make it easier for us to ensure that testing is in a constantly releasable state. I think it *should* keep as many RC bugs out of testing as possible; as shown by many recent 11th-hour bug submissions, we haven't been very successful at keeping other kinds of RC-buggy package relationships out. If britney can be used to address these errors proactively, I believe it would be beneficial; the question is whether it actually *can*, or if requiring fulfilled build-dependencies throughout a development cycle would make testing too rigid. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
