Bug#557296: debootstrap: Use dpkg-deb instead of ar when available
Hello Guillem,
On Sun, Nov 22, 2009 at 4:51 AM, Guillem Jover <guillem@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 <elendil@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: otavio@ossystems.com.br http://www.ossystems.com.br
Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br
Reply to: