Tcl packaging guidelines proposal
by Michael Thomas
I sent this proposal to f-m-l about a week ago to gather comments, and
there were no serious disagreements with the proposal which have not yet
been addressed (thanks to Tibbs and Toshio for their feedback).
Basically, I want to establish a set of guidelines for packaging Tcl
extensions, as we already have guidelines for other popular scripting
languages. In addition to making Tcl packages more consistent with each
other, it will also help work toward fixing my pet-peeve bug (bz #226893)
http://fedoraproject.org/wiki/PackagingDrafts/Tcl
Please let me know if I need to do anything to help get these draft
guidelines adopted.
Thanks,
--Wart
16 years, 3 months
Multiple version naming overly restrictive?
by Toshio Kuratomi
Hey all, I just noticed this section of the packaging Guidelines:
http://fedoraproject.org/wiki/Packaging/NamingGuidelines#MultiplePackages
says:
'''
For many reasons, it is sometimes advantageous to keep multiple versions
of a package in Fedora to be installed simultaneously. When doing so,
the package name should reflect this fact. The most recent version of a
package should use the base name with no versions, and all other addons
should note their version in the name.
'''
I think specifying that the latest package version has [basename] and
the others have [basename][version] may be overly restrictive. We have
precedent in gtk+ vs gtk2 (long term), gcc (3.x) vs gcc4 (short term),
gtkhtml vs gtkhtml2 vs gtkhtml3 (long term) for doing things the other
way. Do we really want to restrict this?
If not, we could amend the text like this:
'''
One package should use the base name with no versions and all other
addons should note their version in the name.
'''
-Toshio
16 years, 9 months
%{_datadir}/gtk-doc/ %doc?
by Toshio Kuratomi
Should files under %{_datadir}/gtk-doc/html be marked as %doc? They are
API docs for libraries which are extracted using the gtk-doc toolset and
viewable in devhelp. I've never seen a set of files that was necessary
for the runtime operation of a library (and doubt that I will... they're
API docs and usually included in a -devel subpackage.) On my current
system I haven't found any files in %{_datadir}/gtk-doc/html that are
marked as %doc.
-Toshio
16 years, 9 months
/srv
by Axel Thimm
Sorry I couldn't make it today (and FWIW I will be quite short of time
until mid September).
On the /srv issue: The FHS is deliberately not providing any layout on
how to internally structure this, as there are at least two very
popular ones (both of them mentioned in the FHS):
/srv/<service>/[<domain>/]...
/srv/<domain>/<service>/...
As neither fits universally and Fedora is a general purpose distro we
should not impose any layout on the users but allow them to freely use
any layout they like. There are extended version of this argumentation
on this list and f-m-l
E.g. no package (other than filesytem) should ever place/own anything
under /srv. Packages that need a dummy or default data location should
use /var instead.
--
Axel.Thimm at ATrpms.net
16 years, 10 months
cmake guideline update proposal
by Rex Dieter
http://fedoraproject.org/wiki/PackagingDrafts/cmake
In short, adding to %cmake:
-DINCLUDE_INSTALL_DIR=%{_includedir} \\\
-DLIB_INSTALL_DIR=%{_libdir} \\\
-DSYSCONF_INSTALL_DIR=%{_sysconfdir} \\\
-DSHARE_INSTALL_PREFIX=%{_datadir}
Found these additions useful while working on kde4 packaging
(SYSCONF_INSTALL_DIR in particular, since kde4's default was/is prefix/etc).
-- Rex
16 years, 10 months
one big SRPM for lots of different stardict dictionaries?
by Thorsten Leemhuis
Hi,
I stumbled over the CVS branch creation commit mails for a package
called "stardict-dic" in my inbox and thought "hey, nice, someone
packaged dictionaries for startdict". But then I took a closer look at
the package and the review bug
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=231267
and got a bit worried.
The plan of the packager afaics seems to be to get all the current and
future dictionaries for other languages into this one just-reviewed and
approved package stardict-dic (SRPM currently 84 MByte in size afaics),
from with multiple sub-packages get build (currently:
stardict-dic-{en,ja,ru,zh_CN,zh_TW} ).
The "one SRPM for all dicts" approach IMHO has major disadvantages IMHO:
the SRPM will become really big if dictionaries for other languages
become part of it. This might be acceptable, but for each added dict or
each bug that gets fixed in one of the dictionaries the whole SRPM gets
rebuild and thus all the stardict-dic-{en,ja,ru,zh_CN,zh_TW} packages
get created newly as well, which creates a lot of load for mirrors and
users to download and install (¹).
This sems very wrong to me; or am I overacting here?
I'd say we should work towards a scheme similar to hunspell; e.g. one
source package per language. Other opinions?
CU
thl
(¹) -- Example:
- user foo install stardict-dic-en-2.4.2-2.fc7.noarch.rpm
- maintainer add german dictionary to stardict-dic, increases release by
one and rebuilds
- user foo updates to stardict-dic-en-2.4.2-3.fc7.noarch.rpm
- maintainer add spanisch dictionary to stardict-dic, increases release
by one and rebuilds
- user foo updates to stardict-dic-en-2.4.2-4.fc7.noarch.rpm
- and so on
16 years, 10 months
Fedora Core 6 pkgs in Fedora 7
by Adam Ornat
Hi all, I've upgraded to Fedora 7 from FC6 and noticed
that there are still .fc6 packages in my system. Could
these packages be removed?
Thanks in advance,
Art
16 years, 10 months
