Suggested ScriptletSnippets (icon cache) changes
by Ville Skyttä
Hello,
I'd suggest the following changes to the "GTK+ icon cache" entry in
Packaging:ScriptletSnippets:
1) Rename the entry to "Icon cache". It's not all about GTK+ but KDE as well.
2) Append " &>/dev/null" to the "touch" line in %postun. If "touch" is not
available when the package is removed, I find it more than likely that GTK+
or KDE are not there to benefit from icon cache updates any longer
either. /usr/share may also be mounted read only with %_netsharedpath.
3) Append " &>/dev/null" to the "touch" line in %post. If "touch" is not yet
available, neither should be kdelibs, and thus there is no reason to touch
the dir. kdelibs itself does a forced update in its %post. /usr/share may
also be mounted read only with %_netsharedpath. (This avoids the need to add
unnecessary "Requires(post): coreutils" to every package that installs icons
just to quiet down a pretty rare and harmless warning.)
4) Remove the -x test and --quiet option to gtk-update-icon-cache, redirect
all output (including stderr) to /dev/null. gtk-update-icon-cache may not be
installed, /usr/share may be mounted read only with %_netsharedpath, etc...
and the --quiet tells me that there was no interest in seeing g-u-i-c's
stdout anyway.
5) Wrap %post in "if [ $1 -eq 1 ] ; then ..." to take care of the initial
installation and let %postun handle package upgrade cases in order to
eliminate one touch and one g-u-i-c invocation per package upgrade. I
suppose this would be "safe enough" to do, it'd just result in possibly stale
icon caches for the duration of the upgrade transaction. (Icons change
relatively rarely, and even if they do, does this smallish stale cache window
really matter at all?)
So the scriptlets would become:
%post
if [ $1 -eq 1 ] ; then
touch --no-create %{_datadir}/icons/hicolor &>/dev/null
gtk-update-icon-cache %{_datadir}/icons/hicolor &>/dev/null || :
fi
%postun
touch --no-create %{_datadir}/icons/hicolor &>/dev/null
gtk-update-icon-cache %{_datadir}/icons/hicolor &>/dev/null || :
14 years, 9 months
guideline for OnlyShowIn?
by Rex Dieter
Per:
"Base KDE applications (e.g. ksysguard) should have OnlyShowIn=KDE"
https://bugzilla.redhat.com/show_bug.cgi?id=481739
Prompted me to try to come up with a good/simple guideline when it is and is
not appropriate to use OnlyShowIn. Problem is, I couldn't, not easily or
quickly anyway.
I thought I'd start on the packaging list first, any thoughts?
-- Rex
14 years, 10 months
Intro and wiki info
by susan_lists＠ties.org
Greetings,
I thought I should introduce myself to the packaging list and devel list.
I'm here to help with documentation in general and packaging related wiki
pages specifically. This includes the Packaging:, PackageMaintainers/*, and
PackagingDrafts/* pages of the wiki. My immediate tasks include helping with
page naming and categories to aid with searches. I am also available to
assist with any proofreading.
My $dayjob is mostly teaching and mostly for Red Hat (RHCE and RHCA
classes). I've been *nix user and admin and instructor for years but I am
fairly new as contributer. I have started out helping with the Fedora Docs
Project and after meeting several people at FUDConF11, accepted the lead on
the docs team side for the packaging docs. It is really a liaison position
between the docs team and the packaging team and other contributors to
packaging documentation. In addition to the renaming, categorizing, and
proofreading, I am sure I will be helping with moving the Packaging
Guidelines to the CMS when we decide on a system and I have DocBook
experience to assist if any of the pages move to XML for other publishing.
>From a docs side, the first thing that needs to occur is some renaming and
categorization. Since it is a wiki and it is easy to undo changes, I am
going to dig in add some categories and then start some page renaming. I
won't be offended if anything gets undone but I hope that those who have
worked so hard to get the pages where they are will also jump in with some
suggestions.
Here are some links that will help explain what needs to occur:
https://fedoraproject.org/wiki/Help:Wiki_structure - This page explains
page naming, namespaces, and categories.
https://fedoraproject.org/wiki/User:Ianweller/Wiki_tip_of_the_week - The
first week is about moving pages (preview available now)
For example the current page [[PackageMaintainers/MaintainerResponsibility]]
would not currently be found in a search for either "package" or
"maintainers" because the mediawiki search uses whole word searches only.
We also want to eliminate the hierarchy. A better name would be [[Package
maintainer responsibilities]].
I was looking at the page
https://fedoraproject.org/wiki/PackageMaintainersand see a lot of good
naming suggestions in the link names and descriptions.
With renaming, categories, and subcategories we can even generate a similar
page automatically.
Check out the fonts pages for an example:
https://fedoraproject.org/wiki/Category:Fonts
Something similar can be done for
https://fedoraproject.org/wiki/Category:Package_Maintainers
I am still looking for suggestions for subcategories for the Package
Maintainers pages.
If there are pages that are old or no longer in use they can be moved to the
Archive namespace. Simply click the move button at the top of the page and
add Archive: at the beginning of the name. For instance
PackageMaintainers/FC3Status has recently been moved to
Archive:PackageMaintainers/FC3Status Anything pointing to the original name
is automatically redirected to the new name. This way the page still exists
and can be found with an advanced search but will not appear in default
search that a visitor to the site may use. Can
PackageMaintainers/PackageStatus/CompsF9Missing also be archived?
Finally, there is a fedora-wiki mailing list that has announcements and
tips, but is also a good place to ask questions and discuss names and
categories. https://admin.fedoraproject.org/mailman/listinfo/fedora-wiki
And I am often on #fedora-docs as laubersm (or some variation) but anyone
there should also be able to help.
I look forward to helping and I appreciate any suggestions.
Thanks,
Susan
--
Susan Lauber, (RHCX, RHCA, RHCSS)
Lauber System Solutions, Inc.
http://www.laubersolutions.com
gpg: 15AC F794 A3D9 64D1 D9CE 4C26 EFC3 11C2 BFA1 0974
14 years, 10 months
PHP Guidelines update proposal
by Remi Collet
What I was thinking (in an quite old discussion, during initial PHP
Guidelines writing) is now reality
According to PHP Guidelines, pear extension must be named
php-pear-<extension>.
That's ok for standard pear.php.net channel.
With non standard channel we can encounter conflicts.
llaumgui is working on submitting ezComponents for review.
http://ezcomponents.org/
For example, one of the extension is Mail and php-pear-Mail already exists.
My proposal is :
http://fedoraproject.org/wiki/PackagingDrafts/PHP
With this proposal, ezComponents will be named
php-ezc-<extensionname>
Comments ?
Remi.
14 years, 10 months
