Hello Guillem, On Sun, Nov 22, 2009 at 4:51 AM, Guillem Jover <guil...@debian.org> wrote: > On Sat, 2009-11-21 at 18:48:51 -0200, Otavio Salvador wrote: >> On Sat, Nov 21, 2009 at 6:34 PM, Frans Pop <elen...@planet.nl> wrote: >> > On Saturday 21 November 2009, Otavio Salvador wrote: >> >> In my opinion debootstrap shouldn't work differently inside of Debian >> >> so I think we shouldn't use dpkg-deb for this. Even though it would >> >> make our life easier giving us "new features" for free it also makes >> >> much more difficult to spot possible missing features when using it in >> >> foreign distributions and I believe this is something we ought to >> >> support well. > > Yes, that's why I explicitly pointed that out in the bug report. And I > can understand the reservations. > > But then debootstrap has not supported all valid .debs for some time > now, so if ar would be only used outside Debian, it would have been > on the same situation as currently (prior to the extra compression > patch being applied).
debootstrap don't _need_ to support all features of all valid .debs but the features accepted in base packages. This doesn't mean we shouldn't add features when possible but it is not a requirement for debootstrap POV. [...] >> > That was my initial reaction as well. One thing that could count against >> > that is that in Debian Installer dpkg-deb is not available either, which >> > would probably ensure sufficient testing of that path. > > Right. Additionally an option could be added to explicitly choose the > extractor, to ease testing. This indeed is a possible solution to be easier to test it. As Frans pointed out d-i is one "tester" of "basic *nix tools backend" already. >> > I should IMO be agreed that debootstrap should never rely on features not >> > commonly available using basic *nix tools. > > Sure, and one of the features of the deb format is that it can be > handled that way if desired. But that it can be handled that way does > not mean we should not use the best tool for the job if available, and > falling back to the basic Unix tools variant otherwise. > >> Supporting dpkg-deb in this case will only add code complexity >> maintainence issues. > > Well, the refactoring patch IMO can be applied regardless of this bug > being rejected. Agreed. > And I could understand this complaint if we'd be talking about > thousands of lines of code, but the code using dpkg-deb instead of ar > is pretty small (29 lines changed in the functions file including the > chooser logic), with the dpkg-deb variant being the simpler one. :) > >> I can foresee we asking: This debootstrap failure were with it running >> inside of Debian or d-i? > > The extractor choosed could be output to avoid that kind of situation. > I can amend the patch adding that if desired. Ok, you convinced me. Could you amend the patch and send it for review? -- Otavio Salvador O.S. Systems E-mail: ota...@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
