Le ven. 5 avr. 2019 à 17:07, Pierre Fourès <pierre.fou...@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.
