Re: Option to allow packages from backports but without forcing it
On Sun, Jul 12, 2020 at 15:23, Thorsten Glaser <t.glaser@tarent.de>
wrote:
On Sun, 12 Jul 2020, Pirate Praveen wrote:
But gitlab is not in buster-backports
Then I don’t understand the problem.
gitlab is in buster-fasttrack, but buster-fasttrack is not self
contained, it needs buster-backports.
apt/aptitude -t buster-backports install gitlab/buster-fasttrack
does not work.
Why?
The same reason as apt/aptitude -t buster-backports install gitlab
apt-get install gitlab/buster-fasttrack even should work,
in that case. Depends/Breaks would suffice to make it
select the right packages from the right suites.
It is not working, hence asking for ideas.
For example, ruby-nokogiri is available in buster-backports (built
with
ruby 2.5) and buster-fasttrack (built with ruby 2.7).
Wasn’t the rule that a package may only be in one of them,
and that it’s only eligible for fasttrack when it’s not in
backports?
fasttrack's rules are not set in stone, it is evolving based on the
needs of packages like gitlab. The reason for having to do this is
because the ruby team does not want to maintain ruby 2.7 in backports
even though it qualify for backports because it can break packages
already in stable.
# apt policy ruby-nokogiri
ruby-nokogiri:
Installed: (none)
Candidate: 1.10.9+dfsg-1+fto10+1
Version table:
1.10.9+dfsg-1+fto10+1 500
500 https://fasttrack.debian.net/debian
buster-fasttrack/main amd64 Packages
1.10.9+dfsg-1~bpo10+1 100
100 https://deb.debian.org/debian buster-backports/main
amd64 Packages
1.10.0+dfsg1-2 500
500 http://deb.debian.org/debian buster/main amd64 Packages
Well here you also run into the problem that apt prefers
the newest package.
Why is that a problem? We need the newer version here.
It also looks like buster-fasttrack is not set up correctly:
its policy value is 500, not 100 (NotAutomatic: yes and
ButAutomaticUpgrades: yes).
That is because we don't really expect the packages to be upgradable to
next stable version (because these packages will not be in any stable
release).
Looking at the fasttrack documentation, it also tells users
to use a buster-backports repository from the fasttrack.debian.net
site, which is also all kinds of wrong.
Why? There are times when we can't have a package in official backports
immediately (transitions, backports-new). This is temporary repository.
These gets removed when they are accepted in official backports.
But the installability problem has a different cause:
[…]
Depends: ruby-faraday (>= 0.17.3~) but 0.15.4-3~bpo10+1 is
to be installed
[…]
$ apt-cache policy ruby-faraday
ruby-faraday:
Installed: (none)
Candidate: 0.13.1-2
Version table:
0.15.4-3~bpo10+1 100
100 http://mirror.lan.tarent.de/debian buster-backports/main
amd64 Packages
0.13.1-2 500
500 http://mirror.lan.tarent.de/debian buster/main amd64
Packages
0.9.2-3 500
500 http://mirror.lan.tarent.de/debian stretch/main amd64
Packages
This package simply is not available in the version required.
Because you did not add buster-backports suite.
# apt policy ruby-faraday
ruby-faraday:
Installed: (none)
Candidate: 0.13.1-2
Version table:
0.17.3-1~bpo10+1 100
100 https://fasttrack.debian.net/debian buster-backports/main
amd64 Packages
0.15.4-3~bpo10+1 100
100 https://deb.debian.org/debian buster-backports/main amd64
Packages
0.13.1-2 500
500 http://deb.debian.org/debian buster/main amd64 Packages
bye,
//mirabilos
--
«MyISAM tables -will- get corrupted eventually. This is a fact of
life. »
“mysql is about as much database as ms access” – “MSSQL at
least descends
from a database” “it's a rebranded SyBase” “MySQL however was
born from a
flatfile and went downhill from there” – “at least jetDB
doesn’t claim to
be a database” (#nosec) ‣‣‣ Please let MySQL and MariaDB
finally die!
Reply to: