On Thu, Jan 11, 2018 at 5:53 AM, Zbigniew Jędrzejewski-Szmek <zbyszek@xxxxxxxxx> wrote: > On Thu, Jan 11, 2018 at 10:26:19AM +0000, James Hogarth wrote: >> I know this may sound fairly nasty in terms of work required to agree >> a solution but I honestly have a strong dislike to taking this >> approach. >> >> Having upgraded and freshly installed systems so different is going to >> be messy with supporting users and in many deployed environments... >> and it's not even about F26 and F27 -> F28 but what happens on an F29+ >> system? >> >> Is this workaround going to be maintained in perpetuity? Is it just >> going to cause even more confusion then? >> >> As a very simple example take a docker host that has been upgraded >> with a fresh container on it. The nobody user is going to differ >> between the two which will at a minimum cause confusion, if not actual >> issues to arise. The docker issue is if two distinct docker instances expect to access a shared filesystem on the server, or to share access to a shared filesystem on the docker server. It is precisely the same issue with any shared directory and mismatched uids or gids of any type. > This example is very unconvincing. If I have three docker images, one > with Fedora, one with Ubuntu, one with OpenSUSE, I'll have different > nobody user/group combo in each case. So expecting any sort of consistency > is unwarranted already. One would typically be aware of mismatched uids among different operating systems based docker images as a matter of default practice. Switching it between Fedora releases is likely to be a surprise. >> Sometimes you just need to "bite the bullet" on a change and accept it >> will be painful in the short term for benefit in the longer term. > Yeah, but "biting the bullet" is quite hard in this case. Somebody > elsewhere in the thread raised the case of tarred backups. People expect > to be able to restore files from a backup, always and unconditionally > and without any owner misattribution. That's why we never remove > existing users and setup.rpm does not reuse uids that stopped being > useful 10 years ago. That was me. And this claim was.... well optimistic: * People expect to be able to restore files from a backup, always and unconditionally and without any owner misattribution. Mis-attribution has *always* been an issue with backup and restoration, trust me on this one. It's why "tar" supports the "--owner-map=FILE" option. > I expect that the workaround would have to be carried for quite a > while, let's say two years, 4 releases. Hopefully by that time the > use of the old names will be much rarer, and _then_ actually removing > the workaround will be much easier. At the moment new systems stop > having the old names defined by default, pressure starts on > script/package/external-package to stop using those names. This means > that their usually starts decreasing without anybody forcefully pushing > that. > > I liked the original plan too, but I think there's too many > (legitimate) concerns about breakage to push it through. If this > was about one simple thing you need to check or do, then it'd be different, > but finding all the uses of a user is messy and complicated. > > Zbyszek If I may suggest, it's a breaking change. It needs to be dealt with as just such a change. The return-on-investment is not high, and it's not solving a critical issue required for this release. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
