Re: Problem with btrfs-progs package
What a neat thread to read after coming home from the pub! ;-)
On 31 May 2016 at 06:32, Dimitri John Ledkov <xnox@debian.org> wrote:
>
> FYI - I strongly do not recommend to run backports. Are there
> particular reasons and/or bugs that you do that on production systems?
> Cause it's best to cherrypick fixes for bugs and ship a proper update
> into debian updates stream without any incompatible packaging changes.
In the case of btrfs, for maximum stability and for maximally reducing
the chances of the volume blowing up or failing in a way that may or
may not be fixable using btrfs check --repair, and that may not be
recoverable using btrfs restore or any other recovery tool...upstream
strongly recommends running the latest LTS kernel plus btrfs-progs of
at least the same version and patchlevel. Latest stable kernel and
latest stable btrfs-progs are recommended for evaluating the progress
of newer experimental features, and for benchmarking purposes.
Meanwhile, officially "Btrfs is under heavy development, and is not
suitable for any uses other than benchmarking and review."
(https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/Documentation/filesystems/btrfs.txt?id=refs/tags/v4.5.5).
Meanwhile, OpenSUSE, the only distribution that is strongly pushing
btrfs provides btrfs-progs-4.5.3 for their oldest supported version
(13.2) which shipped in late 2014. It shipped with a linux-3.16.x
kernel, same as Jessie.
> On 24 May 2016 at 15:18, Uher Marek <marek.uher@t-mobile.cz> wrote:
>>
>> I detected possible problem with btrfs-progs package on our Debian GNU/Linux
>> 8.4 (jessie) servers. The issue is that the new btrfs-progs doesn’t work
>> correctly with following packages:
>>
>>
>>
>> · Snapper
>>
>> · system-storage-manager
>>
>>
>>
>> When I tried to install new btrfs-progs package (4.4.1-1.1~bpo8+1) I got
>> this warning:
>>
>>
>>
>> root@xaero:~# apt-get -u install btrfs-progs
As Gianfranco pointed out, apt-get install -t jessie-backports
btrfs-tools is the official way to install a backport.
What I find interesting about this case is that a user might opt to
install btrfs-progs directly, rather than through the btrfs-tools
dummy package.
eg: apt-get install -t jessie-backports btrfs-progs will not currently
install btrfs-tools, and does not provide btrfs-tools. This case of
"explicitly install the renamed package" is not accounted for in any
of the existing documentation, and was not discussed as a possible
issue when I looked into this on #debian-mentors. Additionally, I
believe it is probably a backport specific issue, as all packages that
depend on btrfs-tools in stretch should have their btrfs-tools
dependencies adjusted to btrfs-progs. If anyone could provide me with
a method to get reverse depends of btrfs-tools for stretch, for all
packages in the archive, I would be happy to fix them. I fixed the
D-I and partman ones, the only ones I was able to find.
But more to the point, what is the canonical method to provide
oldpackage when a user explicitly installs newpackage from backports?
The Provides control?
Cheers,
Nicholas
Reply to: