Hi, 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 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=885878#44 deduplicate from Colin Watson https://launchpadlibrarian.net/14818796/234486.diff 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" (https://www.debian.org/releases/stable/amd64/apds03.html.en) 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 ? Regards, JH Chatenet
