[Fedora-packaging] Need advice on using a new directory in the root hierarchy

Ralf Corsepius rc040203 at freenet.de
Mon Jun 4 02:49:51 UTC 2012


On 06/02/2012 07:40 AM, Michel Alexandre Salim wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 06/02/2012 11:45 AM, Toshio Kuratomi wrote:
>> On Sat, Jun 02, 2012 at 11:09:46AM +0700, Michel Alexandre Salim
>> wrote:
>>> As such, it seems that this is a justifiable case for creating a
>>> new directory under root  -- cf. the introduction of /run, as
>>> documented in Fedora 15's release notes[4]:
>>>
>>> This change is compliant with the Filesystem Hierarchy Standard,
>>> which allows distributions to create new directories in the root
>>> hierarchy as long as there is careful consideration of the
>>> consequences.
>>>
>>> I posit that compatibility with a vast amount of pre-built
>>> binaries, and the reduced usefulness of the tool without this
>>> compatibility (anyone who has used MacPorts, with its lack of
>>> pre-built binaries, would sympathize).
>>>
>>> Should I create an FPC ticket for this?
>> Yes, but unless the FPC is willing to abandon the FHS I think it
>> will be a close or negative vote.
>>
> OK, I probably shouldn't try then if there's almost no chance of it
> going through. So this should be something for RPM Fusion, I suppose?

RPM Fusion is supposed to follow the Fedora packing rules.
=> This would not be an option for you.

>> Also, there was talk about whether Fedora should allow alternate
>> package managers (meaning system-wide package managers that work
>> with formats that are not rpm ie: dpkg or apt-get that works with
>> .debs [not the apt-get rpm port].)  I do not remember what the
>> decision was there.
I don't recall such discussion. I recall a general discussion 
interaction with some language's "installers" (Python, ruby (gems), etc).

With regard to them, there had been consensus of "all installers" must 
properly interact with rpm", esp. must all installations they excercise 
be reflected into rpm's db.

IMO, the same consideration applies to "alternative package installers".
In particular, do several, separate, independent installation db's not 
make any sense.

>> Lastly, the release notes do not accurately reflect the reason that
>> the FPC chose to allow /run.
Well, ... unfortunately, yes.

I can live with this decision (It's not worth to make a fuzz about it), 
nevertheless, I consider this decision to be a serious mistake and would 
be highly in favor of it being revisited and be reverted.

Ralf



More information about the packaging mailing list