Hi,
the default mediawiki install does not allow image uploads (on puprose) and requires the user to adjust permissions (#231542). Perhaps there is a better way to deal with this in mediawiki, but the general issue came up:
Suppose a package requires the user/admin to change permissions on a folder to enable some functionality. How do we deal with that? A package upgrade resets the permissions and there is no way to tell rpm that this folder is "%configdir".
A workaround would be to not own this folder which is very ugly, violates guidelines, leaves orphaned folders behind, and is just not The Right Solution. Which is The Right Solution?
(again in the context of "folder permission change really required by a package", I hope mediawiki's issue may be worked around, so don't stick to this example)
On Thursday 15 March 2007, Axel Thimm wrote:
A workaround would be to not own this folder which is very ugly, violates guidelines, leaves orphaned folders behind, and is just not The Right Solution. Which is The Right Solution?
Well, if I understand correctly, considering that fiddling with the permissions of this dir is required for the purpose of enabling mediawiki to create files in it, and those created files will not be owned by the mediawiki package in any case and will be left behind on package erase (ditto the dir if there are files in it, dir owned or not), I don't think leaving it unowned would be anywhere near a cardinal sin either.
In fact, it sounds much better to me than changing permissions of packaged files - package upgrades reset permissions of files, %config or not. Ditto rpm --setperms/--setugids. Which is why IMHO the answer to the original question is "don't even try to require changing permissions/ownership of packaged files, find a better way around the problem".
Marking the dir as %ghost and experimenting how it behaves then could also be of (mostly academic) interest.
On Thu, Mar 15, 2007 at 03:16:12PM +0200, Ville Skyttä wrote:
On Thursday 15 March 2007, Axel Thimm wrote:
A workaround would be to not own this folder which is very ugly, violates guidelines, leaves orphaned folders behind, and is just not The Right Solution. Which is The Right Solution?
Well, if I understand correctly, considering that fiddling with the permissions of this dir is required for the purpose of enabling mediawiki to create files in it, and those created files will not be owned by the mediawiki package in any case and will be left behind on package erase (ditto the dir if there are files in it, dir owned or not), I don't think leaving it unowned would be anywhere near a cardinal sin either.
In fact, it sounds much better to me than changing permissions of packaged files - package upgrades reset permissions of files, %config or not. Ditto rpm --setperms/--setugids. Which is why IMHO the answer to the original question is "don't even try to require changing permissions/ownership of packaged files, find a better way around the problem".
So, you suggest to not ship the folder at all? Or create it in %post to evade the folder entering the manifest?
Marking the dir as %ghost and experimenting how it behaves then could also be of (mostly academic) interest.
Well, %ghosting is for having something in the manifest w/o shipping it. I want the opposite :)
On Thursday 15 March 2007, Axel Thimm wrote:
So, you suggest to not ship the folder at all? Or create it in %post to evade the folder entering the manifest?
Not at all, if it can't be done right out of the box.
Marking the dir as %ghost and experimenting how it behaves then could also be of (mostly academic) interest.
Well, %ghosting is for having something in the manifest w/o shipping it.
Not only that; if a %ghost'ed file didn't exist when one installed a package, but exist when that package is erased, it will be removed. You seemed to be concerned about the dir being unowned and not removed on erase - %ghosting would help with it being owned, and in some cases the removal as well.
What I don't know is whether ownership/modes of %ghosted but present files are reset on package install/upgrade or not.
packaging@lists.fedoraproject.org
-
Axel Thimm -
Ville Skyttä