6:49 a.m.
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)
--
Axel.Thimm at ATrpms.net
8:16 a.m.
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.
9:40 a.m.
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 :)
--
Axel.Thimm at ATrpms.net
9:49 a.m.
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.
6258
days inactive
6258
days old
packaging@lists.fedoraproject.org
3 comments
2 participants
participants (2)
-
Axel Thimm -
Ville Skyttä