|
|
|
@ -2070,19 +2070,16 @@ sub run_setup() {
|
|
|
|
# for authentication, use the keyrings from the host
|
|
|
|
# for authentication, use the keyrings from the host
|
|
|
|
print $conf "Dir::Etc::Trusted \"$options->{apttrusted}\";\n";
|
|
|
|
print $conf "Dir::Etc::Trusted \"$options->{apttrusted}\";\n";
|
|
|
|
print $conf "Dir::Etc::TrustedParts \"$options->{apttrustedparts}\";\n";
|
|
|
|
print $conf "Dir::Etc::TrustedParts \"$options->{apttrustedparts}\";\n";
|
|
|
|
if ($options->{variant} ne 'apt') {
|
|
|
|
# apt considers itself essential. Thus, when generating an EDSP document
|
|
|
|
# apt considers itself essential. Thus, when generating an EDSP
|
|
|
|
# for an external solver, it will add the Essential:yes field to the apt
|
|
|
|
# document for an external solver, it will add the Essential:yes field
|
|
|
|
# package stanza. This is unnecessary because we compile the set of
|
|
|
|
# to the apt package stanza. This is unnecessary for any other variant
|
|
|
|
# packages we consider essential ourselves and for the 'essential' variant
|
|
|
|
# than 'apt' because in all other variants we compile the set of
|
|
|
|
# it would even be wrong to add apt. This workaround is only needed when
|
|
|
|
# packages we consider essential ourselves and for the 'essential'
|
|
|
|
# apt is used with an external solver but doesn't hurt otherwise and we
|
|
|
|
# variant it would even be wrong to add apt. This workaround is only
|
|
|
|
# don't have a good way to figure out whether apt is using an external
|
|
|
|
# needed when apt is used with an external solver but doesn't hurt
|
|
|
|
# solver or not short of parsing the --aptopt options.
|
|
|
|
# otherwise and we don't have a good way to figure out whether apt is
|
|
|
|
print $conf "pkgCacheGen::ForceEssential \",\";\n";
|
|
|
|
# using an external solver or not short of parsing the --aptopt
|
|
|
|
|
|
|
|
# options.
|
|
|
|
|
|
|
|
print $conf "pkgCacheGen::ForceEssential \",\";\n";
|
|
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
close $conf;
|
|
|
|
close $conf;
|
|
|
|
|
|
|
|
|
|
|
|
# We put certain configuration items in their own configuration file
|
|
|
|
# We put certain configuration items in their own configuration file
|
|
|
|
@ -2488,27 +2485,8 @@ sub run_download() {
|
|
|
|
dryrun => $options->{dryrun},
|
|
|
|
dryrun => $options->{dryrun},
|
|
|
|
},
|
|
|
|
},
|
|
|
|
);
|
|
|
|
);
|
|
|
|
} elsif ($options->{variant} eq 'apt') {
|
|
|
|
|
|
|
|
# if we just want to install Essential:yes packages, apt and their
|
|
|
|
|
|
|
|
# dependencies then we can make use of libapt treating apt as
|
|
|
|
|
|
|
|
# implicitly essential. An upgrade with the (currently) empty status
|
|
|
|
|
|
|
|
# file will trigger an installation of the essential packages plus apt.
|
|
|
|
|
|
|
|
#
|
|
|
|
|
|
|
|
# 2018-09-02, #debian-dpkg on OFTC, times in UTC+2
|
|
|
|
|
|
|
|
# 23:39 < josch> I'll just put it in my script and if it starts
|
|
|
|
|
|
|
|
# breaking some time I just say it's apt's fault. :P
|
|
|
|
|
|
|
|
# 23:42 < DonKult> that is how it usually works, so yes, do that :P (<-
|
|
|
|
|
|
|
|
# and please add that line next to it so you can
|
|
|
|
|
|
|
|
# remind me in 5+ years that I said that after I wrote
|
|
|
|
|
|
|
|
# in the bugreport: "Are you crazy?!? Nobody in his
|
|
|
|
|
|
|
|
# right mind would even suggest depending on it!")
|
|
|
|
|
|
|
|
@dl_debs = run_apt_download_progress({
|
|
|
|
|
|
|
|
APT_ARGV => ['dist-upgrade'],
|
|
|
|
|
|
|
|
dryrun => $options->{dryrun},
|
|
|
|
|
|
|
|
},
|
|
|
|
|
|
|
|
);
|
|
|
|
|
|
|
|
} elsif (any { $_ eq $options->{variant} }
|
|
|
|
} elsif (any { $_ eq $options->{variant} }
|
|
|
|
('essential', 'standard', 'important', 'required', 'buildd')) {
|
|
|
|
('essential', 'apt', 'standard', 'important', 'required', 'buildd')) {
|
|
|
|
# 2021-06-07, #debian-apt on OFTC, times in UTC+2
|
|
|
|
# 2021-06-07, #debian-apt on OFTC, times in UTC+2
|
|
|
|
# 17:27 < DonKult> (?essential includes 'apt' through)
|
|
|
|
# 17:27 < DonKult> (?essential includes 'apt' through)
|
|
|
|
# 17:30 < josch> DonKult: no, because pkgCacheGen::ForceEssential ",";
|
|
|
|
# 17:30 < josch> DonKult: no, because pkgCacheGen::ForceEssential ",";
|
|
|
|
@ -2982,8 +2960,14 @@ sub run_install() {
|
|
|
|
my $options = shift;
|
|
|
|
my $options = shift;
|
|
|
|
|
|
|
|
|
|
|
|
my @pkgs_to_install = (@{ $options->{include} });
|
|
|
|
my @pkgs_to_install = (@{ $options->{include} });
|
|
|
|
|
|
|
|
if ($options->{variant} eq 'extract') {
|
|
|
|
|
|
|
|
error "must not be called with variant extract";
|
|
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
if (none { $_ eq $options->{variant} } ('custom', 'essential')) {
|
|
|
|
|
|
|
|
push @pkgs_to_install, 'apt';
|
|
|
|
|
|
|
|
}
|
|
|
|
if ($options->{variant} eq 'buildd') {
|
|
|
|
if ($options->{variant} eq 'buildd') {
|
|
|
|
push @pkgs_to_install, 'build-essential', 'apt';
|
|
|
|
push @pkgs_to_install, 'build-essential';
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if (any { $_ eq $options->{variant} }
|
|
|
|
if (any { $_ eq $options->{variant} }
|
|
|
|
('required', 'important', 'standard')) {
|
|
|
|
('required', 'important', 'standard')) {
|
|
|
|
@ -7084,14 +7068,10 @@ considered for selection of C<Essential:yes> packages.
|
|
|
|
|
|
|
|
|
|
|
|
=item B<apt>
|
|
|
|
=item B<apt>
|
|
|
|
|
|
|
|
|
|
|
|
The B<essential> set plus apt. This variant uses the fact that B<apt> treats
|
|
|
|
The B<essential> set plus apt.
|
|
|
|
itself as essential and thus running C<apt-get dist-upgrade> without any
|
|
|
|
It is roughly equivalent to running mmdebstrap with
|
|
|
|
packages installed will install the B<essential> set plus B<apt>. If you just
|
|
|
|
|
|
|
|
want B<essential> and B<apt>, then this variant is faster than using the
|
|
|
|
--variant=essential --include="apt"
|
|
|
|
B<essential> variant and adding B<apt> via C<--include> because all packages
|
|
|
|
|
|
|
|
get installed at once. The downside of this variant is, that if it should
|
|
|
|
|
|
|
|
happen that an B<essential> package is not installable, then it will just get
|
|
|
|
|
|
|
|
ignored without throwing an error.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
=item B<buildd>
|
|
|
|
=item B<buildd>
|
|
|
|
|
|
|
|
|
|
|
|
@ -7420,15 +7400,11 @@ the B<setup> step. This can be disabled using B<--skip=update>.
|
|
|
|
=item B<download>
|
|
|
|
=item B<download>
|
|
|
|
|
|
|
|
|
|
|
|
In the B<extract> and B<custom> variants, C<apt-get install> is used to
|
|
|
|
In the B<extract> and B<custom> variants, C<apt-get install> is used to
|
|
|
|
download all the packages requested via the B<--include> option. The B<apt>
|
|
|
|
download all the packages requested via the B<--include> option. In the
|
|
|
|
variant uses the fact that libapt treats the C<apt> packages as implicitly
|
|
|
|
remaining variants, apt patterns are used to find the C<Essential:yes> packages
|
|
|
|
essential to download only all C<Essential:yes> packages plus apt using
|
|
|
|
from the native architecture. If I<SUITE> is a non-empty string, then only
|
|
|
|
C<apt-get dist-upgrade>. In the remaining variants, all Packages files
|
|
|
|
packages from the archive with suite or codename matching I<SUITE> will be
|
|
|
|
downloaded by the B<update> step are inspected to find the C<Essential:yes>
|
|
|
|
considered for selection of C<Essential:yes> packages.
|
|
|
|
package set as well as all packages of the required priority. If I<SUITE> is a
|
|
|
|
|
|
|
|
non-empty string, then only packages from the archive with suite or codename
|
|
|
|
|
|
|
|
matching I<SUITE> will be considered for selection of C<Essential:yes>
|
|
|
|
|
|
|
|
packages.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
=item B<mount>
|
|
|
|
=item B<mount>
|
|
|
|
|
|
|
|
|
|
|
|
|
