Bug#690210: debootstrap : debian-ports support
control: retitle -1 debootstrap: please support multiple suites
On 2018-04-30 09:45, Raphael Hertzog wrote:
> Hi,
>
> On Sat, 28 Apr 2018, jhcha54008 wrote:
> > 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)
>
> Ok, I missed this. Still I'm pretty sure that it's not a good
> trend to continue.
>
> > 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.
>
> A dependency on libdpkg-perl is not a good idea either. This is why I'm
> really questioning the need to for this code to be inside debootstrap
> at all.
From what I get this new dependency on libdpkg-perl or on perl code is
to be able to sort packages by version, as a package can be in both
suite in different versions. However that leads me to 2 questions:
- At least for sid, it's already possible to have a package twice in two
different versions in a single suite. How does it work currently? Does
it takes the first one, the second one, or is it a random selection?
I am not sure that the order in dak is stable though.
- If the order used by debootstrap is not random, we can probably just
"concatenate" the two Packages file in the right order to give more
priority to unreleased (or to -security, see below).
> > > 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 ?
>
> Possibly passing a pre-built "Packages" file directly. It would be the
> result of the merge that you are doing between UNRELEASED and the normal
> suite.
>
> > Is the hope of a debian-ports support in debootstrap still
> > (not too un)reasonable ?
>
> Why aren't you creating a proper suite merging the required bits on the
> server side in ports.debian.org?
>
> Maybe the tools you are using do not make it easy to implement but it's really
> something that is not hard with most of the tools (e.g. reprepro).
I am not really sure why we want to do that on the server side,
especially that we are talking about moving debian-ports to dak at some
point, so it means the work will have to be redone also for dak.
In addition to that, in the light of the recent apt issue, there is
another use case than debian-ports for supporting multiple suites.
Supporting debootstrap from both oldstable and oldstable-security
would allow to debootstrap jessie easily. Currently you need to
deboostrap jessie and then upgrade to the latest apt with the
redirection disabled. Of course you need to do that from a mirror which
doesn't use redirection (i.e. not deb.debian.org as apt from jessie
doesn't support the SRV record). As a bonus this feature could be used
in the d-i netboot images, making the installation even faster, by not
downloading and installing the packages in -security twice.
In that regard, I have retitled the bug report.
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurelien@aurel32.net http://www.aurel32.net
Reply to: