[Aptitude-devel] Bug#964916: Option to allow packages from backports but without forcing it
praveen at onenetbeyond.org
Sun Jul 12 17:00:00 BST 2020
On Sun, Jul 12, 2020 at 15:23, Thorsten Glaser <t.glaser at tarent.de>
> 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.
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
>> 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
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
>> 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
> 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
> 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
> 0.9.2-3 500
> 500 http://mirror.lan.tarent.de/debian stretch/main amd64
> This package simply is not available in the version required.
Because you did not add buster-backports suite.
# apt policy ruby-faraday
100 https://fasttrack.debian.net/debian buster-backports/main
100 https://deb.debian.org/debian buster-backports/main amd64
500 http://deb.debian.org/debian buster/main amd64 Packages
> «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!
More information about the Aptitude-devel