Re: How could I install ecryptfs-utils on Buster
Le ven. 5 avr. 2019 à 17:07, Pierre Fourès <pierre.foures@gmail.com> a écrit :
> I would like a « simple and easy » solution.
In the hope it may help someone or at least give some food for
thoughts, here is what I eventually did to fix my issue.
I use apt-cacher-ng. I first thought to log in the instance and grab
the package and install it manually via dpkg (and do this with all it
dependencies). My point was to revert back to what buster was before
the removal of this package. However, the versions of package
ecryptfs-utils are currently the same between stretch, buster and sid.
So the .deb file will stay in the pool of the mirrors at least until
debian stretch goes out from the LTS it hasn't entered yet. This is a
long time frame. I then thought to use a combo of wget and dpkg to
install it straight from the pool. I also identified this package
could also be removed from the pool if this package is updated in
debian stretch while still in the stable life-cycle of stretch and
included in a point release. There is not a big time-frame for it, and
if this would happen, I believe ecrypfs-utils would probably be
reintegrated in buster-backports. I then take the bet that it won't be
updated before stretch goes oldstable (which should only be some
months ahead) or if it is, ecryptfs should appears in
buster-backports. If not, I will have to find an other solution.
With that being said, I devised my solution relying on the fact that
ecryptfs utils will stay in stretch in order to stay in the pool. But,
instead of fiddling with wget and dpkg, wouldn't it be more efficient
to use the power of apt to install it and all of its dependencies ? I
went back to my idea to use the repository of stretch into the
instance of buster. With the rules of precedence set in apt, I
(almost) never can be able to mix my distrib with software from
stretch. The problem is sensible when mixing with forward versions of
Debian, but, to my understanding, can't occur when mixing with
backward versions of Debian. Please, correct me if I'm wrong.
If I use apt, it will look for the most recent version and take
precedence on the version of buster. But if it appears a package isn't
in the buster repository (like ecryptfs-utils), it might find it in
the stretch repository, and install it from there. While doing so, it
will look for the dependencies and install all of them. But while
looking to satisfy the dependencies, it will find them in the buster
repository and install the most recent of them. I'm then granted I
won't have an installation who slowly slip toward not being 100%
buster except one package or so.
I did the test and all went as expected. I got ecryptfs-utils being
installed with the four of its dependencies. One of them, keyutils, is
in 1.5.9-9 in stretch and 1.6.6 in buster. As expected, apt installed
the one from buster. After the install, I then had precisely the same
packages installed in the same versions as what it was before
ecryptfs-utils was removed from buster. This kind of satisfy my «
simple and easy » solution requirement.
I just have one minor consideration about this. It was about adding
stretch-security on top of it. In the case ecryptfs would be updated,
I would like to take this upgrade. But I'm not sure this would play
well regarding other packages being in the same version number between
stretch and buster. Thinking when stretch will be in LTS, a package
could get an update earlier in stretch than in buster. The package
would then be installed from the stretch-security updates instead of
the pending one in buster. Then when the buster package get released,
how would this all converge ? I'm not sure how all this would goes,
and I'm not willing to experiment, so I decided to leave off the
stretch-security repository and just use the buster one. Doing so,
only ecryptfs-utils (and its companion lib) won't get any security
updates. I will then manually look for updates on ecryptfs package and
decide what to do from there. I indeed subscribed to bug #765854 and
also to the tracker for package ecryptfs-utils for this purpose. I
will be notified by email if anything moves there before it hit the
repositories. If this would ever would happen, I guess I will have to
adjust this current fix for this situation. A simple update wouldn't
seem to be wise without more careful inspection of the situation. Thus
I guess I'm not loosing much on not having ecrypfs automatically
handled by security updates.
I hope I didn't missed anything who could jeopardize the situation,
but I'm pretty confident with all this, and happy how it turned out.
Indeed, I just added two lines before the 'apt-get install
ecryptfs-utils' command, here they are, simple and easy :
> echo "deb http://http.debian.net/debian/ stretch main contrib" >> /etc/apt/sources.list
> apt-get update
Off course, I very welcome comments on all this if I overlooked something.
Regards,
Pierre.
Reply to: