packaging June 2007

packaging@lists.fedoraproject.org

33 participants
36 discussions

Tcl packaging guidelines proposal
by Michael Thomas 02 Jan '08

02 Jan '08

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

4 10

font package naming
by Jens-Ulrik Petersen 21 Sep '07

21 Sep '07

Hi, I would like to propose adding the following text to our "Package Naming Guidelines". http://fedoraproject.org/wiki/Packaging/NamingGuidelines ''' == Fonts Packages == Font packages should be named with the upstream name appended with `-fonts`. Examples: {{{ bitmap-fonts dejavu-lgc-fonts ghostscript-fonts urw-fonts xorg-x11-fonts }}} ''' Should the text discuss what to do when the upstream name contains the word "font" already? See https://www.redhat.com/archives/fedora-maintainers/2007-February/msg00794.h… and https://www.redhat.com/archives/fedora-maintainers/2007-March/msg00262.html for some recent discussion of <upstreamname>-fonts vs fonts-<language> and "-fonts" vs "-font" for singlet font packages. Comments or objections? Jens ps We might even consider renaming some of our "fonts-*" packages to follow this naming scheme for F8.

4 10

Packaging guidelines for Emacsen add-on packages
by Jonathan Underwood 15 Aug '07

15 Aug '07

Dear Packaging Committee, I have placed a draft Guidelines document on the wiki for your consideration. This document covers the packaging of Emacs and XEmacs add-on packages, and provides two template spec files with the intention of lowering the inertial barrier to developing packages for (X)Emacs. The doc can be found here: http://fedoraproject.org/wiki/PackagingDrafts/EmacsenAddOns And I have added it to the table here: http://fedoraproject.org/wiki/PackagingDrafts/DraftsTodo This document doesn't attempt to change guidelines in any way, but rather clarify the situation as presented in the Package Naming Guidelines, and codify them in the form of spec templates. Comments gladly received! Best wishes, Jonathan

7 49

Multiple version naming overly restrictive?
by Toshio Kuratomi 03 Jul '07

03 Jul '07

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

2 1

%{_datadir}/gtk-doc/ %doc?
by Toshio Kuratomi 29 Jun '07

29 Jun '07

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

5 6

/srv
by Axel Thimm 28 Jun '07

28 Jun '07

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

4 18

cmake guideline update proposal
by Rex Dieter 27 Jun '07

27 Jun '07

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

5 8

one big SRPM for lots of different stardict dictionaries?
by Thorsten Leemhuis 26 Jun '07

26 Jun '07

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

6 9

Fedora Core 6 pkgs in Fedora 7
by Adam Ornat 26 Jun '07

26 Jun '07

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

2 1

Re: [Fedora-packaging] one big SRPM for lots of different stardict dictionaries?
by Hu Zheng 26 Jun '07

26 Jun '07

I thought that we can add a de dictionary while keep en rpm's release number don't change, which is not true. I will submit new package requests per language dictionary. Thanks everyone!

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

packaging June 2007