Minor correction to the approved MPI draft
by Susi Lehtola
Hi,
I just corrected the wording on the MPI Guideline from
"NO library configuration (in /etc/ld.so.conf.d) MUST be made"
to
"library configuration (in /etc/ld.so.conf.d) MUST NOT be made"
which is clearer and has the same meaning (it was in the FESCo
discussion [1]). I hope that this updated version can be moved to the
Packaging Guidelines along with the other guidelines approved today.
[1]
http://meetbot.fedoraproject.org/fedora-meeting/2009-08-14/fedora-meeting...
17:20:21 <jds2001> #topic FPC Items
17:20:26 <jds2001> .fesco 241
17:20:29 <jds2001> MPI?
17:20:42 <jds2001> There was something on the page that was confusing to
me, let me find it.
17:21:24 <jds2001> ahh - Each MPI build of shared libraries SHOULD have
a separate -libs subpackage for the libraries (e.g. foo-mpich2-libs). As
in the case of MPI compilers, NO library configuration
(in /etc/ld.so.conf.d) MUST be made.
17:21:25 <nirik> +1 here for MPI. It makes sense to me...
17:21:59 <jds2001> that seems to be as "library configuration
in /etc/ld.so.conf.d MUST NOT be made"
--
Jussi Lehtola
Fedora Project Contributor
jussilehtola(a)fedoraproject.org
14 years, 8 months
Re: Fwd: Django plugin naming
by Toshio Kuratomi
On 08/10/2009 11:52 AM, Diego Búrigo Zacarão wrote:
> Steve, I'm forwarding it for Toshi and the Fedora Packing List as well. :)
>
> 2009/8/10 Steve 'Ashcrow' Milner <smilner(a)redhat.com>
>
>> On 10/08/09 15:00 -0300, Diego Búrigo Zacarão wrote:
>>>
>>> I guess python-$MODULENAME is a good idea for Django apps, once
>>> $MODULENAME
>>> don't suppress the 'django-' part. Otherwise it would be a problem, mainly
>>> because
>>> those apps/addons are named (usually) like django-$SOMETHING and
>>> $SOMETHING
>>> (also usually) is a very simple name, that would conflict with other
>>> possibles python
>>> apps with the same name. One example of it could be the app
>>> 'django-openid'[1],
>>> that would conflict with the 'python-openid' library.
>>>
>>
>> Excellent point. It's too bad there isn't an official location for
>> Django plugins like /path/to/python/sitelib/django/thirdparty/$NAME.
>> Since there isn't one, I wouldn't think it's a good idea to use that
>> ourselves else we would end up with projects that only worked on
>> Fedora :-(.
>>
>> I don't know if that has been thought about or not, but maybe it would
>> be a good thing to bring up to upstream.
>>
>> If it's doing to be like python-$MODULENAME (i.e. python-django-tagging),
>>> it's Ok with me.
>>> I just need someone helping me with it on those sub-packages, as I'm not a
>>> packager in
>>> reality (yet :)).
>>>
>>
>> We shouldn't change the package name ... for instance, if the django
>> application was called tagging and would normally be put into the
>> python site-path as such I don't think it would be very smart of us to
>> rename it to django_tagging without upstream making the same change.
>> Again, we would run into code that only worked on Fedora. Calling the
>> package python-django-tagging and NOT changing the actual module name
>> would seem to be a good idea.
>>
+1
I talked with ivazquez yesterday on IRC (he's done quite a few of the
plugin modules) and we arrived at this conclusion:
Even though the packages live in site-packages and can be imported by
python, unless they're being imported by django, django plugins don't do
much of anything. Since the django package is named Django rather than
python-django, it makes more sense to leave out hte python-* for now.
Many of the upstream names are django-SOMETHING. Like django-tagging.
So for us to call the package django-tagging is following what upstream
is doing. A few packages (like "south" http://south.aeracode.org) don't
have django in their upstream name. For these, we should prepend with
the Django package name: Django-south since they are plugins to the
Django package. Since most of the plugins use lowercase in their
upstream name, it's a good idea to Provide: django-south as well.
Sound reasonable?
-Toshio
14 years, 8 months
Django plugin naming
by Toshio Kuratomi
Django is a python web framework. Currently it seems like the naming of
django and its subpackages do not follow any of our naming guidelines.
I'd like to clarify this and write down the proper format of the names
for the future.
So, in November 2006, the subject of what to call the Django package
came up. I said that the name should be python-django but the package
was entered into the repository as Django instead:
https://www.redhat.com/archives/fedora-extras-list/2006-November/msg00268...
There are plugins to the Django package being reviewed and they're
currently being approved as django-$PLUGINNAME.
There's several factors that keep this format from meeting any of the
current Guidelines:
* grandfathered Django package name.
- Due to this, it could be argued that addons to Django could be
named Django-$PLUGINNAME rather than python-django-$PLUGINNAME.
* lowercasing of the Django name.
- lowercase matches better with the actual module name
- lowercase is something we like in general as mixed case is
something that has broken cornercases (for instance, package Foo and
package foo, would conflict with each other in several of our tools) and
confused users (Why doesn't "yum install django" work?)
An additional factor that I need input from the Django (and Django
plugin) maintainers to answer is how tied to Django the plugins are. I
know there is a movement to make more things accessible outside of their
parent frameworks (for instance, zope has been split into a huge number
of smaller packages). If that's the case with the django plugins as
well, they really should be named python-$MODULENAME rather than
Django-$MODULENAME.
Note that the TurboGears precedent that the Django maintainer used when
packaging Django only follows the main package. TurboGears addons are
named with the python- prefix.
Here's the current plugins repoquery found for me:
django-authopenid
django-contact-form
django-evolution
django-notification
django-pagination
django-sct
django-tagging
-Toshio
14 years, 8 months
Packaging games?
by Ryan Rix
Hello all,
I am attempting to package IVAN (http://ivan.sf.net) as my first
contribution to Fedora outside of bug reports. With the help of the fedora-
kde guys I mostly understand writing specs and the packaging process in
general. I have just a few nagging questions that are keeping me from
submitting this for review right now:
1) When packaging a game, is it safe to assume that the user who will be
running this is a member of the games group?
2) If not, what is the best method of applying setgid to the /usr/bin/ivan
in the spec file?
3) Is it acceptable by review standards to have a zero length file in the
rpm, even if rpmlint moans about it? It's a high score file under /var/games
that apparently cannot be created by the main executable. I tried patching
the source to create the file automatically, but I couldn't figure out how;
it's probably has something to do with permissions. The mode on the fopen
call was already "wb" which 'should' work...
4) Are packaging guidelines for games spelt out anywhere?
Thanks for your time,
Ryan
--
Ryan Rix
(623)-826-0051
What you end up with, after running an operating system concept through
these many marketing coffee filters, is something not unlike plain hot
water.
-- Matt Welsh
http://hackersramblings.wordpress.com | http://twitter.com/phrkonaleash
XMPP: phrkonaleash(a)gmail.com | MSN: phrkonaleash(a)yahoo.com
AIM: phrkonaleash | Yahoo: phrkonaleash
IRC: PhrkOnLsh(a)irc.freenode.net/#srcedit,#teensonlinux,#plugaz and
countless other FOSS channels.
14 years, 8 months
ldconfig -X in scriptlets?
by Miroslav Lichvar
Hi,
I've recently come across an ldconfig issue when updating libraries.
Apparently rpm doesn't always call ldconfig in %postun, I've filed bug
#513224 for that. It doesn't seem to be a real bug though.
The problem is that when ldconfig in %post is called, there are both
old and new libraries on disk. If ldconfig thinks that the older
library is newer (according to some internal sorting function) it
will replace the packaged symlink with one that points to the other
library. After the older library is removed, next ldconfig call will
change the symlink back. But is this correct? If %post scriptlet had a
code that used the library, it would actually used the older one.
ldconfig has -X option which disables the symlink modifications, so
I'd like to propose adding the option to recommended %post (and
possibly also %postun) scriptlet to avoid such surprises.
Comments?
--
Miroslav Lichvar
14 years, 8 months