On 3 August 2010 12:50, Timothy Rice <[email protected]> wrote:

> > What might be a way forwards here, assuming you want to keep the old files
> > around, would be to change the group-name for files that become orphaned
> > through a package upgrade to have a versioned group name.
>
> That would get on my nerves. It just isn't "neat" enough :-)

For me, multiple usernames just for a few orphaned files from an earlier
version of Package X is not "neat" either: but that's just me.

Are you sure one really wants to keep the old files around anyway though?

I would be looking to bin them, in which case there's only one username
required after the upgrade, and in which case having the version in the
username, and needing to change it which each upgrade, seems overkill,
which is where I came in.

I could see a case for changing the ownership of existing files to a
versioned username ahead of the upgrade, which would then be done
as the generic userrname.

Afterwards, it'd just be a matter of cleaning up any files that remain with
the versioned name, which would make identifying them explicit.

But why choose a versioned username - you might as well use "tmp-pkg"
or some such placeholder - in that case?

> The hint's first choice (group name = user name) isn't really using the
> group information **for** anything. The group information in this case is
> redundant and unhelpful. The advantage regarding setuid that you point out
> is not annulled by the scheme I've suggested.

I hear some of the "redundant" charge: not sure I agree with "unhelpful".

Other than setuid cases, where it helps, I can't see that it helps or hinders?

I have only ever used the first scheme so won't comment on the other two


I think the key for me is: unless there's a desire to keep old, orphaned by the
package maintainers, files around after an upgrade, then there's no need to
have versioned package usernames, but that's just me I guess.

Kevin
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Reply via email to