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

Michel Alexandre Salim salimma at fedoraproject.org
Mon Jun 4 04:37:46 UTC 2012


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 06/04/2012 09:49 AM, Ralf Corsepius wrote:
> 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.
> 
Thanks. They do allow akmods though, so I'm not sure exactly where
they draw the line. But I think I should take into account the
possibility that it won't get in there either, and maintain a separate
repo for it (*not* on fedorapeople, of course)

>>> 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.
> 
Python's doesn't, I thought? There is some integration but it's the
other way around -- that RPM-provided Python modules are "seen" by
easy_install and pip.

> 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.
> 
I personally think they could have just used /var/run for that ...

Thanks,

- -- 
Michel Alexandre Salim
Fedora Project Contributor: http://fedoraproject.org/

Email:  salimma at fedoraproject.org  | GPG key ID: A36A937A
Jabber: hircus at jabber.ccc.de       | IRC: hircus at irc.freenode.net

()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPzDuXAAoJEEr1VKujapN6M6IH/1O0riyX4Dhl8Uo4+nPRBz48
52MuTsMkAlG0TuiTod0PhDhShsgIRbDcSBBDErc2mZiV0SKIBAT3OszzG9QfXB6G
7GZ1ktJ86UcRxm+EtdTclp6aVEtpc9VrfcKBy4Ua0OlNPViPzqXi3+IRT75Fz3ZV
nwhbkaTBeSwGS6pOQZ3qBqdn/pFZT/GQaZBK7QEGSo4kjVgqrOKVS1almmFJ4Y/B
JIg1Kec7HyAXzASbdjU+bBTQqw1giPQD5eICqx+vaO+3Pg3N3aDsE5aRNdyVMj1Y
Gecn7WLJ6VXA9Nlld6zoqGYuwX6xgialZfXunVW/+t4wFWR6OuKQ49AhVZzkNBg=
=Nu9R
-----END PGP SIGNATURE-----


More information about the packaging mailing list