[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#690210: debootstrap : debian-ports support


Thank you for your message and your help to improve the
patch towards the quality standard of Debian.

There are still some questions left on the best way to 
package a debian-port support in debootstrap.

Le vendredi 20 avril à 00h 16mn 13s (+0200), Raphael Hertzog a écrit :
> On Wed, 18 Apr 2018, Hideki Yamane wrote:
> > control: tags -1 +pending
> It's not "pending" because it's not yet pushed to the official git
> repository. I don't know if you just forgot to push or if willingly kept
> it out for now...
> But please can you avoid committing intrusive changes before seeking
> reviews ?
> I know that I encouraged you to work on debootstrap but now I feel
> responsible to double check all your work because I found out (an
> non-negligible rate) of simple mistakes and discutable design decisions
> in what you submitted so far.
> >  Adjust it to current git code, could you check it, please?
> I feel really uncomfortable with this patch. It's really intrusive
> and adds tons of perl code in a codebase that was not depending
> on perl. The comment even suggests that we would need an alternative
> C implementation in case perl is not available (and that C implementation
> is not provided here). And the perl code is actually duplicating
> code from libdpkg-perl.

I am afraid debootstrap already depends on perl (it
doesn't show up in the control file as perl-base
is Essential) : it ships a perl function 'pkg_details'
inline (see file /usr/share/debootstrap/functions line 1323
in debootstrap version 1.0.97)

There is no perl in debian-installer, and a C helper is 
provided by the udeb package 'bootstrap-base' as 
/usr/lib/debootstrap/pkgdetails (debootstrap-udeb is arch:all 
and bootstrap-base is arch:any)

I followed the same path to add a debian-ports support. Surely, 
the perl code would greatly benefit from the eye of a perl 
specialist (I am not).

As far as I know, there is no C implementation of sort_pkgs
packaged in debian-installer yet (for an example of what I
have in mind, see 

deduplicate from Colin Watson 
seems to have a similar purpose - I haven't tested it yet)

Should the perl code depends on libdpkg-perl or is it bearable
to inline the needed functions ? The former avoids code duplication
with benefits in size and maintainability, the latter keeps the
dependencies to a minimum (wget, perl-base).

As far as I know, there are three main use cases of debootstrap :
1. create a debian chroot on a host running debian (or similar)
2. in debian-installer (base-installer step)
3. "to install Debian GNU/Linux from a Unix/Linux system"

Depending on libdpkg-perl is beneficial to the first use case,
and inlining the functions to the third.

> IMO the special casing for ports.debian.org architectures should be
> handled in a dedicated wrapper. And maybe debootstrap needs new features
> to make this wrapper possible.

May I ask what for new features you have in mind ?

> But I ask you to not commit this unless you get other reviews explaining
> that this change is OK despite the above comments.
> Alternatively, some sort of middle ground would be to provide a script
> dedicated to stuff hosted ports.debian.org, the main script would be
> unmodified and the hackish code would be hidden in a script that the user
> would have to request explicitly.
> Cheers,
> -- 
> Raphaël Hertzog ◈ Debian Developer
> Support Debian LTS: https://www.freexian.com/services/debian-lts.html
> Learn to master Debian: https://debian-handbook.info/get/

Is the hope of a debian-ports support in debootstrap still
(not too un)reasonable ?

JH Chatenet

Reply to: