From ce4f63fd88b162bac692ab51a1cc5e1dd17b38cf Mon Sep 17 00:00:00 2001 From: ImportUser Date: May 24 2008 14:13:02 +0000 Subject: [PATCH 2/3559] Imported from MoinMoin --- diff --git a/Packaging:R.mw b/Packaging:R.mw new file mode 100644 index 0000000..47f7804 --- /dev/null +++ b/Packaging:R.mw @@ -0,0 +1,227 @@ += How to package R modules = + + + +== What is R? == +The definition from [http://www.r-project.org/ The R-Project website] says that R is: + +''" R is a language and environment for statistical computing and graphics."'' + +R is a GNU project, very similar to the S language developed by Bell Laboratories. + +This language is heavily used in research as it provides a lot of statistical and graphical tools. +It is also a well developed language for data manipulation. + +If you are looking for more information on R, you can go to: +* [http://www.r-project.org/ The R-Project website] +* [http://cran.r-project.org/doc/manuals/R-intro.html An introduction to R] + +If you are interested in packaging R modules, or if you are looking for R libraries, you should check here for upstream sources: +* [http://www.bioconductor.org/ The bioconductor website] +* [http://cran.r-project.org/ The CRAN website] + +== Spec Templates for R packages == + +There are two types of R packages: arch-specific and noarch. + +=== Arch specific R packaging spec template === + +
+%define packname foo
+%define packrel 1
+
+Name:             R-%{packname}
+Version:          1.6.6
+Release:          1%{?dist}
+Source0:          ftp://cran.r-project.org/pub/R/contrib/main/%{packname}_%{version}-%{packrel}.tar.gz
+License:          GPL
+URL:              http://cran.r-project.org/src/contrib
+Group:            Applications/Engineering
+Summary:          Adds foo functionality for R
+BuildRequires:    R-devel, tetex-latex
+BuildRoot:        %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
+Requires(post):   R
+Requires(postun): R
+
+%description
+R Interface to foo, enables bar!
+
+%prep
+%setup -q -c -n %{packname}
+
+%build
+
+%install
+rm -rf $RPM_BUILD_ROOT
+mkdir -p $RPM_BUILD_ROOT%{_libdir}/R/library
+%{_bindir}/R CMD INSTALL -l $RPM_BUILD_ROOT%{_libdir}/R/library %{packname}
+test -d %{packname}/src && (cd %{packname}/src; rm -f *.o *.so)
+rm -rf $RPM_BUILD_ROOT%{_libdir}/R/library/R.css
+
+%check
+%{_bindir}/R CMD check %{packname}
+
+%clean
+rm -rf $RPM_BUILD_ROOT
+
+%post
+%{_R_make_search_index}
+
+%postun
+%{_R_make_search_index}
+
+%files
+%defattr(-, root, root, -)
+%dir %{_libdir}/R/library/%{packname}
+%doc %{_libdir}/R/library/%{packname}/latex
+%doc %{_libdir}/R/library/%{packname}/doc
+%doc %{_libdir}/R/library/%{packname}/html
+%doc %{_libdir}/R/library/%{packname}/man
+%doc %{_libdir}/R/library/%{packname}/DESCRIPTION
+%doc %{_libdir}/R/library/%{packname}/NEWS
+%{_libdir}/R/library/%{packname}/CONTENTS
+%{_libdir}/R/library/%{packname}/INDEX
+%{_libdir}/R/library/%{packname}/NAMESPACE
+%{_libdir}/R/library/%{packname}/Meta
+%{_libdir}/R/library/%{packname}/R
+%{_libdir}/R/library/%{packname}/R-ex
+%{_libdir}/R/library/%{packname}/help
+
+%changelog
+* Fri Jul 6 2007 Tom "spot" Callaway  1.6.6-1
+- Initial package creation
+
+ +=== Noarch R packaging spec template === + +
+%define packname foo
+%define packrel 1
+
+Name:             R-%{packname}
+Version:          1.6.6
+Release:          1%{?dist}
+Source0:          ftp://cran.r-project.org/pub/R/contrib/main/%{packname}_%{version}-%{packrel}.tar.gz
+License:          GPL
+URL:              http://cran.r-project.org/src/contrib
+Group:            Applications/Engineering
+Summary:          Adds foo functionality for R
+BuildRequires:    R-devel, tetex-latex
+BuildRoot:        %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
+BuildArch:        noarch
+Requires(post):   R
+Requires(postun): R
+Requires:         R
+
+%description
+R Interface to foo, enables bar!
+
+%prep
+%setup -q -c -n %{packname}
+
+%build
+
+%install
+rm -rf $RPM_BUILD_ROOT
+mkdir -p $RPM_BUILD_ROOT%{_datadir}/R/library
+%{_bindir}/R CMD INSTALL -l $RPM_BUILD_ROOT%{_datadir}/R/library %{packname}
+test -d %{packname}/src && (cd %{packname}/src; rm -f *.o *.so)
+rm -rf $RPM_BUILD_ROOT%{_datadir}/R/library/R.css
+
+%check
+%{_bindir}/R CMD check %{packname}
+
+%clean
+rm -rf $RPM_BUILD_ROOT
+
+%post
+%{_R_make_search_index}
+
+%postun
+%{_R_make_search_index}
+
+%files
+%defattr(-, root, root, -)
+%dir %{_datadir}/R/library/%{packname}
+%doc %{_datadir}/R/library/%{packname}/latex
+%doc %{_datadir}/R/library/%{packname}/doc
+%doc %{_datadir}/R/library/%{packname}/html
+%doc %{_datadir}/R/library/%{packname}/man
+%doc %{_datadir}/R/library/%{packname}/DESCRIPTION
+%doc %{_datadir}/R/library/%{packname}/NEWS
+%{_datadir}/R/library/%{packname}/CONTENTS
+%{_datadir}/R/library/%{packname}/INDEX
+%{_datadir}/R/library/%{packname}/NAMESPACE
+%{_datadir}/R/library/%{packname}/Meta
+%{_datadir}/R/library/%{packname}/R
+%{_datadir}/R/library/%{packname}/R-ex
+%{_datadir}/R/library/%{packname}/help
+
+%changelog
+* Fri Jul 6 2007 Tom "spot" Callaway  1.6.6-1
+- Initial package creation
+
+ +=== Summary of differences between arch-specific and noarch R packages === + +* Noarch packages set BuildArch: noarch +* Noarch packages install into %{_datadir}/R/library/%{packname}, arch-specific packages install into %{_libdir}/R/library/%{packname} + +== R packaging tips == + +=== Naming of R packages === +Packages of R modules (thus they rely on R as a parent) have their own naming scheme. They should take into account the upstream name of the R module. This makes a package name format of R-$NAME. When in doubt, use the name of the module that you type to import it in R. + +'''Examples: ''' +
+R-mAr (R module named mAr)
+R-RScaLAPACK (R module named RScaLAPACK)
+R-waveslim (R module named waveslim)
+
+ +=== Empty %build section === +Unlike normal Fedora packages, there is normally no separate %build actions (e.g. %configure)that need to be taken for an R package. However, it is important that all R module packages include an empty %build section, as shown in the spec templates. + +=== Installing the R addon bits === +Instead of calling make install, to install the R addon components, you need to run R CMD INSTALL -l $RPM_BUILD_ROOT%{_datadir}/R/library %{packname} (noarch) or R CMD INSTALL -l $RPM_BUILD_ROOT%{_libdir}/R/library %{packname} (arch-specific). Proper %install sections for Fedora R packages are demonstrated in the spec templates. + +=== Deleting the R.css file === +Most R addon modules generate a new R.css file, but it would conflict with the master R.css file, included in the main R package. You must delete this file, and do not include it in your package. + +=== Generating the search index.txt === +R keeps a master index.txt, as a search index of which R libraries are installed on the system. This provides the source for the R html help interface that is accessible through the ''help.start()'' command. This index is always located at %{_libdir}/R/doc/html/search/index.txt. All R packages need to update the search index.txt in %post and %postun. The R package provides a macro to make this simple: %{_R_make_search_index}. Simply put this macro in %post and %postun in your R package, and it will update the search index.txt to include arch-specific and noarch R libraries upon install and uninstall. This is demonstrated in the spec templates. + +NOTE: R packages will throw the following warning from rpmlint: +
+W: R-widgetTools one-line-command-in-%post
+/usr/lib/rpm/R-make-search-index.sh
+
+ +Normally, this would be resolved by running %post -p foo, but this will not work with our script. +Just ignore this warning. + +=== Cleaning the R directory of binaries === +It is important to clean the R directory of binary files (*.o *.so) before running R CMD CHECK. Otherwise, the CHECK command will throw a warning about finding binaries in the source dir. This is accomplished by running (in %install): + +
+test -d %{packname}/src && (cd %{packname}/src; rm -f *.o *.so)
+
+ +This is demonstrated in the spec templates. + +=== Running %check === +Most (if not all) R addon modules come with a built-in check. This can be triggered by running R CMD check. In Fedora, the check should be run in the %check section. Here is an example %check section for a Fedora R package: + +
+%check
+%{_bindir}/R CMD check %{packname}
+
+ +Note that frequently, R packages have circular dependency loops when running R CMD check. If you hit such a case, you can comment out the check to break the dependency loop, and leave a comment explaining the circular dependency problem. + +=== Documentation files === +The R CMD INSTALL operation will install all of the files, including documentation files. The latex, doc, html, man, NEWS, and DESCRIPTION files/directories need to be marked as %doc. +Note that other files, such as CONTENTS, INDEX, NAMESPACE, and help/ are not %doc, since proper R functionality depends on their presence. Be careful not to duplicate %doc files in the package, the spec templates provide good examples on how to package the R addon files without duplications. + +=== Optimization flags === +R packages inherit their optimization flags from the main R package, which stores them in %{_libdir}/R/etc/Makeconf. The design of R is such that all R addon library modules use the same optimization flags that the main R package was built with. Accordingly, this is why R addon packages do not pass $RPM_OPT_FLAGS. Also, there is no simple way to pass special optimization flags to R CMD INSTALL. From 6d064e1460e0fc54fe46852cf108f483e325a244 Mon Sep 17 00:00:00 2001 From: ImportUser Date: May 24 2008 14:13:02 +0000 Subject: [PATCH 4/3559] Imported from MoinMoin --- diff --git a/Packaging:DistTag.mw b/Packaging:DistTag.mw new file mode 100644 index 0000000..9438ac7 --- /dev/null +++ b/Packaging:DistTag.mw @@ -0,0 +1,163 @@ + += Dist Tag Guidelines = +These are the guidelines for using the %{dist} tag in Fedora. Using the %{dist} tag is not mandatory, however, it is the only permitted mechanism for marking the distribution revision of a package. This isn't because any other method is broken or bad, but because we need a consistent standard in Fedora. + +You should consider this document as an addendum to the ["Packaging/NamingGuidelines"] . + +'''Author:''' [[TomCallaway| Tom 'spot' Callaway]]
+'''Revision:''' 0.14
+'''Initial Draft:''' Monday Mar 21, 2005
+'''Last Revised:''' Monday May 21, 2007
+ + + +{{Anchor|Purpose}} +== Purpose of the Dist Tag == +There are several uses for a %{dist} tag. The original purpose was so that a single spec file could be used for multiple distribution releases. In doing this, there are cases in which BuildRequires: and Requires: will need to be different for different distribution releases. Hence, %{dist} does double duty: + +*it differentiates multiple packages which would otherwise have the same %{name}-%{version}-%{release}, but very different dependencies. + +*it allows for a conditional check in the spec to deal with the differing dependencies. + +{{Anchor|IsItMandatory}} +=== Do I Have To Use the Dist Tag? === +No. It is documented and standardized so that maintainers who wish to use it can do so, but it is not mandatory. + +== Using %{dist} == + +OK, so you've decided to use %{dist}. Here is the important information to know: + +=== Possible values for %{dist} === +When you run make tag or make build, the values for %{dist} and its helper variables are assigned according to the cvs branch that you are working in. You do NOT need to define these variables in your spec file. The Makefile will magically set %{dist} for you. + +For reference purposes only, these are the possible values for %dist: + +
+Red Hat Linux:
+7.0, 7.1, 7.2, 7.3: .rhl7
+8: .rhl8
+9: .rhl9
+
+Red Hat Enterprise Linux:
+2.1 (all variants): .el2
+3 (all variants): .el3
+4 (all variants): .el4
+5 (all variants): .el5
+
+Fedora Core:
+1: .fc1
+2: .fc2
+3: .fc3
+4: .fc4
+5: .fc5
+6: .fc6
+7: .fc7
+
+Development:
+
+The development branch takes the disttag of the next major unreleased version of Fedora.
+
+
+Note the leading period in the definition of %{dist}. This is present so that it can easily be used in the release field. +These definitions can be found in common/branches. + +Note that RHEL dist tags are only defined for EPEL packages. + +=== %{dist} in the Release: field === + +When using %{dist} to mark a package as having been built for a specific distribution, you should include it in the Release field, like this: +
+Release: 1%{?dist}
+
+Basically, follow the ["Packaging/NamingGuidelines"] for how to set the value for Release, then append %{?dist} to the end. This translates into: +
+If %{dist} is defined, insert its value here. If not, do nothing.
+
+ +So, if we have the following in a spec file: +
+Name: logjam
+Version: 1.4
+Release: 2%{?dist}
+
+When this package is built in an i386 FC3 buildroot, it generates an rpm named: logjam-1.4-2.fc3.i386.rpm. + +Keep in mind that %{dist} should '''never''' be used in the Name or Version fields, nor in %changelog entries. + +=== Conditionals === + +Along with %{dist}, there are several "helper" variables defined by the buildsystem. These variables are: + +%{rhel}: This variable is only defined on Red Hat Enterprise Linux builds. If defined, it is set to the release number of Red Hat Enterprise Linux present at build time. (Not currently used.) + +%{fedora}: This variable is only defined on Fedora builds. If defined, it is set to the release number of Fedora present at build time. + +%{rhl}: This variable is only defined on Red Hat Linux builds. If defined, it is set to the release number of Red Hat Linux present at build time. + +%{fc#}: This variable is only defined on Fedora builds. For example, on Fedora 7 builds, %{fc7} is defined to 1. + +%{el#}: This variable is only defined on Red Hat Enterprise Linux builds. For example, on RHEL 5 builds, %{el5} is defined to 1. + +All of these variables, if defined, will have a purely numeric value. +With %{dist} and these additional variables, you can create conditionals in a spec file to handle the differences between distributions. + +Here are some examples of how to use these variables in conditionals: + +
+%if 0%{?rhel}
+%endif
+
+%if 0%{?fedora} >= 4
+%endif
+
+%{?fedora:%define _with_xfce --with-xfce}
+
+%if 0%{?rhel}
+%if 0%{?rhl}
+%endif
+%endif
+
+%if 0%{?rhl}%{?fedora}
+%endif
+
+%{?fc8:Requires: foo}
+%{?fc7:Requires: bar}
+%{?fc6:Requires: baz}
+%{?fc5:Requires: quux}
+
+
+
+ +Keep in mind that if you are checking for a specific family of distributions, that you need to use: +
+%if 0%{?rhel}
+
+and '''NOT''' +
+%if %{?rhel}
+
+ +Without the extra 0, if %{rhel} is undefined, the %if conditional will cease to exist, and the rpm will fail to build. + +=== Things that you cannot use %{dist} for === +* You cannot override the variables for %{dist} (or any of the related variables). +* You cannot hardcode a value for %{dist} (or any of the related variables) in your spec. +* You cannot hardcode a dist tag in the spec: '''BAD:''' Release: 1.fc6 '''GOOD:''' Release: 1%{?dist} +* You cannot put any sort of "tagging" in %{dist} (or any of the related variables). %{dist} (and its related variables) exist ONLY to define the distribution that a package was built against. +* %{dist} should never be used in the Name or Version fields, only Release, and only as documented above. +* %{fedora}, %{rhel}, %{rhl}, %{fc#}, %{el#} should never be used in the Name, Version, or Release fields. + +== Common questions == +Q: Why don't you just let the buildsystem (or packager) pass the value for dist to rpm, e.g. rpm --with dist el3? +A: Actually, we do. The Fedora buildsystem defines the values for dist when you run make tag or make build. + +Q: What about RPMForge's dist tags? Why didn't you use their established standard? +A: RPMForge has a set of standard dist tags that they use. Specifically: +
+0.el2, 0.rh7, 0.rh8, 0.rh9, 1.el3, 1.fc1, 1.fc2, 1.fc3, 2.el4, 2.fc4, 2.fc5 ...
+
+RPMForge precedes the distribution value with a numeric value, designed to assist in upgrades between versions of Red Hat Linux, Red Hat Enterprise Linux, and Fedora. I really don't think that an upgrade path between RHEL and Fedora is viable, or something that we should attempt to promote. If Fedora used the same dist tags, we'd be implying that there was support for upgrading between drastically different distributions. It also adds an extra layer of complexity to the Release field, confusing users and new packagers. + +---- +[[Category:Extras]] From ecb91467599b9993aed5678f68142006bad6be0e Mon Sep 17 00:00:00 2001 From: ImportUser Date: May 24 2008 14:13:02 +0000 Subject: [PATCH 6/3559] Imported from MoinMoin --- diff --git a/Packaging:JPackagePolicy.mw b/Packaging:JPackagePolicy.mw new file mode 100644 index 0000000..e5cde61 --- /dev/null +++ b/Packaging:JPackagePolicy.mw @@ -0,0 +1,138 @@ + += Subrelease Packaging Guidelines for JPackage RPMS = + +'''Author:''' [[TomCallaway| Tom 'spot' Callaway]]
+'''Revision:''' 0.05
+'''Initial Draft:''' Tuesday Jan 16, 2007
+'''Last Revised:''' Monday Feb 12, 2007
+ + + +== Summary == +Fedora includes a set of open source Java RPM packages that originate from the JPackage repository (www.jpackage.org). Currently, these packages are marked with a "jpp" tag: + +
+javacc-4.0-3jpp.3.src.rpm
+
+ +These packages are rebuilt against Fedora's gcc and included in Fedora. They use the "jpp" tag for three main technical reasons: + +* to help manage upgrading packages from Fedora to JPackage and back +* to track package hierarchy (this Fedora Java package came from that JPackage Java package) +* to help the Red Hat Java packagers perform grouped operations on all the Java packages + +== Proposal == +Normally, this use of the "jpp" tag would violate the [wiki:Self:Packaging/NamingGuidelines Fedora Package Naming Guidelines] . + +In order to reach a compromise, the following guidelines have been drafted: + +=== Managing upgrading packages from Fedora to JPackage and back === +According to Fernando Nasser, JPackage RPMS only use integers in the Release: field, in the format Xjpp. If this is the case, then the following format will ensure clean upgrades from Fedora to JPackage and so forth: + +JPackage RPMS have a Release of Xjpp (e.g. 1jpp). Fedora RPMS (which are taken from JPackage) will have a Release that takes the JPackage Release (Xjpp), and appends a subrelease integer (Y) after the jpp tag. This will make the Fedora Java packages have a Release of: Xjpp.Y (e.g. 1jpp.1). + +While the Fedora package is in the devel branch, only the subrelease is incremented (e.g. 1jpp.2, 1jpp.3) until a new package from JPackage (e.g 2jpp) is merged into Fedora, at which point, the release would change to match the new JPackage RPM, and the subrelease would reset to 1. + +Normally, we'd give the packager the choice of using '%{?dist}' or bumping the release to ensure clean upgrades across Fedora releases, but since we're trying to ensure hierarchy and upgrades from the JPackage repository, in this special case, use of the '%{?dist}' tag is mandatory. It would go at the end of the Release: field, (e.g. 1jpp.1%{?dist}) + +Once the Fedora package is out of the devel branch and into a released branch, the release and subrelease fields are frozen. These packages are now subject to the [wiki:Self:NamingGuidelines#DistBump Minor release bumps for old branches] rule. + +{| border="1" +|- +| '''JPackage''' || '''Fedora Package''' || '''Status''' || '''Highest RPMver''' +|- +| javacc-4.0-3jpp.src.rpm || javacc-4.0-3jpp.1.fc7.src.rpm || Package merged from JPackage into Fedora devel || Fedora +|- +| javacc-4.0-3jpp.src.rpm || javacc-4.0-3jpp.2.fc7.src.rpm || Fedora package has a bug fixed, bump subrelease || Fedora +|- +| javacc-4.0-3jpp.src.rpm || javacc-4.0-3jpp.3.fc7.src.rpm || Fedora package is rebuilt for new gcc, bump subrel || Fedora +|- +| javacc-4.0-4jpp.src.rpm || javacc-4.0-3jpp.3.fc7.src.rpm || JPackage is updated to fix a bug, bumps major release || JPackage +|- +| javacc-4.0-4jpp.src.rpm || javacc-4.0-4jpp.1.fc7.src.rpm || Fedora package is merged from new JPackage || Fedora +|- +| javacc-5.0-1jpp.src.rpm || javacc-4.0-4jpp.1.fc7.src.rpm || JPackage releases new version of package || JPackage +|- +| javacc-5.0-1jpp.src.rpm || javacc-5.0-1jpp.1.fc7.src.rpm || Fedora package is merged from new JPackage || Fedora +|- +| javacc-5.0-1jpp.src.rpm || javacc-5.0-1jpp.1.fc7.src.rpm || FC-7 is released, package is no longer in devel || Fedora +|- +| javacc-5.0-1jpp.src.rpm || javacc-5.0-1jpp.1.fc7.1.src.rpm || A bug is fixed in the FC-7 package. || Fedora +|} + +This methodology ensures a clean upgrade process. It also ensures that when the "jpp" tag is removed, the upgrade process is unaffected. This is, however, a violation of the naming policy around releases, and is only permitted in this special case exception for Fedora Java packages from JPackage. + +==== Pre-release Packages ==== +JPackage has a Release standard of: 0.X.tag.Yjpp for prerelease packages. Tag is where the alpha/beta/CVS/SVN/etc tag goes, X is an integer incremented upon tag changes, and Y is an integer which increments only for packaging fixes, plain rebuilds etc. This is based on Fedora's pre-release naming standards. The same Subrelease policy is in effect for JPackage derived pre-release Packages in Fedora, on top of the existing [wiki:Self:Packaging/NamingGuidelines#PreReleasePackages Fedora pre-release guidelines] . Here is an example of a pre-release using the JPackage Subrelease Policy: + +{| border="1" +|- +| '''JPackage''' || '''Fedora Package''' || '''Status''' || '''Highest RPMver''' +|- +| javacc-4.0-0.1.a.1jpp.src.rpm || javacc-4.0-0.1.a.1jpp.1.fc7.src.rpm || Package merged from JPackage into Fedora devel || Fedora +|- +| javacc-4.0-0.2.b.1jpp.src.rpm || javacc-4.0-0.1.a.1jpp.1.fc7.src.rpm || JPackage moves to "b" tag || JPackage +|- +| javacc-4.0-0.2.b.1jpp.src.rpm || javacc-4.0-0.2.b.1jpp.1.fc7.src.rpm || Fedora version of "b" tag package || Fedora +|- +| javacc-4.0-0.2.b.2jpp.src.rpm || javacc-4.0-0.2.b.1jpp.1.fc7.src.rpm || JPackage is rebuilt for packaging fix || JPackage +|- +| javacc-4.0-0.2.b.2jpp.src.rpm || javacc-4.0-0.2.b.2jpp.1.fc7.src.rpm || Fedora version of JPackage packaging fix || Fedora +|- +| javacc-4.0-0.2.b.2jpp.src.rpm || javacc-4.0-0.2.b.2jpp.2.fc7.src.rpm || Fedora rebuilds in devel against a new compiler || Fedora +|- +| javacc-4.0-0.2.b.2jpp.src.rpm || javacc-4.0-0.2.b.2jpp.2.fc7.src.rpm || FC-7 is released, package moves out of devel || Fedora +|- +| javacc-4.0-0.2.b.2jpp.src.rpm || javacc-4.0-0.2.b.2jpp.2.fc7.1.src.rpm || A bug is fixed in the FC-7 package. || Fedora +|- +| javacc-4.0-1jpp.src.rpm || javacc-4.0-0.2.b.2jpp.2.fc7.1.src.rpm || JPackage moves to final release (not pre anymore) || JPackage +|- +| javacc-4.0-1jpp.src.rpm || javacc-4.0-1jpp.1.fc7.src.rpm || Fedora version of final package || Fedora +|} + + +=== Track Package Hierarchy From JPackage to Fedora === +With the subrelease scheme as documented above, it is very obvious from which JPackage RPM the Fedora Java package originated from. + +=== Help the Red Hat Java Packagers Perform Grouped Operations === +The need to perform various grouped operations on sets of packages is not unique to the Java packages, but rather, a problem which many people in the Fedora community are working to solve, through new tools and improvements to existing ones. + +One key point to note is that the direction is currently to handle Grouping or Categories of packages with metadata that is not hardcoded into the package itself. Or, to put it simply, to not use the Group: field in rpm for this task. It is far too inflexible, as packages can (and do) fall under many different groups or categories. + +The grouping operations are: +* Being able to query for the set of Java packages installed +* Being able to exclude the Java packages as a group from the yum install/update/remove processes + +Until these grouping operations can be performed without the "jpp" tag, there is no other (non-intrusive) way to meet this need. + +==== Query for the set of Java packages ==== + +The rpm -qg (or rpm -q --group) command currently does not accept patterns. If it was possible to do 'rpm -qg "Java*"' we could add "Java/" to all "Group:" +tags of all Java packages and that would work. + +==== Group Exclude in Yum ==== + +yum has already some group functionality (groupinstall, groupupdate, groupremove, groupinfo) that is based on an XML file that is kept in the repository. But the option --exclude only acts on file names, we need a --groupexclude. + +There is currently a "Java" group, with only 2 packages on it: + +Loading "installonlyn" plugin
+Setting up Group Process
+Setting up repositories
+ +Group: Java
+Description: Support for running programs written in the Java programming language.
+Mandatory Packages:
+libgcj
+java-1.4.2-gcj-compat
+ +We could just make sure all Java packages are in the Java group to make use of the yum group functionality. Enabling a --groupexclude would meet this criteria. + +== Policy Conditions Defined == +Accordingly, Fedora will permit Java packages from JPackage (and ONLY Java packages from JPackage) to use the "jpp" tag, under the following conditions: + +* The use of the "jpp" tag is temporary. Once there is no longer a technical need as defined in this document, it will be removed from all Fedora packages. +* Fedora Java packages must follow the subrelease versioning as defined in this document. When the "jpp" tag is removed from Fedora packages, this document will be updated to reflect the change in the subrelease scheme, but the Fedora Java packages will still need to follow it. +* No other packages fall under this policy (at this time). +* Packagers of Fedora Java packages need to explicitly agree to this policy during package review. From cbfff312af1506399695f6c99132ea0fd5dcc8f4 Mon Sep 17 00:00:00 2001 From: ImportUser Date: May 24 2008 14:13:02 +0000 Subject: [PATCH 8/3559] Imported from MoinMoin --- diff --git a/Packaging:Java.mw b/Packaging:Java.mw new file mode 100644 index 0000000..4c236e2 --- /dev/null +++ b/Packaging:Java.mw @@ -0,0 +1,431 @@ + += Java Packaging Guidelines = +These guidelines are laid out in order of relevance to packaging. + + + +== Introduction == + +=== Background === +Traditionally, Java implementations have been available under a non-free license. Free software clean room implementations of the class library largely centred around GNU Classpath. GCJ, a Java frontend for GCC, allowed for native compilation of Java software. In 2007, Sun released its reference implementation of Java under the GPL+Classpath exception as OpenJDK. This included the bytecode interpreter, just-in-time (JIT) compiler (Hotspot), and the majority of its class library. Due to the remaining small proprietary encumbrances, a project known as IcedTea was formed to build OpenJDK with entirely free tools, and provides Free software plugs for the encumbered pieces of the class libraries. Recent (early 2008) developments have enabled Fedora to ship a package under the OpenJDK name. + +=== The Basics === +The term Java means many things to many people: a class library, a bytecode interpreter, a JIT compiler, a language specification, etc. For the vast majority of users and developers, Java is a programming language and runtime environment that is architecture- and OS-agnostic. The normal flow of code is .java (source file) ’ .class (Java bytecode) ’ .jar (a zip archive). In the majority of cases, a user executes a Java program by specifying a class name containing a main method (just like C and C++). Often, this is done by invoking the java binary with a list of JAR files specifying the classpath like so: + +java [-cp ] [] + +== Java Packaging == +The [http://www.jpackage.org JPackage Project] has defined standard file system locations and conventions for use in Java packages. Many distributions have inherited these conventions and in the vast majority of cases, Fedora follows them verbatim. We include relevant sections of the JPackage guidelines here but caution that the canonical document will always reside upstream: [http://www.jpackage.org/cgi-bin/viewvc.cgi/src/jpackage-utils/doc/jpackage-1.5-policy.xhtml?revision=HEAD&root=jpackage JPackage Guidelines] . Over time, we would like to remove any divergences in these documents, but where they are different, these Fedora guidelines will take precedence for Fedora packages. + +=== Package naming === + +Packages '''MUST''' follow the standard Fedora ["Packaging/NamingGuidelines"] . Java API documentation '''MUST''' be placed into a sub-package called %{name}-javadoc. + +==== Release tags ==== +For now, refer to the ["Packaging/JPackagePolicy"] for release tags. That document should eventually be folded into this one. + +=== Jar file naming === + +1. If a package provides a single JAR file it must have the same name as the package itself. + +ex. jaf.jar + +1. If the project name and the commonly used JAR filename differ, a symbolic link with the usual name must also be provided. + +ex. Single JAR complete naming. Project name is jaf, common name is activation. + +activation.jar ’ jaf.jar + +1. If the package provides several JAR files, the filenames assigned by the build must be used. Above symlinking rules apply. + +ex. 
ant-1.5.3.jar
+ant-optional-1.5.3.jar
+ +1. If the number of provided JAR files exceeds '''two''', you must place them into a sub-directory. + +1. If a project offers the choice of packaging it as a single monolithic jar or several ones, the split packaging should be preferred. + +=== Directory structure === +All JAR files '''MUST''' go into %{_javadir}. Exceptions include [[JNI| JNI-using JAR files]] , and application-specific JAR files (ie. JAR files that can only reasonably be used as part of an application and therefore constitute application-private data). + +Java API documentation uses a system known as javadoc. All javadocs '''MUST''' be installed into %{_javadocdir}. + +=== BuildRequires and Requires === +At a minimum, Java packages '''MUST''': + +
BuildRequires: java-devel [>= specific_version] 
+BuildRequires:  jpackage-utils
+
+Requires:  java >= specific_version
+Requires:  jpackage-utils
+ +For historical reasons, when specifying versions 1.6.0 or greater, an epoch of 1 must be included. Example: + +
Requires: java >= 1:1.6.0
+
+ +=== build-classpath === +build-classpath is a script that can be used to generate classpaths from generic names of JAR files. Example: + +
export CLASSPATH=$(build-classpath commons-logging commons-net)
+
+ +=== build-jar-repository === +build-jar-repository is similar to build-classpath but instead of producing a classpath entry, it creates symlinks in a given directory. Example: +
$ mkdir lib
+$ build-jar-repository -s -p lib commons-logging commons-net
+$ ls -l lib
+commons-logging.jar -> /usr/share/java/commons-logging.jar
+commons-net.jar -> /usr/share/java/commons-net.jar
+
+ +=== ant === +ant is a build tool used by many Java packages. Packages built using ant ship with build.xml files which contain build targets similar to Makefiles. Packages built using ant must: + +
BuildRequires: ant
+...
+%build
+...
+ant
+
+ +=== maven === +maven is a tool used by many Java packages. In Fedora, the package is called maven2. Packages built using maven ship with pom.xml files. They '''MUST''': + +
Requires(post): jpackage-utils
+Requires(postun): jpackage-utils
+ +and '''SHOULD''' contain common sections such as the following: + +
+...
+%build
+export MAVEN_REPO_LOCAL=$(pwd)/.m2/repository
+mkdir -p $MAVEN_REPO_LOCAL
+
+mvn-jpp \
+-Dmaven.repo.local=$MAVEN_REPO_LOCAL \
+install javadoc:javadoc
+...
+%install
+rm -rf $RPM_BUILD_ROOT
+install -d -m 755 $RPM_BUILD_ROOT%{_javadir}
+install -d -m 755 $RPM_BUILD_ROOT%{_datadir}/maven2/poms
+install -pm 644 pom.xml $RPM_BUILD_ROOT/%{_datadir}/maven2/poms/JPP-maven-archiver.pom
+%add_to_maven_depmap org.apache.maven maven-archiver %{version} JPP maven-archiver
+...
+%post
+%update_maven_depmap
+
+%postun
+%update_maven_depmap
+...
+
+ +=== Wrapper Scripts === +Applications wishing to provide a convenient method of execution '''SHOULD''' provide a wrapper script in %{_bindir}. These can be as simple as this example: + +
#!/bin/bash
+. /usr/share/java-utils/java-functions
+
+MAIN_CLASS=MyCoolApp
+
+set_classpath "mycoolapp"
+
+run "$@"
+
+ +=== GCJ === +Please refer to ["Packaging/GCJGuidelines"] for GCJ-specific guidelines. + +=== -devel packages === +-devel packages don't really make sense for Java packages. Header files do not exist for Java packages. + +== Specfile Template == +=== ant === +
+Name:           # see normal package guidelines
+Version:        # see normal package guidelines
+Release:        1%{?dist}
+Summary:        # see normal package guidelines (SNPG)
+
+Group:          # SNPG
+License:        # SNPG
+URL:            # SNPG
+Source0:        # SNPG
+BuildRoot:      %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
+
+BuildRequires:  jpackage-utils
+
+BuildRequires:  java-devel
+
+BuildRequires:  ant
+
+Requires:       jpackage-utils
+
+Requires:       java
+
+%description
+
+%package javadoc
+Summary:        Javadocs for %{name}
+Group:          Development Documentation
+Requires:       %{name} = %{version}-%{release}
+Requires:       jpackage-utils
+
+%description javadoc
+This package contains the API documentation for %{name}.
+
+%package manual
+Summary:        Manual for %{name}
+Group:          Development Documentation
+Requires:       jpackage-utils
+Requires:       %{name} = %{version}-%{release}
+
+%description manual
+The manual for %{name}.
+
+%prep
+%setup -q
+
+
+find -name '*.jar' -o -name '*.class' -exec rm -f '{}' \;
+
+
+%build
+ant
+
+%install
+rm -rf $RPM_BUILD_ROOT
+
+mkdir -p $RPM_BUILD_ROOT%{_javadir}
+cp -p [build path to jar]   \
+$RPM_BUILD_ROOT%{_javadir}/%{name}-%{version}.jar
+
+
+mkdir -p $RPM_BUILD_ROOT%{_javadocdir}/%{name}
+cp -rp [javadoc directory]  \
+$RPM_BUILD_ROOT%{_javadocdir}/%{name}
+
+%clean
+rm -rf $RPM_BUILD_ROOT
+
+%files
+%defattr(-,root,root,-)
+%{_javadir}/*
+%doc
+
+%files javadoc
+%defattr(-,root,root,-)
+%{_javadocdir}/%{name}
+
+%files manual
+%defattr(-,root,root,-)
+%doc [manual directory] /*
+
+%changelog
+
+ +=== maven === +
+Name:           # see normal package guidelines
+Version:        # see normal package guidelines
+Release:        1%{?dist}
+Summary:        # see normal package guidelines (SNPG)
+
+Group:          # SNPG
+License:        # SNPG
+URL:            # SNPG
+Source0:        # SNPG
+BuildRoot:      %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
+
+BuildRequires:  jpackage-utils
+
+BuildRequires:  java-devel
+
+BuildRequires:  maven2
+
+BuildRequires:    maven2-plugin-compiler
+BuildRequires:    maven2-plugin-install
+BuildRequires:    maven2-plugin-jar
+BuildRequires:    maven2-plugin-javadoc
+BuildRequires:    maven2-plugin-release
+BuildRequires:    maven2-plugin-resources
+BuildRequires:    maven2-plugin-surefire
+
+Requires:       jpackage-utils
+
+Requires(post):       jpackage-utils
+Requires(postun):     jpackage-utils
+
+Requires:       java
+
+%description
+
+%package javadoc
+Summary:        Javadocs for %{name}
+Group:          Development/Documentation
+Requires:       %{name}-%{version}-%{release}
+Requires:       jpackage-utils
+
+%description javadoc
+This package contains the API documentation for %{name}.
+
+%package manual
+Summary:        Manual for %{name}
+Group:          Development/Documentation
+Requires:       jpackage-utils
+Requires:       %{name}-%{version}-%{release}
+
+%description manual
+The manual for %{name}.
+
+%prep
+%setup -q
+
+%build
+
+export MAVEN_REPO_LOCAL=$(pwd)/.m2/repository
+mkdir -p $MAVEN_REPO_LOCAL
+
+mvn-jpp \
+-Dmaven.repo.local=$MAVEN_REPO_LOCAL \
+install javadoc:javadoc
+
+%install
+rm -rf $RPM_BUILD_ROOT
+
+mkdir -p $RPM_BUILD_ROOT%{_javadir}
+cp -p [build path to jar]   \
+$RPM_BUILD_ROOT%{_javadir}/%{name}-%{version}.jar
+
+
+mkdir -p $RPM_BUILD_ROOT%{_javadocdir}/%{name}
+cp -rp [javadoc directory]  \
+$RPM_BUILD_ROOT%{_javadocdir}/%{name}
+
+install -d -m 755 $RPM_BUILD_ROOT%{_datadir}/maven2/poms
+install -pm 644 [path to pom]  \
+$RPM_BUILD_ROOT%{_datadir}/maven2/poms/JPP-%{name}.pom
+
+%add_to_maven_depmap org.apache.maven %{name} %{version} JPP %{name}
+
+%clean
+rm -rf $RPM_BUILD_ROOT
+
+%post
+%update_maven_depmap
+
+%postun
+%update_maven_depmap
+
+%files
+%defattr(-,root,root,-)
+%{_datadir}/maven2/poms
+%{_mavendepmapfragdir}
+%{_javadir}/*
+%doc
+
+%files javadoc
+%defattr(-,root,root,-)
+%{_javadocdir}/%{name}
+
+%files manual
+%defattr(-,root,root,-)
+%doc [manual directory] /*
+
+%changelog
+
+
+ +For detailed instructions on the JPackage/Fedora maven, see the JPackage Maven rpm readme located [http://fedoraproject.org/wiki/Java/JPPMavenReadme here] . + +{{Anchor|JNI}} +== Packaging JAR files that use JNI == + +=== Applicability === + +Java programs that wish to make calls into native libraries do so via the Java Native Interface (JNI). A Java package uses JNI if it contains a .so + +{{Template:Warning}} Note that GCJ packages contain .sos in %{_libdir}/gcj/%{name} but they are not JNI .sos. + +=== Guideline === + +JAR files that require JNI shared objects '''MUST''' be installed in %{_libdir}/%{name}. The JNI shared objects themselves must also be installed in %{_libdir}/%{name}. If the JNI-using code calls System.loadLibrary you'll have to patch it to use System.load, passing it the full path to the dynamic shared object. If the package installs a wrapper script you'll need to manually add %{_libdir}/%{name}/ to CLASSPATH. If you are depending on a JNI-using JAR file, you'll need to add it manually -- build-classpath will not find it. + +=== Rationale === + +This is less convenient, but cleaner from a packaging point-of-view, than putting the JAR file in %{_javadir}, and putting the JNI shared object in %{_libdir} to be loaded from the default library path. First, JNI shared objects are dlopen'd, and dlopen'd shared objects should not be placed directly in %{_libdir} since they are application-private data, and not libraries meant to be linked to directly -- that is, not meant to be shared. Second, placing the JAR file in %{_javadir} causes the build-classpath script to always load it, even when running on a runtime environment of the wrong arch, meaning that the System.loadLibrary line would fail. + +The plan is to eventually eliminate patching of the System.loadLibrary line and wrapper script by making jpackage-utils multilib aware. This involves the following changes: creating %{_libdir}/java and %{_libdir}/jni directories; giving JNI-containing packages the ability to require an architecture-specific runtime environment; adding support for specifying the required runtime architecture in a wrapper script; modifying jpackage-utils's runtime scripts to search %{_libdir}/java; modifying IcedTea to look for JNI shared objects in %{_libdir}/jni. + +The %{_jnidir} rpm macro defines the main JNI jar repository. Like %{_javadir} it is declined in -ext and -x.y.z variants. It follows exactly the same rules as the %{_javadir}-derived tree structure, except that it hosts JAR files that use JNI. + +%{_jnidir} usually expands into /usr/lib/java. + +== Things to avoid == +=== Pre-built JAR files / Other bundled software === +Many Java projects re-ship their dependencies in their own releases. This is unacceptable in Fedora. All packages '''MUST''' be built from source and '''MUST''' enumerate their dependencies with Requires. They '''MUST NOT''' build against or re-ship the pre-included JAR files but instead symlink out to the JAR files provided by dependencies. There may arise rare cases that an upstream project is distributing JAR files that are actually not re-distributable +by Fedora. In this situation, the JAR files themselves should not be redistributed -- even in the source zip. A modified source zip should be created with some sort of modifier in the name (ex. -CLEAN) along with instructions for reproducing. It is a good idea to have something similar to the following at the end of %prep (courtesy David Walluck): + +
+JAR files=""
+for j in $(find -name \*.jar); do
+if [ ! -L $j ] ; then
+JAR files="$JAR files $j"
+fi
+done
+if [ ! -z "$JAR files" ] ; then
+echo "These JAR files should be deleted and symlinked to system JAR files: $JAR files"
+exit 1
+fi
+
+ +=== Javadoc scriptlets === +Older JPackage packages contained %post scriptlets creating %ghost symlinks. These '''MUST''' not appear in Fedora Java packages and are actively being removed at JPackage. + +=== Selected rpmlint issues === +==== class-path-in-manifest ==== +Use sed to remove class-path elements in MANIFEST.MF (or whatever file is being used as the JAR manifest) prior to JAR creation. Example: + +
+sed -i '/class-path/I d' META-INF/MANIFEST.MF
+
+'''Will this preserve the line ending as the [http://java.sun.com/docs/books/tutorial/deployment/jar/downman.html this page] says it must?''' + +== Comments == + +- Which version of java should stuff be built for? Probably 1.5 (for gcj) if possible? Should mention something about this. (VilleSkyttä) + +- I think referencing the GCJ Guidelines, which say the package should build on GCJ, is sufficient, since building on GCJ implies building on 1.5. In general packages should build against/require whatever Java version upstream uses. (ThomasFitzsimmons) + +- Referring to GCJ guidelines would work for me, but the 1.5 issue needs to be explicitly mentioned there, it's not clear to everyone. (VilleSkyttä) + +- "Requires: java" should have a version in it (depending on which version of java it was built for). Possibly also depend on jre instead of java (maybe this is just cosmetic)? (VilleSkyttä) + +- Agreed. I removed the conditional brackets around >= specific_version. I think we should just stick with "java" and not bother with "jre", since that's how it's been done in the past. (ThomasFitzsimmons) + +- Thanks. Spec templates still have the unversioned form, though. (VilleSkyttä) + +- Drop versioned jars and install only unversioned ones? https://www.redhat.com/archives/fedora-devel-list/2008-March/msg02346.html (VilleSkyttä) + +- Fine by me. (ThomasFitzsimmons) + +- For users attempting to introduce a new Java package, we should tell them to first check if the package exists on JPackage (JPackage.org). JPackage packages follow a large majority of the guidelines in this draft, and thus importing should be fairly easy. Additionally, having a package in sync with JPackage will prevent potential incompatibility issues with other JPackage packages. (DeepakBhole) + +- Would we want that to be a '''should''' or a '''must'''? In other words, if a packager wants to deviate from the JPackage package but still falls within the Guidelines do we want to allow them that freedom? + +- My one major issue with this Guideline is the use of "canonical document" in the header for "Java Packaging". We do have other Guidelines that point to external sources for additional sources but they are targeted pieces (For instance, make sure .desktop files provided by the package follow the freedesktop spec [LINK to spec] ). The Java Guidelines are broader and also have an overlay of information (saying that the JPackage Guidelines are the "canonical document" seems to mean "follow the JPackage Guidelines except where the Fedora Guidelines differ"). This makes it harder for a reviewer to understand what's going on in a package that they attempt to review because they need to keep flipping between two Guidelines and trying to remember where one differs from another. It would be better organization if the Java Guidelines took one of the following approaches: 1) Major concerns listed in the Fedora Guidelines. Specifics point to the relevant section of the JPackage Guidelines. For instance: +
+=== Jar File Naming ===
+Jar files must be named after the package name using the [http://www.jpackage.org/cgi-bin/viewvc.cgi/src/jpackage-utils/doc/jpackage-1.5-policy.xhtml?revision=HEAD&root=jpackage#id2434750 JPackage Jar File Naming Guideline] 
+
+For something that differs we could note the derivation and that our Guidelines take precedence: +
+=== Jar File Naming ===
+Our rules are derived from the [http://www.jpackage.org/cgi-bin/viewvc.cgi/src/jpackage-utils/doc/jpackage-1.5-policy.xhtml?revision=HEAD&root=jpackage#id2434750 JPackage Guidelines] 
+but we don't use versioned names for jars.  Please use the following rules instead:
+[...] 
+
+The alternative to this would be to have people read the entirety of the JPackage Guidelines and then point out the places that we differ. We would probably want to do that by importing the JPackage Guidelines to the wiki and annotating the few cases where we differ. Note that we would probably want to decide whether resyncing when JPackage changes a Guidelines be done automatically or if the new version had to be brought in through FPC -> FESCo approval. We would also need someone from the Java team to do that resyncing as we might otherwise be unaware of the changes. From 4c9db006f36cd43e8836bc30fbd9692180d4b96b Mon Sep 17 00:00:00 2001 From: ImportUser Date: May 24 2008 14:13:02 +0000 Subject: [PATCH 10/3559] Imported from MoinMoin --- diff --git a/Packaging:LicensingGuidelines.mw b/Packaging:LicensingGuidelines.mw new file mode 100644 index 0000000..a0455a8 --- /dev/null +++ b/Packaging:LicensingGuidelines.mw @@ -0,0 +1,115 @@ += Licensing Guidelines = + +'''Author:''' [[TomCallaway| Tom 'spot' Callaway]]
+'''Revision:''' 0.05
+'''Initial Draft:''' Thursday August 2, 2007
+'''Last Revised:''' Monday March 31, 2008
+ + + +== Fedora Licensing == +The goal of the Fedora Project is to work with the Linux community to create a complete, general purpose operating system exclusively from Free and Open Source software. + +All software in Fedora must be under licenses in the [http://fedoraproject.org/wiki/Licensing#SoftwareLicenses Fedora licensing list] . This list is based on the licenses approved by the [http://www.gnu.org/philosophy/license-list.html#GPLCompatibleLicenses Free Software Foundation] , [http://www.opensource.org/licenses/ OSI] and consultation with Red Hat Legal. + +If code is multiple licensed, and at least one of the licenses is approved for Fedora, that code can be included in Fedora under the approved license(s) (but only under the terms of the approved license(s)). + +{{Anchor|LicenseText}} +== License Text == +If (and only if) the source package includes the text of the license(s) in its own file, then that file, containing the text of the license(s) for the package, must be included as documentation. + +{{Anchor|LicenseField}} +== License: field == +Every Fedora package must contain a License: entry. Maintainers should be aware that the contents of the License: field are understood to not be legally binding (only the source code itself is), but maintainers must make every possible effort to be accurate when filling the License: field. + +The License: field refers to the licenses of the contents of the '''''binary''''' rpm. When in doubt, ask. + +{{Anchor|ValidLicenseShortNames}} +=== Valid License Short Names === +The License: field must be filled with the appropriate license Short License identifier(s) from the "Good License" tables on the [[Licensing| Fedora Licensing]] page. If your license does not appear in the tables, it needs to be sent to fedora-legal-list@redhat.com (note that this list is moderated, only members may directly post). If the license is approved, it will be added to the appropriate table. + +{{Anchor|Distributable}} +=== "Distributable" === +In the past, Fedora (and Red Hat Linux) packages have used "Distributable" in the License: field. In virtually all of these cases, this was not correct. Fedora no longer permits packages to use "Distributable" as a valid License. If your package contains content which is freely redistributable without restrictions, but does not contain any license other than explicit permission from the content owner/creator, then that package can use "Freely redistributable without restriction" as its License: identifier. + +{{Anchor|Firmware}} +=== Firmware === +The License: field for any firmware that disallows modification should be set to: "Redistributable, no modification permitted". + +{{Anchor|VersionedLicenses}} +=== Versioned licenses === +Some licenses include the version as part of the Short License Identifier. This is only done when multiple versions of the license differ in significant ways (e.g. one revision is GPLv2 incompatible, while a later version is not). Be careful to ensure that you use the correct Short License Identifier, as shown in the tables on the [[Licensing| Fedora Licensing]] page. + +{{Anchor|OrLaterVersionLicenses}} +=== "or later version" licenses === +Some licenses state that either the current version of the license or later versions may be used. It is important to note when a license states this. When a license has an "or later version" clause, we note that by appending a + to the Short License Identifier. +Please note that there are already special Short License Identifiers for GPLv2+ and LGPLv2+, there is no need to append an additional + for those cases. + +{{Anchor|GPLandLGPL}} +=== GPL and LGPL === +Since compatibility of code and library linking is especially complex with GPL and LGPL, Fedora packages can no longer simply use "GPL" or "LGPL" in the License: field. Please refer to the [[Licensing| Fedora Licensing]] page for the acceptable identifiers, and be careful to ensure that you select the correct one. + +{{Anchor|DualLicensing}} +=== Dual Licensing Scenarios === +If your package is dual licensed (or triple licensed, etc.), the spec must reflect this by using "or" as a separator. Note that this only applies when the contents of the package are actually under a dual license, and not when the package contains items under multiple, distinct, and independent licenses. + +Example: +
+Package libfoo is dual licensed as Mozilla Public License v1.1 and GNU General Public License v2 or later. The package spec must have:
+
+License: MPLv1.1 or GPLv2+
+
+ +{{Anchor|MultipleLicensing}} +=== Multiple Licensing Scenarios === +If your package contains files which are under multiple, distinct, and independent licenses, then the spec must reflect this by using "and" as a separator. Fedora maintainers are highly encouraged to avoid this scenario whenever reasonably possible, by dividing files into subpackages (subpackages can each have their own License: field). + +Example: +Package bar-utils contains some files under the Python License, some other files under the GNU Lesser General Public License v2 or later, and one file under the BSD License (no advertising). The package spec must have: +
+License: Python and LGPLv2+ and BSD
+
+ +In addition, the package must contain a comment explaining the multiple licensing breakdown. The actual implementation of this is left to the maintainer. +Some suggested implementations include + +* A comment right above the License: field: +
+License: GPLv2+ and BSD
+
+* Including a file as %doc which contains the licensing breakdown for the packaged files, then using: +
+
+* Noting the license above the appropriate %files section: +
+%files
+%defattr(-,root,root,-)
+%doc Changes
+%{_bindir}/cobra-util
+%{_bindir}/viper-util
+%{_bindir}/gnu-util
+%{_bindir}/rms-util
+%{_bindir}/berkeley-util
+
+ +{{Anchor|CombinedDualAndMultipleLicensing}} +=== Combined Dual and Multiple Licensing Scenario === +If you are unlucky enough that your package possesses items multiple, distinct, and independent licenses...AND some of those items are dual licensed, you must note the dual licensed items by wrapping them with parenthesis (). Otherwise, the guidelines for Dual and Multiple Licensing apply. + +Example: +Package baz-utils contains some files under the Python License, some other files under the GNU Lesser General Public License v2 or later, one file under the BSD License, no advertising, and one file which is dual licensed as Mozilla Public License v1.1 and GNU General Public License v2 or later. The package spec must have: +
+License: Python and LGPLv2+ and BSD and (MPLv1.1 or GPLv2+)
+
+Since this is a multiple licensing scenario, the package must contain a comment explaining the multiple licensing breakdown. The actual implementation of this is left to the maintainer. + +{{Anchor|MixedSourceLicensing}} +=== Mixed Source Licensing Scenario === +In some cases, it is possible for a binary to be generated from multiple source files with compatible, but differing licenses. Thus, the binary file would actually have simultaneous dual licensing (an AND, as opposed to an OR). For example, it is possible that a binary is generated from a source file licensed as BSD with advertising, and another source file licensed as QPL (which specifies that modifications must be shipped as patches). In this scenario, we'd wrap the list of licenses for that binary with parenthesis, example: + +Package spot-utils contains some files under the Python License, but one of the files is generated from a BSD with advertising source file and a QPL source file. +
+License: Python and (BSD with advertising and QPL)
+
+ +{{:Licensing/SoftwareTypes}} From ae1db9c0428d2ffc0000699c4f738dfd4b8c6e4c Mon Sep 17 00:00:00 2001 From: ImportUser Date: May 24 2008 14:13:02 +0000 Subject: [PATCH 12/3559] Imported from MoinMoin --- diff --git a/Packaging:OCaml.mw b/Packaging:OCaml.mw new file mode 100644 index 0000000..8b778fe --- /dev/null +++ b/Packaging:OCaml.mw @@ -0,0 +1,160 @@ + += OCaml Packaging Guidelines = + +This document seeks to document the conventions and customs surrounding the proper packaging of ocaml modules in Fedora. It does not intend to cover all situations, but to codify those practices which have served the Fedora ocaml community well. + + + += Naming = + +The base OCaml compiler is called ocaml. + +OCaml modules, libraries and syntax extensions should be named ocaml-foo. Examples include: ocaml-extlib, ocaml-ssl. + +This naming does not apply to applications written in OCaml, which can be given their normal name. Examples include: mldonkey, virt-top, cduce. + +Rationale: this is how they are named in other distros (Debian, PLD) and this is consistent with perl / php / python naming. + += Packaging libraries = + +[[Image:Packaging_OCaml_ocaml-foolib.spec]] - An example specfile for an imaginary OCaml library called ''foolib''. + +== Main package == + +In order to allow OCaml scripts and the toplevel to use a library, the main package should contain only files matching: +* *.cma (contains the bytecode) +* *.cmi (contains the compiled signature) +* *.so (if present, contains OCaml <-> C stubs) +* META (the findlib description) +* *.so.owner (if present, used by findlib) +* a license file (if present) marked %doc + +*.cmo files are not normally included. There are two exceptions where *.cmo files may be included: +* if file is needed for link (like gtkInit.cmo in lablgtk or std_exit.cmo in OCaml itself), then it must be included to allow the library to be linked properly. +* if the cmo file is a camlp4 preprocessor (like Camlp4OCamlPrinter.cmo in OCaml), then it must be included because otherwise the syntax extension would not be available. + +If the package contains *.so files, then they should have rpaths removed, as per Fedora packaging guidelines. + +The packager should check the META file[[FootNote(http://www.ocaml-programming.de/packages/documentation/findlib/guide-html/x131.html - Findlib users guide - writing META files.)] . If there is no META file, then the packager should create one, include it in the package, and pass it to the upstream maintainer. + +Rationale: OCaml does not support dynamic linking of binaries, and even if it did with the current module hash system for expressing strict typing requirements almost any conceivable change to a library would require the binary to be recompiled. OCaml scripts are the closest we come to dynamic linking, in as much as they do not usually depend on a specific version of a library (albeit this only works because the scripts are recompiled each time they run). + +== -devel subpackage == + +The -devel subpackage of a library should contain all other files required to allow development with the library. Normally these would be: + +* *.a (contains the compiled machine code) +* *.cmxa (describes the compiled machine code) +* *.cmx (if present, allows cross-module optimizations) +* *.mli (contains the signature of the library) + +*.o files are not normally included. There is however one exception -- if file is needed for link (like gtkInit.cmx and gtkInit.o in lablgtk or std_exit.cmx and std_exit.o in OCaml itself), then it should be included. + +*.ml files are not normally included. The exception is if the file describes a module signature ''and'' there is no corresponding .mli file, then the .ml file should be included. (Note that Debian is more permissive and they often distribute *.ml files, allowing the programmer to peek at the implementation of a module). + +Documentation, examples and other articles which are useful to the developer may be included in the -devel sub-package. The license file (which is in the main package) does not need to be included again in the -devel subpackage. + +If the -devel subpackage would only contain documentation files, then the packager may at their discretion place the documentation files in the main package and not have a -devel subpackage at all. + +The -devel subpackage should require the exact name-version-release of the main package (as per Fedora policy). It should also require any C libraries required for development, and sometimes this means an explicit 'Requires' is needed. For example, ocaml-pcre-devel needs an explicit 'Requires: pcre-devel' to make it usable for development. + +Rationale for inclusion of all cmx files: [*.cmx files] are needed even for module included in .cmxa libraries in order to enable cross-module optimizations (inlining, constant propagation and direct function calls). The .o files are not needed. [From a private email from Alain Frisch] + +== -doc subpackage == + +If the documentation files are very large they may be placed in a +separate -doc subpackage, as per normal Fedora guidelines. + +== -data subpackage == + +If the package contains excessively large data files, they may +be placed in a separate -data subpackage, as per normal Fedora guidelines. + +== Requires and provides == + +For each module that library A uses from another library B, library A must have a Requires of the form: +ocaml(Modulename) = MD5hash +Similarly for each module that library A may provide to other libraries, library A must have a Provides of the same form. + +A library must depend on the precise version of the OCaml compiler, for example: +ocaml(runtime) = 3.10.0 + +There are two scripts in the base ocaml package which automatically calculate the right Requires and Provides for a library. To use them, just add the following to the spec file: + +
+%define _use_internal_dependency_generator 0
+%define __find_requires /usr/lib/rpm/ocaml-find-requires.sh
+%define __find_provides /usr/lib/rpm/ocaml-find-provides.sh
+
+ +Rationale: OCaml does not offer binary compatibility between releases of the compiler (even between bugfixes). Furthermore the module system uses a hash over the interface and some internals of a module which basically means a library or program must be linked against the identical modules it was compiled with. The Requires and Provides lines express the module name and hash so that RPM enforces the same requirements as the OCaml linker itself. Please see the further reading at the end of this page for more details. + += Packaging binaries = + +The rules for packaging OCaml binaries are not significantly different from packaging ordinary programs (see ["Packaging/Guidelines"] ). + +However if the OCaml package also contains a library, then you should follow the rules above for packaging libraries as well. + +== Stripping binaries == + +Binaries should be stripped, as per ordinary Fedora packaging guidelines. + +There is one exception where a binary should not be stripped. If the package was compiled with ocamlc -custom then the package contains bytecode which strip will remove, thus rendering the binary inoperable. It is easy to test for this: If after stripping, any attempt to run the binary results in the message ''No bytecode file specified'' then the binary is compiled like this and should not be stripped. + +Rationale: http://bugs.debian.org/256900 + +== Providing best possible binaries == + +The packager should attempt to ship native code compiled binaries in preference to bytecode compiled binaries, where this is possible. + += Bytecode-only architectures = + +The OCaml native code compiler (ocamlopt) contains code generators for popular architectures, but not for every architecture that Fedora might support. On such architectures, the spec file should still build bytecode libraries and binaries. + +To test for presence of the native compiler, do: + +
+%define opt %(test -x %{_bindir}/ocamlopt && echo 1 || echo 0)
+
+ +then define conditional sections in %build, %install and %files if necessary. For example: + +
+%build
+make byte
+%if %opt
+make opt
+%endif
+
+ +To test that your spec file will work on such an architecture, temporarily remove or rename /usr/bin/ocamlopt and /usr/bin/ocamlopt.opt while building. + +Rationale: Debian packaging policy section 2.3 does the same thing. + += Unnecessary files = + +The following files should not normally be distributed: + +* *.cmo object files. Exception: see above. +* *.o for corresponding *.cmx. Exception: see above. +* *.ml sources. Exception: see above. + += Security issues in OCaml libraries = + +If a security issue arises in an OCaml library, then all libraries and binaries which depend on it must be recompiled. + +OCaml scripts do not need to be changed (unless resolving the security issue requires changing the public interface to the library and the script is broken by the change). This is because OCaml scripts are recompiled each time they run. + += Further reading = + +* http://pkg-ocaml-maint.alioth.debian.org/ocaml_packaging_policy.txt - Debian packaging policy document. +* http://docs.pld-linux.org/ocaml.html +* http://lists.debian.org/debian-ocaml-maint/2005/01/threads.html#00042 - Thread on ABI compatibility of different versions of OCaml. +* https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01234.html - Explains lack of dynamic linking in upstream. +* https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01280.html - Proposal to include MD5 sums in RPM deps. +* https://bugzilla.redhat.com/show_bug.cgi?id=433783 - Common rpmlint errors and warnings in OCaml packages. + += Footnotes = + +[[FootNote] From b1c45c72eb865610d35d0eec6a832449416f7445 Mon Sep 17 00:00:00 2001 From: ImportUser Date: May 24 2008 14:13:02 +0000 Subject: [PATCH 14/3559] Imported from MoinMoin --- diff --git a/Packaging:OpenOffice.orgExtensions.mw b/Packaging:OpenOffice.orgExtensions.mw new file mode 100644 index 0000000..9c49b89 --- /dev/null +++ b/Packaging:OpenOffice.orgExtensions.mw @@ -0,0 +1,41 @@ + +== OpenOffice.org extension rpm guidelines == + +1. Extensions deinstalled with unopkg remove '''Must''' have a %postun of 'unopkg list --shared > /dev/null 2>&1' because the actual removal of files is deferred until the next start, so this ensures that this takes place under the control of your rpm on deinstallation. +1. Extensions '''Should''' be both installed unpacked and then registered with 'unopkg --link' where possible to save disk-space. Otherwise during registration of a packed .oxt or .uno.pkg with unopkg the package is automatically unzipped and the contents copied into a persistent cache directory. Using -link and an unpacked .oxt/.uno.pkg dir allows this additional copy to be omitted and importantly allows the rest of the standard rpmbuild tooling to determine additional autorequires for a package or find flaws that cannot be seen in the opaque zip case. +1. Unpacked Extensions '''Must''' be installed in a dir called [http://extensions.openoffice.org/servlets/ReadMsg?list=dev&msgNo=142 NAME.oxt, NAME.uno.pkg or NAME.zip] +1. An extension should normally just be able to just Require: an appropriate openoffice.org component e.g. openoffice.org-core, without a specific n-v-r as extensions use the stable UNO abi which rarely changes, and then only to add extra apis. So unless you require a specific feature of a openoffice.org release there is no need to require a specific n-v-r and force a rebuild on every n-v-r of openoffice.org. +1. extensions '''Must''' be named openoffice.org-FOO. The location where an extension is unpacked '''Must''' be in an arch or arch-independent location depending on if the extension has been written in an arch or arch-independent language. e.g. StarBasic and Java only extensions are noarch and '''Must''' be unpacked under /usr/share/openoffice.org/extensions, while e.g. C++ extensions are arch-dependant and '''Must''' be unpacked under %{_libdir}/openoffice.org/extensions. +1. extensions are similar to e.g. xorg video drivers in that there exist proprietary or binary only extensions, but of course normal Fedora rules apply to what extensions can be packaged, i.e. see normal packaging licensing etc. rules. The license '''Must''' be acceptable, and the package '''Must''' be built from source. +1. extensions can be written in any language that has a uno binding, e.g. C++, python, java or StarBasic. Consider the additional packaging guidelines of the language that the extension is written in if such guidelines exists. +1. Some obsolete versions of openoffice.org < F9 had bugs in unopkg, so the minimum Requires are: 2.3.0-6.12 for F8, and 2.3.0-6.6 for F7 + +.. +An example is... +
+Requires(pre):    openoffice.org-core >= 2.3.0-6.6
+Requires(post):   openoffice.org-core >= 2.3.0-6.6
+Requires(preun):  openoffice.org-core >= 2.3.0-6.6
+Requires(postun): openoffice.org-core >= 2.3.0-6.6
+
+%install
+mkdir -p $RPM_BUILD_ROOT%{_datadir}/openoffice.org/extensions/writer2latex.uno.pkg
+unzip target/lib/writer2latex.uno.pkg -d $RPM_BUILD_ROOT%{_datadir}/openoffice.org/extensions/writer2latex.uno.pkg
+
+%pre
+if [ $1 -gt 1 ] ; then
+unopkg remove --shared org.openoffice.legacy.writer2latex.uno.pkg || :
+fi
+
+%post
+unopkg add --shared --link %{_datadir}/writer2latex.uno.pkg || :
+
+%preun
+if [ $1 -eq 0 ] ; then
+unopkg remove --shared org.openoffice.legacy.writer2latex.uno.pkg || :
+fi
+
+%postun
+unopkg list --shared > /dev/null 2>&1 || :
+
From bd117b2de2a6fc3b7f613b37f692cc26e0cf33e5 Mon Sep 17 00:00:00 2001 From: ImportUser Date: May 24 2008 14:13:02 +0000 Subject: [PATCH 16/3559] Imported from MoinMoin --- diff --git a/Packaging:Debuginfo.mw b/Packaging:Debuginfo.mw new file mode 100644 index 0000000..6d5df13 --- /dev/null +++ b/Packaging:Debuginfo.mw @@ -0,0 +1,47 @@ += Debuginfo packages = + + + +This page contains information about debuginfo packages and common pitfalls about them for packagers. For usage information and an explanation why debuginfo packages are important, see StackTraces. + +The discussion on this page assumes that the redhat-rpm-config package is installed. + +== Checking your debuginfo package for usefulness == + +A useful debuginfo package contains stripped symbols from ELF binaries (*.debug in /usr/lib/debug) as well as the source code related to them (in /usr/src/debug). The script that generates the packages is /usr/lib/rpm/find-debuginfo.sh, read it through to get a basic understanding of how they're generated. If your debuginfo package doesn't contain any files, or is missing the sources or the size of the *.debug files in it is unexpectedly small (typically *.debug are larger than the corresponding binary it was stripped from), it's likely that there's a flaw in your package. That's not always the case though, read on. + +=== Useless or incomplete debuginfo packages due to packaging issues === + +Useless or incomplete debuginfo packages are often a result of packaging flaws. Typical flaws that often manifest themselves as debuginfo packages containing no files: + +* The specfile or the package's build routines explicitly strip symbols out of the binaries. Look for invocations of strip, install -s, ld -s, or gcc -s etc and get rid of them (or the -s flags). The method how to do that varies, some examples cases include patching, using %configure or a make target that prevents the strip from happening, and/or overriding a strip command like for example make install STRIP=/bin/true +* The package is not marked as noarch, but does not contain any architecture dependent things (native binaries, architecture dependent paths etc). True noarch packages contain nothing rpmbuild could strip from them, so it's expected that they're empty if BuildArch: noarch is missing. If that's the case, make the package noarch. +* find-debuginfo.sh processes only files that are executable when it's run; for practical purposes one can assume that happens under the hood after the %install section. Make sure that all ELF binaries (executables, shared libraries, DSO's) are executable at end of %install. +* find-debuginfo.sh does not process setuid or setgid binaries. There's a [https://bugzilla.redhat.com/117858 bug filed against rpmbuild] about that, but until it is fixed in the distros your package is targeted at, make sure that all your binaries do _not_ have the setuid/setgid bits at end of %install, and restore them in the %files section using %attr(...) /path/to/file + +Flaws that manifest themselves as unexpectedly small *.debug in the debuginfo package and/or source files missing: + +* The package was built without passing -g to gcc or g++. Without -g, no or insufficient information for debuginfo packages is generated, make sure that it is being used. +* Note that the default CFLAGS and CXXFLAGS of the distro already contain -g, so if those flags are being honored, it should be already in use. If not, suboptimal debuginfo packages are not the only problem; the package is probably also compiled without the security enhancing options of recent compiler versions. Make sure that $RPM_OPT_FLAGS is being honored and used. +* strip -g was used on the binaries; see above for possible remedies. + +=== Useless or incomplete debuginfo packages due to other reasons === + +Empty debuginfo packages may also be generated in situations where there are no obvious packaging flaws present. Sometimes these are because of limitations of find-debuginfo.sh, sometimes not. Some usual cases: + +* Packages whose only architecture dependent binary part is a static library or many of them +* R and Mono packages '''TODO: people knowledgeable of R and/or Mono, verify these''' + +If you wish to disable generation of the useless debuginfo package while waiting for improvements to find-debuginfo.sh or if it's unlikely that it could be enhanced to produce a good debuginfo for your package (for example no architecture dependent files, but package is not noarch because of the installation paths it uses), use %define debug_package %{nil} in the specfile, and be sure to add a comment next to it explaining why it was done. + +== Missing debuginfo packages == + +It is normal for noarch package builds to not produce a debuginfo package. If it's missing in other cases (where it has not been explicitly disabled), something's wrong. One such case is a [https://bugzilla.redhat.com/192422 missing %build section] with some rpmbuild versions. + +== Resources == + +* debuginfo package listings for Fedora Core and Extras, sorted by size. Most debuginfo packages roughly up to 20kB in size are candidates that should be examined - however significantly larger -debuginfo packages may suffer from the same problems too, esp. in the "missing -g" case. (URLs not pointing to download.fedora.redhat.com due to missing sort option in its dir listings.) +* http://mirrors.kernel.org/fedora/core/development/i386/debug/?C=S;O=A +* http://mirrors.kernel.org/fedora/extras/development/i386/debug/?C=S;O=A +* StackTraces +* rpmlint >= 0.77 From 0f669206732dd7544c672cb266b276b6ef756a69 Mon Sep 17 00:00:00 2001 From: ImportUser Date: May 24 2008 14:13:02 +0000 Subject: [PATCH 18/3559] Imported from MoinMoin --- diff --git a/Packaging:Naming.mw b/Packaging:Naming.mw new file mode 100644 index 0000000..2462286 --- /dev/null +++ b/Packaging:Naming.mw @@ -0,0 +1,433 @@ + += Package Naming Guidelines = + +'''Author:''' [[TomCallaway| Tom 'spot' Callaway]]
+'''Revision:''' 0.49
+'''Initial Draft:''' Wednesday Feb 23, 2005
+'''Last Revised:''' Friday, April 25, 2008
+ + + +{{Anchor|CommonCharacterSet}} +== Common Character Set for Package Naming == +While Fedora is an international community, for consistency and usability, there needs to be a common character set for package naming. + +Specifically, all Fedora packages must be named using only the following ASCII characters. These characters are displayed here: + +
+abcdefghijklmnopqrstuvwxyz
+ABCDEFGHIJKLMNOPQRSTUVWXYZ
+0123456789-._+
+
+ +=== General Naming === +When naming a package, the name should match the upstream tarball or project name from which this software came. In some cases, this naming choice may be more complicated. If this package has been packaged by other distributions/packagers in the past, then you should try to match their name for consistency. In any case, try to use your best judgement, and other developers will help in the final decision. + +Additionally, it is possible that the upstream name does not fall into the [[CommonCharacterSet| Common Character Set]] . If this is the case, refer to: [[Transliteration| When Upstream Naming is outside of the specified character set]] . + +=== Separators === +When naming packages for Fedora, the maintainer must use the dash '-' as the delimiter for name parts. The maintainer must NOT use an underscore '_', a plus '+', or a period '.' as a delimiter. + +There are a few exceptions to the no underscore '_' rule. +* httpd, pam, and SDL addon packages are excluded, refer to "'''[[AddonHttpdPamSDL| Addon Packages (httpd, pam and SDL)]] '''". +* packages that are locale specific, and use the locale in the name are excluded, refer to "'''[[AddonLocale| Addon Packages (locale)]] '''". +* packages where the upstream name naturally contains an underscore are excluded from this. Examples of these packages include: +
+arptables_jf
+dhcpv6_client
+java_cup
+knm_new
+libart_lgpl
+lm_sensors
+microcode_ctl
+nss_db
+nss_ldap
+sg3_utils
+tcp_wrappers
+
+ +If in doubt, ask on fedora-devel-list. + +{{Anchor|Transliteration}} +=== When Upstream Naming is outside of the specified character set === +Fedora recognizes that the task of converting text to the specified ASCII character set (aka transliteration) is difficult. Accordingly, when the upstream name is outside of the specified ASCII character set, the Fedora package maintainer should first contact the upstream for that software and ask them for a transliteration of the name for Fedora to use. + +If (and only if) the upstream is unable, unwilling, or unavailable to provide a transliterated name, the Fedora packager must choose to either perform their own transliteration, or withdraw the package from consideration in Fedora. + +When deciding how to transliterate a package name, the Fedora packager should look to see what (if any) other distributions have done for that package's name, and take that into account. + +{{Anchor|OriginalProvides}} +=== Extra Provides === +Transliterated packages may Provide: the original, non-transliterated name, but are not required to do so. + +{{Anchor|MultiplePackages}} +== Multiple packages with the same base name == +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. One package should use the base name with no versions and all other addons should note their version in the name. + +'''Example:''' +
openssl occasionally has multiple versions in Fedora for backwards compatibility.
+The most current version of openssl has Name: openssl
+The previous version of openssl has Name: openssl096b
+Note that we do not use delimiters in the name in this situation, we remove the period '.' from the version number and attach it to the name. + +{{Anchor|SpecName}} +== Spec file name == +The spec file should be named using the %{name}.spec scheme. This is to make it easier for people to find the appropriate spec when they install a src.rpm. + +Example: +
+If your package is named foo-1.0.0-1.src.rpm, then the spec file should be named foo.spec.
+
+ +There is normally no need to include the %{version} in the spec file name. If you are packaging multiple versions of a package for simultaneous use, they should already reflect the version in the %{name}.spec scheme (refer to [[MultiplePackages| Multiple Packages with the same base name]] for details). In normal cases adding the version can cause the spec file's history to be lost when a package's version is upgraded. + +As a special exception, there are a few packages which are allowed to have a version in their spec filename. This is because they had the version in their name when they were merged from Fedora Core's cvs and removing the version at that time would have *lost* history: +* gcc +* [Please ask the packaging committee to add your package if you think it should also fall under this exception.] + +This exception will go away when any of the following criteria are met: +1. We move the packages to a revision control system which is able to preserve history across a file rename. +1. The package spec file is going to be renamed anyway (for example, gcc41.spec is currently in cvs. When gcc is upgraded to gcc-4.2, the new spec will be created as gcc.spec '''not''' gcc42.spec) + + +{{Anchor|PackageVersion}} +== Package Version == +The Version field in the spec is where the maintainer should put the current version of the software being packaged. +If the version is non-numeric (contains tags that are not numbers), you may need to include the additional non-numeric characters in the release field. + +There are four cases where the version contains non-numeric characters: + +* Pre-release packages: Packages released as "pre-release" versions, prior to a "final" version. Example tags include "alpha", "beta", "rc", "cvs". Unfortunately, we cannot simply put these letters into the version tag, so we use the Release field for this. Details can be found here: [[NonNumericRelease| Non-Numeric Version in Release]] + +* Post-release packages: Packages released after a "final" version. These packages contain the same numeric version as the "final" version, but have an additional non-numeric identifier. Details can be found here: [[NonNumericRelease| Non-Numeric Version in Release]] + +* Snapshot packages: Packages built from cvs or subversion snapshots. These packages could be either "pre" or "post" release packages. Details can be found here: [[NonNumericRelease| Non-Numeric Version in Release]] + +* JPackage derived Fedora packages: Packages which derive from JPackage RPMS follow a special policy. Details can be found here: [wiki:Self:Packaging/JPackagePolicy JPackagePolicy] + +{{Anchor|PackageRelease}} +== Package Release == +In the past, Fedora.us used 0.fdr as a release prefix to identify Fedora.us packages. In Fedora, this repository "tagging" is unnecessary, and should not be used. The release number (referred to in some older documentation as a "vepoch") is how the maintainer marks build revisions, starting from 1. When a minor change (spec file changed, patch added/removed) occurs, or a package is rebuilt to use newer headers or libraries, the release number should be incremented. If a major change (new version of the software being packaged) occurs, the version number should be changed to reflect the new software version, and the release number should be reset to 1. + +{{Anchor|NonNumericRelease}} +=== Non-Numeric Version in Release === +There are three cases in which non-numeric versions occur in the Release field: + +* Pre-release packages +* Snapshot packages +* Post-release packages + +{{Anchor|PreReleasePackages}} +==== Pre-Release packages ==== +Non-numeric versioned "pre-release" packages can be problematic so they must be treated with care. +These are cases where the upstream "pre-release" version has letters rather than simple numbers in their version. Often they have tags like alpha, beta, rc, or letters like a and b denoting that it is a version before the "final" number. Unfortunately, we cannot simply put these letters into the version tag, so we'll use the Release field for this. + +Release Tag for Pre-Release Packages: +0.%{X}.%{alphatag} + +Where %{X} is the release number increment, and %{alphatag} is the string that came from the version. +In this case, the period '.' should be used as the delimiter between the release number increment, and the non-numeric version string. No other extra characters should appear in the Release field. This is to prevent Release values such as "3jpp_2fc.42-spotwashere". + +Example (pre-release): +
+mozilla-1.4a.tar.gz (this is a pre-release, version 1.4a of mozilla)
+mozilla-1.4.tar.gz (this is what the 1.4 release will actually look like)
+mozilla-1.4-0.1.a  (so, this is the acceptable Fedora %{name}-%{version}-%{release})
+mozilla-1.4-1 (and this is what the 1.4 release Fedora %{name}-%{version}-%{release} should be)
+
+ +Example (pre-release): +
+alsa-lib-0.9.2beta1.tar.gz (this is a beta release of alsa-lib, version 0.9.2beta1)
+alsa-lib-0.9.2-0.1.beta1 (this is the correct Fedora %{name}-%{version}-%{release})
+alsa-lib-0.9.2-0.2.beta1 (this is an incremented Fedora %{name}-%{version}-%{release}. Note that the first 0 is not incremented.)
+
+ +Example (pre-release svn checkout): +
+kismet-0-0.1.20040110svn (this is a pre-release, svn checkout of kismet)
+kismet-0-0.2.20040110svn (this is a bugfix to the previous package)
+kismet-0-0.3.20040204svn (this is a new svn checkout, note the increment of %{X})
+kismet-1.0-1 (this is the formal release of kismet 1.0)
+
+ +Upgrade Path Example (mozilla): +
+mozilla-1.4-0.1.a (add a new patch on top of 1.4a)
+mozilla-1.4-0.2.a (add another new patch on top of 1.4a)
+mozilla-1.4-0.3.a (upgrade to 1.4b)
+mozilla-1.4-0.4.b (add a new patch on top of 1.4b)
+mozilla-1.4-0.5.b (move to 1.4 "final" version, and to a normal version)
+mozilla-1.4-1 (add a new patch on top of 1.4 "final")
+mozilla-1.4-2
+
+ +Upgrade Path Example (alsa-lib): +
+alsa-lib-0.9.2-0.1.beta1 (add a new patch on top of 0.9.2beta1)
+alsa-lib-0.9.2-0.2.beta1 (upgrade to 0.9.2beta2)
+alsa-lib-0.9.2-0.3.beta2 (upgrade to 0.9.2beta3)
+alsa-lib-0.9.2-0.4.beta3 (add a new patch on top of 0.9.2beta3)
+alsa-lib-0.9.2-0.5.beta3 (upgrade to 0.9.2rc1)
+alsa-lib-0.9.2-0.6.rc1 (upgrade to 0.9.2rc2)
+alsa-lib-0.9.2-0.7.rc2 (upgrade to 0.9.2 "final", version becomes normal)
+alsa-lib-0.9.2-1 (add a new patch on top of 0.9.2 "final")
+alsa-lib-0.9.2-2
+
+ +{{Anchor|SnapshotPackages}} +==== Snapshot packages ==== + +If a snapshot package is considered a "pre-release package", you should follow the guidelines listed in [[PreReleasePackages| Pre-Release Packages]] , and use an %{alphatag} beginning with the date in YYYYMMDD format and followed by up to 16 (ASCII) alphanumeric characters of your choosing. The date should reference the date the checkout was taken; the rest can be as simple as "cvs" or "snap", or a subversion change number like "svn12345" or an abbreviated git hash like "git5aef11739b". + +If a snapshot package is considered a "post-release package", the following applies: + +Release Tag for Post-Release Snapshot Packages: +%{X}.%{alphatag} + +Where %{X} is the build number from any previous "stable" package build, incremented by one (if no previous stable package build, use 1), and %{alphatag} is the checkout string, as described above. + +Example (post-release cvs): +
+kismet-1.0-1 (this is the formal release of kismet 1.0)
+kismet-1.0-2 (this is a bugfix build to the 1.0 release)
+kismet-1.0-3.20050515cvs (move to a post-release cvs checkout)
+kismet-1.0-4.20050515cvs (bugfix to the post-release cvs checkout)
+kismet-1.0-5.20050517cvs (new cvs checkout, note the increment of %{X})
+
+ +{{Anchor|PostReleasePackages}} +==== Post-Release packages ==== +Like pre-release packages, non-numeric versioned "post-release" packages can be problematic and also must be treated with care. These fall under two generic categories: + +* Properly ordered simple versions. These are usually due to quick bugfix releases, such as openssl-0.9.6b or gkrellm-2.1.7a. As new versions come out, the non-numeric tag is properly incremented (e.g. openssl-0.9.6c) or the numeric version is increased and the non-numeric tag is dropped (openssl-0.9.7). In this case, the non-numeric characters are permitted in the Version: field. +* When upstream uses versions that attempt to have meaning to humans instead of being easy for a computer to order. For example, GA1, CR2, PR3. In this case, the non-numeric string can be put in the Release: field using the following syntax: %{X}.%{posttag} + +In this syntax, %{X} is the release number increment, and %{posttag} is the string that came from the version. Here, the period '.' should be used as the delimiter between the release number increment, and the non-numeric version string. No other extra characters should appear in the Release field. + +Example (complicated post-release): +
+foo-1.1.0-0.1.BETA (this is a prerelease, first beta)
+foo-1.1.0-0.2.BETA1 (this is a prerelease, second beta)
+foo-1.1.0-0.3.BETA2 (this is a prerelease, third beta)
+foo-1.1.0-0.4.CR1 (this is a prerelease, candidate release 1)
+foo-1.1.0-0.5.CR2 (this is a prerelease, candidate release 2)
+foo-1.1.0-1 (final release)
+foo-1.1.0-2.GA1 (post release, GA1)
+foo-1.1.0-3.CP1 (post release, CP1, after GA1)
+foo-1.1.0-4.CP2 (post release, CP2, after CP1)
+foo-1.1.0-5.SP1 (post release, SP1, after CP2)
+foo-1.1.0-6.SP1_CP1 (post release, SP1_CP1, after SP1)
+
+ +It is important to be careful with the post-release scheme, to ensure that package ordering is correct. It may be necessary to use Epoch to ensure that the current package is considered newer than the previous package. In such cases, the packager should try to convince upstream to be more reasonable with their post-release versioning. + +Also, packagers using the post-release scheme should put a comment in their spec file with a brief description of the upstream conventions for naming/versioning that are being worked around. + +{{Anchor|DistTag}} +=== Using the %{?dist} Tag === +If you wish to use a single spec file to build for multiple distributions, you can use the %{?dist} tag in the Release field. +Please refer to the DistTag documentation for the details on the appropriate way to do this. + +{{Anchor|DistBump}} +=== Minor release bumps for old branches === +Sometimes, you may find yourself in a situation where an older branch needs a fix, but the newer branches are fine. For example, if foo = 1.0-1%{?dist} in FC-4 and FC-5, and only FC-4 needs a fix. Normally, you would need to bump the release in each of the branches to ensure that FC-4 < FC-5, but that is a waste of time and energy for the newer branches which do not need to be touched. + +In this case, you can add an extra digit (prefixed by a period) to the very end of the release tag in the FC-4 branch, instead of bumping it the usual way. +Example:
+
+
+Release: 1%{?dist}
+
+ +
+
+Release: 1%{?dist}.1
+
+ +This will make a foo-1.0-1.fc4.1 package, which is still less than the foo-1.0-1.fc5 package in the FC-5 branch. + +As necessary, the last digit (the minor release bump) can be incremented on a per-branch basis as needed.
+This is ONLY permitted if you are using disttags in your Release field. + +'''BE CAREFUL WITH THIS!''' You always want to make sure that packages in branches can be upgraded to packages in more recent branches. Or to put it simply, FC-4 < FC-5 < FC-6. There is a tool in the rpmdevtools package called rpmdev-vercmp. This tool will prompt you for two sets of Epoch, Version, and Release, then tell you which is considered newer by rpm. + + +{{Anchor|CaseSensitivity}} +== Case Sensitivity == +In Fedora packaging, the maintainer should use his/her best judgement when considering how to name the package. While case sensitivity is not a mandatory requirement, case should only be used where necessary. Keep in mind to respect the wishes of the upstream maintainers. If they refer to their application as "ORBit", you should use "ORBit" as the package name, and not "orbit". However, if they do not express any preference of case, you should default to lowercase naming.
+
+The exception to this is for perl module packaging. The CPAN Group and Type should be capitalized in the name, as if they were proper nouns . (Refer to '''[[AddonPerl| Addon Packages (perl modules)]] ''' for details.) + +{{Anchor|PackageRename}} +== Renaming/replacing existing packages == + +In the event that it becomes necessary to rename or replace an existing package, the new package should make the change transparent to end users to the extent applicable. + +If a package is being renamed without any functional changes, or is a compatible enough replacement to an existing package (where "enough" means that it includes only changes of magnitude that are commonly found in version upgrade changes), provide clean upgrade paths and compatibility with: + +
+Provides: oldpackagename = $provEVR
+Obsoletes: oldpackagename < $obsEVR
+
+ +$provEVR refers to an (Epoch-)Version-Release tuple the original unchanged package would have had if it had been version or release bumped, using macros. $obsEVR is an (Epoch-)Version-Release tuple arranged so that there is a clean upgrade path, but without gratuitously polluting the version space upwards, usually not using macros. + +If a package supersedes/replaces an existing package without being a compatible enough replacement as defined in above, use only the Obsoletes from above. + +If the provided package had an Epoch set, it must be preserved in both the Provides and Obsoletes. It may and should be removed from the actual new package. + +Example: foo being renamed to bar, bar is compatible with foo, and the last foo package release being foo-1.0-3%{?dist} with Epoch: 2; add to bar (and similarly for all subpackages as applicable): + +
+Version: 1.0
+Release: 4%{?dist}
+Provides: foo = 2:%{version}-%{release}
+Obsoletes: foo < 2:1.0-4
+
+ +If there is no standard naming for a package or other long term naming compatibility requirements involved with the rename, the Provides should be assumed to be deprecated and short lived and removed in the distro release after the next one (ie. if introduced in FC-X, keep in all subsequent package revisions for distros FC-X and FC-(X+1), drop in FC-(X+2)), and the distro version where it is planned to be dropped documented in a comment in the specfile. Maintainers of affected packages should be notified and encouraged to switch to use the new name. Forward compatibility Provides: in older distro branches can be considered in order to make it possible for package maintainers to keep same simple specfiles between branches but still switch to the newer name. + +For packages that are not usually pulled in by using the package name as the dependency such as library only packages (which are pulled in through library soname depenencies), there's usually no need to add the Provides. Note however that the -devel subpackages of lib packages are pulled in as build dependencies using the package name, so adding the Provides is often appropriate there. + +{{Anchor|DocumentationSubPackages}} +== Documentation SubPackages == +Large documentation files should go in a subpackage. This subpackage must be named with the format: %{name}-doc . +The definition of large is left up to the packager's best judgement, but is not restricted to size. Large can refer to either size or quantity. + +{{Anchor|AddonGeneral}} +== Addon Packages (General) == +If a new package is considered an "addon" package that enhances or adds a new functionality to an existing Fedora package without being useful on its own, its name should reflect this fact.
+
+The new package ("child") should prepend the "parent" package in its name, in the format: %{parent}-%{child}. + +'''Examples:''' +
+gnome-applet-netmon (netmon applet for gnome, relies on gnome)
+php-adodb (adodb functionality for php, relies on php)
+python-twisted (the twisted module for python, relies on python)
+tetex-arabtex (arabic functionality for tetex, relies on tetex)
+xmms-cdread (direct cd read functionality for xmms, relies on xmms)
+
+ +There are some exceptions to this general addon package naming policy, and they are noted below.
+ +{{Anchor|AddonHttpdPamSDL}} +== Addon Packages (httpd, pam, and SDL) == +Packages that rely on Apache httpd, pam, or SDL as a parent use a slightly different naming scheme. +pam and SDL addons use the format: %{parent}_%{child}, with an underscore "_" as a delimiter. +Apache httpd addons use the format: mod_%{child}, with an underscore "_" as a delimiter. +This naming scheme is usually the same as used for the source tarball name.
+ +'''Examples:''' +
+mod_perl (perl components for Apache httpd, relies on httpd)
+pam_krb5 (krb5 components for pam, relies on pam)
+SDL_gfx (Additional graphics components for SDL, relies on SDL)
+SDL_ttf (TrueType font rendering support for SDL, relies on SDL)
+
+ +{{Anchor|AddonEclipse}} +== Addon Packages (Eclipse plugins) == +Eclipse plugin packages MUST be named eclipse-. For example, a package of the anyedit plugin for Eclipse would by named eclipse-anyedit. + +{{Anchor|AddonEmacs}} +== Addon Packages (emacs components) == +Packages of emacs add-on components (code that adds additional functionality to emacs compatible editors) have their own naming +scheme. It is often the case that a component will add functionality to several different compatible editors, such as GNU +Emacs and XEmacs (and possibly development versions of these editors). The package name should take into account the upstream name of the +emacs component. + +Where a component adds functionality to more than one emacs compatible editor, the package name should be of the form emacs-common-$NAME. In this +case, the main package should contain only files common to all emacs compatible editors, and the code specific to each should be placed in a +subpackage reflecting the specific editor $EDITOR-$NAME eg. xemacs-$NAME, emacs-$NAME (the latter being the package specific to GNU Emacs). An +example of this scheme can be found in the package emacs-common-muse. + +Where a component is designed to add functionality to only a single emacs compatible editor, the main package name should reflect this by being +called $EDITOR-$NAME. An example of this situation can be found in the package emacs-auctex, which is built only for GNU Emacs. + + +'''Examples:''' +
+emacs-common-muse (muse component for all emacs compatible editors)
+xemacs-muse (muse component subpackage that provides XEmacs specific files)
+emacs-autex (autex component only for GNU Emacs)
+
+ +{{Anchor|AddonErlang}} +== Addon Packages (erlang modules) == +Packages of erlang modules (thus they rely on erlang as a parent) have their own naming scheme. They should take into account the upstream name of the erlang module. This makes a package name format of erlang-$NAME. When in doubt, use the name of the module that you use when importing it into a script. + +'''Example: ''' +
+erlang-esdl (erlang module named esdl)
+
+ +{{Anchor|AddonOCaml}} +== Addon Packages (OCaml modules) == +OCaml modules, libraries and syntax extensions should be named ocaml-foo. Examples include: ocaml-extlib, ocaml-ssl. + +This naming does not apply to applications written in OCaml, which can be given their normal name. Examples include: mldonkey, virt-top, cduce. + +{{Anchor|AddonOpenOffice.org}} +== Addon Packages (OpenOffice.org extensions) == +Packages of OpenOffice.org extensions (thus they rely on OpenOffice.org as a parent) have their own naming scheme. They must take into account the upstream name of the OpenOffice.org extension. This makes a package name format of openoffice.org-$NAME. + +{{Anchor|AddonPerl}} +== Addon Packages (perl modules) == +Packages of perl modules (thus they rely on perl as a parent) use a slightly different naming scheme. They should be named perl-CPANDIST where CPANDIST is the name of the packaged CPAN module distribution (which is almost always also the unit of perl module packaging). In the rare cases when a CPAN module distribution needs to be split into smaller subpackages eg. due to dependencies, the extra subpackages should be named perl-CPANDIST-Something.
+ +'''Examples: ''' +
+perl-Archive-Zip (Archive-Zip is the CPAN distribution name)
+perl-Cache-Cache (Cache-Cache is the CPAN distribution name)
+
+ +{{Anchor|AddonPHP}} +== Addon Packages (php modules) == +For details on the PHP naming scheme, see [[Packaging/PHP#NamingScheme]] . + +{{Anchor|AddonPython}} +== Addon Packages (python modules) == +Packages of python modules (thus they rely on python as a parent) use a slightly different naming scheme. They should take into account the upstream name of the python module. This makes a package name format of python-$NAME. When in doubt, use the name of the module that you type to import it in a script. + +'''Examples: ''' +
+python-psycopg  (python module named psycopg)
+python-simpletal (python module named simpletal)
+python-tpg (python module named tpg)
+
+ +There is an exception to this rule. If the upstream source has "py" (or "Py") in its name, you can use that name for the package. So, for example, pygtk is acceptable. + +{{Anchor|AddonR}} +== Addon Packages (R modules) == +Packages of R modules (thus they rely on R as a parent) have their own naming scheme. They should take into account the upstream name of the R module. This makes a package name format of R-$NAME. When in doubt, use the name of the module that you type to import it in R. + +'''Examples: ''' +
+R-mAr (R module named mAr)
+R-RScaLAPACK (R module named RScaLAPACK)
+R-waveslim (R module named waveslim)
+
+ +{{Anchor|AddonSugar}} +== Addon Packages (Sugar Activities) == +The name for all packaged Sugar activities must be prefixed with sugar-. For more details, see ["Packaging/SugarActivityGuidelines"] . + +{{Anchor|AddonTCL}} +== Addon Packages (Tcl/Tk extensions) == +The name for all packaged Tcl/Tk extensions must be prefixed with tcl-. This rule applies even for Tcl/Tk packages that are already prefixed with tcl in the name. For more details, see ["Packaging/Tcl#NamingConventions"] . + +{{Anchor|AddonLocale}} +== Addon Packages (locales) == +If a package adds a locale to an existing parent package, then it can use an underscore in the locale. + +'''Examples: ''' +
+ttfonts-zh_TW (adds zh_TW locale fonts in ttfonts family)
+ttfonts-zh_CN (adds zh_CN locale fonts in ttfonts family)
+
+ +[[Category:Extras]] From 8cc2b019c9f5b968ffd031431aa784f99c2a4839 Mon Sep 17 00:00:00 2001 From: ImportUser Date: May 24 2008 14:13:02 +0000 Subject: [PATCH 20/3559] Imported from MoinMoin --- diff --git a/Packaging:UsersAndGroups.mw b/Packaging:UsersAndGroups.mw new file mode 100644 index 0000000..bd4c32a --- /dev/null +++ b/Packaging:UsersAndGroups.mw @@ -0,0 +1,40 @@ + +== User and group handling in packages == + +This guideline is for packaging cases that require creation of users and groups. Note that for the moment, we primarily address the case where the mapping from user/group names to uids/gids is decided dynamically by target systems at package install time. Some options for system administrators for making this mapping static even though the package scriptlets use a dynamic scheme are also discussed below, and more are being investigated, including possibilities to make the mapping static at package build time. + +To create users and groups in packages, use the following: + +
+Requires(pre): shadow-utils
+[...] 
+%pre
+getent group GROUPNAME >/dev/null || groupadd -r GROUPNAME
+getent passwd USERNAME >/dev/null || \
+useradd -r -g GROUPNAME -d HOMEDIR -s /sbin/nologin \
+-c "Useful comment about the purpose of this account" USERNAME
+exit 0
+
+ +HOMEDIR should usually be a directory created and owned by the package, with appropriately restrictive permissions. One good choice for the location of the directory is the package's data directory in case it has one. + +User accounts created by packages are rarely used for interactive logons, and should thus generally use /sbin/nologin as the user's shell. + +We want to invoke groupadd explicitly instead of relying on useradd to create the group for us. This is because useradd alone would fail if the group it tries to create already existed. Note: even though the useradd manual page doesn't mention it (as of FC6), -g GROUPNAME appears to imply -n. + +The exit 0 at the end will result in the %pre scriptlet passing through even if the user/group creation fails for some reason. This is suboptimal but has less potential for system wide breakage than allowing it to fail. If the user/group aren't available at the time the package's payload is unpacked, rpm will fall back to getting those files owned by root. + +We run getent before groupadd and useradd to check whether the user/group we're about to create already exists, and we skip the creation if they do. This is in order to provide a possibility for local system administrators to create the users/groups beforehand in case they wish to get a predefined static UID/GID mapping for those users. Creating users eg. when using unattended kickstart installations is a case where creating users/groups beforehand is a bit tricky; one way to accomplish that is to create a customized version of the "setup" package with the desired users/groups along with their static UID/GID mappings are in place, and to make sure the install transaction uses that package instead of the vanilla distro one. + +We run the groupadd/useradd always -- both on initial installs and upgrades -- in %pre. This is made possible by the getent checks above, and should fix things up if the user/group has disappeared after the package to be upgraded was initially installed (just like file permissions get reset on upgrades etc). + +We never remove users or groups created by packages. There's no sane way to check if files owned by those users/groups are left behind (and even if there would, what would we do to them?), and leaving those behind with ownerships pointing to now nonexistent users/groups may result in security issues when a semantically unrelated user/group is created later and reuses the UID/GID. Also, in some setups deleting the user/group might not be possible or/nor desirable (eg. when using a shared remote user/group database). Cleanup of unused users/groups is left to the system administrators to take care of if they so desire. + +In some cases it is desirable to create only a group without a user account. Usually this is because there are some system resources to which we want to control access by using that group, and a separate user account would add no value. Examples of common such cases include (but are not limited to) games whose executables are setgid for the purpose of sharing high score files or the like, and/or software that needs exceptional permissions to some hardware devices and it wouldn't be appropriate to grant those to all system users nor even only those logged in on the console. In these cases, apply only the groupadd parts of the above recipe. + +Note that the practice of not creating users/groups if they exist has a drawback of possibly unrelated but coincidentally same named existing system users and/or groups unnecessarily and undesirably getting access to things in a package that uses the same user/group names. This version of the users/groups guideline does not address that issue in any way, but it is possible that future revisions will if a good enough way to do that is found. + +=== Collection of past random notes === + +Moved to PackagingDrafts/UsersAndGroupsThoughts (note that these are not part of this guideline). From c7558ef4aa1af16d76a39dc034703cdced20ee7f Mon Sep 17 00:00:00 2001 From: ImportUser Date: May 24 2008 14:13:02 +0000 Subject: [PATCH 22/3559] Imported from MoinMoin --- diff --git a/Packaging:EclipsePlugins.mw b/Packaging:EclipsePlugins.mw new file mode 100644 index 0000000..e6c1cbf --- /dev/null +++ b/Packaging:EclipsePlugins.mw @@ -0,0 +1,243 @@ + += Packaging Eclipse Plugins = + + + +== Glossary == +* '''Plugin,,1,,''': A functional unit of Eclipse functionality. Post-Eclipse 3.0, the term "plugin" can almost always be interchanged with the term "bundle" which itself is shorthand for "OSGi bundle". +* '''Plugin,,2,,''': The colloquial name given to a set of functional Eclipse plugins ex. "CDT". More common usage among non-Eclipse developers than the above definition. +* '''Feature''': A collection of plugin,,1,,s. +* '''Fragment''': A bundle with native elements ex. org.eclipse.core.filesystem.linux.${arch} + +== Introduction == +Eclipse is a modular platform that can be used for building everything from server-side applications to full-blown graphical applications like the Eclipse IDE and Lotus Notes. Each of the modular blobs is referred to as a plugin or a bundle. In a nutshell, the system itself is a small runtime (Equinox) based on the OSGi specifications [see http://www.eclipse.org/equinox/ for more information] which loads and runs a given list of bundles. Most people think of Eclipse as a programming integrated development environment (IDE). This document details best practices for packaging Eclipse IDE plugins. Examples include adding Subversion functionality (eclipse-subclipse) and tools for tracking your tasks (eclipse-mylyn). + +== Naming == +Eclipse plugin packages '''MUST''' be named eclipse-. For example, a package of the anyedit plugin for Eclipse would by named eclipse-anyedit. + +=== Binary RPM naming === +If a project provides multiple features, package each of the features as a separate binary plugin, matching the naming and grouping of plugins directly. + +=== Group Tag === +There is no single Group tag for Eclipse plugins. Choose a Group that best fits the plugin and satisfies rpmlint. Some of the existing Groups include: +
+Development/Tools
+Development/Languages
+System Environment/Libraries
+
+ +== Source == +Obtaining source for Eclipse plugins is sometimes difficult. Most projects do not release source tarballs so it is often necessary to create an archive from a source revision control system. Ensure that instructions for reproducing the source archive are included in comments in the specfile. These instructions can take the form of either explicit instructions as in [http://cvs.fedoraproject.org/viewcvs/*checkout*/devel/eclipse-cdt/eclipse-cdt.spec eclipse-cdt] or be put into a [http://cvs.fedoraproject.org/viewcvs/*checkout*/devel/eclipse-rpm-editor/fetch-specfile-editor.sh?content-type=text%2Fplain separate shell script] as in [http://cvs.fedoraproject.org/viewcvs/*checkout*/devel/eclipse-rpm-editor/eclipse-rpm-editor.spec eclipse-rpm-editor] . + +Remember that Eclipse plugin packages, like all Fedora software packages, must be built from source, and cannot contain any "pre-built" binary components. + +== Building == +Eclipse plugins '''SHOULD''' be built with the Eclipse Plugin Development Environment (PDE; PDE Build specifically) because these builds are generally easier to maintain. ant builds are acceptable, but are generally more difficult to maintain. Following what upstream does is the best practice. + +=== pdebuild === +As of Fedora 9, there is a script that makes invoking PDE Build easy: /usr/share/eclipse/buildscripts/pdebuild: + +
+usage: /usr/share/eclipse/buildscripts/pdebuild [] 
+
+Use PDE Build to build Eclipse features
+
+Optional arguments:
+-h      Show this help message
+-f      Feature ID to build
+-d      Plugin dependencies in addition to Eclipse SDK
+(space-separated, names on which to glob features and plugins)
+-a      Additional build arguments (ex. -DjavacSource=1.5)
+-j      VM arguments (ex. -DJ2SE-1.5=%{_jvmdir}/java/jre/lib/rt.jar)
+-v      Be verbose
+-D      Debug platform itself (passes -consolelog -debug to Eclipse)
+
+ +{{Template:Warning}} Note: PDE Build must be called explicitly in Fedora 8 and earlier (including EPEL 5). The following snippet may be used to replace the pdebuild call in the template: + +
+/bin/sh -x %{eclipse_base}/buildscripts/copy-platform SDK %{eclipse_base} 
+mkdir home
+SDK=$(cd SDK > /dev/null && pwd)
+
+homedir=$(cd home > /dev/null && pwd)
+
+java -cp $SDK/startup.jar                              \
+-Dosgi.sharedConfiguration.area=%{_libdir}/eclipse/configuration  \
+org.eclipse.core.launcher.Main                    \
+-application org.eclipse.ant.core.antRunner       \
+-Dtype=feature                                    \
+-Did=org.eclipse.plugin_feature                   \
+-DbaseLocation=$SDK                               \
+-DsourceDirectory=$(pwd)                          \
+-DbuildDirectory=$(pwd)/build                     \
+-Dbuilder=%{eclipse_base}/plugins/org.eclipse.pde.build/templates/package-build \
+
+-f %{eclipse_base}/plugins/org.eclipse.pde.build/scripts/build.xml \
+-vmargs -Duser.home=$homedir                      \
+
+
+ +==== EPEL 5 ==== +The copy-platform script is in a different location on RHEL 5 than it is in Fedora. If calling copy-platform explicitly, the following snippet may be useful to facilitate Eclipse plugins for EPEL 5: +
+%if 0%{?rhel} == 5
+/bin/sh -x %{_libdir}/eclipse/buildscripts/copy-platform SDK %{eclipse_base}
+%else
+/bin/sh -x %{eclipse_base}/buildscripts/copy-platform SDK %{eclipse_base}
+%endif
+
+ +== File Locations == +All plugin jars should go into %{_datadir}/eclipse/plugins and features should go into %{_datadir}/eclipse/features. The only exception is for fragments which should go into %{_libdir}/eclipse/plugins (and features if applicable). + +== Arch vs. noarch == +While many Eclipse plugins will be architecture-independent, please follow the ["Packaging/GCJGuidelines"] with regards to gcj ahead-of-time compilation. As those guidelines specify, gcj-compiled packages are arch-dependent and are thus not noarch. + +== Things to avoid == +=== Pre-built binaries === +If Eclipse plugins depend upon third party libraries (and licensing permits it), developers often include these libraries directly in their source control system. In this case, the libraries must exist as other packages in Fedora and their contents (such as their jars) be symlinked from within the source and build trees of the Eclipse plugin being packaged. While it may make source archives smaller in size if they are cleansed of these pre-built files, it is not necessary to do so unless the libraries themselves are not redistributable. Binary RPMs '''MUST NOT''' include pre-built files. + +{{Template:Note}} A simple check which may be run at the end of %prep (courtesy David Walluck (I think that's who gave it to Ben Konrath)): +
+JARS=""
+for j in $(find -name \*.jar); do
+if [ ! -L $j ] ; then
+JARS="$JARS $j"
+fi
+done
+if [ ! -z "$JARS" ] ; then
+echo "These jars should be deleted and symlinked to system jars: $JARS"
+exit 1
+fi
+
+ +=== Differing from upstream === +Plugins that are jarred should remain jarred and those that are expanded should be expanded in their RPM. There are two cases (that we can think of as of this writing) that warrant diverging from upstream: +1. Symlinking to a binary jar from another package +1. Expanding a jar to allow for symlinking to a binary jar from another package + +See below for a tip on how to deal with the expanded jar case. + +== Specfile Template == +
+%define eclipse_base        %{_datadir}/eclipse
+
+Name:           eclipse-plugin
+Version:        1.0
+Release:        1%{?dist}
+Summary:        Plugin provides such and such functionality for the Eclipse IDE.
+
+Group:          Development/Tools
+License:        EPL
+URL:            http://www.eclipse.org/plugin
+Source0:        org.eclipse.plugin-TAG-fetched-src.tar.bz2
+BuildRoot:      %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
+Arch:           noarch
+
+BuildRequires:  java-devel >= 1.5.0
+BuildRequires:  eclipse-pde
+Requires:       eclipse-platform
+
+%description
+Plugin provides such and such functionality for the Eclipse IDE.
+Specific functionality b is provided in %{name}-b.
+
+%package b
+Summary: b functionality for plugin
+Requires: %{name} = %{version}-%{release}
+Group: Development/Tools
+
+%description b
+%{name}-b enhances plugin with b-specific functionality.
+
+%prep
+%setup -q org.eclipse.plugin
+
+%build
+%{eclipse_base}/buildscripts/pdebuild -f org.eclipse.plugin_feature
+
+%{eclipse_base}/buildscripts/pdebuild -f org.eclipse.plugin.b_feature
+
+%install
+rm -rf $RPM_BUILD_ROOT
+install -d -m 755 $RPM_BUILD_ROOT%{eclipse_base}
+unzip -q -d $RPM_BUILD_ROOT%{eclipse_base}/.. \
+build/rpmBuild/org.eclipse.plugin_feature.zip
+unzip -q -d $RPM_BUILD_ROOT%{eclipse_base}/.. \
+build/rpmBuild/org.eclipse.plugin.b_feature.zip
+
+%clean
+rm -rf $RPM_BUILD_ROOT
+
+%files
+%defattr(-,root,root,-)
+%{eclipse_base}/plugins/org.eclipse.plugin.a_*.jar
+%{eclipse_base}/plugins/org.eclipse.plugin.c_*.jar
+%dir %{eclipse_base}/features/org.eclipse.plugin_feature_*
+%doc %{eclipse_base}/features/org.eclipse.plugin_feature_*/license.html
+%doc %{eclipse_base}/features/org.eclipse.plugin_feature_*/about.html
+%doc %{eclipse_base}/features/org.eclipse.plugin_feature_*/epl-v10.html
+%{eclipse_base}/features/org.eclipse.plugin_feature_*/feature.xml
+
+%files b
+%defattr(-,root,root,-)
+%{eclipse_base}/plugins/org.eclipse.plugin.b_*.jar
+%dir %{eclipse_base}/features/org.eclipse.plugin.b_feature_*
+%doc %{eclipse_base}/features/org.eclipse.plugin.b_feature_*/license.html
+%doc %{eclipse_base}/features/org.eclipse.plugin.b_feature_*/epl-v10.html
+%{eclipse_base}/features/org.eclipse.plugin.b_feature_*/feature.xml
+
+%changelog
+* Fri Feb 29 2008 Andrew Overholt  1.0-1
+- Initial Fedora package
+
+ +== Tips and Notes == + +=== Common Defines === +%define eclipse_base %{_datadir}/eclipse and, if necessary %define eclipse_lib_base %{_libdir}/eclipse. + +=== Requires === +Until rpmstubby (see below) is released and/or more widespread, Requires on bits provided by the Eclipse SDK (RCP, SWT, Platform, JDT, PDE, CVS, etc.) should only be on the binary package providing the required functionality (ex. eclipse-cvs-client or eclipse-rcp). For IDE features, the most common requirement will be eclipse-platform. + +=== Features vs. Plugins === +Eclipse features are groups of plugins. They are preferred, but not required since they provide nice demarcation lines for binary RPMs. We generally try to make binary RPMs mirror upstream features. Eclipse features also work nicely with rpmstubby (see below), but not all plugins have features. + +=== JAR Expansion === +In rare cases it may be necessary to symlink to something ''inside'' a JAR. This situation is often referred to as "nested JARs". If the plugin code itself is not enclosed in a nested JAR, expansion will result in a directory structure containing class files. This is best illustrated with an example: + +
+$ unzip -l org.eclipse.mylyn.web.core_2.2.0.I20071220-1700.jar | grep jar$
+46725  12-20-07 20:08   lib-httpclient/commons-codec-1.3.jar
+279781  12-20-07 20:08   lib-httpclient/commons-httpclient-3.0.1.jar
+38015  12-20-07 20:08   lib-httpclient/commons-logging-1.0.4.jar
+26202  12-20-07 20:08   lib-httpclient/commons-logging-api-1.0.4.jar
+153253  12-20-07 20:08   lib-rome/jdom-1.0.jar
+197290  12-20-07 20:08   lib-rome/rome-0.8.jar
+26624  12-20-07 20:08   lib-xmlrpc/ws-commons-util-1.0.1-sources.jar
+34840  12-20-07 20:08   lib-xmlrpc/ws-commons-util-1.0.1.jar
+35142  12-20-07 20:08   lib-xmlrpc/xmlrpc-client-3.0-sources.jar
+43312  12-20-07 20:08   lib-xmlrpc/xmlrpc-client-3.0.jar
+91225  12-20-07 20:08   lib-xmlrpc/xmlrpc-common-3.0-sources.jar
+98051  12-20-07 20:08   lib-xmlrpc/xmlrpc-common-3.0.jar
+
+ +Note that we have embedded jars which we would like to turn into symlinks to existing jars (from other packages). If we simply unzip the plugin jar and symlink, one would think we would be okay: + +
+$ unzip -qq org.eclipse.mylyn.web.core_2.2.0.I20071220-1700.jar
+$ rm !$
+$ ls
+about.html  lib-httpclient  lib-rome  lib-xmlrpc  META-INF  org
+$ 
+
+ +However, we end up with the plugin classes themselves being expanded in the org directory. [https://bugzilla.redhat.com/273881 Bug #273881] causes build failures when building debuginfo packages in this case. The acceptable workaround is to modify the build.properties file in the plugin to jar the plugin code separately (ex. mylyn-webcore.jar) and include it within this expanded plugin directory. An example of this work-around can be seen in [http://cvs.fedoraproject.org/viewcvs/devel/eclipse-mylyn/ eclipse-mylyn] (specifically the patches related to org.eclipse.mylyn.webcore). + +=== OSGi === +OSGi bundles contain metadata just like RPMs do. This metadata can be used to automatically generate Provides and Requires similar to how it is done for mono packages. This functionality exists in Fedora's current rpm package but requires some investigation as at the time of this writing it does not appear to be functioning properly. + +=== rpmstubby === +rpmstubby is a small project that is part of the [http://eclipse.org/linuxtools linuxdistros project] at eclipse.org. Its aim is to make packaging Eclipse plugins as RPMs extremely simple. It is still in its infancy, but specfiles for packages like eclipse-mylyn were originally stubbed out using it. It is hoped that it can soon be provided as a tool to Fedora packagers. Help is always welcome on the project and it can be checked out of svn here: svn://anonymous@dev.eclipse.org/svnroot/technology/org.eclipse.linuxtools/rpmstubby/trunk. From 0448a6429ff297c31a9f4b5f28010a819f195973 Mon Sep 17 00:00:00 2001 From: ImportUser Date: May 24 2008 14:13:02 +0000 Subject: [PATCH 24/3559] Imported from MoinMoin --- diff --git a/Packaging:SugarActivityGuidelines.mw b/Packaging:SugarActivityGuidelines.mw new file mode 100644 index 0000000..896c2c4 --- /dev/null +++ b/Packaging:SugarActivityGuidelines.mw @@ -0,0 +1,101 @@ + += Sugar Draft Packaging Guidelines = +These guidelines are for packaging Sugar activities. [http://wiki.laptop.org/go/Sugar Sugar] is the core of the OLPC Human Interface. + + + +== Macros == +Sugar looks for its activities in two fixed locations, which are defined in sugar-toolkit with rpm macros: + +Architecture Independent (noarch): +
+%define sugaractivitydir /usr/share/sugar/activities/
+
+ +Architecture Dependent: +
+%define sugarlibdir %{_libdir}/sugar/activities
+
+ +== Necessary BuildRequires == +All Sugar Activities use setup.py, which is dependant upon sugar-toolkit. Accordingly, all activities need to: +
+BuildRequires: sugar-toolkit
+
+ +== Naming == +All activities '''MUST''' be named sugar-. + +== Architecture-specific Activities == +All activities containing compiled code (thus, architecture-specific) must be built in the %build section. Any architecture-specific bits must either go in %{_bindir} %{_libdir} or %{sugarlibdir} as appropriate. + +== Runtime Dependencies == +All runtime dependency information '''MUST''' be manually added. There is no build time detection for Sugar activities. + +== Sample SPEC == +
+Name:           sugar-journal
+Version:        79
+Release:        1%{?dist}
+Summary:        Journal for Sugar
+
+Group:          Sugar/Activities
+License:        GPLv2+
+URL:            http://wiki.laptop.org/go/Journal
+Source0:        journal-activity-%{version}.tar.bz2
+Source1:        sugar-journal-checkout.sh
+BuildRoot:      %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
+
+BuildRequires:  python sugar-toolkit
+Requires:       sugar
+BuildArch:      noarch
+
+%description
+The Journal activity provides an intuitive interface for viewing projects and
+files saved by the XO user. Activities that the user has stopped will show in
+the journal view with a timer showing how long ago they were stopped.
+
+%prep
+%setup -q -n journal-activity-%{version}
+
+
+%build
+
+
+%install
+rm -rf $RPM_BUILD_ROOT
+mkdir -p $RPM_BUILD_ROOT%{sugaractivitydir}
+./setup.py install $RPM_BUILD_ROOT%{sugaractivitydir}
+
+
+%clean
+rm -rf $RPM_BUILD_ROOT
+
+
+%files
+%defattr(-,root,root,-)
+%doc NEWS
+%{sugaractivitydir}/Journal.activity/
+
+
+%changelog
+* Fri Apr 04 2008 Dennis Gilmore  - 79-1
+- Initial packaging
+
+ +== Sample Checkout Script == +
+#!/bin/bash
+
+VERSION=79
+NAME=journal-activity
+
+rm -rf $NAME-$VERSION
+
+git clone git://dev.laptop.org/$NAME $NAME-$VERSION
+
+tar -cjvf $NAME-$VERSION.tar.bz2 $NAME-$VERSION
+
+rm -rf $NAME-$VERSION
+
From c23fb4d65fce9a00d91f7f4da6c31a5eeeeeddb4 Mon Sep 17 00:00:00 2001 From: ImportUser Date: May 24 2008 14:13:02 +0000 Subject: [PATCH 26/3559] Imported from MoinMoin --- diff --git a/Packaging:Ruby.mw b/Packaging:Ruby.mw new file mode 100644 index 0000000..e3608fd --- /dev/null +++ b/Packaging:Ruby.mw @@ -0,0 +1,95 @@ + += Ruby Packaging Guidelines = + + + +Each Ruby package '''must''' indicate the Ruby ABI version it depends on with a line like +
+Requires: ruby(abi) = 1.8
+
+ +Ruby packages '''must''' require ruby at build time with a BuildRequires: ruby, and '''may''' indicate the minimal ruby version they need for building. + +{{Anchor|ruby_naming}} +== Naming Guidelines == +{{Template:Note}} These naming guidelines only apply to ruby packages whose main purpose is providing a Ruby library; packages that mainly provide user-level tools that happen to be written in Ruby do not need to follow these naming guidelines, and should follow the general [[Packaging/NamingGuidelines| NamingGuidelines]] instead. + +The name of a ruby extension/library package '''must''' be of the form ruby-UPSTREAM. If the upstream name UPSTREAM contains ruby, that '''should''' be dropped from the name. For example, the SQLite database driver for ruby is called sqlite3-ruby. The corresponding Fedora package should be called ruby-sqlite3, and not ruby-sqlite3-ruby. + +A ruby extension/library package '''must''' indicate what it provides with a Provides: ruby(LIBRARY) = VERSION declaration in the spec file. The string LIBRARY '''should''' be the same as what is used in the require statement in a Ruby script that uses the library. The VERSION '''should''' be the upstream version of the library, as long as upstream follows a sane versioning scheme. For example, a Ruby script using the SQLite database driver will include it with require 'sqlite3'. The specfile for the corresponding Fedora package must contain a line Provides: ruby(sqlite3) = 1.1.0, assuming the package contains version 1.1.0 of the library. + +== Build Architecture and File Placement == +The following only affects the files that the package installs into %{_libdir}/ruby, i.e., Ruby library files. All other files in a Ruby package must adhere to the general Fedora Extras packaging conventions. + +=== Pure Ruby packages === +Pure Ruby packages '''must''' be built as noarch packages. + +The Ruby library files in a pure Ruby package '''must''' be placed into Config::CONFIG["sitelibdir"] . The specfile '''must''' get that path using +
+%{!?ruby_sitelib: %define ruby_sitelib %(ruby -rrbconfig -e 'puts Config::CONFIG["sitelibdir"] ')}
+
+ +{{Template:Note}} For Fedora Core 3 and earlier releases, it is not possible to build noarch packages; for those releases, all Ruby packages '''must''' be architecture-specific, even if they only contain Ruby files. (See [https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=184199 bug 184199] for details) + +{{Anchor|ruby_sitearch}} +=== Ruby packages with binary content/shared libraries === + +For packages with binary content, e.g., database drivers or any other Ruby bindings to C libraries, the package '''must''' be architecture specific. + +The binary files in a Ruby package with binary content '''must''' be placed into Config::CONFIG["sitearchdir"] . The Ruby files in such a package '''should''' be placed into that directory, too. The specfile '''must''' get that path using +
+%{!?ruby_sitearch: %define ruby_sitearch %(ruby -rrbconfig -e 'puts Config::CONFIG["sitearchdir"] ')}
+
+ +== Ruby Gems == + +[http://www.rubygems.org/ Ruby Gems] are Ruby's own packaging format. Gems contain a lot of the same metadata that RPM's need, making fairly smooth interoperation between RPM and Gems possible. This guideline ensures that Gems are packaged as RPM's in a way that ensures (1) that such RPM's fit cleanly with the rest of the distribution and (2) make it possible for the end user to satisfy dependencies of a Gem by installing the appropriate RPM-packaged Gem. + +Both RPM's and Gems use similar terminology --- there's specfiles, package names, dependencies etc. for both. To keep confusion to a minimum, whenever the term from the Gem world is meant, it is explicitly called the 'Gem specification'. An unqualified 'package' in the following always means an RPM. + +* Packages that contain Ruby Gems '''must''' be called rubygem-%{gemname} where gemname is the name from the Gem's specification. +* The Source of the package '''must''' be the full URL to the released Gem archive; the version of the package '''must''' be the Gem's version +* The package '''must''' have a Requires and a BuildRequires on rubygems +* The package '''must''' provide rubygem(%{gemname}) where gemname is the name from the Gem's specification. For every dependency on a Gem named gemdep, the package must contain a Requires on rubygem(%{gemdep}) with the same version constraints as the Gem +* The %prep and %build sections of the specfile '''should''' be empty. +* The Gem '''must''' be installed into %{gemdir} defined as +
+%define gemdir %(ruby -rubygems -e 'puts Gem::dir' 2>/dev/null)
+
+The install '''should''' be performed with the command +
+gem install --local --install-dir %{buildroot}%{gemdir} --force %{SOURCE0}
+
+* The package '''must''' own the following files and directories: +
+%{gemdir}/gems/%{gemname}-%{version}/
+%{gemdir}/cache/%{gemname}-%{version}.gem
+%{gemdir}/specifications/%{gemname}-%{version}.gemspec
+
+* Architecture-specific content '''must not''' be installed into %{gemdir} +* If the Gem only contains pure Ruby code, it '''must''' be marked as BuildArch: noarch. If the Gem contains binary content (e.g., for a database driver), it '''must''' be marked as architecture specific, and all architecture specific content '''must''' be moved from the %{gemdir} to the [#ruby_sitearch %{ruby_sitearch} directory] during %install + +=== Packaging for Gem and non-Gem use === + +If the same Ruby library is to be packaged for use as a Gem and as a straight Ruby library without Gem support, it '''must''' be packaged as a Gem first. To make it available to code that does not use Ruby Gems, a subpackage called ruby-%{gemname} '''must''' be created in the rubygem-%{gemname} package such that + +* The subpackage '''must''' require rubygem(%gemname) = %version +* The subpackage '''must''' provide ruby(LIBRARY) = %version where LIBRARY is the same as in the [#ruby_naming general Ruby guideline] above. +* All the toplevel library files of the Gem must be symlinked into ruby_sitelib. +* The subpackage '''must''' own these symbolic links. + +As an example, for activesupport, the rubygem-activesupport package would have a subpackge ruby-activesupport: +
+%package -n ruby-activesupport
+...
+Requires: rubygem(activesupport) = %version
+Provides: ruby(active_support) = %version  # The underscore is intentional, not a typo
+...
+%files -n ruby-activesupport
+%{ruby_sitelib}/active_support
+%{ruby_sitelib}/active_support.rb
+
+ +=== Tips for Packagers === + +Gems carry a lot of metadata; [http://people.redhat.com/dlutter/gem2spec.html Gem2Spec] is a tool to generate an initial specfile and/or source RPM from a Gem. The generated specfile still needs some hand-editing, but conforms to 90% with this guideline. From 993e03b6db02a3d5db3947208f938e48febe3373 Mon Sep 17 00:00:00 2001 From: ImportUser Date: May 24 2008 14:13:02 +0000 Subject: [PATCH 28/3559] Imported from MoinMoin --- diff --git a/Packaging:Emacs_Old.mw b/Packaging:Emacs_Old.mw new file mode 100644 index 0000000..04d7080 --- /dev/null +++ b/Packaging:Emacs_Old.mw @@ -0,0 +1,417 @@ += Packaging of add-ons for GNU Emacs and XEmacs = + + + + +== Purpose == + +The purpose of this document is to promote good practice in packaging add-ons for GNU Emacs and XEmacs, and to encourage the submission of more Emacs add-on packages to the package collection by providing easy to use spec file templates. + +This document refers to packaging for Fedora 8 onwards. + +== Packaging add-ons for (X)Emacs == + +=== Executive summary of Guidelines === +The following list contains the key points of the guidelines. More detail on each of these may be found in the subsequent sections. + + +1. Where an add-on package foo is for both GNU Emacs and XEmacs, the main package should be called emacs-common-foo. This main package should contain files common to both GNU Emacs and XEmacs such as documentation etc. Files specific to each of GNU Emacs and XEmacs should be placed in sub-packages as detailed in points 4 and 5 below. + +2. Where a package is specific only to one flavour of (X)Emacs, the main package should be called emacs-foo or xemacs-foo. In both cases, elisp source should be packaged in separate sub-packages as detailed below. + +3. Where a package which is not primarily an (X)Emacs add-on package but contains auxillary (X)Emacs components, these should be placed in sub-packages following the guidelines below. + +4. Files specific to GNU Emacs should be placed in two sub-packages: +* emacs-foo: this sub-package should contain compiled elisp and other files needed to use the add-on package with GNU Emacs only. It should not contain any source elisp files which are not required to run the package. +* emacs-foo-el: this sub-package contains the source elisp files used to build the add-on package for GNU Emacs. Files in this package should not be required to use the add-on package. + +5. Files specific to XEmacs should be placed in two sub-packages: +* xemacs-foo: this sub-package should contain compiled elisp and other files needed to use the add-on package with XEmacs only. It should not contain any source elisp files which are not required to run the package. +* xemacs-foo-el: this sub-package contains the source elisp files used to build the add-on package for XEmacs. Files in this package should not be required to use the add-on package. + +6. File locations for GNU Emacs add-on packages: +* All elisp and related files for the add-on package should be installed in the directory /usr/share/emacs/site-lisp/foo. +* /usr/share/emacs/site-lisp/foo should be owned by the package emacs-foo. +* If the package requires a startup file this should be called foo-init.el and be placed in /usr/share/emacs/site-lisp/site-start.d/. + +7. Files locations for XEmacs add-on packages: +* All elisp and related files for the add-on package should be installed in the directory /usr/share/xemacs/site-packages/lisp. +* /usr/share/xemacs/site-packages/lisp should be owned by xemacs-foo. +* If the package requires a startup file this should be called foo-init.el and be placed in /usr/share/xemacs/site-packages/lisp/site-start.d/. + +8. emacs-foo-el must have Requires: emacs-foo = %{version}-%{release}. + +9. xemacs-foo-el must have Requires: xemacs-foo = %{version}-%{release}. + +10. Where it is relevant, emacs-foo and xemacs-foo must have Requires: emacs-common-foo = %{version}-%{release}. + +11. emacs-foo must have Requires: emacs(bin) >= X, where X is the version of GNU Emacs used to build the package. + +12. xemacs-foo must have Requires: xemacs(bin) >= Y, where Y is the version of GNU Emacs used to build the package. + +13. If an add-on package requires only byte compilation of elisp then BuildArch: noarch should be used. + +=== Principles === +The existence of the GNU Emacs and XEmacs variants makes packaging Emacs add-on packaging slightly complex. GNU Emacs and XEmacs have different philosophies regarding add-on packages. + +XEmacs has its own packaging system and maintains and distributes its own library of third party add-on modules. These are distributed in Fedora in the xemacs-packages-base and xemacs-packages-extra packages. GNU Emacs doesn't have any equivalent system, and third party add-ons are left for the user or distribution to install. + +The packaging naming guidelines state that: + +''Packages of emacs add-on components (code that adds additional functionality to emacs compatible editors) have their own naming scheme. It is often the case that a component will add functionality to several different compatible editors, such as GNU Emacs and XEmacs (and possibly development versions of these editors). The package name should take into account the upstream name of the emacs component.'' + +''Where a component adds functionality to more than one emacs compatible editor, the package name should be of the form emacs-common-$NAME. In this case, the main package should contain only files common to all emacs compatible editors, and the code specific to each should be placed in a subpackage reflecting the specific editor $EDITOR-$NAME eg. xemacs-$NAME, emacs-$NAME (the latter being the package specific to GNU Emacs). An example of this scheme can be found in the package emacs-common-muse.'' + +''Where a component is designed to add functionality to only a single emacs compatible editor, the main package name should reflect this by being called $EDITOR-$NAME. An example of this situation can be found in the package emacs-auctex, which is built only for GNU Emacs.'' + +Wherever possible, we encourage making an add-on package available for both GNU Emacs and XEmacs. One common case where that is not desireable is when an add-on package is already available for XEmacs in either xemacs-packages-base or xemacs-packages-extra. For example VM (a mail reader for Emacs) is provided for XEmacs in the xemacs-packages-extra package, but is not included in the emacs or emacs-common packages. Therefore it is sensible to create a package called emacs-vm which is the VM package for GNU Emacs only. Another such example is AUCTeX. + +=== Location of installed files === +==== GNU Emacs ==== +For GNU Emacs, files for add-on package foo should be placed in /usr/share/emacs/site-lisp/foo. + +Usually an add-on package will require a startup file, and this should be called foo-init.el and be placed in /usr/share/emacs/site-lisp/site-start.d/. + +The following code snippet show how to use macros to determine these at package build time: +
+%if %($(pkg-config emacs) ; echo $?)
+%define emacs_lispdir %{_datadir}/emacs/site-lisp
+%define emacs_startdir %{_datadir}/emacs/site-lisp/site-start.d
+%else
+%define emacs_lispdir %(pkg-config emacs --variable sitepkglispdir)
+%define emacs_startdir %(pkg-config emacs --variable sitestartdir)
+%endif
+...
+BuildRequires: emacs-el
+...
+
+ +==== XEmacs ==== +For XEmacs, files for add-on package foo should be placed in /usr/share/xemacs/site-packages/lisp/foo. + +Usually an add-on package will require a startup file, and this should be called foo-init.el and be placed in /usr/share/xemacs/site-packages/lisp/site-start.d/. + +The following code snippet show how to use macros to determine these at package build time: +
+%if %($(pkg-config xemacs) ; echo $?)
+%define xemacs_lispdir %{_datadir}/xemacs/site-packages
+%define xemacs_startdir %{_datadir}/xemacs/site-packages/site-start.d
+%else
+%define xemacs_lispdir %(pkg-config xemacs --variable sitepkglispdir)
+%define xemacs_startdir %(pkg-config xemacs --variable sitestartdir)
+%endif
+...
+BuildRequires: xemacs-devel
+...
+
+ +=== Packaging of source elisp files === +Typically, an Emacs add-on package will be compiled from source elisp files. The resulting compiled elisp files will then be included in the relevant emacs-foo and xemacs-foo packages. However, these packages SHOULD NOT contain uncompiled elisp source files which are not required for the program to run. Rather, following the precedent set by GNU Emacs packaging, the elisp source files should be placed in their own sub-packages, named emacs-foo-el and xemacs-foo-el. + +The (x)emacs-foo-el packages are similar in many ways to the -devel subpackages for system libraries. It is often the case that byte compiling the elisp source for one add-on will require the presence of the elisp source for another add-on package at build time for example. + +=== BuildArch for (X)Emacs add-on packages === +You should set BuildArch: noarch for add-on packages which only compile elisp files during building. + +If the package building process also compiles programs in other languages, you may need to not set BuildArch. + +=== Requires for GNU Emacs and XEmacs === +Add-on packages should have appropriate Requires entries for the flavour of (X)Emacs they are targeted at. +Both GNU Emacs and XEmacs are available in two different packages - some details of these packages follow. +1. GNU Emacs is packaged as two variants. The emacs package is built with Xorg support to allow the user to run Emacs in a windowed environment. The emacs-nox package is built without Xorg support and hence allows Emacs to be run only in a console. Note: +* Both the emacs and emacs-nox packages have Requires: emacs-common. +* Both emacs and emacs-nox have a virtual Provides: emacs(bin) + +2. XEmacs is packaged as two variants. The xemacs package is built with Xorg support to allow the user to run Emacs in a windowed environment. The xemacs-nox package is built without Xorg support and hence allows Emacs to be run only in a console. Note: +* Both the xemacs and xemacs-nox packages have Requires: xemacs-common. +* Both xemacs and xemacs-nox have a virtual Provides: xemacs(bin) + +Assuming your add-on package will work in both a windowed and a console (X)Emacs session, it is wrong to have Requires: emacs or Requires: xemacs as that would pull in a dependency on Xorg even if the console variants of (X)Emacs was installed. Rather you should use Requires: xemacs(bin) for XEmacs add-on packages, and Requires: emacs(bin) for GNU Emacs add-on packages. + +If the package ONLY works with Xorg support built into (X)Emacs, then the packages should have Requires: emacs or Requires: xemacs. This is very uncommon. + +==== Why we need versioned Requires ==== +Many elisp packages aim for backwards source level compatibility by checking whether some features exist in the (X)Emacs in use when the package is being run or byte-compiled. If yes, they use what's available. If no, they provide their own versions of missing functions, macros etc. This propagates into *.elc during byte compilation, and quite a few functions do get added between upstream (X)Emacs releases. + +So let's say I byte-compile a package into *.elc with XEmacs 21.5.28. Elisp package quux checks if the foo-bar function is available in the XEmacs being used to byte-compile it. Yes, it is, so the internal backwards compat version of foo-bar included in quux does not end up in the *.elc. Now, let's assume foo-bar was added in XEmacs 21.5.28 and didn't exist in 21.5.27 and we're trying to run the *.elc with 21.5.27 -> boom, foo-bar is not available. Note: this wouldn't happen if only *.el were shipped - *.elc are the potential and likely problem. Requiring >= version of the XEmacs used to byte-compile the *.elc is not the only solution (nor enough for all corner cases), but is the best one we currently have available. + +The main package and subpackages will need to have appropriately version Requires to ensure that a recent enough version of (X)Emacs is installed. (X)Emacs byte compiled lisp is usually forward compatible with later (X)Emacs versions, but is frequently not compatible with earlier versions of (X)Emacs. + +==== Determining the Required (X)Emacs version at package build time ==== +It is recommended to derive greater-than-or-equal-to valued versioned dependencies from the version of (X)Emacs used to byte-compile the package at package build time. The mechanism for doing so is provided by pkg-config (when available). + +For Emacs add-ons you will need to add BuildRequires: emacs-el and use the macro below +
+%if %($(pkg-config emacs) ; echo $?)
+%define emacs_version 22.1
+%else
+%define emacs_version %(pkg-config emacs --modversion)
+%endif
+...
+Requires: emacs(bin) >= emacs_version
+BuildRequires: emacs-el
+...
+
+ +For Xemacs you will need to add BuildRequires: xemacs-devel and use the macro below +
+%if %($(pkg-config xemacs) ; echo $?)
+%define xemacs_version 21.5
+%else
+%define xemacs_version %(pkg-config xemacs --modversion)
+%endif
+...
+Requires: xemacs(bin) >= xemacs_version
+BuildRequires: xemacs-devel
+...
+
+ +=== Other packages containing Emacsen add-ons === +It is often the case that a software package, while not being primarily an Emacs add-on package, will contain components for (X)Emacs. For example, the Gnuplot program contains some elisp files for editing Gnuplot input files in GNU Emacs and running Gnuplot from GNU Emacs. + +{| border="1" +|- +| {{Template:Tip}} Where a package contains add-on components for (X)Emacs, in general these components should be packaged in a sub-package consistent with the guidelines here for main (X)Emacs packages. +|} + +In other words, if a package foo contains components for (X)Emacs, the subpackages containing the files to run the (X)Emmacs components should be called emacs-foo and emacs-foo-el, which own the directories /usr/share/emacs/site-lisp/foo and /usr/share/xemacs/site-packages/lisp/foo respectively. Elisp source files not needed for running the add-ons should be packaged in separate sub-packages emacs-foo-el and xemacs-foo-el, which should Require emacs-foo and xemacs-foo respectively. + +== Templates for Emacsen add-on package spec files == + +=== Template for a package for both GNU Emacs and XEmacs === +This spec-file template for the add-on package "foo" creates 5 packages: + +1. emacs-common-foo is the main package. This should contain files which are common to both the emacs-foo and xemacs-foo subpackages below. Examples of what this file would contain are the package documentation, the COPYING file, the CHANGELOG file etc. + +2. emacs-foo. This sub-package Requires emacs-common-foo and contains the files needed to run foo with Emacs only. This package owns the director /usr/share/emacs/site-lisp/foo. + +3. emacs-foo-el. This sub-package contains the elisp source files corresponding to the compiled elisp files in package emacs-foo. This sub-package Requires: emacs-foo, as the directory in which the elisp source files are installed to is owned by emacs-foo. + +4. xemacs-foo. This sub-package Requires emacs-common-foo and contains the files needed to run foo with Emacs only. This package owns the director /usr/share/emacs/site-packages/lisp/foo. + +5. xemacs-foo-el. This sub-package contains the elisp source files corresponding to the compiled elisp files in package xemacs-foo. This sub-package Requires: xemacs-foo, as the directory in which the elisp source files are installed to is owned by xemacs-foo. + +For the Requires mentioned in 1-5 above, the exact %{version}-%{release} should be matched. + +For convenience, there are two macros at the top of the file which you should customise to your package. You do not have to use the macros placed at the top of the file, but they help readability and make writing a spec file for a new package much quicker. + +
+%define pkg foo
+%define pkgname Foo
+
+%if %($(pkg-config emacs) ; echo $?)
+%define emacs_version 22.1
+%define emacs_lispdir %{_datadir}/emacs/site-lisp
+%define emacs_startdir %{_datadir}/emacs/site-lisp/site-start.d
+%else
+%define emacs_version %(pkg-config emacs --modversion)
+%define emacs_lispdir %(pkg-config emacs --variable sitepkglispdir)
+%define emacs_startdir %(pkg-config emacs --variable sitestartdir)
+%endif
+
+%if %($(pkg-config xemacs) ; echo $?)
+%define xemacs_version 21.5
+%define xemacs_lispdir %{_datadir}/xemacs/site-packages
+%define xemacs_startdir %{_datadir}/xemacs/site-packages/site-start.d
+%else
+%define xemacs_version %(pkg-config xemacs --modversion)
+%define xemacs_lispdir %(pkg-config xemacs --variable sitepkglispdir)
+%define xemacs_startdir %(pkg-config xemacs --variable sitestartdir)
+%endif
+
+Name:           emacs-common-%{pkg}
+Version:
+Release:        1%{?dist}
+Summary:
+
+Group:
+License:
+URL:
+Source0:
+BuildRoot:      %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
+
+BuildArch:	noarch
+BuildRequires:  emacs emacs-el
+BuildRequires:  xemacs xemacs-devel
+Requires:
+
+%description
+%{pkgname} is an add-on package for GNU Emacs and XEmacs. It does wonderful things...
+
+This package contains the files common to both the GNU Emacs and XEmacs %{pkgname}
+packages.
+
+%package -n emacs-%{pkg}
+Summary:	Compiled elisp files to run %{pkgname} under GNU Emacs
+Group:
+Requires:	emacs(bin) >= %{emacs_version}
+Requires:       emacs-common-%{pkg} = %{version}-%{release}
+
+%description -n emacs-%{pkg}
+This package contains the byte compiled elisp packages to run %{pkgname} with GNU
+Emacs.
+
+
+%package -n emacs-%{pkg}-el
+Summary:	Elisp source files for %{pkgname} under GNU Emacs
+Group:
+Requires:	emacs-%{pkg} = %{version}-%{release}
+
+%description -n emacs-%{pkg}-el
+This package contains the elisp source files for %{pkgname} under GNU Emacs. You
+do not need to install this package to run %{pkgname}. Install the emacs-%{pkg}
+package to use %{pkgname} with GNU Emacs.
+
+
+%package -n xemacs-%{pkg}
+Summary:	Compiled elisp files to run %{pkgname} under XEmacs
+Group:
+Requires:	xemacs(bin) >= %{xemacs_version}
+Requires:       emacs-common-%{pkg} = %{version}-%{release}
+
+%description -n xemacs-%{pkg}
+This package contains the byte compiled elisp packages to use %{pkgname} with
+XEmacs.
+
+
+%package -n xemacs-%{pkg}-el
+Summary:	Elisp source files for %{pkgname} under XEmacs
+Group:
+Requires:	xemacs-%{pkg} = %{version}-%{release}
+
+%description -n xemacs-%{pkg}-el
+This package contains the elisp source files for %{pkgname} under XEmacs. You do
+not need to install this package to run %{pkgname}. Install the xemacs-%{pkg}
+package to use %{pkgname} with XEmacs.
+
+
+%prep
+%setup -q -n %{pkg}-%{version}
+
+%build
+
+
+%install
+rm -rf $RPM_BUILD_ROOT
+
+
+%clean
+rm -rf $RPM_BUILD_ROOT
+
+
+%post
+
+
+%preun
+
+
+%files
+%defattr(-,root,root,-)
+%doc
+
+
+%files -n emacs-%{pkg}
+%defattr(-,root,root,-)
+%{emacs_lispdir}/%{pkg}/*.elc
+%{emacs_startdir/*.el
+%dir %{emacs_lispdir}/%{pkg}
+
+
+%files -n emacs-%{pkg}-el
+%defattr(-,root,root,-)
+%{emacs_lispdir}/%{pkg}/*.el
+
+
+%files -n xemacs-%{pkg}
+%defattr(-,root,root,-)
+%{xemacs_lispdir}/%{pkg}/*.elc
+%{xemacs_startdir}/*.el
+%dir %{xemacs_lispdir}/%{pkg}
+
+
+%files -n xemacs-%{pkg}-el
+%defattr(-,root,root,-)
+%{xemacs_lispdir}/%{pkg}/*.el
+
+
+%changelog
+
+ +=== Template for a add-on package for GNU Emacs only === +This is a template for a package for GNU Emacs only. The main package is called emacs-foo and contains all files needed to run package foo with GNU Emacs. There is a subpackage called emacs-foo-el which installs the elisp source files. emacs-foo owns the directory into which it is installed (/usr/share/emacs/site-lisp/foo), and so emacs-foo-el Requires emacs-foo with the matching version and release tag. + +
+%define pkg foo
+%define pkgname Foo
+
+%if %($(pkg-config emacs) ; echo $?)
+%define emacs_version 22.1
+%define emacs_lispdir %{_datadir}/emacs/site-lisp
+%define emacs_startdir %{_datadir}/emacs/site-lisp/site-start.d
+%else
+%define emacs_version %(pkg-config emacs --modversion)
+%define emacs_lispdir %(pkg-config emacs --variable sitepkglispdir)
+%define emacs_startdir %(pkg-config emacs --variable sitestartdir)
+%endif
+
+Name:           emacs-%{pkg}
+Version:
+Release:        1%{?dist}
+Summary:
+
+Group:
+License:
+URL:
+Source0:
+BuildRoot:      %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
+
+BuildArch:      noarch
+BuildRequires:  emacs emacs-el
+Requires:       emacs(bin) >= %{emacs_version}
+
+%description
+%{pkgname} is an add-on package for GNU Emacs. It does wonderful things...
+
+%package -n %{name}-el
+Summary:        Elisp source files for %{pkgname} under GNU Emacs
+Group:
+Requires:       %{name} = %{version}-%{release}
+
+%description -n %{name}-el
+This package contains the elisp source files for %{pkgname} under GNU Emacs. You
+do not need to install this package to run %{pkgname}. Install the %{name}
+package to use %{pkgname} with GNU Emacs.
+
+%prep
+%setup -q -n %{pkg}-%{version}
+
+%build
+
+
+%install
+rm -rf $RPM_BUILD_ROOT
+
+
+%clean
+rm -rf $RPM_BUILD_ROOT
+
+
+%post
+
+
+%preun
+
+
+%files
+%defattr(-,root,root,-)
+%doc
+%{emacs_lispdir}/%{pkg}/*.elc
+%{emacs_startdir}/*.el
+%dir %{emacs_lispdir}/%{pkg}
+
+%files -n %{name}-el
+%defattr(-,root,root,-)
+%{emacs_lispdir}/%{pkg}/*.el
+
+%changelog
+
From ddfd89ee086548a156cc940452c80ad06b7821e8 Mon Sep 17 00:00:00 2001 From: ImportUser Date: May 24 2008 14:13:02 +0000 Subject: [PATCH 30/3559] Imported from MoinMoin --- diff --git a/Packaging:Octave.mw b/Packaging:Octave.mw new file mode 100644 index 0000000..5064389 --- /dev/null +++ b/Packaging:Octave.mw @@ -0,0 +1,179 @@ += How to package Octave packages = + + + +== What is Octave? == +The definition from [http://www.octave.org/ website] says: + +''"GNU Octave is a high-level language, primarily intended for numerical computations. It provides a convenient command line interface for solving linear and nonlinear problems numerically, and for performing other numerical experiments using a language that is mostly compatible with Matlab. It may also be used as a batch-oriented language."'' + +If you are interested in packaging Octave packages, you should check here for upstream sources: +* [http://octave.sourceforge.net/ The Octave Forge website] + +== Spec Templates for Octave packages == + +There are two types of Octave packages: arch-specific and noarch. + +=== Arch specific Octave spec template === + +
+%define pkg foo
+%{!?octave_api: %define octave_api %(octave-config -p API_VERSION || echo 0)}
+
+Name:           octave-%{pkg}
+Version:        1.2.1
+Release:        1%{?dist}
+Summary:        Foo Interface for Octave
+Group:          Applications/Engineering
+License:        GPLv2+
+URL:            http://octave.sourceforge.net
+Source0:        http://downloads.sourceforge.net/octave/%{pkg}-%{version}.tar.gz
+BuildRoot:      %{_tmppath}/%{name}-%{version}-%{release}-root%-(%{__id_u} -n)
+
+Requires:       octave(api) = %{octave_api}
+Obsoletes:      octave-forge < 20071015
+
+BuildRequires:  octave-devel >= 2.9.14
+BuildRequires:  gcc-c++ libstdc++-devel
+
+%define octave_distpkg %{?_vendor:%_vendor}%{?!_vendor:distributions}
+
+%description
+Provides Foo interface for Octave.
+
+%prep
+%setup -q -n %{pkg}-%{version}
+
+%build
+unset TERM
+%configure
+make TMPDIR=%{_tmppath} %{?_smp_mflags}
+
+%install
+unset TERM
+rm -rf %{buildroot}
+make install TMPDIR=%{_tmppath} DESTDIR=%{buildroot} DISTPKG=%{octave_distpkg}
+
+%clean
+rm -rf %{buildroot}
+
+%post
+%{_datadir}/octave/packages/%{pkg}-%{version}/packinfo/dist_admin install
+
+%preun
+%{_datadir}/octave/packages/%{pkg}-%{version}/packinfo/dist_admin uninstall
+
+%postun
+octave -q -H --no-site-file --eval "pkg('rebuild');"
+
+%files
+%defattr(-,root,root)
+%{_libexecdir}/octave/packages/%{pkg}-%{version}
+%dir %{_datadir}/octave/packages/%{pkg}-%{version}
+%{_datadir}/octave/packages/%{pkg}-%{version}/*.m
+%dir %{_datadir}/octave/packages/%{pkg}-%{version}/packinfo
+%doc %{_datadir}/octave/packages/%{pkg}-%{version}/packinfo/COPYING
+%doc %{_datadir}/octave/packages/%{pkg}-%{version}/packinto/DESCRIPTION
+%{_datadir}/octave/packages/%{pkg}-%{version}/packinfo/.autoload
+%{_datadir}/octave/packages/%{pkg}-%{version}/packinfo/INDEX
+%{_datadir}/octave/packages/%{pkg}-%{version}/packinfo/dist_admin
+%{_datadir}/octave/packages/%{pkg}-%{version}/packinfo/on_uninstall.m
+
+%changelog
+* Tue Sep 25 2007 Orion Poplawski  1.2.1-1
+- Octave package template
+
+ +=== Noarch Octave spec template === + +
+%define pkg foo
+
+Name:           octave-%{pkg}
+Version:        1.2.1
+Release:        1%{?dist}
+Summary:        Foo Interface for Octave
+Group:          Applications/Engineering
+License:        GPLv2+
+URL:            http://octave.sourceforge.net
+Source0:        http://downloads.sourceforge.net/octave/%{pkg}-%{version}.tar.gz
+BuildRoot:      %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
+
+Requires:       octave
+Obsoletes:      octave-forge < 20071015
+
+BuildRequires:  octave-devel >= 2.9.14
+BuildRequires:  gcc-c++ libstdc++-devel
+BuildArch:      noarch
+
+%define octave_distpkg %{?_vendor:%_vendor}%{?!_vendor:distributions}
+
+%description
+Provides Foo interface for Octave.
+
+%prep
+%setup -q -n %{pkg}-%{version}
+
+%build
+
+%install
+unset TERM
+rm -rf %{buildroot}
+make install PACKAGE=%SOURCE0 TMPDIR=%{_tmppath} \
+DESTDIR=%{buildroot} DISTPKG=%{octave_distpkg}
+
+%clean
+rm -rf %{buildroot}
+
+%post
+%{_datadir}/octave/packages/%{pkg}-%{version}/packinfo/dist_admin install
+
+%preun
+%{_datadir}/octave/packages/%{pkg}-%{version}/packinfo/dist_admin uninstall
+
+%postun
+octave -q -H --no-site-file --eval "pkg('rebuild');"
+
+%files
+%defattr(-,root,root)
+%dir %{_datadir}/octave/packages/%{pkg}-%{version}
+%{_datadir}/octave/packages/%{pkg}-%{version}/*.m
+%dir %{_datadir}/octave/packages/%{pkg}-%{version}/packinfo
+%doc %{_datadir}/octave/packages/%{pkg}-%{version}/packinfo/COPYING
+%doc %{_datadir}/octave/packages/%{pkg}-%{version}/packinto/DESCRIPTION
+%{_datadir}/octave/packages/%{pkg}-%{version}/packinfo/.autoload
+%{_datadir}/octave/packages/%{pkg}-%{version}/packinfo/INDEX
+%{_datadir}/octave/packages/%{pkg}-%{version}/packinfo/dist_admin
+%{_datadir}/octave/packages/%{pkg}-%{version}/packinfo/on_uninstall.m
+
+%changelog
+* Tue Sep 25 2007 Orion Poplawski  1.2.1-1
+- Octave package template
+
+ +=== Summary of differences between arch-specific and noarch octave packages === + +* Noarch packages set BuildArch: noarch +* Don't require a specific api version +* No build step needed, just install from the source tar ball +* Noarch packages don't install anything into %{_libexecdir}/octave/packages + +== Octave packaging tips == + +=== Naming of Octave packages === +Packages of Octave packages have their own naming scheme. They should take into account the upstream name of the package. This makes a package name format of octave-$NAME. When in doubt, use the name of the module that you type to import it in octave. + +'''Examples: ''' +
+octave-java (Octave package named java)
+octave-gsl (Octave package named gsl)
+
+ +=== unset TERM === +Due to an issue with octave emitting an escape sequence (due to readline library) on startup, you need to unset the TERM variable in the %build and %install sections. + +=== Updating the octave package database === +Octave maintains a list of installed packages in /usr/share/octave/octave_packages that needs to be updated on package install and removal. This is handled by the dist_admin script in each package. + +=== Documentation files === +All package files are installed into the octave directories. The COPYING and DESCRIPTION files are documentation and need to be marked as %doc. The others are not. From 66244faa5f72e0eca6fd8aafe13324a220acac7f Mon Sep 17 00:00:00 2001 From: ImportUser Date: May 24 2008 14:13:02 +0000 Subject: [PATCH 32/3559] Imported from MoinMoin --- diff --git a/Packaging:ReviewGuidelines.mw b/Packaging:ReviewGuidelines.mw new file mode 100644 index 0000000..970fcee --- /dev/null +++ b/Packaging:ReviewGuidelines.mw @@ -0,0 +1,73 @@ + += Package Review Guidelines = +This is a set of guidelines for Package Reviews. Note that a complete list of things to check for would be impossible, but every attempt has been made to make this document as comprehensive as possible. Reviewers and contributors (packagers) should use their best judgement whenever items are unclear, and if in doubt, ask on the [https://www.redhat.com/mailman/listinfo/fedora-packaging fedora-packaging list] . + +'''Author:''' [[TomCallaway| Tom 'spot' Callaway]]
+'''Revision:''' 0.27
+'''Initial Draft:''' Monday Jun 27, 2005
+'''Last Revised:''' Friday Nov 30, 2007
+ +== Package Review Process == +Contributors and reviewers should follow the PackageReviewProcess. + +{{Anchor|ThingsToCheckOnReview}} +== Things To Check On Review == + +There are many many things to check for a review. This list is provided to assist new reviewers in identifying areas that they should look for, but is by no means complete. Reviewers should use their own good judgement when reviewing packages. The items listed fall into two categories: '''SHOULD''' and '''MUST'''. Items marked as '''SHOULD''' are things that the package (or reviewer) '''SHOULD''' do, but is not required to do. Items marked as '''MUST''' are things that the package (or reviewer) '''MUST''' do. If a package fails a '''MUST''' item, that is considered a blocker. No package with blockers can be approved on a review. Those items must be fixed before approval can be given. + +'''MUST Items:''' + +- '''MUST''': rpmlint must be run on every package. The output should be posted in the review.
+- '''MUST''': The package must be named according to the [[Packaging/NamingGuidelines| Package Naming Guidelines]] .
+- '''MUST''': The spec file name must match the base package %{name}, in the format %{name}.spec unless your package has an exemption on [[Packaging/NamingGuidelines| Package Naming Guidelines]] .
+- '''MUST''': The package must meet the [[Packaging/Guidelines| Packaging Guidelines]] .
+- '''MUST''': The package must be licensed with a Fedora approved license and meet the [[Packaging/LicensingGuidelines| Licensing Guidelines]] .
+- '''MUST''': The License field in the package spec file must match the actual license.
+- '''MUST''': If (and only if) the source package includes the text of the license(s) in its own file, then that file, containing the text of the license(s) for the package must be included in %doc.
+- '''MUST''': The spec file must be written in American English.
+- '''MUST''': The spec file for the package MUST be legible. If the reviewer is unable to read the spec file, it will be impossible to perform a review. Fedora is not the place for entries into the Obfuscated Code Contest (http://www.ioccc.org/).
+- '''MUST''': The sources used to build the package must match the upstream source, as provided in the spec URL. Reviewers should use md5sum for this task. If no upstream URL can be specified for this package, please see the [[Packaging/SourceURL| Source URL Guidelines]] for how to deal with this.
+- '''MUST''': The package must successfully compile and build into binary rpms on at least one supported architecture.
+- '''MUST''': If the package does not successfully compile, build or work on an architecture, then those architectures should be listed in the spec in ExcludeArch. Each architecture listed in ExcludeArch needs to have a bug filed in bugzilla, describing the reason that the package does not compile/build/work on that architecture. The bug number should then be placed in a comment, next to the corresponding ExcludeArch line. New packages will not have bugzilla entries during the review process, so they should put this description in the comment until the package is approved, then file the bugzilla entry, and replace the long explanation with the bug number. The bug should be marked as blocking one (or more) of the following bugs to simplify tracking such issues: [https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=FE-ExcludeArch-x86 FE-ExcludeArch-x86] , [https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=FE-ExcludeArch-x64 FE-ExcludeArch-x64] , [https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=FE-ExcludeArch-ppc FE-ExcludeArch-ppc] , [https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=FE-ExcludeArch-ppc64 FE-ExcludeArch-ppc64]
+- '''MUST''': All build dependencies must be listed in BuildRequires, except for any that are listed in the [wiki:Self:Packaging/Guidelines#Exceptions exceptions section of Packaging Guidelines] ; inclusion of those as BuildRequires is optional. Apply common sense.
+- '''MUST''': The spec file MUST handle locales properly. This is done by using the %find_lang macro. Using %{_datadir}/locale/* is strictly forbidden.
+- '''MUST''': Every binary RPM package which stores shared library files (not just symlinks) in any of the dynamic linker's default paths, must call ldconfig in %post and %postun. If the package has multiple subpackages with libraries, each subpackage should also have a %post/%postun section that calls /sbin/ldconfig. An example of the correct syntax for this is: +
+%post -p /sbin/ldconfig
+
+%postun -p /sbin/ldconfig
+

+- '''MUST''': If the package is designed to be relocatable, the packager must state this fact in the request for review, along with the rationalization for relocation of that specific package. Without this, use of Prefix: /usr is considered a blocker.
+- '''MUST''': A package must own all directories that it creates. If it does not create a directory that it uses, then it should require a package which does create that directory. Refer to the [[Packaging/Guidelines#FileAndDirectoryOwnership| Guidelines]] for examples.
+- '''MUST''': A package must not contain any duplicate files in the %files listing.
+- '''MUST''': Permissions on files must be set properly. Executables should be set with executable permissions, for example. Every %files section must include a %defattr(...) line.
+- '''MUST''': Each package must have a %clean section, which contains rm -rf %{buildroot} ([wiki:Self:Packaging/Guidelines#UsingBuildRootOptFlags or $RPM_BUILD_ROOT] ).
+- '''MUST''': Each package must consistently use macros, as described in the [wiki:Self:Packaging/Guidelines#macros macros section of Packaging Guidelines] .
+- '''MUST''': The package must contain code, or permissable content. This is described in detail in the [wiki:Self:Packaging/Guidelines#CodeVsContent code vs. content section of Packaging Guidelines] .
+- '''MUST''': Large documentation files should go in a -doc subpackage. (The definition of large is left up to the packager's best judgement, but is not restricted to size. Large can refer to either size or quantity)
+- '''MUST''': If a package includes something as %doc, it must not affect the runtime of the application. To summarize: If it is in %doc, the program must run properly if it is not present.
+- '''MUST''': Header files must be in a -devel package.
+- '''MUST''': Static libraries must be in a -static package.
+- '''MUST''': Packages containing pkgconfig(.pc) files must 'Requires: pkgconfig' (for directory ownership and usability).
+- '''MUST''': If a package contains library files with a suffix (e.g. libfoo.so.1.1), then library files that end in .so (without suffix) must go in a -devel package.
+- '''MUST''': In the vast majority of cases, devel packages must require the base package using a fully versioned dependency: Requires: %{name} = %{version}-%{release}
+- '''MUST''': Packages must NOT contain any .la libtool archives, these should be removed in the spec.
+- '''MUST''': Packages containing GUI applications must include a %{name}.desktop file, and that file must be properly installed with desktop-file-install in the %install section. This is described in detail in the [wiki:Self:Packaging/Guidelines#desktop desktop files section of Packaging Guidelines] . If you feel that your packaged GUI application does not need a .desktop file, you must put a comment in the spec file with your explanation.
+- '''MUST''': Packages must not own files or directories already owned by other packages. The rule of thumb here is that the first package to be installed should own the files or directories that other packages may rely upon. This means, for example, that no package in Fedora should ever share ownership with any of the files or directories owned by the filesystem or man package. If you feel that you have a good reason to own a file or directory that another package owns, then please present that at package review time.
+- '''MUST''': At the beginning of %install, each package MUST run rm -rf %{buildroot} ([wiki:Self:Packaging/Guidelines#UsingBuildRootOptFlags or $RPM_BUILD_ROOT] ). See [wiki:Self:Packaging/Guidelines#PreppingBuildRootForInstall Prepping BuildRoot For %install] for details.
+- '''MUST''': All filenames in rpm packages must be valid UTF-8.
+'''SHOULD Items:''' + +- '''SHOULD''': If the source package does not include license text(s) as a separate file from upstream, the packager SHOULD query upstream to include it.
+- '''SHOULD''': The description and summary sections in the package spec file should contain translations for supported Non-English languages, if available.
+- '''SHOULD''': The reviewer should test that the package builds in mock. See [wiki:Self:PackageMaintainers/MockTricks MockTricks] for details on how to do this.
+- '''SHOULD''': The package should compile and build into binary rpms on all supported architectures.
+- '''SHOULD''': The reviewer should test that the package functions as described. A package should not segfault instead of running, for example.
+- '''SHOULD''': If scriptlets are used, those scriptlets must be sane. This is vague, and left up to the reviewers judgement to determine sanity.
+- '''SHOULD''': Usually, subpackages other than devel should require the base package using a fully versioned dependency.
+- '''SHOULD''': The placement of pkgconfig(.pc) files depends on their usecase, and this is usually for development purposes, so should be placed in a -devel pkg. A reasonable exception is that the main pkg itself is a devel tool not installed in a user runtime, e.g. gcc or gdb.
+- '''SHOULD''': If the package has file dependencies outside of /etc, /bin, /sbin, /usr/bin, or /usr/sbin consider requiring the package which provides the file instead of the file itself. Please see [[Packaging/Guidelines#FileDeps| File Dependencies]] in the Guidelines for further information. + +---- +[[Category:Extras]] From 8946c5ef53e62c5d80546b21170f13ba774775aa Mon Sep 17 00:00:00 2001 From: ImportUser Date: May 24 2008 14:13:02 +0000 Subject: [PATCH 34/3559] Imported from MoinMoin --- diff --git a/Packaging:Mono.mw b/Packaging:Mono.mw new file mode 100644 index 0000000..4f174b8 --- /dev/null +++ b/Packaging:Mono.mw @@ -0,0 +1,144 @@ +
#!html
+
+
+ += Mono Packaging = +'''Revision:''' 0.3
+'''Last Revised:''' Monday Aug 27, 2007
+ + +== Glossary == +* '''AOT''': Ahead Of Time. This usually refers to the ELF .so file that is the result of ahead of time compiling an assembly. AOTs are dependent on the assemblies they were generated from for certain data (unlike their equivalents in python and java). AOTs are created explicitly, not automatically. +* '''Assembly''': An assembly is the EXE or DLL file created by compiling a mono application. These are not the same as EXE's or DLL's created by compiling a C or C++ program on Windows. An assembly contains CIL code rather than machine code. +* '''CIL''': CIL stands for Common Intermediate Language. It is roughly equivalent to java bytecode and is generally portable across architectures. Some programming practices (calling out to native system libraries) can lead to CIL code that will not run on all architectures. +* '''Glue Libraries''': Libraries which bridge a system library written in C or C++ with Mono. These wrappers are separate different than AOTs. + +== Packaging Tips == + +=== File Locations === + +Mono packages should install assemblies to %{_libdir} rather than /usr/lib or %{_datadir}. In most cases the preference is for %{_libdir}/PACKAGENAME. We use %{_libdir} because we do not consider mono packages to be noarch. + +The main reason for this is that mono can ahead-of-time compile its assemblies into ELF shared objects. These AOTs have to exist in the same directory as their DLL/EXE counterparts otherwise mono cannot use them. Even if we, as packagers, choose not to create the AOT files when we build the mono rpms, the system administrator can choose to create them after install. Since there's no way to place the mono assemblies into an arch independent directory and the AOTs into arch dependent directories, the whole thing has to go into an arch dependent tree. + +=== gacutil in a spec file === + +gacutil is used to register dlls with mono (think of it as installing a library - which it is!). + +When packaging *any* mono application which generates libraries which gacutil then registers (say mysql-connector-net), you need something like the following in the spec file + +
+%install
+%{__rm} -rf %{buildroot}
+%{__mkdir_p} %{buildroot}%{_libdir}/mono/gac/
+gacutil -i bin/mono-1.0/release/MySql.Data.dll -f -package mysql-connector-net -root %{buildroot}%{_libdir}
+
+%files
+%{_libdir}/mono/gac/MySql.Data
+%{_libdir}/mono/mysql-connector-net/MySql.Data.dll
+
+ +gacutil format + +
+-i = input dll
+-f = check references
+-package = package name
+-root = build root
+
+ +=== RPMS and source === +{{Template:Warning}} Don't build RPMS against built from source versions of mono. It will work for you but probably not for other users! + +While you may get away with recompiling the source for part of the overall package (such as gnome-panel is part of gnome or evolution-data-server is part of evolution) for other programs, you should not attempt this with Mono. + +If you're going to use the source, you '''MUST''' remove the RPMS first. + +Compiling mono is not a trivial matter and may not even work (when you download the source, you must also ''make get-monolite-latest'' which grabs a version of the corelib and mcs which are need for compiling the main C# compilers - the monolite-latest does not always work and you end up without a working copy of Mono. + +=== Reporting Mono bugs === + +Upstream Mono's bugtracker is located at Ximian: [http://bugzilla.ximian.com] + +=== rpmlint and mono packages === +rpmlint is a program that checks packages for common problems. For mono packages, some of the rpmlint messages can be disregarded. + +Mono installs binaries in %{_libdir}//bin with symlinks back to /usr/bin. rpmlint is not happy with this and generates an error (which is the correct behaviour). It will also not recognise that mono libraries are not ELF format and may generate errors on this as well. + +rpmlint will also pick up on any .pc file installed in the rpm (see below). + +=== -devel packages === + +Mono packages '''must''' package .pc files in a -devel package, even if that is the only file that will be included. If we were to permit .pc files in non-devel packages, then we'll have non-devel packages that depend on -devel packages, inflating the install needlessly. + +=== Building Mono Packages Using mock with SELinux Enabled === + +See [[Extras/MockTricks]] + +=== Empty debuginfo === + +Sometimes building mono packages results in an empty debuginfo sub package, one without any files to install. See [[Packaging/Debuginfo]] + +== Incorrect Behaviours == + +=== Distributing Prebuilt Assemblies === +Because mono .dlls are generally architecture independent, upstream may ship tarballs which install precompiled .dlls and .exes. All packages '''must''' build from source so the packager needs to watch out for these tarballs and be certain not to use them. (This can sneak in during upgrades as well, so the packager has to make sure they're building from source every time the tarball is changed.) + +=== Distributing .DLLs from other projects === + +The Mono project's website makes +[http://www.mono-project.com/Assemblies_and_the_GAC#Libraries_with_Unstable_APIs this suggestion] + +
Sometimes developers might want to distribute a library to other developers but they might not have a library that is API stable or has not matured enough over time to guarantee the backwards-compatibility of their libraries or they are not willing to maintain multiple packages of the various versions for users.
+[...] 
+To solve this problem, we recommend that:
+
+* The library developer ships a properly configured pkg-config file.
+* The library consumers include an "update-libraries" target on their Makefile that will import the latest version of a library from a system directory into their application source code distribution.
+* The library consumers ship this library as part of their package.
+
+ +This suggestion may make it easier for applications targetting unstable library APIs but it is '''''extremely poor practice'''''. Using libraries in this manner has all the same problems as linking with static libraries, most notably that the application can suffer from security holes in the library long after it is fixed upstream. Mono applications in Fedora cannot include upstream DLLs (even if they are compiled from source). This is a blocker issue and '''must''' be fixed. + +There are several techniques for detecting the presence of these libraries, none of them fool proof. If you know of a better method, please add it: + +1. Upstream tarball contains .dlls that were not rebuilt from source contained in the package. +2. Look through the installed .dlls for any that have the same name as system .dlls or are suspiciously out of place (Package is myDiary and contains mysql.dll, sqlite.dll, and gtk-sharp.dll) +3. Source directories look odd: +
+PKGNAME/
+src/
+data/
+libs/
+gtk-sharp/
+atk-sharp/
+
+ +=== Redefining _libdir === + +Packagers should avoid redefining _libdir in their spec file. Redefinition of this macro will cover up problems instead of helping fix them. Packagers should: + +1. Identify which directories the files should install into according to the [[Packaging/Guidelines| Packaging Guidelines]] . +2. Patch the packages build scripts to install to those locations. +3. Identify places where the package has hardcoded the old locations instead of the new ones and fix those. +4. Either report the issues to upstream or submit patches. Note that upstream projects are generally receptive to patches that allow package builders to redefine install locations at build time -- less receptive to patches which change upstream's hardcoded defaults to our hardcoded defaults. + +=== Defining target === + +Was done for a brief period when we attempted to package mono apps as noarch. It was not necessary then (the actual fix was to stop using AC_CANONICAL_* in the configure.ac file) and it is definitely not needed now that we are no longer building noarch mono packages. From 47f88cdd0d5ec441ec1c7631997489b6d928aac4 Mon Sep 17 00:00:00 2001 From: ImportUser Date: May 24 2008 14:13:02 +0000 Subject: [PATCH 36/3559] Imported from MoinMoin --- diff --git a/Packaging:RPMMacros.mw b/Packaging:RPMMacros.mw new file mode 100644 index 0000000..928dd42 --- /dev/null +++ b/Packaging:RPMMacros.mw @@ -0,0 +1,59 @@ + += Valid RPM Macros = + +Here are the definitions for some common specfile macros as they are defined on Fedora Core 3 (rpm-4.3.2-21). For definitions of more macros, examine the output of "rpm --showrc". To see the expanded definition of a macro use the command "rpm --eval ''''%{macro}''''". Note that neither command will take into account macros defined inside specfiles, but both will take into account macros defined in your ~/.rpmmacros file and macros defined on the command line. + + +=== Macros mimicking autoconf variables === +
+%{_sysconfdir}        /etc
+%{_initrddir}         %{_sysconfdir}/rc.d/init.d
+%{_prefix}            /usr
+%{_exec_prefix}       %{_prefix}
+%{_bindir}            %{_exec_prefix}/bin
+%{_lib}               lib (lib64 on 64bit systems)
+%{_libdir}            %{_exec_prefix}/%{_lib}
+%{_libexecdir}        %{_exec_prefix}/libexec
+%{_sbindir}           %{_exec_prefix}/sbin
+%{_sharedstatedir}    %{_prefix}/com
+%{_datadir}           %{_prefix}/share
+%{_includedir}        %{_prefix}/include
+%{_oldincludedir}     /usr/include
+%{_infodir}           /usr/share/info
+%{_mandir}            /usr/share/man
+%{_localstatedir}     /var
+
+ +=== RPM directory macros === +
+%{_topdir}            %{_usrsrc}/redhat
+%{_builddir}          %{_topdir}/BUILD
+%{_rpmdir}            %{_topdir}/RPMS
+%{_sourcedir}         %{_topdir}/SOURCES
+%{_specdir}           %{_topdir}/SPECS
+%{_srcrpmdir}         %{_topdir}/SRPMS
+
+ +=== Build flags macros === +
+%{_global_cflags}     -O2 -g -pipe
+%{_optflags}          %{__global_cflags} -m32 -march=i386 -mtune=pentium4 # if redhat-rpm-config is installed
+
+ +=== Other macros === +
+%{_var}               /var
+%{_tmppath}           %{_var}/tmp
+%{_usr}               /usr
+%{_usrsrc}            %{_usr}/src
+%{_docdir}            %{_datadir}/doc
+
+ +== Reference == +Here are macros from other distributions to aid you in package conversion: + +* [[Extras/ReferencePLDRPMMacros| PLD RPM Macros]] +* [[Extras/ReferenceMandrakeRPMMacros| Mandrake RPM Macros]] +---- +[[Category:Extras]] From bbcea2b84c9c7de0d9262178ea64f5e85df111ae Mon Sep 17 00:00:00 2001 From: ImportUser Date: May 24 2008 14:13:02 +0000 Subject: [PATCH 38/3559] Imported from MoinMoin --- diff --git a/Packaging:PHP.mw b/Packaging:PHP.mw new file mode 100644 index 0000000..354f536 --- /dev/null +++ b/Packaging:PHP.mw @@ -0,0 +1,163 @@ += Guidelines for packaging PHP addon modules = + + + +== Different kinds of packages == + +There are basically two different kinds of php modules, which are packaged for Fedora Extras: + +* [http://pecl.php.net PECL] (PHP Extention Community Library), which are PHP modules usually written in C, which are dynamically loaded by the PHP interpreter on startup. +* [http://pear.php.net PEAR] (PHP Extension and Application Repository), which are reusable components written in PHP, usually classes, which can be used in your own PHP applications and scripts by using e.g. the include() directive. + +While upstream used the same package and distribution format for both, creating RPMs has to take some differences into account. + +{{Anchor|NamingScheme}} +== Naming scheme == + +* PECL packages should be named ''php-pecl-PECLPackageName-%{version}-%{release}.%{arch}.rpm''. +* PEAR packages should be named ''php-pear-PEARPackageName-%{version}-%{release}.noarch.rpm''. +* Other packages should be named ''php-PackageName-%{version}-%{release}.%{arch}.rpm''; %{arch} can be "noarch" where appropriate. + +Please make sure that the PEAR package is correctly being built for noarch. + +The PECLPackageName and the PEARPackageName should be consistent with the upstream naming scheme. +The Crack PHP Extension would thus be named ''php-pecl-crack'' with the resulting packages being ''php-pecl-crack-0.4-1.i386.rpm'' and ''php-pecl-crack-0.4-1.src.rpm''. + +Note that web applications that happen to be written in PHP do not belong under the php-* namespace. + +== File Placement == + +Non-PEAR PHP extensions should put their Class files in /usr/share/php. + +== Requires and Provides == + +=== PEAR Packages === + +A PEAR package '''MUST''' have: + +
+BuildRequires: php-pear(PEAR)
+Requires: php-pear(PEAR)
+Requires(post): %{__pear}
+Requires(postun): %{__pear}
+Provides:     php-pear(foo) = %{version}
+
+ +=== PECL Packages === + +A PECL package '''MUST''' have: + +
+BuildRequires: php-devel, php-pear
+Requires(post): %{__pecl}
+Requires(postun): %{__pecl}
+
+%if %{?php_zend_api}0
+Requires:     php(zend-abi) = %{php_zend_api}
+Requires:     php(api) = %{php_core_api}
+%else
+Requires:     php-api = %{php_apiver}
+%endif
+
+Provides:     php-pecl(foo) = %{version}
+
+ +=== Other Packages === + +PHP addons which are neither PEAR nor PECL should require what makes sense (either a base PHP version or a php-api as necessary). + +== Macros and scriptlets == + +=== PEAR Modules === + +The php-pear package in Fedora Core 5 and above (version 1:1.4.9-1.2) provides several useful macros: +* %{pear_phpdir} +* %{pear_docdir} +* %{pear_testdir} +* %{pear_datadir} +* %{pear_xmldir} + +These defintions for the .spec should be of interest: +
+BuildRequires:    php-pear >= 1:1.4.9-1.2
+Provides:         php-pear(PackageName) = %{version}
+Requires:         php >= 4.3, php-pear(PEAR)
+Requires(post):   %{_bindir}/pear
+Requires(postun): %{_bindir}/pear
+
+ +And here are some recommended scriptlets for properly registering and unregistering the module: +
+%post
+%{_bindir}/pear install --nodeps --soft --force --register-only %{pear_xmldir}/Foo_Bar.xml >/dev/null ||:
+
+%postun
+if [ "$1" -eq "0" ] ; then
+%{_bindir}/pear uninstall --nodeps --ignore-errors --register-only Foo_Bar >/dev/null ||:
+fi
+
+ +=== PECL Modules === + +The php-pear package in Fedora Core 5 and above (version 1:1.4.9-1.2) provides several useful macros: +* %{pecl_phpdir} +* %{pecl_docdir} +* %{pecl_testdir} +* %{pecl_datadir} +* %{pecl_xmldir} + +You may need to define a few additional macros to extract some information from PHP. It is recommended that you use the following: +
+%global php_apiver  %((echo 0; php -i 2>/dev/null | sed -n 's/^PHP API => //p') | tail -1)
+%{!?__pecl:     %{expand: %%global __pecl     %{_bindir}/pecl}}
+%{!?php_extdir: %{expand: %%global php_extdir %(php-config --extension-dir)}}
+
+ +And here are some recommended scriptlets for properly registering and unregistering the module: +
+%if 0%{?pecl_install:1}
+%post
+%{pecl_install} %{pecl_xmldir}/%{name}.xml >/dev/null || :
+%endif
+
+
+%if 0%{?pecl_uninstall:1}
+%postun
+if [ $1 -eq 0 ]  ; then
+%{pecl_uninstall} %{pecl_name} >/dev/null || :
+fi
+%endif
+
+ +=== Other Modules === + +If your module includes compiled code, you may need to define some macros to extract some information from PHP. It is recommended that you user the following: +
+%global php_apiver  %((echo 0; php -i 2>/dev/null | sed -n 's/^PHP API => //p') | tail -1)
+%global php_extdir  %(php-config --extension-dir 2>/dev/null || echo "undefined")
+%global php_version %(php-config --version 2>/dev/null || echo 0)
+
+ +== Additional Hints for Packagers == + +=== PEAR & PECL Packages === + +The source archive contains a package.xml outside any directory, so you have to use use +
+%setup -q -c
+
+in your %prep section to avoid writing files to the build root. + +=== PEAR Packages === + +To create your initial specfile, you can use the default template provided by the rpmdevtools package: + +
+fedora-newrpmspec -t php-pear php-pear-Foo
+
+ +Or you can generate one; make sure you have the php-pear-PEAR-Command-Packaging package installed: + +
+pear make-rpm-spec Foo.tgz
+
From 4567ccd310d1c65ac0bbb6759592a7535e3514e6 Mon Sep 17 00:00:00 2001 From: ImportUser Date: May 24 2008 14:13:02 +0000 Subject: [PATCH 40/3559] Imported from MoinMoin --- diff --git a/Packaging:Cmake.mw b/Packaging:Cmake.mw new file mode 100644 index 0000000..4d473a5 --- /dev/null +++ b/Packaging:Cmake.mw @@ -0,0 +1,56 @@ += Guidelines for cmake = + +More and more projects are moving to cmake, especially with KDE4 making the jump. It seems like it is time to start collecting cmake best practices for generating Fedora RPMS using cmake + + + + +{{Anchor|cmakeMacros}} +== RPM Macros == + +
+
+
+%_cmake_lib_suffix64 -DLIB_SUFFIX=64
+%__cmake %{_bindir}/cmake
+
+%cmake \
+CFLAGS="${CFLAGS:-%optflags}" ; export CFLAGS ; \
+CXXFLAGS="${CXXFLAGS:-%optflags}" ; export CXXFLAGS ; \
+FFLAGS="${FFLAGS:-%optflags}" ; export FFLAGS ; \
+%__cmake \\\
+%if "%{?_lib}" == "lib64" \
+%{?_cmake_lib_suffix64} \\\
+%endif \
+-DCMAKE_INSTALL_PREFIX:PATH=%{_prefix} \\\
+-DBUILD_SHARED_LIBS:BOOL=ON
+
+ + +{{Anchor|cmakeUsage}} +== Specfile Usage == + +
+%build
+%cmake .
+make VERBOSE=1 %{?_smp_mflags}
+
+
+%install
+rm -rf $RPM_BUILD_ROOT
+make install DESTDIR=$RPM_BUILD_ROOT
+
+
+%check
+ctest
+
+ + +{{Anchor|cmakeNotes}} +== Notes == +'''NOTE''': -DCMAKE_SKIP_RPATH:BOOL=ON. With recent cmake-2.4, it should not be used. This cmake version handles RPATHs issues correctly (set them in build-dir, remove them during installation). Setting CMAKE_SKIP_RPATH for this version would avoid RPATHs in build-dir too. This might link binaries against system-libraries (e.g. when a previous version of the package was installed) instead of the libraries which were created by the build. + +Nevertheless, RPATH issues might arise when cmake was used improperly. E.g. installing a target with INSTALL(FILES ... RENAME ...) will '''not''' strip rpaths; in this case INSTALL(TARGETS ...) must be used in combination with changing the OUTPUT_NAME property. + +'''NOTE''': The proposed %cmake macro defines -DLIB_SUFFIX=64 on 64bit platforms. Not all packages handle this gracefully. The kdesvn package, for example, included cmake files taken from the KDE upstream that needed to be patched for this to work properly for all files (esp. .la files for loadable KDE modules). You might want to see the patch included in the kdesvn .src.rpm for example changes. From 3a8c5570e385b35b2f6f8e0bb93825cd08e33840 Mon Sep 17 00:00:00 2001 From: ImportUser Date: May 24 2008 14:13:02 +0000 Subject: [PATCH 42/3559] Imported from MoinMoin --- diff --git a/Packaging:Guidelines.mw b/Packaging:Guidelines.mw new file mode 100644 index 0000000..d9602c2 --- /dev/null +++ b/Packaging:Guidelines.mw @@ -0,0 +1,847 @@ + += Packaging Guidelines = + +It is the reviewer's responsibility to point out specific problems with a package and a packager's responsibility to deal with those issues. The reviewer and packager work together to determine the severity of the issues (whether they block a package or can be worked on after the package is in the repository.) The Packaging Guidelines are a collection of common issues and the severity that should be placed on them. While these guidelines should not be ignored, they should also not be blindly followed. If you think that your package should be exempt from part of the Guidelines, please bring the issue to the Fedora Packaging Committee. + +Please remember that any package that you submit must also conform to the [[Packaging/ReviewGuidelines| Review Guidelines]] . + +'''Author:''' [[TomCallaway| Tom 'spot' Callaway]] (based on many other documents)
+'''Revision:''' 0.91
+'''Initial Draft:''' Wednesday Feb 23, 2005
+'''Last Revised:''' Wednesday May 21, 2008
+ + + +{{Anchor|Naming}} +== Naming == + +You should go through the ["Packaging/NamingGuidelines"] to ensure that your package is named appropriately. + +{{Anchor|Legal}} +== Legal == + +There are various legal concerns to consider when packaging for Fedora. + +{{Anchor|LegalLicensing}} +=== Licensing === + +You should review ["Licensing"] and the ["Packaging/LicensingGuidelines"] to ensure that your package is licensed appropriately. + +{{Anchor|SourceRequirement}} +== No inclusion of pre-built binaries or libraries == + +All binaries or libraries included with Fedora packages must have been built from sourcecode included in the source package. This is a requirement for the following reasons: +* Security: Pre-packaged binaries and libraries not built from source could include anything, malicious, dangerous, or just broken. Also, these are functionally impossible to patch. +* Compiler Flags: Pre-packaged binaries and libraries not built from source probably don't have the standard Fedora compiler flags for security and optimization. + +If you are in doubt as to whether something is considered a binary or library, here is some helpful criteria: +* Is it executable? If so, it is probably a binary. +* Does it contain a .so, ,so.#, or .so.#.#.# extension? If so, it is probably a library. +* If in doubt, ask your reviewer. If the reviewer is not sure, they should ask the Fedora Packaging Committee. + +Packages which require non-open source components to build are also not permitted (e.g. proprietary compiler required). + +{{Anchor|SourceRequirementExceptions}} +=== Exceptions === +* Some software (usually related to compilers or cross-compiler environments) cannot be build without the use of a previous toolchain or development environment (open source). If you have a package which meets this criteria, contact the Fedora Packaging Committee for approval. +* An exception is made for binary firmware, as long as it meets the requirements documented here: [wiki:Self:Packaging/LicensingGuidelines#BinaryFirmware BinaryFirmware] + +{{Anchor|PackageFromScratch}} +== Writing a package from scratch == +When writing a package from scratch, you should base your spec file on the Fedora spec file template (see ["rpmdevtools"] ). Please put your preferences about spec file formatting and organization aside, and try to conform to this template as much as possible. This is not because we believe this is the only right way to write a spec file, but because it often makes it easier for QA to spot mistakes and quickly understand what you are trying to do. + +{{Anchor|ModifyingExistingPackage}} +== Modifying an existing package == +If you base a package on an existing non-Fedora package, be careful to verify its correctness and to understand exactly what goes on. Do not submit a package without knowing what those strange, but innocent-looking commands do. + +In particular, you should +*verify any sources and patches. +*verify that the license stated in the spec file matches the actual license of the software (see [[tags| Tags]] ), +*skim the summary and description for typos and oddities (see [[summary| Summary and description]] ), +*make sure that the correct build root is used, +*ensure that macro usage is consistent (see [[macros| Macros]] ). + +Keep old changelog entries to credit the original authors. Entries that are several years old or refer to ancient versions of the software may be erased. If you end up doing radical changes and re-write most of the spec file anyway, feel free to start the changelog from scratch. In other words, use your best judgement. + +{{Anchor|layout}} +== Filesystem Layout == + +Fedora follows the [http://www.pathname.com/fhs/ Filesystem Hierarchy Standard] with regards to filesystem layout. The FHS defines where files should be placed on the system. Fedora packages should follow the FHS whenever possible. Any deviation from the FHS should be rationalized when the package is reviewed. + +There is one notable exception, libexecdir. + +{{Anchor|libexecdir}} +=== Libexecdir === + +The [http://www.pathname.com/fhs/ Filesystem Hierarchy Standard] does not include any provision for libexecdir, but Fedora packages can store appropriate files there. Libexecdir (aka, /usr/libexec on Fedora systems) should be used as the directory for executable programs that are designed primarily to be run by other programs rather than by users. +Fedora's rpm includes a macro for libexecdir, %{_libexecdir}. Packagers are highly encouraged to store libexecdir files in a package-specific subdirectory of %{_libexecdir}, such as %{_libexecdir}/%{name}. + +{{Anchor|rpmlint}} +== Use rpmlint == +Run rpmlint on the rpms to examine them for common errors, and fix them (unless rpmlint is wrong, which can happen, too). If you find rpmlint's output cryptic, the -i switch to it can be used to get more verbose descriptions of most errors and warnings. The rpmlint package is available in the Fedora repositories. + +=== Rpmlint Errors === + +Rpmlint has the ability to make a lot of noise when it is run, even on perfectly valid packages. This section exists to help you decipher the messages, so that you can make fixes as necessary. + +* E: foo-package no-packager-tag: This error occurs because no Packager: value is defined in the spec file. In Fedora, we do not use the Packager tag, so you can ignore this error. +* E: foo-package no-signature: This error occurs because your package is not signed. Since Fedora doesn't store SRPMS in CVS (only the files inside them), you do not need to sign your package, and you can ignore this error. +* W: foo-package summary-ended-with-dot Summary of my package.: This error occurs because the entry in your spec for Summary: ended with a period. Just get rid of the period at the end of the line. +* E: foo-package wrong-script-end-of-line-encoding /path/to/somefile: This error occurs because of DOS line breaks in a file. Fix it with sed in the %prep section: %{__sed} -i 's/\r//' src/somefile -- DONT use dos2unix, that can cause build fail on FC3. +* E: foo-package invalid-lc-messages-dir /usr/share/locale/xx_XX/LC_MESSAGES/foo.mo: This error is a common false positive and usually should be ignored. + +{{Anchor|Changelogs}} +== Changelogs == +''Every time'' you make changes, that is, whenever you increment the E-V-R of a package, add a changelog entry. This is important not only to have an idea about the history of a package, but also to enable users, fellow packages, and QA people to easily spot the changes that you make. + +If a particular change is related to a Bugzilla bug, include the bug ID in the changelog entry for easy reference, e.g. + +
+* Wed Jun 14 2003 Joe Packager  - 1.0-2
+- Added README file (#42).
+
+ +You must use one of the following formats: +
+* Fri Jun 23 2006 Jesse Keating  - 0.6-4
+- And fix the link syntax.
+
+ +
+* Fri Jun 23 2006 Jesse Keating  0.6-4
+- And fix the link syntax.
+
+ +
+* Fri Jun 23 2006 Jesse Keating 
+- 0.6-4
+- And fix the link syntax.
+
+ + +{{Anchor|tags}} +== Tags == +*The ''Packager'' tag should not be used in spec files. The identities of the packagers are evident from the changelog entries. By not using the ''Packager'' tag, you also avoid seeing bad binaries rebuilt by someone else with your name in the header. See also the '''Maximum RPM definition of the Packager tag''' at [http://www.rpm.org/max-rpm/s1-rpm-inside-tags.html#S3-RPM-INSIDE-PACKAGER-TAG www.rpm.org] . If you need to include information about the packager in the rpms ''you'' built, use %packager in your ~/.rpmmacros instead. +*The ''Vendor'' tag should not be used. It is set automatically by the build system. +*The ''Copyright'' tag is deprecated. Use the ''License'' tag instead, as detailed in ["Packaging/LicensingGuidelines"] . Contact the upstream author if there is any doubt about what license the software is distributed under. +*The ''Summary'' tag value should not end in a period. If this bothers you from a grammatical point of view, sit down, take a deep breath, and get over it. +*Usually, the ''PreReq'' tag should be replaced by plain ''Requires''. For more info, see Maximum RPM snapshot's [http://www.rpm.org/max-rpm-snapshot/s1-rpm-depend-manual-dependencies.html#S3-RPM-DEPEND-FINE-GRAINED fine grained dependencies chapter] . +* The ''Source'' tag documents where to find the upstream sources for the rpm. In most cases this should be a complete URL to the upstream tarball. For special cases, please see the ["Packaging/SourceURL"] Guidelines + +{{Anchor|BuildRoot}} +== BuildRoot tag == + +The ''!BuildRoot'' value MUST be below %{_tmppath}/ and MUST contain at least %{name}, %{version} and %{release}. It may invoke mktemp since this is guaranteed to exist on every system. From there, packagers are expected to use a sane ''!BuildRoot''. + +The ''recommended'' values for the ''!BuildRoot'' tag are (in descending order of preference) : +
+%(mktemp -ud %{_tmppath}/%{name}-%{version}-%{release}-XXXXXX)
+%{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
+%{_tmppath}/%{name}-%{version}-%{release}-root
+
+ +At one point, the second was a mandatory value, but it is now left to the packager to decide. If unsure, simply pick the first. + +{{Anchor|PreppingBuildRootForInstall}} +=== Prepping BuildRoot For %install === +It is important to properly prepare the !BuildRoot in the %install section of your package before it is used. Every Fedora package MUST have an %install section that begins with either: + +
+%install
+rm -rf %{buildroot}
+
+ +or + +
+%install
+rm -rf $RPM_BUILD_ROOT
+
+ +This is to ensure that the !BuildRoot will be created fresh during the %install section. + +{{Anchor|Requires}} +== Requires == +RPM has very good capabilities of automatically finding dependencies for libraries and eg. Perl modules. In short, don't reinvent the wheel, but just let rpm do its job. There is usually no need to explicitly list eg. Requires: libX11 when the dependency has already been picked up by rpm in the form of depending on libraries in the libX11 package. + +Build requirements are different. There's no automatic dependency find procedure for them, which means that you must explicitly list stuff that the package requires to build successfully. Typically, some -devel packages are listed there. Refer to the [[BuildRequires| BuildRequires section]] . + +Sometimes we know that a package requires eg. gtk+-devel 1.2 or newer to build (and thus gtk+ 1.2 or newer to run, but that's handled automatically). There are two things to consider here: + +First, if the lowest possible requirement is so old that nobody has a version older than that installed on any target distribution release, there's no need to include the version in the dependency at all. In that case we know the available software is new enough. For example, the version in gtk+-devel 1.2 dependency above is unnecessary for all Red Hat Linux distributions since (at least) release 6.2. As a rule of thumb, if the version is not required, don't add it just for fun. + +Second, the Epoch must be listed when adding a versioned dependency to achieve robust epoch-version-release comparison. A quick way to check the Epoch of package foo is to run: + +rpm --query --qf "%{EPOCH}\n" packagename + +Typically, the requirements for -devel packages need yet another look. They're not usually picked up automatically by rpm. If the foo-devel package has a foo-config script, you can try doing a foo-config --libs and foo-config --cflags to get strong hints what packages should be marked as foo's requirements. For example: + +
+$ gtk-config --cflags
+-I/usr/include/gtk-1.2 -I/usr/include/glib-1.2 -I/usr/lib/glib/include -I/usr/X11R6/include
+$ gtk-config --libs
+-L/usr/lib -L/usr/X11R6/lib -lgtk -lgdk -rdynamic -lgmodule -lglib -ldl -lXi -lXext -lX11 -lm
+
+ +This means that gtk+-devel should contain + +Requires: glib-devel libXi-devel libXext-devel libX11-devel + +{{Anchor|PreReq}} +=== PreReq === + +Packages should not use the PreReq tag. Once upon a time, in dependency loops PreReq used to "win" over the conventional Requires when RPM determined the installation order in a transaction. This is no longer the case. + +{{Anchor|FileDeps}} +=== File Dependencies === + +Rpm gives you the ability to depend on files instead of packages. Whenever possible you should avoid file dependencies outside of /etc, /bin, /sbin, /usr/bin, or /usr/sbin. Using file dependencies outside of those directories requires yum (and other depsolvers using the repomd format) to download and parse a large xml file looking for the dependency. Helping the depsolvers avoid this processing by depending on the package instead of the file saves our end users a lot of time. There are times when other technical considerations outweigh these considerations. One specific example is packages installing into %{_libdir}/mozilla/plugins. In this case, mandating a specific browser in your package just to own this directory could drag in a large amount of needless packages. Requiring the directory to resolve the dependency is the better choice. + +{{Anchor|BuildRequires}} +== BuildRequires == + +In package development and testing, please verify that your package is not missing any necessary build dependencies. Having proper build requirements saves the time of all developers and testers as well as autobuild systems because they will not need to search for missing build requirements manually. It is also a safety feature that prevents builds with that would not otherwise fail, but would be missing crucial features. For example, a graphical application may exclude PNG support after its '''configure''' script detects that libpng is not installed. + +Before adding BuildRequires to any package, please be comfortable with [[Requires| Requires]] . + +There are two suggested ways of detecting missing BuildRequires. '''rpmdev-rmdevelrpms''' and '''mock'''. The first one is designed to remove all developer-related packages from your system. If the build fails or is missing certain features due to missing build dependencies, then the missing dependency needs to be found and added. Check the [[rmdevelrpms| rpmdev-rmdevelrpms]] section to find out more.
+'''mock''' is another good way to check build dependencies. Rather than remove all developer packages, it tries to build your package in a chroot. It makes no changes to your normal, daily environment and ensures that your package will build fine. However, '''mock''' may need a good internet connection to download all required packages. [[Extras/MockTricks| MockTricks]] page contains more information. Another mock-like tool, '''mach''' is also available in the Fedora repository. + +{{Anchor|rmdevelrpms}} +=== rpmdev-rmdevelrpms === + +'''rpmdev-rmdevelrpms''' script within the ["rpmdevtools"] toolkit is a script written by Ville Skyttä that helps RPM packagers in finding missing BuildRequires. Simply run it and allow it to remove all *-devel packages and build tools like this example. + +
+[root@build-fc1 /] # rpmdev-rmdevelrpms
+Found 52 devel packages:
+guile-devel-1.6.4-8.2
+bison-1.875-5
+m4-1.4.1-14
+flex-2.5.4a-30
+openssl-devel-0.9.7a-23
+automake-1.7.8-1
+fontconfig-devel-2.2.1-6.1
+XFree86-devel-4.3.0-42
+tcl-devel-8.3.5-93
+SDL_image-devel-1.2.3-3
+SDL_ttf-devel-2.0.6-0.fdr.3.1
+pth-devel-2.0.0-0.fdr.1.1
+libIDL-devel-0.8.2-1
+atk-devel-1.4.0-1
+gtk2-devel-2.2.4-5.1
+libmng-devel-1.0.4-4
+glib-devel-1.2.10-11
+gtk+-devel-1.2.10-28.1
+audiofile-devel-0.2.3-7
+compface-1.4-0.fdr.3.1
+esound-devel-0.2.31-1
+libungif-devel-4.1.0-16
+gnome-libs-devel-1.4.1.2.90-35
+openldap-devel-2.1.22-8
+aspell-devel-0.50.3-16
+gpgme03-devel-0.3.16-0.fdr.2.1
+freeglut-devel-1.3-1.20020125.3
+e2fsprogs-devel-1.34-1
+db4-devel-4.1.25-14
+krb5-devel-1.3.1-6
+autoconf-2.57-3
+libtool-1.5-8
+gdbm-devel-1.8.0-21
+freetype-devel-2.1.4-5
+pkgconfig-0.14.0-6
+ncurses-devel-5.3-9
+tk-devel-8.3.5-93
+SDL-devel-1.2.5-9
+SDL_mixer-devel-1.2.4-9
+zlib-devel-1.2.0.7-2
+libgpg-error-devel-0.6-0.fr.3.1
+glib2-devel-2.2.3-1.1
+pango-devel-1.2.5-1.1
+libjpeg-devel-6b-29
+libpng-devel-1.2.2-17
+ORBit-devel-0.5.17-10.3
+clamav-devel-0.65-0.fdr.4.1
+cyrus-sasl-devel-2.1.15-6
+libtiff-devel-3.5.7-14
+imlib-devel-1.9.13-14
+gdk-pixbuf-devel-0.22.0-3.0
+pilot-link-devel-0.11.8-1
+Remove them? [y/N]  y[
+]Removing.................................................................................................
+................................................................Done.
+
+Then attempt to build your RPM package. Use yum to reinstall any packages that are already in BuildRequires. If your build fails after this point, then you need to read through the build process and ascertain the missing BuildRequires from the error messages within. + +Be very careful to watch especially the '''configure''' part of the build process for missing optional libraries or tools that are desirable for the package. + +By default, the script may attempt to remove some packages that your system needs to operate correctly. Usually, this will fail due to an unsatisfied dependency (and this, BTW is why the script is using rpm -e instead of yum remove...) + +An example of this are the gettext and libgcj packages. gettext is usually a development-only package, but for example redhat-lsb depends on it. Also, it seems that RH9 Konqueror needs openssl-devel for SSL. If you wish to mark some packages so that they will be ignored by rpmdev-rmdevelrpms, do it in /etc/rpmdevtools/rmdevelrpms.conf or your personal /.rmdevelrpmsrc and pay special attention to the packages you treated this way when building. + +{{Anchor|Exceptions}} +=== Exceptions === + +There is no need to include the following packages or their dependencies as BuildRequires because they would occur too often. These packages are considered the minimum build environment. The derived list of all deps pulled in by this list is on ["Packaging/FullExceptionList"] . + +
+bash
+bzip2
+coreutils
+cpio
+diffutils
+fedora-release
+findutils
+gawk
+gcc
+gcc-c++
+grep
+gzip
+info
+make
+patch
+redhat-rpm-config
+rpm-build
+sed
+shadow-utils
+tar
+unzip
+util-linux-ng
+which
+
+ +{{Anchor|summary}} +== Summary and description == +The summary should be a short and concise description of the package. The description expands upon this. Do not include installation instructions in the description; it is not a manual. If the package requires some manual configuration or there are other important instructions to the user, refer the user to the documentation in the package. Add a ''README.Fedora'', or similar, if you feel this is necessary. Also, please make sure that there are no lines in the description longer than 80 characters. + +Please put personal preferences aside and use American English spelling in the summary and description. Anything else belongs in localized versions. + +{{Anchor|PackageEncoding}} +== Encoding == +Unless you need to use characters outside the [http://commons.wikimedia.org/wiki/Image:Ascii_full.png ASCII repertoire] , you will not need to be concerned about the encoding of the spec file. If you do need non-ASCII characters, save your spec files as UTF-8. If you're in doubt as to what characters are ASCII, please refer to [http://commons.wikimedia.org/wiki/Image:Ascii_full.png this chart] . + +{{Anchor|FilenameEncoding}} +=== Non-ASCII Filenames === +Similarly, filenames that contain non-ASCII characters must be encoded as UTF-8. Since there's no way to note which encoding the filename is in, using the same encoding for all filenames is the best way to ensure users can read the filenames properly. If upstream ships filenames that are not encoded in UTF-8 you can use a utility like convmv (from the convmv package) to convert the filename in your %install section. + +{{Anchor|PackageDocumentation}} +== Documentation == +Any relevant documentation included in the source distribution should be included in the package. Irrelevant documentation include build instructions, the omnipresent ''INSTALL'' file containing generic build instructions, for example, and documentation for non-Linux systems, e.g. ''README.MSDOS''. Pay also attention about which subpackage you include documentation in, for example API documentation belongs in the -devel subpackage, not the main one. Or if there's a lot of documentation, consider putting it into a subpackage. In this case, it is recommended to use *-doc as the subpackage name, and Documentation as the value of the Group tag. + +{{Anchor|CompilerFlags}} +== Compiler flags == +Compilers used to build packages should honor the applicable compiler flags set in the system rpm configuration. As of Aug 2006, this means in practice $RPM_OPT_FLAGS/%{optflags} for C, C++, and Fortran compilers. Honoring means that the contents of that variable is used as the basis of the flags actually used by the compiler during the package build. Adding to and overriding or filtering parts of these flags is permitted if there's a good reason to do so; the rationale for doing so should be reviewed and documented in the specfile especially in the override and filter cases. + +{{Anchor|Debuginfo}} +== Debuginfo packages == +Packages should produce useful -debuginfo packages, or explicitly disable them when it is not possible to generate a useful one but rpmbuild would do it anyway. Whenever a -debuginfo package is explicitly disabled, an explanation why it was done is required in the specfile. Debuginfo packages are discussed in more detail in a separate document, ["Packaging/Debuginfo"] . + +{{Anchor|StaticLibraries}} +== Exclusion of Static Libraries == +Packages including libraries should exclude static libs as far as possible (eg by configuring with ''--disable-static''). Static libraries should only be included in exceptional circumstances. Applications linking against libraries should as far as possible link against shared libraries not static versions. + +Libtool archives, ''foo.la'' files, should not be included. Packages using libtool will install these by default even if you configure with ''--disable-static'', so they may need to be removed before packaging. Due to bugs in older versions of libtool or bugs in programs that use it, there are times when it is not always possible to remove *.la files without modifying the program. In most cases it is fairly easy to work with upstream to fix these issues. Note that if you are updating a library in a stable release (not devel) and the package already contains *.la files, removing the *.la files should be treated as an API/ABI change -- ie: Removing them changes the interface that the library gives to the rest of the world and should not be undertaken lightly. + +{{Anchor|StaticInclusion}} +=== Packaging Static Libraries === +* In general, packagers are strongly encouraged not to ship static libs unless a compelling reason exists. + +* We want to be able to track which packages are using static libraries (so we can find which packages need to be rebuilt if a security flaw in a static library is fixed, for instance). There are two scenarios in which static libraries are packaged: +1. '''Static libraries and shared libraries.''' In this case, the static libraries must be placed in a ''*-static'' subpackage. Separating the static libraries from the other development files in ''*-devel'' allow us to track this usage by checking which packages Build''''''Require the ''*-static'' package. The intent is that whenever possible, packages will move away from using these static libraries, to the shared libraries. +2. '''Static libraries only.''' When a package only provides static libraries you can place all the static library files in the ''*-devel'' subpackage. When doing this you also must have a virtual Provide for the ''*-static'' package: +
+%package devel
+Provides: foo-static = %{version}-%{release}
+
+ +Packages which explicitly need to link against the static version must BuildRequire: foo-static, so that the usage can be tracked. + +* If (and only if) a package has shared libraries which require static libraries to be functional, the static libraries can be included in the ''*-devel'' subpackage. The devel subpackage must have a virtual Provide for the ''*-static'' package, and packages dependent on it must Build''''''Require the ''*-static'' package. + +{{Anchor|StaticLinkage}} +=== Staticly Linking Executables === +* Static linkage is a special exception and should be decided on a case-by-case basis. The packager must provide rationale for linking statically, including precedences where available, to FESCO for approval. +* If you link statically against a library, add yourself to the initialcc list for the library so you can watch for any security issues or bug fixes for which you'd want to rebuild your package against a new version of the library. Here are [[PackageMaintainers/CVSAdminProcedure| instructions]] for making that request. + +==== Programs which don't need to notify FESCo ==== +* Programs written in OCaml do not normally link dynamically to OCaml libraries. Because of that this requirement is waived. (OCaml code that calls out to libraries written in C should still link dynamically to the C libraries, however.) + +* If a library you depend on '''only''' provides a static version your package can link against it provided that you Build''''''Require the ''*-static'' subpackage. Packagers in such a situation should be aware that if a shared library becomes available, that you should adjust your package to use the shared library. + +{{Anchor|SystemLibraryDuplication}} +== Duplication of system libraries == + +For several reasons, a package should not include or build against a local copy of a library that exists on a system. The package should be patched to use the system libraries. + +This prevents old bugs and security holes from living on after the core system libraries have been fixed. + +{{Anchor|Rpath}} +== Beware of Rpath == +Sometimes, code will hardcode specific library paths when linking binaries (using the -rpath or -R flag). This is commonly referred to as an rpath, and in Fedora it is forbidden. Normally, the dynamic linker and loader (ld.so) resolve the executable's dependencies on shared libraries and load what is required. However, when -rpath or -R is used, the location information is then hardcoded into the binary and is examined by ld.so in the beginning of the execution. Since the Linux dynamic linker is usually smarter than a hardcoded path, we do not permit the use of rpath in Fedora. + +There is a tool called ''check-rpaths'' which is included in the ''rpmdevtools'' package. It is a good idea to add it to the ''%__arch_install_post'' macro in your ''~/.rpmmacros'' config file: +
+%__arch_install_post            \
+/usr/lib/rpm/check-rpaths     \
+/usr/lib/rpm/check-buildroot
+
+ +When ''check-rpaths'' is run, you might see output like this: +
+ERROR   0001: file '/usr/bin/xapian-tcpsrv' contains a standard rpath '/usr/lib64' in [/usr/lib64] 
+
+ +Often, rpath is used because a binary is looking for libraries in a non-standard location (standard locations are /lib, /usr/lib, /lib64, /usr/lib64). If you are storing a library in a non-standard location (e.g. /usr/lib/foo/), you should include a custom config file in /etc/ld.so.conf.d/. For example, if I was putting 32 bit libraries of libfoo in /usr/lib/foo, I would want to make a file called "foo32.conf" in /etc/ld.so.conf.d/, which contained the following: +
+/usr/lib/foo
+
+Make sure that you also make a 64bit version of this file (e.g. foo64.conf) as well (unless the package is disabled for 64bit architectures, of course). + +{{Anchor|RemovingRpath}} +=== Removing Rpath === + +There are several different ways to fix the rpath issue: + +* If the application uses configure, try passing the ''--disable-rpath'' flag to configure. +* If the application uses a local copy of libtool, add the following lines to the spec after %configure: +
+%configure
+sed -i 's|^hardcode_libdir_flag_spec=.*|hardcode_libdir_flag_spec=""|g' libtool
+sed -i 's|^runpath_var=LD_RUN_PATH|runpath_var=DIE_RPATH_DIE|g' libtool
+
+* Sometimes, the code/Makefiles can be patched to remove the ''-rpath'' or ''-R'' flag from being called. This is not always easy or sane to do, however. +* As a last resort, Fedora has a package called ''chrpath''. When this package is installed, you can run chrpath --delete on the files which contain rpaths. So, in our earlier example, we'd run: +
+chrpath --delete $RPM_BUILD_ROOT%{_bindir}/xapian-tcpsrv
+
+Make sure that you remember to add a '''BuildRequires: chrpath''' if you end up using this method. + +{{Anchor|Config}} +== Configuration files == + +Configuration files must be marked as such in packages. + +As a rule of thumb, use %config(noreplace) instead of plain %config unless your best, educated guess is that doing so will break things. In other words, think hard before overwriting local changes in configuration files on package upgrades. An example case when /not/ to use noreplace is when a package's configuration file changes so that the new package revision wouldn't work with the config file from the previous package revision. Whenever plain %config is used, add a brief comment to the specfile explaining why. + +Don't use %config or %config(noreplace) under /usr. /usr is deemed to not contain configuration files in Fedora. + +{{Anchor|Init}} +{{Anchor|Initscripts}} +== Initscripts == + +Currently, only SystemV-style initscripts are supported in Fedora. There are detailed guidelines for SysV-style initscripts here: ["Packaging/SysVInitScript"] + +{{Anchor|desktop}} +== Desktop files == + +If a package contains a GUI application, then it needs to also include a properly installed .desktop file. For the purposes of these guidelines, a GUI application is defined as any application which draws an X window and runs from within that window. Installed .desktop files MUST follow the [[http://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html desktop-entry-spec] , paying particular attention to validating correct usage of Name, GenericName, [[http://standards.freedesktop.org/menu-spec/latest/apa.html Categories] , +[[http://www.freedesktop.org/Standards/startup-notification-spec StartupNotify] +entries. + +=== Icon tag in Desktop Files === +The icon tag can be specified in two ways: + +* Full path to specific icon file: + Icon=/usr/share/pixmaps/comical.png + +* Short name without file extension: + Icon=comical + +The short name without file extension is preferred, because it allows for icon theming (it assumes .png by default, then tries .svg and finally .xpm), but either method is acceptable. + +=== .desktop file creation === +If the package doesn't already include and install its own .desktop file, you need to make your own, and include it as a Source: (e.g. Source3: %{name}.desktop). Here are the contents of a sample .desktop file (comical.desktop): + +
+[Desktop Entry] 
+Encoding=UTF-8
+Name=Comical
+GenericName=Comic Archive Reader
+Comment=Open .cbr & .cbz files
+Exec=comical
+Icon=comical
+Terminal=false
+Type=Application
+Categories=Graphics;
+
+ +=== desktop-file-install usage === +It is not simply enough to just include the .desktop file in the package, one MUST run desktop-file-install in %install (and have BuildRequires: desktop-file-utils), to help ensure .desktop file safety and spec-compliance. +Here are some examples of desktop-file-install usage: + +
+desktop-file-install --vendor=""               \
+--dir=${RPM_BUILD_ROOT}%{_datadir}/applications         \
+%{SOURCE3}
+
+ +
+desktop-file-install --vendor=""                \
+--add-category="Multimedia"                              \
+--delete-original                                        \
+--dir=%{buildroot}%{_datadir}/applications               \
+%{buildroot}/%{_datadir}/applnk/Multimedia/foo.desktop
+
+ +
+desktop-file-install --vendor=""                           \
+--remove-category="Science"                              \
+--dir=%{buildroot}%{_datadir}/applications/   \
+%{buildroot}/%{_datadir}/applications//foo.desktop
+
+ + +* If upstream uses , leave it intact, otherwise use fedora as . +* It is important that vendor_id stay constant for the life of a package. +This is mostly for the sake of menu-editing (which bases off of .desktop file/path names). + +{{Anchor|macros}} +== Macros == +Use macros instead of hard-coded directory names (see ["Packaging/RPMMacros"] ). + +Having macros in a Source: or Patch: line is a matter of style. Some people enjoy the ready readability of a source line without macros. Others prefer the ease of updating for new versions when macros are used. In all cases, remember to be consistent in your spec file and verify that the URLs you list are valid. spectool (from the rpmdevtools package) can aid you in checking that whether the URL contains macros or not. + +If you need to determine the actual string when it contains macros, you can use rpm. For example, to determine the actual Source: value, you can run: +
+rpm -q --specfile foo.spec --qf "$(grep -i ^Source foo.spec)\n"
+
+ +{{Anchor|UsingBuildRootOptFlags}} +=== Using %{buildroot} and %{optflags} vs $RPM_BUILD_ROOT and $RPM_OPT_FLAGS === +There are two styles of defining the rpm Build Root and Optimization Flags in a spec file. + +
+macro style   variable style
+Build Root  %{buildroot}  $RPM_BUILD_ROOT
+Opt. Flags  %{optflags}   $RPM_OPT_FLAGS
+
+
+ +There is very little value in choosing one style over the other, since they will resolve to the same values in all scenarios. You should pick a style and use it consistently throughout your packaging. + +Mixing the two styles, while valid, is bad from a QA and usability point of view, and should not be done in Fedora packages. + +{{Anchor|MakeInstall}} +=== Why the %makeinstall macro should not be used === +Fedora's RPM includes a %makeinstall macro but it must '''NOT''' be used when make install DESTDIR=%{buildroot} works. %makeinstall is a kludge that can work with Makefiles that don't make use of the DESTDIR variable but it has the following potential issues: +* %makeinstall overrides a set of Make variables during "make install" and prepends the %{buildroot} path. I.e. it performs make prefix="%{buildroot}%{_prefix}" libdir="%{buildroot}%{_libdir} ...". +* It is error-prone and can have unexpected effects when run against less than perfect Makefiles, e.g. the buildroot path may be included in installed files where variables are substituted at install-time. +* It can trigger unnecessary and wrong rebuilds when executing "make install", since the Make variables have different values compared with the %build section. +* If a package contains libtool archives, it can cause broken *.la files to be installed. + +Instead, Fedora packages should use: make DESTDIR=%{buildroot} install or make DESTDIR=$RPM_BUILD_ROOT install + +{{Anchor|locales}} +== Handling Locale Files == + +If the package includes translations, add +
+BuildRequires: gettext
+
+If you don't, your package could fail to generate translation files in the buildroot. + +Fedora includes an rpm macro called %find_lang. This macro will locate all of the locale files that belong to your package (by name), and put this list in a file. You can then use that file to include all of the locales. %find_lang should be run in the %install section of your spec file, after all of the files have been installed into the buildroot. The correct syntax for %find_lang is usually: +
+%find_lang %{name}
+
+In some cases, the application may use a different "name" for its locales. You may have to look at the locale files and see what they are named. If they are named myapp.mo, then you will need to pass myapp to %find_lang instead of %{name}. +After %find_lang is run, it will generate a file in the active directory (by default, the top level of the source dir). This file will be named based on what you passed as the option to the %find_lang macro. Usually, it will be named %{name}.lang. You should then use this file in the %files list to include the locales detected by %find_lang. To do this, you should include it with the -f parameter to %files. +
+%files -f %{name}.lang
+%defattr(-,root,root,-)
+%{_bindir}/foobar
+...
+
+If you are already using the -f parameter for the %files section where the locales should live, just append the contents of %{name}.lang to the end of the file that you are already using with -f. (Note that only one file may be used with %files -f.) + +Here is an example of proper usage of %find_lang, in foo.spec: + +
+...
+%prep
+%setup -q
+
+%build
+%configure --with-cheese
+
+%install
+make DESTDIR=$RPM_BUILD_ROOT install
+%find_lang %{name}
+
+%clean
+rm -rf $RPM_BUILD_ROOT
+
+%files -f %{name}.lang
+%defattr(-,root,root,-)
+%doc LICENSE README
+%{_bindir}/foobar
+
+%changelog
+* Thu May 4 2006 Tom "spot" Callaway  0.1-1
+- sample spec that uses %%find_lang
+
+
+ +{{Anchor|whyfindlang}} +=== Why do we need to use %find_lang? === + +Using %find_lang helps keep the spec file simple, and helps avoid several other packaging mistakes. + +* Packages that use %{_datadir}/* to grab all the locale files in one line also grab ownership of the locale directories, which is not permitted. +* Most packages that have locales have lots of locales. Using %find_lang is much easier in the spec file than having to do: +
+%{_datadir}/locale/ar/LC_MESSAGES/%{name}.mo
+%{_datadir}/locale/be/LC_MESSAGES/%{name}.mo
+%{_datadir}/locale/cs/LC_MESSAGES/%{name}.mo
+%{_datadir}/locale/de/LC_MESSAGES/%{name}.mo
+%{_datadir}/locale/es/LC_MESSAGES/%{name}.mo
+...
+
+* As new locale files appear in later package revisions, %find_lang will automatically include them when it is run, preventing you from having to update the spec any more than is necessary. + +Keep in mind that usage of %find_lang in packages containing locales is a MUST. + +{{Anchor|Timestamps}} +== Timestamps == +When adding file copying commands in the spec file, consider using a command that preserves the files' timestamps, eg. cp -p or install -p. + +When downloading sources, patches etc, consider using a client that preserves the upstream timestamps. For example wget -N or curl -R. To make the change global for wget, add this to your ~/.wgetrc: timestamping = on, and for curl, add to your ~/.curlrc: -R. + +{{Anchor|parallelmake}} +== Parallel make == +Whenever possible, invocations of make should be done as +
+make %{?_smp_mflags}
+
+This generally speeds up builds and especially on SMP machines. + +Do make sure, however, that the package builds cleanly this way as some make files do not support parallel building. Therefore you should consider adding +
+%_smp_mflags -j3
+
+to your ~/.rpmmacros file -- even on UP machines -- as this will expose most of these errors. + + +{{Anchor|reqprepost}} +== Scriptlets requirements == +Do not use the Requires(pre,post) style notation for scriptlet dependencies, because of two bugs in RPM. Instead, they should be split like this: +
+Requires(pre): ...
+Requires(post): ...
+
+For more information, see [http://www.redhat.com/archives/fedora-devel-list/2004-April/msg00674.html www.redhat.com] . + +{{Anchor|ScriptletConditionals}} +== Running scriptlets only in certain situations == +When the rpm command executes the scriptlets in a package it indicates if the action preformed is an install, erase, upgrade or reinstall by passing an integer argument to the script in question according to the following: +
+install   erase   upgrade  reinstall
+%pre         1        -         2         2
+%post        1        -         2         2
+%preun       -        0         1         -
+%postun      -        0         1         -
+
+This means that for example a package that installs an init script with the chkconfig command should uninstall it only on erase and not upgrade with the following snippet: +
+%preun
+if [ $1 -eq 0 ] ; then
+/sbin/chkconfig --del %{name}
+fi
+
+See also /usr/share/doc/rpm-*/triggers, which gives a more formal, generalized definition about the integer value(s) passed to various scripts. + +{{Anchor|SciptletsWriteDirs}} +== Scriplets are only allowed to write in certain directories == +Build scripts of packages (%prep, %build, %install, %check and %clean) may only alter files (create, modify, delete) under %{buildroot}, %{_builddir} and valid temporary locations like /tmp, /var/tmp (or $TMPDIR or %{_tmppath} as set by the rpmbuild process) according to the following matrix + +{| border="1" +|- +| || /tmp, /var/tmp, $TMPDIR, %{_tmppath} || %{_builddir} || %{buildroot} +|- +|%prep || yes || yes || no +|- +|%build || yes || yes || no +|- +|%install || yes || yes || yes +|- +|%check || yes || yes || no +|- +|%clean || yes || yes || yes +|} + +Further clarification: That should hold true irrespective of the builder's uid. + +{{Anchor|ConditionalDependencies}} +== Conditional dependencies == +If the spec file contains conditional dependencies selected based on presence of optional --with(out) foo arguments to rpmbuild, build the source RPM to be submitted with the default options, ie. so that none of these arguments are present in the rpmbuild command line. The reason is that those requirements get "serialized" into the resulting source RPM, ie. the conditionals no longer apply. + +{{Anchor|SeparateUserAccounts}} +== Build packages with separate user accounts == +When building software, which you have not conducted a full security-audit on, protect sensitive data, such as your GPG private key, in a separate user account. + +The same applies to reviewers/testers. Rebuild src.rpms in a separate account which does not have access to any sensitive data. + +{{Anchor|RelocatablePackages}} +== Relocatable packages == +The use of RPM's facility for generating relocatable packages is strongly discouraged. It is difficult to make work properly, impossible to use from the installer or from yum, and not generally necessary if other packaging guidelines are followed. However, in the unlikely event that you have a good reason to make a package relocatable, you MUST state this intent and reasoning in the request for package review. + + +{{Anchor|CodeVsContent}} +== Code Vs Content == +It is important to make distinction between computer executable code and content. +While code is permitted (assuming, of course, that it has an open source compatible license, is not legally questionable, etc.), only some kinds of content are permissable. + +The rule is this: + +If the content enhances the OS user experience, then the content is OK to be packaged in Fedora. This means, for example, that things like: fonts, themes, clipart, and wallpaper are OK. + +Content still has to be reviewed for inclusion. It must have an open source compatible license, must not be legally questionable. In addition, there are several additional restrictions for content: +* Content must not be pornographic, or contain nudity, whether animated, simulated, or photographed. There are better places on the Internet to get porn. +* Content should not be offensive, discriminatory, or derogatory. If you're not sure if a piece of content is one of these things, it probably is. +* All content is subject to review by FESCo, who has the final say on whether or not it can be included. + +Some examples of content which is permissable: + +* Package documentation or help files +* Clipart for use in office suites +* Background images (non-offensive, discriminatory, with permission to freely redistribute) +* Fonts (under an open source license, with no ownership/legal concerns) +* Game levels are not considered content, since games without levels would be non functional. +* Sound or graphics included with the source tarball that the program or theme uses (or the documentation uses) are acceptable. +* Game music or audio content is permissible, as long as the content is freely distributable without restriction, and the format is not patent encumbered. +* Example files included with the source tarball are not considered content. + +Some examples of content which are not permissable: + +* Comic book art files +* Religious texts +* mp3 files (patent encumbered) + +If you are unsure if something is considered approved content, ask on fedora-devel-list. + +{{Anchor|FileAndDirectoryOwnership}} +== File and Directory Ownership == + +Your package should own all of the files that are installed as part of the %install process. Packages must not own files already owned by other packages. The rule of thumb here is that the first package to be installed should own the files that other packages may rely upon. This means, for example, that no package in Fedora should ever share ownership with any of the files owned by the filesystem or man package. If you feel that you have a good reason to own a file or that another package owns, then please present that at package review time. + +Directory ownership is a little more complex than file ownership. Although the rule of thumb is the same: own all the directories you create but none of the directories of packages you depend on, there are several instances where it's desirable for multiple packages to own a directory. Examples of this are: + +1) The package you depend on to provide a directory may choose to own a different directory in a later version and your package will run unmodified with that later version. + +One common example of this is a Perl module. Assume ''perl-A-B'' depends on ''perl-A'' and installs files into /usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi/A/B. The base Perl package guarantees that it will own /usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi for as long as it remains compatible with version 5.8.8, but a future upgrade of the ''perl-A'' package may install into (and thus own) /usr/lib/perl5/vendor_perl/5.9.0/i386-linux-thread-multi/A. So the ''perl-A-B'' package needs to own /usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi/A as well as /usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi/A/B in order to maintain proper ownership. + +2) Multiple packages have files in a common directory but none of them requires others. + +An example: +
+Foo-Animal-Emu puts files into /usr/share/Foo/Animal/Emu
+Foo-Animal-Llama puts files into /usr/share/Foo/Animal/Llama
+
+Neither package depends on the other one. Neither package depends on any other package which owns the /usr/share/Foo/Animal/ directory. In this case, each package must own the /usr/share/Foo/Animal/ directory. + +In all cases we are guarding against unowned directories being present on a system. Unowned directories are affected by the umask of the user installing the package and thus can be a security risk or lead to packages which won't run. + +{{Anchor|UsersAndGroups}} +== Users and Groups == + +Some packages require or benefit from dedicated runtime user and/or group accounts. Guidelines for handling these cases are in a separate ["Packaging/UsersAndGroups"] document. + +{{Anchor|WebApplications}} +== Web Applications == + +Web applications packaged in Fedora should put their content into /usr/share/%{name} and NOT into /var/www/. This is done because: + +* /var is supposed to contain variable data files and logs. /usr/share is much more appropriate for this. +* Many users already have content in /var/www, and we do not want any Fedora package to step on top of that. +* /var/www is no longer specified by the Filesystem Hierarchy Standard + +{{Anchor|Conflicts}} +== Conflicts == + +Whenever possible, Fedora packages should avoid conflicting with each other. Unfortunately, this is not always possible. For full details on Fedora's Conflicts policy, see: ["Packaging/Conflicts"] . + +== No External Kernel Modules == +{{:Packaging/KernelModules}} + +{{Anchor|NoFilesOrDirectoriesUnderSrv}} +== No Files or Directories under /srv == + +The [http://www.pathname.com/fhs/pub/fhs-2.3.html#SRVDATAFORSERVICESPROVIDEDBYSYSTEM FHS says] : + +
+"...no program should rely on a specific subdirectory structure of /srv existing
+or data necessarily being stored in /srv. However /srv should always exist on FHS
+compliant systems and should be used as the default location for such data.
+
+Distributions must take care not to remove locally placed files in these
+directories without administrator permission."
+
+ +/srv is a poorly implemented section of the FHS, and its intended use case is unclear. At this time, no Fedora package can have any directories or files under /srv. + +It is important to note that a Fedora package, once installed, and run by a user, can use /srv as a default location for data. The package simply must not own any directories or files in /srv. + +=== Packages already in Fedora owning files or directories in /srv === +Any packages currently in Fedora that own files or directories in /srv must be fixed before Fedora 10. + +{{Anchor|ApplicationSpecificGuidelines}} +== Application Specific Guidelines == + +Some applications have specific guidelines written for them, located on their own pages in the Packaging/ hierarchy. + +{{Anchor|EclipseGuidelines}} +=== Eclipse === +Guidelines for Eclipse plugin packages: ["Packaging/EclipsePlugins"] + +{{Anchor|EmacsGuidelines}} +=== Emacs === +Guidelines for Emacs/X-Emacs packages: ["Packaging/Emacs"] + +{{Anchor|FontGuidelines}} +=== Fonts === +Guidelines for font packages: ["Packaging/FontsPolicy"] + +{{Anchor|JavaGuidelines}} +=== Java === +Guidelines for java packages: ["Packaging/Java"] + +{{Anchor|MonoGuidelines}} +=== Mono === +Guidelines for Mono packages: ["Packaging/Mono"] + +{{Anchor|OCamlGuidelines}} +=== OCaml === +Guidelines for OCaml packages: ["Packaging/OCaml"] + +{{Anchor|OpenOffice.orgGuidelines}} +=== OpenOffice.org === +Guidelines for OpenOffice.org extension packages: ["Packaging/OpenOffice.orgExtensions"] + +{{Anchor|PerlGuidelines}} +=== Perl === +Guidelines for Perl packages: ["Packaging/Perl"] + +{{Anchor|PHPGuidelines}} +=== PHP === +Guidelines for PHP packages: ["Packaging/PHP"] + +{{Anchor|PythonGuidelines}} +=== Python === +Guidelines for Python addon modules: ["Packaging/Python"] + +{{Anchor|RGuidelines}} +=== R === +Guidelines for R module packages: ["Packaging/R"] + +{{Anchor|RubyGuidelines}} +=== Ruby === +Guidelines for Ruby packages: ["Packaging/Ruby"] + +{{Anchor|SugarGuidelines}} +=== Sugar === +Guidelines for Sugar Activity packages: ["Packaging/SugarActivityGuidelines"] + +{{Anchor|TclGuidelines}} +=== Tcl/Tk === +Guidelines for Tcl/Tk extension packages: ["Packaging/Tcl"] From 7ed3b0ea0974747f107ccd649d8a7574219e3668 Mon Sep 17 00:00:00 2001 From: ImportUser Date: May 24 2008 14:13:02 +0000 Subject: [PATCH 44/3559] Imported from MoinMoin --- diff --git a/Packaging:FullExceptionList.mw b/Packaging:FullExceptionList.mw new file mode 100644 index 0000000..5d6f9f9 --- /dev/null +++ b/Packaging:FullExceptionList.mw @@ -0,0 +1,5 @@ + +This list is derived from [[Packaging/Guidelines#Exceptions]] by resolving all deps. These are the packages you can safely assume will be present in a BuildRoot without being pulled in by a package's BuildRequires. + +List has been removed as it is variable across the collections. If you need something that is '''A)''' not listed in the minimal list, and '''B)''' isn't brought in by something else you BuildRequire, you should list it as a BuildRequire just to be safe. From 235175fa97b0443e1f74e32d48acafa5da7f6a24 Mon Sep 17 00:00:00 2001 From: ImportUser Date: May 24 2008 14:13:02 +0000 Subject: [PATCH 46/3559] Imported from MoinMoin --- diff --git a/Packaging:SourceURL.mw b/Packaging:SourceURL.mw new file mode 100644 index 0000000..3410ee9 --- /dev/null +++ b/Packaging:SourceURL.mw @@ -0,0 +1,79 @@ +{{Anchor|ReferencingSource}} += Referencing Source = + + + +One of the design goals of rpm is to cleanly separate upstream source from vendor modifications. For the Fedora packager, this means that sources used to build a package should be the vanilla sources available from upstream. To help reviewers and QA scripts verify this, the packager needs to indicate where a reviewer can find the source that was used to make the rpm. + +The most common case is where upstream distributes source as a tar.gz, tar.bz2 or zip archive that we can download from an upstream website. In these cases you must use a full URL to the package in the SourceX: line. For example: + +
+Source0: http://downloads.sourceforge.net/%{name}/%{name}-%{version}.tar.gz
+
+Source0: http://ftp.gnome.org/pub/GNOME/sources/gnome-common/2.12/gnome-common-2.12.0.tar.bz2
+
+ +There are several cases where upstream is not providing the source to you in an upstream tarball. In these cases you must document how to generate the tarball used in the rpm either through a spec file comment or a script included as a separate SourceX:. + +Here are some specific examples: + +{{Anchor|RevisionControl}} +== Using Revision Control == + +In some cases you may want to pull sources from upstream's revision control system because there have been many changes since the last release and you think that a tarball that you generate from there will more accurately show how the package relates to upstream's development. Here's how you can use a comment to show where the source came from: + +
+Source0: foo-20070221.tar.gz
+
+ +When pulling from revision control, please remember to use a Name-version-release compatible with the [wiki:Self:Packaging/NamingGuidelines#PackageVersion Version] and +[wiki:Self:Packaging/NamingGuidelines#PackageRelease Release] Guidelines. In particular, check the section on [wiki:Self:Packaging/NamingGuidelines#SnapshotPackages Naming Snapshots] . + +{{Anchor|ProhibitedCode}} +== When Upstream uses Prohibited Code == + +Some upstream packages include patents or trademarks that we are not allowed to ship even as source code. In these cases you have to modify the source tarball to remove this code before you even upload it to the build system. Here's an example of using a script to document how you went from the upstream tarball to the one included in the package: + +From the spec: +
+Source0: libfoo-1.0-nopatents.tar.gz
+Source1: generate-tarball.sh
+
+ +generate-tarball.sh: +
+#!/bin/sh
+
+VERSION=$1
+
+tar -xzvf libfoo-$VERSION.tar.gz
+rm libfoo-$VERSION/src/patentedcodec.c
+sed -i -e 's/patentedcodec.c//' libfoo-$VERSION/src/Makefile
+
+tar -czvf libfoo-$VERSION-nopatents.tar.gz libfoo-$VERSION
+
+ +{{Anchor|WeAreUpstream}} +== We are Upstream == + +For some packages where we are the upstream authors, for instance, the system-config-* tools, the source rpm that we distribute is the canonical source of the files. There is no public revision control system or publically released tarball for these programs so there is no tarball to list. Add a comment like the following to the spec: + +
+Source0: system-config-foo-1.0.tar.gz
+
+ +{{Anchor|Sourceforge}} +== Sourceforge.net == + +For packages hosted on sourceforge, use +
+Source0: http://downloads.sourceforge.net/%{name}/%{name}-%{version}.tar.gz
+
+changing ".tar.gz" to whatever matches the upstream distribution. Note that we are using downloads.sourceforge.net instead of an arbitrarily chosen mirror. You may use the package name/package version instead of the %{name} and %{version} macros, of course. + +{{Anchor|VersionMacro}} +== Using %{version} == + +Using %{version} in the SourceX: makes it easier for you to bump the version of a package, because most of the time you do not need to edit SourceX: when editing the specfile for the new package. +---- +[[Category:Extras]] From 2f5e0304aaa7287fc8badcdb07e61893cbcc868d Mon Sep 17 00:00:00 2001 From: ImportUser Date: May 24 2008 14:13:02 +0000 Subject: [PATCH 48/3559] Imported from MoinMoin --- diff --git a/Packaging:Tcl.mw b/Packaging:Tcl.mw new file mode 100644 index 0000000..04793c9 --- /dev/null +++ b/Packaging:Tcl.mw @@ -0,0 +1,126 @@ + += Tcl packaging guidelines = + +These conventions apply to Tcl packages in Fedora 9 and later. There are some aspects of Tcl in Fedora 7 and Fedora 8 that will conflict with these guidelines. + +{{Anchor|NamingConventions}} +== Naming Conventions == + +The name for all Tcl/Tk extensions must be prefixed with tcl-. This rule applies even for Tcl/Tk packages that are already prefixed with tcl in the name (see examples below). An optional Provides: foo is recommended to allow selecting the package based on the upstream name, as long as the upstream name is not excessively generic and does not conflict with an existing package name. Tk extensions have the option of adding additional Provides: with the prefix tk-.
+Examples: + +
+Name: tcl-bwidget
+Provides: bwidget = %{version}-%{release}, tk-bwidget = %{version}-%{release}
+
+ +
+Name: tcl-tclxml
+Provides: tclxml = %{version}-%{release}
+
+ +
+Name: tcl-thread
+
+ +The exception to this naming rule are existing packages that provide both an extension and a shell, such as expect. However, note that providing a shell is strongly discouraged (see below). + +== Applications == + +Tcl and Tk applications '''must''' use a non-versioned interpreter name in shebang line. This is to prevent any unnecessary dependency on the version of the interpreter being used. Most dependencies are with specific Tcl extensions, not the command line applications. Nevertheless, if an application does require a specific version of Tcl, it should use the standard Tcl package system to express this, as well as an explicit Requires: tcl(abi) = 8.x in the spec file. + +Bad: +
+#!/usr/bin/tclsh8.5
+
+ +Good: +
+#!/usr/bin/tclsh
+package require -exact Tcl 8.5
+
+ +The same rules apply for Tk applications. The non-versioned wish interpreter name '''must''' be used. + +== Extensions == + +Tcl in Fedora 7 and earlier searches for extensions in all subdirectories of the following three directories: %{_libdir} , %{_datadir} , and %{_datadir}/tcl8.x. In Fedora 8 this package path is extended to include %{_libdir}/tcl8.x. While Tcl is able to load extensions extensions that have been installed into %{_libdir} and %{_datadir} , this is strongly discouraged. In Fedora 9, %{_libdir} and %{_datadir} have been removed from the search path to optimize package loading times. Instead, Tcl extension packages '''must''' be installed in %{_datadir}/tcl8.x if they are noarch packages containing only Tcl code, or %{_libdir}/tcl8.x if they are arch-specific extensions containing shared libraries. Note that most Tcl extensions are not configured do install in these directories out of the box, and may need to use additional configure switches, patches, or script code in %install to move the files to the correct location. + +Both arch-specific and noarch Tcl extensions '''must''' use +
+Requires: tcl(abi) = 8.5
+
+to indicate which Tcl version they were built against. This is necessary because the guidelines below require extensions to be installed into tcl-versioned directories, which are only used by a single verison of Tcl. This does impose an inconvenience that all arch-specific and noarch extensions will need to be rebuilt for a new minor version of Tcl, but since new Tcl minor versions only appear once every few years, this should not be such a problematic inconvenience. + +==== noarch packages ==== + +The following macros '''must''' be used at the top of the spec file to determine the correct installation paths: + +
+%{!?tcl_version: %define tcl_version %(echo 'puts $tcl_version' | tclsh)}
+%{!?tcl_sitelib: %define tcl_sitelib %{_datadir}/tcl%{tcl_version}}
+
+ +In order for the macros to work, the package must also BuildRequires: tcl either directly, or indirectly with BuildRequires: tcl-devel + +Merely adding the %{tcl_sitearch} and %{tcl_sitelib} is not enough to ensure that the packages get installed into the correct location. Most Tcl extensions will install into %{_libdir} by default. There are two ways to change this. For most noarch packages, you can use the --libdir and --datadir configure switches to change the installation directory: +
+%configure --libdir=%{tcl_sitelib} --datadir=%{tcl_sitelib}
+
+ +For noarch packages that aren't fixed by using --libdir, you can simply move the installation directory in the %install section of the spec file. +
+%install
+rm -rf $RPM_BUILD_ROOT
+make install DESTDIR=$RPM_BUILD_ROOT
+install -d $RPM_BUILD_ROOT%{tcl_sitelib}
+mv $RPM_BUILD_ROOT%{_datadir}/foobar%{version} $RPM_BUILD_ROOT%{tcl_sitelib}/foobar%{version}
+
+ +It may also be acceptible to patch upstream's configure script and Makefile to add additional flexibility for the install directory, but the packager is not required to do this. + +==== arch-specific packages ==== +The following macros '''must''' be used at the top of the spec file to determine the correct installation paths: + +
+%{!?tcl_version: %define tcl_version %(echo 'puts $tcl_version' | tclsh)}
+%{!?tcl_sitearch: %define tcl_sitearch %{_libdir}/tcl%{tcl_version}}
+
+ +In order for the macros to work, the package must also BuildRequires: tcl either directly, or indirectly with BuildRequires: tcl-devel + +While %{tcl_sitearch} is a symlink to %{tcl_sitelib} in Fedora 8 and earlier, in Fedora 9 it is an actual directory. + +The --libdir flag for the configure script can often be used to set the correct installation directory: + +
+%build
+%configure --libdir=%{tcl_sitearch}
+
+ +For most arch-specific packages, the --libdir flag for the configure script is also used to locate tclConfig.sh. Some of these arch-specific packages will break if --libdir is redirected to %{tcl_sitearch} . For packages that can't handle alternate values for --libdir, you can simply move the installation directory in the %install section of the spec file: + +
+%install
+rm -rf $RPM_BUILD_ROOT
+make install DESTDIR=$RPM_BUILD_ROOT
+install -d $RPM_BUILD_ROOT%{tcl_sitearch}
+mv $RPM_BUILD_ROOT%{_libdir}/foobar%{version} $RPM_BUILD_ROOT%{tcl_sitearch}/foobar%{version}
+
+ +arch-specific packages can be generally grouped into three categories: those that provide a shell, those that provide a fooConfig.sh file and a shared library for linking, and those that only provide a shared library for dlopen(). + +'''No shells:''' +Very few Tcl extension packages provide a shell. Providing a shell for an extension is frowned upon. The extension's shared library can be dynamically loaded into a Tcl interpreter through the standard package require ... mechanism without providing a shell that automatically loads the shared library. The exceptions to this rule are the shells that are commonly expected to be present on a system, including Tk (wish) and Expect (expect, expectk). + +'''-devel subpackage for fooConfig.sh:''' +Some arch-specific Tcl extensions provide a shared library and a corresponding fooConfig.sh file with instructions for linking against the library. The shared library for such packages '''must''' be installed into %{_libdir} so that it can be found at runtime by applications that link against it. Unfortunately, the pkgIndex.tcl file in the package directory often references the shared library with a relative path. There are two ways to fix this. First, the maintainer can choose to keep the installation directory as %{_libdir}, and make a symlink to %{tcl_sitearch}. Second, the maintainer can choose to patch the pkgIndex.tcl file to contain an appropriate path to the shared library. Either solution is acceptible. + +fooConfig.sh files must be placed in a -devel subpackage. This may require some sed magic to modify fooConfig.sh so that the paths to the libraries and headers are still correct. + +'''No dlopen()'d libraries in %{_libdir}:''' +If the extension does '''not''' provide a fooConfig.sh file, then the shared library '''must not''' be installed directly in %{_libdir} , but in the package-specific installation directory in %{tcl_sitearch} instead. This may require a patch to update the extension's pkgIndex.tcl file to look for the shared library in the correct location. + +'''Stubs are ok if put in -devel subpackage:''' +Some Tcl extensions provide a static 'stub' library. Stub libraries are a Tcl-ism to provide version-independent dynamic linking on a variety of platforms. These are not normal static libraries that provide the library's actual functionality, but instead provide a level of indirection pointing to the shared library. These stub libraries do not have the same static linking issues that are generally frowned upon in Fedora, and thus are acceptible. If a package provides such a stub library, it must be placed in a -devel subpackage. More information on stubs can be found on the Tcl wiki: http://wiki.tcl.tk/285 From c2e046988f2ddfa600dd4a2bf68300f55655b325 Mon Sep 17 00:00:00 2001 From: ImportUser Date: May 24 2008 14:13:02 +0000 Subject: [PATCH 50/3559] Imported from MoinMoin --- diff --git a/Packaging:Perl.mw b/Packaging:Perl.mw new file mode 100644 index 0000000..a1ed8b8 --- /dev/null +++ b/Packaging:Perl.mw @@ -0,0 +1,204 @@ += Perl Packaging = + +This document seeks to document the conventions and customs surrounding the proper packaging of perl modules in Fedora. It does not intend to cover all situations, but to codify those practices which have served the Fedora perl community well. + + + +{{Anchor|licensetag}} += License tag = + +Perl itself is dual licensed, under both the GPL and Artistic licenses. Many perl modules follow this practice; when they do, the license tag should be filled out as "GPL+ or Artistic", not the other way around. + +Note also that under the new [[Licensing| license tag guidelines]] , it's important to specify "GPL+" not just "GPL" for those packages "licensed under the same terms as perl itself." + +
+License:  GPL+ or Artistic
+
+ +{{Anchor|DirectoryOwnership}} += Directory Ownership = +As specified in the [[Guidelines#FileAndDirectoryOwnership| general Packaging Guidelines]] , perl packages are permitted to share ownership of directories. + +As an example, assume that perl-A-B depends on perl-A and installs files into /usr/lib/perl5/vendor_perl/5.10.0/i386-linux-thread-multi/A/B. The base Perl package guarantees that it will own /usr/lib/perl5/vendor_perl/5.10.0/i386-linux-thread-multi for as long as it remains compatible with version 5.10.0, but a future upgrade of the perl-A package may install into (and thus own) /usr/lib/perl5/vendor_perl/5.11.0/i386-linux-thread-multi/A. So the perl-A-B package needs to own /usr/lib/perl5/vendor_perl/5.10.0/i386-linux-thread-multi/A as well as /usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi/A/B in order to maintain proper ownership. + +{{Anchor|requiresandprovides}} += Perl Requires and Provides = + +Perl packages use the virtual perl(Foo) naming to indicate a given perl module. Packages should use this methodology, and not require the package name directly. E.g. a package requires the perl module Readonly, a package should not explicitly require the package perl-Readonly, but rather perl(Readonly), which the perl-Readonly package provides. + +{{Template:Warning}} NOTE: Explicitly requiring perl-devel, even when wrapped in a conditional construct, is strongly discouraged, and is generally considered a blocker at review and a packaging bug. Instead, see the next section on requiring core modules -- making sure that these core modules are BR'ed when used will pull in the correct development perl packages. + + +{{Anchor|corebrs}} +== Core modules as buildrequires == + +Historically, buildrequiring a core module (that is, one provided by the perl package itself) has been frowned upon. However, with the perl/perl-devel split, a number of core modules are now packages seperately from the perl package, and now need to be explicitly buildrequired: + +* perl(CPAN) +* perl(ExtUtils::Embed) +* perl(ExtUtils::MakeMaker) +* perl(Test::Harness) +* perl(Test::More) +* perl(Test::Simple) + +{{Anchor|module_compat}} +== Versioned MODULE_COMPAT_ Requires == +All perl modules must include the versioned MODULE_COMPAT Requires: + +
+Requires:  perl(:MODULE_COMPAT_%(eval "%{__perl} -V:version"; echo $version))
+
+ +This is to ensure that perl packages have a dependency on a perl which provides the appropriate versioned directory structure (otherwise, the modules won't be found). + +{{Anchor|libperl}} +=== Packages that link to libperl === +Some packages link to libperl.so, usually to provide embedded perl functionality. All of these packages must also use the versioned MODULE_COMPAT Requires. + +{{Anchor|depfiltering}} +== Filtering Requires: and Provides == + +RPM's dependency generator can often throw in additional dependencies and will often think packages provide functionality contrary to reality. To fix this, the dependency generator needs to be overriden so that the additional dependencies can be filtered out. There are two main ways to do this: + +=== In %prep (preferred) === + +Filtering can be done entirely in the SPEC file, in the %prep section: + +
+cat << \EOF > %{name}-prov
+#!/bin/sh
+%{__perl_provides} $* |\
+sed -e '/perl(unwanted_provide)/d'
+EOF
+
+%define __perl_provides %{_builddir}/%{name}-%{version}/%{name}-prov
+chmod +x %{__perl_provides}
+
+
+cat << \EOF > %{name}-req
+#!/bin/sh
+%{__perl_requires} $* |\
+sed -e '/perl(unwanted_require)/d'
+EOF
+
+%define __perl_requires %{_builddir}/%{name}-%{version}/%{name}-req
+chmod +x %{__perl_requires}
+
+ +=== External filtering === + +Or the script can be placed in an external file and referenced from the specfile. This is worse than the above because the full path of the to-be-overridden script needs to be hardcoded into the file, ignoring the system rpmbuild config. It is, however, the method used by a significant number of existing packages. + +
+Source98: filter-provides.sh
+Source99: filter-requires.sh
+
+%define __perl_provides %{SOURCE98}
+%define __perl_requires %{SOURCE99}
+
+where filter-provides.sh contains: +
+#!/bin/sh
+/usr/lib/rpm/perl.prov $* |
+sed -e '/perl(unwanted_provide)/d'
+
+and filter-requires.sh contains: +
+#!/bin/sh
+/usr/lib/rpm/perl.req $* |
+sed -e '/perl(unwanted_require)/d'
+
+ +{{Anchor|manualdeps}} +== Manual Requires and Provides == + +Under some circumstances, RPM's automatic dependency generator can miss dependencies that should be added. +This is usually as a result of using language constructs that the dependency script wasn't expecting. +An example of this is in the perl-Class-Accessor-Chained package, where the following can be found: +
+use base 'Class::Accessor::Fast';
+...
+use base 'Class::Accessor';
+A tell-tale sign of this particular construct is that the package contains a dependency on perl(base), but this is not the only situation in which dependencies can be missed. This package needed additional dependencies as follows: +
+Requires: perl(Class::Accessor), perl(Class::Accessor::Fast)
+In general, it's a good idea to look at the upstream package's documentation for details of other dependencies. + +Another similar example of missing requirements can be seen in perl-Spreadsheet-WriteExcel: +
+package Spreadsheet::WriteExcel::Utility;
+...
+use autouse 'Date::Calc'  => qw(Delta_DHMS Decode_Date_EU Decode_Date_US);
+use autouse 'Date::Manip' => qw(ParseDate Date_Init);
+
+ +Similarly, it possible to miss Provides:, as was the case in [http://bugzilla.redhat.com/167797 Bug #167797] , where the perl-DBD-Pg package failed to Provide: perl(DBD::Pg) due to the following construct in DBD::Pg version 1.43: +
+{ package DBD::Pg;
+The usual way of writing this, and what's expected by RPM, is: +
+{
+package DBD::Pg;
+So it's wise to examine the Provides: of your packages to check that they are sane and complete. +If something is missing, it can be fixed either by using manual Provides: entries, or by patching the source to use a format that RPM can parse correctly. + += URL tag = + +For CPAN-based packages the URL tag should use a non-versioned search.cpan.org URL. E.g., if one were packaging the module Net::XMPP, the URL would be: + +
+URL:            http://search.cpan.org/dist/Net-XMPP/
+
+ += Testing and Test Suites = + +Perl packages typically have a large, healthy test suite. It is policy to run as much of the test suite as possible, subject to the technical limitations of the buildsystem. This means, at the least: + +* All modules required for tests should be listed as a buildrequires +* Any "optional" tests should be enabled +* Any modules needed for the tests but not yet in Fedora that could be included in Fedora should also be submitted for review + +== When to *not* test == + +There are a couple caveats here: + +* Optional tests do not need to be enabled if they will cause circular build deps +* Tests which require network or display access should be disabled for the buildsystem, but with a method provided for local builds +* Tests which do not test package functionality should still be invoked, but their exclusion not be considered a blocker (e.g. Test::Pod::Coverage, Test::Kwalitee and the like) + +Additionally, for "meta" packages that provide a common interface to a number of similar modules, it is not necessary to package all of the modules that the package supports so long as at least one module exists to allow the meta package to provide functionality. For instance, the package perl-JSON-Any (JSON::Any) provides a common interface to JSON, JSON::XS, JSON::PC, JSON::Syck and JSON::DWIM; JSON::PC and JSON::DWIM are not currently in Fedora and do not need to be packaged. + +== Conditionally enabling/disabling tests == + +One common way to disable a test for mock but enable it locally is to use a _with_foo macro test. e.g.: + +
+%check
+%{?!_with_network_tests: rm t/roster.t }
+./Build test
+
+ +With this construct, an offending test will be removed and not executed, unless "--with network_tests" is passed to rpmbuild or %_with_network_tests is defined somewhere, e.g. in a user's $HOME/.rpmmacros. This approach preserves the test suite for local builds while working within the technical limitations of the buildsystem. + += Makefile.PL vs Build.PL = + +Perl modules typically utilize one of two different buildsystems: + +* ExtUtils::MakeMaker +* Module::Build + +The two different styles are easily recognizable: ExtUtils::MakeMaker employs the Makefile.PL build file, and is the "classical" approach; Module::Build is a newer approach, with support for things MakeMaker cannot do. While the ultimate choice of which system to employ is clearly in the hands of upstream, if Build.PL is present in a distribution the packager should employ that build framework unless there is a good reason otherwise. + +See also ["Perl/Build.PL VsMakefile.PL"] . + += .h files in module packages = + +It is not uncommon for binary module packages to include .h files, see e.g. perl-DBI, perl-Glib, perl-Gtk2. For a variety of reasons these should not be split off into a -devel package. + += Set inital-cc to 'perl-sig' = + +It's common practice to set the [https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list Fedora perl SIG mailing list] as a member of the initial-cc list for bugzilla. This can be done by adding the user perl-sig to the initial CC list. + += cpanspec = + +cpanspec is an excellent little tool to assist in creating Fedora-compliant packages from CPAN-based modules. Its use as a starting point is recommended (but certainly not mandated). From 91803f912a95170643235727f0e257a80b6af693 Mon Sep 17 00:00:00 2001 From: ImportUser Date: May 24 2008 14:13:02 +0000 Subject: [PATCH 52/3559] Imported from MoinMoin --- diff --git a/Packaging:KernelModules.mw b/Packaging:KernelModules.mw new file mode 100644 index 0000000..0fb2e21 --- /dev/null +++ b/Packaging:KernelModules.mw @@ -0,0 +1,5 @@ +At one point (pre Fedora 8), packages containing "addon" kernel modules were permitted. This is no longer the case. Fedora strongly encourages kernel module packagers to submit their code into the upstream kernel tree. + +Existing kernel module packages must be removed (or merged into the main kernel package) before Fedora 9. + +The reference documentation on how to package kernel modules in the "kmod" style has been preserved [[Obsolete/KernelModules| here]] . From dc845f7a45cadbfce0afecbd9ad5cde09b945266 Mon Sep 17 00:00:00 2001 From: ImportUser Date: May 24 2008 14:13:02 +0000 Subject: [PATCH 54/3559] Imported from MoinMoin --- diff --git a/Packaging:Scriptlets.mw b/Packaging:Scriptlets.mw new file mode 100644 index 0000000..e71fb4e --- /dev/null +++ b/Packaging:Scriptlets.mw @@ -0,0 +1,250 @@ + += RPM scriptlet recipes = +Rpm spec files have several sections which allow packages to run code on installation and removal. These scriptlets are mostly used to update the running system with information from the package. This page offers a quick overview of the RPM scriptlets and a number of common recipes for scriptlets in packages. For a more complete treatment of scriptlets, please see the [http://www.rpm.org/max-rpm-snapshot/ Maximum RPM book] . + +'''Contents:''' + + += Syntax = +The basic syntax is similar to the %build, %install, and other sections of the rpm spec file. The scripts support a special flag, -p which allows the scriptlet to invoke a single program directly rather than having to spawn a shell to invoke the programs. (ie: %post -p /sbin/ldconfig) + +The scriptlets also take an argument, passed into them by the controlling rpmbuild process. This argument, accessed via $1 is the number of packages of this name which will be left on the system when the action completes, except for %pretrans and %posttrans which are always run with $1 as 0 (%pretrans and %posttrans are available in rpm 4.4 and later). So for the common case of install, upgrade, and uninstall we have: + +{| border="1" +|- +| || install || upgrade || uninstall +|- +| %pretrans || $1 == 0 || $1 == 0 || (N/A) +|- +| %pre || $1 == 1 || $1 == 2 || (N/A) +|- +| %post || $1 == 1 || $1 == 2 || (N/A) +|- +| %preun || (N/A) || $1 == 1 || $1 == 0 +|- +| %postun || (N/A) || $1 == 1 || $1 == 0 +|- +| %posttrans || $1 == 0 || $1 == 0 || (N/A) +|} + +Note that these values will vary if there are multiple versions of the same package installed (This mostly occurs with parallel installable packages such as the kernel. However, it can also occur when errors prevent a package upgrade form completing.) So it is a good idea to use this construct: +
+%pre
+if [ $1 -gt 1 ] ; then
+fi
+
+...for %pre and %post scripts rather than checking that it equals 2. + +Except in some really exceptional cases (if any), we want all scriptlets to exit with the zero exit status. Because rpm in its default configuration does not at the moment execute shell scriptlets with the -e argument to the shell, excluding explicit exit calls (frowned upon with a non-zero argument!), the exit status of the last command in a scriptlet determines its exit status. Most commands in the snippets in this document have a "|| :" appended to them, which is a generic trick to force the zero exit status for those commands whether they worked or not. Usually the most important bit is to apply this to the last command executed in a scriptlet, or to add a separate command such as plain ":" or "exit 0" as the last one in a scriptlet. Note that depending on the case, other error checking/prevention measures may be more appropriate, as well as running some commands only if we saw a previous command in the scriptlet which is a must prerequisite to succeed. + +Non-zero exit codes from scriptlets break installs/upgrades/erases so that no further actions will be taken for that package in a transaction (see scriptlet ordering below), which may for example prevent an old version of a package from being erased on upgrades, leaving behind duplicate rpmdb entries and possibly stale, unowned files on the filesystem. There are some cases where letting the transaction to proceed when some things in scriptlets failed may result in partially broken setup. It is however often limited to that package only whereas letting a transaction to proceed with some packages dropped out on the fly is more likely to result in broader system wide problems. + +{{Anchor|order}} += Scriptlet Ordering = +The scriptlets in %pre and %post are respectively run before and after a package is installed. The scriptlets %preun and %postun are run before and after a package is uninstalled. The scriptlets %pretrans and %posttrans are run at start and end of a transaction. On upgrade, the scripts are run in the following order: + +1. %pretrans of new package +1. %pre of new package +1. (package install) +1. %post of new package +1. %preun of old package +1. (removal of old package) +1. %postun of old package +1. %posttrans of new package + += Snippets = + +{{Anchor|shlibs}} +== Shared libraries == +Installing shared libraries requires running /sbin/ldconfig to update the dynamic linker's cache files. These can be invoked like: +
+%post
+/sbin/ldconfig
+%postun
+/sbin/ldconfig
+
+It is also common to invoke these with the '-p' option as they are often the only program invoked in a scriptlet: +
+%post -p /sbin/ldconfig
+%postun -p /sbin/ldconfig
+
+If applicable, the latter way is recommended because doing so will automatically add appropriate dependencies on /sbin/ldconfig to the package (and FWIW, will prevent unnecessarily launching a shell process in the scriptlets). + +{{Anchor|users}} +== Users and groups == +These are discussed on a [[Packaging/UsersAndGroups| separate page]] + +{{Anchor|services}} +== Services == +=== Initscripts Conventions === + +Full guidelines for SysV-style initscripts can be found here: ["Packaging/SysVInitScript"]
+Scriptlet specifics can be found here: ["Packaging/SysVInitScript#InitscriptScriptlets"] + +{{Anchor|gconf}} +== GConf == +GConf is a configuration scheme currently used by the GNOME desktop. Programs which use it setup default values in a [NAME] .schemas file which is installed under %{_sysconfdir}/gconf/schemas/[NAME] .schemas. These defaults are then registered with the gconf daemon which monitors the configuration values and alerts applications when values the applications are interested in change. The schema files also provide documentation about what each value in the configuration system means (which gets displayed when you browse the database in the gconf-editor program). + +For packaging purposes, we have to disable schema installation during build, and also register the values in the [NAME] .schemas file with the gconf daemon on installation and unregister them on removal. Due to the ordering of the scriptlets, this is a four step process. + +Disabling the GConf installation during the package creation can be done like so: +
+%install
+rm -rf $RPM_BUILD_ROOT
+export GCONF_DISABLE_MAKEFILE_SCHEMA_INSTALL=1
+make install DESTDIR=$RPM_BUILD_ROOT
+...
+
+The GCONF_DISABLE_MAKEFILE_SCHEMA_INSTALL environment variable suppresses the installation of the schema during the building of the package. An alternative for some packages is to pass a configure flag: +
+%build
+%configure --disable-schemas
+...
+
+Unfortunately, this configure switch only works if the upstream packager has adapted their Makefile.am to handle it. If the Makefile.am is not configured, this switch won't do anything and you'll need to use the environment variable instead. + +Here's the second part: +
+Requires(pre): GConf2
+Requires(post): GConf2
+Requires(preun): GConf2
+...
+%pre
+if [ "$1" -gt 1 ] ; then
+export GCONF_CONFIG_SOURCE=gconftool-2 --get-default-source
+gconftool-2 --makefile-uninstall-rule \
+%{_sysconfdir}/gconf/schemas/[NAME] .schemas >/dev/null || :
+fi
+
+In this section we uninstall the old schemas when we upgrade. The way we do this is first to get information about where gconf stores its values via the gconftool-2 --get-default-source line. Then we uninstall the schema from that source. If the package could be upgrading a package which had another name for the schema at one time, then we uncomment the lines to uninstall those as well. + +The next section is for installing the new schema: +
+%post
+export GCONF_CONFIG_SOURCE=gconftool-2 --get-default-source
+gconftool-2 --makefile-install-rule \
+%{_sysconfdir}/gconf/schemas/[NAME] .schemas > /dev/null ||| :
+
+Here we do the same things as in the %pre section for upgrading except the gconftool-2 switch used is --makefile-install-rule to install the new schemas instead of the uninstall-rule to remove the old schemas. + +The last section deals with deleting the schemas on package removal: +
+%preun
+if [ "$1" -eq 0 ] ; then
+export GCONF_CONFIG_SOURCE=gconftool-2 --get-default-source
+gconftool-2 --makefile-uninstall-rule \
+%{_sysconfdir}/gconf/schemas/[NAME] .schemas > /dev/null || :
+fi
+
+This snippet is nearly the same as the one for upgrading. Why can't we just combine this portion with the %pre portion? The answer is that we want to delete any old versions of the schema during an upgrade. But this has to happen before we install the new version (in the %post script) otherwise we end up removing the schema that the upgrading package installs. However, if it really is a removal that will leave no other instances of this package on the system, we have to clean up the schema before deleting it. + +'''Note:''' RHEL4 and FC <= 4 suffer from GConf [https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173869 Bug #173869] . If you are building for EPEL-4, you need to add killall -HUP gconfd-2 > /dev/null || : after the gconftool-2 calls in all the scriptlets. + +{{Anchor|info}} +== Texinfo == +The GNU project and many other programs use the texinfo file format for much of its documentation. These info files are usually located in /usr/share/info/. +When installing or removing a package, install-info from the info package takes care of adding the newly installed files to the main info index and removing them again on deinstallation. + +
+Requires(post): info
+Requires(preun): info
+...
+%post
+/sbin/install-info %{_infodir}/%{name}.info %{_infodir}/dir || :
+
+%preun
+if [ $1 = 0 ] ; then
+/sbin/install-info --delete %{_infodir}/%{name}.info %{_infodir}/dir || :
+fi
+
+ +These two scriptlets tell install-info to add entries for the info pages to the main index file on installation and remove them at erase time. The "|| :" in this case prevents failures that would typically affect systems that have been configured not to install any %doc files, or have read-only mounted, %_netsharedpath /usr/share. + +{{Anchor|scrollkeeper}} +== Scrollkeeper == +Gnome and KDE use the scrollkeeper cataloging system to keep track of documentation installed on the system. Scrollkeeper allows the help system to sort and search documentation metadata stored in .omf files. When you add documentation in these systems you need to make scrollkeeper aware that the documentation has been changed. + +Note that we ''''''BuildRequires scrollkeeper as most Makefile's are setup to install the necessary scrollkeeper files only if scrollkeeper is present at install time. +
+BuildRequires:  scrollkeeper
+Requires(post): scrollkeeper
+Requires(postun): scrollkeeper
+...
+%post
+scrollkeeper-update -q -o %{_datadir}/omf/%{name} || :
+
+%postun
+scrollkeeper-update -q || :
+
+These two scriptlets tell scrollkeeper to update its indexes to account for the new scrollkeeper files. + + +{{Anchor|desktopdb}} +== desktop-database == +Use this when a desktop entry has a ''''''MimeType key. +
+%post
+update-desktop-database &> /dev/null || :
+
+%postun
+update-desktop-database &> /dev/null || :
+
+Note: For FC5+, this scriptlet follows the same convention as mimeinfo files and gtk-icon-cache. Namely, the spec file should not Require desktop-file-utils for this. For older releases, one should +
+Requires(post): desktop-file-utils
+Requires(postun): desktop-file-utils
+
+(See http://bugzilla.redhat.com/180898 and http://bugzilla.redhat.com/180899) + +{{Anchor|mimeinfo}} +== mimeinfo == +Use this when a package drops an XML file in %{_datadir}/mime/packages. +
+%post
+update-mime-database %{_datadir}/mime &> /dev/null || :
+
+%postun
+update-mime-database %{_datadir}/mime &> /dev/null || :
+
+Note that similarly to the gtk-update-icon-cache code, these scriptlets should be run only if the user has update-mime-info installed and without a specific Requires: shared-mime-info. If shared-mime-info is not installed, update-mime-database won't be run when this package is installed. This does not matter because it will be run when the shared-mime-info package is installed. + +{{Anchor|iconcache}} +== GTK+ icon cache == + +If an application installs icons into one of the subdirectories in %{_datadir}/icons/ (such as hicolor in the following examples), gtk-update-icon-cache should be run after the package is installed/uninstalled on FC4 and later. This is required so that the installed icons show up in GNOME menus right after package installation, and speeds up GTK+ applications' access to the icons. For KDE, just 'touch'ing the top-level icon directory is enough. + +Note that no dependencies should be added for this. If gtk-update-icon-cache is not available, there's nothing that would be needing the cache update. Not adding the dependency on gtk-update-icon-cache (ie. gtk2 >= 2.6.0) makes it easier to use the package (or the same specfile) on systems where it's not available nor needed, such as older distro versions or (very) trimmed down installations. + +
+%post
+touch --no-create %{_datadir}/icons/hicolor
+if [ -x %{_bindir}/gtk-update-icon-cache ] ; then
+%{_bindir}/gtk-update-icon-cache --quiet %{_datadir}/icons/hicolor || :
+fi
+
+%postun
+touch --no-create %{_datadir}/icons/hicolor
+if [ -x %{_bindir}/gtk-update-icon-cache ] ; then
+%{_bindir}/gtk-update-icon-cache --quiet %{_datadir}/icons/hicolor || :
+fi
+
+ +{{Anchor|fonts}} +== Fonts == +Use this when your package installs new fonts. +
+%post
+if [ -x %{_bindir}/fc-cache ] ; then
+%{_bindir}/fc-cache %{_datadir}/fonts || :
+fi
+%postun
+if [ "$1" = "0" ] ; then
+if [ -x %{_bindir}/fc-cache ] ; then
+%{_bindir}/fc-cache %{_datadir}/fonts || :
+fi
+fi
+
+ +---- +[[Category:Extras]] From 1e1367c4f82a0c12ed78e83401934fafda7ed78e Mon Sep 17 00:00:00 2001 From: ImportUser Date: May 24 2008 14:13:02 +0000 Subject: [PATCH 56/3559] Imported from MoinMoin --- diff --git a/Packaging:GCJGuidelines.mw b/Packaging:GCJGuidelines.mw new file mode 100644 index 0000000..5602298 --- /dev/null +++ b/Packaging:GCJGuidelines.mw @@ -0,0 +1,56 @@ + += GCJ Guidelines = + +GCJ AOT bits '''SHOULD''' be built and included in packages. If GCJ-specific issues prevent you from building the package, it is permissible to simply omit GCJ support and build using OpenJDK. However, please file a bug against the gcc component in Red Hat bugzilla. Compilation into native code must be optional and enabled by default, if present. + +In some rare cases Java packages might not contain any executable code whatsoever so AOT-compiling for gcj would not be required. An example of such a package would be one that contained only annotation definitions. + +{| border="1" +|- +| {{Template:Warning}} Note: For Fedora versions < 8, no JDK was available other than GCJ so java packages with executable code '''MUST''' have the GCJ AOT bits. +|} + +== How to add GCJ AOT bits to a Java package == +Like other Java runtimes, libgcj can load classes from bytecode class files. Unlike other Java runtimes, libgcj can also load classes that have been compiled to native machine code using GCJ. + +* For packages in which all JAR files are in the main package: + +1. Add the following definition: 
+%define with_gcj %{!?_without_gcj:1}%{?_without_gcj:0}
+
+1. Conditionalize dependencies and be architecture dependent 
+%if %{with_gcj}
+BuildRequires:    java-gcj-compat-devel >= 1.0.31
+Requires(post):   java-gcj-compat >= 1.0.31
+Requires(postun): java-gcj-compat >= 1.0.31
+%else
+BuildArch:      noarch
+%endif
+
+1. Add the following to the end of %install section:
+%if %{with_gcj}
+%{_bindir}/aot-compile-rpm
+%endif
+
+1. Add the following to the package's %post and %postun sections, creating the sections if necessary:
+%if %{with_gcj}
+if [ -x %{_bindir}/rebuild-gcj-db ] 
+then
+%{_bindir}/rebuild-gcj-db
+fi
+%endif
+
+1. Add the following to the %files section:
+%if %{with_gcj}
+%attr(-,root,root) %{_libdir}/gcj/%{name}
+%endif
+
+ +* For packages in which all JAR files are in one subpackage, the Requires(), %post, %postun and %files lines should refer to that subpackage. + +* For packages in which more than one subpackage (including the main package) contains JAR files, then each subpackage should have its own Requires(), %post and %postun lines, and the %files lists should be split such that the subpackage that contains /path/to/foo-x.y.z.jar should have the following %files line:
+%if %{with_gcj}
+%attr(-,root,root) %{_libdir}/gcj/%{name}/foo-x.y.z.jar.*
+%endif
+
Note that the path has been stripped and .* has been appended. From f7cd11a68fa1cb35422e94bab72a3417b2c379fe Mon Sep 17 00:00:00 2001 From: ImportUser Date: May 24 2008 14:13:02 +0000 Subject: [PATCH 58/3559] Imported from MoinMoin --- diff --git a/Packaging:Conflicts.mw b/Packaging:Conflicts.mw new file mode 100644 index 0000000..752169e --- /dev/null +++ b/Packaging:Conflicts.mw @@ -0,0 +1,76 @@ + += Conflicts Guidelines = + +'''Author:''' [[TomCallaway| Tom 'spot' Callaway]]
+'''Revision:''' 0.06
+'''Initial Draft:''' Tuesday Dec 5, 2006
+'''Last Revised:''' Tuesday Apr 10, 2007
+ + + +{{Anchor|Conflicts}} +== Conflicts == +Whenever possible, Fedora packages should avoid conflicting with each other. Unfortunately, this is not always possible. These guidelines illustrate how conflicts should be handled in Fedora, specifically concerning when and when not to use the Conflicts: field. + +{{Anchor|AcceptableUsesOfConflicts}} +== Acceptable Uses of Conflicts: == +As a general rule, Fedora packages must NOT contain any usage of the Conflicts: field. This field is commonly misused, when a Requires: would usually be more appropriate. It confuses depsolvers and end-users for no good reason. However, there are some cases in which using the Conflicts: field is appropriate and acceptable. + +{{Anchor|ImplicitConflicts}} +=== Implicit Conflicts === +Keep in mind that implicit conflicts are NEVER acceptable. If your package conflicts with another package, then you must either resolve the conflict, or mark it with Conflicts:. + +{{Anchor|OptionalFunctionality}} +=== Optional Functionality === +Some software can utilize other optional software applications if present, but do not require them to be installed. If they are not installed, the software will still function properly. However, if those other "optional applications" are too old, then the software won't work. This is an acceptable use of the Conflicts: field. The packager must document the reason in a comment above the Conflicts: field: + +'''Example:''' +
+Conflicts: unrar < 2.0
+
+ +If the software links to the libraries of another package, it must use Requires: instead of Conflicts: to mark that dependency. Also, if the software does not function properly without another package being installed, it must use Requires: instead of Conflicts:. + +The packager should ask: + +''If the package (at the correct version) in Conflicts: is not present, will my package be functional?'' + +If the answer is yes, then it is probably a valid use of Conflicts:. If the answer is no, then it is almost certainly a better case for Requires:. + +For example, if foo-game needs libbar to run, but will not work with libbar that is older than 1.2.3: + +'''WRONG:''' Conflicts: libbar < 1.2.3
+'''RIGHT:''' Requires: libbar >= 1.2.3
+ +Packagers should keep usage of Conflicts: to a bare minimum. Only upgrading from two previous release of Fedora is supported, so Conflicts against older packages than that, while technically correct, are unnecessary, and should not be included. + +{{Anchor|CompatPackageConflicts}} +=== Compat Package Conflicts === +It is acceptable to use Conflicts: in some cases involving compat packages. These are the cases where it is not feasible to patch applications to look in alternate locations for the -compat files, so the foo-devel and foo-compat-devel packages need to Conflict:. Whenever possible, this should be avoided. + +{{Anchor|ConflictingFiles}} +== Conflicting Files == +There are many types of files which can conflict between multiple packages. Fedora strongly discourages using Conflicts: to resolve these cases. Here are some suggestions which can be used to resolve these conflicts (note that not all file conflict cases are listed, nor are all possible solutions): + +{{Anchor|ManPageNameConflicts}} +=== Man Page Name Conflicts === +* Rename the man pages to slightly alter the suffix of the man page (e.g man1/check.1.gz and man1/check.1foo.gz) +* Rename the man pages to include a prefix of the providing package (e.g. foo-check.1.gz and bar-check.1.gz) + +{{Anchor|LibraryNameConflicts}} +=== Library Name Conflicts === +* Put the library in a subdirectory of /usr/lib or /lib and include a ld.so.conf file in /etc/ld.so.conf.d/. + +{{Anchor|HeaderNameConflicts}} +=== Header Name Conflicts === +* Put the headers in a subdirectory of /usr/include. + +{{Anchor|BinaryNameConflicts}} +=== Binary Name Conflicts === +* Convince upstream to rename the binaries to something less generic (or just less conflicting). +* In the case where the conflicting binaries provide the same functionality, you can then rename the binaries with a prefix, and use "alternatives" to let the end user to select which generic name is the default. Note that this is usually not the case. + +{{Anchor|OtherUsesOfConflicts}} +== Other Uses of Conflicts: == +If you find yourself in a situation where you feel that your package has to conflict with another package (either explicitly or implicitly), but does not fit the documented accepted cases above, then you need to make your case to the [wiki:Self:Packaging/Committee Fedora Packaging Committee] . If they agree, then, and only then can you use Conflicts: in a Fedora package. Remember, whenever you use Conflicts:, you are also required to include the reasoning in a comment next to the Conflicts: entry, so that it will be abundantly clear why it needed to exist. From 01fc5b4992acc2570d7eaf905186d32ab1078c85 Mon Sep 17 00:00:00 2001 From: ImportUser Date: May 24 2008 14:13:02 +0000 Subject: [PATCH 60/3559] Imported from MoinMoin --- diff --git a/Packaging:GuidelinesTodo.mw b/Packaging:GuidelinesTodo.mw new file mode 100644 index 0000000..8d6e576 --- /dev/null +++ b/Packaging:GuidelinesTodo.mw @@ -0,0 +1,214 @@ + + +== Action Items == +Status should be one of: +* ratify -- Change needs be presented to FESCo for objections. +* followup -- There are questions or concerns that need to be addressed. +* writeup -- Change needs to be written into the official guidelines. + +{| border="1" +|- style="color: white; background-color: #3074c2; font-weight: bold" +|Status||Task Name||Owner||Meeting Date||Notes +|- +|writeup||!PatchUpstreamStatus||walters||2008-05-06||["PackagingDrafts/PatchUpstreamStatus"] +|- +|writeup||!DesktopVerify||caillon||2008-05-06||["PackagingDrafts/DesktopVerify"] +|- +|ratify||Withdraw the JPackage Naming Exception||spot||2008-05-20||["Packaging/JPackagePolicy"] +|} + +{{:PackagingDrafts/DraftsTodo}} + +== Resolved items == +{| border="1" +|- style="color: white; background-color: #3074c2; font-weight: bold" +|Task Name||Owner||Resolution Date||Notes +|- +|Sugar Activities ||DennisGilmore||2008-04-22||["Packaging/SugarActivityGuidelines"] +|- +|Update Static Lib Policies ||TomCallaway||2008-04-22||["PackagingDrafts/StaticLibraryPolicy"] +|- +|No packages may own files or dirs in /srv||spot||2008-04-08||["PackagingDrafts/NoBitsInSrv"] +|- +|Build GCJ AOT bits conditionally||LubomirKundrak||2008-04-08||["PackagingDrafts/ConditionalGCJ"] +|- +|SysV-style initscript guidelines ||spot || 2008-04-01 || ["Packaging/SysVInitScript"] +|- +|Java package guidelines ||AndrewOverholt || 2008-04-01 || ["Packaging/Java"] +|- +|Eclipse plugin guidelines ||spot || 2008-04-01 || ["Packaging/EclipsePlugins"] +|- +|GCJGuidelines||spot||2008-04-01||["Packaging/GCJGuidelines"] +|- +|Tcl packaging guidelines ||MichaelThomas ||2008-03-11|| ["Packaging/Tcl"] +|- +|Updated OCaml packaging guidelines ||RichardJones || 2008-03-11 || ["PackagingDrafts/OCaml"] +|- +|ASCII Naming Guidelines ||spot || 2008-03-25 || ["PackagingDrafts/ASCIINaming"] +|- +|Perl Guidelines ||spot || 2008-03-25 || ["PackagingDrafts/Perl"] +|- +|Self:OpenOffice.org extensions guidelines ||CaolanMcNamara ||2008-03-25 || ["Packaging/OpenOffice.orgExtensions"] +|- +|[[SIGs/Fonts| Fonts SIG]] packaging policies || NicolasMailhot || 2007-11-20 || [[Packaging/FontsPolicy| general fonts packaging policy]] +|- +|[[SIGs/Fonts| Fonts SIG]] packaging policies || NicolasMailhot || 2007-11-20 || [[Packaging/FontsSpecTemplate| fonts spec template]] (only general case for now can be extended later) +|- +|Python Eggs||ToshioKuratomi||2007-09-18||Python modules need to be able to provide multiple versions. Eggs allow this. Work out how to modify the guidelines for eggs. ["PackagingDrafts/PythonEggs"] +|- +|R packaging Guidelines||spot||2007-09-11||["PackagingDrafts/R"] +|- +|Emacsen Packaging Guidelines and templates || spot || 2007-09-11 ||PackagingDrafts/EmacsenAddOns +|- +|PHP Guidelines||spot||2007-09-11||PEAR Packages, PECL Packages, Macros and Scriplets: ["PackagingDrafts/PHP"] +|- +|Handling dynamic UID/GID in packages||VilleSkyttä||2007-08-13||["PackagingDrafts/UsersAndGroups"] +|- +|License Tag Guidelines||spot||2007-07-31||["PackagingDrafts/LicenseTag"] +|- +|writeup||Relax Package Naming for Dual Versions||ToshioKuratomi||2007-07-10||With multiple versions of a library it does not matter which of them is versioned and which versionless +|- +|Directory Ownership Improvement||[wiki:Self:TomCallaway spot] ||2007-06-26||[[PackagingDrafts/DirectoryOwnershipImprovement]] +|- +|Static Library Update||ToshioKuratomi||2007-06-19||[[PackagingDrafts/StaticLibraryChanges| ]] +|- +|Scriptlet snippets fixes||VilleSkyttä||2007-06-19||Scriptlet snippets fail safety fixes/clarifications +|- +|OCaml||ToshioKuratomi||2007-06-12||Guidelines for libraries and programs written in [http://fedoraproject.org/wiki/PackagingDrafts/OCaml OCaml] +|- +|cmake||RexDieter||2007-03-20|| [[PackagingDrafts/cmake]] +|- +|Ruby gems||[wiki:Self:DavidLutterkort lutter] ||2007-05-01||[[PackagingDrafts/RubyGems| Packaging of Ruby GEMS]] +|- +|Static Libraries||ToshioKuratomi||2007-05-22||http://fedoraproject.org/wiki/PackagingDrafts/StaticLibraryChanges +|- +|Extra DistTag Conditional Macros||[wiki:Self:TomCallaway spot] ||2007-05-21||[[PackagingDrafts/ExtraDistTagConditionalMacros]] +|- +|PHP: Versioned BuildRequires in Macros Section||[wiki:Self:TomCallaway spot] ||2007-05-21||[[PackagingDrafts/PHP]] +|- +|PHP: PECL Extensions||[wiki:Self:TomCallaway spot] ||2007-05-21||[[PackagingDrafts/PHP]] +|- +|Conflicts||[wiki:Self:TomCallaway spot] ||2007-05-07||[[PackagingDrafts/Conflicts]] +|- +|extras-list references||tibbs||2007-04-13||[[PackagingDrafts/FixMailingListRefs]] +|- +|Responsibilities||ToshioKuratomi||2007-04-10||http://fedoraproject.org/wiki/PackagingDrafts/OverallReviewGoals +|- +|UTF8 Filenames||ToshioKuratomi||2007-03-27||[[PackagingDrafts/Utf8Filenames]] +|- +|Post Release Packages||[wiki:Self:TomCallaway spot] ||2007-03-27||[[PackagingDrafts/PostRelease]] +|- +|Firmware Guidelines||[wiki:Self:TomCallaway spot] ||2007-03-06||https://www.redhat.com/archives/fedora-packaging/2007-February/msg00292.html +|- +|PackagingDrafts/BuildRootHandling||[wiki:Self:TomCallaway spot] ||2007-03-13||Require that BuildRoot be deleted immediately at the beginning of %install +|- +|Static linkage||RalfCorsepius||2006-10-31||Static linkage should be "strongly discouraged" [http://fedoraproject.org/wiki/PackagingDrafts/StaticLinkage] +|- +|PackagingDrafts/SciptletsWriteDirs||AxelThimm||2007-03-13||Only allow writing in %buildroot during %install +|- +|Init scripts||JesseKeating||2007-02-27||[[PackagingDrafts/InitScripts]] +|- +|Disallow %config files in /usr||AxelThimm||2007-03-06||[[PackagingDrafts/UsrConfigs]] +|- +|Buildroot||AxelThimm||2007-02-27||[[PackagingDrafts/BuildRoot]] +|- +|package builds allowed to write in certain filesystem areas||AxelThimm||2006-10-12||Build scripts of packages (%prep, %build, %install and %check) may only alter files (create, modify, delete) under %{buildroot}, %{_builddir} and valid temporary locations like /tmp, /var/tmp (or $TMPDIR or %{_tmppath} as set by the rpmbuild process). Further clarification: That should hold true irrespective of the builder's uid +|- +|Source URL Requirement||abadger1999||2007-02-20||http://www.fedoraproject.org/wiki/PackagingDrafts/SourceUrl +|- +|File dependencies||ToshioKuratomi||2007-02-20||Limit file deps to certain directories.
http://www.fedoraproject.org/wiki/PackagingDrafts/FileDeps +|- +|spec file naming clarification||abadger1999||2007-02-13||[[PackagingDrafts/SpecFileNaming]] +|- +|jpackage naming||[wiki:Self:TomCallaway spot] ||2007-02-13||[[Packaging/JPackagePolicy]] +|- +|.desktop files||RexDieter||2007-01-30||[[PackagingDrafts/DesktopFiles]] +|- +|non-pear PHP extension paths||[wiki:Self:TomCallaway spot] ||2007-01-30||Non-pear PHP extensions should put their Class files in /usr/share/php +|- +|MakeInstall Clarification||[wiki:Self:TomCallaway spot] ||2007-01-30||Clarify %makeinstall section, on why it should not be used [wiki:Self:PackagingDrafts/MakeInstall PackagingDrafts/MakeInstall] +|- +|BuildRoot is mandatory||[wiki:Self:TomCallaway spot] ||2007-01-30||Suggested buildroot is now mandatory +|- +|All binaries must be built from source||[wiki:Self:TomCallaway spot] ||2007-01-30||See: [wiki:Self:PackagingDrafts/SourceRequirement PackagingDrafts/SourceRequirement] +|- +|BuildRequires Clarification||[wiki:Self:TomCallaway spot] ||2007-01-30||Clarify BuildRequires tools, see [wiki:Self:PackagingDrafts/BuildRequires PackagingDrafts/BuildRequires] +|- +|Debuginfo packages||VilleSkyttä||2007-02-09||Add pointer to [wiki:Self:Packaging/Debuginfo sanity checking of debuginfo packages] to guidelines, require [https://www.redhat.com/archives/fedora-packaging/2006-October/msg00149.html explanation in specfile if disabled] . +|- +|Requires vs PreReq||[wiki:Self:TomCallaway spot] ||2006-10-31||Use "Requires" not "PreReq". [http://rpm.org/max-rpm-snapshot/s1-rpm-depend-manual-dependencies.html#S3-RPM-DEPEND-FINE-GRAINED rpm.org explanation] +|- +|Provides/obsoletes clarifications||VilleSkyttä||2007-01-22||Naming guidelines improvements on Provides/Obsoletes use when renaming/replacing packages. +|- +|Failsafe scriptlets||VilleSkyttä||2006-12-14||Make || : (or other scriptlet failure preventation measures) more prominent in ["Packaging/ScriptletSnippets"] +|- +|Directory ownership||JasonTibbitts||2006-11-07||"Packages must not own files or directories already owned by other packages that they depend on. Exceptions to this rule are: perl...." Add specific wording on when and how Perl packages are excluded from this. +|- +|Translations||RexDieter||2006-10-31||If the package has any translations, add BuildRequires: gettext. If you don't, your package could fail to generate translation files in the buildroot. +|- +|bumping release num after the dist tag||spot||2006-10-16||Added to [[Packaging/NamingGuidelines]] +|- +|GConf configure flag||abadger1999||2006-10-12||Update the ScriptletSnippet for alternate GConf disabling "GConf schema installation can be prevented at build time by using GCONF_DISABLE_MAKEFILE_SCHEMA_INSTALL.... alternatively, %configure --disable-schemas works for some packages." +|- +|Ruby library provides||DavidLutterkort||2006-10-12||Current ruby packaging guidelines say that ruby library packages must provide 'ruby(LIBRARY)'; this should be changed to include a version, i.e. 'ruby(LIBRARY) = VERSION' where VERSION is the upstream version of the library as long as upstream follows a reasonable versioning process (which most ruby projects do) +|- +|desktop-file-install --vendor||RexDieter||2006-10-05||clarify --vendor=... usage. proposal: [[PackagingDrafts/DesktopFiles]] +|- +|pkgconfig||RexDieter||2006-09-14||[[PackagingDrafts/pkgconfig]] +|- +|libexecdir (completed)||abadger1999||2006-06-29||The packaging guidelines follow the FHS. An exception should be made for %{_libexecdir} which is useful for binaries intended for running by other programs. This is especially true on multilib systems. [https://www.redhat.com/archives/fedora-packaging/2006-June/msg00161.html Packaging list discussion] . (Note by Axel: Maybe get involved in FHS discussions to resurrect libexec in the FHS?) +|- +|mono||abadger1999||2006-06-29||The current ["Packaging/Mono"] Guidelines contain misinformation and poor practices. We need to separate the good practices from the ones that were done because an upstream package made it convenient. There have been several mailing list discussions: [https://www.redhat.com/archives/fedora-packaging/2006-June/msg00031.html 1] [https://www.redhat.com/archives/fedora-packaging/2006-June/msg00134.html 2] [https://www.redhat.com/archives/fedora-extras-list/2006-June/msg00835.html 3] My (hopefully accurate) [https://www.redhat.com/archives/fedora-packaging/2006-June/msg00154.html summary] +|- +|ruby||lutter||2006-06-29||The [http://www.fedoraproject.org/wiki/Packaging/Ruby Ruby packaging guidelines] need to be discussed/blessed so that Ruby review requests can move forward +|- +|Drafts Hierarchy||abadger1999||2006-07-06||The problems with the Mono Guidelines and the change in permissions on the ["Packaging"] hierarchy shows we need a separate area to propose draft documents and changes. This area 1) should not be taken as official by packagers, 2) should allow packagers to write in comments, 3) serve as a staging area where future guidelines can be discussed. I'd like to bless ["PackagingDrafts"] for this. Currently used for ["PackagingDrafts/RubyGems"] and ["PackagingDrafts/Mono"] +|- +|Perl tweaks||JasonTibbitts||easyfix||No changes to the guidelines. Perl template was commented to tell the packager to remove OPTIMIZE and other lines for noarch packages. +|- +|PHP guidelines||JasonTibbitts||2006-07-27||Decide whether the PHP guidelines (Packaging/PHP) are good as is, or if they need more work. +|- +|ScriptletSnippets||abadger1999||2006-07-27||Ratify the ScriptletSnippets as official guide. +|- +|changelog format||spot||2006-07-06||We decided to adopt ["PackagingDrafts/Changelog"] . Adopted as a '''Must''' +|- +|Python:Include %ghost files||abadger1999||2006-08-10||After recent discussion on fed-extras, %ghost'ing of .pyo files is seen as harmful. We should just include them in %files. +|- +|Reword %makeinstall guideline||abadger1999||2006-08-24||Discussed and voted on the mailing list: Fedora's RPM includes a %makeinstall macro but it must NOT be used when make install DESTDIR=%{buildroot} will work. %makeinstall is a kludge that can work with Makefiles that don't make use of the DESTDIR variable but it has the following potential issues: +|- +|$RPM_OPT_FLAGS||VilleSkyttä||2006-08-??||A section about [wiki:Self:Packaging/Guidelines#CompilerFlags compiler flags] has been added to the packaging guidelines +|- +|Reword ldconfig guideline||abadger1999||2006-08-17||MUST: Every binary RPM package which stores shared library files (not just symlinks) in any of the dynamic linker's default paths, must call ldconfig in %post and %postun. +|- +|CommitID ||JasonTibbitts ||2007-06-26||Allow upstream VCS commit ID to appear in alphatag [[PackagingDrafts/CommitIDs| ]] +|} + +{| border="1" +|- ||||||style="color: white; background-color: #3074c2; font-weight: bold" +|Rejected Items +|- +|Package Names should be all lowercase||abadger1999|| 2008-04-08 ||["PackagingDrafts/ASCIINamingLowercase"] +|- +|RPMGroups||[wiki:Self:TomCallaway spot] ||2006-11-28||Revisit Making Group optional at some point, when RPM is ready. +|- +|ipv6 in Fedora||[wiki:Self:TomCallaway spot] ||2006-07-13||ipv6 initiatives should be a Fedora SIG, not a Packaging Committee decision. +|- +|Hardcoding Dist Tags||spot||2006-07-13||Allow packages to write Release: 1.fc5 literally instead of Release: 1%{?dist} +|- +|Python Submodule Naming||abadger1999||2006-08-24||Should a python submodule named paste.deploy be named python-paste-deploy or python-pastedeploy. List discussion decided to leave this at maintainers discretion (status quo) +|- +|kernel modules||AxelThimm||2006-08-23||Review the kernel module packaging guide [http://www.redhat.com/archives/fedora-extras-list/2006-April/msg01555.html mail on fedora-extras] [[AxelThimm/kmdls| own page]] +|- +|disttags for rawhide/test||AxelThimm||2006-08-31||What disttags should Rawhide use to ensure proper upgrade paths and automated rebuilds (e.g. .fc6.89 vs .fc7). +|- +|disttags for FL||AxelThimm||withdrawn||What disttags should Fedora Legacy (for RHL7.3 and RHL9) use to ensure proper upgrade paths. +|- +|libfoo or compat||AxelThimm||withdrawn||Guidelines for creating compatibility packages possibly already in advance [http://www.redhat.com/archives/fedora-extras-list/2006-June/msg01079.html mail on fedora-extras] +|- +|Secure BuildRoot ||LubomirKundrak||failed vote||["PackagingDrafts/SecureBuildRoot"] idea is sound, but should be handled in rpm. +|- +|Register VirtualProvides ||PatriceDumas||failed vote||["PackagingDrafts/ProvidesList"] idea is sound, but should be automatically generated. +|} +---- +[[Category:Extras]] From 78f492cd8ef9c13d9024bdc904f6310d3894183f Mon Sep 17 00:00:00 2001 From: ImportUser Date: May 24 2008 14:13:02 +0000 Subject: [PATCH 62/3559] Imported from MoinMoin --- diff --git a/Packaging:Python_Eggs.mw b/Packaging:Python_Eggs.mw new file mode 100644 index 0000000..a190ccf --- /dev/null +++ b/Packaging:Python_Eggs.mw @@ -0,0 +1,126 @@ += Python Eggs = + +Python packages have started to use setuptools in their package build scripts. Packages which do this provide extra metadata about the package in the form of eggs. This document explains how to package eggs. + + + +== Why Eggs == +Eggs have several uses including: +1. Allowing end users to install eggs not made from rpms or install eggs into their home directories. This is an important feature for people working within a shared hosting environment. +1. Giving python packages an easy way to support plugins. +1. Giving us a way to support multiple versions of a python module for compat libraries. + +== What are Eggs == +Eggs can be placed on disk in several formats: +* As a module and a file with a .egg-info extension that contains the metadata. Created by distutils in Fedora 9's python2.5. +* As a module and a directory with a .egg-info extension that contains the metadata. Created using the most common invocation of setup.py in our examples below. +* As a directory with a .egg extension that contains the module and egg metadata. Created when we use easy_install -m to allow installing multiple versions of a module. +* As a single zip file with a .egg extension that contains the module and the egg metadata. + +In Fedora Packages, these will be installed to %{python_sitelib} or %{python_sitearch} directories. + +{{Anchor|WhenEggs}} +== When to Provide Eggs == +Since eggs establish a base of functionality that upstream authors can expect, we need to be sure to include the egg files if a package builds them. Starting with Fedora 9 any package that uses setuptools or distutils will build egg-info. In Fedora 8 or less, only setuptools packages build egg-info. If you need to provide egg-info for a distutils package on Fedora 8 or less, [[NonSetuptoolsEggs| Providing Eggs using Setuptools]] describes a method of substituting setuptools for distutils in the build process so egg-info is created. + +{{ Template:note/| In the past, when there was a requirement for an egg which was not provided by upstream we would patch the requiring package to not require that package. This behaviour is deprecated and as packages are updated maintainers should follow the below guidelines to install eggs for the required packages. Please see [[NonSetuptoolsEggs| Creating Eggs for Non-setuptools Packages]] +}} + +== Upstream Eggs == +Do not distribute eggs from upstream. In Fedora, all packages must be rebuilt from source. An egg package contains compiled bytecode and may, if it contains a C extension, contain compiled binary extensions as well. These are opaque structures with no guarantee that they were even built from the source distributed with the egg. If you must use an egg from upstream because they do not provide tarballs, you need to include it as a source in your spec, unzip it in %setup, and rebuild from the source files contained within it. + +== Providing Eggs using Setuptools == +When upstream uses setuptools to provide eggs it is very simple to include them in your package. Your spec file will look something like this: + +
+BuildRequires: python-setuptools-devel
+
+[...] 
+
+%install
+%{__python} setup.py install --skip-build --root $RPM_BUILD_ROOT
+
+[...] 
+
+%files
+[...] 
+%{python_sitelib}/*
+
+ +{{ /code/| commandline argument to create egg info and an expanded directory directly in site-packages. This is no longer necessary as --root creates things the way we want for packaging. +}} + +{{Anchor|NonSetuptoolsEggs}} +== Providing Eggs for non-setuptools packages == +{{ Template:note/| These instructions are only for distutils in Fedora <= 8. Fedora 9 and above will automatically generate egg-info files. +}} + +When we need to provide eggs in a non-setuptools package because another package requires that functionality we can modify our spec files to generate the egg-info: + +
+BuildRequires: python-setuptools-devel
+
+[...] 
+
+%build
+CFLAGS="$RPM_OPT_FLAGS" %{__python} -c 'import setuptools; execfile("setup.py")' build
+
+%install
+rm -rf $RPM_BUILD_ROOT
+%{__python} -c 'import setuptools; execfile("setup.py")' install --skip-build --root $RPM_BUILD_ROOT
+
+%files
+%{python_sitelib}/*egg-info
+%{python_sitelib}/[MODULENAME] 
+
+ +By importing setuptools before executing setup.py we override the distutils functions that process the file with their setuptools equivalents. Those functions create the egg-info files. + +== Multiple Versions == + +{{ /code/| section +}} + +Sometimes we want to keep an old version of a module around for compatibility. When upstream has renamed the module for us, this is a straightforward creation of a new module. For instance, python-psycopg and python-psycopg2. + +When upstream doesn't include the version in the name, we have to find another way to parallel install two versions of the package. Eggs give us this ability. The latest version of a package must be installed as the python-MODULENAME and is built using the normal guidelines. The compatibility versions of the module should be named python-$MODULENAME$DISTINGUISHINGVER and be enabled by making these spec file changes: + +
+Requires: python-setuptools
+
+%build
+CFLAGS="$RPM_OPT_FLAGS" %{__python} setup.py bdist_egg
+
+%install
+rm -rf $RPM_BUILD_ROOT
+mkdir -p $RPM_BUILD_ROOT%{python_sitelib}
+easy_install -m --prefix $RPM_BUILD_ROOT%{_usr} dist/*.egg
+
+ +This creates the python egg under the %{python_sitelib}/*.egg directory. This module is not directly usable via the import statement. Instead, the consuming package must setup the PYTHONPATH to reference the compat version before it imports the module. This can be done in a variety of ways. +* Manually modifying sys.path is quick if the user just wants to try out some code with the old version: +
+>>> import sys
+>>> sys.path.insert(0, '/usr/lib/python2.5/site-packages/CherryPy-2.2.1-py2.5.egg/')
+>>> import cherrypy
+
+* Using setuptools and easy_install to create "script wrappers" to invoke the programs. Setuptools has you define an entrypoint in the program's module (basically, a main() function) and then writes a script to access that via an option in setup.py. + +It is highly recommended that any such compatibility packages install a README.fedora file explaining how to use this module. The file should contain the above examples of how to call the module from code and explain that this is a compat package and that a newer version exists. Here's an [[Image:Packaging_Python_Eggs_README.fedora]] example README.fedora] to look at for ideas. + +There are several other methods of invoking scripts so that they might take the right version but they suffer from various problems. They are listed here because a program you're packaging may use them and you need to know about them if they break. If you mention them in README.fedora, please also add why they are dangerous to use. + +* pkg_resources.requires('MODULE[VERSIONINFO] '): Does not work with a default version (able to be imported via import MODULE). The setuptools author refuses to remove this limitation and refuses to document that it is a limitation. Therefore you may run across scripts that use this method and need to patch them to use one of the above, supported methods instead. +* __requires__='MODULE[VERSIONINFO] ': This works but the setuptools author feels that it is only a workaround and will not support it. It works presently but could stop in a future version of setuptools. Some upstreams use this method and may need to be fixed if the setuptools author ever changes the interface. + +== Egg "Features" to avoid == +Eggs provide some features that are to be avoided as part of the packaging process for Fedora. Some of these may provide benefit to our users but should not be used when creating system packages. + +* Do not let easy_install download and install packages from the net to add to the build root. This will fail on the build system as well as being bad packaging. Packages which are downloaded are probably missing from your BuildRequires. + +== Links == + +* http://peak.telecommunity.com/DevCenter/PythonEggs +* http://peak.telecommunity.com/DevCenter/setuptools +* http://lists.debian.org/debian-python/2007/09/msg00004.html -- Discussion of eggs in Debian +* http://mail.python.org/pipermail/distutils-sig/2007-September/008181.html -- Discussion of these guidelines on the distutils list From b247336e78485e79486298fbf4fc2160f938a70a Mon Sep 17 00:00:00 2001 From: Timlau Date: May 26 2008 12:28:42 +0000 Subject: [PATCH 64/3559] /* Desktop files */ --- diff --git a/Packaging:Guidelines.mw b/Packaging:Guidelines.mw index d9602c2..b1f196c 100644 --- a/Packaging:Guidelines.mw +++ b/Packaging:Guidelines.mw @@ -435,8 +435,8 @@ Currently, only SystemV-style initscripts are supported in Fedora. There are det {{Anchor|desktop}} == Desktop files == -If a package contains a GUI application, then it needs to also include a properly installed .desktop file. For the purposes of these guidelines, a GUI application is defined as any application which draws an X window and runs from within that window. Installed .desktop files MUST follow the [[http://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html desktop-entry-spec] , paying particular attention to validating correct usage of Name, GenericName, [[http://standards.freedesktop.org/menu-spec/latest/apa.html Categories] , -[[http://www.freedesktop.org/Standards/startup-notification-spec StartupNotify] +If a package contains a GUI application, then it needs to also include a properly installed .desktop file. For the purposes of these guidelines, a GUI application is defined as any application which draws an X window and runs from within that window. Installed .desktop files MUST follow the [[http://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html desktop-entry-spec]] , paying particular attention to validating correct usage of Name, GenericName, [[http://standards.freedesktop.org/menu-spec/latest/apa.html Categories]] , +[[http://www.freedesktop.org/Standards/startup-notification-spec StartupNotify]] entries. === Icon tag in Desktop Files === @@ -497,6 +497,7 @@ desktop-file-install --vendor="" \ This is mostly for the sake of menu-editing (which bases off of .desktop file/path names). {{Anchor|macros}} + == Macros == Use macros instead of hard-coded directory names (see ["Packaging/RPMMacros"] ). From fad841270b9a46079cd00aaf127686f72875081e Mon Sep 17 00:00:00 2001 From: Timlau Date: May 26 2008 12:29:41 +0000 Subject: [PATCH 65/3559] /* Desktop files */ --- diff --git a/Packaging:Guidelines.mw b/Packaging:Guidelines.mw index b1f196c..b64aa8c 100644 --- a/Packaging:Guidelines.mw +++ b/Packaging:Guidelines.mw @@ -435,8 +435,8 @@ Currently, only SystemV-style initscripts are supported in Fedora. There are det {{Anchor|desktop}} == Desktop files == -If a package contains a GUI application, then it needs to also include a properly installed .desktop file. For the purposes of these guidelines, a GUI application is defined as any application which draws an X window and runs from within that window. Installed .desktop files MUST follow the [[http://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html desktop-entry-spec]] , paying particular attention to validating correct usage of Name, GenericName, [[http://standards.freedesktop.org/menu-spec/latest/apa.html Categories]] , -[[http://www.freedesktop.org/Standards/startup-notification-spec StartupNotify]] +If a package contains a GUI application, then it needs to also include a properly installed .desktop file. For the purposes of these guidelines, a GUI application is defined as any application which draws an X window and runs from within that window. Installed .desktop files MUST follow the [http://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html desktop-entry-spec] , paying particular attention to validating correct usage of Name, GenericName, [http://standards.freedesktop.org/menu-spec/latest/apa.html Categories] , +[http://www.freedesktop.org/Standards/startup-notification-spec StartupNotify] entries. === Icon tag in Desktop Files === From 40e0f08e242a8f3e07df006180ca190e1510f261 Mon Sep 17 00:00:00 2001 From: Timlau Date: May 26 2008 12:34:34 +0000 Subject: [PATCH 66/3559] /* Application Specific Guidelines */ --- diff --git a/Packaging:Guidelines.mw b/Packaging:Guidelines.mw index b64aa8c..b2ab8b9 100644 --- a/Packaging:Guidelines.mw +++ b/Packaging:Guidelines.mw @@ -793,56 +793,56 @@ Some applications have specific guidelines written for them, located on their ow {{Anchor|EclipseGuidelines}} === Eclipse === -Guidelines for Eclipse plugin packages: ["Packaging/EclipsePlugins"] +Guidelines for Eclipse plugin packages: [[Packaging/EclipsePlugins]] {{Anchor|EmacsGuidelines}} === Emacs === -Guidelines for Emacs/X-Emacs packages: ["Packaging/Emacs"] +Guidelines for Emacs/X-Emacs packages: [[Packaging/Emacs]] {{Anchor|FontGuidelines}} === Fonts === -Guidelines for font packages: ["Packaging/FontsPolicy"] +Guidelines for font packages: [[Packaging/FontsPolicy]] {{Anchor|JavaGuidelines}} === Java === -Guidelines for java packages: ["Packaging/Java"] +Guidelines for java packages: [[Packaging/Java]] {{Anchor|MonoGuidelines}} === Mono === -Guidelines for Mono packages: ["Packaging/Mono"] +Guidelines for Mono packages: [[Packaging/Mono]] {{Anchor|OCamlGuidelines}} === OCaml === -Guidelines for OCaml packages: ["Packaging/OCaml"] +Guidelines for OCaml packages: [[Packaging/OCaml]] {{Anchor|OpenOffice.orgGuidelines}} === OpenOffice.org === -Guidelines for OpenOffice.org extension packages: ["Packaging/OpenOffice.orgExtensions"] +Guidelines for OpenOffice.org extension packages: [[Packaging/OpenOffice.orgExtensions]] {{Anchor|PerlGuidelines}} === Perl === -Guidelines for Perl packages: ["Packaging/Perl"] +Guidelines for Perl packages: [[Packaging/Perl]] {{Anchor|PHPGuidelines}} === PHP === -Guidelines for PHP packages: ["Packaging/PHP"] +Guidelines for PHP packages: [[Packaging/PHP]] {{Anchor|PythonGuidelines}} === Python === -Guidelines for Python addon modules: ["Packaging/Python"] +Guidelines for Python addon modules: [[Packaging/Python]] {{Anchor|RGuidelines}} === R === -Guidelines for R module packages: ["Packaging/R"] +Guidelines for R module packages: [[Packaging/R]] {{Anchor|RubyGuidelines}} === Ruby === -Guidelines for Ruby packages: ["Packaging/Ruby"] +Guidelines for Ruby packages: [[Packaging/Ruby]] {{Anchor|SugarGuidelines}} === Sugar === -Guidelines for Sugar Activity packages: ["Packaging/SugarActivityGuidelines"] +Guidelines for Sugar Activity packages: [[Packaging/SugarActivityGuidelines]] {{Anchor|TclGuidelines}} === Tcl/Tk === -Guidelines for Tcl/Tk extension packages: ["Packaging/Tcl"] +Guidelines for Tcl/Tk extension packages: [[Packaging/Tcl]] From 3cac9e2f57d397c28bd085ae5ec964b94265278b Mon Sep 17 00:00:00 2001 From: Timlau Date: May 26 2008 12:44:19 +0000 Subject: [PATCH 67/3559] Make achor links work by adding # --- diff --git a/Packaging:Guidelines.mw b/Packaging:Guidelines.mw index b2ab8b9..e4dddb0 100644 --- a/Packaging:Guidelines.mw +++ b/Packaging:Guidelines.mw @@ -57,14 +57,15 @@ If you base a package on an existing non-Fedora package, be careful to verify it In particular, you should *verify any sources and patches. -*verify that the license stated in the spec file matches the actual license of the software (see [[tags| Tags]] ), -*skim the summary and description for typos and oddities (see [[summary| Summary and description]] ), +*verify that the license stated in the spec file matches the actual license of the software (see [[#tags| Tags]] ), +*skim the summary and description for typos and oddities (see [[#summary| Summary and description]] ), *make sure that the correct build root is used, -*ensure that macro usage is consistent (see [[macros| Macros]] ). +*ensure that macro usage is consistent (see [[#macros| Macros]] ). Keep old changelog entries to credit the original authors. Entries that are several years old or refer to ancient versions of the software may be erased. If you end up doing radical changes and re-write most of the spec file anyway, feel free to start the changelog from scratch. In other words, use your best judgement. {{Anchor|layout}} + == Filesystem Layout == Fedora follows the [http://www.pathname.com/fhs/ Filesystem Hierarchy Standard] with regards to filesystem layout. The FHS defines where files should be placed on the system. Fedora packages should follow the FHS whenever possible. Any deviation from the FHS should be rationalized when the package is reviewed. From 5b2338dcf2c445b1511f83778a31599d3f03e77c Mon Sep 17 00:00:00 2001 From: Timlau Date: May 26 2008 12:45:32 +0000 Subject: [PATCH 68/3559] Make achor links work by adding # --- diff --git a/Packaging:Guidelines.mw b/Packaging:Guidelines.mw index e4dddb0..91b77aa 100644 --- a/Packaging:Guidelines.mw +++ b/Packaging:Guidelines.mw @@ -166,7 +166,7 @@ This is to ensure that the !BuildRoot will be created fresh during the %in == Requires == RPM has very good capabilities of automatically finding dependencies for libraries and eg. Perl modules. In short, don't reinvent the wheel, but just let rpm do its job. There is usually no need to explicitly list eg. Requires: libX11 when the dependency has already been picked up by rpm in the form of depending on libraries in the libX11 package. -Build requirements are different. There's no automatic dependency find procedure for them, which means that you must explicitly list stuff that the package requires to build successfully. Typically, some -devel packages are listed there. Refer to the [[BuildRequires| BuildRequires section]] . +Build requirements are different. There's no automatic dependency find procedure for them, which means that you must explicitly list stuff that the package requires to build successfully. Typically, some -devel packages are listed there. Refer to the [[#BuildRequires| BuildRequires section]] . Sometimes we know that a package requires eg. gtk+-devel 1.2 or newer to build (and thus gtk+ 1.2 or newer to run, but that's handled automatically). There are two things to consider here: @@ -200,6 +200,7 @@ Packages should not use the PreReq tag. Once upon a time, in dependency loops Pr Rpm gives you the ability to depend on files instead of packages. Whenever possible you should avoid file dependencies outside of /etc, /bin, /sbin, /usr/bin, or /usr/sbin. Using file dependencies outside of those directories requires yum (and other depsolvers using the repomd format) to download and parse a large xml file looking for the dependency. Helping the depsolvers avoid this processing by depending on the package instead of the file saves our end users a lot of time. There are times when other technical considerations outweigh these considerations. One specific example is packages installing into %{_libdir}/mozilla/plugins. In this case, mandating a specific browser in your package just to own this directory could drag in a large amount of needless packages. Requiring the directory to resolve the dependency is the better choice. {{Anchor|BuildRequires}} + == BuildRequires == In package development and testing, please verify that your package is not missing any necessary build dependencies. Having proper build requirements saves the time of all developers and testers as well as autobuild systems because they will not need to search for missing build requirements manually. It is also a safety feature that prevents builds with that would not otherwise fail, but would be missing crucial features. For example, a graphical application may exclude PNG support after its '''configure''' script detects that libpng is not installed. From eae6280b0577c15479235109d21cddc172f0c887 Mon Sep 17 00:00:00 2001 From: Timlau Date: May 26 2008 12:48:31 +0000 Subject: [PATCH 69/3559] Make achor links work by adding # --- diff --git a/Packaging:Naming.mw b/Packaging:Naming.mw index 2462286..1cb10e2 100644 --- a/Packaging:Naming.mw +++ b/Packaging:Naming.mw @@ -24,7 +24,7 @@ ABCDEFGHIJKLMNOPQRSTUVWXYZ === General Naming === When naming a package, the name should match the upstream tarball or project name from which this software came. In some cases, this naming choice may be more complicated. If this package has been packaged by other distributions/packagers in the past, then you should try to match their name for consistency. In any case, try to use your best judgement, and other developers will help in the final decision. -Additionally, it is possible that the upstream name does not fall into the [[CommonCharacterSet| Common Character Set]] . If this is the case, refer to: [[Transliteration| When Upstream Naming is outside of the specified character set]] . +Additionally, it is possible that the upstream name does not fall into the [[#CommonCharacterSet| Common Character Set]] . If this is the case, refer to: [[#Transliteration| When Upstream Naming is outside of the specified character set]] . === Separators === When naming packages for Fedora, the maintainer must use the dash '-' as the delimiter for name parts. The maintainer must NOT use an underscore '_', a plus '+', or a period '.' as a delimiter. From 35730f3743324b9f78c3c52f6ef03b627546f590 Mon Sep 17 00:00:00 2001 From: Timlau Date: May 26 2008 12:49:19 +0000 Subject: [PATCH 70/3559] Make achor links work by adding # --- diff --git a/Packaging:Naming.mw b/Packaging:Naming.mw index 1cb10e2..132582e 100644 --- a/Packaging:Naming.mw +++ b/Packaging:Naming.mw @@ -30,8 +30,8 @@ Additionally, it is possible that the upstream name does not fall into the [[#Co When naming packages for Fedora, the maintainer must use the dash '-' as the delimiter for name parts. The maintainer must NOT use an underscore '_', a plus '+', or a period '.' as a delimiter. There are a few exceptions to the no underscore '_' rule. -* httpd, pam, and SDL addon packages are excluded, refer to "'''[[AddonHttpdPamSDL| Addon Packages (httpd, pam and SDL)]] '''". -* packages that are locale specific, and use the locale in the name are excluded, refer to "'''[[AddonLocale| Addon Packages (locale)]] '''". +* httpd, pam, and SDL addon packages are excluded, refer to "'''[[#AddonHttpdPamSDL| Addon Packages (httpd, pam and SDL)]] '''". +* packages that are locale specific, and use the locale in the name are excluded, refer to "'''[[#AddonLocale| Addon Packages (locale)]] '''". * packages where the upstream name naturally contains an underscore are excluded from this. Examples of these packages include: 
 arptables_jf
@@ -50,6 +50,7 @@ tcp_wrappers
 If in doubt, ask on fedora-devel-list.
 
 {{Anchor|Transliteration}}
+
 === When Upstream Naming is outside of the specified character set ===
 Fedora recognizes that the task of converting text to the specified ASCII character set (aka transliteration) is difficult. Accordingly, when the upstream name is outside of the specified ASCII character set, the Fedora package maintainer should first contact the upstream for that software and ask them for a transliteration of the name for Fedora to use.
 

From ba3af4188dc5534e6578689982e5d7df17aef9ea Mon Sep 17 00:00:00 2001
From: Timlau 
Date: May 26 2008 12:50:33 +0000
Subject: [PATCH 71/3559] Make achor links work by adding #


---

diff --git a/Packaging:Naming.mw b/Packaging:Naming.mw
index 132582e..84a0451 100644
--- a/Packaging:Naming.mw
+++ b/Packaging:Naming.mw
@@ -99,15 +99,16 @@ If the version is non-numeric (contains tags that are not numbers), you may need
 
 There are four cases where the version contains non-numeric characters:
 
-* Pre-release packages: Packages released as "pre-release" versions, prior to a "final" version. Example tags include "alpha", "beta", "rc", "cvs". Unfortunately, we cannot simply put these letters into the version tag, so we use the Release field for this. Details can be found here: [[NonNumericRelease|  Non-Numeric Version in Release]] 
+* Pre-release packages: Packages released as "pre-release" versions, prior to a "final" version. Example tags include "alpha", "beta", "rc", "cvs". Unfortunately, we cannot simply put these letters into the version tag, so we use the Release field for this. Details can be found here: [[#NonNumericRelease|  Non-Numeric Version in Release]] 
 
-* Post-release packages: Packages released after a "final" version. These packages contain the same numeric version as the "final" version, but have an additional non-numeric identifier. Details can be found here: [[NonNumericRelease|  Non-Numeric Version in Release]] 
+* Post-release packages: Packages released after a "final" version. These packages contain the same numeric version as the "final" version, but have an additional non-numeric identifier. Details can be found here: [[#NonNumericRelease|  Non-Numeric Version in Release]] 
 
-* Snapshot packages: Packages built from cvs or subversion snapshots. These packages could be either "pre" or "post" release packages. Details can be found here: [[NonNumericRelease|  Non-Numeric Version in Release]] 
+* Snapshot packages: Packages built from cvs or subversion snapshots. These packages could be either "pre" or "post" release packages. Details can be found here: [[#NonNumericRelease|  Non-Numeric Version in Release]] 
 
 * JPackage derived Fedora packages: Packages which derive from JPackage RPMS follow a special policy. Details can be found here: [wiki:Self:Packaging/JPackagePolicy JPackagePolicy] 
 
 {{Anchor|PackageRelease}}
+
 == Package Release ==
 In the past, Fedora.us used 0.fdr as a release prefix to identify Fedora.us packages. In Fedora, this repository "tagging" is unnecessary, and should not be used. The release number (referred to in some older documentation as a "vepoch") is how the maintainer marks build revisions, starting from 1. When a minor change (spec file changed, patch added/removed) occurs, or a package is rebuilt to use newer headers or libraries, the release number should be incremented. If a major change (new version of the software being packaged) occurs, the version number should be changed to reflect the new software version, and the release number should be reset to 1.
 

From ee0a06a427a8bcd6f81997d701004666295d0f1a Mon Sep 17 00:00:00 2001
From: Timlau 
Date: May 26 2008 12:51:30 +0000
Subject: [PATCH 72/3559] Make achor links work by adding #


---

diff --git a/Packaging:Naming.mw b/Packaging:Naming.mw
index 84a0451..ab60ade 100644
--- a/Packaging:Naming.mw
+++ b/Packaging:Naming.mw
@@ -181,7 +181,7 @@ alsa-lib-0.9.2-2
 {{Anchor|SnapshotPackages}}
 ==== Snapshot packages ====
 
-If a snapshot package is considered a "pre-release package", you should follow the guidelines listed in [[PreReleasePackages|  Pre-Release Packages]] , and use an %{alphatag} beginning with the date in YYYYMMDD format and followed by up to 16 (ASCII) alphanumeric characters of your choosing.  The date should reference the date the checkout was taken; the rest can be as simple as "cvs" or "snap", or a subversion change number like "svn12345" or an abbreviated git hash like "git5aef11739b".
+If a snapshot package is considered a "pre-release package", you should follow the guidelines listed in [[#PreReleasePackages|  Pre-Release Packages]] , and use an %{alphatag} beginning with the date in YYYYMMDD format and followed by up to 16 (ASCII) alphanumeric characters of your choosing.  The date should reference the date the checkout was taken; the rest can be as simple as "cvs" or "snap", or a subversion change number like "svn12345" or an abbreviated git hash like "git5aef11739b".
 
 If a snapshot package is considered a "post-release package", the following applies:
 
@@ -200,6 +200,7 @@ kismet-1.0-5.20050517cvs (new cvs checkout, note the increment of %{X})
{{Anchor|PostReleasePackages}} + ==== Post-Release packages ==== Like pre-release packages, non-numeric versioned "post-release" packages can be problematic and also must be treated with care. These fall under two generic categories: From b347bd86811cb7f50bbaf35a0f42c211291e6b82 Mon Sep 17 00:00:00 2001 From: Timlau Date: May 26 2008 12:52:18 +0000 Subject: [PATCH 73/3559] Make achor links work by adding # --- diff --git a/Packaging:Naming.mw b/Packaging:Naming.mw index ab60ade..42a88d3 100644 --- a/Packaging:Naming.mw +++ b/Packaging:Naming.mw @@ -261,9 +261,10 @@ This is ONLY permitted if you are using disttags in your Release field. == Case Sensitivity == In Fedora packaging, the maintainer should use his/her best judgement when considering how to name the package. While case sensitivity is not a mandatory requirement, case should only be used where necessary. Keep in mind to respect the wishes of the upstream maintainers. If they refer to their application as "ORBit", you should use "ORBit" as the package name, and not "orbit". However, if they do not express any preference of case, you should default to lowercase naming.

-The exception to this is for perl module packaging. The CPAN Group and Type should be capitalized in the name, as if they were proper nouns . (Refer to '''[[AddonPerl| Addon Packages (perl modules)]] ''' for details.) +The exception to this is for perl module packaging. The CPAN Group and Type should be capitalized in the name, as if they were proper nouns . (Refer to '''[[#AddonPerl| Addon Packages (perl modules)]] ''' for details.) {{Anchor|PackageRename}} + == Renaming/replacing existing packages == In the event that it becomes necessary to rename or replace an existing package, the new package should make the change transparent to end users to the extent applicable. From 7261ea29cbe2f1d1923ec437a7d13ed9e97cf879 Mon Sep 17 00:00:00 2001 From: Timlau Date: May 26 2008 12:53:15 +0000 Subject: [PATCH 74/3559] Make achor links work by adding # --- diff --git a/Packaging:Naming.mw b/Packaging:Naming.mw index 42a88d3..eeb6efb 100644 --- a/Packaging:Naming.mw +++ b/Packaging:Naming.mw @@ -81,7 +81,7 @@ Example: If your package is named foo-1.0.0-1.src.rpm, then the spec file should be named foo.spec. -There is normally no need to include the %{version} in the spec file name. If you are packaging multiple versions of a package for simultaneous use, they should already reflect the version in the %{name}.spec scheme (refer to [[MultiplePackages| Multiple Packages with the same base name]] for details). In normal cases adding the version can cause the spec file's history to be lost when a package's version is upgraded. +There is normally no need to include the %{version} in the spec file name. If you are packaging multiple versions of a package for simultaneous use, they should already reflect the version in the %{name}.spec scheme (refer to [[#MultiplePackages| Multiple Packages with the same base name]] for details). In normal cases adding the version can cause the spec file's history to be lost when a package's version is upgraded. As a special exception, there are a few packages which are allowed to have a version in their spec filename. This is because they had the version in their name when they were merged from Fedora Core's cvs and removing the version at that time would have *lost* history: * gcc @@ -93,6 +93,7 @@ This exception will go away when any of the following criteria are met: {{Anchor|PackageVersion}} + == Package Version == The Version field in the spec is where the maintainer should put the current version of the software being packaged. If the version is non-numeric (contains tags that are not numbers), you may need to include the additional non-numeric characters in the release field. From a4bfb53e731c5a84cef0dfea91b3799e2ce044d3 Mon Sep 17 00:00:00 2001 From: Timlau Date: May 26 2008 14:27:23 +0000 Subject: [PATCH 75/3559] fixed links --- diff --git a/Packaging:Guidelines.mw b/Packaging:Guidelines.mw index 91b77aa..f917bbf 100644 --- a/Packaging:Guidelines.mw +++ b/Packaging:Guidelines.mw @@ -26,9 +26,10 @@ There are various legal concerns to consider when packaging for Fedora. {{Anchor|LegalLicensing}} === Licensing === -You should review ["Licensing"] and the ["Packaging/LicensingGuidelines"] to ensure that your package is licensed appropriately. +You should review [[Licensing]] and the [[Packaging/LicensingGuidelines]] to ensure that your package is licensed appropriately. {{Anchor|SourceRequirement}} + == No inclusion of pre-built binaries or libraries == All binaries or libraries included with Fedora packages must have been built from sourcecode included in the source package. This is a requirement for the following reasons: From db3cfb47ab5b20486d0bb1d3887725c932a10658 Mon Sep 17 00:00:00 2001 From: Timlau Date: May 26 2008 14:34:58 +0000 Subject: [PATCH 76/3559] link fixes --- diff --git a/Packaging:Guidelines.mw b/Packaging:Guidelines.mw index f917bbf..6205fce 100644 --- a/Packaging:Guidelines.mw +++ b/Packaging:Guidelines.mw @@ -206,15 +206,15 @@ Rpm gives you the ability to depend on files instead of packages. Whenever poss In package development and testing, please verify that your package is not missing any necessary build dependencies. Having proper build requirements saves the time of all developers and testers as well as autobuild systems because they will not need to search for missing build requirements manually. It is also a safety feature that prevents builds with that would not otherwise fail, but would be missing crucial features. For example, a graphical application may exclude PNG support after its '''configure''' script detects that libpng is not installed. -Before adding BuildRequires to any package, please be comfortable with [[Requires| Requires]] . +Before adding BuildRequires to any package, please be comfortable with [[#Requires| Requires]] . -There are two suggested ways of detecting missing BuildRequires. '''rpmdev-rmdevelrpms''' and '''mock'''. The first one is designed to remove all developer-related packages from your system. If the build fails or is missing certain features due to missing build dependencies, then the missing dependency needs to be found and added. Check the [[rmdevelrpms| rpmdev-rmdevelrpms]] section to find out more.
+There are two suggested ways of detecting missing BuildRequires. '''rpmdev-rmdevelrpms''' and '''mock'''. The first one is designed to remove all developer-related packages from your system. If the build fails or is missing certain features due to missing build dependencies, then the missing dependency needs to be found and added. Check the [[#rmdevelrpms| rpmdev-rmdevelrpms]] section to find out more.
'''mock''' is another good way to check build dependencies. Rather than remove all developer packages, it tries to build your package in a chroot. It makes no changes to your normal, daily environment and ensures that your package will build fine. However, '''mock''' may need a good internet connection to download all required packages. [[Extras/MockTricks| MockTricks]] page contains more information. Another mock-like tool, '''mach''' is also available in the Fedora repository. {{Anchor|rmdevelrpms}} === rpmdev-rmdevelrpms === -'''rpmdev-rmdevelrpms''' script within the ["rpmdevtools"] toolkit is a script written by Ville Skyttä that helps RPM packagers in finding missing BuildRequires. Simply run it and allow it to remove all *-devel packages and build tools like this example. +'''rpmdev-rmdevelrpms''' script within the [[rpmdevtools]] toolkit is a script written by Ville Skyttä that helps RPM packagers in finding missing BuildRequires. Simply run it and allow it to remove all *-devel packages and build tools like this example. 
 [root@build-fc1 /] # rpmdev-rmdevelrpms
@@ -286,7 +286,7 @@ An example of this are the gettext and libgcj packages. gettext is usually a dev
 {{Anchor|Exceptions}}
 === Exceptions ===
 
-There is no need to include the following packages or their dependencies as BuildRequires because they would occur too often. These packages are considered the minimum build environment.  The derived list of all deps pulled in by this list is on ["Packaging/FullExceptionList"] .
+There is no need to include the following packages or their dependencies as BuildRequires because they would occur too often. These packages are considered the minimum build environment.  The derived list of all deps pulled in by this list is on [[Packaging/FullExceptionList]] .
 
 
 bash
@@ -315,6 +315,7 @@ which
 

 
 {{Anchor|summary}}
+
 == Summary and description ==
 The summary should be a short and concise description of the package. The description expands upon this. Do not include installation instructions in the description; it is not a manual. If the package requires some manual configuration or there are other important instructions to the user, refer the user to the documentation in the package. Add a ''README.Fedora'', or similar, if you feel this is necessary. Also, please make sure that there are no lines in the description longer than 80 characters.
 

From ca61e88f88558ab7edb61db5ef9a9668bb3e6a71 Mon Sep 17 00:00:00 2001
From: Timlau 
Date: May 26 2008 14:37:31 +0000
Subject: [PATCH 77/3559] fixed links


---

diff --git a/Packaging:Guidelines.mw b/Packaging:Guidelines.mw
index 6205fce..858a020 100644
--- a/Packaging:Guidelines.mw
+++ b/Packaging:Guidelines.mw
@@ -126,12 +126,13 @@ You must use one of the following formats:
 == Tags ==
 *The ''Packager'' tag should not be used in spec files. The identities of the packagers are evident from the changelog entries. By not using the ''Packager'' tag, you also avoid seeing bad binaries rebuilt by someone else with your name in the header.  See also the '''Maximum RPM definition of the Packager tag''' at [http://www.rpm.org/max-rpm/s1-rpm-inside-tags.html#S3-RPM-INSIDE-PACKAGER-TAG www.rpm.org] .  If you need to include information about the packager in the rpms ''you'' built, use %packager in your ~/.rpmmacros instead.
 *The ''Vendor'' tag should not be used. It is set automatically by the build system.
-*The ''Copyright'' tag is deprecated. Use the ''License'' tag instead, as detailed in ["Packaging/LicensingGuidelines"] . Contact the upstream author if there is any doubt about what license the software is distributed under.
+*The ''Copyright'' tag is deprecated. Use the ''License'' tag instead, as detailed in [[Packaging/LicensingGuidelines]] . Contact the upstream author if there is any doubt about what license the software is distributed under.
 *The ''Summary'' tag value should not end in a period. If this bothers you from a grammatical point of view, sit down, take a deep breath, and get over it.
 *Usually, the ''PreReq'' tag should be replaced by plain ''Requires''.   For more info, see Maximum RPM snapshot's  [http://www.rpm.org/max-rpm-snapshot/s1-rpm-depend-manual-dependencies.html#S3-RPM-DEPEND-FINE-GRAINED fine grained dependencies chapter] .
-* The ''Source'' tag documents where to find the upstream sources for the rpm.  In most cases this should be a complete URL to the upstream tarball.  For special cases, please see the ["Packaging/SourceURL"]  Guidelines
+* The ''Source'' tag documents where to find the upstream sources for the rpm.  In most cases this should be a complete URL to the upstream tarball.  For special cases, please see the [[Packaging/SourceURL]]  Guidelines
 
 {{Anchor|BuildRoot}}
+
 == BuildRoot tag ==
 
 The ''!BuildRoot'' value MUST be below %{_tmppath}/ and MUST contain at least %{name}, %{version} and %{release}. It may invoke mktemp since this is guaranteed to exist on every system. From there, packagers are expected to use a sane ''!BuildRoot''.

From b333e9f9875d7724a2c630df2b47fe80aaa2ef9f Mon Sep 17 00:00:00 2001
From: Orion 
Date: May 27 2008 22:05:11 +0000
Subject: [PATCH 78/3559] /* GCJ */


---

diff --git a/Packaging:Java.mw b/Packaging:Java.mw
index 4c236e2..891d8df 100644
--- a/Packaging:Java.mw
+++ b/Packaging:Java.mw
@@ -137,7 +137,7 @@ run "$@"
=== GCJ === -Please refer to ["Packaging/GCJGuidelines"] for GCJ-specific guidelines. +Please refer to [[Packaging/GCJGuidelines]] for GCJ-specific guidelines. === -devel packages === -devel packages don't really make sense for Java packages. Header files do not exist for Java packages. From ea1340ba7a20a9144815dd4c3d87d99f1daef05e Mon Sep 17 00:00:00 2001 From: Overholt Date: May 28 2008 13:25:46 +0000 Subject: [PATCH 79/3559] /* Glossary */ --- diff --git a/Packaging:EclipsePlugins.mw b/Packaging:EclipsePlugins.mw index e6c1cbf..7ee258e 100644 --- a/Packaging:EclipsePlugins.mw +++ b/Packaging:EclipsePlugins.mw @@ -5,8 +5,8 @@ == Glossary == -* '''Plugin,,1,,''': A functional unit of Eclipse functionality. Post-Eclipse 3.0, the term "plugin" can almost always be interchanged with the term "bundle" which itself is shorthand for "OSGi bundle". -* '''Plugin,,2,,''': The colloquial name given to a set of functional Eclipse plugins ex. "CDT". More common usage among non-Eclipse developers than the above definition. +* '''Plugin1''': A functional unit of Eclipse functionality. Post-Eclipse 3.0, the term "plugin" can almost always be interchanged with the term "bundle" which itself is shorthand for "OSGi bundle". +* '''Plugin2''': The colloquial name given to a set of functional Eclipse plugins ex. "CDT". More common usage among non-Eclipse developers than the above definition. * '''Feature''': A collection of plugin,,1,,s. * '''Fragment''': A bundle with native elements ex. org.eclipse.core.filesystem.linux.${arch} From c27d3a6579706359d7e89e89dcc8d2e49ccb6dee Mon Sep 17 00:00:00 2001 From: Overholt Date: May 28 2008 13:26:01 +0000 Subject: [PATCH 80/3559] /* Glossary */ --- diff --git a/Packaging:EclipsePlugins.mw b/Packaging:EclipsePlugins.mw index 7ee258e..592f211 100644 --- a/Packaging:EclipsePlugins.mw +++ b/Packaging:EclipsePlugins.mw @@ -7,7 +7,7 @@ == Glossary == * '''Plugin1''': A functional unit of Eclipse functionality. Post-Eclipse 3.0, the term "plugin" can almost always be interchanged with the term "bundle" which itself is shorthand for "OSGi bundle". * '''Plugin2''': The colloquial name given to a set of functional Eclipse plugins ex. "CDT". More common usage among non-Eclipse developers than the above definition. -* '''Feature''': A collection of plugin,,1,,s. +* '''Feature''': A collection of plugin1s. * '''Fragment''': A bundle with native elements ex. org.eclipse.core.filesystem.linux.${arch} == Introduction == From 1260500e9a938bc6f7081977a955d9ebe6179a7e Mon Sep 17 00:00:00 2001 From: Overholt Date: May 28 2008 13:26:45 +0000 Subject: [PATCH 81/3559] /* Jar file naming */ --- diff --git a/Packaging:Java.mw b/Packaging:Java.mw index 891d8df..ab74c8c 100644 --- a/Packaging:Java.mw +++ b/Packaging:Java.mw @@ -27,24 +27,24 @@ For now, refer to the ["Packaging/JPackagePolicy"] for release tags. That docu === Jar file naming === -1. If a package provides a single JAR file it must have the same name as the package itself. +# If a package provides a single JAR file it must have the same name as the package itself. ex. jaf.jar -1. If the project name and the commonly used JAR filename differ, a symbolic link with the usual name must also be provided. +# If the project name and the commonly used JAR filename differ, a symbolic link with the usual name must also be provided. ex. Single JAR complete naming. Project name is jaf, common name is activation. activation.jar ’ jaf.jar -1. If the package provides several JAR files, the filenames assigned by the build must be used. Above symlinking rules apply. +# If the package provides several JAR files, the filenames assigned by the build must be used. Above symlinking rules apply. ex. 
ant-1.5.3.jar
 ant-optional-1.5.3.jar
-1. If the number of provided JAR files exceeds '''two''', you must place them into a sub-directory. +# If the number of provided JAR files exceeds '''two''', you must place them into a sub-directory. -1. If a project offers the choice of packaging it as a single monolithic jar or several ones, the split packaging should be preferred. +# If a project offers the choice of packaging it as a single monolithic jar or several ones, the split packaging should be preferred. === Directory structure === All JAR files '''MUST''' go into %{_javadir}. Exceptions include [[JNI| JNI-using JAR files]] , and application-specific JAR files (ie. JAR files that can only reasonably be used as part of an application and therefore constitute application-private data). From 9fb88d9574554da4f6ead012acdec81d3854d9b0 Mon Sep 17 00:00:00 2001 From: Spot Date: May 28 2008 13:55:13 +0000 Subject: [PATCH 82/3559] /* Action Items */ --- diff --git a/Packaging:GuidelinesTodo.mw b/Packaging:GuidelinesTodo.mw index 8d6e576..e33ec90 100644 --- a/Packaging:GuidelinesTodo.mw +++ b/Packaging:GuidelinesTodo.mw @@ -15,7 +15,7 @@ Status should be one of: |- |writeup||!DesktopVerify||caillon||2008-05-06||["PackagingDrafts/DesktopVerify"] |- -|ratify||Withdraw the JPackage Naming Exception||spot||2008-05-20||["Packaging/JPackagePolicy"] +|writeup||Withdraw the JPackage Naming Exception||spot||2008-05-20||["Packaging/JPackagePolicy"] |} {{:PackagingDrafts/DraftsTodo}} From cdb7561325abb642a23adf3105b7d05b1f2c338c Mon Sep 17 00:00:00 2001 From: Toshio Date: Jun 01 2008 19:47:17 +0000 Subject: [PATCH 83/3559] Add links to cmake documentation --- diff --git a/Packaging:Cmake.mw b/Packaging:Cmake.mw index 4d473a5..645c813 100644 --- a/Packaging:Cmake.mw +++ b/Packaging:Cmake.mw @@ -54,3 +54,7 @@ ctest Nevertheless, RPATH issues might arise when cmake was used improperly. E.g. installing a target with INSTALL(FILES ... RENAME ...) will '''not''' strip rpaths; in this case INSTALL(TARGETS ...) must be used in combination with changing the OUTPUT_NAME property. '''NOTE''': The proposed %cmake macro defines -DLIB_SUFFIX=64 on 64bit platforms. Not all packages handle this gracefully. The kdesvn package, for example, included cmake files taken from the KDE upstream that needed to be patched for this to work properly for all files (esp. .la files for loadable KDE modules). You might want to see the patch included in the kdesvn .src.rpm for example changes. + +'''NOTE''': cmake has good documentation in two places: +* http://www.cmake.org/HTML/Documentation.html +* http://www.cmake.org/Wiki/CMake From ec2841e1e574b6905dbad1b47e5dba4cfea5e44f Mon Sep 17 00:00:00 2001 From: Rdieter Date: Jun 03 2008 14:36:39 +0000 Subject: [PATCH 84/3559] /* Possible values for %{dist} */ --- diff --git a/Packaging:DistTag.mw b/Packaging:DistTag.mw index 9438ac7..5422b20 100644 --- a/Packaging:DistTag.mw +++ b/Packaging:DistTag.mw @@ -45,7 +45,7 @@ Red Hat Enterprise Linux: 4 (all variants): .el4 5 (all variants): .el5 -Fedora Core: +Fedora, Fedora Core: 1: .fc1 2: .fc2 3: .fc3 @@ -53,6 +53,9 @@ Fedora Core: 5: .fc5 6: .fc6 7: .fc7 +8: .fc8 +9: .fc9 +10: .fc10 Development: From ad710632d8b82364aeac267131c5431a0c839a32 Mon Sep 17 00:00:00 2001 From: Rdieter Date: Jun 03 2008 14:37:33 +0000 Subject: [PATCH 85/3559] /* Dist Tag Guidelines */ --- diff --git a/Packaging:DistTag.mw b/Packaging:DistTag.mw index 5422b20..5461413 100644 --- a/Packaging:DistTag.mw +++ b/Packaging:DistTag.mw @@ -6,9 +6,9 @@ These are the guidelines for using the %{dist} tag in Fedora. Using You should consider this document as an addendum to the ["Packaging/NamingGuidelines"] . '''Author:''' [[TomCallaway| Tom 'spot' Callaway]]
-'''Revision:''' 0.14
+'''Revision:''' 0.15
'''Initial Draft:''' Monday Mar 21, 2005
-'''Last Revised:''' Monday May 21, 2007
+'''Last Revised:''' Tuesday, June 03 2008
From e240e66d032f41da69ec2bc04065c31b6f07e509 Mon Sep 17 00:00:00 2001 From: Spot Date: Jun 03 2008 15:49:44 +0000 Subject: [PATCH 86/3559] /* Resolved items */ --- diff --git a/Packaging:GuidelinesTodo.mw b/Packaging:GuidelinesTodo.mw index e33ec90..af3bf30 100644 --- a/Packaging:GuidelinesTodo.mw +++ b/Packaging:GuidelinesTodo.mw @@ -184,9 +184,12 @@ Status should be one of: |CommitID ||JasonTibbitts ||2007-06-26||Allow upstream VCS commit ID to appear in alphatag [[PackagingDrafts/CommitIDs| ]] |} + {| border="1" |- ||||||style="color: white; background-color: #3074c2; font-weight: bold" |Rejected Items +|- style="color: white; background-color: #3074c2; font-weight: bold" +|Task Name||Owner||Resolution Date||Notes |- |Package Names should be all lowercase||abadger1999|| 2008-04-08 ||["PackagingDrafts/ASCIINamingLowercase"] |- From fa94b2cfe01f23d4c456fb3bf5af6fef3d1c5662 Mon Sep 17 00:00:00 2001 From: Spot Date: Jun 03 2008 15:50:36 +0000 Subject: [PATCH 87/3559] /* Resolved items */ --- diff --git a/Packaging:GuidelinesTodo.mw b/Packaging:GuidelinesTodo.mw index af3bf30..b30acc5 100644 --- a/Packaging:GuidelinesTodo.mw +++ b/Packaging:GuidelinesTodo.mw @@ -186,8 +186,7 @@ Status should be one of: {| border="1" -|- ||||||style="color: white; background-color: #3074c2; font-weight: bold" -|Rejected Items +! Rejected Items |- style="color: white; background-color: #3074c2; font-weight: bold" |Task Name||Owner||Resolution Date||Notes |- From df06ad4282bfa77fb6a18bfe9658cee2d2daa812 Mon Sep 17 00:00:00 2001 From: Spot Date: Jun 04 2008 02:26:07 +0000 Subject: [PATCH 88/3559] /* Dist Tag Guidelines */ --- diff --git a/Packaging:DistTag.mw b/Packaging:DistTag.mw index 5461413..5db5d52 100644 --- a/Packaging:DistTag.mw +++ b/Packaging:DistTag.mw @@ -3,9 +3,9 @@ = Dist Tag Guidelines = These are the guidelines for using the %{dist} tag in Fedora. Using the %{dist} tag is not mandatory, however, it is the only permitted mechanism for marking the distribution revision of a package. This isn't because any other method is broken or bad, but because we need a consistent standard in Fedora. -You should consider this document as an addendum to the ["Packaging/NamingGuidelines"] . +You should consider this document as an addendum to the [[Packaging/NamingGuidelines]] . -'''Author:''' [[TomCallaway| Tom 'spot' Callaway]]
+'''Author:''' [[User:Spot| Tom 'spot' Callaway]]
'''Revision:''' 0.15
'''Initial Draft:''' Monday Mar 21, 2005
'''Last Revised:''' Tuesday, June 03 2008
From 9181d4974abdc7f39501f80c40ab2185df721236 Mon Sep 17 00:00:00 2001 From: Spot Date: Jun 05 2008 14:37:14 +0000 Subject: [PATCH 89/3559] /* Package Review Process */ --- diff --git a/Packaging:ReviewGuidelines.mw b/Packaging:ReviewGuidelines.mw index 970fcee..367c8c7 100644 --- a/Packaging:ReviewGuidelines.mw +++ b/Packaging:ReviewGuidelines.mw @@ -9,9 +9,10 @@ This is a set of guidelines for Package Reviews. Note that a complete list of th '''Last Revised:''' Friday Nov 30, 2007
== Package Review Process == -Contributors and reviewers should follow the PackageReviewProcess. +Contributors and reviewers should follow the [[PackageReviewProcess]]. {{Anchor|ThingsToCheckOnReview}} + == Things To Check On Review == There are many many things to check for a review. This list is provided to assist new reviewers in identifying areas that they should look for, but is by no means complete. Reviewers should use their own good judgement when reviewing packages. The items listed fall into two categories: '''SHOULD''' and '''MUST'''. Items marked as '''SHOULD''' are things that the package (or reviewer) '''SHOULD''' do, but is not required to do. Items marked as '''MUST''' are things that the package (or reviewer) '''MUST''' do. If a package fails a '''MUST''' item, that is considered a blocker. No package with blockers can be approved on a review. Those items must be fixed before approval can be given. From f0c6b082f48d39e5247cbc72013d8aa8cbcf399f Mon Sep 17 00:00:00 2001 From: Tibbs Date: Jun 17 2008 17:26:52 +0000 Subject: [PATCH 90/3559] Add TeX naming guideline. --- diff --git a/Packaging:Naming.mw b/Packaging:Naming.mw index eeb6efb..36b895b 100644 --- a/Packaging:Naming.mw +++ b/Packaging:Naming.mw @@ -1,11 +1,9 @@ - = Package Naming Guidelines = '''Author:''' [[TomCallaway| Tom 'spot' Callaway]]
-'''Revision:''' 0.49
+'''Revision:''' 0.50
'''Initial Draft:''' Wednesday Feb 23, 2005
-'''Last Revised:''' Friday, April 25, 2008
+'''Last Revised:''' Tuesday, June 17, 2008
@@ -312,7 +310,6 @@ The new package ("child") should prepend the "parent" package in its name, in th gnome-applet-netmon (netmon applet for gnome, relies on gnome) php-adodb (adodb functionality for php, relies on php) python-twisted (the twisted module for python, relies on python) -tetex-arabtex (arabic functionality for tetex, relies on tetex) xmms-cdread (direct cd read functionality for xmms, relies on xmms) @@ -435,4 +432,10 @@ ttfonts-zh_TW (adds zh_TW locale fonts in ttfonts family) ttfonts-zh_CN (adds zh_CN locale fonts in ttfonts family) +{{Anchor|AddonTeX}} +== Addon Packages (TeX) == +As Fedora has switched TeX environments in the past, TeX packages should not +be named after the TeX environment (TeX Live or teTeX) but instead should +carry the prefix "tex-". + [[Category:Extras]] From 0e6778478e175630554271c03470d20640d3f029 Mon Sep 17 00:00:00 2001 From: Tibbs Date: Jun 17 2008 17:40:06 +0000 Subject: [PATCH 91/3559] PackageReviewProcess moved to Package Review Process --- diff --git a/Packaging:ReviewGuidelines.mw b/Packaging:ReviewGuidelines.mw index 367c8c7..1630045 100644 --- a/Packaging:ReviewGuidelines.mw +++ b/Packaging:ReviewGuidelines.mw @@ -9,7 +9,7 @@ This is a set of guidelines for Package Reviews. Note that a complete list of th '''Last Revised:''' Friday Nov 30, 2007
== Package Review Process == -Contributors and reviewers should follow the [[PackageReviewProcess]]. +Contributors and reviewers should follow the [[Package Review Process]]. {{Anchor|ThingsToCheckOnReview}} From a6aaf8acf968d901a0162af2d4b2f5f992421759 Mon Sep 17 00:00:00 2001 From: Tibbs Date: Jun 18 2008 04:04:11 +0000 Subject: [PATCH 92/3559] Repair content lost in the wiki migration. --- diff --git a/Packaging:SourceURL.mw b/Packaging:SourceURL.mw index 3410ee9..3122f2e 100644 --- a/Packaging:SourceURL.mw +++ b/Packaging:SourceURL.mw @@ -23,6 +23,10 @@ Here are some specific examples: In some cases you may want to pull sources from upstream's revision control system because there have been many changes since the last release and you think that a tarball that you generate from there will more accurately show how the package relates to upstream's development. Here's how you can use a comment to show where the source came from: 
+# The source for this package was pulled from upstream's vcs.  Use the
+# following commands to generate the tarball:
+#  svn export -r 250 http://www.example.com/svn/foo/trunk foo-20070221
+#  tar -czvf foo-20070221.tar.gz foo-20070221
 Source0: foo-20070221.tar.gz
@@ -37,6 +41,11 @@ Some upstream packages include patents or trademarks that we are not allowed to From the spec: 
 Source0: libfoo-1.0-nopatents.tar.gz
+# libfoo contains patented code that we cannot ship.  Therefore we use
+# this script to remove the patented code before shipping it.
+# Download the upstream tarball and invoke this script while in the
+# tarball's directory:
+# ./generate-tarball.sh 1.0
 Source1: generate-tarball.sh
@@ -59,6 +68,9 @@ tar -czvf libfoo-$VERSION-nopatents.tar.gz libfoo-$VERSION For some packages where we are the upstream authors, for instance, the system-config-* tools, the source rpm that we distribute is the canonical source of the files. There is no public revision control system or publically released tarball for these programs so there is no tarball to list. Add a comment like the following to the spec: 
+# This is a Red Hat maintained package which is specific to
+# our distribution.  Thus the source is only available from
+# within this srpm.
 Source0: system-config-foo-1.0.tar.gz
From f08d5aecf4c338868b2bec0c3a24cd820c93d32b Mon Sep 17 00:00:00 2001 From: Tibbs Date: Jun 18 2008 18:39:32 +0000 Subject: [PATCH 93/3559] Restore many wikilinks damaged by the wiki conversion. --- diff --git a/Packaging:Guidelines.mw b/Packaging:Guidelines.mw index 858a020..6fe1134 100644 --- a/Packaging:Guidelines.mw +++ b/Packaging:Guidelines.mw @@ -16,7 +16,7 @@ Please remember that any package that you submit must also conform to the [[Pack {{Anchor|Naming}} == Naming == -You should go through the ["Packaging/NamingGuidelines"] to ensure that your package is named appropriately. +You should go through the [Packaging/NamingGuidelines]] to ensure that your package is named appropriately. {{Anchor|Legal}} == Legal == @@ -50,7 +50,7 @@ Packages which require non-open source components to build are also not permitte {{Anchor|PackageFromScratch}} == Writing a package from scratch == -When writing a package from scratch, you should base your spec file on the Fedora spec file template (see ["rpmdevtools"] ). Please put your preferences about spec file formatting and organization aside, and try to conform to this template as much as possible. This is not because we believe this is the only right way to write a spec file, but because it often makes it easier for QA to spot mistakes and quickly understand what you are trying to do. +When writing a package from scratch, you should base your spec file on the Fedora spec file template (see [[Rpmdevtools]] ). Please put your preferences about spec file formatting and organization aside, and try to conform to this template as much as possible. This is not because we believe this is the only right way to write a spec file, but because it often makes it easier for QA to spot mistakes and quickly understand what you are trying to do. {{Anchor|ModifyingExistingPackage}} == Modifying an existing package == @@ -340,7 +340,7 @@ Compilers used to build packages should honor the applicable compiler flags set {{Anchor|Debuginfo}} == Debuginfo packages == -Packages should produce useful -debuginfo packages, or explicitly disable them when it is not possible to generate a useful one but rpmbuild would do it anyway. Whenever a -debuginfo package is explicitly disabled, an explanation why it was done is required in the specfile. Debuginfo packages are discussed in more detail in a separate document, ["Packaging/Debuginfo"] . +Packages should produce useful -debuginfo packages, or explicitly disable them when it is not possible to generate a useful one but rpmbuild would do it anyway. Whenever a -debuginfo package is explicitly disabled, an explanation why it was done is required in the specfile. Debuginfo packages are discussed in more detail in a separate document, [[Packaging/Debuginfo]] . {{Anchor|StaticLibraries}} == Exclusion of Static Libraries == @@ -435,7 +435,7 @@ Don't use %config or %config(noreplace) under /usr. /usr is deemed to not contai {{Anchor|Initscripts}} == Initscripts == -Currently, only SystemV-style initscripts are supported in Fedora. There are detailed guidelines for SysV-style initscripts here: ["Packaging/SysVInitScript"] +Currently, only SystemV-style initscripts are supported in Fedora. There are detailed guidelines for SysV-style initscripts here: [[Packaging/SysVInitScript]] {{Anchor|desktop}} == Desktop files == @@ -504,7 +504,7 @@ This is mostly for the sake of menu-editing (which bases off of .desktop file/pa {{Anchor|macros}} == Macros == -Use macros instead of hard-coded directory names (see ["Packaging/RPMMacros"] ). +Use macros instead of hard-coded directory names (see [[Packaging/RPMMacros]] ). Having macros in a Source: or Patch: line is a matter of style. Some people enjoy the ready readability of a source line without macros. Others prefer the ease of updating for new versions when macros are used. In all cases, remember to be consistent in your spec file and verify that the URLs you list are valid. spectool (from the rpmdevtools package) can aid you in checking that whether the URL contains macros or not. @@ -751,7 +751,7 @@ In all cases we are guarding against unowned directories being present on a syst {{Anchor|UsersAndGroups}} == Users and Groups == -Some packages require or benefit from dedicated runtime user and/or group accounts. Guidelines for handling these cases are in a separate ["Packaging/UsersAndGroups"] document. +Some packages require or benefit from dedicated runtime user and/or group accounts. Guidelines for handling these cases are in a separate [[Packaging/UsersAndGroups]] document. {{Anchor|WebApplications}} == Web Applications == @@ -765,7 +765,7 @@ Web applications packaged in Fedora should put their content into /usr/share/%{n {{Anchor|Conflicts}} == Conflicts == -Whenever possible, Fedora packages should avoid conflicting with each other. Unfortunately, this is not always possible. For full details on Fedora's Conflicts policy, see: ["Packaging/Conflicts"] . +Whenever possible, Fedora packages should avoid conflicting with each other. Unfortunately, this is not always possible. For full details on Fedora's Conflicts policy, see: [[Packaging/Conflicts]] . == No External Kernel Modules == {{:Packaging/KernelModules}} From 702c303ac5cc1ef13a41148d18ea0c6fee2d0ebd Mon Sep 17 00:00:00 2001 From: Tibbs Date: Jun 18 2008 18:58:04 +0000 Subject: [PATCH 94/3559] Missed a bracket. --- diff --git a/Packaging:Guidelines.mw b/Packaging:Guidelines.mw index 6fe1134..df77473 100644 --- a/Packaging:Guidelines.mw +++ b/Packaging:Guidelines.mw @@ -16,7 +16,7 @@ Please remember that any package that you submit must also conform to the [[Pack {{Anchor|Naming}} == Naming == -You should go through the [Packaging/NamingGuidelines]] to ensure that your package is named appropriately. +You should go through the [[Packaging/NamingGuidelines]] to ensure that your package is named appropriately. {{Anchor|Legal}} == Legal == From 9e0b41103c7bc620c87c58bf88ec7589a1221f56 Mon Sep 17 00:00:00 2001 From: Tibbs Date: Jun 18 2008 22:37:26 +0000 Subject: [PATCH 95/3559] Fix some links. --- diff --git a/Packaging:Java.mw b/Packaging:Java.mw index ab74c8c..017e886 100644 --- a/Packaging:Java.mw +++ b/Packaging:Java.mw @@ -20,10 +20,10 @@ The [http://www.jpackage.org JPackage Project] has defined standard file system === Package naming === -Packages '''MUST''' follow the standard Fedora ["Packaging/NamingGuidelines"] . Java API documentation '''MUST''' be placed into a sub-package called %{name}-javadoc. +Packages '''MUST''' follow the standard Fedora [[Packaging/NamingGuidelines]] . Java API documentation '''MUST''' be placed into a sub-package called %{name}-javadoc. ==== Release tags ==== -For now, refer to the ["Packaging/JPackagePolicy"] for release tags. That document should eventually be folded into this one. +For now, refer to the [[Packaging/JPackagePolicy]] for release tags. That document should eventually be folded into this one. === Jar file naming === From 304e4b83593f163ba3a1e8b27cee9d05e9fe056f Mon Sep 17 00:00:00 2001 From: Tibbs Date: Jun 18 2008 22:39:18 +0000 Subject: [PATCH 96/3559] Fix another broken link. --- diff --git a/Packaging:Guidelines.mw b/Packaging:Guidelines.mw index df77473..96f34ad 100644 --- a/Packaging:Guidelines.mw +++ b/Packaging:Guidelines.mw @@ -46,7 +46,7 @@ Packages which require non-open source components to build are also not permitte {{Anchor|SourceRequirementExceptions}} === Exceptions === * Some software (usually related to compilers or cross-compiler environments) cannot be build without the use of a previous toolchain or development environment (open source). If you have a package which meets this criteria, contact the Fedora Packaging Committee for approval. -* An exception is made for binary firmware, as long as it meets the requirements documented here: [wiki:Self:Packaging/LicensingGuidelines#BinaryFirmware BinaryFirmware] +* An exception is made for binary firmware, as long as it meets the requirements documented here: [[Packaging/LicensingGuidelines#BinaryFirmware BinaryFirmware]] {{Anchor|PackageFromScratch}} == Writing a package from scratch == From 91c8f178cb08393ea06782c646ead3227a9385a0 Mon Sep 17 00:00:00 2001 From: Tibbs Date: Jun 24 2008 19:25:20 +0000 Subject: [PATCH 97/3559] Copied from the accepted draft. --- diff --git a/Packaging:PatchUpstreamStatus.mw b/Packaging:PatchUpstreamStatus.mw new file mode 100644 index 0000000..8a8f48c --- /dev/null +++ b/Packaging:PatchUpstreamStatus.mw @@ -0,0 +1,44 @@ +== All patches should have an upstream bug link or comment == + +All patches in Fedora spec files '''SHOULD''' have a comment above them about their upstream status. Any time you create a patch, it is best practice to file it in an upstream bug tracker, and include a link to that in the comment above the patch. For example: + +
+# http://bugzilla.gnome.org/show_bug.cgi?id=12345
+Patch0: gnome-panel-fix-frobnicator.patch
+
+ +The above is perfectly acceptable; but if you prefer, a brief comment about what the patch does above can be helpful: + +
+# Don't crash with frobnicator applet
+# http://bugzilla.gnome.org/show_bug.cgi?id=12345
+Patch0: gnome-panel-fix-frobnicator.patch
+
+ +Sending patches upstream and adding this comment will help ensure that Fedora is acting as a good FLOSS citizen (see [[PackageMaintainers/WhyUpstream| Why Upstream?]] ). It will help others (and even you) down the line in package maintenance by knowing what patches are likely to appear in a new upstream release. + +=== If upstream doesn't have a bug tracker === +You can indicate that you have sent the patch upstream and any known status: + +
+# Sent upstream via email 20080407
+Patch0: foobar-fix-the-bar.patch
+
+ + +
+# Upstream has applied this in SVN trunk
+Patch0: foobar-fix-the-baz.patch
+
+ +=== Fedora-specific (or rejected upstream) patches === +It may be that some patches truly are Fedora-specific; in that case, say so: + +
+# This patch is temporary until we land the long term System.loadLibrary fix in OpenJDK
+Patch0: jna-jni-path.patch
+
+ += Why upstream? = + +Refer [[PackageMaintainers/WhyUpstream| Why Upstream?]] From 932d4fcd524e8ee9c37aad8a4f8bcaef745bc0d2 Mon Sep 17 00:00:00 2001 From: Tibbs Date: Jun 27 2008 17:50:29 +0000 Subject: [PATCH 98/3559] gem2spec is obsolete; point to gem2rpm instead. --- diff --git a/Packaging:Ruby.mw b/Packaging:Ruby.mw index e3608fd..a7d7da8 100644 --- a/Packaging:Ruby.mw +++ b/Packaging:Ruby.mw @@ -1,4 +1,3 @@ - = Ruby Packaging Guidelines = @@ -92,4 +91,4 @@ Provides: ruby(active_support) = %version # The underscore is intentional, not === Tips for Packagers === -Gems carry a lot of metadata; [http://people.redhat.com/dlutter/gem2spec.html Gem2Spec] is a tool to generate an initial specfile and/or source RPM from a Gem. The generated specfile still needs some hand-editing, but conforms to 90% with this guideline. +Gems carry a lot of metadata; [http://rubyforge.org/projects/gem2rpm/ gem2rpm] is a tool to generate an initial specfile and/or source RPM from a Gem. The generated specfile still needs some hand-editing, but conforms to 90% with this guideline. From 4598588b4e14c267e20c65fa2ff3572a59cbc5b8 Mon Sep 17 00:00:00 2001 From: Tibbs Date: Jun 27 2008 19:40:41 +0000 Subject: [PATCH 99/3559] Fix some wiki conversion damage. --- diff --git a/Packaging:GCJGuidelines.mw b/Packaging:GCJGuidelines.mw index 5602298..2633115 100644 --- a/Packaging:GCJGuidelines.mw +++ b/Packaging:GCJGuidelines.mw @@ -49,7 +49,8 @@ fi * For packages in which all JAR files are in one subpackage, the Requires(), %post, %postun and %files lines should refer to that subpackage. -* For packages in which more than one subpackage (including the main package) contains JAR files, then each subpackage should have its own Requires(), %post and %postun lines, and the %files lists should be split such that the subpackage that contains /path/to/foo-x.y.z.jar should have the following %files line:
+* For packages in which more than one subpackage (including the main package) contains JAR files, then each subpackage should have its own Requires(), %post and %postun lines, and the %files lists should be split such that the subpackage that contains /path/to/foo-x.y.z.jar should have the following %files line:
+
 %if %{with_gcj}
 %attr(-,root,root) %{_libdir}/gcj/%{name}/foo-x.y.z.jar.*
 %endif

From 7702e387f6bea096f84aa2b15a9be572c72a705c Mon Sep 17 00:00:00 2001
From: Tibbs 
Date: Jun 29 2008 18:47:00 +0000
Subject: [PATCH 100/3559] Moved "comments" block to the talk page where people can actually edit them.


---

diff --git a/Packaging:Java.mw b/Packaging:Java.mw
index 017e886..2f1780d 100644
--- a/Packaging:Java.mw
+++ b/Packaging:Java.mw
@@ -393,39 +393,3 @@ Use sed to remove class-path elements in MANIFES
 sed -i '/class-path/I d' META-INF/MANIFEST.MF
 

 '''Will this preserve the line ending as the [http://java.sun.com/docs/books/tutorial/deployment/jar/downman.html this page]  says it must?'''
-
-== Comments ==
-
-- Which version of java should stuff be built for?  Probably 1.5 (for gcj) if possible?  Should mention something about this.  (VilleSkyttä)
-
-- I think referencing the GCJ Guidelines, which say the package should build on GCJ, is sufficient, since building on GCJ implies building on 1.5.  In general packages should build against/require whatever Java version upstream uses. (ThomasFitzsimmons)
-
-- Referring to GCJ guidelines would work for me, but the 1.5 issue needs to be explicitly mentioned there, it's not clear to everyone. (VilleSkyttä)
-
-- "Requires: java" should have a version in it (depending on which version of java it was built for).  Possibly also depend on jre instead of java (maybe this is just cosmetic)?  (VilleSkyttä)
-
-- Agreed.  I removed the conditional brackets around >= specific_version.  I think we should just stick with "java" and not bother with "jre", since that's how it's been done in the past. (ThomasFitzsimmons)
-
-- Thanks.  Spec templates still have the unversioned form, though. (VilleSkyttä)
-
-- Drop versioned jars and install only unversioned ones?  https://www.redhat.com/archives/fedora-devel-list/2008-March/msg02346.html  (VilleSkyttä)
-
-- Fine by me. (ThomasFitzsimmons)
-
-- For users attempting to introduce a new Java package, we should tell them to first check if the package exists on JPackage (JPackage.org). JPackage packages follow a large majority of the guidelines in this draft, and thus importing should be fairly easy. Additionally, having a package in sync with JPackage will prevent potential incompatibility issues with other JPackage packages. (DeepakBhole)
-
-- Would we want that to be a '''should''' or a '''must'''?  In other words, if a packager wants to deviate from the JPackage package but still falls within the Guidelines do we want to allow them that freedom?
-
-- My one major issue with this Guideline is the use of "canonical document" in the header for "Java Packaging".  We do have other Guidelines that point to external sources for additional sources but they are targeted pieces (For instance, make sure .desktop files provided by the package follow the freedesktop spec [LINK to spec] ).  The Java Guidelines are broader and also have an overlay of information (saying that the JPackage Guidelines are the "canonical document" seems to mean "follow the JPackage Guidelines except where the Fedora Guidelines differ").  This makes it harder for a reviewer to understand what's going on in a package that they attempt to review because they need to keep flipping between two Guidelines and trying to remember where one differs from another.  It would be better organization if the Java Guidelines took one of the following approaches:  1) Major concerns listed in the Fedora Guidelines.  Specifics point to the relevant section of the JPackage Guidelines.  For instance:
-
-=== Jar File Naming ===
-Jar files must be named after the package name using the [http://www.jpackage.org/cgi-bin/viewvc.cgi/src/jpackage-utils/doc/jpackage-1.5-policy.xhtml?revision=HEAD&root=jpackage#id2434750 JPackage Jar File Naming Guideline] 
-

-For something that differs we could note the derivation and that our Guidelines take precedence:
-
-=== Jar File Naming ===
-Our rules are derived from the [http://www.jpackage.org/cgi-bin/viewvc.cgi/src/jpackage-utils/doc/jpackage-1.5-policy.xhtml?revision=HEAD&root=jpackage#id2434750 JPackage Guidelines] 
-but we don't use versioned names for jars.  Please use the following rules instead:
-[...] 
-

-The alternative to this would be to have people read the entirety of the JPackage Guidelines and then point out the places that we differ.  We would probably want to do that by importing the JPackage Guidelines to the wiki and annotating the few cases where we differ.  Note that we would probably want to decide whether resyncing when JPackage changes a Guidelines be done automatically or if the new version had to be brought in through FPC -> FESCo approval.  We would also need someone from the Java team to do that resyncing as we might otherwise be unaware of the changes.

From b76cc58ce29d0cc8580a5561a679a0ef3d85ac38 Mon Sep 17 00:00:00 2001
From: Spot 
Date: Jul 10 2008 16:46:20 +0000
Subject: [PATCH 101/3559] *Empty MediaWiki Message*


---

diff --git a/Packaging:FontsPolicy.mw b/Packaging:FontsPolicy.mw
index 2e490ba..751d9ac 100644
--- a/Packaging:FontsPolicy.mw
+++ b/Packaging:FontsPolicy.mw
@@ -1,17 +1,13 @@
-
-= Fonts packaging policy =
-
-
+{{CompactHeader|fonts-sig}}
 
 == Legal considerations ==
 
-The FLOSS font scene is still too young to have evolved common licensing conventions. As a result packaging fonts will often require more legal work than packaging your average FLOSS app. Before you continue, check our [[SIGs/Fonts/Legal|  legal page]] .
+The FLOSS font scene is still too young to have evolved common licensing conventions. As a result packaging fonts will often require more legal work than packaging your average FLOSS app. Before you continue, check our [[Legal_considerations_for_fonts| legal page]].
 
 {{Anchor|build-from-sources}}
 == Building from sources ==
 
-Fonts '''SHOULD''' be built from source whenever upstream provides them in a source format[[FootNote(As documented in our general ]] .)  . Automating the build ensures we'll be able to fix the fonts when problems are reported and upstream is not responsive. Sometimes that means working with upstream to sanitize its build processes.
+Fonts '''SHOULD''' be built from source whenever upstream provides them in a source formatAs documented in our general [[Packaging/Guidelines#SourceRequirementExceptions|packaging guidelines]].. Automating the build ensures we'll be able to fix the fonts when problems are reported and upstream is not responsive. Sometimes that means working with upstream to sanitize its build processes.
 
 {{Anchor|no-handler-deps}}
 == Install-time dependencies ==
@@ -25,7 +21,7 @@ Likewise, installation of stack-specific configuration files is allowed, if they
 {{Anchor|no-new-core-fonts}}
 == Core fonts ==
 
-Once upon a time every Linux GUI application used the so-called ''Core fonts'' server-side X11 backend[[FootNote(Fonts accessed through the original ''core'' X protocol, using tools like ''mkfontdir'', ''xfs'', ''/etc/X11/fontpath.d/'', ''XLFD'' strings, etc. See also this [http://keithp.com/~keithp/talks/xtc2001/paper/ paper]  written shortly before projects massively migrated to client-side fonts.)  . It was riddled with problems. The FLOSS developers finally gave up on it, declared it legacy and broken by design, and moved to client-side font handling (''fontconfig''). Nowadays almost no modern Linux GUI application uses the ''Core fonts'' backend. Few (if any) people are willing to fix its remaining bugs.
+Once upon a time every Linux GUI application used the so-called ''Core fonts'' server-side X11 backendFonts accessed through the original ''core'' X protocol, using tools like ''mkfontdir'', ''xfs'', ''/etc/X11/fontpath.d/'', ''XLFD'' strings, etc. See also this [http://keithp.com/~keithp/talks/xtc2001/paper/ paper] written shortly before projects massively migrated to client-side fonts.. It was riddled with problems. The FLOSS developers finally gave up on it, declared it legacy and broken by design, and moved to client-side font handling (''fontconfig''). Nowadays almost no modern Linux GUI application uses the ''Core fonts'' backend. Few (if any) people are willing to fix its remaining bugs.
 
 Therefore, unless your font has previously been registered in ''Core fonts'', and the problems triggered by this font hopefully fixed, you '''SHOULD NOT''' declare it there. This is especially true of fonts in modern (TTF or OTF) formats.
 
@@ -34,6 +30,7 @@ The users of this legacy backend won't thank you for destabilizing it with new f
 {{Anchor|grouping}}
 == Grouping ==
 
-{{:PackagingDrafts/FontsComps}}
+{{:Comps_fonts_rules}}
 
-----
+{{:Fonts_SIG_signature}}
+[[Category:Fonts packaging|Packaging policy]]

From ed5007162cc2164a036fd3c892e3a9d13f677f31 Mon Sep 17 00:00:00 2001
From: Spot 
Date: Jul 11 2008 16:39:56 +0000
Subject: [PATCH 102/3559] /* Package Version */


---

diff --git a/Packaging:Naming.mw b/Packaging:Naming.mw
index 36b895b..8dcdc71 100644
--- a/Packaging:Naming.mw
+++ b/Packaging:Naming.mw
@@ -104,7 +104,7 @@ There are four cases where the version contains non-numeric characters:
 
 * Snapshot packages: Packages built from cvs or subversion snapshots. These packages could be either "pre" or "post" release packages. Details can be found here: [[#NonNumericRelease|  Non-Numeric Version in Release]] 
 
-* JPackage derived Fedora packages: Packages which derive from JPackage RPMS follow a special policy. Details can be found here: [wiki:Self:Packaging/JPackagePolicy JPackagePolicy] 
+* JPackage derived Fedora packages: Packages which derive from JPackage RPMS follow a special policy. Details can be found here: [[Packaging/JPackagePolicy|JPackagePolicy]] 
 
 {{Anchor|PackageRelease}}
 

From c3f9e5a3b23d5d8860f8f4fdcffac71558db942a Mon Sep 17 00:00:00 2001
From: Spot 
Date: Jul 11 2008 16:52:09 +0000
Subject: [PATCH 103/3559] *Empty MediaWiki Message*


---

diff --git a/Packaging:JPackagePolicy.mw b/Packaging:JPackagePolicy.mw
index e5cde61..170a9da 100644
--- a/Packaging:JPackagePolicy.mw
+++ b/Packaging:JPackagePolicy.mw
@@ -3,38 +3,30 @@
 = Subrelease Packaging Guidelines for JPackage RPMS =
 
 '''Author:''' [[TomCallaway|  Tom 'spot' Callaway]] 

-'''Revision:''' 0.05

+'''Revision:''' 0.06

 '''Initial Draft:''' Tuesday Jan 16, 2007

-'''Last Revised:''' Monday Feb 12, 2007

-
+'''Last Revised:''' Friday Jul 11, 2008

 
+{{Admon/warning | These guidelines have changed significantly since 0.05. An archived copy of the old guidelines is here: [[OldJPackagePolicy]].}}
 
 == Summary ==
-Fedora includes a set of open source Java RPM packages that originate from the JPackage repository (www.jpackage.org). Currently, these packages are marked with a "jpp" tag:
+Fedora includes a set of open source Java RPM packages that originate from the JPackage repository (www.jpackage.org). 
 
 
 javacc-4.0-3jpp.3.src.rpm
 

 
-These packages are rebuilt against Fedora's gcc and included in Fedora. They use the "jpp" tag for three main technical reasons:
-
-* to help manage upgrading packages from Fedora to JPackage and back
-* to track package hierarchy (this Fedora Java package came from that JPackage Java package)
-* to help the Red Hat Java packagers perform grouped operations on all the Java packages
-
-== Proposal ==
-Normally, this use of the "jpp" tag would violate the [wiki:Self:Packaging/NamingGuidelines Fedora Package Naming Guidelines] .
-
-In order to reach a compromise, the following guidelines have been drafted:
+Fedora does not permit "repotags" in its packages. It is necessary to remove the "jpp" component in the Fedora version of these packages.
+Some additional guidelines have been drafted for these packages.
 
 === Managing upgrading packages from Fedora to JPackage and back ===
 According to Fernando Nasser, JPackage RPMS only use integers in the Release: field, in the format Xjpp. If this is the case, then the following format will ensure clean upgrades from Fedora to JPackage and so forth:
 
-JPackage RPMS have a Release of Xjpp (e.g. 1jpp). Fedora RPMS (which are taken from JPackage) will have a Release that takes the JPackage Release (Xjpp), and appends a subrelease integer (Y) after the jpp tag. This will make the Fedora Java packages have a Release of: Xjpp.Y (e.g. 1jpp.1).
+JPackage RPMS have a Release of Xjpp (e.g. 1jpp). Fedora RPMS (which are taken from JPackage) will have a Release that takes the JPackage Release (Xjpp), removes the repotag (jpp) and appends a subrelease integer (Y). This will make the Fedora Java packages have a Release of: X.Y (e.g. 1.1).
 
-While the Fedora package is in the devel branch, only the subrelease is incremented (e.g. 1jpp.2, 1jpp.3) until a new package from JPackage (e.g 2jpp) is merged into Fedora, at which point, the release would change to match the new JPackage RPM, and the subrelease would reset to 1.
+While the Fedora package is in the devel branch, only the subrelease is incremented (e.g. 1.2, 1.3) until a new package from JPackage (e.g 2jpp) is merged into Fedora, at which point, the release would change to match the new JPackage RPM (without the repotag), and the subrelease would reset to 1.
 
-Normally, we'd give the packager the choice of using '%{?dist}' or bumping the release to ensure clean upgrades across Fedora releases, but since we're trying to ensure hierarchy and upgrades from the JPackage repository, in this special case, use of the '%{?dist}' tag is mandatory. It would go at the end of the Release: field, (e.g. 1jpp.1%{?dist})
+Normally, we'd give the packager the choice of using '%{?dist}' or bumping the release to ensure clean upgrades across Fedora releases, but since we're trying to ensure hierarchy and upgrades from the JPackage repository, in this special case, use of the '%{?dist}' tag is mandatory. It would go at the end of the Release: field, (e.g. 1.1%{?dist})
 
 Once the Fedora package is out of the devel branch and into a released branch, the release and subrelease fields are frozen. These packages are now subject to the [wiki:Self:NamingGuidelines#DistBump Minor release bumps for old branches]  rule.
 
@@ -42,26 +34,26 @@ Once the Fedora package is out of the devel branch and into a released branch, t
 |-
 | '''JPackage'''           || '''Fedora Package'''          || '''Status'''                                          || '''Highest RPMver'''
 |-
-| javacc-4.0-3jpp.src.rpm  || javacc-4.0-3jpp.1.fc7.src.rpm || Package merged from JPackage into Fedora devel        || Fedora
+| javacc-4.0-3jpp.src.rpm  || javacc-4.0-3.1.fc7.src.rpm || Package merged from JPackage into Fedora devel        || Fedora
 |-
-| javacc-4.0-3jpp.src.rpm  || javacc-4.0-3jpp.2.fc7.src.rpm || Fedora package has a bug fixed, bump subrelease       || Fedora
+| javacc-4.0-3jpp.src.rpm  || javacc-4.0-3.2.fc7.src.rpm || Fedora package has a bug fixed, bump subrelease       || Fedora
 |-
-| javacc-4.0-3jpp.src.rpm  || javacc-4.0-3jpp.3.fc7.src.rpm || Fedora package is rebuilt for new gcc, bump subrel    || Fedora
+| javacc-4.0-3jpp.src.rpm  || javacc-4.0-3.3.fc7.src.rpm || Fedora package is rebuilt for new gcc, bump subrel    || Fedora
 |-
-| javacc-4.0-4jpp.src.rpm  || javacc-4.0-3jpp.3.fc7.src.rpm || JPackage is updated to fix a bug, bumps major release || JPackage
+| javacc-4.0-4jpp.src.rpm  || javacc-4.0-3.3.fc7.src.rpm || JPackage is updated to fix a bug, bumps major release || JPackage
 |-
-| javacc-4.0-4jpp.src.rpm  || javacc-4.0-4jpp.1.fc7.src.rpm || Fedora package is merged from new JPackage            || Fedora
+| javacc-4.0-4jpp.src.rpm  || javacc-4.0-4.1.fc7.src.rpm || Fedora package is merged from new JPackage            || Fedora
 |-
-| javacc-5.0-1jpp.src.rpm  || javacc-4.0-4jpp.1.fc7.src.rpm || JPackage releases new version of package              || JPackage
+| javacc-5.0-1jpp.src.rpm  || javacc-4.0-4.1.fc7.src.rpm || JPackage releases new version of package              || JPackage
 |-
-| javacc-5.0-1jpp.src.rpm  || javacc-5.0-1jpp.1.fc7.src.rpm || Fedora package is merged from new JPackage            || Fedora
+| javacc-5.0-1jpp.src.rpm  || javacc-5.0-1.1.fc7.src.rpm || Fedora package is merged from new JPackage            || Fedora
 |-
-| javacc-5.0-1jpp.src.rpm  || javacc-5.0-1jpp.1.fc7.src.rpm || FC-7 is released, package is no longer in devel       || Fedora
+| javacc-5.0-1jpp.src.rpm  || javacc-5.0-1.1.fc7.src.rpm || FC-7 is released, package is no longer in devel       || Fedora
 |-
-| javacc-5.0-1jpp.src.rpm  || javacc-5.0-1jpp.1.fc7.1.src.rpm || A bug is fixed in the FC-7 package.                 || Fedora
+| javacc-5.0-1jpp.src.rpm  || javacc-5.0-1.1.fc7.1.src.rpm || A bug is fixed in the FC-7 package.                 || Fedora
 |}
 
-This methodology ensures a clean upgrade process. It also ensures that when the "jpp" tag is removed, the upgrade process is unaffected. This is, however, a violation of the naming policy around releases, and is only permitted in this special case exception for Fedora Java packages from JPackage.
+This methodology ensures a clean upgrade process. This is, however, a violation of the naming policy around releases, and is only permitted in this special case exception for Fedora Java packages from JPackage.
 
 ==== Pre-release Packages ====
 JPackage has a Release standard of: 0.X.tag.Yjpp for prerelease packages. Tag is where the alpha/beta/CVS/SVN/etc tag goes, X is an integer incremented upon tag changes, and Y is an integer which increments only for packaging fixes, plain rebuilds etc. This is based on Fedora's pre-release naming standards. The same Subrelease policy is in effect for JPackage derived pre-release Packages in Fedora, on top of the existing [wiki:Self:Packaging/NamingGuidelines#PreReleasePackages Fedora pre-release guidelines] . Here is an example of a pre-release using the JPackage Subrelease Policy:
@@ -70,69 +62,33 @@ JPackage has a Release standard of: 0.X.tag.Yjpp for prerelease packages. Tag is
 |-
 | '''JPackage'''                 || '''Fedora Package'''                || '''Status'''                                          || '''Highest RPMver'''
 |-
-| javacc-4.0-0.1.a.1jpp.src.rpm  || javacc-4.0-0.1.a.1jpp.1.fc7.src.rpm || Package merged from JPackage into Fedora devel        || Fedora
+| javacc-4.0-0.1.a.1jpp.src.rpm  || javacc-4.0-0.1.a.1.1.fc7.src.rpm || Package merged from JPackage into Fedora devel        || Fedora
 |-
-| javacc-4.0-0.2.b.1jpp.src.rpm  || javacc-4.0-0.1.a.1jpp.1.fc7.src.rpm || JPackage moves to "b" tag                             || JPackage
+| javacc-4.0-0.2.b.1jpp.src.rpm  || javacc-4.0-0.1.a.1.1.fc7.src.rpm || JPackage moves to "b" tag                             || JPackage
 |-
-| javacc-4.0-0.2.b.1jpp.src.rpm  || javacc-4.0-0.2.b.1jpp.1.fc7.src.rpm || Fedora version of "b" tag package                     || Fedora
+| javacc-4.0-0.2.b.1jpp.src.rpm  || javacc-4.0-0.2.b.1.1.fc7.src.rpm || Fedora version of "b" tag package                     || Fedora
 |-
-| javacc-4.0-0.2.b.2jpp.src.rpm  || javacc-4.0-0.2.b.1jpp.1.fc7.src.rpm || JPackage is rebuilt for packaging fix                 || JPackage
+| javacc-4.0-0.2.b.2jpp.src.rpm  || javacc-4.0-0.2.b.1.1.fc7.src.rpm || JPackage is rebuilt for packaging fix                 || JPackage
 |-
-| javacc-4.0-0.2.b.2jpp.src.rpm  || javacc-4.0-0.2.b.2jpp.1.fc7.src.rpm || Fedora version of JPackage packaging fix              || Fedora
+| javacc-4.0-0.2.b.2jpp.src.rpm  || javacc-4.0-0.2.b.2.1.fc7.src.rpm || Fedora version of JPackage packaging fix              || Fedora
 |-
-| javacc-4.0-0.2.b.2jpp.src.rpm  || javacc-4.0-0.2.b.2jpp.2.fc7.src.rpm || Fedora rebuilds in devel against a new compiler       || Fedora
+| javacc-4.0-0.2.b.2jpp.src.rpm  || javacc-4.0-0.2.b.2.2.fc7.src.rpm || Fedora rebuilds in devel against a new compiler       || Fedora
 |-
-| javacc-4.0-0.2.b.2jpp.src.rpm  || javacc-4.0-0.2.b.2jpp.2.fc7.src.rpm || FC-7 is released, package moves out of devel          || Fedora
+| javacc-4.0-0.2.b.2jpp.src.rpm  || javacc-4.0-0.2.b.2.2.fc7.src.rpm || FC-7 is released, package moves out of devel          || Fedora
 |-
-| javacc-4.0-0.2.b.2jpp.src.rpm  || javacc-4.0-0.2.b.2jpp.2.fc7.1.src.rpm || A bug is fixed in the FC-7 package.                 || Fedora
+| javacc-4.0-0.2.b.2jpp.src.rpm  || javacc-4.0-0.2.b.2.2.fc7.1.src.rpm || A bug is fixed in the FC-7 package.                 || Fedora
 |-
-| javacc-4.0-1jpp.src.rpm        || javacc-4.0-0.2.b.2jpp.2.fc7.1.src.rpm || JPackage moves to final release (not pre anymore)   || JPackage
+| javacc-4.0-1jpp.src.rpm        || javacc-4.0-0.2.b.2.2.fc7.1.src.rpm || JPackage moves to final release (not pre anymore)   || JPackage
 |-
-| javacc-4.0-1jpp.src.rpm        || javacc-4.0-1jpp.1.fc7.src.rpm       || Fedora version of final package                       || Fedora
+| javacc-4.0-1jpp.src.rpm        || javacc-4.0-1.1.fc7.src.rpm       || Fedora version of final package                       || Fedora
 |}
 
 
 === Track Package Hierarchy From JPackage to Fedora ===
 With the subrelease scheme as documented above, it is very obvious from which JPackage RPM the Fedora Java package originated from.
 
-=== Help the Red Hat Java Packagers Perform Grouped Operations ===
-The need to perform various grouped operations on sets of packages is not unique to the Java packages, but rather, a problem which many people in the Fedora community are working to solve, through new tools and improvements to existing ones.
-
-One key point to note is that the direction is currently to handle Grouping or Categories of packages with metadata that is not hardcoded into the package itself. Or, to put it simply, to not use the Group: field in rpm for this task. It is far too inflexible, as packages can (and do) fall under many different groups or categories.
-
-The grouping operations are:
-* Being able to query for the set of Java packages installed
-* Being able to exclude the Java packages as a group from the yum install/update/remove processes
-
-Until these grouping operations can be performed without the "jpp" tag, there is no other (non-intrusive) way to meet this need.
-
-==== Query for the set of Java packages ====
-
-The rpm -qg (or rpm -q --group) command currently does not accept patterns. If it was possible to do 'rpm -qg "Java*"' we could add "Java/" to all "Group:"
-tags of all Java packages and that would work.
-
-==== Group Exclude in Yum ====
-
-yum has already some group functionality (groupinstall, groupupdate, groupremove, groupinfo) that is based on an XML file that is kept in the repository.  But the option --exclude only acts on file names, we need a --groupexclude.
-
-There is currently a "Java" group, with only 2 packages on it:
-
-Loading "installonlyn" plugin

-Setting up Group Process

-Setting up repositories

-
-Group: Java 

-Description: Support for running programs written in the Java programming language.

-Mandatory Packages: 

-libgcj

-java-1.4.2-gcj-compat

-
-We could just make sure all Java packages are in the Java group to make use of the yum group functionality. Enabling a --groupexclude would meet this criteria.
-
 == Policy Conditions Defined ==
-Accordingly, Fedora will permit Java packages from JPackage (and ONLY Java packages from JPackage) to use the "jpp" tag, under the following conditions:
 
-* The use of the "jpp" tag is temporary. Once there is no longer a technical need as defined in this document, it will be removed from all Fedora packages.
-* Fedora Java packages must follow the subrelease versioning as defined in this document. When the "jpp" tag is removed from Fedora packages, this document will be updated to reflect the change in the subrelease scheme, but the Fedora Java packages will still need to follow it.
+* Fedora Java packages (which have a relationship to JPackage packages) must follow the subrelease versioning as defined in this document. 
 * No other packages fall under this policy (at this time).
 * Packagers of Fedora Java packages need to explicitly agree to this policy during package review.

From b66fbcf67087bd18feb3f884b3df0234f11cc53d Mon Sep 17 00:00:00 2001
From: Spot 
Date: Jul 12 2008 00:32:27 +0000
Subject: [PATCH 104/3559] /* Subrelease Packaging Guidelines for JPackage RPMS */


---

diff --git a/Packaging:JPackagePolicy.mw b/Packaging:JPackagePolicy.mw
index 170a9da..1e9cab6 100644
--- a/Packaging:JPackagePolicy.mw
+++ b/Packaging:JPackagePolicy.mw
@@ -7,7 +7,7 @@
 '''Initial Draft:''' Tuesday Jan 16, 2007

 '''Last Revised:''' Friday Jul 11, 2008

 
-{{Admon/warning | These guidelines have changed significantly since 0.05. An archived copy of the old guidelines is here: [[OldJPackagePolicy]].}}
+{{Admon/warning | These guidelines have changed significantly since 0.05. An archived copy of the old guidelines is here: [[Packaging/OldJPackagePolicy]].}}
 
 == Summary ==
 Fedora includes a set of open source Java RPM packages that originate from the JPackage repository (www.jpackage.org). 

From 80bfade0af61d5c0158d76c3ad0fa7dc887e8ef2 Mon Sep 17 00:00:00 2001
From: Spot 
Date: Jul 15 2008 16:49:32 +0000
Subject: [PATCH 105/3559] /* Action Items */


---

diff --git a/Packaging:GuidelinesTodo.mw b/Packaging:GuidelinesTodo.mw
index b30acc5..e3d5321 100644
--- a/Packaging:GuidelinesTodo.mw
+++ b/Packaging:GuidelinesTodo.mw
@@ -14,8 +14,6 @@ Status should be one of:
 |writeup||!PatchUpstreamStatus||walters||2008-05-06||["PackagingDrafts/PatchUpstreamStatus"]
 |-
 |writeup||!DesktopVerify||caillon||2008-05-06||["PackagingDrafts/DesktopVerify"]
-|-
-|writeup||Withdraw the JPackage Naming Exception||spot||2008-05-20||["Packaging/JPackagePolicy"]
 |}
 
 {{:PackagingDrafts/DraftsTodo}}

From 060d90b64749f14ee91fbe7d9343b3e311d9c5d3 Mon Sep 17 00:00:00 2001
From: Spot 
Date: Jul 15 2008 16:50:09 +0000
Subject: [PATCH 106/3559] /* Resolved items */


---

diff --git a/Packaging:GuidelinesTodo.mw b/Packaging:GuidelinesTodo.mw
index e3d5321..6417290 100644
--- a/Packaging:GuidelinesTodo.mw
+++ b/Packaging:GuidelinesTodo.mw
@@ -23,6 +23,8 @@ Status should be one of:
 |- style="color: white; background-color: #3074c2; font-weight: bold" 
 |Task Name||Owner||Resolution Date||Notes
 |-
+|Withdraw the JPackage Naming Exception||spot||2008-05-20||["Packaging/JPackagePolicy"]
+|-
 |Sugar Activities ||DennisGilmore||2008-04-22||["Packaging/SugarActivityGuidelines"]
 |-
 |Update Static Lib Policies ||TomCallaway||2008-04-22||["PackagingDrafts/StaticLibraryPolicy"]

From d73f4f21be2e171292ec5a20c1080f3ca8dd7bd0 Mon Sep 17 00:00:00 2001
From: Spot 
Date: Jul 28 2008 14:54:41 +0000
Subject: [PATCH 107/3559] *Empty MediaWiki Message*


---

diff --git a/Packaging:SourceURL.mw b/Packaging:SourceURL.mw
index 3122f2e..3abbf54 100644
--- a/Packaging:SourceURL.mw
+++ b/Packaging:SourceURL.mw
@@ -30,8 +30,8 @@ In some cases you may want to pull sources from upstream's revision control syst
 Source0: foo-20070221.tar.gz
-When pulling from revision control, please remember to use a Name-version-release compatible with the [wiki:Self:Packaging/NamingGuidelines#PackageVersion Version] and -[wiki:Self:Packaging/NamingGuidelines#PackageRelease Release] Guidelines. In particular, check the section on [wiki:Self:Packaging/NamingGuidelines#SnapshotPackages Naming Snapshots] . +When pulling from revision control, please remember to use a Name-version-release compatible with the [[Packaging/NamingGuidelines#PackageVersion|Version]] and +[[Packaging/NamingGuidelines#PackageRelease|Release]] Guidelines. In particular, check the section on [[Packaging/NamingGuidelines#SnapshotPackages|Naming Snapshots]] . {{Anchor|ProhibitedCode}} == When Upstream uses Prohibited Code == From 9407854c8635fba20d8d0469e04b71f4d5b1d07d Mon Sep 17 00:00:00 2001 From: Spot Date: Aug 03 2008 13:03:45 +0000 Subject: [PATCH 108/3559] fix broken links from old wiki --- diff --git a/Packaging:ReviewGuidelines.mw b/Packaging:ReviewGuidelines.mw index 1630045..89e40cd 100644 --- a/Packaging:ReviewGuidelines.mw +++ b/Packaging:ReviewGuidelines.mw @@ -31,7 +31,7 @@ There are many many things to check for a review. This list is provided to assis - '''MUST''': The sources used to build the package must match the upstream source, as provided in the spec URL. Reviewers should use md5sum for this task. If no upstream URL can be specified for this package, please see the [[Packaging/SourceURL| Source URL Guidelines]] for how to deal with this.
- '''MUST''': The package must successfully compile and build into binary rpms on at least one supported architecture.
- '''MUST''': If the package does not successfully compile, build or work on an architecture, then those architectures should be listed in the spec in ExcludeArch. Each architecture listed in ExcludeArch needs to have a bug filed in bugzilla, describing the reason that the package does not compile/build/work on that architecture. The bug number should then be placed in a comment, next to the corresponding ExcludeArch line. New packages will not have bugzilla entries during the review process, so they should put this description in the comment until the package is approved, then file the bugzilla entry, and replace the long explanation with the bug number. The bug should be marked as blocking one (or more) of the following bugs to simplify tracking such issues: [https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=FE-ExcludeArch-x86 FE-ExcludeArch-x86] , [https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=FE-ExcludeArch-x64 FE-ExcludeArch-x64] , [https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=FE-ExcludeArch-ppc FE-ExcludeArch-ppc] , [https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=FE-ExcludeArch-ppc64 FE-ExcludeArch-ppc64]
-- '''MUST''': All build dependencies must be listed in BuildRequires, except for any that are listed in the [wiki:Self:Packaging/Guidelines#Exceptions exceptions section of Packaging Guidelines] ; inclusion of those as BuildRequires is optional. Apply common sense.
+- '''MUST''': All build dependencies must be listed in BuildRequires, except for any that are listed in the [[Packaging/Guidelines#Exceptions |exceptions section of the Packaging Guidelines]] ; inclusion of those as BuildRequires is optional. Apply common sense.
- '''MUST''': The spec file MUST handle locales properly. This is done by using the %find_lang macro. Using %{_datadir}/locale/* is strictly forbidden.
- '''MUST''': Every binary RPM package which stores shared library files (not just symlinks) in any of the dynamic linker's default paths, must call ldconfig in %post and %postun. If the package has multiple subpackages with libraries, each subpackage should also have a %post/%postun section that calls /sbin/ldconfig. An example of the correct syntax for this is: 
@@ -43,9 +43,9 @@ There are many many things to check for a review. This list is provided to assis
 - '''MUST''': A package must own all directories that it creates. If it does not create a directory that it uses, then it should require a package which does create that directory.  Refer to the [[Packaging/Guidelines#FileAndDirectoryOwnership|  Guidelines]]  for examples. 

 - '''MUST''': A package must not contain any duplicate files in the %files listing.

 - '''MUST''': Permissions on files must be set properly. Executables should be set with executable permissions, for example. Every %files section must include a %defattr(...) line.

-- '''MUST''': Each package must have a %clean section, which contains rm -rf %{buildroot} ([wiki:Self:Packaging/Guidelines#UsingBuildRootOptFlags or $RPM_BUILD_ROOT] ).

-- '''MUST''': Each package must consistently use macros, as described in the [wiki:Self:Packaging/Guidelines#macros macros section of Packaging Guidelines] . 

-- '''MUST''': The package must contain code, or permissable content. This is described in detail in the [wiki:Self:Packaging/Guidelines#CodeVsContent code vs. content section of Packaging Guidelines] . 

+- '''MUST''': Each package must have a %clean section, which contains rm -rf %{buildroot} ([[Packaging/Guidelines#UsingBuildRootOptFlags| or $RPM_BUILD_ROOT]] ).

+- '''MUST''': Each package must consistently use macros, as described in the [[Packaging/Guidelines#macros|macros section of Packaging Guidelines]] . 

+- '''MUST''': The package must contain code, or permissable content. This is described in detail in the [[Packaging/Guidelines#CodeVsContent| code vs. content section of Packaging Guidelines]] . 

 - '''MUST''': Large documentation files should go in a -doc subpackage. (The definition of large is left up to the packager's best judgement, but is not restricted to size. Large can refer to either size or quantity)

 - '''MUST''': If a package includes something as %doc, it must not affect the runtime of the application. To summarize: If it is in %doc, the program must run properly if it is not present. 

 - '''MUST''': Header files must be in a -devel package.

@@ -54,15 +54,15 @@ There are many many things to check for a review. This list is provided to assis
 - '''MUST''': If a package contains library files with a suffix (e.g. libfoo.so.1.1), then library files that end in .so (without suffix) must go in a -devel package.

 - '''MUST''': In the vast majority of cases, devel packages must require the base package using a fully versioned dependency: Requires: %{name} = %{version}-%{release} 

 - '''MUST''': Packages must NOT contain any .la libtool archives, these should be removed in the spec.

-- '''MUST''': Packages containing GUI applications must include a %{name}.desktop file, and that file must be properly installed with desktop-file-install in the %install section. This is described in detail in the [wiki:Self:Packaging/Guidelines#desktop desktop files section of Packaging Guidelines] . If you feel that your packaged GUI application does not need a .desktop file, you must put a comment in the spec file with your explanation.

+- '''MUST''': Packages containing GUI applications must include a %{name}.desktop file, and that file must be properly installed with desktop-file-install in the %install section. This is described in detail in the [[Packaging/Guidelines#desktop| desktop files section of the Packaging Guidelines]] . If you feel that your packaged GUI application does not need a .desktop file, you must put a comment in the spec file with your explanation.

 - '''MUST''': Packages must not own files or directories already owned by other packages. The rule of thumb here is that the first package to be installed should own the files or directories that other packages may rely upon. This means, for example, that no package in Fedora should ever share ownership with any of the files or directories owned by the filesystem or man package. If you feel that you have a good reason to own a file or directory that another package owns, then please present that at package review time.

-- '''MUST''': At the beginning of %install, each package MUST run rm -rf %{buildroot} ([wiki:Self:Packaging/Guidelines#UsingBuildRootOptFlags or $RPM_BUILD_ROOT] ). See [wiki:Self:Packaging/Guidelines#PreppingBuildRootForInstall Prepping BuildRoot For %install]  for details.

+- '''MUST''': At the beginning of %install, each package MUST run rm -rf %{buildroot} ([[Packaging/Guidelines#UsingBuildRootOptFlags| or $RPM_BUILD_ROOT]] ). See [[Packaging/Guidelines#PreppingBuildRootForInstall| Prepping BuildRoot For %install]]  for details.

 - '''MUST''': All filenames in rpm packages must be valid UTF-8.

 '''SHOULD Items:'''
 
 - '''SHOULD''': If the source package does not include license text(s) as a separate file from upstream, the packager SHOULD query upstream to include it.

 - '''SHOULD''': The description and summary sections in the package spec file should contain translations for supported Non-English languages, if available.

-- '''SHOULD''': The reviewer should test that the package builds in mock. See [wiki:Self:PackageMaintainers/MockTricks MockTricks]  for details on how to do this.

+- '''SHOULD''': The reviewer should test that the package builds in mock. See [[PackageMaintainers/MockTricks| MockTricks]]  for details on how to do this.

 - '''SHOULD''': The package should compile and build into binary rpms on all supported architectures.

 - '''SHOULD''': The reviewer should test that the package functions as described. A package should not segfault instead of running, for example.

 - '''SHOULD''': If scriptlets are used, those scriptlets must be sane. This is vague, and left up to the reviewers judgement to determine sanity.


From df0fc3c333867fb9a1fc6f1742ca0943361c4a66 Mon Sep 17 00:00:00 2001
From: Tibbs 
Date: Aug 11 2008 23:03:07 +0000
Subject: [PATCH 109/3559] Fix damaged link.


---

diff --git a/Packaging:Naming.mw b/Packaging:Naming.mw
index 8dcdc71..24496b2 100644
--- a/Packaging:Naming.mw
+++ b/Packaging:Naming.mw
@@ -416,9 +416,10 @@ R-waveslim (R module named waveslim)
 
 {{Anchor|AddonSugar}}
 == Addon Packages (Sugar Activities) ==
-The name for all packaged Sugar activities must be prefixed with sugar-. For more details, see ["Packaging/SugarActivityGuidelines"] .
+The name for all packaged Sugar activities must be prefixed with sugar-. For more details, see [[Packaging/SugarActivityGuidelines]] .
 
 {{Anchor|AddonTCL}}
+
 == Addon Packages (Tcl/Tk extensions) ==
 The name for all packaged Tcl/Tk extensions must be prefixed with tcl-. This rule applies even for Tcl/Tk packages that are already prefixed with tcl in the name. For more details, see ["Packaging/Tcl#NamingConventions"] .
 

From 5d85dbedd8170caaf8da231fc79597e92597844c Mon Sep 17 00:00:00 2001
From: Tibbs 
Date: Aug 11 2008 23:03:57 +0000
Subject: [PATCH 110/3559] Fix damaged link.


---

diff --git a/Packaging:Naming.mw b/Packaging:Naming.mw
index 24496b2..eae3f68 100644
--- a/Packaging:Naming.mw
+++ b/Packaging:Naming.mw
@@ -421,9 +421,10 @@ The name for all packaged Sugar activities must be prefixed with sugar-. For mor
 {{Anchor|AddonTCL}}
 
 == Addon Packages (Tcl/Tk extensions) ==
-The name for all packaged Tcl/Tk extensions must be prefixed with tcl-. This rule applies even for Tcl/Tk packages that are already prefixed with tcl in the name. For more details, see ["Packaging/Tcl#NamingConventions"] .
+The name for all packaged Tcl/Tk extensions must be prefixed with tcl-. This rule applies even for Tcl/Tk packages that are already prefixed with tcl in the name. For more details, see [[Packaging/Tcl#NamingConventions]].
 
 {{Anchor|AddonLocale}}
+
 == Addon Packages (locales) ==
 If a package adds a locale to an existing parent package, then it can use an underscore in the locale.
 

From fa6e8820efa055a977ae7af3861ddf91cc4597ab Mon Sep 17 00:00:00 2001
From: Tibbs 
Date: Aug 14 2008 20:13:46 +0000
Subject: [PATCH 111/3559] Fix damaged table.


---

diff --git a/Packaging:Guidelines.mw b/Packaging:Guidelines.mw
index 96f34ad..0742a6e 100644
--- a/Packaging:Guidelines.mw
+++ b/Packaging:Guidelines.mw
@@ -642,7 +642,7 @@ For more information, see [http://www.redhat.com/archives/fedora-devel-list/2004
 == Running scriptlets only in certain situations ==
 When the rpm command executes the scriptlets in a package it indicates if the action preformed is an install, erase, upgrade or reinstall by passing an integer argument to the script in question according to the following:
 
-install   erase   upgrade  reinstall
+          install   erase   upgrade  reinstall
 %pre         1        -         2         2
 %post        1        -         2         2
 %preun       -        0         1         -
@@ -658,6 +658,7 @@ fi
 See also /usr/share/doc/rpm-*/triggers, which gives a more formal, generalized definition about the integer value(s) passed to various scripts.
 
 {{Anchor|SciptletsWriteDirs}}
+
 == Scriplets are only allowed to write in certain directories ==
 Build scripts of packages (%prep, %build, %install, %check and %clean) may only alter files (create, modify, delete) under %{buildroot}, %{_builddir} and valid temporary locations like /tmp, /var/tmp (or $TMPDIR or %{_tmppath} as set by the rpmbuild process) according to the following matrix
 

From e4e993dda677991648ec26c04da46a6b0041c26a Mon Sep 17 00:00:00 2001
From: Tibbs 
Date: Aug 17 2008 14:32:36 +0000
Subject: [PATCH 112/3559] Indent.


---

diff --git a/Packaging:Scriptlets.mw b/Packaging:Scriptlets.mw
index e71fb4e..80735c2 100644
--- a/Packaging:Scriptlets.mw
+++ b/Packaging:Scriptlets.mw
@@ -236,13 +236,13 @@ Use this when your package installs new fonts.
 
 %post
 if [ -x %{_bindir}/fc-cache ] ; then
-%{_bindir}/fc-cache %{_datadir}/fonts || :
+  %{_bindir}/fc-cache %{_datadir}/fonts || :
 fi
 %postun
 if [ "$1" = "0" ] ; then
-if [ -x %{_bindir}/fc-cache ] ; then
-%{_bindir}/fc-cache %{_datadir}/fonts || :
-fi
+  if [ -x %{_bindir}/fc-cache ] ; then
+    %{_bindir}/fc-cache %{_datadir}/fonts || :
+  fi
 fi
 

 

From d2a49e52532a9b416490509327af2582eb833899 Mon Sep 17 00:00:00 2001
From: Tibbs 
Date: Aug 17 2008 14:33:01 +0000
Subject: [PATCH 113/3559] Indent.


---

diff --git a/Packaging:Scriptlets.mw b/Packaging:Scriptlets.mw
index 80735c2..caf6dc2 100644
--- a/Packaging:Scriptlets.mw
+++ b/Packaging:Scriptlets.mw
@@ -220,17 +220,18 @@ Note that no dependencies should be added for this. If gtk-update-icon-cache is 
 %post
 touch --no-create %{_datadir}/icons/hicolor
 if [ -x %{_bindir}/gtk-update-icon-cache ] ; then
-%{_bindir}/gtk-update-icon-cache --quiet %{_datadir}/icons/hicolor || :
+  %{_bindir}/gtk-update-icon-cache --quiet %{_datadir}/icons/hicolor || :
 fi
 
 %postun
 touch --no-create %{_datadir}/icons/hicolor
 if [ -x %{_bindir}/gtk-update-icon-cache ] ; then
-%{_bindir}/gtk-update-icon-cache --quiet %{_datadir}/icons/hicolor || :
+  %{_bindir}/gtk-update-icon-cache --quiet %{_datadir}/icons/hicolor || :
 fi
 

 
 {{Anchor|fonts}}
+
 == Fonts ==
 Use this when your package installs new fonts.
 

From 3821f62da7c75682d090962b99fa45e0335bca55 Mon Sep 17 00:00:00 2001
From: Tibbs 
Date: Aug 17 2008 14:33:27 +0000
Subject: [PATCH 114/3559] Indent.


---

diff --git a/Packaging:Scriptlets.mw b/Packaging:Scriptlets.mw
index caf6dc2..0e59e07 100644
--- a/Packaging:Scriptlets.mw
+++ b/Packaging:Scriptlets.mw
@@ -155,13 +155,14 @@ Requires(preun): info
 
 %preun
 if [ $1 = 0 ] ; then
-/sbin/install-info --delete %{_infodir}/%{name}.info %{_infodir}/dir || :
+  /sbin/install-info --delete %{_infodir}/%{name}.info %{_infodir}/dir || :
 fi
 

 
 These two scriptlets tell install-info to add entries for the info pages to the main index file on installation and remove them at erase time.  The "|| :" in this case prevents failures that would typically affect systems that have been configured not to install any %doc files, or have read-only mounted, %_netsharedpath /usr/share.
 
 {{Anchor|scrollkeeper}}
+
 == Scrollkeeper ==
 Gnome and KDE use the scrollkeeper cataloging system to keep track of documentation installed on the system.  Scrollkeeper allows the help system to sort and search documentation metadata stored in .omf files.  When you add documentation in these systems you need to make scrollkeeper aware that the documentation has been changed.
 

From 82b57b80c945a4af8684f2fe518cf2b060188485 Mon Sep 17 00:00:00 2001
From: Orion 
Date: Sep 09 2008 02:57:24 +0000
Subject: [PATCH 115/3559] Fix typos


---

diff --git a/Packaging:Octave.mw b/Packaging:Octave.mw
index 5064389..6d237e4 100644
--- a/Packaging:Octave.mw
+++ b/Packaging:Octave.mw
@@ -28,7 +28,7 @@ Group:          Applications/Engineering
 License:        GPLv2+
 URL:            http://octave.sourceforge.net
 Source0:        http://downloads.sourceforge.net/octave/%{pkg}-%{version}.tar.gz
-BuildRoot:      %{_tmppath}/%{name}-%{version}-%{release}-root%-(%{__id_u} -n)
+BuildRoot:      %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
 
 Requires:       octave(api) = %{octave_api}
 Obsoletes:      octave-forge < 20071015
@@ -73,7 +73,7 @@ octave -q -H --no-site-file --eval "pkg('rebuild');"
 %{_datadir}/octave/packages/%{pkg}-%{version}/*.m
 %dir %{_datadir}/octave/packages/%{pkg}-%{version}/packinfo
 %doc %{_datadir}/octave/packages/%{pkg}-%{version}/packinfo/COPYING
-%doc %{_datadir}/octave/packages/%{pkg}-%{version}/packinto/DESCRIPTION
+%doc %{_datadir}/octave/packages/%{pkg}-%{version}/packinfo/DESCRIPTION
 %{_datadir}/octave/packages/%{pkg}-%{version}/packinfo/.autoload
 %{_datadir}/octave/packages/%{pkg}-%{version}/packinfo/INDEX
 %{_datadir}/octave/packages/%{pkg}-%{version}/packinfo/dist_admin
@@ -140,7 +140,7 @@ octave -q -H --no-site-file --eval "pkg('rebuild');"
 %{_datadir}/octave/packages/%{pkg}-%{version}/*.m
 %dir %{_datadir}/octave/packages/%{pkg}-%{version}/packinfo
 %doc %{_datadir}/octave/packages/%{pkg}-%{version}/packinfo/COPYING
-%doc %{_datadir}/octave/packages/%{pkg}-%{version}/packinto/DESCRIPTION
+%doc %{_datadir}/octave/packages/%{pkg}-%{version}/packinfo/DESCRIPTION
 %{_datadir}/octave/packages/%{pkg}-%{version}/packinfo/.autoload
 %{_datadir}/octave/packages/%{pkg}-%{version}/packinfo/INDEX
 %{_datadir}/octave/packages/%{pkg}-%{version}/packinfo/dist_admin

From adb63a2ebedf438b4d94242ec25d4d4394fd6cdb Mon Sep 17 00:00:00 2001
From: Spot 
Date: Sep 12 2008 13:36:09 +0000
Subject: [PATCH 116/3559] /* Scriptlet Ordering */


---

diff --git a/Packaging:Scriptlets.mw b/Packaging:Scriptlets.mw
index 0e59e07..97c4dc7 100644
--- a/Packaging:Scriptlets.mw
+++ b/Packaging:Scriptlets.mw
@@ -44,14 +44,14 @@ Non-zero exit codes from scriptlets break installs/upgrades/erases so that no fu
 = Scriptlet Ordering =
 The scriptlets in %pre and %post are respectively run before and after a package is installed.  The scriptlets %preun and %postun are run before and after a package is uninstalled.  The scriptlets %pretrans and %posttrans are run at start and end of a transaction.  On upgrade, the scripts are run in the following order:
 
-1. %pretrans of new package
-1. %pre of new package
-1. (package install)
-1. %post of new package
-1. %preun of old package
-1. (removal of old package)
-1. %postun of old package
-1. %posttrans of new package
+#. %pretrans of new package
+#. %pre of new package
+#. (package install)
+#. %post of new package
+#. %preun of old package
+#. (removal of old package)
+#. %postun of old package
+#. %posttrans of new package
 
 = Snippets =
 

From b77e06b4cba20b172c4bf230e873eb2d53179873 Mon Sep 17 00:00:00 2001
From: Spot 
Date: Sep 12 2008 13:36:31 +0000
Subject: [PATCH 117/3559] /* Scriptlet Ordering */


---

diff --git a/Packaging:Scriptlets.mw b/Packaging:Scriptlets.mw
index 97c4dc7..14bc343 100644
--- a/Packaging:Scriptlets.mw
+++ b/Packaging:Scriptlets.mw
@@ -44,14 +44,14 @@ Non-zero exit codes from scriptlets break installs/upgrades/erases so that no fu
 = Scriptlet Ordering =
 The scriptlets in %pre and %post are respectively run before and after a package is installed.  The scriptlets %preun and %postun are run before and after a package is uninstalled.  The scriptlets %pretrans and %posttrans are run at start and end of a transaction.  On upgrade, the scripts are run in the following order:
 
-#. %pretrans of new package
-#. %pre of new package
-#. (package install)
-#. %post of new package
-#. %preun of old package
-#. (removal of old package)
-#. %postun of old package
-#. %posttrans of new package
+# %pretrans of new package
+# %pre of new package
+# (package install)
+# %post of new package
+# %preun of old package
+# (removal of old package)
+# %postun of old package
+# %posttrans of new package
 
 = Snippets =
 

From 9d0791477c550da0062edf8cb5656b5a674c900a Mon Sep 17 00:00:00 2001
From: Spot 
Date: Sep 16 2008 17:19:16 +0000
Subject: [PATCH 118/3559] /* Action Items */


---

diff --git a/Packaging:GuidelinesTodo.mw b/Packaging:GuidelinesTodo.mw
index 6417290..d9f7481 100644
--- a/Packaging:GuidelinesTodo.mw
+++ b/Packaging:GuidelinesTodo.mw
@@ -14,6 +14,14 @@ Status should be one of:
 |writeup||!PatchUpstreamStatus||walters||2008-05-06||["PackagingDrafts/PatchUpstreamStatus"]
 |-
 |writeup||!DesktopVerify||caillon||2008-05-06||["PackagingDrafts/DesktopVerify"]
+|-
+|writeup||Haskell ||spot||2008-09-16|| [[PackagingDrafts/Haskell]]
+|-
+|writeup||Font Bundles||spot||2008-09-16|| [[TomCallaway/Packaging_Font_Bundles2]]
+|-
+|writeup||Avoid Font Bundling||spot||2008-09-16|| [[TomCallaway/No_bundling_of_fonts_in_other_packages2]] (Fonts policy amendment)
+|-
+|writeup||Lisp ||spot||2008-09-16||[[PackagingDrafts/Lisp]]
 |}
 
 {{:PackagingDrafts/DraftsTodo}}

From 9cbb3ab8b081575ef8269901ecba836d7c4bb6d4 Mon Sep 17 00:00:00 2001
From: Spot 
Date: Sep 16 2008 17:21:23 +0000
Subject: [PATCH 119/3559] New page: = Haskell Packaging Guidelines =  This documents the guidelines and conventions for packaging Haskell projects in Fedora.    == What is Haskell? ==  (from http://haskell.org/)  Haskell is ...


---

diff --git a/Packaging:Haskell.mw b/Packaging:Haskell.mw
new file mode 100644
index 0000000..86a2423
--- /dev/null
+++ b/Packaging:Haskell.mw
@@ -0,0 +1,200 @@
+= Haskell Packaging Guidelines =
+
+This documents the guidelines and conventions for packaging Haskell projects in Fedora.
+
+
+
+== What is Haskell? ==
+
+(from http://haskell.org/)
+
+Haskell is an advanced purely functional programming language. The product of more than twenty years of cutting edge research, it allows rapid development of robust, concise, correct software. With strong support for integration with other languages, built-in concurrency, debuggers, profilers, rich libraries and an active community, Haskell makes it easier to produce flexible, maintainable high-quality software.
+
+GHC, or the Glasgow Haskell Compiler, is the most popular and widely used Haskell compiler.  It complies with Haskell 98, the latest official language specification, and also includes numerous experimental language ideas.  It represents a good picture of what the future of Haskell will look like, so it is a good choice for development.  Many Haskell programs work better or only with GHC.  So currently these guidelines mainly focus on packaging for GHC.  At some later stage if the need arises they may be extended to cover other implementation in more detail.
+
+== Base package naming ==
+
+=== Libraries ===
+Haskell library packages should be prefixed with the compiler or interpreter they are intended for.  Package names should follow the upstream naming and preserve case.  For example,  the bzlib library from [http://hackage.haskell.org/ Hackage] packaged for GHC would be named ghc-bzlib in Fedora, and the QuickCheck library would be named ghc-QuickCheck.
+
+If a library is packaged for more than one Haskell compiler or interpreter, the base name should instead be prefixed with haskell, e.g. haskell-X11.  Such a package would then have subpackages for each compiler and/or interpreter it is built for (e.g. ghc-X11, hug98-X11, etc.
+
+''Rationale: The Fedora Project tries to follow upstream as closely as possible.  Upstream maintains very consistent naming schemes, and mixed case names are tracked very well.''
+
+=== Programs ===
+For packages of Haskell programs the usual Fedora Package Naming Guidelines must be followed: ie in they should follow the upstream name. Examples include projects like darcs, haddock, and xmonad.  If the package also generates libraries, then the libraries SHOULD be subpackaged as a Haskell library package named after the compiler or interpreter as above.
+
+''Rationale: Binaries are not dependant on the compiler they were compiled with anymore than a C program is dependant on whether it's been compiled with gcc or icc.''
+
+== Description ==
+When packaging things out of [http://hackage.haskell.org Hackage]  or other sources, you may find that the description is incomplete or improperly labeled.  Please double check all parts of the package description so that it meets Fedora's standards for writing quality.
+
+== Build and Install ==
+
+%build and %install can be done through a series of macros that ensure correctness.
+
+
+%build
+%cabal_configure
+%cabal_build
+%cabal_haddock
+

+
+''Note: Please include profiling libraries where possible or include a justification for not doing so.''
+
+%cabal_build will build a package without installing it
+
+%cabal_haddock builds haddock files
+
+
+%install
+rm -rf ${RPM_BUILD_ROOT}
+%cabal_install
+

+
+%cabal_install will install the package without including the registration scripts for ghc's library management.  For libraries, see below how to achieve this.
+
+== Packaging libraries ==
+GHC libraries should be installed under libdir/ghc as done by Cabal.
+
+
+%define pkg_libdir %{_libdir}/ghc-%{ghc_version}/%{pkg_name}-%{version}
+

+
+=== File lists ===
+You can generate filelists using the following macro, rather than doing it by hand:
+
+
+%ghc_gen_filelists %{name}
+

+
+This macro takes one parameter, which is just a name to be used for the file lists.  This same parameter must be used later in the files section.
+
+The files section would then look something like this:
+
+
+%files -f %{name}.files
+%defattr(-,root,root,-)
+%doc dist/doc/html
+%doc LICENSE TODO README
+
+
+%files -n %{name}-prof -f %{name}-prof.files
+%defattr(-,root,root,-)
+%doc LICENSE
+

+
+=== Install scripts ===
+Libraries must be registered with the installed GHC.
+
+To generate registration scripts that can be embedded in the package, include the following in %build, and include the following install script macros.
+
+%ghc_gen_scripts
+

+
+To separate the copying phase from the registration phase of installation, include the following in %install
+
+%ghc_install_scripts
+

+
+To register packages at install time, make sure to include the following bits:
+
+%pre -n ghc-%{pkg_name}
+%ghc_preinst_script
+
+
+%post -n ghc-%{pkg_name}
+%ghc_postinst_script
+
+
+%preun -n ghc-%{pkg_name}
+%ghc_preun_script
+
+
+%postun -n ghc-%{pkg_name}
+%ghc_postun_script
+

+
+== Packaging programs ==
+Programs are packaged in their simple name, eg xmonad would remain xmonad.  Any libraries should go into a separate subpackage: eg the spec file for xmonad would generate two rpms, both of which are required for runtime, xmonad and ghc-xmonad.  xmonad would require ghc-xmonad, but not visa versa.  ghc-xmonad would contain a line in its description explaining that these are the libraries necessary for xmonad to run.
+
+Binary packages should be compiled with GHC when possible.  Some Haskell packages might require some compiler extension not provided in GHC. Alternate compilers may be used so long as they are packaged for Fedora.  Please make it clear what feature is needed when submitting that package for review, and leave an appropriate comment in the spec file.
+
+If a compiler is not available in Fedora, please submit it for package review as well.  We can block your review request on the compiler, and if they pass review, they can be accepted simultaneously.  Please note that your compiler must follow Fedora's guidelines for packaging and package submission.
+
+''Rationale: Binaries are recognized on their name alone.  Furthermore, they do not require a compiler to run.  Therefore the name provided should simply be the upstream name.  GHC is the best supported compiler in Fedora currently.  Therefore, if something goes wrong, we have a larger skill base to ask for help.''
+
+== Documentation ==
+Packages should try to make sure Haddock document links correctly to other dependent packages.
+
+== Debug Information ==
+Debuginfo packages should not be built for GHC binaries, since they will be empty anyway.
+
+''Rationale: GHC does not emit DWARF debug data.''
+
+== Macros ==
+
+A number of macros are defined for cabal packages, per compiler.  They have names like %ghc_build and %ghc_install. Similar macros can be defined for other compilers.  Please stick to this API when implementing macros for other compilers.
+
+* %cabal
+* %cabal_configure
+* %cabal_build
+* %cabal_makefile
+* %cabal_haddock
+* %cabal_install
+* %ghc_install_scripts
+* %ghc_gen_filelists()
+* %ghc_preinst_script
+* %ghc_postinst_script
+* %ghc_preun_script
+* %ghc_postun_script
+
+=== Definitions ===
+
+Definitions per compiler go here
+
+* [[PackagingDrafts/Haskell/GHCMacroDefs | Definitions for GHC Macros ]]
+
+== Spec Templates ==
+There are three types of packages: Library only, Library and Binary, and Binary only.  The program cabal-rpm can generate a SPEC file suited to all three cases.  The following templates are the output from cabal-rpm with a few minor changes.  These templates should build under mock, and any failure is a bug against these guidelines.
+
+* [[PackagingDrafts/Haskell/LibraryOnlyTemplate|  Library Only Template]] 
+* [[PackagingDrafts/Haskell/BinaryOnlyTemplate|  Binary Only Template]]
+* [[PackagingDrafts/Haskell/LibraryAndBinaryTemplate|  Library and Binary Template]]
+
+== Static vs. Dynamic Linking ==
+
+Currently GHC performs only static linking with other Haskell libraries, partly due to a significant amount of optimizations done when inlining functions from other libraries.  Therefore, when recompiling any library, all packages that depend on it will also need to be recompiled, and in the event of a security advisory, one needs to be applied to all dependencies.
+
+This is not true for libraries linked through other languages using the Foreign Function Interface (FFI).  When linking to these libraries, the standard dynamic linker is used.
+
+''Note: this is very similar to OCaml, and the usual rules that apply there apply here as well.''
+
+Keep in mind though, this does not mean that you can just put all dependencies in the BuildRequires list and be done with it.  Some packages, such as xmonad, perform lots of run time code generation, and may require certain libraries to be present to work.
+
+== Using cabal-rpm ==
+If you use cabal-rpm to generate spec files, there are a few gotchas.  These items are the difference between Yaakov Nemoy's working cabal-rpm and the guidelines.  Since there is little variety in spec files, it might be easier to copy one of the templates from above and make the changes needed.
+
+* The file name of the spec file will be the name of the package.  Make sure to prepend 'ghc-' or the appropriate name for another compiler to the spec file before submitting it for review.  This is necessary for libraries only.  (For example, there would be a collision between ghc-zlib and zlib, but there is only one haddock or darcs.)
+* cabal-rpm is currently only aware of haskell libraries installed by default with GHC.  It will need alot more work to provide automagic dependency detection.
+* cabal-rpm isn't always so intelligent about runtime dependencies for libraries.  For example, it may specify the devel version of a library where the non-devel version is required. (This is important for binaries only.  Libraries require devel versions, of course.)
+* BuildRequires probably needs to be filled out by hand.  One suitable method is to keep testing it in mock until it compiles cleanly.
+* If the source package requires steps besides cabal, report it to upstream, and make sure to include them in the %build and %install sections.
+
+Double check the following:
+
+* License
+* Group
+* URL - this can be the Hackage page
+* Source URL - this can be from Hackage
+* Summary
+* Description
+* Files section includes all documentation and LICENSES. If not, please patch it according to the Fedora Packaging Guidelines
+
+Finally, make sure to include changelog entries to specify what has been changed from the original cabal-rpm output.
+
+== References ==
+* http://urchin.earth.li/~ian/haskell-policy/ - Debian Haskell packaging policy
+* [[Packaging/OCaml|Fedora OCaml Packaging Guidelines]]
+* [[SIGs/Haskell|Fedora Haskell SIG]]
+* [http://ynemoy.fedorapeople.org/haskell Ynemoy's macros and cabal-rpm tree]

From 4cd8e5c722323ed625fc25f6ac6e8e5dd1a1a801 Mon Sep 17 00:00:00 2001
From: Spot 
Date: Sep 16 2008 17:22:30 +0000
Subject: [PATCH 120/3559] *Empty MediaWiki Message*


---

diff --git a/Packaging:GuidelinesTodo.mw b/Packaging:GuidelinesTodo.mw
index d9f7481..ea4a85f 100644
--- a/Packaging:GuidelinesTodo.mw
+++ b/Packaging:GuidelinesTodo.mw
@@ -15,7 +15,7 @@ Status should be one of:
 |-
 |writeup||!DesktopVerify||caillon||2008-05-06||["PackagingDrafts/DesktopVerify"]
 |-
-|writeup||Haskell ||spot||2008-09-16|| [[PackagingDrafts/Haskell]]
+
 |-
 |writeup||Font Bundles||spot||2008-09-16|| [[TomCallaway/Packaging_Font_Bundles2]]
 |-
@@ -31,6 +31,8 @@ Status should be one of:
 |- style="color: white; background-color: #3074c2; font-weight: bold" 
 |Task Name||Owner||Resolution Date||Notes
 |-
+|Haskell ||spot||2008-09-16|| [[Packaging/Haskell]]
+|-
 |Withdraw the JPackage Naming Exception||spot||2008-05-20||["Packaging/JPackagePolicy"]
 |-
 |Sugar Activities ||DennisGilmore||2008-04-22||["Packaging/SugarActivityGuidelines"]

From 7938a77d2288b5646c23b2773389be0576a2139e Mon Sep 17 00:00:00 2001
From: Spot 
Date: Sep 16 2008 17:23:00 +0000
Subject: [PATCH 121/3559] /* Action Items */


---

diff --git a/Packaging:GuidelinesTodo.mw b/Packaging:GuidelinesTodo.mw
index ea4a85f..bd25d8c 100644
--- a/Packaging:GuidelinesTodo.mw
+++ b/Packaging:GuidelinesTodo.mw
@@ -15,8 +15,6 @@ Status should be one of:
 |-
 |writeup||!DesktopVerify||caillon||2008-05-06||["PackagingDrafts/DesktopVerify"]
 |-
-
-|-
 |writeup||Font Bundles||spot||2008-09-16|| [[TomCallaway/Packaging_Font_Bundles2]]
 |-
 |writeup||Avoid Font Bundling||spot||2008-09-16|| [[TomCallaway/No_bundling_of_fonts_in_other_packages2]] (Fonts policy amendment)

From 44894a768651b695dabe90720512721e9fb97075 Mon Sep 17 00:00:00 2001
From: Spot 
Date: Sep 16 2008 17:24:27 +0000
Subject: [PATCH 122/3559] New page: = Lisp Packaging Guidelines =  This document seeks to document the conventions and customs surrounding the proper packaging of Common Lisp implementations and libraries in Fedora. This doc...


---

diff --git a/Packaging:Lisp.mw b/Packaging:Lisp.mw
new file mode 100644
index 0000000..c303fd0
--- /dev/null
+++ b/Packaging:Lisp.mw
@@ -0,0 +1,134 @@
+= Lisp Packaging Guidelines =
+
+This document seeks to document the conventions and customs surrounding the proper packaging of Common Lisp implementations and libraries in Fedora.
+This document does ''not'' describe conventions and customs for application programs that are written in Common Lisp.
+
+= Introduction =
+
+Most Common Lisp implementations provide a compiler to generate their own binary representation of source.  These binary files typically end in .fasl (for Fast Load).  These .fasl files are not compatible across Common Lisp implementations, or even between different versions of the same implementation.   This unique property calls for special support on the packaging front.
+
+The Common Lisp community currently rallies around a common packaging and deployment technology called asdf (Another System Definition Format).   Projects deployed using asdf include a system definition file.  These files include information about project dependencies, licensing, and the authors.  Projects don't typically distribute binaries, but rather depend on the asdf utilities to compile the Lisp source code on demand.  When you run program that depends on a library managed by asdf, the asdf system will automatically compile the dependent Lisp code on demand and cache the results.
+
+The Debian Lisp community have developed tools and guidelines for packaging and maintaining asdf managed libraries on Linux systems.  Their tool is called common-lisp-controller and, combined with asdf, it ensures that .fasl files are managed properly on the system.  For instance, when a Common Lisp implementation is upgraded, the .fasl files for all of the packages built using the old implementation are deleted so that new ones may be generated on demand.
+
+The rest of this packaging guideline aims to describe how to package Common Lisp implementations, libraries and programs to take advantage of asdf and the common-lisp-controller.
+
+= Guidelines for Libraries and Programs written in Common Lisp =
+
+== Naming ==
+
+Lisp libraries should have their package names prefixed with "cl-", except in the case where the library name already starts with "cl-".
+
+Rationale: There is some overlap between Lisp library names and existing Fedora packages.  Creating a special name space for Lisp libraries should simplify life for everybody.
+
+== -devel sub-package ==
+
+Pure lisp libraries do not require -devel sub-packages, as they install source code by default.
+
+== Use of asdf ==
+
+Libraries should be managed by asdf, a packaging format for Common Lisp libraries (see the cl-asdf package for details).  Most modern Lisp libraries already ship with asdf system definition files (with names typically ending in ".asd").  If none exist, then one will have to be written.  The contents of these files is not all that different from an RPM .spec file, so this should not be too difficult for a Lisp-savvy packager.  The ASDF manual describing how to write .asd files is available here: http://constantly.at/lisp/asdf/ .
+
+== Install location and hooking into the common-lisp-controller ==
+
+Libraries should depend on the common-lisp-controller package.
+Lisp source should be installed in %{_datadir}/common-lisp/source/.
+The package should own that directory.  The parent directories are owned by the common-lisp-controller package.
+A symlink to the asdf system definition file should be created from %{_datadir}/common-lisp/systems/.asd to %{_datadir}/common-lisp/source//.asd (this target directory is also owned by common-lisp-controller).
+The %post section should call "%{_sbindir}/register-common-lisp-source ".
+The %preun section should call "%{_sbindir}/unregister-common-lisp-source "
+These scripts are provided by common-lisp-controller.
+
+== Spec file template ==
+
+Name:           # see normal package guidelines
+Version:        # see normal package guidelines
+Release:        1%{?dist}
+Summary:        # see normal package guidelines (SNPG)
+
+Group:          # SNPG
+License:        # SNPG
+URL:            # SNPG
+Source0:        # SNPG
+BuildRoot:      %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
+
+BuildRequires:   common-lisp-controller
+Requires:        common-lisp-controller
+Requires(post):  common-lisp-controller
+Requires(preun): common-lisp-controller
+
+%description
+
+%prep
+%setup -q
+
+%build
+
+%install
+%{__rm} -rf %{buildroot}
+
+# Replace @NAME@ below with the Common Lisp library name, which may be different from the
+# package name if it is not already prefixed with "cl-".
+
+mkdir -m 755 -p %{buildroot}%{_datadir}/common-lisp/source/@NAME@
+mkdir -m 755 -p %{buildroot}%{_datadir}/common-lisp/systems
+for s in *.lisp; do
+  install -m 644 $s %{buildroot}%{_datadir}/common-lisp/source/@NAME@;
+done;
+for s in *.asd; do
+  install -m 644 $s %{buildroot}%{_datadir}/common-lisp/source/@NAME@;
+done;
+cd %{buildroot}%{_datadir}/common-lisp/source/@NAME@
+for asd in *.asd; do
+  ln -s %{_datadir}/common-lisp/source/@NAME@/$asd ../../systems;
+done
+
+%post
+/usr/sbin/register-common-lisp-source @NAME@
+
+%preun
+/usr/sbin/unregister-common-lisp-source @NAME@
+
+%clean
+%{__rm} -rf %{buildroot}
+
+%files
+%defattr(-,root,root,-)
+%doc
+%{_datadir}/common-lisp/source/@NAME@
+%{_datadir}/common-lisp/systems/@NAME@.asd
+
+%changelog
+

+
+= Guidelines for Common Lisp implementations =
+
+== Naming ==
+
+There are no special requirements here.  Common Lisp implementations should be packaged using their normal project name.
+
+== -devel sub-package ==
+
+Common Lisp implementations do not require -devel sub-packages, and they necessarily include all development tools by default.
+
+== Use of asdf ==
+
+Common Lisp implementations should be able to load asdf by simply entering "(require 'asdf)" at the Lisp Read-Eval-Print loop (REPL).  This may involve modifying search paths or related changes at build time.
+
+== Install location and hooking into the common-lisp-controller ==
+
+Common Lisp implementations should depend on the common-lisp-controller package.
+
+Common Lisp implementations should install a script in %{_libdir}/common-lisp/bin/.sh that supports a single command on the command line: "install-clc". This should load %{_datadir}/common-lisp/source/common-lisp-controller/common-lisp-controller.lisp, call (common-lisp-controller:init-common-lisp-controller-v4 ) and then save the resulting image as default for the system.
+
+The %post section should call "%{_sbindir}/register-common-lisp-implementation ".
+The %preun section should call "%{_sbindir}/unregister-common-lisp-implementation "
+
+These scripts, and the %{_libdir}/common-lisp/bin directory are provided and owned by the common-lisp-controller package.
+
+All implementations should be modified to load common-lisp-controller's %{_sysconfdir}/lisp-config.lisp on startup.
+
+
+= Further reading =
+
+See http://www.cliki.net/common-lisp-controller and http://common-lisp.net/project/asdf/  for more details on common-lisp-controller and asdf.

From cd821baf32cff83605f73d270537033e45b9f625 Mon Sep 17 00:00:00 2001
From: Spot 
Date: Sep 16 2008 17:26:32 +0000
Subject: [PATCH 123/3559] add links to Lisp and Haskell guidelines


---

diff --git a/Packaging:Guidelines.mw b/Packaging:Guidelines.mw
index 0742a6e..9efffc2 100644
--- a/Packaging:Guidelines.mw
+++ b/Packaging:Guidelines.mw
@@ -7,9 +7,9 @@ It is the reviewer's responsibility to point out specific problems with a packag
 Please remember that any package that you submit must also conform to the [[Packaging/ReviewGuidelines|  Review Guidelines]] .
 
 '''Author:''' [[TomCallaway|  Tom 'spot' Callaway]]  (based on many other documents)

-'''Revision:''' 0.91

+'''Revision:''' 0.92

 '''Initial Draft:''' Wednesday Feb 23, 2005

-'''Last Revised:''' Wednesday May 21, 2008

+'''Last Revised:''' Tuesday Sep 16, 2008

 
 
 
@@ -809,10 +809,18 @@ Guidelines for Emacs/X-Emacs packages: [[Packaging/Emacs]]
 === Fonts ===
 Guidelines for font packages: [[Packaging/FontsPolicy]] 
 
+{{Anchor|HaskellGuidelines}}
+=== Haskell ===
+Guidelines for Haskell packages: [[Packaging/Haskell]]
+
 {{Anchor|JavaGuidelines}}
 === Java ===
 Guidelines for java packages: [[Packaging/Java]] 
 
+{{Anchor|LispGuidelines}}
+=== Lisp ===
+Guidelines for lisp packages: [[Packaging/Lisp]]
+
 {{Anchor|MonoGuidelines}}
 === Mono ===
 Guidelines for Mono packages: [[Packaging/Mono]] 

From be0ac863c288de94c1ca5d7b88fe9020440425f4 Mon Sep 17 00:00:00 2001
From: Spot 
Date: Sep 16 2008 17:27:36 +0000
Subject: [PATCH 124/3559] *Empty MediaWiki Message*


---

diff --git a/Packaging:GuidelinesTodo.mw b/Packaging:GuidelinesTodo.mw
index bd25d8c..0997f24 100644
--- a/Packaging:GuidelinesTodo.mw
+++ b/Packaging:GuidelinesTodo.mw
@@ -18,8 +18,6 @@ Status should be one of:
 |writeup||Font Bundles||spot||2008-09-16|| [[TomCallaway/Packaging_Font_Bundles2]]
 |-
 |writeup||Avoid Font Bundling||spot||2008-09-16|| [[TomCallaway/No_bundling_of_fonts_in_other_packages2]] (Fonts policy amendment)
-|-
-|writeup||Lisp ||spot||2008-09-16||[[PackagingDrafts/Lisp]]
 |}
 
 {{:PackagingDrafts/DraftsTodo}}
@@ -31,6 +29,8 @@ Status should be one of:
 |-
 |Haskell ||spot||2008-09-16|| [[Packaging/Haskell]]
 |-
+|Lisp ||spot||2008-09-16||[[Packaging/Lisp]]
+|-
 |Withdraw the JPackage Naming Exception||spot||2008-05-20||["Packaging/JPackagePolicy"]
 |-
 |Sugar Activities ||DennisGilmore||2008-04-22||["Packaging/SugarActivityGuidelines"]

From 3508935d3a2391e78588accfbcf7f1e08a32a5ba Mon Sep 17 00:00:00 2001
From: Spot 
Date: Sep 16 2008 17:42:09 +0000
Subject: [PATCH 125/3559] Avoid Font Bundling


---

diff --git a/Packaging:Guidelines.mw b/Packaging:Guidelines.mw
index 9efffc2..94dd9f2 100644
--- a/Packaging:Guidelines.mw
+++ b/Packaging:Guidelines.mw
@@ -7,7 +7,7 @@ It is the reviewer's responsibility to point out specific problems with a packag
 Please remember that any package that you submit must also conform to the [[Packaging/ReviewGuidelines|  Review Guidelines]] .
 
 '''Author:''' [[TomCallaway|  Tom 'spot' Callaway]]  (based on many other documents)

-'''Revision:''' 0.92

+'''Revision:''' 0.93

 '''Initial Draft:''' Wednesday Feb 23, 2005

 '''Last Revised:''' Tuesday Sep 16, 2008

 
@@ -792,6 +792,22 @@ It is important to note that a Fedora package, once installed, and run by a user
 === Packages already in Fedora owning files or directories in /srv ===
 Any packages currently in Fedora that own files or directories in /srv must be fixed before Fedora 10.
 
+{{Anchor|AvoidFontBundling}}
+== Avoid bundling of fonts in other packages ==
+Given that fonts can be reused in many ways, that they can be bulky, that they usually have distinct licensing requirements, and that font legal problems are endemic:
+
+# any package that makes use of bundled font files '''SHOULD''' strongly consider packaging them in a separate sub-package, if they have any value outside of the package
+#*Font files which are in a standardized format, and contain a set of characters or symbols which are useful for other packages are considered to have value.
+#*if a package includes fonts with value outside the application, the packager '''SHOULD''' ask upstream to publish the font files separately
+# the packager(s) and reviewer(s) of fonts '''MUST''' be familiar with our [[Legal_considerations_for_fonts|fonts legal page]].
+# they '''SHOULD''' exert their best efforts to trace fonts to their original creators, and not ship fonts collected by middlemen with no modifications.
+#* middlemen often strip part of the legal context.
+# they '''SHOULD''' package each font family separately, and avoid font collections that mix fonts of different history, licensing, or origin.
+#* font collections hide legal problems in the mass.
+#* the exception is fonts created by the same authors and released at the same time in the same archive. But even then it is very possible some fonts will be tainted, while the others are fine.
+
+In addition, fonts in general-purpose formats such as Type1, OpenType TT (TTF) or OpenType CFF (OTF) are subject to specific packaging guidelines ([[Packaging/FontsPolicy|1]], [[Packaging/FontsSpecTemplate|2]]), and should never be packaged in a private application directory instead of the system-wide font repositories.
+
 {{Anchor|ApplicationSpecificGuidelines}}
 == Application Specific Guidelines ==
 

From 7c3eb5cdcf60c8662da990f3855907a00bf703c4 Mon Sep 17 00:00:00 2001
From: Spot 
Date: Sep 16 2008 17:45:02 +0000
Subject: [PATCH 126/3559] *Empty MediaWiki Message*


---

diff --git a/Packaging:Guidelines.mw b/Packaging:Guidelines.mw
index 94dd9f2..43981b6 100644
--- a/Packaging:Guidelines.mw
+++ b/Packaging:Guidelines.mw
@@ -792,8 +792,12 @@ It is important to note that a Fedora package, once installed, and run by a user
 === Packages already in Fedora owning files or directories in /srv ===
 Any packages currently in Fedora that own files or directories in /srv must be fixed before Fedora 10.
 
+{{Anchor|Bundling}}
+== Bundling of multiple projects ==
+Fedora packages should make every effort to avoid having multiple, separate, upstream projects bundled together in a single package.
+
 {{Anchor|AvoidFontBundling}}
-== Avoid bundling of fonts in other packages ==
+=== Avoid bundling of fonts in other packages ===
 Given that fonts can be reused in many ways, that they can be bulky, that they usually have distinct licensing requirements, and that font legal problems are endemic:
 
 # any package that makes use of bundled font files '''SHOULD''' strongly consider packaging them in a separate sub-package, if they have any value outside of the package

From 2499bd2a5eac9a6fe5076421940707107bdc5764 Mon Sep 17 00:00:00 2001
From: Spot 
Date: Sep 16 2008 17:46:58 +0000
Subject: [PATCH 127/3559] add bundles text


---

diff --git a/Packaging:FontsPolicy.mw b/Packaging:FontsPolicy.mw
index 751d9ac..37a073e 100644
--- a/Packaging:FontsPolicy.mw
+++ b/Packaging:FontsPolicy.mw
@@ -32,5 +32,20 @@ The users of this legacy backend won't thank you for destabilizing it with new f
 
 {{:Comps_fonts_rules}}
 
+== Font bundles ==
+
+As noted in the [[Packaging/Guidelines#Bundling |Packaging Guidelines]], Fedora packages should make every effort to avoid having multiple, separate, upstream projects bundled together in a single package. This applies equally to font packages.
+
+Sometimes local groups publish a collection of fonts of different origins and different licensing in a single archive. In that case the interested packager '''SHOULD''' ask this upstream to break up its archive in different files. If upstream refuses the packager '''MAY''' base a single ''src.rpm'' on the collection archive, but he '''MUST''' make sure each bundled font set ends up in a different, appropriately licensed sub-package.
+
+When a project is the upstream of several font families, which are all licensed the same way, and released on the same dates, in a single archive, the packager '''MAY''' create a single package. However the packager '''SHOULD''' consider splitting each font family in a different sub-package, so users can install only the font families they care about.
+
+Multi-source packages are difficult to maintain and confusing to users. In addition:
+* fonts are comparatively bulky, and big font packages will be blacklisted from live-cds and by low-bandwidth users.
+* multi-family packages force users to install fonts they may not care of or even like just to get the other fonts in the package.
+
+As a rule, try to produce small simple user-friendly mono-family font packages that will be easy to maintain (you should however strive to group different faces of the same font family in the same package). Avoid grouping unrelated fonts in a single package.
+
+
 {{:Fonts_SIG_signature}}
 [[Category:Fonts packaging|Packaging policy]]

From 42e86eedc9d746bdc2944e84ababd0b0e3021003 Mon Sep 17 00:00:00 2001
From: Spot 
Date: Sep 16 2008 17:47:43 +0000
Subject: [PATCH 128/3559] *Empty MediaWiki Message*


---

diff --git a/Packaging:GuidelinesTodo.mw b/Packaging:GuidelinesTodo.mw
index 0997f24..a366f1d 100644
--- a/Packaging:GuidelinesTodo.mw
+++ b/Packaging:GuidelinesTodo.mw
@@ -14,10 +14,6 @@ Status should be one of:
 |writeup||!PatchUpstreamStatus||walters||2008-05-06||["PackagingDrafts/PatchUpstreamStatus"]
 |-
 |writeup||!DesktopVerify||caillon||2008-05-06||["PackagingDrafts/DesktopVerify"]
-|-
-|writeup||Font Bundles||spot||2008-09-16|| [[TomCallaway/Packaging_Font_Bundles2]]
-|-
-|writeup||Avoid Font Bundling||spot||2008-09-16|| [[TomCallaway/No_bundling_of_fonts_in_other_packages2]] (Fonts policy amendment)
 |}
 
 {{:PackagingDrafts/DraftsTodo}}
@@ -31,6 +27,10 @@ Status should be one of:
 |-
 |Lisp ||spot||2008-09-16||[[Packaging/Lisp]]
 |-
+|Font Bundles||spot||2008-09-16|| [[TomCallaway/Packaging_Font_Bundles2]]
+|-
+|Avoid Font Bundling||spot||2008-09-16|| [[TomCallaway/No_bundling_of_fonts_in_other_packages2]] (Fonts policy amendment)
+|-
 |Withdraw the JPackage Naming Exception||spot||2008-05-20||["Packaging/JPackagePolicy"]
 |-
 |Sugar Activities ||DennisGilmore||2008-04-22||["Packaging/SugarActivityGuidelines"]

From 5768d6e3c266d0d29203ed76b161df59baf7afd0 Mon Sep 17 00:00:00 2001
From: Spot 
Date: Sep 16 2008 17:54:28 +0000
Subject: [PATCH 129/3559] /* desktop-file-install usage */


---

diff --git a/Packaging:Guidelines.mw b/Packaging:Guidelines.mw
index 43981b6..46a6a24 100644
--- a/Packaging:Guidelines.mw
+++ b/Packaging:Guidelines.mw
@@ -472,8 +472,8 @@ Categories=Graphics;
=== desktop-file-install usage === -It is not simply enough to just include the .desktop file in the package, one MUST run desktop-file-install in %install (and have BuildRequires: desktop-file-utils), to help ensure .desktop file safety and spec-compliance. -Here are some examples of desktop-file-install usage: +It is not simply enough to just include the .desktop file in the package, one MUST run desktop-file-install OR desktop-file-validate in %install (and have BuildRequires: desktop-file-utils), to help ensure .desktop file safety and spec-compliance. desktop-file-install MUST be used if the package does not install the file or there are changes desired to the .desktop file (such as add/removing categories, etc). desktop-file-validate MAY be used instead if the .desktop file's content/location does not need modification. Here are some examples of +usage: 
 desktop-file-install --vendor=""               \
@@ -496,6 +496,9 @@ desktop-file-install --vendor=""                           \
 %{buildroot}/%{_datadir}/applications//foo.desktop
+
+desktop-file-validate %{buildroot}/%{_datadir}/applications/foo.desktop
+
* If upstream uses , leave it intact, otherwise use fedora as . * It is important that vendor_id stay constant for the life of a package. From e4d0d611db481ebf1a160a0337022e21fa4e202d Mon Sep 17 00:00:00 2001 From: Spot Date: Sep 16 2008 17:58:48 +0000 Subject: [PATCH 130/3559] *Empty MediaWiki Message* --- diff --git a/Packaging:Guidelines.mw b/Packaging:Guidelines.mw index 46a6a24..cabce2e 100644 --- a/Packaging:Guidelines.mw +++ b/Packaging:Guidelines.mw @@ -815,6 +815,46 @@ Given that fonts can be reused in many ways, that they can be bulky, that they u In addition, fonts in general-purpose formats such as Type1, OpenType TT (TTF) or OpenType CFF (OTF) are subject to specific packaging guidelines ([[Packaging/FontsPolicy|1]], [[Packaging/FontsSpecTemplate|2]]), and should never be packaged in a private application directory instead of the system-wide font repositories. +== All patches should have an upstream bug link or comment == + +All patches in Fedora spec files '''SHOULD''' have a comment above them about their upstream status. Any time you create a patch, it is best practice to file it in an upstream bug tracker, and include a link to that in the comment above the patch. For example: + +
+# http://bugzilla.gnome.org/show_bug.cgi?id=12345
+Patch0: gnome-panel-fix-frobnicator.patch
+
+ +The above is perfectly acceptable; but if you prefer, a brief comment about what the patch does above can be helpful: + +
+# Don't crash with frobnicator applet
+# http://bugzilla.gnome.org/show_bug.cgi?id=12345
+Patch0: gnome-panel-fix-frobnicator.patch
+
+ +Sending patches upstream and adding this comment will help ensure that Fedora is acting as a good FLOSS citizen (see [[PackageMaintainers/WhyUpstream| Why Upstream?]] ). It will help others (and even you) down the line in package maintenance by knowing what patches are likely to appear in a new upstream release. + +=== If upstream doesn't have a bug tracker === +You can indicate that you have sent the patch upstream and any known status: + +
+# Sent upstream via email 20080407
+Patch0: foobar-fix-the-bar.patch
+
+ +
+# Upstream has applied this in SVN trunk
+Patch0: foobar-fix-the-baz.patch
+
+ +=== Fedora-specific (or rejected upstream) patches === +It may be that some patches truly are Fedora-specific; in that case, say so: + +
+# This patch is temporary until we land the long term System.loadLibrary fix in OpenJDK
+Patch0: jna-jni-path.patch
+
+ {{Anchor|ApplicationSpecificGuidelines}} == Application Specific Guidelines == From 16114006ae9f73dc7c6c8636fd1a8e7ed5ea1d13 Mon Sep 17 00:00:00 2001 From: Spot Date: Sep 16 2008 17:59:47 +0000 Subject: [PATCH 131/3559] *Empty MediaWiki Message* --- diff --git a/Packaging:GuidelinesTodo.mw b/Packaging:GuidelinesTodo.mw index a366f1d..aa69d0e 100644 --- a/Packaging:GuidelinesTodo.mw +++ b/Packaging:GuidelinesTodo.mw @@ -10,10 +10,6 @@ Status should be one of: {| border="1" |- style="color: white; background-color: #3074c2; font-weight: bold" |Status||Task Name||Owner||Meeting Date||Notes -|- -|writeup||!PatchUpstreamStatus||walters||2008-05-06||["PackagingDrafts/PatchUpstreamStatus"] -|- -|writeup||!DesktopVerify||caillon||2008-05-06||["PackagingDrafts/DesktopVerify"] |} {{:PackagingDrafts/DraftsTodo}} @@ -23,6 +19,10 @@ Status should be one of: |- style="color: white; background-color: #3074c2; font-weight: bold" |Task Name||Owner||Resolution Date||Notes |- +|PatchUpstreamStatus||walters||2008-09-16||[[PackagingDrafts/PatchUpstreamStatus]] +|- +|DesktopVerify||caillon||2008-09-16||[[PackagingDrafts/DesktopVerify]] +|- |Haskell ||spot||2008-09-16|| [[Packaging/Haskell]] |- |Lisp ||spot||2008-09-16||[[Packaging/Lisp]] From 66b6b1a54e26ffb91dd07d4fde4402f8a26a2aa9 Mon Sep 17 00:00:00 2001 From: Spot Date: Oct 02 2008 13:27:09 +0000 Subject: [PATCH 132/3559] /* Initscripts Conventions */ --- diff --git a/Packaging:Scriptlets.mw b/Packaging:Scriptlets.mw index 14bc343..2e5ae42 100644 --- a/Packaging:Scriptlets.mw +++ b/Packaging:Scriptlets.mw @@ -79,10 +79,11 @@ These are discussed on a [[Packaging/UsersAndGroups| separate page]] == Services == === Initscripts Conventions === -Full guidelines for SysV-style initscripts can be found here: ["Packaging/SysVInitScript"]
-Scriptlet specifics can be found here: ["Packaging/SysVInitScript#InitscriptScriptlets"] +Full guidelines for SysV-style initscripts can be found here: [[Packaging/SysVInitScript]]
+Scriptlet specifics can be found here: [[Packaging/SysVInitScript#InitscriptScriptlets]] {{Anchor|gconf}} + == GConf == GConf is a configuration scheme currently used by the GNOME desktop. Programs which use it setup default values in a [NAME] .schemas file which is installed under %{_sysconfdir}/gconf/schemas/[NAME] .schemas. These defaults are then registered with the gconf daemon which monitors the configuration values and alerts applications when values the applications are interested in change. The schema files also provide documentation about what each value in the configuration system means (which gets displayed when you browse the database in the gconf-editor program). From d81e9c5d9a7e724331a72e486576b71e5a9a8549 Mon Sep 17 00:00:00 2001 From: Spot Date: Oct 06 2008 13:52:34 +0000 Subject: [PATCH 133/3559] /* OpenOffice.org extension rpm guidelines */ --- diff --git a/Packaging:OpenOffice.orgExtensions.mw b/Packaging:OpenOffice.orgExtensions.mw index 9c49b89..bda3eaa 100644 --- a/Packaging:OpenOffice.orgExtensions.mw +++ b/Packaging:OpenOffice.orgExtensions.mw @@ -2,17 +2,17 @@ --> == OpenOffice.org extension rpm guidelines == -1. Extensions deinstalled with unopkg remove '''Must''' have a %postun of 'unopkg list --shared > /dev/null 2>&1' because the actual removal of files is deferred until the next start, so this ensures that this takes place under the control of your rpm on deinstallation. -1. Extensions '''Should''' be both installed unpacked and then registered with 'unopkg --link' where possible to save disk-space. Otherwise during registration of a packed .oxt or .uno.pkg with unopkg the package is automatically unzipped and the contents copied into a persistent cache directory. Using -link and an unpacked .oxt/.uno.pkg dir allows this additional copy to be omitted and importantly allows the rest of the standard rpmbuild tooling to determine additional autorequires for a package or find flaws that cannot be seen in the opaque zip case. -1. Unpacked Extensions '''Must''' be installed in a dir called [http://extensions.openoffice.org/servlets/ReadMsg?list=dev&msgNo=142 NAME.oxt, NAME.uno.pkg or NAME.zip] -1. An extension should normally just be able to just Require: an appropriate openoffice.org component e.g. openoffice.org-core, without a specific n-v-r as extensions use the stable UNO abi which rarely changes, and then only to add extra apis. So unless you require a specific feature of a openoffice.org release there is no need to require a specific n-v-r and force a rebuild on every n-v-r of openoffice.org. -1. extensions '''Must''' be named openoffice.org-FOO. The location where an extension is unpacked '''Must''' be in an arch or arch-independent location depending on if the extension has been written in an arch or arch-independent language. e.g. StarBasic and Java only extensions are noarch and '''Must''' be unpacked under /usr/share/openoffice.org/extensions, while e.g. C++ extensions are arch-dependant and '''Must''' be unpacked under %{_libdir}/openoffice.org/extensions. -1. extensions are similar to e.g. xorg video drivers in that there exist proprietary or binary only extensions, but of course normal Fedora rules apply to what extensions can be packaged, i.e. see normal packaging licensing etc. rules. The license '''Must''' be acceptable, and the package '''Must''' be built from source. -1. extensions can be written in any language that has a uno binding, e.g. C++, python, java or StarBasic. Consider the additional packaging guidelines of the language that the extension is written in if such guidelines exists. -1. Some obsolete versions of openoffice.org < F9 had bugs in unopkg, so the minimum Requires are: 2.3.0-6.12 for F8, and 2.3.0-6.6 for F7 - -.. -An example is... +# Extensions deinstalled with unopkg remove '''Must''' have a %postun of 'unopkg list --shared > /dev/null 2>&1' because the actual removal of files is deferred until the next start, so this ensures that this takes place under the control of your rpm on deinstallation.
+# Extensions '''Should''' be both installed unpacked and then registered with 'unopkg --link' where possible to save disk-space. Otherwise during registration of a packed .oxt or .uno.pkg with unopkg the package is automatically unzipped and the contents copied into a persistent cache directory. Using -link and an unpacked .oxt/.uno.pkg dir allows this additional copy to be omitted and importantly allows the rest of the standard rpmbuild tooling to determine additional autorequires for a package or find flaws that cannot be seen in the opaque zip case.
+# Unpacked Extensions '''Must''' be installed in a dir called [http://extensions.openoffice.org/servlets/ReadMsg?list=dev&msgNo=142 NAME.oxt, NAME.uno.pkg or NAME.zip]
+# An extension should normally just be able to just Require: an appropriate openoffice.org component e.g. openoffice.org-core, without a specific n-v-r as extensions use the stable UNO abi which rarely changes, and then only to add extra apis. So unless you require a specific feature of a openoffice.org release there is no need to require a specific n-v-r and force a rebuild on every n-v-r of openoffice.org.
+# extensions '''Must''' be named openoffice.org-FOO. The location where an extension is unpacked '''Must''' be in an arch or arch-independent location depending on if the extension has been written in an arch or arch-independent language. e.g. StarBasic and Java only extensions are noarch and '''Must''' be unpacked under /usr/share/openoffice.org/extensions, while e.g. C++ extensions are arch-dependant and '''Must''' be unpacked under %{_libdir}/openoffice.org/extensions.
+# extensions are similar to e.g. xorg video drivers in that there exist proprietary or binary only extensions, but of course normal Fedora rules apply to what extensions can be packaged, i.e. see normal packaging licensing etc. rules. The license '''Must''' be acceptable, and the package '''Must''' be built from source.
+# extensions can be written in any language that has a uno binding, e.g. C++, python, java or StarBasic. Consider the additional packaging guidelines of the language that the extension is written in if such guidelines exists.
+# Some obsolete versions of openoffice.org < F9 had bugs in unopkg, so the minimum Requires are: 2.3.0-6.12 for F8, and 2.3.0-6.6 for F7
+
+..
+An example is...
 Requires(pre):    openoffice.org-core >= 2.3.0-6.6
 Requires(post):   openoffice.org-core >= 2.3.0-6.6
@@ -29,7 +29,7 @@ unopkg remove --shared org.openoffice.legacy.writer2latex.uno.pkg || :
 fi
 
 %post
-unopkg add --shared --link %{_datadir}/writer2latex.uno.pkg || :
+unopkg add --shared --force --link %{_datadir}/writer2latex.uno.pkg || :
 
 %preun
 if [ $1 -eq 0 ] ; then

From 78cb429e680e38ca04b1213d06da1b1d7994a142 Mon Sep 17 00:00:00 2001
From: Spot 
Date: Oct 14 2008 12:33:51 +0000
Subject: [PATCH 134/3559] /* Versioned MODULE_COMPAT_ Requires */


---

diff --git a/Packaging:Perl.mw b/Packaging:Perl.mw
index a1ed8b8..e058d5a 100644
--- a/Packaging:Perl.mw
+++ b/Packaging:Perl.mw
@@ -46,7 +46,7 @@ Historically, buildrequiring a core module (that is, one provided by the perl pa
 All perl modules must include the versioned MODULE_COMPAT Requires:
 
 
-Requires:  perl(:MODULE_COMPAT_%(eval "%{__perl} -V:version"; echo $version))
+Requires:  perl(:MODULE_COMPAT_%(eval "%{__perl} -V:version"; echo $version))
 

 
 This is to ensure that perl packages have a dependency on a perl which provides the appropriate versioned directory structure (otherwise, the modules won't be found).
@@ -56,6 +56,7 @@ This is to ensure that perl packages have a dependency on a perl which provides 
 Some packages link to libperl.so, usually to provide embedded perl functionality. All of these packages must also use the versioned MODULE_COMPAT Requires.
 
 {{Anchor|depfiltering}}
+
 == Filtering Requires: and Provides ==
 
 RPM's dependency generator can often throw in additional dependencies and will often think packages provide functionality contrary to reality.  To fix this, the dependency generator needs to be overriden so that the additional dependencies can be filtered out.  There are two main ways to do this:

From 28158ec62f9fcf8d31090fb3b7080ae1ede790d3 Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Oct 15 2008 17:47:06 +0000
Subject: [PATCH 135/3559] MinGW Guidelines


---

diff --git a/Packaging:MinGW_Future.mw b/Packaging:MinGW_Future.mw
new file mode 100644
index 0000000..a83a94c
--- /dev/null
+++ b/Packaging:MinGW_Future.mw
@@ -0,0 +1,309 @@
+= Packaging Guidelines for MinGW Windows cross-compiler =
+
+= Introduction =
+
+The Fedora MinGW project's mission is to provide an excellent
+development environment for Fedora users who wish to cross-compile
+their programs to run on Windows, minimizing the need to use Windows
+at all.  In the past developers have had to port and compile all of
+the libraries and tools they have needed, and this huge effort has
+happened independently many times over.  We aim to eliminate
+duplication of work for application developers by providing a range of
+libraries and development tools which have already been ported to the
+cross-compiler environment.  This means that developers will not need
+to recompile the application stack themselves, but can concentrate
+just on the changes needed to their own application.
+
+Note that when deciding to contribute a new library to the Fedora
+MinGW project, it is advisable to start with our example specfile:
+http://hg.et.redhat.com/misc/fedora-mingw--devel/?fl=7e95a9b24e2d;file=example/mingw32-example.spec
+
+= Track Fedora native package versions =
+
+In general terms, MinGW packages which provide cross-compiled versions
+of packages already natively available in Fedora, should follow the
+native Fedora package as closely as possible.  This means they should
+stay at the same version, include all the same patches as the native
+Fedora package, and be built with the same configuration options.
+
+The MinGW SIG have written an RPM comparison tool which makes it
+possible to compare MinGW packages with the Fedora native packages, in
+order to determine whether versions, patches and configuration are
+aligned.
+
+= Follow Fedora policy =
+
+MinGW packages must follow Fedora policy, except where noted in this
+document.  MinGW packages go through the same review process, CVS
+admin process etc as other Fedora packages.
+
+= Package naming =
+
+Packages should be named by prefixing the upstream package name
+with mingw32-
+
+= Base packages =
+
+The base packages provide a root filesystem, base libraries, binutils
+(basic programs like 'strip', 'ld' etc), the compiler (gcc) and the
+Win32 API.  Packages may need to depend on one or more of these.  In
+particular, almost any conceivable package should depend on
+mingw32-filesystem and mingw32-runtime.
+
+{|
+| mingw32-filesystem || Core filesystem directory layout, and RPM macros for spec files.  Equivalent to 'filesystem' RPM
+|-
+| mingw32-runtime || Base libraries for core MinGW runtime & development environment.  Equivalent to glibc & glibc-devel RPMs
+|-
+| mingw32-binutils || Cross-compiled binutils (utilities like 'strip', 'as', 'ld') which understand Windows executables and DLLs.  Equivalent to 'binutils' RPM
+|-
+| mingw32-w32api || Win32 API.  A [http://www.mingw.org/MinGWiki/index.php/w32api free (public domain) reimplementation] of the header files required to link to the Win32 API.  No direct equivalent in base Fedora - glibc-devel is closest
+|-
+| mingw32-gcc || GNU compiler collection.  Compilers for C and C++ which cross-compile to a Windows target.  Equivalent to gcc RPM
+|}
+
+= Filesystem layout =
+
+ [root]
+   |
+   +- etc
+   |   |
+   |   +- rpm
+   |       |
+   |       +- macros.mingw32
+   |
+   +- usr
+       |
+       +- bin   - Links to cross compiler toolchain
+       |   |
+       |   +- i686-pc-mingw32-cpp
+       |   +- i686-pc-mingw32-gcc
+       |   +- i686-pc-mingw32-g++
+       |   +- ... etc..
+       |
+       +- lib
+       |   |
+       |   +- rpm
+       |       |
+       |       +- mingw32-defs   - custom helper scripts for auto-requires, binary stripping, etc
+       |       +- mingw32-find-provides.sh - extra DLL names
+       |       +- mingw32-find-requires.sh - discover required DLL names
+       |
+       +- i686-pc-mingw32  - root of mingw toolchain and binaries - see next diagram
+
+
+ /usr/i686-pc-mingw32
+   |
+   +- bin  - Cross compiler toolchain  
+   |   |
+   |   +- cpp
+   |   +- gcc
+   |   +- g++
+   |   +- ... etc ...
+   |
+   +- lib  - Cross compiler toolchain support libraries / files
+   |
+   +- sys-root  - root for cross compiled binaries
+       |
+       +- mingw
+           |
+           +- bin     - cross-compiled binaries & runtime DLL parts
+           +- doc     - documentation
+           +- include - include files for cross compiled libs
+           +- lib     - cross-compiled static libraries & linktime DLL parts
+           |   |
+           |   +- pkgconfig  - pkg-config definitions for libraries
+           |
+           +- share
+               |
+               +- man
+
+= Filenames of the cross-compilers and binutils =
+
+The cross-compilers and binutils are Fedora binaries and are therefore
+placed in %{_bindir} (ie. /usr/bin)
+according to the FHS and Fedora guidelines.
+
+The cross-compilers and binutils which generate i686 binaries for Windows are named:
+
+ %{_bindir}/i686-pc-mingw32-gcc
+ %{_bindir}/i686-pc-mingw32-g++
+ %{_bindir}/i686-pc-mingw32-ld
+ %{_bindir}/i686-pc-mingw32-as
+ %{_bindir}/i686-pc-mingw32-strip
+ etc.
+
+The same binaries are present in
+%{_prefix}/i686-pc-mingw32/bin without any prefix in the
+name, ie:
+
+ %{_prefix}/i686-pc-mingw32/bin/gcc
+ %{_prefix}/i686-pc-mingw32/bin/g++
+ %{_prefix}/i686-pc-mingw32/bin/ld
+ %{_prefix}/i686-pc-mingw32/bin/as
+ %{_prefix}/i686-pc-mingw32/bin/strip
+ etc.
+
+= Naming of the root filesystem =
+
+The root filesystem contains Windows executables and DLLs and any other Windows-only
+files.  It is necessary both because we need to store Windows libraries in order to
+link further libraries which depend on them, and also because MinGW requires a
+root filesystem location.  The location (for i686 target) is provided by the macro:
+
+ %{_mingw32_sysroot}   %{_prefix}/i686-pc-mingw32/sys-root
+
+= Standard mingw RPM macros =
+
+The mingw32-filesystem package provides a number of
+convenience macros for the cross compiled sysroot directories, and
+toolchain. It is mandatory to use these macros in all MinGW packages
+submitted to Fedora.
+
+== Toolchain macros ==
+
+The following macros are for the %build and %install section of the spec
+
+{|
+| _mingw32_ar	|| i686-pc-mingw32-ar || cross compiler 'ar' binary
+|-
+| _mingw32_cc	|| i686-pc-mingw32-gcc || cross compiler 'gcc' binary
+|-
+| _mingw32_cflags	|| -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions --param=ssp-buffer-size=4 ||
+|-
+| _mingw32_configure || CC="%{_mingw32_cc}"  CFLAGS="%{_mingw32_cflags}"  ./configure  --build=%_build --host=%{_mingw32_host} --target=%{_mingw32_target}  --prefix=%{_mingw32_prefix} || standard invocation for autotools 'configure' scripts
+|-
+| _mingw32_cpp	|| i686-pc-mingw32-gcc -E || cross compiler 'cpp' binary
+|-
+| _mingw32_host	|| i686-pc-mingw32  || Host platform for build
+|-
+| _mingw32_objdump ||	i686-pc-mingw32-objdump || cross compiler 'objdump' binary
+|-
+| _mingw32_ranlib	|| i686-pc-mingw32-ranlib || cross compiler 'ranlib' binary
+|-
+| _mingw32_strip	|| i686-pc-mingw32-strip || cross compiler 'strip' binary 
+|-
+| _mingw32_target	|| i686-pc-mingw32 || Target platform for build
+|}
+
+== Filesystem location macros ==
+
+The following macros are for use in %build, %install and %files sections of the RPM spec
+
+{|
+|_mingw32_bindir	|| %{_mingw32_prefix}/bin || Location of Windows executables.
+|-
+|_mingw32_datadir	|| %{_mingw32_prefix}/share || Shared data used under Windows.
+|-
+|_mingw32_docdir	|| %{_mingw32_prefix}/share/doc || Documentation.
+|-
+|_mingw32_infodir	|| %{_mingw32_prefix}/share/info || Info files (see note below).
+|-
+|_mingw32_includedir	|| %{_mingw32_prefix}/include || Header files used when cross-compiling for Windows.
+|-
+|_mingw32_libdir	|| %{_mingw32_prefix}/lib || Windows libraries (see sections below).
+|-
+|_mingw32_libexecdir || %{_mingw32_prefix}/libexec ||
+|-
+|_mingw32_mandir	|| %{_mingw32_prefix}/share/man || Man pages (see note below).
+|-
+|_mingw32_prefix	|| %{_mingw32_sysroot}/mingw || Windows equivalent of %{_prefix}, required by MinGW.
+|-
+|_mingw32_sbindir	|| %{_mingw32_prefix}/sbin ||
+|-
+|_mingw32_sysconfdir	|| %{_mingw32_prefix}/etc || Configuration files used when running under Windows.
+|-
+|_mingw32_sysroot	|| %{_prefix}/i686-pc-mingw32/sys-root || Windows system root.
+|}
+
+= Dependencies =
+
+If a package contains binaries which depend on a DLL provided by
+another package, these dependencies should be expressed in the form:
+
+ mingw32(foo.dll)
+
+where foo.dll is the name of the DLL.  The name must be
+converted to lowercase because Windows binaries contain case
+insensitive dependencies.
+
+All packages should depend on mingw32-filesystem.
+
+Correct dependency generation is done automatically.  Packagers should
+include these lines in all library packages:
+
+ %define _use_internal_dependency_generator 0
+ %define __find_requires %{_mingw32_findrequires}
+ %define __find_provides %{_mingw32_findprovides}
+
+All specfiles should BuildRequire at least:
+
+ BuildRequires:  mingw32-filesystem >= minimum-version
+
+and any other BuildRequires that they need.
+
+= Build architecture =
+
+All packages should have:
+
+ BuildArch: noarch
+
+unless they contain Fedora native executables.
+
+= Libraries (DLLs) =
+
+All libraries must be built as DLLs.
+
+Because of the peculiarity of Windows, DLLs are stored in the
+%{_mingw32_bindir} directory, along with a control file in
+the %{_mingw32_libdir} directory.  For example, for a
+library called foo there would be:
+
+ %{_mingw32_bindir}/foo.dll
+ %{_mingw32_bindir}/foo.def
+ %{_mingw32_libdir}/foo.dll.a
+ %{_mingw32_libdir}/foo.la
+
+All files are required in those locations in order to link
+successfully, except that the .def file is not always
+built by libtool for reasons unknown, and the .dll may
+contain a version number although not always
+(eg. foo-0.dll).
+
+== Do not use %{_mingw32_bindir}/* or %{_mingw32_libdir}/* in %files section ==
+
+The %files section must list DLLs separately.  Packages
+must NOT use %{_mingw32_bindir}/* or
+%{_mingw32_libdir}/*
+
+The reason for this is that libtool is very fragile and will give up
+on building a DLL very easily.  Therefore we force the name of the DLL
+to be listed explicitly in the %files section in order to
+catch this during RPM builds.
+
+== Manpages and info files ==
+
+If manpages or info files are simply duplicates of equivalent
+documentation found in Fedora native packages, then they should not be
+packaged in the MinGW package.
+
+== Static libraries ==
+
+In accordance with ordinary Fedora policy, static libraries should not
+be built, and if they are then they should be placed in a
+-static subpackage.
+
+The exception is the base package mingw32-w32api which
+contains static libraries that are required for GCC to create
+executables.
+
+== Stripping ==
+
+Libraries and executables should be stripped.  This is done correctly
+and automatically if the spec file includes these lines:
+
+ %define __strip %{_mingw32_strip}
+ %define __objdump %{_mingw32_objdump}
+
+(Note that if __strip and __objdump are not overridden in the specfile
+then this can sometimes cause Windows binaries to be corrupted).

From d4bc1f808838448f959c5c622a7943a2f4a2d560 Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Oct 15 2008 17:55:13 +0000
Subject: [PATCH 136/3559] FPC and FESCo Approved


---

diff --git a/Packaging:UnownedDirectories.mw b/Packaging:UnownedDirectories.mw
new file mode 100644
index 0000000..b241fb1
--- /dev/null
+++ b/Packaging:UnownedDirectories.mw
@@ -0,0 +1,99 @@
+= Unowned Directories =
+
+The term "unowned directory" (or "orphaned directory") refers to a packaging mistake where these three things happen:
+
+* a package includes files within a directory it creates, but '''not''' the directory itself
+* none of the package's dependencies provide the directory either
+* the directory belongs to your package and does not belong to any core package or base filesystem package that is considered essential/fundamental to any Fedora System.
+
+== Issues ==
+
+Unowned directories can cause the following problems.
+
+=== Inaccessible Directories ===
+
+A restrictive superuser umask during package installation can create inaccessible directories.  For instance, if the superuser does this:
+
+  umask 077
+  yum update
+  [or]
+  rpm -ivh PACKAGE
+
+Unowned directories within the updated or installed packages will only be readable and executable by root.  This prevents other users from using the files within those directories.
+
+This causes run-time problems for users. For example, unreadable subdirs below %_libdir disable plugins. Unreadable subdirs below %_datadir prevent application data, help texts, and graphics from being accessed.
+
+Several sorts of users fix such permission problems with chmod instead of taking the time to report it as a bug. It is common belief that such bugs are so obvious they would be found by the package maintainer or will be reported by other users.
+
+=== Directories not Removed ===
+Upon uninstalling the package (or upgrading to another version), the old directory is not removed from the file system because it does not belong in the package in the RPM database.
+
+Especially if directories contain a version number, they clutter up the file system with every update which doesn't remove old directories.
+
+=== Directories cannot be Verified ===
+Unowned/orphaned directories cannot be checked with rpm -V and not with rpm -qf either.
+
+=== ./configure Scripts can Fail ===
+Upstream source tarball configuration can fail, because it detects the presence of an old but empty versioned header directories or because it is trying to use multiple versioned directories instead of just the latest valid one.
+
+== Tools to Help ==
+
+It's easy to find unowned directories with rpmls from rpmdevtools or rpm -qlv. Just a bit of carefulness is needed to not include core filesystem directories, such as %_bindir, %_libdir (and obvious others, e.g. from the "filesystem" pkg) which don't belong into your package.
+
+== Common Mistakes ==
+
+Here are some examples of common packaging mistakes in spec %files lists to avoid
+
+=== Wildcarding Files inside a Created Directory ===
+
+==== Unversioned ====
+
+  %{_datadir}/foo/*
+
+This includes everything _in_ "foo", but not "foo" itself. "rpm -qlv pkgname" will show a missing drwxr-xr-x entry for "foo".  Correct would be:
+
+  %{_datadir}/foo/
+
+to include the directory _and_ the entire tree below it.
+
+==== Versioned ====
+
+  %{_docdir}/%{name}-%{version}/*
+  %{_includedir}/%{name}-%{version}/*.h
+
+This is the same as the unversioned scenario with the addition that everytime the package is upgraded to a new version the old directory will remain on the filesystem.  Correct would be:
+
+  %{_docdir}/%{name}-%{version}/
+  %dir %{_includedir}/%{name}-%{version}
+  %{_includedir}/%{name}-%{version}/*.h
+
+
+=== Forgetting to Include a Toplevel Directory ===
+
+  %dir %{_libdir}/foo-2/fu
+  %dir %{_libdir}/foo-2/bar
+  %{_libdir}/foo-2/fu/*.so
+  %{_libdir}/foo-2/bar/config*
+
+Here it is an attempt at including the directories explicitly with the %dir macro. However, while "bar" is included, "foo-2" is not.  Typically packagers run into that mistake if all installed files are stored only in subdirs of the parent "foo-2" directory.  Correct would be:
+
+  %dir %{_libdir}/foo-2
+  %dir %{_libdir}/foo-2/fu
+  %dir %{_libdir}/foo-2/bar
+  %{_libdir}/foo-2/fu/*.so
+  %{_libdir}/foo-2/bar/config*
+
+
+==== Only Including Files ====
+
+  %{_datadir}/%{name}/db/raw/*.db
+  %{_datadir}/%{name}/pixmaps/*.png
+
+Here only specific data files are included, and all 4 directories below %_datadir are unowned.  Correct would be:
+
+  %dir %{_datadir}/%{name}
+  %dir %{_datadir}/%{name}/db
+  %dir %{_datadir}/%{name}/db/raw
+  %dir %{_datadir}/%{name}/pixmaps
+  %{_datadir}/%{name}/db/raw/*.db
+  %{_datadir}/%{name}/pixmaps/*.png

From 6166388896c66417609f0dda02de4692eeced26a Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Oct 15 2008 18:55:41 +0000
Subject: [PATCH 137/3559] Update for unowned directories clarification


---

diff --git a/Packaging:ReviewGuidelines.mw b/Packaging:ReviewGuidelines.mw
index 89e40cd..83b267b 100644
--- a/Packaging:ReviewGuidelines.mw
+++ b/Packaging:ReviewGuidelines.mw
@@ -55,7 +55,7 @@ There are many many things to check for a review. This list is provided to assis
 - '''MUST''': In the vast majority of cases, devel packages must require the base package using a fully versioned dependency: Requires: %{name} = %{version}-%{release} 

 - '''MUST''': Packages must NOT contain any .la libtool archives, these should be removed in the spec.

 - '''MUST''': Packages containing GUI applications must include a %{name}.desktop file, and that file must be properly installed with desktop-file-install in the %install section. This is described in detail in the [[Packaging/Guidelines#desktop| desktop files section of the Packaging Guidelines]] . If you feel that your packaged GUI application does not need a .desktop file, you must put a comment in the spec file with your explanation.

-- '''MUST''': Packages must not own files or directories already owned by other packages. The rule of thumb here is that the first package to be installed should own the files or directories that other packages may rely upon. This means, for example, that no package in Fedora should ever share ownership with any of the files or directories owned by the filesystem or man package. If you feel that you have a good reason to own a file or directory that another package owns, then please present that at package review time.

+- '''MUST''': Packages must own the files and directories they create unless they are already owned by another package.  Please see [[Packaging/Guidelines#File_and_Directory_Ownership| File and Directory Ownership]] for details and corner-cases.

 - '''MUST''': At the beginning of %install, each package MUST run rm -rf %{buildroot} ([[Packaging/Guidelines#UsingBuildRootOptFlags| or $RPM_BUILD_ROOT]] ). See [[Packaging/Guidelines#PreppingBuildRootForInstall| Prepping BuildRoot For %install]]  for details.

 - '''MUST''': All filenames in rpm packages must be valid UTF-8.

 '''SHOULD Items:'''

From 0da38622b47d71beb3f5d5f65196d18f4c0872e6 Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Oct 15 2008 20:18:22 +0000
Subject: [PATCH 138/3559] Undo revision 55162 by [[Special:Contributions/Toshio|Toshio]] ([[User talk:Toshio|Talk]])


---

diff --git a/Packaging:ReviewGuidelines.mw b/Packaging:ReviewGuidelines.mw
index 83b267b..89e40cd 100644
--- a/Packaging:ReviewGuidelines.mw
+++ b/Packaging:ReviewGuidelines.mw
@@ -55,7 +55,7 @@ There are many many things to check for a review. This list is provided to assis
 - '''MUST''': In the vast majority of cases, devel packages must require the base package using a fully versioned dependency: Requires: %{name} = %{version}-%{release} 

 - '''MUST''': Packages must NOT contain any .la libtool archives, these should be removed in the spec.

 - '''MUST''': Packages containing GUI applications must include a %{name}.desktop file, and that file must be properly installed with desktop-file-install in the %install section. This is described in detail in the [[Packaging/Guidelines#desktop| desktop files section of the Packaging Guidelines]] . If you feel that your packaged GUI application does not need a .desktop file, you must put a comment in the spec file with your explanation.

-- '''MUST''': Packages must own the files and directories they create unless they are already owned by another package.  Please see [[Packaging/Guidelines#File_and_Directory_Ownership| File and Directory Ownership]] for details and corner-cases.

+- '''MUST''': Packages must not own files or directories already owned by other packages. The rule of thumb here is that the first package to be installed should own the files or directories that other packages may rely upon. This means, for example, that no package in Fedora should ever share ownership with any of the files or directories owned by the filesystem or man package. If you feel that you have a good reason to own a file or directory that another package owns, then please present that at package review time.

 - '''MUST''': At the beginning of %install, each package MUST run rm -rf %{buildroot} ([[Packaging/Guidelines#UsingBuildRootOptFlags| or $RPM_BUILD_ROOT]] ). See [[Packaging/Guidelines#PreppingBuildRootForInstall| Prepping BuildRoot For %install]]  for details.

 - '''MUST''': All filenames in rpm packages must be valid UTF-8.

 '''SHOULD Items:'''

From a949b750b3116c86437442fd2b79bdbbc36fa9c6 Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Oct 15 2008 20:22:59 +0000
Subject: [PATCH 139/3559] /* File and Directory Ownership */


---

diff --git a/Packaging:Guidelines.mw b/Packaging:Guidelines.mw
index cabce2e..fd82ae2 100644
--- a/Packaging:Guidelines.mw
+++ b/Packaging:Guidelines.mw
@@ -750,9 +750,9 @@ Foo-Animal-Llama puts files into /usr/share/Foo/Animal/Llama
Neither package depends on the other one. Neither package depends on any other package which owns the /usr/share/Foo/Animal/ directory. In this case, each package must own the /usr/share/Foo/Animal/ directory. -In all cases we are guarding against unowned directories being present on a system. Unowned directories are affected by the umask of the user installing the package and thus can be a security risk or lead to packages which won't run. - +In all cases we are guarding against unowned directories being present on a system. Please see [[Packaging/UnownedDirectories]] for the details. {{Anchor|UsersAndGroups}} + == Users and Groups == Some packages require or benefit from dedicated runtime user and/or group accounts. Guidelines for handling these cases are in a separate [[Packaging/UsersAndGroups]] document. From a624974456b230fc40bca2b38c6f28939236d406 Mon Sep 17 00:00:00 2001 From: Toshio Date: Oct 15 2008 22:17:16 +0000 Subject: [PATCH 140/3559] *Empty MediaWiki Message* --- diff --git a/Packaging:GuidelinesTodo.mw b/Packaging:GuidelinesTodo.mw index aa69d0e..a2bf80c 100644 --- a/Packaging:GuidelinesTodo.mw +++ b/Packaging:GuidelinesTodo.mw @@ -19,6 +19,10 @@ Status should be one of: |- style="color: white; background-color: #3074c2; font-weight: bold" |Task Name||Owner||Resolution Date||Notes |- +|[[SIGs/MinGW|MinGW]] ||[[RichardJones]]|| Discuss soon? ||[[PackagingDrafts/MinGW]] - As of 2008-09-22 these are in a good state for discussion. +|- +|Unowned Directories||abadger1999|| 2008-10-30 ||[[PackagingDrafts/UnownedDirectories]] Clarification only +|- |PatchUpstreamStatus||walters||2008-09-16||[[PackagingDrafts/PatchUpstreamStatus]] |- |DesktopVerify||caillon||2008-09-16||[[PackagingDrafts/DesktopVerify]] From 83e9d746453c0840111494429297754abb0c5903 Mon Sep 17 00:00:00 2001 From: Tibbs Date: Oct 24 2008 18:40:02 +0000 Subject: [PATCH 141/3559] *Empty MediaWiki Message* --- diff --git a/Packaging:Conflicts.mw b/Packaging:Conflicts.mw index 752169e..4c98084 100644 --- a/Packaging:Conflicts.mw +++ b/Packaging:Conflicts.mw @@ -73,4 +73,4 @@ There are many types of files which can conflict between multiple packages. Fedo {{Anchor|OtherUsesOfConflicts}} == Other Uses of Conflicts: == -If you find yourself in a situation where you feel that your package has to conflict with another package (either explicitly or implicitly), but does not fit the documented accepted cases above, then you need to make your case to the [wiki:Self:Packaging/Committee Fedora Packaging Committee] . If they agree, then, and only then can you use Conflicts: in a Fedora package. Remember, whenever you use Conflicts:, you are also required to include the reasoning in a comment next to the Conflicts: entry, so that it will be abundantly clear why it needed to exist. +If you find yourself in a situation where you feel that your package has to conflict with another package (either explicitly or implicitly), but does not fit the documented accepted cases above, then you need to make your case to the [[Packaging/Committee |Fedora Packaging Committee]]. If they agree, then, and only then can you use Conflicts: in a Fedora package. Remember, whenever you use Conflicts:, you are also required to include the reasoning in a comment next to the Conflicts: entry, so that it will be abundantly clear why it needed to exist. From 11aef99fda32440740c893763e15916fdd1b7590 Mon Sep 17 00:00:00 2001 From: Spot Date: Oct 29 2008 14:04:11 +0000 Subject: [PATCH 142/3559] /* Versioned MODULE_COMPAT_ Requires */ --- diff --git a/Packaging:Perl.mw b/Packaging:Perl.mw index e058d5a..1c6f0fe 100644 --- a/Packaging:Perl.mw +++ b/Packaging:Perl.mw @@ -46,7 +46,7 @@ Historically, buildrequiring a core module (that is, one provided by the perl pa All perl modules must include the versioned MODULE_COMPAT Requires: 
-Requires:  perl(:MODULE_COMPAT_%(eval "%{__perl} -V:version"; echo $version))
+Requires:  perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo $version))
This is to ensure that perl packages have a dependency on a perl which provides the appropriate versioned directory structure (otherwise, the modules won't be found). From 29bdb5682593602dd2beb6cbb0421a4ed6b72fd4 Mon Sep 17 00:00:00 2001 From: Tibbs Date: Nov 07 2008 16:03:40 +0000 Subject: [PATCH 143/3559] Undo some wiki conversion damage. --- diff --git a/Packaging:LicensingGuidelines.mw b/Packaging:LicensingGuidelines.mw index a0455a8..bae237d 100644 --- a/Packaging:LicensingGuidelines.mw +++ b/Packaging:LicensingGuidelines.mw @@ -79,6 +79,7 @@ License: GPLv2+ and BSD * Including a file as %doc which contains the licensing breakdown for the packaged files, then using: 
+# For a breakdown of the licensing, see PACKAGE-LICENSING
* Noting the license above the appropriate %files section: 
@@ -93,6 +94,7 @@ License: GPLv2+ and BSD
{{Anchor|CombinedDualAndMultipleLicensing}} + === Combined Dual and Multiple Licensing Scenario === If you are unlucky enough that your package possesses items multiple, distinct, and independent licenses...AND some of those items are dual licensed, you must note the dual licensed items by wrapping them with parenthesis (). Otherwise, the guidelines for Dual and Multiple Licensing apply. From 1385c58cc10618e3dbfa34e3434a8d239e8848d6 Mon Sep 17 00:00:00 2001 From: Spot Date: Nov 18 2008 15:31:56 +0000 Subject: [PATCH 144/3559] /* Resolved items */ --- diff --git a/Packaging:GuidelinesTodo.mw b/Packaging:GuidelinesTodo.mw index a2bf80c..9b635b4 100644 --- a/Packaging:GuidelinesTodo.mw +++ b/Packaging:GuidelinesTodo.mw @@ -19,7 +19,7 @@ Status should be one of: |- style="color: white; background-color: #3074c2; font-weight: bold" |Task Name||Owner||Resolution Date||Notes |- -|[[SIGs/MinGW|MinGW]] ||[[RichardJones]]|| Discuss soon? ||[[PackagingDrafts/MinGW]] - As of 2008-09-22 these are in a good state for discussion. +|[[SIGs/MinGW|MinGW]] ||[[RichardJones]]|| 2008-11-18 ||[[PackagingDrafts/MinGW]] - As of 2008-09-22 these are in a good state for discussion. |- |Unowned Directories||abadger1999|| 2008-10-30 ||[[PackagingDrafts/UnownedDirectories]] Clarification only |- @@ -202,6 +202,8 @@ Status should be one of: |- style="color: white; background-color: #3074c2; font-weight: bold" |Task Name||Owner||Resolution Date||Notes |- +| Avoid packing junk in CMake/CPack || dchen ||2008-11-18 || [[PackagingDrafts/CmakeCpack]] isn't relevant for a Fedora Packaging guideline +|- |Package Names should be all lowercase||abadger1999|| 2008-04-08 ||["PackagingDrafts/ASCIINamingLowercase"] |- |RPMGroups||[wiki:Self:TomCallaway spot] ||2006-11-28||Revisit Making Group optional at some point, when RPM is ready. From 9760ff387eed32349336ff4b903c4414ba37c103 Mon Sep 17 00:00:00 2001 From: Spot Date: Dec 09 2008 18:14:59 +0000 Subject: [PATCH 145/3559] *Empty MediaWiki Message* --- diff --git a/Packaging:GuidelinesTodo.mw b/Packaging:GuidelinesTodo.mw index 9b635b4..435eafc 100644 --- a/Packaging:GuidelinesTodo.mw +++ b/Packaging:GuidelinesTodo.mw @@ -10,6 +10,12 @@ Status should be one of: {| border="1" |- style="color: white; background-color: #3074c2; font-weight: bold" |Status||Task Name||Owner||Meeting Date||Notes +|- +|ratify||RubyGem with C code || mtasaka ||2008-12-09||[[PackagingDrafts/RubyGem with C code]] +|- +|ratify||Font packaging automation || [[Nicolas Mailhot]] ||2008-12-09||[[PackagingDrafts/Fonts_packaging_automation]] Refactoring of Fedora fonts packaging guidelines and template +|- +|ratify||Updates to the Eclipse plugin guidelines || overholt || 2008-12-09 || Was previously discussed [https://www.redhat.com/archives/fedora-packaging/2008-October/msg00121.html here]. Only difference from that diff is the addition of Fedora 9 notes as requested [https://www.redhat.com/archives/fedora-packaging/2008-December/msg00006.html here]. http://overholt.fedorapeople.org/EclipsePlugins.diff |} {{:PackagingDrafts/DraftsTodo}} From 5208ffddd5a92417ff4a74fd1d438848b1fe9b93 Mon Sep 17 00:00:00 2001 From: Spot Date: Dec 09 2008 18:19:18 +0000 Subject: [PATCH 146/3559] /* Action Items */ --- diff --git a/Packaging:GuidelinesTodo.mw b/Packaging:GuidelinesTodo.mw index 435eafc..dc4191d 100644 --- a/Packaging:GuidelinesTodo.mw +++ b/Packaging:GuidelinesTodo.mw @@ -16,6 +16,8 @@ Status should be one of: |ratify||Font packaging automation || [[Nicolas Mailhot]] ||2008-12-09||[[PackagingDrafts/Fonts_packaging_automation]] Refactoring of Fedora fonts packaging guidelines and template |- |ratify||Updates to the Eclipse plugin guidelines || overholt || 2008-12-09 || Was previously discussed [https://www.redhat.com/archives/fedora-packaging/2008-October/msg00121.html here]. Only difference from that diff is the addition of Fedora 9 notes as requested [https://www.redhat.com/archives/fedora-packaging/2008-December/msg00006.html here]. http://overholt.fedorapeople.org/EclipsePlugins.diff +|- +|ratify||Make adherence to the FHS a '''MUST''', with the added exception of /usr/ for cross toolchains.|| spot || 2008-12-09 ||https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00074.html "with exceptions for libexecdir (specified in the [http://www.gnu.org/prep/standards/standards.html#Directory-Variables GNU Coding Standards]) and /usr/target for crosscompilers" |} {{:PackagingDrafts/DraftsTodo}} From 987543b689432cf9d7fab0b24548739559e28aad Mon Sep 17 00:00:00 2001 From: Spot Date: Dec 16 2008 22:22:37 +0000 Subject: [PATCH 147/3559] /* License: field */ --- diff --git a/Packaging:LicensingGuidelines.mw b/Packaging:LicensingGuidelines.mw index bae237d..d7d2509 100644 --- a/Packaging:LicensingGuidelines.mw +++ b/Packaging:LicensingGuidelines.mw @@ -28,6 +28,10 @@ The License: field refers to the licenses of the contents of the '''''binary'''' === Valid License Short Names === The License: field must be filled with the appropriate license Short License identifier(s) from the "Good License" tables on the [[Licensing| Fedora Licensing]] page. If your license does not appear in the tables, it needs to be sent to fedora-legal-list@redhat.com (note that this list is moderated, only members may directly post). If the license is approved, it will be added to the appropriate table. +{{Anchor|License Text}} +=== License Text === +If (and only if) the source package includes the text of the license(s) in its own file, then that file, containing the text of the license(s) for the package must be included in %doc. If the source package does not include the text of the license(s), the packager should contact upstream and encourage them to correct this mistake. + {{Anchor|Distributable}} === "Distributable" === In the past, Fedora (and Red Hat Linux) packages have used "Distributable" in the License: field. In virtually all of these cases, this was not correct. Fedora no longer permits packages to use "Distributable" as a valid License. If your package contains content which is freely redistributable without restrictions, but does not contain any license other than explicit permission from the content owner/creator, then that package can use "Freely redistributable without restriction" as its License: identifier. From b345f68ddbe5bc052c5cffb2f783ecd1e4ef024a Mon Sep 17 00:00:00 2001 From: Spot Date: Dec 16 2008 22:37:08 +0000 Subject: [PATCH 148/3559] add Spec Legibility --- diff --git a/Packaging:Guidelines.mw b/Packaging:Guidelines.mw index fd82ae2..4f554b6 100644 --- a/Packaging:Guidelines.mw +++ b/Packaging:Guidelines.mw @@ -7,11 +7,9 @@ It is the reviewer's responsibility to point out specific problems with a packag Please remember that any package that you submit must also conform to the [[Packaging/ReviewGuidelines| Review Guidelines]] . '''Author:''' [[TomCallaway| Tom 'spot' Callaway]] (based on many other documents)
-'''Revision:''' 0.93
+'''Revision:''' 0.95
'''Initial Draft:''' Wednesday Feb 23, 2005
-'''Last Revised:''' Tuesday Sep 16, 2008
- - +'''Last Revised:''' Tuesday Dec 16, 2008
{{Anchor|Naming}} == Naming == @@ -48,6 +46,10 @@ Packages which require non-open source components to build are also not permitte * Some software (usually related to compilers or cross-compiler environments) cannot be build without the use of a previous toolchain or development environment (open source). If you have a package which meets this criteria, contact the Fedora Packaging Committee for approval. * An exception is made for binary firmware, as long as it meets the requirements documented here: [[Packaging/LicensingGuidelines#BinaryFirmware BinaryFirmware]] +{{Anchor|Spec Legibility}} +== Spec Legibility == +All Fedora Package Spec Files must be legible. If the reviewer is unable to read the spec file, it will be impossible to perform a review. Fedora Spec files are not the place for entries into the [http://www.ioccc.org/ Obfuscated Code Contest]. + {{Anchor|PackageFromScratch}} == Writing a package from scratch == When writing a package from scratch, you should base your spec file on the Fedora spec file template (see [[Rpmdevtools]] ). Please put your preferences about spec file formatting and organization aside, and try to conform to this template as much as possible. This is not because we believe this is the only right way to write a spec file, but because it often makes it easier for QA to spot mistakes and quickly understand what you are trying to do. From c148df08dad4993bd78193332b26f02a984e2896 Mon Sep 17 00:00:00 2001 From: Spot Date: Dec 16 2008 22:49:30 +0000 Subject: [PATCH 149/3559] *Empty MediaWiki Message* --- diff --git a/Packaging:Guidelines.mw b/Packaging:Guidelines.mw index 4f554b6..8f6ae91 100644 --- a/Packaging:Guidelines.mw +++ b/Packaging:Guidelines.mw @@ -67,8 +67,13 @@ In particular, you should Keep old changelog entries to credit the original authors. Entries that are several years old or refer to ancient versions of the software may be erased. If you end up doing radical changes and re-write most of the spec file anyway, feel free to start the changelog from scratch. In other words, use your best judgement. -{{Anchor|layout}} +{{Anchor|Architecture Support}} +== Architecture Support == +All Fedora packages must successfully compile and build into binary rpms on at least one supported primary architecture. Fedora packagers should make every effort to support all [[Architectures#Primary_Architectures primary architectures]]. + +Content, code which does not need to compile or build, and architecture independent code (noarch) are notable exceptions. +{{Anchor|layout}} == Filesystem Layout == Fedora follows the [http://www.pathname.com/fhs/ Filesystem Hierarchy Standard] with regards to filesystem layout. The FHS defines where files should be placed on the system. Fedora packages should follow the FHS whenever possible. Any deviation from the FHS should be rationalized when the package is reviewed. From 2a5a4a4fe837effb798f3dfe5bcd4fabfbffb128 Mon Sep 17 00:00:00 2001 From: Spot Date: Dec 16 2008 22:50:08 +0000 Subject: [PATCH 150/3559] /* Architecture Support */ --- diff --git a/Packaging:Guidelines.mw b/Packaging:Guidelines.mw index 8f6ae91..9486dda 100644 --- a/Packaging:Guidelines.mw +++ b/Packaging:Guidelines.mw @@ -69,11 +69,12 @@ Keep old changelog entries to credit the original authors. Entries that are seve {{Anchor|Architecture Support}} == Architecture Support == -All Fedora packages must successfully compile and build into binary rpms on at least one supported primary architecture. Fedora packagers should make every effort to support all [[Architectures#Primary_Architectures primary architectures]]. +All Fedora packages must successfully compile and build into binary rpms on at least one supported primary architecture. Fedora packagers should make every effort to support all [[Architectures#Primary_Architectures|primary architectures]]. Content, code which does not need to compile or build, and architecture independent code (noarch) are notable exceptions. {{Anchor|layout}} + == Filesystem Layout == Fedora follows the [http://www.pathname.com/fhs/ Filesystem Hierarchy Standard] with regards to filesystem layout. The FHS defines where files should be placed on the system. Fedora packages should follow the FHS whenever possible. Any deviation from the FHS should be rationalized when the package is reviewed. From 384032084639f3e28c0323b879b3b8b8a443ce94 Mon Sep 17 00:00:00 2001 From: Spot Date: Dec 16 2008 22:55:39 +0000 Subject: [PATCH 151/3559] /* Architecture Support */ --- diff --git a/Packaging:Guidelines.mw b/Packaging:Guidelines.mw index 9486dda..04b7a89 100644 --- a/Packaging:Guidelines.mw +++ b/Packaging:Guidelines.mw @@ -73,6 +73,13 @@ All Fedora packages must successfully compile and build into binary rpms on at l Content, code which does not need to compile or build, and architecture independent code (noarch) are notable exceptions. +=== Architecture Build Failures === +If a Fedora package does not successfully compile, build or work on an architecture, then those architectures should be listed in the spec in ExcludeArch. Each architecture listed in ExcludeArch needs to have a bug filed in bugzilla, describing the reason that the package does not compile/build/work on that architecture. The bug number should then be placed in a comment, next to the corresponding ExcludeArch line. New packages will not have bugzilla entries during the review process, so they should put this description in the comment until the package is approved, then file the bugzilla entry, and replace the long explanation with the bug number. The bug should be marked as blocking one (or more) of the following bugs to simplify tracking such issues: +* [https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=FE-ExcludeArch-x86 FE-ExcludeArch-x86] +* [https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=FE-ExcludeArch-x64 FE-ExcludeArch-x64] +* [https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=FE-ExcludeArch-ppc FE-ExcludeArch-ppc] +* [https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=FE-ExcludeArch-ppc64 FE-ExcludeArch-ppc64] + {{Anchor|layout}} == Filesystem Layout == From 8a5fdf6d71710ce2e166b3c10edb8eb6ba4b75a8 Mon Sep 17 00:00:00 2001 From: Spot Date: Dec 16 2008 23:10:52 +0000 Subject: [PATCH 152/3559] *Empty MediaWiki Message* --- diff --git a/Packaging:Guidelines.mw b/Packaging:Guidelines.mw index 04b7a89..1820712 100644 --- a/Packaging:Guidelines.mw +++ b/Packaging:Guidelines.mw @@ -357,6 +357,25 @@ Compilers used to build packages should honor the applicable compiler flags set == Debuginfo packages == Packages should produce useful -debuginfo packages, or explicitly disable them when it is not possible to generate a useful one but rpmbuild would do it anyway. Whenever a -debuginfo package is explicitly disabled, an explanation why it was done is required in the specfile. Debuginfo packages are discussed in more detail in a separate document, [[Packaging/Debuginfo]] . +{{Anchor|SharedLibraries}} +== Shared Libraries == +Whenever possible (and feasible), Fedora Packages containing libraries should build them as shared libraries. In addition, every binary RPM package which contains shared library files (not just symlinks) in any of the dynamic linker's default paths, must call ldconfig in %post and %postun. If the package has multiple subpackages with libraries, each subpackage should also have a %post/%postun section that calls /sbin/ldconfig. An example of the correct syntax for this is: +
+%post -p /sbin/ldconfig
+
+%postun -p /sbin/ldconfig
+
+Note that this specific syntax only works if /sbin/ldconfig is the only call in %post and %postun. If you have additional commands to run during the scriptlet, call /sbin/ldconfig at the beginning of the scriptlet, like this: +
+%post
+/sbin/ldconfig
+/usr/bin/foo --add
+
+%postun
+/sbin/ldconfig
+/usr/bin/foo --remove
+
+ {{Anchor|StaticLibraries}} == Exclusion of Static Libraries == Packages including libraries should exclude static libs as far as possible (eg by configuring with ''--disable-static''). Static libraries should only be included in exceptional circumstances. Applications linking against libraries should as far as possible link against shared libraries not static versions. @@ -368,16 +387,14 @@ Libtool archives, ''foo.la'' files, should not be included. Packages using libto * In general, packagers are strongly encouraged not to ship static libs unless a compelling reason exists. * We want to be able to track which packages are using static libraries (so we can find which packages need to be rebuilt if a security flaw in a static library is fixed, for instance). There are two scenarios in which static libraries are packaged: -1. '''Static libraries and shared libraries.''' In this case, the static libraries must be placed in a ''*-static'' subpackage. Separating the static libraries from the other development files in ''*-devel'' allow us to track this usage by checking which packages Build''''''Require the ''*-static'' package. The intent is that whenever possible, packages will move away from using these static libraries, to the shared libraries. -2. '''Static libraries only.''' When a package only provides static libraries you can place all the static library files in the ''*-devel'' subpackage. When doing this you also must have a virtual Provide for the ''*-static'' package: -
-%package devel
-Provides: foo-static = %{version}-%{release}
-
+# '''Static libraries and shared libraries.''' In this case, the static libraries must be placed in a ''*-static'' subpackage. Separating the static libraries from the other development files in ''*-devel'' allow us to track this usage by checking which packages BuildRequire the ''*-static'' package. The intent is that whenever possible, packages will move away from using these static libraries, to the shared libraries. +# '''Static libraries only.''' When a package only provides static libraries you can place all the static library files in the ''*-devel'' subpackage. When doing this you also must have a virtual Provide for the ''*-static'' package: +
%package devel
+Provides: foo-static = %{version}-%{release}
Packages which explicitly need to link against the static version must BuildRequire: foo-static, so that the usage can be tracked. -* If (and only if) a package has shared libraries which require static libraries to be functional, the static libraries can be included in the ''*-devel'' subpackage. The devel subpackage must have a virtual Provide for the ''*-static'' package, and packages dependent on it must Build''''''Require the ''*-static'' package. +* If (and only if) a package has shared libraries which require static libraries to be functional, the static libraries can be included in the ''*-devel'' subpackage. The devel subpackage must have a virtual Provide for the ''*-static'' package, and packages dependent on it must BuildRequire the ''*-static'' package. {{Anchor|StaticLinkage}} === Staticly Linking Executables === From ba575364842100cf4f83a057ddb87aeabcd92aa4 Mon Sep 17 00:00:00 2001 From: Spot Date: Dec 16 2008 23:16:16 +0000 Subject: [PATCH 153/3559] *Empty MediaWiki Message* --- diff --git a/Packaging:ReviewGuidelines.mw b/Packaging:ReviewGuidelines.mw index 89e40cd..5df1c29 100644 --- a/Packaging:ReviewGuidelines.mw +++ b/Packaging:ReviewGuidelines.mw @@ -15,60 +15,61 @@ Contributors and reviewers should follow the [[Package Review Process]]. == Things To Check On Review == -There are many many things to check for a review. This list is provided to assist new reviewers in identifying areas that they should look for, but is by no means complete. Reviewers should use their own good judgement when reviewing packages. The items listed fall into two categories: '''SHOULD''' and '''MUST'''. Items marked as '''SHOULD''' are things that the package (or reviewer) '''SHOULD''' do, but is not required to do. Items marked as '''MUST''' are things that the package (or reviewer) '''MUST''' do. If a package fails a '''MUST''' item, that is considered a blocker. No package with blockers can be approved on a review. Those items must be fixed before approval can be given. +There are many many things to check for a review. This list is provided to assist new reviewers in identifying areas that they should look for, but is by no means complete. Reviewers should use their own good judgement when reviewing packages. The items listed fall into two categories: '''SHOULD''' and '''MUST'''. -'''MUST Items:''' +{{admon/warning|MUST Items|Items marked as '''MUST''' are things that the package (or reviewer) '''MUST''' do. If a package fails a '''MUST''' item, that is considered a blocker. No package with blockers can be approved on a review. Those items must be fixed before approval can be given. }} -- '''MUST''': rpmlint must be run on every package. The output should be posted in the review.
-- '''MUST''': The package must be named according to the [[Packaging/NamingGuidelines| Package Naming Guidelines]] .
-- '''MUST''': The spec file name must match the base package %{name}, in the format %{name}.spec unless your package has an exemption on [[Packaging/NamingGuidelines| Package Naming Guidelines]] .
-- '''MUST''': The package must meet the [[Packaging/Guidelines| Packaging Guidelines]] .
-- '''MUST''': The package must be licensed with a Fedora approved license and meet the [[Packaging/LicensingGuidelines| Licensing Guidelines]] .
-- '''MUST''': The License field in the package spec file must match the actual license.
-- '''MUST''': If (and only if) the source package includes the text of the license(s) in its own file, then that file, containing the text of the license(s) for the package must be included in %doc.
-- '''MUST''': The spec file must be written in American English.
-- '''MUST''': The spec file for the package MUST be legible. If the reviewer is unable to read the spec file, it will be impossible to perform a review. Fedora is not the place for entries into the Obfuscated Code Contest (http://www.ioccc.org/).
-- '''MUST''': The sources used to build the package must match the upstream source, as provided in the spec URL. Reviewers should use md5sum for this task. If no upstream URL can be specified for this package, please see the [[Packaging/SourceURL| Source URL Guidelines]] for how to deal with this.
-- '''MUST''': The package must successfully compile and build into binary rpms on at least one supported architecture.
-- '''MUST''': If the package does not successfully compile, build or work on an architecture, then those architectures should be listed in the spec in ExcludeArch. Each architecture listed in ExcludeArch needs to have a bug filed in bugzilla, describing the reason that the package does not compile/build/work on that architecture. The bug number should then be placed in a comment, next to the corresponding ExcludeArch line. New packages will not have bugzilla entries during the review process, so they should put this description in the comment until the package is approved, then file the bugzilla entry, and replace the long explanation with the bug number. The bug should be marked as blocking one (or more) of the following bugs to simplify tracking such issues: [https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=FE-ExcludeArch-x86 FE-ExcludeArch-x86] , [https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=FE-ExcludeArch-x64 FE-ExcludeArch-x64] , [https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=FE-ExcludeArch-ppc FE-ExcludeArch-ppc] , [https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=FE-ExcludeArch-ppc64 FE-ExcludeArch-ppc64]
-- '''MUST''': All build dependencies must be listed in BuildRequires, except for any that are listed in the [[Packaging/Guidelines#Exceptions |exceptions section of the Packaging Guidelines]] ; inclusion of those as BuildRequires is optional. Apply common sense.
-- '''MUST''': The spec file MUST handle locales properly. This is done by using the %find_lang macro. Using %{_datadir}/locale/* is strictly forbidden.
-- '''MUST''': Every binary RPM package which stores shared library files (not just symlinks) in any of the dynamic linker's default paths, must call ldconfig in %post and %postun. If the package has multiple subpackages with libraries, each subpackage should also have a %post/%postun section that calls /sbin/ldconfig. An example of the correct syntax for this is: -
-%post -p /sbin/ldconfig
+* '''MUST''': rpmlint must be run on every package. The output should be posted in the review.[[Packaging/Guidelines#rpmlint|Packaging Guidelines: Use rpmlint]] 

+* '''MUST''': The package must be named according to the [[Packaging/NamingGuidelines| Package Naming Guidelines]] .

+* '''MUST''': The spec file name must match the base package %{name}, in the format %{name}.spec unless your package has an exemption. [[Packaging/NamingGuidelines#Spec_file_name| Naming Guidelines: Spec File Naming]] . 

+* '''MUST''': The package must meet the [[Packaging/Guidelines|  Packaging Guidelines]] .

+* '''MUST''': The package must be licensed with a Fedora approved license and meet the [[Packaging/LicensingGuidelines|  Licensing Guidelines]] .

+* '''MUST''': The License field in the package spec file must match the actual license. [[Packaging/LicensingGuidelines#ValidLicenseShortNames| Licensing Guidelines: Valid License Short Names]]

+* '''MUST''': If (and only if) the source package includes the text of the license(s) in its own file, then that file, containing the text of the license(s) for the package must be included in %doc.[[Packaging/Licensing Guidelines#License Text |Licensing Guidelines: License Text]]

+* '''MUST''': The spec file must be written in American English. [[Packaging/Guidelines#summary|Packaging Guidelines: Summary]]

+* '''MUST''': The spec file for the package '''MUST''' be legible. [[Packaging/Guidelines#Spec_Legibility|Packaging Guidelines: Spec Legibility]]

+* '''MUST''': The sources used to build the package must match the upstream source, as provided in the spec URL. Reviewers should use md5sum for this task.  If no upstream URL can be specified for this package, please see the [[Packaging/SourceURL|  Source URL Guidelines]]  for how to deal with this.

+* '''MUST''': The package '''MUST''' successfully compile and build into binary rpms on at least one primary architecture. [[Packaging/Guidelines#Architecture_Support|Packaging Guidelines: Architecture Support]]

+* '''MUST''': If the package does not successfully compile, build or work on an architecture, then those architectures should be listed in the spec in ExcludeArch. Each architecture listed in ExcludeArch '''MUST''' have a bug filed in bugzilla, describing the reason that the package does not compile/build/work on that architecture. The bug number '''MUST''' be placed in a comment, next to the corresponding ExcludeArch line. [[Packaging/Guidelines#Architecture_Build_Failures|Packaging Guidelines: Architecture Build Failures]]

+* '''MUST''': All build dependencies must be listed in BuildRequires, except for any that are listed in the [[Packaging/Guidelines#Exceptions |exceptions section of the Packaging Guidelines]] ; inclusion of those as BuildRequires is optional. Apply common sense.

+* '''MUST''': The spec file MUST handle locales properly. This is done by using the %find_lang macro. Using %{_datadir}/locale/* is strictly forbidden.[[Packaging/Guidelines#Handling_Locale_Files|Packaging Guidelines: Handling Locale Files]]

+* '''MUST''': Every binary RPM package (or subpackage) which stores shared library files (not just symlinks) in any of the dynamic linker's default paths, must call ldconfig in %post and %postun. [[Packaging/Guidelines#Shared_Libraries|Packaging Guidelines: Shared Libraries]]

+
+* '''MUST''': If the package is designed to be relocatable, the packager must state this fact in the request for review, along with the rationalization for relocation of that specific package. Without this, use of Prefix: /usr is considered a blocker.

+* '''MUST''': A package must own all directories that it creates. If it does not create a directory that it uses, then it should require a package which does create that directory.  Refer to the [[Packaging/Guidelines#FileAndDirectoryOwnership|  Guidelines]]  for examples. 

+* '''MUST''': A package must not contain any duplicate files in the %files listing.

+* '''MUST''': Permissions on files must be set properly. Executables should be set with executable permissions, for example. Every %files section must include a %defattr(...) line.

+* '''MUST''': Each package must have a %clean section, which contains rm -rf %{buildroot} ([[Packaging/Guidelines#UsingBuildRootOptFlags| or $RPM_BUILD_ROOT]] ).

+* '''MUST''': Each package must consistently use macros, as described in the [[Packaging/Guidelines#macros|macros section of Packaging Guidelines]] . 

+* '''MUST''': The package must contain code, or permissable content. This is described in detail in the [[Packaging/Guidelines#CodeVsContent| code vs. content section of Packaging Guidelines]] . 

+* '''MUST''': Large documentation files should go in a -doc subpackage. (The definition of large is left up to the packager's best judgement, but is not restricted to size. Large can refer to either size or quantity)

+* '''MUST''': If a package includes something as %doc, it must not affect the runtime of the application. To summarize: If it is in %doc, the program must run properly if it is not present. 

+* '''MUST''': Header files must be in a -devel package.

+* '''MUST''': Static libraries must be in a -static package.

+* '''MUST''': Packages containing pkgconfig(.pc) files must 'Requires: pkgconfig' (for directory ownership and usability).

+* '''MUST''': If a package contains library files with a suffix (e.g. libfoo.so.1.1), then library files that end in .so (without suffix) must go in a -devel package.

+* '''MUST''': In the vast majority of cases, devel packages must require the base package using a fully versioned dependency: Requires: %{name} = %{version}-%{release} 

+* '''MUST''': Packages must NOT contain any .la libtool archives, these should be removed in the spec.

+* '''MUST''': Packages containing GUI applications must include a %{name}.desktop file, and that file must be properly installed with desktop-file-install in the %install section. This is described in detail in the [[Packaging/Guidelines#desktop| desktop files section of the Packaging Guidelines]] . If you feel that your packaged GUI application does not need a .desktop file, you must put a comment in the spec file with your explanation.

+* '''MUST''': Packages must not own files or directories already owned by other packages. The rule of thumb here is that the first package to be installed should own the files or directories that other packages may rely upon. This means, for example, that no package in Fedora should ever share ownership with any of the files or directories owned by the filesystem or man package. If you feel that you have a good reason to own a file or directory that another package owns, then please present that at package review time.

+* '''MUST''': At the beginning of %install, each package MUST run rm -rf %{buildroot} ([[Packaging/Guidelines#UsingBuildRootOptFlags| or $RPM_BUILD_ROOT]] ). See [[Packaging/Guidelines#PreppingBuildRootForInstall| Prepping BuildRoot For %install]]  for details.

+* '''MUST''': All filenames in rpm packages must be valid UTF-8.

 
-%postun -p /sbin/ldconfig
-

-- '''MUST''': If the package is designed to be relocatable, the packager must state this fact in the request for review, along with the rationalization for relocation of that specific package. Without this, use of Prefix: /usr is considered a blocker.
-- '''MUST''': A package must own all directories that it creates. If it does not create a directory that it uses, then it should require a package which does create that directory. Refer to the [[Packaging/Guidelines#FileAndDirectoryOwnership| Guidelines]] for examples.
-- '''MUST''': A package must not contain any duplicate files in the %files listing.
-- '''MUST''': Permissions on files must be set properly. Executables should be set with executable permissions, for example. Every %files section must include a %defattr(...) line.
-- '''MUST''': Each package must have a %clean section, which contains rm -rf %{buildroot} ([[Packaging/Guidelines#UsingBuildRootOptFlags| or $RPM_BUILD_ROOT]] ).
-- '''MUST''': Each package must consistently use macros, as described in the [[Packaging/Guidelines#macros|macros section of Packaging Guidelines]] .
-- '''MUST''': The package must contain code, or permissable content. This is described in detail in the [[Packaging/Guidelines#CodeVsContent| code vs. content section of Packaging Guidelines]] .
-- '''MUST''': Large documentation files should go in a -doc subpackage. (The definition of large is left up to the packager's best judgement, but is not restricted to size. Large can refer to either size or quantity)
-- '''MUST''': If a package includes something as %doc, it must not affect the runtime of the application. To summarize: If it is in %doc, the program must run properly if it is not present.
-- '''MUST''': Header files must be in a -devel package.
-- '''MUST''': Static libraries must be in a -static package.
-- '''MUST''': Packages containing pkgconfig(.pc) files must 'Requires: pkgconfig' (for directory ownership and usability).
-- '''MUST''': If a package contains library files with a suffix (e.g. libfoo.so.1.1), then library files that end in .so (without suffix) must go in a -devel package.
-- '''MUST''': In the vast majority of cases, devel packages must require the base package using a fully versioned dependency: Requires: %{name} = %{version}-%{release}
-- '''MUST''': Packages must NOT contain any .la libtool archives, these should be removed in the spec.
-- '''MUST''': Packages containing GUI applications must include a %{name}.desktop file, and that file must be properly installed with desktop-file-install in the %install section. This is described in detail in the [[Packaging/Guidelines#desktop| desktop files section of the Packaging Guidelines]] . If you feel that your packaged GUI application does not need a .desktop file, you must put a comment in the spec file with your explanation.
-- '''MUST''': Packages must not own files or directories already owned by other packages. The rule of thumb here is that the first package to be installed should own the files or directories that other packages may rely upon. This means, for example, that no package in Fedora should ever share ownership with any of the files or directories owned by the filesystem or man package. If you feel that you have a good reason to own a file or directory that another package owns, then please present that at package review time.
-- '''MUST''': At the beginning of %install, each package MUST run rm -rf %{buildroot} ([[Packaging/Guidelines#UsingBuildRootOptFlags| or $RPM_BUILD_ROOT]] ). See [[Packaging/Guidelines#PreppingBuildRootForInstall| Prepping BuildRoot For %install]] for details.
-- '''MUST''': All filenames in rpm packages must be valid UTF-8.
-'''SHOULD Items:''' +
+
+
-- '''SHOULD''': If the source package does not include license text(s) as a separate file from upstream, the packager SHOULD query upstream to include it.
-- '''SHOULD''': The description and summary sections in the package spec file should contain translations for supported Non-English languages, if available.
-- '''SHOULD''': The reviewer should test that the package builds in mock. See [[PackageMaintainers/MockTricks| MockTricks]] for details on how to do this.
-- '''SHOULD''': The package should compile and build into binary rpms on all supported architectures.
-- '''SHOULD''': The reviewer should test that the package functions as described. A package should not segfault instead of running, for example.
-- '''SHOULD''': If scriptlets are used, those scriptlets must be sane. This is vague, and left up to the reviewers judgement to determine sanity.
-- '''SHOULD''': Usually, subpackages other than devel should require the base package using a fully versioned dependency.
-- '''SHOULD''': The placement of pkgconfig(.pc) files depends on their usecase, and this is usually for development purposes, so should be placed in a -devel pkg. A reasonable exception is that the main pkg itself is a devel tool not installed in a user runtime, e.g. gcc or gdb.
-- '''SHOULD''': If the package has file dependencies outside of /etc, /bin, /sbin, /usr/bin, or /usr/sbin consider requiring the package which provides the file instead of the file itself. Please see [[Packaging/Guidelines#FileDeps| File Dependencies]] in the Guidelines for further information. +{{admon/important|SHOULD Items:|Items marked as '''SHOULD''' are things that the package (or reviewer) '''SHOULD''' do, but is not required to do.}} ----- -[[Category:Extras]] +* '''SHOULD''': If the source package does not include license text(s) as a separate file from upstream, the packager SHOULD query upstream to include it.
+* '''SHOULD''': The description and summary sections in the package spec file should contain translations for supported Non-English languages, if available.
+* '''SHOULD''': The reviewer should test that the package builds in mock. See [[PackageMaintainers/MockTricks| MockTricks]] for details on how to do this.
+* '''SHOULD''': The package should compile and build into binary rpms on all supported architectures.
+* '''SHOULD''': The reviewer should test that the package functions as described. A package should not segfault instead of running, for example.
+* '''SHOULD''': If scriptlets are used, those scriptlets must be sane. This is vague, and left up to the reviewers judgement to determine sanity.
+* '''SHOULD''': Usually, subpackages other than devel should require the base package using a fully versioned dependency.
+* '''SHOULD''': The placement of pkgconfig(.pc) files depends on their usecase, and this is usually for development purposes, so should be placed in a -devel pkg. A reasonable exception is that the main pkg itself is a devel tool not installed in a user runtime, e.g. gcc or gdb.
+* '''SHOULD''': If the package has file dependencies outside of /etc, /bin, /sbin, /usr/bin, or /usr/sbin consider requiring the package which provides the file instead of the file itself. Please see [[Packaging/Guidelines#FileDeps| File Dependencies]] in the Guidelines for further information. + +== References to the Fedora Packaging Guidelines == + From 5269e7d15120ddf1e6344c587fede8a93a4c0709 Mon Sep 17 00:00:00 2001 From: Spot Date: Dec 16 2008 23:16:43 +0000 Subject: [PATCH 154/3559] *Empty MediaWiki Message* --- diff --git a/Packaging:ReviewGuidelines.mw b/Packaging:ReviewGuidelines.mw index 5df1c29..efcf7fb 100644 --- a/Packaging:ReviewGuidelines.mw +++ b/Packaging:ReviewGuidelines.mw @@ -4,9 +4,9 @@ This is a set of guidelines for Package Reviews. Note that a complete list of things to check for would be impossible, but every attempt has been made to make this document as comprehensive as possible. Reviewers and contributors (packagers) should use their best judgement whenever items are unclear, and if in doubt, ask on the [https://www.redhat.com/mailman/listinfo/fedora-packaging fedora-packaging list] . '''Author:''' [[TomCallaway| Tom 'spot' Callaway]]
-'''Revision:''' 0.27
+'''Revision:''' 0.28
'''Initial Draft:''' Monday Jun 27, 2005
-'''Last Revised:''' Friday Nov 30, 2007
+'''Last Revised:''' Tuesday Dec 16, 2008
== Package Review Process == Contributors and reviewers should follow the [[Package Review Process]]. From 7481cb446b57167de4765105ff505ad7adcf9822 Mon Sep 17 00:00:00 2001 From: Spot Date: Dec 16 2008 23:19:49 +0000 Subject: [PATCH 155/3559] /* License Text */ --- diff --git a/Packaging:LicensingGuidelines.mw b/Packaging:LicensingGuidelines.mw index d7d2509..a275aef 100644 --- a/Packaging:LicensingGuidelines.mw +++ b/Packaging:LicensingGuidelines.mw @@ -15,10 +15,9 @@ All software in Fedora must be under licenses in the [http://fedoraproject.org/w If code is multiple licensed, and at least one of the licenses is approved for Fedora, that code can be included in Fedora under the approved license(s) (but only under the terms of the approved license(s)). {{Anchor|LicenseText}} -== License Text == -If (and only if) the source package includes the text of the license(s) in its own file, then that file, containing the text of the license(s) for the package, must be included as documentation. {{Anchor|LicenseField}} + == License: field == Every Fedora package must contain a License: entry. Maintainers should be aware that the contents of the License: field are understood to not be legally binding (only the source code itself is), but maintainers must make every possible effort to be accurate when filling the License: field. From 3bafd47d858fa2ec0a93a98c4693278ff4b0b327 Mon Sep 17 00:00:00 2001 From: Spot Date: Dec 16 2008 23:20:16 +0000 Subject: [PATCH 156/3559] /* Things To Check On Review */ --- diff --git a/Packaging:ReviewGuidelines.mw b/Packaging:ReviewGuidelines.mw index efcf7fb..285d822 100644 --- a/Packaging:ReviewGuidelines.mw +++ b/Packaging:ReviewGuidelines.mw @@ -25,7 +25,7 @@ There are many many things to check for a review. This list is provided to assis * '''MUST''': The package must meet the [[Packaging/Guidelines| Packaging Guidelines]] .
* '''MUST''': The package must be licensed with a Fedora approved license and meet the [[Packaging/LicensingGuidelines| Licensing Guidelines]] .
* '''MUST''': The License field in the package spec file must match the actual license. [[Packaging/LicensingGuidelines#ValidLicenseShortNames| Licensing Guidelines: Valid License Short Names]]
-* '''MUST''': If (and only if) the source package includes the text of the license(s) in its own file, then that file, containing the text of the license(s) for the package must be included in %doc.[[Packaging/Licensing Guidelines#License Text |Licensing Guidelines: License Text]]
+* '''MUST''': If (and only if) the source package includes the text of the license(s) in its own file, then that file, containing the text of the license(s) for the package must be included in %doc.[[Packaging/LicensingGuidelines#License Text |Licensing Guidelines: License Text]]
* '''MUST''': The spec file must be written in American English. [[Packaging/Guidelines#summary|Packaging Guidelines: Summary]]
* '''MUST''': The spec file for the package '''MUST''' be legible. [[Packaging/Guidelines#Spec_Legibility|Packaging Guidelines: Spec Legibility]]
* '''MUST''': The sources used to build the package must match the upstream source, as provided in the spec URL. Reviewers should use md5sum for this task. If no upstream URL can be specified for this package, please see the [[Packaging/SourceURL| Source URL Guidelines]] for how to deal with this.
From 14018d2e5795e3f1713f81180868253f3b04bd88 Mon Sep 17 00:00:00 2001 From: Spot Date: Dec 22 2008 20:25:32 +0000 Subject: [PATCH 193/3559] /* Exceptions */ --- diff --git a/Packaging:Guidelines.mw b/Packaging:Guidelines.mw index 1820712..49864e3 100644 --- a/Packaging:Guidelines.mw +++ b/Packaging:Guidelines.mw @@ -44,9 +44,10 @@ Packages which require non-open source components to build are also not permitte {{Anchor|SourceRequirementExceptions}} === Exceptions === * Some software (usually related to compilers or cross-compiler environments) cannot be build without the use of a previous toolchain or development environment (open source). If you have a package which meets this criteria, contact the Fedora Packaging Committee for approval. -* An exception is made for binary firmware, as long as it meets the requirements documented here: [[Packaging/LicensingGuidelines#BinaryFirmware BinaryFirmware]] +* An exception is made for binary firmware, as long as it meets the requirements documented here: [[Packaging/LicensingGuidelines#BinaryFirmware|BinaryFirmware]] {{Anchor|Spec Legibility}} + == Spec Legibility == All Fedora Package Spec Files must be legible. If the reviewer is unable to read the spec file, it will be impossible to perform a review. Fedora Spec files are not the place for entries into the [http://www.ioccc.org/ Obfuscated Code Contest]. From 48c09c130bfdf53153eb049934cea80d872b24fe Mon Sep 17 00:00:00 2001 From: Spot Date: Dec 25 2008 14:00:18 +0000 Subject: [PATCH 194/3559] *Empty MediaWiki Message* --- diff --git a/Packaging:Debuginfo.mw b/Packaging:Debuginfo.mw index 6d5df13..d252dbd 100644 --- a/Packaging:Debuginfo.mw +++ b/Packaging:Debuginfo.mw @@ -2,7 +2,7 @@ -This page contains information about debuginfo packages and common pitfalls about them for packagers. For usage information and an explanation why debuginfo packages are important, see StackTraces. +This page contains information about debuginfo packages and common pitfalls about them for packagers. For usage information and an explanation why debuginfo packages are important, see [[StackTraces]]. The discussion on this page assumes that the redhat-rpm-config package is installed. @@ -43,5 +43,5 @@ It is normal for noarch package builds to not produce a debuginfo package. If i * debuginfo package listings for Fedora Core and Extras, sorted by size. Most debuginfo packages roughly up to 20kB in size are candidates that should be examined - however significantly larger -debuginfo packages may suffer from the same problems too, esp. in the "missing -g" case. (URLs not pointing to download.fedora.redhat.com due to missing sort option in its dir listings.) * http://mirrors.kernel.org/fedora/core/development/i386/debug/?C=S;O=A * http://mirrors.kernel.org/fedora/extras/development/i386/debug/?C=S;O=A -* StackTraces +* [[StackTraces]] * rpmlint >= 0.77 From f4940edd08e3ae6c149c38c4cf0c7d95a25eb167 Mon Sep 17 00:00:00 2001 From: Spot Date: Jan 07 2009 18:31:28 +0000 Subject: [PATCH 195/3559] add guideline for no duplicate files --- diff --git a/Packaging:Guidelines.mw b/Packaging:Guidelines.mw index 49864e3..ee4ac6d 100644 --- a/Packaging:Guidelines.mw +++ b/Packaging:Guidelines.mw @@ -7,9 +7,9 @@ It is the reviewer's responsibility to point out specific problems with a packag Please remember that any package that you submit must also conform to the [[Packaging/ReviewGuidelines| Review Guidelines]] . '''Author:''' [[TomCallaway| Tom 'spot' Callaway]] (based on many other documents)
-'''Revision:''' 0.95
+'''Revision:''' 0.96
'''Initial Draft:''' Wednesday Feb 23, 2005
-'''Last Revised:''' Tuesday Dec 16, 2008
+'''Last Revised:''' Wednesday Jan 7, 2009
{{Anchor|Naming}} == Naming == @@ -784,8 +784,12 @@ Foo-Animal-Llama puts files into /usr/share/Foo/Animal/Llama Neither package depends on the other one. Neither package depends on any other package which owns the /usr/share/Foo/Animal/ directory. In this case, each package must own the /usr/share/Foo/Animal/ directory. In all cases we are guarding against unowned directories being present on a system. Please see [[Packaging/UnownedDirectories]] for the details. -{{Anchor|UsersAndGroups}} +{{Anchor|DuplicateFiles}} +=== Duplicate Files === +A Fedora package must not contain any duplicate files in the %files listing. + +{{Anchor|UsersAndGroups}} == Users and Groups == Some packages require or benefit from dedicated runtime user and/or group accounts. Guidelines for handling these cases are in a separate [[Packaging/UsersAndGroups]] document. From a1ae61e2c57e6b0b29fb2748f581b06ab075ec64 Mon Sep 17 00:00:00 2001 From: Spot Date: Jan 09 2009 18:07:10 +0000 Subject: [PATCH 196/3559] references for all must (and most shoulds) --- diff --git a/Packaging:ReviewGuidelines.mw b/Packaging:ReviewGuidelines.mw index 285d822..37c492b 100644 --- a/Packaging:ReviewGuidelines.mw +++ b/Packaging:ReviewGuidelines.mw @@ -4,9 +4,9 @@ This is a set of guidelines for Package Reviews. Note that a complete list of things to check for would be impossible, but every attempt has been made to make this document as comprehensive as possible. Reviewers and contributors (packagers) should use their best judgement whenever items are unclear, and if in doubt, ask on the [https://www.redhat.com/mailman/listinfo/fedora-packaging fedora-packaging list] . '''Author:''' [[TomCallaway| Tom 'spot' Callaway]]
-'''Revision:''' 0.28
+'''Revision:''' 0.29
'''Initial Draft:''' Monday Jun 27, 2005
-'''Last Revised:''' Tuesday Dec 16, 2008
+'''Last Revised:''' Friday Jan 9, 2009
== Package Review Process == Contributors and reviewers should follow the [[Package Review Process]]. @@ -34,26 +34,25 @@ There are many many things to check for a review. This list is provided to assis * '''MUST''': All build dependencies must be listed in BuildRequires, except for any that are listed in the [[Packaging/Guidelines#Exceptions |exceptions section of the Packaging Guidelines]] ; inclusion of those as BuildRequires is optional. Apply common sense.
* '''MUST''': The spec file MUST handle locales properly. This is done by using the %find_lang macro. Using %{_datadir}/locale/* is strictly forbidden.[[Packaging/Guidelines#Handling_Locale_Files|Packaging Guidelines: Handling Locale Files]]
* '''MUST''': Every binary RPM package (or subpackage) which stores shared library files (not just symlinks) in any of the dynamic linker's default paths, must call ldconfig in %post and %postun. [[Packaging/Guidelines#Shared_Libraries|Packaging Guidelines: Shared Libraries]]
- -* '''MUST''': If the package is designed to be relocatable, the packager must state this fact in the request for review, along with the rationalization for relocation of that specific package. Without this, use of Prefix: /usr is considered a blocker.
-* '''MUST''': A package must own all directories that it creates. If it does not create a directory that it uses, then it should require a package which does create that directory. Refer to the [[Packaging/Guidelines#FileAndDirectoryOwnership| Guidelines]] for examples.
-* '''MUST''': A package must not contain any duplicate files in the %files listing.
-* '''MUST''': Permissions on files must be set properly. Executables should be set with executable permissions, for example. Every %files section must include a %defattr(...) line.
-* '''MUST''': Each package must have a %clean section, which contains rm -rf %{buildroot} ([[Packaging/Guidelines#UsingBuildRootOptFlags| or $RPM_BUILD_ROOT]] ).
-* '''MUST''': Each package must consistently use macros, as described in the [[Packaging/Guidelines#macros|macros section of Packaging Guidelines]] .
-* '''MUST''': The package must contain code, or permissable content. This is described in detail in the [[Packaging/Guidelines#CodeVsContent| code vs. content section of Packaging Guidelines]] .
-* '''MUST''': Large documentation files should go in a -doc subpackage. (The definition of large is left up to the packager's best judgement, but is not restricted to size. Large can refer to either size or quantity)
-* '''MUST''': If a package includes something as %doc, it must not affect the runtime of the application. To summarize: If it is in %doc, the program must run properly if it is not present.
-* '''MUST''': Header files must be in a -devel package.
-* '''MUST''': Static libraries must be in a -static package.
-* '''MUST''': Packages containing pkgconfig(.pc) files must 'Requires: pkgconfig' (for directory ownership and usability).
-* '''MUST''': If a package contains library files with a suffix (e.g. libfoo.so.1.1), then library files that end in .so (without suffix) must go in a -devel package.
-* '''MUST''': In the vast majority of cases, devel packages must require the base package using a fully versioned dependency: Requires: %{name} = %{version}-%{release}
-* '''MUST''': Packages must NOT contain any .la libtool archives, these should be removed in the spec.
-* '''MUST''': Packages containing GUI applications must include a %{name}.desktop file, and that file must be properly installed with desktop-file-install in the %install section. This is described in detail in the [[Packaging/Guidelines#desktop| desktop files section of the Packaging Guidelines]] . If you feel that your packaged GUI application does not need a .desktop file, you must put a comment in the spec file with your explanation.
-* '''MUST''': Packages must not own files or directories already owned by other packages. The rule of thumb here is that the first package to be installed should own the files or directories that other packages may rely upon. This means, for example, that no package in Fedora should ever share ownership with any of the files or directories owned by the filesystem or man package. If you feel that you have a good reason to own a file or directory that another package owns, then please present that at package review time.
-* '''MUST''': At the beginning of %install, each package MUST run rm -rf %{buildroot} ([[Packaging/Guidelines#UsingBuildRootOptFlags| or $RPM_BUILD_ROOT]] ). See [[Packaging/Guidelines#PreppingBuildRootForInstall| Prepping BuildRoot For %install]] for details.
-* '''MUST''': All filenames in rpm packages must be valid UTF-8.
+* '''MUST''': If the package is designed to be relocatable, the packager must state this fact in the request for review, along with the rationalization for relocation of that specific package. Without this, use of Prefix: /usr is considered a blocker. [[Packaging/Guidelines#RelocatablePackages|Packaging Guidelines: Relocatable Packages]]
+* '''MUST''': A package must own all directories that it creates. If it does not create a directory that it uses, then it should require a package which does create that directory. [[Packaging/Guidelines#FileAndDirectoryOwnership|Packaging Guidelines: File And Directory Ownership]]
+* '''MUST''': A package must not contain any duplicate files in the %files listing. [[Packaging/Guidelines#DuplicateFiles|Packaging Guidelines: Duplicate Files]]
+* '''MUST''': Permissions on files must be set properly. Executables should be set with executable permissions, for example. Every %files section must include a %defattr(...) line. [[Packaging/Guidelines#FilePermissions|Packaging Guidelines: File Permissions]]
+* '''MUST''': Each package must have a %clean section, which contains rm -rf %{buildroot} ([[Packaging/Guidelines#UsingBuildRootOptFlags|or $RPM_BUILD_ROOT]]). [[Packaging/Guidelines#clean|Packaging Guidelines: %clean]]
+* '''MUST''': Each package must consistently use macros. [[Packaging/Guidelines#macros|Packaging Guidelines: Macros]]
+* '''MUST''': The package must contain code, or permissable content. [[Packaging/Guidelines#CodeVsContent|Packaging Guidelines: Code Vs. Content]]
+* '''MUST''': Large documentation files must go in a -doc subpackage. (The definition of large is left up to the packager's best judgement, but is not restricted to size. Large can refer to either size or quantity). [[Packaging/Guidelines#PackageDocumentation|Packaging Guidelines: Package Documentation]]
+* '''MUST''': If a package includes something as %doc, it must not affect the runtime of the application. To summarize: If it is in %doc, the program must run properly if it is not present. [[Packaging/Guidelines#PackageDocumentation|Packaging Guidelines: Package Documentation]]
+* '''MUST''': Header files must be in a -devel package. [[Packaging/Guidelines#DevelPackages|Packaging Guidelines: Devel Packages]]
+* '''MUST''': Static libraries must be in a -static package. [[Packaging/Guidelines#StaticLibraries|Packaging Guidelines: Packaging Static Libraries]]
+* '''MUST''': Packages containing pkgconfig(.pc) files must 'Requires: pkgconfig' (for directory ownership and usability). [[Packaging/Guidelines#PkgconfigFiles|Packaging Guidelines: Pkgconfig Files]]
+* '''MUST''': If a package contains library files with a suffix (e.g. libfoo.so.1.1), then library files that end in .so (without suffix) must go in a -devel package. [[Packaging/Guidelines#DevelPackages|Packaging Guidelines: Devel Packages]]
+* '''MUST''': In the vast majority of cases, devel packages must require the base package using a fully versioned dependency: Requires: %{name} = %{version}-%{release} [[Packaging/Guidelines#RequiringBasePackage|Packaging Guidelines: Requiring Base Package]]
+* '''MUST''': Packages must NOT contain any .la libtool archives, these must be removed in the spec if they are built.[[Packaging/Guidelines#StaticLibraries|Packaging Guidelines: Packaging Static Libraries]]
+* '''MUST''': Packages containing GUI applications must include a %{name}.desktop file, and that file must be properly installed with desktop-file-install in the %install section. If you feel that your packaged GUI application does not need a .desktop file, you must put a comment in the spec file with your explanation. [[Packaging/Guidelines#desktop|Packaging Guidelines: Desktop files]]
+* '''MUST''': Packages must not own files or directories already owned by other packages. The rule of thumb here is that the first package to be installed should own the files or directories that other packages may rely upon. This means, for example, that no package in Fedora should ever share ownership with any of the files or directories owned by the filesystem or man package. If you feel that you have a good reason to own a file or directory that another package owns, then please present that at package review time. [[Packaging/Guidelines#FileAndDirectoryOwnership|Packaging Guidelines: File And Directory Ownership]]
+* '''MUST''': At the beginning of %install, each package MUST run rm -rf %{buildroot} ([[Packaging/Guidelines#UsingBuildRootOptFlags|or $RPM_BUILD_ROOT]]). [[Packaging/Guidelines#PreppingBuildRootForInstall|Packaging Guidelines: Prepping BuildRoot For %install]]
+* '''MUST''': All filenames in rpm packages must be valid UTF-8. [[Packaging/Guidelines#FilenameEncoding|Packaging Guidelines: Filename Encoding]]

@@ -61,15 +60,15 @@ There are many many things to check for a review. This list is provided to assis {{admon/important|SHOULD Items:|Items marked as '''SHOULD''' are things that the package (or reviewer) '''SHOULD''' do, but is not required to do.}} -* '''SHOULD''': If the source package does not include license text(s) as a separate file from upstream, the packager SHOULD query upstream to include it.
-* '''SHOULD''': The description and summary sections in the package spec file should contain translations for supported Non-English languages, if available.
-* '''SHOULD''': The reviewer should test that the package builds in mock. See [[PackageMaintainers/MockTricks| MockTricks]] for details on how to do this.
-* '''SHOULD''': The package should compile and build into binary rpms on all supported architectures.
+* '''SHOULD''': If the source package does not include license text(s) as a separate file from upstream, the packager SHOULD query upstream to include it. [[Packaging/LicensingGuidelines#License_Text|Licensing Guidelines: License Text]]
+* '''SHOULD''': The description and summary sections in the package spec file should contain translations for supported Non-English languages, if available. [[Packaging/Guidelines#summary|Packaging Guidelines: Summary and description]]
+* '''SHOULD''': The reviewer should test that the package builds in mock. [[PackageMaintainers/MockTricks|Mock Tricks]]
+* '''SHOULD''': The package should compile and build into binary rpms on all supported architectures. [[Packaging/Guidelines#ArchitectureSupport|Packaging Guidelines: Architecture Support]]
* '''SHOULD''': The reviewer should test that the package functions as described. A package should not segfault instead of running, for example.
-* '''SHOULD''': If scriptlets are used, those scriptlets must be sane. This is vague, and left up to the reviewers judgement to determine sanity.
-* '''SHOULD''': Usually, subpackages other than devel should require the base package using a fully versioned dependency.
-* '''SHOULD''': The placement of pkgconfig(.pc) files depends on their usecase, and this is usually for development purposes, so should be placed in a -devel pkg. A reasonable exception is that the main pkg itself is a devel tool not installed in a user runtime, e.g. gcc or gdb.
-* '''SHOULD''': If the package has file dependencies outside of /etc, /bin, /sbin, /usr/bin, or /usr/sbin consider requiring the package which provides the file instead of the file itself. Please see [[Packaging/Guidelines#FileDeps| File Dependencies]] in the Guidelines for further information. +* '''SHOULD''': If scriptlets are used, those scriptlets must be sane. This is vague, and left up to the reviewers judgement to determine sanity. [[Packaging/Guidelines#Scriptlets|Packaging Guidelines: Scriptlets]]
+* '''SHOULD''': Usually, subpackages other than devel should require the base package using a fully versioned dependency. [[Packaging/Guidelines#RequiringBasePackage|Packaging Guidelines: Requiring Base Package]]
+* '''SHOULD''': The placement of pkgconfig(.pc) files depends on their usecase, and this is usually for development purposes, so should be placed in a -devel pkg. A reasonable exception is that the main pkg itself is a devel tool not installed in a user runtime, e.g. gcc or gdb. [[Packaging/Guidelines#PkgconfigFiles|Packaging Guidelines: Pkgconfig Files]]
+* '''SHOULD''': If the package has file dependencies outside of /etc, /bin, /sbin, /usr/bin, or /usr/sbin consider requiring the package which provides the file instead of the file itself. [[Packaging/Guidelines#FileDeps|Packaging Guidelines: File Dependencies]] == References to the Fedora Packaging Guidelines == From 43ff72031f759a9a213f34c1e73512e6af1a7c82 Mon Sep 17 00:00:00 2001 From: Spot Date: Jan 09 2009 18:07:31 +0000 Subject: [PATCH 197/3559] file permissions, clean, devel packages, pkgconfig, scriptlet reorg --- diff --git a/Packaging:Guidelines.mw b/Packaging:Guidelines.mw index ee4ac6d..1262571 100644 --- a/Packaging:Guidelines.mw +++ b/Packaging:Guidelines.mw @@ -7,9 +7,9 @@ It is the reviewer's responsibility to point out specific problems with a packag Please remember that any package that you submit must also conform to the [[Packaging/ReviewGuidelines| Review Guidelines]] . '''Author:''' [[TomCallaway| Tom 'spot' Callaway]] (based on many other documents)
-'''Revision:''' 0.96
+'''Revision:''' 0.97
'''Initial Draft:''' Wednesday Feb 23, 2005
-'''Last Revised:''' Wednesday Jan 7, 2009
+'''Last Revised:''' Friday Jan 9, 2009
{{Anchor|Naming}} == Naming == @@ -68,7 +68,7 @@ In particular, you should Keep old changelog entries to credit the original authors. Entries that are several years old or refer to ancient versions of the software may be erased. If you end up doing radical changes and re-write most of the spec file anyway, feel free to start the changelog from scratch. In other words, use your best judgement. -{{Anchor|Architecture Support}} +{{Anchor|ArchitectureSupport}} == Architecture Support == All Fedora packages must successfully compile and build into binary rpms on at least one supported primary architecture. Fedora packagers should make every effort to support all [[Architectures#Primary_Architectures|primary architectures]]. @@ -151,9 +151,9 @@ You must use one of the following formats: == BuildRoot tag == -The ''!BuildRoot'' value MUST be below %{_tmppath}/ and MUST contain at least %{name}, %{version} and %{release}. It may invoke mktemp since this is guaranteed to exist on every system. From there, packagers are expected to use a sane ''!BuildRoot''. +The ''BuildRoot'' value MUST be below %{_tmppath}/ and MUST contain at least %{name}, %{version} and %{release}. It may invoke mktemp since this is guaranteed to exist on every system. From there, packagers are expected to use a sane ''BuildRoot''. -The ''recommended'' values for the ''!BuildRoot'' tag are (in descending order of preference) : +The ''recommended'' values for the ''BuildRoot'' tag are (in descending order of preference) : 
 %(mktemp -ud %{_tmppath}/%{name}-%{version}-%{release}-XXXXXX)
 %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
@@ -164,7 +164,7 @@ At one point, the second was a mandatory value, but it is now left to the packag
 
 {{Anchor|PreppingBuildRootForInstall}}
 === Prepping BuildRoot For %install ===
-It is important to properly prepare the !BuildRoot in the %install section of your package before it is used. Every Fedora package MUST have an %install section that begins with either:
+It is important to properly prepare the ''BuildRoot'' in the %install section of your package before it is used. Every Fedora package MUST have an %install section that begins with either:
 
 
 %install
@@ -178,7 +178,15 @@ or
 rm -rf $RPM_BUILD_ROOT
 

 
-This is to ensure that the !BuildRoot will be created fresh during the %install section.
+This is to ensure that the ''BuildRoot'' will be created fresh during the %install section.
+
+{{Anchor|Clean}}
+== %clean ==
+Each package must have a %clean section, which contains rm -rf %{buildroot} ([[Packaging/Guidelines#UsingBuildRootOptFlags|or $RPM_BUILD_ROOT]]).

+

+In the past, some packages checked that %{buildroot} was not / before deleting it. This is not necessary in Fedora, for several reasons:
+* All Fedora packages are required to have a sane ''BuildRoot'', see: [[Packaging/Guidelines#BuildRoot]]
+* In Fedora 10 (and newer), rpm sets a sane ''BuildRoot'' by default (and ignores any spec defined ''BuildRoot'')
 
 {{Anchor|Requires}}
 == Requires ==
@@ -332,11 +340,10 @@ which
{{Anchor|summary}} - == Summary and description == The summary should be a short and concise description of the package. The description expands upon this. Do not include installation instructions in the description; it is not a manual. If the package requires some manual configuration or there are other important instructions to the user, refer the user to the documentation in the package. Add a ''README.Fedora'', or similar, if you feel this is necessary. Also, please make sure that there are no lines in the description longer than 80 characters. -Please put personal preferences aside and use American English spelling in the summary and description. Anything else belongs in localized versions. +Please put personal preferences aside and use American English spelling in the summary and description. Packages can contain additional translated summary/description for supported Non-English languages, if available. {{Anchor|PackageEncoding}} == Encoding == @@ -350,6 +357,8 @@ Similarly, filenames that contain non-ASCII characters must be encoded as UTF-8. == Documentation == Any relevant documentation included in the source distribution should be included in the package. Irrelevant documentation include build instructions, the omnipresent ''INSTALL'' file containing generic build instructions, for example, and documentation for non-Linux systems, e.g. ''README.MSDOS''. Pay also attention about which subpackage you include documentation in, for example API documentation belongs in the -devel subpackage, not the main one. Or if there's a lot of documentation, consider putting it into a subpackage. In this case, it is recommended to use *-doc as the subpackage name, and Documentation as the value of the Group tag. +Also, if a package includes something as %doc, it must not affect the runtime of the application. To summarize: If it is in %doc, the program must run properly if it is not present. + {{Anchor|CompilerFlags}} == Compiler flags == Compilers used to build packages should honor the applicable compiler flags set in the system rpm configuration. As of Aug 2006, this means in practice $RPM_OPT_FLAGS/%{optflags} for C, C++, and Fortran compilers. Honoring means that the contents of that variable is used as the basis of the flags actually used by the compiler during the package build. Adding to and overriding or filtering parts of these flags is permitted if there's a good reason to do so; the rationale for doing so should be reviewed and documented in the specfile especially in the override and filter cases. @@ -358,6 +367,24 @@ Compilers used to build packages should honor the applicable compiler flags set == Debuginfo packages == Packages should produce useful -debuginfo packages, or explicitly disable them when it is not possible to generate a useful one but rpmbuild would do it anyway. Whenever a -debuginfo package is explicitly disabled, an explanation why it was done is required in the specfile. Debuginfo packages are discussed in more detail in a separate document, [[Packaging/Debuginfo]] . +{{Anchor|DevelPackages}} +== Devel Packages == +If the software being packaged contains files intended solely for development, those files should be put in a -devel subpackage. The following are examples of file types which should be in -devel: +* Header files (e.g. .h files) +* Unversioned shared libraries (e.g. libfoo.so). Versioned shared libraries (e.g. libfoo.so.3, libfoo.so.3.0.0) should not be in -devel. + +A good rule of thumb is if the file is used for development and not needed for the base package to run properly, it should go in -devel. + +{{Anchor|PkgconfigFiles}} +=== Pkgconfig Files === +The placement of pkgconfig(.pc) files depends on their usecase. Since they are almost always used for development purposes, they should be placed in a -devel package. +A reasonable exception is when the main package itself is a development tool not installed in a user runtime, e.g. gcc or gdb. Packages containing pkgconfig(.pc) files must Requires: pkgconfig (for directory ownership and usability). + +{{Anchor|RequiringBasePackage}} +== Requiring Base Package == +Devel packages must require the base package using a fully versioned dependency: Requires: %{name} = %{version}-%{release}. +Usually, subpackages other than -devel should also require the base package using a fully versioned dependency. + {{Anchor|SharedLibraries}} == Shared Libraries == Whenever possible (and feasible), Fedora Packages containing libraries should build them as shared libraries. In addition, every binary RPM package which contains shared library files (not just symlinks) in any of the dynamic linker's default paths, must call ldconfig in %post and %postun. If the package has multiple subpackages with libraries, each subpackage should also have a %post/%postun section that calls /sbin/ldconfig. An example of the correct syntax for this is: @@ -378,7 +405,7 @@ Note that this specific syntax only works if /sbin/ldconfig is the {{Anchor|StaticLibraries}} -== Exclusion of Static Libraries == +== Packaging Static Libraries == Packages including libraries should exclude static libs as far as possible (eg by configuring with ''--disable-static''). Static libraries should only be included in exceptional circumstances. Applications linking against libraries should as far as possible link against shared libraries not static versions. Libtool archives, ''foo.la'' files, should not be included. Packages using libtool will install these by default even if you configure with ''--disable-static'', so they may need to be removed before packaging. Due to bugs in older versions of libtool or bugs in programs that use it, there are times when it is not always possible to remove *.la files without modifying the program. In most cases it is fairly easy to work with upstream to fix these issues. Note that if you are updating a library in a stable release (not devel) and the package already contains *.la files, removing the *.la files should be treated as an API/ABI change -- ie: Removing them changes the interface that the library gives to the rest of the world and should not be undertaken lightly. @@ -664,9 +691,12 @@ Do make sure, however, that the package builds cleanly this way as some make fil to your ~/.rpmmacros file -- even on UP machines -- as this will expose most of these errors. +{{Anchor|Scriptlets}} +== Scriptlets == +Great care should be taken when using scriptlets in Fedora packages. If scriptlets are used, those scriptlets must be sane. Some common scriptlets are documented here: [[Packaging/ScriptletSnippets]]. {{Anchor|reqprepost}} -== Scriptlets requirements == +=== Scriptlets requirements === Do not use the Requires(pre,post) style notation for scriptlet dependencies, because of two bugs in RPM. Instead, they should be split like this: 
 Requires(pre): ...
@@ -675,7 +705,7 @@ Requires(post): ...
 For more information, see [http://www.redhat.com/archives/fedora-devel-list/2004-April/msg00674.html www.redhat.com] .
 
 {{Anchor|ScriptletConditionals}}
-== Running scriptlets only in certain situations ==
+=== Running scriptlets only in certain situations ===
 When the rpm command executes the scriptlets in a package it indicates if the action preformed is an install, erase, upgrade or reinstall by passing an integer argument to the script in question according to the following:
 
           install   erase   upgrade  reinstall
@@ -694,8 +724,7 @@ fi
 See also /usr/share/doc/rpm-*/triggers, which gives a more formal, generalized definition about the integer value(s) passed to various scripts.
 
 {{Anchor|SciptletsWriteDirs}}
-
-== Scriplets are only allowed to write in certain directories ==
+=== Scriplets are only allowed to write in certain directories ===
 Build scripts of packages (%prep, %build, %install, %check and %clean) may only alter files (create, modify, delete) under %{buildroot}, %{_builddir} and valid temporary locations like /tmp, /var/tmp (or $TMPDIR or %{_tmppath} as set by the rpmbuild process) according to the following matrix
 
 {| border="1"
@@ -789,6 +818,15 @@ In all cases we are guarding against unowned directories being present on a syst
 === Duplicate Files ===
 A Fedora package must not contain any duplicate files in the %files listing.
 
+{{Anchor|FilePermissions}}
+=== File Permissions ===
+Permissions on files must be set properly. Executables should be set with executable permissions, for example. Every %files section must include a %defattr(...) line. Here is a good default:
+
+%files
+%defattr(-,root,root,-)
+

+Unless you have a very good reason to deviate from that, you should use %defattr(-,root,root,-) for all %files sections in your package.
+
 {{Anchor|UsersAndGroups}}
 == Users and Groups ==
 

From 5d68def4db022c902f9a2ad939426a325d5fe209 Mon Sep 17 00:00:00 2001
From: Spot 
Date: Jan 09 2009 20:13:50 +0000
Subject: [PATCH 198/3559] *Empty MediaWiki Message*


---

diff --git a/Packaging:Guidelines.mw b/Packaging:Guidelines.mw
index 1262571..b798ef7 100644
--- a/Packaging:Guidelines.mw
+++ b/Packaging:Guidelines.mw
@@ -867,9 +867,6 @@ directories without administrator permission."
 
 It is important to note that a Fedora package, once installed, and run by a user, can use /srv as a default location for data. The package simply must not own any directories or files in /srv.
 
-=== Packages already in Fedora owning files or directories in /srv ===
-Any packages currently in Fedora that own files or directories in /srv must be fixed before Fedora 10.
-
 {{Anchor|Bundling}}
 == Bundling of multiple projects ==
 Fedora packages should make every effort to avoid having multiple, separate, upstream projects bundled together in a single package.

From 61214ef64601f20d3e313696996012d5fedbc737 Mon Sep 17 00:00:00 2001
From: Spot 
Date: Jan 11 2009 21:05:02 +0000
Subject: [PATCH 199/3559] *Empty MediaWiki Message*


---

diff --git a/Packaging:ReviewGuidelines.mw b/Packaging:ReviewGuidelines.mw
index 37c492b..64a4054 100644
--- a/Packaging:ReviewGuidelines.mw
+++ b/Packaging:ReviewGuidelines.mw
@@ -31,7 +31,7 @@ There are many many things to check for a review. This list is provided to assis
 * '''MUST''': The sources used to build the package must match the upstream source, as provided in the spec URL. Reviewers should use md5sum for this task.  If no upstream URL can be specified for this package, please see the [[Packaging/SourceURL|  Source URL Guidelines]]  for how to deal with this.

 * '''MUST''': The package '''MUST''' successfully compile and build into binary rpms on at least one primary architecture. [[Packaging/Guidelines#Architecture_Support|Packaging Guidelines: Architecture Support]]

 * '''MUST''': If the package does not successfully compile, build or work on an architecture, then those architectures should be listed in the spec in ExcludeArch. Each architecture listed in ExcludeArch '''MUST''' have a bug filed in bugzilla, describing the reason that the package does not compile/build/work on that architecture. The bug number '''MUST''' be placed in a comment, next to the corresponding ExcludeArch line. [[Packaging/Guidelines#Architecture_Build_Failures|Packaging Guidelines: Architecture Build Failures]]

-* '''MUST''': All build dependencies must be listed in BuildRequires, except for any that are listed in the [[Packaging/Guidelines#Exceptions |exceptions section of the Packaging Guidelines]] ; inclusion of those as BuildRequires is optional. Apply common sense.

+* '''MUST''': All build dependencies must be listed in BuildRequires, except for any that are listed in the [[Packaging/Guidelines#Exceptions_2|exceptions section of the Packaging Guidelines]] ; inclusion of those as BuildRequires is optional. Apply common sense.

 * '''MUST''': The spec file MUST handle locales properly. This is done by using the %find_lang macro. Using %{_datadir}/locale/* is strictly forbidden.[[Packaging/Guidelines#Handling_Locale_Files|Packaging Guidelines: Handling Locale Files]]

 * '''MUST''': Every binary RPM package (or subpackage) which stores shared library files (not just symlinks) in any of the dynamic linker's default paths, must call ldconfig in %post and %postun. [[Packaging/Guidelines#Shared_Libraries|Packaging Guidelines: Shared Libraries]]

 * '''MUST''': If the package is designed to be relocatable, the packager must state this fact in the request for review, along with the rationalization for relocation of that specific package. Without this, use of Prefix: /usr is considered a blocker. [[Packaging/Guidelines#RelocatablePackages|Packaging Guidelines: Relocatable Packages]]


From 9311c19100a8b64cc35f2a41613743afdcefa662 Mon Sep 17 00:00:00 2001
From: Spot 
Date: Jan 14 2009 15:31:42 +0000
Subject: [PATCH 200/3559] /* Action Items */


---

diff --git a/Packaging:GuidelinesTodo.mw b/Packaging:GuidelinesTodo.mw
index dc4191d..03fbc0a 100644
--- a/Packaging:GuidelinesTodo.mw
+++ b/Packaging:GuidelinesTodo.mw
@@ -18,6 +18,8 @@ Status should be one of:
 |ratify||Updates to the Eclipse plugin guidelines || overholt || 2008-12-09 || Was previously discussed [https://www.redhat.com/archives/fedora-packaging/2008-October/msg00121.html here].  Only difference from that diff is the addition of Fedora 9 notes as requested [https://www.redhat.com/archives/fedora-packaging/2008-December/msg00006.html here]. http://overholt.fedorapeople.org/EclipsePlugins.diff
 |-
 |ratify||Make adherence to the FHS a '''MUST''', with the added exception of /usr/ for cross toolchains.|| spot || 2008-12-09 ||https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00074.html "with exceptions for libexecdir (specified in the [http://www.gnu.org/prep/standards/standards.html#Directory-Variables GNU Coding Standards]) and /usr/target for crosscompilers"
+|-
+|ratify||Font Packaging Naming Guidelines || [[Nicolas Mailhot]] || 2009-01-14 || [[PackagingDrafts/Font_package_naming_%282009-01-13%29]]
 |}
 
 {{:PackagingDrafts/DraftsTodo}}

From 8199da6669bc38f96db8ee85f1ebd5a34e5dc157 Mon Sep 17 00:00:00 2001
From: Spot 
Date: Jan 14 2009 15:34:03 +0000
Subject: [PATCH 201/3559] /* Action Items */


---

diff --git a/Packaging:GuidelinesTodo.mw b/Packaging:GuidelinesTodo.mw
index 03fbc0a..ea84a82 100644
--- a/Packaging:GuidelinesTodo.mw
+++ b/Packaging:GuidelinesTodo.mw
@@ -19,6 +19,8 @@ Status should be one of:
 |-
 |ratify||Make adherence to the FHS a '''MUST''', with the added exception of /usr/ for cross toolchains.|| spot || 2008-12-09 ||https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00074.html "with exceptions for libexecdir (specified in the [http://www.gnu.org/prep/standards/standards.html#Directory-Variables GNU Coding Standards]) and /usr/target for crosscompilers"
 |-
+|ratify||Font package splitting rules (guidelines change) || [[Nicolas Mailhot]] || 2009-01-06 || [[PackagingDrafts/Font package splitting rules (2008-12-21)]]
+|-
 |ratify||Font Packaging Naming Guidelines || [[Nicolas Mailhot]] || 2009-01-14 || [[PackagingDrafts/Font_package_naming_%282009-01-13%29]]
 |}
 

From 66db0b0aa6d278f85935644b6764428732e64406 Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Jan 18 2009 19:53:26 +0000
Subject: [PATCH 202/3559] Fix missing comment examples


---

diff --git a/Packaging:LicensingGuidelines.mw b/Packaging:LicensingGuidelines.mw
index a275aef..f01faa1 100644
--- a/Packaging:LicensingGuidelines.mw
+++ b/Packaging:LicensingGuidelines.mw
@@ -78,6 +78,7 @@ Some suggested implementations include
 
 * A comment right above the License: field:
 
+# The entire source code is GPLv2+ except foolib/ which is BSD
 License: GPLv2+ and BSD
 

 * Including a file as %doc which contains the licensing breakdown for the packaged files, then using:
@@ -89,10 +90,13 @@ License: GPLv2+ and BSD
 %files
 %defattr(-,root,root,-)
 %doc Changes
+# Python
 %{_bindir}/cobra-util
 %{_bindir}/viper-util
+# LGPLv2+
 %{_bindir}/gnu-util
 %{_bindir}/rms-util
+# BSD
 %{_bindir}/berkeley-util
 

 

From bc94e55a63a3c1a9b666e58494cc73233db5e6f6 Mon Sep 17 00:00:00 2001
From: Spot 
Date: Jan 20 2009 18:41:38 +0000
Subject: [PATCH 203/3559] *Empty MediaWiki Message*


---

diff --git a/Packaging:GuidelinesTodo.mw b/Packaging:GuidelinesTodo.mw
index ea84a82..57cbe01 100644
--- a/Packaging:GuidelinesTodo.mw
+++ b/Packaging:GuidelinesTodo.mw
@@ -11,17 +11,23 @@ Status should be one of:
 |- style="color: white; background-color: #3074c2; font-weight: bold" 
 |Status||Task Name||Owner||Meeting Date||Notes
 |-
-|ratify||RubyGem with C code || mtasaka ||2008-12-09||[[PackagingDrafts/RubyGem with C code]]
+|ratify||Explicit Requires || spot || 2009-01-20 ||[[PackagingDrafts/ExplicitRequires]]
 |-
-|ratify||Font packaging automation || [[Nicolas Mailhot]] ||2008-12-09||[[PackagingDrafts/Fonts_packaging_automation]] Refactoring of Fedora fonts packaging guidelines and template
+|ratify||Updated Haskell Guidelines || spot || 2009-01-20 || [[PackagingDrafts/Haskell]]
 |-
-|ratify||Updates to the Eclipse plugin guidelines || overholt || 2008-12-09 || Was previously discussed [https://www.redhat.com/archives/fedora-packaging/2008-October/msg00121.html here].  Only difference from that diff is the addition of Fedora 9 notes as requested [https://www.redhat.com/archives/fedora-packaging/2008-December/msg00006.html here]. http://overholt.fedorapeople.org/EclipsePlugins.diff
+|ratify||Symlinks ||spot ||2009-01-20 ||[[PackagingDrafts/Symlinks]]
 |-
-|ratify||Make adherence to the FHS a '''MUST''', with the added exception of /usr/ for cross toolchains.|| spot || 2008-12-09 ||https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00074.html "with exceptions for libexecdir (specified in the [http://www.gnu.org/prep/standards/standards.html#Directory-Variables GNU Coding Standards]) and /usr/target for crosscompilers"
+|writeup||RubyGem with C code || mtasaka ||2008-12-09||[[PackagingDrafts/RubyGem with C code]]
 |-
-|ratify||Font package splitting rules (guidelines change) || [[Nicolas Mailhot]] || 2009-01-06 || [[PackagingDrafts/Font package splitting rules (2008-12-21)]]
+|writeup||Font packaging automation || [[Nicolas Mailhot]] ||2008-12-09||[[PackagingDrafts/Fonts_packaging_automation]] Refactoring of Fedora fonts packaging guidelines and template
 |-
-|ratify||Font Packaging Naming Guidelines || [[Nicolas Mailhot]] || 2009-01-14 || [[PackagingDrafts/Font_package_naming_%282009-01-13%29]]
+|writeup||Updates to the Eclipse plugin guidelines || overholt || 2008-12-09 || Was previously discussed [https://www.redhat.com/archives/fedora-packaging/2008-October/msg00121.html here].  Only difference from that diff is the addition of Fedora 9 notes as requested [https://www.redhat.com/archives/fedora-packaging/2008-December/msg00006.html here]. http://overholt.fedorapeople.org/EclipsePlugins.diff
+|-
+|writeup||Make adherence to the FHS a '''MUST''', with the added exception of /usr/ for cross toolchains.|| spot || 2008-12-09 ||https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00074.html "with exceptions for libexecdir (specified in the [http://www.gnu.org/prep/standards/standards.html#Directory-Variables GNU Coding Standards]) and /usr/target for crosscompilers"
+|-
+|writeup||Font package splitting rules (guidelines change) || [[Nicolas Mailhot]] || 2009-01-06 || [[PackagingDrafts/Font package splitting rules (2008-12-21)]]
+|-
+|writeup||Font Packaging Naming Guidelines || [[Nicolas Mailhot]] || 2009-01-14 || [[PackagingDrafts/Font_package_naming_%282009-01-13%29]]
 |}
 
 {{:PackagingDrafts/DraftsTodo}}

From 425cfa9b08c49881d3956cb03d9f60034cb8a773 Mon Sep 17 00:00:00 2001
From: Spot 
Date: Jan 20 2009 19:52:42 +0000
Subject: [PATCH 204/3559] /* desktop-file-install usage */


---

diff --git a/Packaging:Guidelines.mw b/Packaging:Guidelines.mw
index b798ef7..eb17f6b 100644
--- a/Packaging:Guidelines.mw
+++ b/Packaging:Guidelines.mw
@@ -536,33 +536,24 @@ It is not simply enough to just include the .desktop file in the package, one MU
 usage:
 
 
-desktop-file-install --vendor=""               \
+desktop-file-install                                    \
 --dir=${RPM_BUILD_ROOT}%{_datadir}/applications         \
 %{SOURCE3}
 

 
 
-desktop-file-install --vendor=""                \
---add-category="Multimedia"                              \
---delete-original                                        \
---dir=%{buildroot}%{_datadir}/applications               \
+desktop-file-install                                    \
+--add-category="Multimedia"                             \
+--delete-original                                       \
+--dir=%{buildroot}%{_datadir}/applications              \
 %{buildroot}/%{_datadir}/applnk/Multimedia/foo.desktop
 

 
 
-desktop-file-install --vendor=""                           \
---remove-category="Science"                              \
---dir=%{buildroot}%{_datadir}/applications/   \
-%{buildroot}/%{_datadir}/applications//foo.desktop
-

-
-
 desktop-file-validate %{buildroot}/%{_datadir}/applications/foo.desktop
 

 
-* If upstream uses , leave it intact, otherwise use fedora as .
-* It is important that vendor_id stay constant for the life of a package.
-This is mostly for the sake of menu-editing (which bases off of .desktop file/path names).
+* For new packages, do not apply a vendor tag to desktop files. Existing packages that use a vendor tag must continue to do so for the life of the package. This is mostly for the sake of menu-editing (which bases off of .desktop file/path names).
 
 {{Anchor|macros}}
 

From 5093f9168e1485904df87f34fc4d4bf401e11e02 Mon Sep 17 00:00:00 2001
From: Spot 
Date: Jan 20 2009 20:19:44 +0000
Subject: [PATCH 205/3559] /* Font bundles */


---

diff --git a/Packaging:FontsPolicy.mw b/Packaging:FontsPolicy.mw
index 37a073e..e27cdbf 100644
--- a/Packaging:FontsPolicy.mw
+++ b/Packaging:FontsPolicy.mw
@@ -32,20 +32,33 @@ The users of this legacy backend won't thank you for destabilizing it with new f
 
 {{:Comps_fonts_rules}}
 
-== Font bundles ==
+== Package layout for fonts ==
+
+# Fonts released upstream in separate archives '''MUST''' be packaged in separate source packages (''src.rpm''), unless they belong to the same font family.
+# Packagers '''SHOULD''' ask upstream to release each font family in a separate versioned archive, when it bundles in a common release archive:
+## fonts with other material such as application code, or
+## different font families.
+#* As an exception, when a project is the upstream of several font families, which are all licensed the same way, and released on the same date, with the same version, the use of a common release archive is tolerated.
+# Packagers '''MUST''' package each font family in a separate (''noarch.rpm'') (sub)package, notwithstanding on how they applied the previous source package (''src.rpm'') rules. The only admitted exceptions are:
+## source packages that only include one font family and no other code or content (font documentation excepted), in which case a simple package is fine,
+## font families which are designed to extend other font families with larger Unicode coverage (for example ''Arial Unicode'', ''Droid Sans Fallback''), in which case grouping the font family and its extension in a single (sub)package is acceptable.
+##* such cases should be notified to the fontconfig maintainer and the Fedora [[Fonts SIG mailing lists|fonts list]], so the font family split can be eventually hidden from users.
+## fonts that use a format that bundles different font families in a single file.
+# On the other hand, the different faces of a font family '''MUST''' be packaged together in a common (''noarch.rpm'') (sub)package, and not spread over different (sub)packages
+
+'''Rationale:'''
 
 As noted in the [[Packaging/Guidelines#Bundling |Packaging Guidelines]], Fedora packages should make every effort to avoid having multiple, separate, upstream projects bundled together in a single package. This applies equally to font packages.
 
-Sometimes local groups publish a collection of fonts of different origins and different licensing in a single archive. In that case the interested packager '''SHOULD''' ask this upstream to break up its archive in different files. If upstream refuses the packager '''MAY''' base a single ''src.rpm'' on the collection archive, but he '''MUST''' make sure each bundled font set ends up in a different, appropriately licensed sub-package.
+Multi-source packages are difficult to maintain and confusing to users. In addition, fonts are comparatively bulky, and big font packages will be blacklisted from live-cds and by low-bandwidth users.
 
-When a project is the upstream of several font families, which are all licensed the same way, and released on the same dates, in a single archive, the packager '''MAY''' create a single package. However the packager '''SHOULD''' consider splitting each font family in a different sub-package, so users can install only the font families they care about.
-
-Multi-source packages are difficult to maintain and confusing to users. In addition:
-* fonts are comparatively bulky, and big font packages will be blacklisted from live-cds and by low-bandwidth users.
-* multi-family packages force users to install fonts they may not care of or even like just to get the other fonts in the package.
-
-As a rule, try to produce small simple user-friendly mono-family font packages that will be easy to maintain (you should however strive to group different faces of the same font family in the same package). Avoid grouping unrelated fonts in a single package.
+The functional font unit for users is the font family. Users don't understand partially installed fonts (font faces spread over different packages) and bundles (multi-family packages that force them to install fonts they may not care of or even like just to get the other fonts in the package). Because it is a unit, projects will extend or fork a font family as a whole, but not necessarily in step with other bundled families.
 
+Lastly, multi-font packages unnecessarily complexify font auto-installation..
+
+Notes:
+
+
 
 {{:Fonts_SIG_signature}}
 [[Category:Fonts packaging|Packaging policy]]

From d6c18e1801cda3f355334a309df7714a8d98dd8b Mon Sep 17 00:00:00 2001
From: Spot 
Date: Jan 20 2009 20:24:10 +0000
Subject: [PATCH 206/3559] *Empty MediaWiki Message*


---

diff --git a/Packaging:FontsPolicy.mw b/Packaging:FontsPolicy.mw
index e27cdbf..7aa8b34 100644
--- a/Packaging:FontsPolicy.mw
+++ b/Packaging:FontsPolicy.mw
@@ -32,6 +32,133 @@ The users of this legacy backend won't thank you for destabilizing it with new f
 
 {{:Comps_fonts_rules}}
 
+== Naming ==
+
+Fedora font packages are named '''[foundryname-]projectname[-fontfamilyname]-fonts''', in lowercase.
+
+=== Clarifications ===
+
+# For Fedora purposes a “foundry” is an entity that publishes a set of fonts with consistent font QA rules. Thus a generic hosting service such as [http://www.sf.net Sourceforge] is not a foundry, but the [http://openfontlibrary.org/ Open Font Library] is.
+# It is good practice to contract ''foundryname-'' in a short prefix.
+# The ''foundryname-'' prefix can optionally be skipped:
+#* for entities that never released more than one font family, or
+#* when the font project and the publishing entity are one and the same.
+# If ''projectname'' or ''foundryname'' are repeated in ''fontfamilyname'', they can be dropped from ''fontfamilyname''.
+# When ''foundryname'', ''projectname'' or ''fontfamilyname'' contain the ''font'' or ''fonts'' affix, this affix should be dropped from themTo avoid ''foofont-fonts'' packages..
+# ''-fontfamilyname'' should not be included in the srpm name of a package that includes several different font families.
+# If any element of the naming contains spaces, they should be replaced by “-”.
+# The use of the ''-fonts'' suffix is not dependant on the actual number of font files in the package.
+
+When in doubt, ask the [[Fonts_SIG_mailing_lists|mailing list]] for clarification.
+
+=== Examples ===
+
+{| border="1"
+|+ Font package naming examples
+|-
+! colspan="2" | Source package (''src.rpm'')
+! colspan="2" | Binary (sub)package
+! rowspan="2" | Description
+|-
+! Fonts
+! Other
+! Fonts
+! Other
+|-
+| apanov-heuristica-fonts
+|
+| apanov-heuristica-fonts
+|
+| “Heuristica” font family published by Andrey Panov, “apanov”.
+|-
+| sil-abyssinica-fonts
+|
+| sil-abyssinica-fonts
+|
+| “Abyssinica SIL” font family published by the “SIL” foundry.
+|-
+| oflb-brett-fonts
+|
+| oflb-brett-fonts
+|
+| “BrettFont” font family published on the “Open Font Library”, “oflb” foundry.
+|-
+| rowspan="2" | dejavu-fonts
+| rowspan="2" |
+|
+* dejavu-sans-fonts
+* dejavu-sans-mono-fonts
+* dejavu-serif-fonts
+|
+| The three “DejaVu” font families self-published by the “DejaVu” project.
+|-
+|
+| dejavu-fonts-common
+| Utility subpackage with no font files inside.
+|-
+| rowspan="2" | google-droid-fonts
+| rowspan="2" |
+|
+* google-droid-sans-fonts
+* google-droid-sans-mono-fonts
+* google-droid-serif-fonts
+|
+| The three “Droid” font families published by “Google”, as part of its “Droid” release.
+|-
+|
+| google-droid-fonts-common
+| Utility subpackage with no font files inside.
+|-
+| rowspan="2" | un-core-fonts
+| rowspan="2" |
+|
+* un-core-pilgi-fonts
+* un-core-dinaru-fonts
+* un-core-batang-fonts…
+|
+| “UN Core” fonts published by the “UN” project.
+|-
+|
+| un-core-fonts-common
+| Utility subpackage with no font files inside.
+|-
+| rowspan="2" |
+| rowspan="2" | openoffice.org
+| openoffice.org-opensymbol-fonts
+|
+| The “OpenSymbol” font family published as part of “openoffice.org”.
+|-
+| 
+|
+* openoffice.org-writer
+* openoffice.org-calc…
+|
+|-
+| rowspan="3" | ctan-cm-lgc-fonts
+| rowspan="3" |
+|
+* ctan-cm-lgc-sans-fonts
+* ctan-cm-lgc-roman-fonts
+* ctan-cm-lgc-typewriter-fonts…
+|
+| “CM LGC” font families published by the “CTAN” foundry.
+|-
+|
+| ctan-cm-lgc-fonts-common
+| Utility subpackage with no font files inside.
+|-
+|
+| ctan-cm-lgc-tex
+|
+TEX overlay for ctan-cm-lgc fonts
+(cooked up example, this page is not a TEX naming guideline)
+|-
+|}
+
+Notes:
+
+
+
 == Package layout for fonts ==
 
 # Fonts released upstream in separate archives '''MUST''' be packaged in separate source packages (''src.rpm''), unless they belong to the same font family.

From 2bb797eb55eb7152114012b8966064e627e4c9fc Mon Sep 17 00:00:00 2001
From: Spot 
Date: Jan 20 2009 20:28:03 +0000
Subject: [PATCH 207/3559] *Empty MediaWiki Message*


---

diff --git a/Packaging:Naming.mw b/Packaging:Naming.mw
index eae3f68..004c278 100644
--- a/Packaging:Naming.mw
+++ b/Packaging:Naming.mw
@@ -1,9 +1,9 @@
 = Package Naming Guidelines =
 
 '''Author:''' [[TomCallaway|  Tom 'spot' Callaway]] 

-'''Revision:''' 0.50

+'''Revision:''' 0.51

 '''Initial Draft:''' Wednesday Feb 23, 2005

-'''Last Revised:''' Tuesday, June 17, 2008

+'''Last Revised:''' Tuesday, Jan 20, 2009

 
 
 
@@ -299,6 +299,10 @@ For packages that are not usually pulled in by using the package name as the dep
 Large documentation files should go in a subpackage. This subpackage must be named with the format: %{name}-doc .
 The definition of large is left up to the packager's best judgement, but is not restricted to size. Large can refer to either size or quantity.
 
+{{Anchor|FontPackages}}
+== Font Packages ==
+Packages containing fonts must be named '''[foundryname-]projectname[-fontfamilyname]-fonts''', in lowercase. For a full explanation, see [[Packaging/FontsPolicy#Naming]].
+
 {{Anchor|AddonGeneral}}
 == Addon Packages (General) ==
 If a new package is considered an "addon" package that enhances or adds a new functionality to an existing Fedora package without being useful on its own, its name should reflect this fact.


From abb23bed948f3600ba5c866e2e83bb3eb0f98c70 Mon Sep 17 00:00:00 2001
From: Spot 
Date: Jan 20 2009 20:36:08 +0000
Subject: [PATCH 208/3559] *Empty MediaWiki Message*


---

diff --git a/Packaging:EclipsePlugins.mw b/Packaging:EclipsePlugins.mw
index 592f211..e1920b7 100644
--- a/Packaging:EclipsePlugins.mw
+++ b/Packaging:EclipsePlugins.mw
@@ -36,10 +36,10 @@ Remember that Eclipse plugin packages, like all Fedora software packages, must b
 Eclipse plugins '''SHOULD''' be built with the Eclipse Plugin Development Environment (PDE; PDE Build specifically) because these builds are generally easier to maintain.  ant builds are acceptable, but are generally more difficult to maintain.  Following what upstream does is the best practice.
 
 === pdebuild ===
-As of Fedora 9, there is a script that makes invoking PDE Build easy:  /usr/share/eclipse/buildscripts/pdebuild:
+As of Fedora 9, there is a script that makes invoking PDE Build easy:  /usr/lib{,64}/eclipse/buildscripts/pdebuild (in Fedora 9 the script is located at /usr/share/eclipse/buildscripts/pdebuild):
 
 
-usage: /usr/share/eclipse/buildscripts/pdebuild [] 
+usage: /usr/lib{,64}/eclipse/buildscripts/pdebuild [] 
 
 Use PDE Build to build Eclipse features
 
@@ -52,6 +52,7 @@ Optional arguments:
 -j      VM arguments (ex. -DJ2SE-1.5=%{_jvmdir}/java/jre/lib/rt.jar)
 -v      Be verbose
 -D      Debug platform itself (passes -consolelog -debug to Eclipse)
+-o      Orbit dependencies
 

 
 {{Template:Warning}} Note:  PDE Build must be called explicitly in Fedora 8 and earlier (including EPEL 5).  The following snippet may be used to replace the pdebuild call in the template:
@@ -80,7 +81,7 @@ org.eclipse.core.launcher.Main                    \
==== EPEL 5 ==== -The copy-platform script is in a different location on RHEL 5 than it is in Fedora. If calling copy-platform explicitly, the following snippet may be useful to facilitate Eclipse plugins for EPEL 5: +The copy-platform script is in a different location on RHEL 5 than it is in Fedora. If calling copy-platform explicitly, the following snippet may be useful to facilitate building Eclipse plugins for EPEL 5: 
 %if 0%{?rhel} == 5
 /bin/sh -x %{_libdir}/eclipse/buildscripts/copy-platform SDK %{eclipse_base}
@@ -90,14 +91,25 @@ The copy-platform script is in a different location on RHEL 5 than
== File Locations == -All plugin jars should go into %{_datadir}/eclipse/plugins and features should go into %{_datadir}/eclipse/features. The only exception is for fragments which should go into %{_libdir}/eclipse/plugins (and features if applicable). +All platform-independent plugins/features should go into %{_datadir}/eclipse/dropins/. JARs should therefore go into %{_datadir}/eclipse/dropins//plugins and features should go into %{_datadir}/eclipse/dropins//features. Architecture-specific plugins/features should go into %{_libdir}/eclipse/dropins/. JARs should therefore go into %{_libdir}/eclipse/dropins//plugins and features should go into %{_datadir}/eclipse/dropins//features. Example: + +
+%install
+rm -rf %{buildroot}
+installDir=%{buildroot}%{_datadir}/eclipse/dropins/quickrex
+install -d -m 755 $installDir
+unzip -q -d $installDir \
+ build/rpmBuild/de.babe.eclipse.plugins.QuickREx.zip
+
+ +For Fedora 9, all plugin jars should go into %{_datadir}/eclipse/plugins and features should go into %{_datadir}/eclipse/features. The only exception is for fragments which should go into %{_libdir}/eclipse/plugins (and features if applicable). Note that this is not reflected in the template below. == Arch vs. noarch == While many Eclipse plugins will be architecture-independent, please follow the ["Packaging/GCJGuidelines"] with regards to gcj ahead-of-time compilation. As those guidelines specify, gcj-compiled packages are arch-dependent and are thus not noarch. == Things to avoid == === Pre-built binaries === -If Eclipse plugins depend upon third party libraries (and licensing permits it), developers often include these libraries directly in their source control system. In this case, the libraries must exist as other packages in Fedora and their contents (such as their jars) be symlinked from within the source and build trees of the Eclipse plugin being packaged. While it may make source archives smaller in size if they are cleansed of these pre-built files, it is not necessary to do so unless the libraries themselves are not redistributable. Binary RPMs '''MUST NOT''' include pre-built files. +If Eclipse plugins depend upon third party libraries (and licensing permits it), developers often include these libraries directly in their source control system. In this case, the libraries must exist as other packages in Fedora and their contents (such as their JARs) be symlinked from within the source and build trees of the Eclipse plugin being packaged. While it may make source archives smaller in size if they are cleansed of these pre-built files, it is not necessary to do so unless the libraries themselves are not redistributable. Binary RPMs '''MUST NOT''' include pre-built files. {{Template:Note}} A simple check which may be run at the end of %prep (courtesy David Walluck (I think that's who gave it to Ben Konrath)): 
@@ -108,21 +120,21 @@ JARS="$JARS $j"
 fi
 done
 if [ ! -z "$JARS" ] ; then
-echo "These jars should be deleted and symlinked to system jars: $JARS"
+echo "These JARs should be deleted and symlinked to system JARs: $JARS"
 exit 1
 fi
=== Differing from upstream === Plugins that are jarred should remain jarred and those that are expanded should be expanded in their RPM. There are two cases (that we can think of as of this writing) that warrant diverging from upstream: -1. Symlinking to a binary jar from another package -1. Expanding a jar to allow for symlinking to a binary jar from another package +# Symlinking to a binary JAR from another package +# Expanding a JAR to allow for symlinking to a binary JAR from another package -See below for a tip on how to deal with the expanded jar case. +See below for a tip on how to deal with the expanded JAR case. == Specfile Template == 
-%define eclipse_base        %{_datadir}/eclipse
+%define eclipse_base        %{_libdir}/eclipse
 
 Name:           eclipse-plugin
 Version:        1.0
@@ -162,10 +174,10 @@ Group: Development/Tools
 
 %install
 rm -rf $RPM_BUILD_ROOT
-install -d -m 755 $RPM_BUILD_ROOT%{eclipse_base}
-unzip -q -d $RPM_BUILD_ROOT%{eclipse_base}/.. \
+install -d -m 755 $RPM_BUILD_ROOT%{_datadir}/eclipse/dropins/plugin-a
+unzip -q -d $RPM_BUILD_ROOT%{_datadir}/eclipse/dropins/plugin-a \
 build/rpmBuild/org.eclipse.plugin_feature.zip
-unzip -q -d $RPM_BUILD_ROOT%{eclipse_base}/.. \
+unzip -q -d $RPM_BUILD_ROOT%{_datadir}/eclipse/dropins/plugin-b \
 build/rpmBuild/org.eclipse.plugin.b_feature.zip
 
 %clean
@@ -173,23 +185,16 @@ rm -rf $RPM_BUILD_ROOT
 
 %files
 %defattr(-,root,root,-)
-%{eclipse_base}/plugins/org.eclipse.plugin.a_*.jar
-%{eclipse_base}/plugins/org.eclipse.plugin.c_*.jar
-%dir %{eclipse_base}/features/org.eclipse.plugin_feature_*
-%doc %{eclipse_base}/features/org.eclipse.plugin_feature_*/license.html
-%doc %{eclipse_base}/features/org.eclipse.plugin_feature_*/about.html
-%doc %{eclipse_base}/features/org.eclipse.plugin_feature_*/epl-v10.html
-%{eclipse_base}/features/org.eclipse.plugin_feature_*/feature.xml
+%{_datadir}/eclipse/dropins/plugin-a
 
 %files b
 %defattr(-,root,root,-)
-%{eclipse_base}/plugins/org.eclipse.plugin.b_*.jar
-%dir %{eclipse_base}/features/org.eclipse.plugin.b_feature_*
-%doc %{eclipse_base}/features/org.eclipse.plugin.b_feature_*/license.html
-%doc %{eclipse_base}/features/org.eclipse.plugin.b_feature_*/epl-v10.html
-%{eclipse_base}/features/org.eclipse.plugin.b_feature_*/feature.xml
+%{_datadir}/eclipse/dropins/plugin-b
 
 %changelog
+* Fri Oct 17 2008 Andrew Overholt  1.0-2
+- Update for Eclipse 3.4.x
+
 * Fri Feb 29 2008 Andrew Overholt  1.0-1
 - Initial Fedora package
@@ -197,7 +202,7 @@ rm -rf $RPM_BUILD_ROOT == Tips and Notes == === Common Defines === -%define eclipse_base %{_datadir}/eclipse and, if necessary %define eclipse_lib_base %{_libdir}/eclipse. +%define eclipse_base %{_libdir}/eclipse. === Requires === Until rpmstubby (see below) is released and/or more widespread, Requires on bits provided by the Eclipse SDK (RCP, SWT, Platform, JDT, PDE, CVS, etc.) should only be on the binary package providing the required functionality (ex. eclipse-cvs-client or eclipse-rcp). For IDE features, the most common requirement will be eclipse-platform. @@ -224,7 +229,7 @@ $ unzip -l org.eclipse.mylyn.web.core_2.2.0.I20071220-1700.jar | grep jar$ 98051 12-20-07 20:08 lib-xmlrpc/xmlrpc-common-3.0.jar -Note that we have embedded jars which we would like to turn into symlinks to existing jars (from other packages). If we simply unzip the plugin jar and symlink, one would think we would be okay: +Note that we have embedded JARs which we would like to turn into symlinks to existing JARs (from other packages). If we simply unzip the plugin JAR and symlink, one would think we would be okay: 
 $ unzip -qq org.eclipse.mylyn.web.core_2.2.0.I20071220-1700.jar
@@ -234,7 +239,7 @@ about.html  lib-httpclient  lib-rome  lib-xmlrpc  META-INF  org
 $
-However, we end up with the plugin classes themselves being expanded in the org directory. [https://bugzilla.redhat.com/273881 Bug #273881] causes build failures when building debuginfo packages in this case. The acceptable workaround is to modify the build.properties file in the plugin to jar the plugin code separately (ex. mylyn-webcore.jar) and include it within this expanded plugin directory. An example of this work-around can be seen in [http://cvs.fedoraproject.org/viewcvs/devel/eclipse-mylyn/ eclipse-mylyn] (specifically the patches related to org.eclipse.mylyn.webcore). +However, we end up with the plugin classes themselves being expanded in the org directory. [https://bugzilla.redhat.com/273881 Bug #273881] causes build failures when building debuginfo packages in this case. The acceptable workaround is to modify the build.properties file in the plugin to JAR the plugin code separately (ex. mylyn-webcore.jar) and include it within this expanded plugin directory. An example of this work-around can be seen in [http://cvs.fedoraproject.org/viewcvs/devel/eclipse-mylyn/ eclipse-mylyn] (specifically the patches related to org.eclipse.mylyn.webcore). === OSGi === OSGi bundles contain metadata just like RPMs do. This metadata can be used to automatically generate Provides and Requires similar to how it is done for mono packages. This functionality exists in Fedora's current rpm package but requires some investigation as at the time of this writing it does not appear to be functioning properly. From e060b21f23ec43a22c9051c54245f5f73677448c Mon Sep 17 00:00:00 2001 From: Spot Date: Jan 20 2009 20:42:22 +0000 Subject: [PATCH 209/3559] *Empty MediaWiki Message* --- diff --git a/Packaging:Ruby.mw b/Packaging:Ruby.mw index a7d7da8..824095b 100644 --- a/Packaging:Ruby.mw +++ b/Packaging:Ruby.mw @@ -40,6 +40,13 @@ The binary files in a Ruby package with binary content '''must''' be placed into %{!?ruby_sitearch: %define ruby_sitearch %(ruby -rrbconfig -e 'puts Config::CONFIG["sitearchdir"] ')} +For packages which create C shared libraries using extconf.rb +
+export CONFIGURE_ARGS="--with-cflags='%{optflags}'"
+
+'''should''' be used to pass CFLAGS to Makefile correctly. +This also applies to Ruby Gems. + == Ruby Gems == [http://www.rubygems.org/ Ruby Gems] are Ruby's own packaging format. Gems contain a lot of the same metadata that RPM's need, making fairly smooth interoperation between RPM and Gems possible. This guideline ensures that Gems are packaged as RPM's in a way that ensures (1) that such RPM's fit cleanly with the rest of the distribution and (2) make it possible for the end user to satisfy dependencies of a Gem by installing the appropriate RPM-packaged Gem. @@ -68,6 +75,25 @@ gem install --local --install-dir %{buildroot}%{gemdir} --force %{SOURCE0} * Architecture-specific content '''must not''' be installed into %{gemdir} * If the Gem only contains pure Ruby code, it '''must''' be marked as BuildArch: noarch. If the Gem contains binary content (e.g., for a database driver), it '''must''' be marked as architecture specific, and all architecture specific content '''must''' be moved from the %{gemdir} to the [#ruby_sitearch %{ruby_sitearch} directory] during %install +=== Ruby Gem with extension libraries written in C === + +When a Ruby Gem contains extension libraries written in C, +* First, %prep stage '''must''' contain %setup -q -c -T to create the directory where C libraries are compiled. +* Then at %build stage the Ruby Gem '''must''' be installed under the directory created at %prep stage to get C libraries compiled under there. +* When gem install is used to install Gem file, using -V option is '''recommend''' to check if CFLAGS is correctly honored. +* Finally at %install stage the whole tree under the directory created at %prep stage '''should''' be '''copied''' (not moved) to under %{buildroot}%{gemdir}. +** When all tree under the directory created at %prep stage is moved to under %{buildroot}, find_debuginfo.sh will complain that the corresponding source files are missing. +* Installed C codes (usually under %{geminstdir}/etc) '''may''' be removed even if gem contents %{gemname} reports that installed C codes should be found there. + +==== Note ==== +The current guideline +
+If the Gem contains binary content (e.g., for a database driver), it must be marked 
+as architecture specific, and all architecture specific content must be moved 
+from the %{gemdir} to the [#ruby_sitearch %{ruby_sitearch} directory] during %install
+
+must still apply. + === Packaging for Gem and non-Gem use === If the same Ruby library is to be packaged for use as a Gem and as a straight Ruby library without Gem support, it '''must''' be packaged as a Gem first. To make it available to code that does not use Ruby Gems, a subpackage called ruby-%{gemname} '''must''' be created in the rubygem-%{gemname} package such that From b61fb9acfcefbe5b7cfd15cd4cbb2a3d99275faa Mon Sep 17 00:00:00 2001 From: Spot Date: Jan 20 2009 20:49:49 +0000 Subject: [PATCH 210/3559] *Empty MediaWiki Message* --- diff --git a/Packaging:FontsPolicy.mw b/Packaging:FontsPolicy.mw index 7aa8b34..ed4899a 100644 --- a/Packaging:FontsPolicy.mw +++ b/Packaging:FontsPolicy.mw @@ -32,6 +32,18 @@ The users of this legacy backend won't thank you for destabilizing it with new f {{:Comps_fonts_rules}} +== Technical implementation == + +Creating font packages or subpackages in Fedora is done using the ''fontpackages-devel'' packageBuilt from the [[pkgdb:fontpackages|fontpackages]] srpm.. Its sources are published on [http://fedorahosted.org/ fedorahosted] in [http://fedorahosted.org/releases/f/o/fontpackages/ archive] and git (git://git.fedorahosted.org/fontpackages.git) formats. + +It contains a set of commented fontconfig templates, and the two official Fedora fonts spec templates: +* a [[Simple fonts spec template|simple template]] for font source packages containing a single font family, +* a [[Fonts spec template for multiple_fonts|complex template]] for font source packages containing several different font families. + +While this package has been created by Fedora for Fedora, its content should be pretty generic. Apart from the occasional reference to this wiki as documentation source, it should not include any blatant Fedora-ism. + +''fontpackages'' evolutions can be discussed on the Fonts SIG [[Fonts SIG mailing lists|mailing list]]. + == Naming == Fedora font packages are named '''[foundryname-]projectname[-fontfamilyname]-fonts''', in lowercase. @@ -158,7 +170,6 @@ TEX overlay for ctan-cm-lgc fonts Notes: - == Package layout for fonts == # Fonts released upstream in separate archives '''MUST''' be packaged in separate source packages (''src.rpm''), unless they belong to the same font family. From 99df5b45e1008a53c88369ccbf49e40c9dfdb488 Mon Sep 17 00:00:00 2001 From: Spot Date: Jan 20 2009 20:51:38 +0000 Subject: [PATCH 211/3559] *Empty MediaWiki Message* --- diff --git a/Packaging:FontsPolicy.mw b/Packaging:FontsPolicy.mw index ed4899a..fb3d406 100644 --- a/Packaging:FontsPolicy.mw +++ b/Packaging:FontsPolicy.mw @@ -32,18 +32,6 @@ The users of this legacy backend won't thank you for destabilizing it with new f {{:Comps_fonts_rules}} -== Technical implementation == - -Creating font packages or subpackages in Fedora is done using the ''fontpackages-devel'' packageBuilt from the [[pkgdb:fontpackages|fontpackages]] srpm.. Its sources are published on [http://fedorahosted.org/ fedorahosted] in [http://fedorahosted.org/releases/f/o/fontpackages/ archive] and git (git://git.fedorahosted.org/fontpackages.git) formats. - -It contains a set of commented fontconfig templates, and the two official Fedora fonts spec templates: -* a [[Simple fonts spec template|simple template]] for font source packages containing a single font family, -* a [[Fonts spec template for multiple_fonts|complex template]] for font source packages containing several different font families. - -While this package has been created by Fedora for Fedora, its content should be pretty generic. Apart from the occasional reference to this wiki as documentation source, it should not include any blatant Fedora-ism. - -''fontpackages'' evolutions can be discussed on the Fonts SIG [[Fonts SIG mailing lists|mailing list]]. - == Naming == Fedora font packages are named '''[foundryname-]projectname[-fontfamilyname]-fonts''', in lowercase. @@ -170,6 +158,18 @@ TEX overlay for ctan-cm-lgc fonts Notes: +== Technical implementation == + +Creating font packages or subpackages in Fedora is done using the ''fontpackages-devel'' packageBuilt from the [[pkgdb:fontpackages|fontpackages]] srpm.. Its sources are published on [http://fedorahosted.org/ fedorahosted] in [http://fedorahosted.org/releases/f/o/fontpackages/ archive] and git (git://git.fedorahosted.org/fontpackages.git) formats. + +It contains a set of commented fontconfig templates, and the two official Fedora fonts spec templates: +* a [[Simple fonts spec template|simple template]] for font source packages containing a single font family, +* a [[Fonts spec template for multiple_fonts|complex template]] for font source packages containing several different font families. + +While this package has been created by Fedora for Fedora, its content should be pretty generic. Apart from the occasional reference to this wiki as documentation source, it should not include any blatant Fedora-ism. + +''fontpackages'' evolutions can be discussed on the Fonts SIG [[Fonts SIG mailing lists|mailing list]]. + == Package layout for fonts == # Fonts released upstream in separate archives '''MUST''' be packaged in separate source packages (''src.rpm''), unless they belong to the same font family. From 1d1c365dbeeb340a13803816f61df84a0f0056e9 Mon Sep 17 00:00:00 2001 From: Spot Date: Jan 20 2009 20:58:04 +0000 Subject: [PATCH 212/3559] *Empty MediaWiki Message* --- diff --git a/Packaging:FontsPolicy.mw b/Packaging:FontsPolicy.mw index fb3d406..e259772 100644 --- a/Packaging:FontsPolicy.mw +++ b/Packaging:FontsPolicy.mw @@ -4,33 +4,33 @@ The FLOSS font scene is still too young to have evolved common licensing conventions. As a result packaging fonts will often require more legal work than packaging your average FLOSS app. Before you continue, check our [[Legal_considerations_for_fonts| legal page]]. -{{Anchor|build-from-sources}} -== Building from sources == - -Fonts '''SHOULD''' be built from source whenever upstream provides them in a source formatAs documented in our general [[Packaging/Guidelines#SourceRequirementExceptions|packaging guidelines]].. Automating the build ensures we'll be able to fix the fonts when problems are reported and upstream is not responsive. Sometimes that means working with upstream to sanitize its build processes. - -{{Anchor|no-handler-deps}} -== Install-time dependencies == - -Font packages in a generic format (TTF, OTF) are resources and '''MUST NOT''' force the installation of a particular font handler through direct or indirect ''Requires''. Fonts can be used by many different software stacks, including outside an X11 context, you should not choose one of them in the stead of users. - -Execution of stack-specific helpers in scriptlets is allowed, as long as it's conditioned on the presence of those helpers on the system, does not force their installation for the font package, and does not block package installation in their absence. - -Likewise, installation of stack-specific configuration files is allowed, if they have no effect in the absence of this software stack, and are auto-discovered on installation of the software stack package. +== Package layout for fonts == -{{Anchor|no-new-core-fonts}} -== Core fonts == +# Fonts released upstream in separate archives '''MUST''' be packaged in separate source packages (''src.rpm''), unless they belong to the same font family. +# Packagers '''SHOULD''' ask upstream to release each font family in a separate versioned archive, when it bundles in a common release archive: +## fonts with other material such as application code, or +## different font families. +#* As an exception, when a project is the upstream of several font families, which are all licensed the same way, and released on the same date, with the same version, the use of a common release archive is tolerated. +# Packagers '''MUST''' package each font family in a separate (''noarch.rpm'') (sub)package, notwithstanding on how they applied the previous source package (''src.rpm'') rules. The only admitted exceptions are: +## source packages that only include one font family and no other code or content (font documentation excepted), in which case a simple package is fine, +## font families which are designed to extend other font families with larger Unicode coverage (for example ''Arial Unicode'', ''Droid Sans Fallback''), in which case grouping the font family and its extension in a single (sub)package is acceptable. +##* such cases should be notified to the fontconfig maintainer and the Fedora [[Fonts SIG mailing lists|fonts list]], so the font family split can be eventually hidden from users. +## fonts that use a format that bundles different font families in a single file. +# On the other hand, the different faces of a font family '''MUST''' be packaged together in a common (''noarch.rpm'') (sub)package, and not spread over different (sub)packages -Once upon a time every Linux GUI application used the so-called ''Core fonts'' server-side X11 backendFonts accessed through the original ''core'' X protocol, using tools like ''mkfontdir'', ''xfs'', ''/etc/X11/fontpath.d/'', ''XLFD'' strings, etc. See also this [http://keithp.com/~keithp/talks/xtc2001/paper/ paper] written shortly before projects massively migrated to client-side fonts.. It was riddled with problems. The FLOSS developers finally gave up on it, declared it legacy and broken by design, and moved to client-side font handling (''fontconfig''). Nowadays almost no modern Linux GUI application uses the ''Core fonts'' backend. Few (if any) people are willing to fix its remaining bugs. +'''Rationale:''' -Therefore, unless your font has previously been registered in ''Core fonts'', and the problems triggered by this font hopefully fixed, you '''SHOULD NOT''' declare it there. This is especially true of fonts in modern (TTF or OTF) formats. +As noted in the [[Packaging/Guidelines#Bundling |Packaging Guidelines]], Fedora packages should make every effort to avoid having multiple, separate, upstream projects bundled together in a single package. This applies equally to font packages. -The users of this legacy backend won't thank you for destabilizing it with new fonts. They value stability. Otherwise they'd have moved to ''fontconfig'' like everyone else a long time ago. +Multi-source packages are difficult to maintain and confusing to users. In addition, fonts are comparatively bulky, and big font packages will be blacklisted from live-cds and by low-bandwidth users. -{{Anchor|grouping}} -== Grouping == +The functional font unit for users is the font family. Users don't understand partially installed fonts (font faces spread over different packages) and bundles (multi-family packages that force them to install fonts they may not care of or even like just to get the other fonts in the package). Because it is a unit, projects will extend or fork a font family as a whole, but not necessarily in step with other bundled families. -{{:Comps_fonts_rules}} +Lastly, multi-font packages unnecessarily complexify font auto-installation.. + +Notes: + + == Naming == @@ -158,6 +158,11 @@ TEX overlay for ctan-cm-lgc fonts Notes: +{{Anchor|build-from-sources}} +== Building from sources == + +Fonts '''SHOULD''' be built from source whenever upstream provides them in a source formatAs documented in our general [[Packaging/Guidelines#SourceRequirementExceptions|packaging guidelines]].. Automating the build ensures we'll be able to fix the fonts when problems are reported and upstream is not responsive. Sometimes that means working with upstream to sanitize its build processes. + == Technical implementation == Creating font packages or subpackages in Fedora is done using the ''fontpackages-devel'' packageBuilt from the [[pkgdb:fontpackages|fontpackages]] srpm.. Its sources are published on [http://fedorahosted.org/ fedorahosted] in [http://fedorahosted.org/releases/f/o/fontpackages/ archive] and git (git://git.fedorahosted.org/fontpackages.git) formats. @@ -170,33 +175,28 @@ While this package has been created by Fedora for Fedora, its content should be ''fontpackages'' evolutions can be discussed on the Fonts SIG [[Fonts SIG mailing lists|mailing list]]. -== Package layout for fonts == +{{Anchor|no-handler-deps}} +== Install-time dependencies == -# Fonts released upstream in separate archives '''MUST''' be packaged in separate source packages (''src.rpm''), unless they belong to the same font family. -# Packagers '''SHOULD''' ask upstream to release each font family in a separate versioned archive, when it bundles in a common release archive: -## fonts with other material such as application code, or -## different font families. -#* As an exception, when a project is the upstream of several font families, which are all licensed the same way, and released on the same date, with the same version, the use of a common release archive is tolerated. -# Packagers '''MUST''' package each font family in a separate (''noarch.rpm'') (sub)package, notwithstanding on how they applied the previous source package (''src.rpm'') rules. The only admitted exceptions are: -## source packages that only include one font family and no other code or content (font documentation excepted), in which case a simple package is fine, -## font families which are designed to extend other font families with larger Unicode coverage (for example ''Arial Unicode'', ''Droid Sans Fallback''), in which case grouping the font family and its extension in a single (sub)package is acceptable. -##* such cases should be notified to the fontconfig maintainer and the Fedora [[Fonts SIG mailing lists|fonts list]], so the font family split can be eventually hidden from users. -## fonts that use a format that bundles different font families in a single file. -# On the other hand, the different faces of a font family '''MUST''' be packaged together in a common (''noarch.rpm'') (sub)package, and not spread over different (sub)packages +Font packages in a generic format (TTF, OTF) are resources and '''MUST NOT''' force the installation of a particular font handler through direct or indirect ''Requires''. Fonts can be used by many different software stacks, including outside an X11 context, you should not choose one of them in the stead of users. -'''Rationale:''' +Execution of stack-specific helpers in scriptlets is allowed, as long as it's conditioned on the presence of those helpers on the system, does not force their installation for the font package, and does not block package installation in their absence. -As noted in the [[Packaging/Guidelines#Bundling |Packaging Guidelines]], Fedora packages should make every effort to avoid having multiple, separate, upstream projects bundled together in a single package. This applies equally to font packages. +Likewise, installation of stack-specific configuration files is allowed, if they have no effect in the absence of this software stack, and are auto-discovered on installation of the software stack package. -Multi-source packages are difficult to maintain and confusing to users. In addition, fonts are comparatively bulky, and big font packages will be blacklisted from live-cds and by low-bandwidth users. +{{Anchor|grouping}} +== Grouping == -The functional font unit for users is the font family. Users don't understand partially installed fonts (font faces spread over different packages) and bundles (multi-family packages that force them to install fonts they may not care of or even like just to get the other fonts in the package). Because it is a unit, projects will extend or fork a font family as a whole, but not necessarily in step with other bundled families. +{{:Comps_fonts_rules}} -Lastly, multi-font packages unnecessarily complexify font auto-installation.. - -Notes: - - +{{Anchor|no-new-core-fonts}} +== Core fonts == + +Once upon a time every Linux GUI application used the so-called ''Core fonts'' server-side X11 backendFonts accessed through the original ''core'' X protocol, using tools like ''mkfontdir'', ''xfs'', ''/etc/X11/fontpath.d/'', ''XLFD'' strings, etc. See also this [http://keithp.com/~keithp/talks/xtc2001/paper/ paper] written shortly before projects massively migrated to client-side fonts.. It was riddled with problems. The FLOSS developers finally gave up on it, declared it legacy and broken by design, and moved to client-side font handling (''fontconfig''). Nowadays almost no modern Linux GUI application uses the ''Core fonts'' backend. Few (if any) people are willing to fix its remaining bugs. + +Therefore, unless your font has previously been registered in ''Core fonts'', and the problems triggered by this font hopefully fixed, you '''SHOULD NOT''' declare it there. This is especially true of fonts in modern (TTF or OTF) formats. + +The users of this legacy backend won't thank you for destabilizing it with new fonts. They value stability. Otherwise they'd have moved to ''fontconfig'' like everyone else a long time ago. {{:Fonts_SIG_signature}} [[Category:Fonts packaging|Packaging policy]] From feea6256f33dd356c32037f77cfdf224bdbaadd9 Mon Sep 17 00:00:00 2001 From: Spot Date: Jan 20 2009 20:59:25 +0000 Subject: [PATCH 213/3559] *Empty MediaWiki Message* --- diff --git a/Packaging:GuidelinesTodo.mw b/Packaging:GuidelinesTodo.mw index 57cbe01..896da11 100644 --- a/Packaging:GuidelinesTodo.mw +++ b/Packaging:GuidelinesTodo.mw @@ -17,17 +17,6 @@ Status should be one of: |- |ratify||Symlinks ||spot ||2009-01-20 ||[[PackagingDrafts/Symlinks]] |- -|writeup||RubyGem with C code || mtasaka ||2008-12-09||[[PackagingDrafts/RubyGem with C code]] -|- -|writeup||Font packaging automation || [[Nicolas Mailhot]] ||2008-12-09||[[PackagingDrafts/Fonts_packaging_automation]] Refactoring of Fedora fonts packaging guidelines and template -|- -|writeup||Updates to the Eclipse plugin guidelines || overholt || 2008-12-09 || Was previously discussed [https://www.redhat.com/archives/fedora-packaging/2008-October/msg00121.html here]. Only difference from that diff is the addition of Fedora 9 notes as requested [https://www.redhat.com/archives/fedora-packaging/2008-December/msg00006.html here]. http://overholt.fedorapeople.org/EclipsePlugins.diff -|- -|writeup||Make adherence to the FHS a '''MUST''', with the added exception of /usr/ for cross toolchains.|| spot || 2008-12-09 ||https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00074.html "with exceptions for libexecdir (specified in the [http://www.gnu.org/prep/standards/standards.html#Directory-Variables GNU Coding Standards]) and /usr/target for crosscompilers" -|- -|writeup||Font package splitting rules (guidelines change) || [[Nicolas Mailhot]] || 2009-01-06 || [[PackagingDrafts/Font package splitting rules (2008-12-21)]] -|- -|writeup||Font Packaging Naming Guidelines || [[Nicolas Mailhot]] || 2009-01-14 || [[PackagingDrafts/Font_package_naming_%282009-01-13%29]] |} {{:PackagingDrafts/DraftsTodo}} @@ -37,6 +26,20 @@ Status should be one of: |- style="color: white; background-color: #3074c2; font-weight: bold" |Task Name||Owner||Resolution Date||Notes |- +|Update Desktop File Install Usage to Drop Vendor || spot || 2009-01-20 || [[TomCallaway/DesktopFileVendor]] +|- +|Font Packaging Naming Guidelines || [[Nicolas Mailhot]] || 2009-01-20 || [[PackagingDrafts/Font_package_naming_%282009-01-13%29]] +|- +|Font package splitting rules (guidelines change) || [[Nicolas Mailhot]] || 2009-01-20 || [[PackagingDrafts/Font package splitting rules (2008-12-21)]] +|- +|Make adherence to the FHS a '''MUST''', with the added exception of /usr/ for cross toolchains.|| spot || 2008-01-20 ||https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00074.html "with exceptions for libexecdir (specified in the [http://www.gnu.org/prep/standards/standards.html#Directory-Variables GNU Coding Standards]) and /usr/target for crosscompilers" +|- +|Updates to the Eclipse plugin guidelines || overholt || 2009-01-20 || Was previously discussed [https://www.redhat.com/archives/fedora-packaging/2008-October/msg00121.html here]. Only difference from that diff is the addition of Fedora 9 notes as requested [https://www.redhat.com/archives/fedora-packaging/2008-December/msg00006.html here]. http://overholt.fedorapeople.org/EclipsePlugins.diff +|- +|RubyGem with C code || mtasaka ||2009-01-20||[[PackagingDrafts/RubyGem with C code]] +|- +|Font packaging automation || [[Nicolas Mailhot]] ||2008-01-20||[[PackagingDrafts/Fonts_packaging_automation]] Refactoring of Fedora fonts packaging guidelines and template +|- |[[SIGs/MinGW|MinGW]] ||[[RichardJones]]|| 2008-11-18 ||[[PackagingDrafts/MinGW]] - As of 2008-09-22 these are in a good state for discussion. |- |Unowned Directories||abadger1999|| 2008-10-30 ||[[PackagingDrafts/UnownedDirectories]] Clarification only From 6d6489bb6c7e5bd668e67a1489ab019b2205d262 Mon Sep 17 00:00:00 2001 From: Spot Date: Jan 20 2009 20:59:41 +0000 Subject: [PATCH 214/3559] MUST follow FHS, not SHOULD --- diff --git a/Packaging:Guidelines.mw b/Packaging:Guidelines.mw index eb17f6b..ff8c3cd 100644 --- a/Packaging:Guidelines.mw +++ b/Packaging:Guidelines.mw @@ -7,9 +7,9 @@ It is the reviewer's responsibility to point out specific problems with a packag Please remember that any package that you submit must also conform to the [[Packaging/ReviewGuidelines| Review Guidelines]] . '''Author:''' [[TomCallaway| Tom 'spot' Callaway]] (based on many other documents)
-'''Revision:''' 0.97
+'''Revision:''' 0.98
'''Initial Draft:''' Wednesday Feb 23, 2005
-'''Last Revised:''' Friday Jan 9, 2009
+'''Last Revised:''' Tuesday Jan 20, 2009
{{Anchor|Naming}} == Naming == @@ -85,9 +85,9 @@ If a Fedora package does not successfully compile, build or work on an architect == Filesystem Layout == -Fedora follows the [http://www.pathname.com/fhs/ Filesystem Hierarchy Standard] with regards to filesystem layout. The FHS defines where files should be placed on the system. Fedora packages should follow the FHS whenever possible. Any deviation from the FHS should be rationalized when the package is reviewed. +Fedora follows the [http://www.pathname.com/fhs/ Filesystem Hierarchy Standard] with regards to filesystem layout. The FHS defines where files should be placed on the system. Fedora packages must follow the FHS. Any deviation from the FHS should be rationalized when the package is reviewed. -There is one notable exception, libexecdir. +There are notable exceptions to this guideline for libexecdir (as specified in the [[http://www.gnu.org/prep/standards/standards.html#Directory-Variables|GNU Coding Standards]]) and /usr/target for cross-compilers. {{Anchor|libexecdir}} === Libexecdir === @@ -226,7 +226,6 @@ Packages should not use the PreReq tag. Once upon a time, in dependency loops Pr Rpm gives you the ability to depend on files instead of packages. Whenever possible you should avoid file dependencies outside of /etc, /bin, /sbin, /usr/bin, or /usr/sbin. Using file dependencies outside of those directories requires yum (and other depsolvers using the repomd format) to download and parse a large xml file looking for the dependency. Helping the depsolvers avoid this processing by depending on the package instead of the file saves our end users a lot of time. There are times when other technical considerations outweigh these considerations. One specific example is packages installing into %{_libdir}/mozilla/plugins. In this case, mandating a specific browser in your package just to own this directory could drag in a large amount of needless packages. Requiring the directory to resolve the dependency is the better choice. {{Anchor|BuildRequires}} - == BuildRequires == In package development and testing, please verify that your package is not missing any necessary build dependencies. Having proper build requirements saves the time of all developers and testers as well as autobuild systems because they will not need to search for missing build requirements manually. It is also a safety feature that prevents builds with that would not otherwise fail, but would be missing crucial features. For example, a graphical application may exclude PNG support after its '''configure''' script detects that libpng is not installed. From b170f6c318e31522dfb61b1c66eabaf41860c5d6 Mon Sep 17 00:00:00 2001 From: Spot Date: Jan 20 2009 21:04:41 +0000 Subject: [PATCH 215/3559] *Empty MediaWiki Message* --- diff --git a/Packaging:FontsPolicy.mw b/Packaging:FontsPolicy.mw index e259772..419a026 100644 --- a/Packaging:FontsPolicy.mw +++ b/Packaging:FontsPolicy.mw @@ -4,6 +4,8 @@ The FLOSS font scene is still too young to have evolved common licensing conventions. As a result packaging fonts will often require more legal work than packaging your average FLOSS app. Before you continue, check our [[Legal_considerations_for_fonts| legal page]]. +{{Admon/note|What is a font family?|{{:Fonts spec template notes/font-family}}}} + == Package layout for fonts == # Fonts released upstream in separate archives '''MUST''' be packaged in separate source packages (''src.rpm''), unless they belong to the same font family. @@ -27,10 +29,6 @@ Multi-source packages are difficult to maintain and confusing to users. In addit The functional font unit for users is the font family. Users don't understand partially installed fonts (font faces spread over different packages) and bundles (multi-family packages that force them to install fonts they may not care of or even like just to get the other fonts in the package). Because it is a unit, projects will extend or fork a font family as a whole, but not necessarily in step with other bundled families. Lastly, multi-font packages unnecessarily complexify font auto-installation.. - -Notes: - - == Naming == @@ -154,9 +152,6 @@ TEX overlay for ctan-cm-lgc fonts (cooked up example, this page is not a TEX naming guideline) |- |} - -Notes: - {{Anchor|build-from-sources}} == Building from sources == @@ -198,5 +193,8 @@ Therefore, unless your font has previously been registered in ''Core fonts'', an The users of this legacy backend won't thank you for destabilizing it with new fonts. They value stability. Otherwise they'd have moved to ''fontconfig'' like everyone else a long time ago. +== Notes == + + {{:Fonts_SIG_signature}} [[Category:Fonts packaging|Packaging policy]] From 75c47b5a5f831230569bd60d3e648f702792f756 Mon Sep 17 00:00:00 2001 From: Spot Date: Jan 20 2009 21:06:20 +0000 Subject: [PATCH 216/3559] *Empty MediaWiki Message* --- diff --git a/Packaging:FontsPolicy.mw b/Packaging:FontsPolicy.mw index 419a026..26f91ee 100644 --- a/Packaging:FontsPolicy.mw +++ b/Packaging:FontsPolicy.mw @@ -4,6 +4,7 @@ The FLOSS font scene is still too young to have evolved common licensing conventions. As a result packaging fonts will often require more legal work than packaging your average FLOSS app. Before you continue, check our [[Legal_considerations_for_fonts| legal page]]. +

{{Admon/note|What is a font family?|{{:Fonts spec template notes/font-family}}}} == Package layout for fonts == From 7b9b67d569552e5041aeb5d2e53d3094efb993c7 Mon Sep 17 00:00:00 2001 From: Spot Date: Jan 20 2009 21:09:40 +0000 Subject: [PATCH 217/3559] *Empty MediaWiki Message* --- diff --git a/Packaging:Scriptlets.mw b/Packaging:Scriptlets.mw index 2e5ae42..cff0505 100644 --- a/Packaging:Scriptlets.mw +++ b/Packaging:Scriptlets.mw @@ -231,23 +231,3 @@ if [ -x %{_bindir}/gtk-update-icon-cache ] ; then %{_bindir}/gtk-update-icon-cache --quiet %{_datadir}/icons/hicolor || : fi - -{{Anchor|fonts}} - -== Fonts == -Use this when your package installs new fonts. -
-%post
-if [ -x %{_bindir}/fc-cache ] ; then
-  %{_bindir}/fc-cache %{_datadir}/fonts || :
-fi
-%postun
-if [ "$1" = "0" ] ; then
-  if [ -x %{_bindir}/fc-cache ] ; then
-    %{_bindir}/fc-cache %{_datadir}/fonts || :
-  fi
-fi
-
- ----- -[[Category:Extras]] From 2217915b4ae951ed8371a753cc3b1d22384a0021 Mon Sep 17 00:00:00 2001 From: Spot Date: Jan 20 2009 21:12:21 +0000 Subject: [PATCH 218/3559] /* Avoid bundling of fonts in other packages */ --- diff --git a/Packaging:Guidelines.mw b/Packaging:Guidelines.mw index ff8c3cd..a040a21 100644 --- a/Packaging:Guidelines.mw +++ b/Packaging:Guidelines.mw @@ -863,6 +863,10 @@ Fedora packages should make every effort to avoid having multiple, separate, ups {{Anchor|AvoidFontBundling}} === Avoid bundling of fonts in other packages === +Multi-source packages are difficult to maintain and confusing to users. In addition, fonts are comparatively bulky, and big font packages will be blacklisted from live-cds and by low-bandwidth users. The functional font unit for users is the font family. Users don't understand partially installed fonts (font faces spread over different packages) and bundles (multi-family packages that force them to install fonts they may not care of or even like just to get the other fonts in the package). Because it is a unit, projects will extend or fork a font family as a whole, but not necessarily in step with other bundled families. Lastly, multi-font packages unnecessarily complexify font auto-installation. + +For more information, see: [[Packaging:FontsPolicy#Package_layout_for_fonts]]. + Given that fonts can be reused in many ways, that they can be bulky, that they usually have distinct licensing requirements, and that font legal problems are endemic: # any package that makes use of bundled font files '''SHOULD''' strongly consider packaging them in a separate sub-package, if they have any value outside of the package From 5b0f4087d56588c3d5e76e813c61e863ddbe8539 Mon Sep 17 00:00:00 2001 From: Spot Date: Jan 20 2009 21:13:23 +0000 Subject: [PATCH 219/3559] /* Avoid bundling of fonts in other packages */ --- diff --git a/Packaging:Guidelines.mw b/Packaging:Guidelines.mw index a040a21..39f3a17 100644 --- a/Packaging:Guidelines.mw +++ b/Packaging:Guidelines.mw @@ -867,18 +867,6 @@ Multi-source packages are difficult to maintain and confusing to users. In addit For more information, see: [[Packaging:FontsPolicy#Package_layout_for_fonts]]. -Given that fonts can be reused in many ways, that they can be bulky, that they usually have distinct licensing requirements, and that font legal problems are endemic: - -# any package that makes use of bundled font files '''SHOULD''' strongly consider packaging them in a separate sub-package, if they have any value outside of the package -#*Font files which are in a standardized format, and contain a set of characters or symbols which are useful for other packages are considered to have value. -#*if a package includes fonts with value outside the application, the packager '''SHOULD''' ask upstream to publish the font files separately -# the packager(s) and reviewer(s) of fonts '''MUST''' be familiar with our [[Legal_considerations_for_fonts|fonts legal page]]. -# they '''SHOULD''' exert their best efforts to trace fonts to their original creators, and not ship fonts collected by middlemen with no modifications. -#* middlemen often strip part of the legal context. -# they '''SHOULD''' package each font family separately, and avoid font collections that mix fonts of different history, licensing, or origin. -#* font collections hide legal problems in the mass. -#* the exception is fonts created by the same authors and released at the same time in the same archive. But even then it is very possible some fonts will be tainted, while the others are fine. - In addition, fonts in general-purpose formats such as Type1, OpenType TT (TTF) or OpenType CFF (OTF) are subject to specific packaging guidelines ([[Packaging/FontsPolicy|1]], [[Packaging/FontsSpecTemplate|2]]), and should never be packaged in a private application directory instead of the system-wide font repositories. == All patches should have an upstream bug link or comment == From eeb7c3b33427c6951cbdc5674dcd1680d88ae4eb Mon Sep 17 00:00:00 2001 From: Spot Date: Jan 20 2009 21:16:02 +0000 Subject: [PATCH 220/3559] /* Avoid bundling of fonts in other packages */ --- diff --git a/Packaging:Guidelines.mw b/Packaging:Guidelines.mw index 39f3a17..89b0de0 100644 --- a/Packaging:Guidelines.mw +++ b/Packaging:Guidelines.mw @@ -863,12 +863,9 @@ Fedora packages should make every effort to avoid having multiple, separate, ups {{Anchor|AvoidFontBundling}} === Avoid bundling of fonts in other packages === -Multi-source packages are difficult to maintain and confusing to users. In addition, fonts are comparatively bulky, and big font packages will be blacklisted from live-cds and by low-bandwidth users. The functional font unit for users is the font family. Users don't understand partially installed fonts (font faces spread over different packages) and bundles (multi-family packages that force them to install fonts they may not care of or even like just to get the other fonts in the package). Because it is a unit, projects will extend or fork a font family as a whole, but not necessarily in step with other bundled families. Lastly, multi-font packages unnecessarily complexify font auto-installation. - +Fonts in general-purpose formats such as Type1, OpenType TT (TTF) or OpenType CFF (OTF) are subject to specific packaging guidelines ([[Packaging/FontsPolicy|1]], [[Packaging/FontsSpecTemplate|2]]), and should never be packaged in a private application directory instead of the system-wide font repositories. For more information, see: [[Packaging:FontsPolicy#Package_layout_for_fonts]]. -In addition, fonts in general-purpose formats such as Type1, OpenType TT (TTF) or OpenType CFF (OTF) are subject to specific packaging guidelines ([[Packaging/FontsPolicy|1]], [[Packaging/FontsSpecTemplate|2]]), and should never be packaged in a private application directory instead of the system-wide font repositories. - == All patches should have an upstream bug link or comment == All patches in Fedora spec files '''SHOULD''' have a comment above them about their upstream status. Any time you create a patch, it is best practice to file it in an upstream bug tracker, and include a link to that in the comment above the patch. For example: From 2b918d2964201ed31bf6a8dbec3bb33d28103e0d Mon Sep 17 00:00:00 2001 From: Spot Date: Jan 20 2009 21:19:15 +0000 Subject: [PATCH 221/3559] [[Packaging:FontsSpecTemplate]] moved to [[OldFontsSpecTemplate]] --- diff --git a/Packaging:FontsSpecTemplate.mw b/Packaging:FontsSpecTemplate.mw new file mode 100644 index 0000000..af5dd74 --- /dev/null +++ b/Packaging:FontsSpecTemplate.mw @@ -0,0 +1 @@ +#REDIRECT [[OldFontsSpecTemplate]] From 9b89e963c1d6dfcd48e4fceb93f7ca3911f54353 Mon Sep 17 00:00:00 2001 From: Spot Date: Jan 20 2009 21:20:02 +0000 Subject: [PATCH 222/3559] /* Avoid bundling of fonts in other packages */ --- diff --git a/Packaging:Guidelines.mw b/Packaging:Guidelines.mw index 89b0de0..e44108b 100644 --- a/Packaging:Guidelines.mw +++ b/Packaging:Guidelines.mw @@ -863,7 +863,7 @@ Fedora packages should make every effort to avoid having multiple, separate, ups {{Anchor|AvoidFontBundling}} === Avoid bundling of fonts in other packages === -Fonts in general-purpose formats such as Type1, OpenType TT (TTF) or OpenType CFF (OTF) are subject to specific packaging guidelines ([[Packaging/FontsPolicy|1]], [[Packaging/FontsSpecTemplate|2]]), and should never be packaged in a private application directory instead of the system-wide font repositories. +Fonts in general-purpose formats such as Type1, OpenType TT (TTF) or OpenType CFF (OTF) are subject to specific packaging guidelines ([[Packaging/FontsPolicy|1]]), and should never be packaged in a private application directory instead of the system-wide font repositories. For more information, see: [[Packaging:FontsPolicy#Package_layout_for_fonts]]. == All patches should have an upstream bug link or comment == From f4635105f63740b6531821db30b040770ec46a1d Mon Sep 17 00:00:00 2001 From: Redirect fixer Date: Jan 21 2009 21:51:57 +0000 Subject: [PATCH 223/3559] [[OldFontsSpecTemplate]] has been moved, it is now a redirect to [[Fonts spec template (2008-10-01)]] --- diff --git a/Packaging:FontsSpecTemplate.mw b/Packaging:FontsSpecTemplate.mw index af5dd74..467c3ea 100644 --- a/Packaging:FontsSpecTemplate.mw +++ b/Packaging:FontsSpecTemplate.mw @@ -1 +1 @@ -#REDIRECT [[OldFontsSpecTemplate]] +#REDIRECT [[Fonts spec template (2008-10-01)]] From 6019020f17ff67d99c6baff127c1a0e90ef491ba Mon Sep 17 00:00:00 2001 From: Redirect fixer Date: Jan 21 2009 21:55:14 +0000 Subject: [PATCH 224/3559] [[Fonts spec template (2008-10-01)]] has been moved, it is now a redirect to [[Fonts spec template (2007-10-01)]] --- diff --git a/Packaging:FontsSpecTemplate.mw b/Packaging:FontsSpecTemplate.mw index 467c3ea..742a9c0 100644 --- a/Packaging:FontsSpecTemplate.mw +++ b/Packaging:FontsSpecTemplate.mw @@ -1 +1 @@ -#REDIRECT [[Fonts spec template (2008-10-01)]] +#REDIRECT [[Fonts spec template (2007-10-01)]] From 9b9346fd461bd569444854ccd65a0429ccc7f8d0 Mon Sep 17 00:00:00 2001 From: Spot Date: Jan 29 2009 21:17:28 +0000 Subject: [PATCH 225/3559] /* Summary and description */ --- diff --git a/Packaging:Guidelines.mw b/Packaging:Guidelines.mw index e44108b..831f946 100644 --- a/Packaging:Guidelines.mw +++ b/Packaging:Guidelines.mw @@ -344,7 +344,21 @@ The summary should be a short and concise description of the package. The descri Please put personal preferences aside and use American English spelling in the summary and description. Packages can contain additional translated summary/description for supported Non-English languages, if available. +=== Trademarks in Summary or Description === +Packagers should be careful how they use trademarks in Summary or Description. There are a few rules to follow: +* Never use "(TM)" or "(R)" (or the unicode equivalents, ™/®). It is incredibly complicated to use these properly, so it is actually safer for us to not use them at all. +* Use trademarks in a way that is not ambiguous. Avoid phrasing like "similar to" or "like". Some examples: + +* '''BAD:''' It is similar to Adobe Photoshop. +* '''GOOD:''' It supports Adobe Photoshop PSD files, ... + +* '''BAD:''' A Linux version of Microsoft Office +* '''GOOD:''' A word-processor with support for Microsoft Office DOC files + +If you're not sure, ask yourself, is there any chance someone may get confused and think that this package is the trademarked item? When in doubt, try to leave the trademark out. + {{Anchor|PackageEncoding}} + == Encoding == Unless you need to use characters outside the [http://commons.wikimedia.org/wiki/Image:Ascii_full.png ASCII repertoire] , you will not need to be concerned about the encoding of the spec file. If you do need non-ASCII characters, save your spec files as UTF-8. If you're in doubt as to what characters are ASCII, please refer to [http://commons.wikimedia.org/wiki/Image:Ascii_full.png this chart] . From 8043ae7841e55d1e80086f76f47f935956d55fd8 Mon Sep 17 00:00:00 2001 From: Spot Date: Jan 31 2009 19:25:32 +0000 Subject: [PATCH 226/3559] /* .desktop file creation */ --- diff --git a/Packaging:Guidelines.mw b/Packaging:Guidelines.mw index 831f946..35f3ede 100644 --- a/Packaging:Guidelines.mw +++ b/Packaging:Guidelines.mw @@ -532,8 +532,7 @@ The short name without file extension is preferred, because it allows for icon t If the package doesn't already include and install its own .desktop file, you need to make your own, and include it as a Source: (e.g. Source3: %{name}.desktop). Here are the contents of a sample .desktop file (comical.desktop): 
-[Desktop Entry] 
-Encoding=UTF-8
+[Desktop Entry]
 Name=Comical
 GenericName=Comic Archive Reader
 Comment=Open .cbr & .cbz files

From f652de8b7eb75728abd41c5329a2a055975c787d Mon Sep 17 00:00:00 2001
From: Spot 
Date: Feb 03 2009 22:00:46 +0000
Subject: [PATCH 227/3559] *Empty MediaWiki Message*


---

diff --git a/Packaging:Perl.mw b/Packaging:Perl.mw
index 1c6f0fe..49a03c9 100644
--- a/Packaging:Perl.mw
+++ b/Packaging:Perl.mw
@@ -203,3 +203,7 @@ It's common practice to set the [https://www.redhat.com/mailman/listinfo/fedora-
 = cpanspec =
 
 cpanspec is an excellent little tool to assist in creating Fedora-compliant packages from CPAN-based modules.  Its use as a starting point is recommended (but certainly not mandated).
+
+For more information, see: https://fedoraproject.org/wiki/Perl/cpanspec 
+
+[[Category:Perl]]

From 61d0505572b6787c55dbd8d37c770416ca217399 Mon Sep 17 00:00:00 2001
From: Spot 
Date: Feb 03 2009 22:04:04 +0000
Subject: [PATCH 228/3559] *Empty MediaWiki Message*


---

diff --git a/Packaging:Perl.mw b/Packaging:Perl.mw
index 49a03c9..a9d1c46 100644
--- a/Packaging:Perl.mw
+++ b/Packaging:Perl.mw
@@ -190,7 +190,7 @@ Perl modules typically utilize one of two different buildsystems:
 
 The two different styles are easily recognizable:  ExtUtils::MakeMaker employs the Makefile.PL build file, and is the "classical" approach; Module::Build is a newer approach, with support for things MakeMaker cannot do.  While the ultimate choice of which system to employ is clearly in the hands of upstream, if Build.PL is present in a distribution the packager should employ that build framework unless there is a good reason otherwise.
 
-See also ["Perl/Build.PL VsMakefile.PL"] .
+See also [[PackagingTips/Perl#Makefile.PL_vs_Build.PL]] .
 
 = .h files in module packages =
 
@@ -204,6 +204,6 @@ It's common practice to set the [https://www.redhat.com/mailman/listinfo/fedora-
 
 cpanspec is an excellent little tool to assist in creating Fedora-compliant packages from CPAN-based modules.  Its use as a starting point is recommended (but certainly not mandated).
 
-For more information, see: https://fedoraproject.org/wiki/Perl/cpanspec 
+For more information, see: [[Perl/cpanspec]] 
 
 [[Category:Perl]]

From a5e5504699f6b43ab870602f73808e3786adfc8b Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Feb 04 2009 03:50:31 +0000
Subject: [PATCH 229/3559] Fix broken links to mediawiki syntax


---

diff --git a/Packaging:Python_Eggs.mw b/Packaging:Python_Eggs.mw
index a190ccf..0dc74ac 100644
--- a/Packaging:Python_Eggs.mw
+++ b/Packaging:Python_Eggs.mw
@@ -21,9 +21,10 @@ In Fedora Packages, these will be installed to %{python_sitelib} or %{python_sit
 
 {{Anchor|WhenEggs}}
 == When to Provide Eggs ==
-Since eggs establish a base of functionality that upstream authors can expect, we need to be sure to include the egg files if a package builds them.  Starting with Fedora 9 any package that uses setuptools or distutils will build egg-info.  In Fedora 8 or less, only setuptools packages build egg-info.  If you need to provide egg-info for a distutils package on Fedora 8 or less, [[NonSetuptoolsEggs|  Providing Eggs using Setuptools]]  describes a method of substituting setuptools for distutils in the build process so egg-info is created.
+Since eggs establish a base of functionality that upstream authors can expect, we need to be sure to include the egg files if a package builds them.  Starting with Fedora 9 any package that uses setuptools or distutils will build egg-info.  In Fedora 8 or less, only setuptools packages build egg-info.  If you need to provide egg-info for a distutils package on Fedora 8 or less, [[#Providing_Eggs_for_non-setuptools_packages|  Providing Eggs using Setuptools]]  describes a method of substituting setuptools for distutils in the build process so egg-info is created.
 
-{{ Template:note/| In the past, when there was a requirement for an egg which was not provided by upstream we would patch the requiring package to not require that package.  This behaviour is deprecated and as packages are updated maintainers should follow the below guidelines to install eggs for the required packages.  Please see [[NonSetuptoolsEggs|  Creating Eggs for Non-setuptools Packages]] 
+
+{{admon/note| In the past, when there was a requirement for an egg which was not provided by upstream we would patch the requiring package to not require that package.  This behaviour is deprecated and as packages are updated maintainers should follow the below guidelines to install eggs for the required packages.  Please see [[#Providing_Eggs_for_non-setuptools_packages|  Creating Eggs for Non-setuptools Packages]] 
 }}
 
 == Upstream Eggs ==

From 9c5548e61508e4e036d2f1c8874ce0b5b76e6f75 Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Feb 04 2009 03:53:31 +0000
Subject: [PATCH 230/3559] Fixan admon/note


---

diff --git a/Packaging:Python_Eggs.mw b/Packaging:Python_Eggs.mw
index 0dc74ac..400a3f3 100644
--- a/Packaging:Python_Eggs.mw
+++ b/Packaging:Python_Eggs.mw
@@ -48,10 +48,11 @@ BuildRequires: python-setuptools-devel
 %{python_sitelib}/*
-{{ /code/| commandline argument to create egg info and an expanded directory directly in site-packages. This is no longer necessary as --root creates things the way we want for packaging. +{{admon/note|Note: older versions of setuptools used the --single-version-externally-managed commandline argument to create egg info and an expanded directory directly in site-packages. This is no longer necessary as --root creates things the way we want for packaging. }} {{Anchor|NonSetuptoolsEggs}} + == Providing Eggs for non-setuptools packages == {{ Template:note/| These instructions are only for distutils in Fedora <= 8. Fedora 9 and above will automatically generate egg-info files. }} From 5d9c3b34f3fb49a9998184e013a00b013db1c56d Mon Sep 17 00:00:00 2001 From: Toshio Date: Feb 04 2009 03:55:26 +0000 Subject: [PATCH 231/3559] Comments in 
 did not get copied from moin


---

diff --git a/Packaging:Python_Eggs.mw b/Packaging:Python_Eggs.mw
index 400a3f3..a240a33 100644
--- a/Packaging:Python_Eggs.mw
+++ b/Packaging:Python_Eggs.mw
@@ -34,17 +34,25 @@ Do not distribute eggs from upstream.  In Fedora, all packages must be rebuilt f
 When upstream uses setuptools to provide eggs it is very simple to include them in your package.  Your spec file will look something like this:
 
 
+# Must have setuptools to build the package
+# The build portions moved to a subpackage in F-8
 BuildRequires: python-setuptools-devel
 
-[...] 
+[...]
 
+# --root $RPM_BUILD_ROOT makes the package install with a single, expanded
+# directory in %{python_sitelib} and a separate egginfo directory.
 %install
-%{__python} setup.py install --skip-build --root $RPM_BUILD_ROOT
+%{__python} setup.py install --skip-build --root $RPM_BUILD_ROOT 
 
-[...] 
+[...]
 
 %files
-[...] 
+[...]
+# This captures both the module directory and the egg-info directory
+# Something like:
+# /usr/lib/python2.5/site-packages/sqlalchemy
+# /usr/lib/python2.5/site-packages/SQLAlchemy-0.3.10-py2.5.egg-info
 %{python_sitelib}/*
 

 

From 33fe35135c2ef188f29350fd38b8338bb51521c5 Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Feb 04 2009 03:59:36 +0000
Subject: [PATCH 232/3559] Fix another admon/note


---

diff --git a/Packaging:Python_Eggs.mw b/Packaging:Python_Eggs.mw
index a240a33..68d7d7d 100644
--- a/Packaging:Python_Eggs.mw
+++ b/Packaging:Python_Eggs.mw
@@ -62,8 +62,8 @@ BuildRequires: python-setuptools-devel
 {{Anchor|NonSetuptoolsEggs}}
 
 == Providing Eggs for non-setuptools packages ==
-{{ Template:note/| These instructions are only for distutils in Fedora <= 8.  Fedora 9 and above will automatically generate egg-info files.
-}}
+
+{{admon/note|These instructions are only for distutils in RHEL4 & 5.  Fedora 9 and above will automatically generate egg-info files.}}
 
 When we need to provide eggs in a non-setuptools package because another package requires that functionality we can modify our spec files to generate the egg-info:
 

From 7887b7fb205236999c270a4cb0c11aa9fc07816b Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Feb 04 2009 04:02:31 +0000
Subject: [PATCH 233/3559] Fix some more comments not imported


---

diff --git a/Packaging:Python_Eggs.mw b/Packaging:Python_Eggs.mw
index 68d7d7d..bb93abf 100644
--- a/Packaging:Python_Eggs.mw
+++ b/Packaging:Python_Eggs.mw
@@ -88,21 +88,21 @@ By importing setuptools before executing setup.py we override the distutils func
 
 == Multiple Versions ==
 
-{{ /code/|  section
-}}
-
 Sometimes we want to keep an old version of a module around for compatibility.  When upstream has renamed the module for us, this is a straightforward creation of a new module.  For instance, python-psycopg and python-psycopg2.
 
 When upstream doesn't include the version in the name, we have to find another way to parallel install two versions of the package.  Eggs give us this ability.  The latest version of a package must be installed as the python-MODULENAME and is built using the normal guidelines.  The compatibility versions of the module should be named python-$MODULENAME$DISTINGUISHINGVER and be enabled by making these spec file changes:
 
 
+# Require setuptools as the consumer will need pkg_resources to use this module
 Requires: python-setuptools
 
 %build
+# Build an egg file that we can then install from
 CFLAGS="$RPM_OPT_FLAGS" %{__python} setup.py bdist_egg
 
 %install
 rm -rf $RPM_BUILD_ROOT
+# Install the egg so that only code that wants this particular version can get it.
 mkdir -p $RPM_BUILD_ROOT%{python_sitelib}
 easy_install -m --prefix $RPM_BUILD_ROOT%{_usr} dist/*.egg
 

@@ -116,7 +116,7 @@ This creates the python egg under the %{python_sitelib}/*.egg directory.  This m
* Using setuptools and easy_install to create "script wrappers" to invoke the programs. Setuptools has you define an entrypoint in the program's module (basically, a main() function) and then writes a script to access that via an option in setup.py. -It is highly recommended that any such compatibility packages install a README.fedora file explaining how to use this module. The file should contain the above examples of how to call the module from code and explain that this is a compat package and that a newer version exists. Here's an [[Image:Packaging_Python_Eggs_README.fedora]] example README.fedora] to look at for ideas. +It is highly recommended that any such compatibility packages install a README.fedora file explaining how to use this module. The file should contain the above examples of how to call the module from code and explain that this is a compat package and that a newer version exists. There are several other methods of invoking scripts so that they might take the right version but they suffer from various problems. They are listed here because a program you're packaging may use them and you need to know about them if they break. If you mention them in README.fedora, please also add why they are dangerous to use. From c97cd7fbcf08e55d61ea1cce7440857925f98bb7 Mon Sep 17 00:00:00 2001 From: Spot Date: Feb 17 2009 18:41:56 +0000 Subject: [PATCH 234/3559] *Empty MediaWiki Message* --- diff --git a/Packaging:GuidelinesTodo.mw b/Packaging:GuidelinesTodo.mw index 896da11..738ea30 100644 --- a/Packaging:GuidelinesTodo.mw +++ b/Packaging:GuidelinesTodo.mw @@ -17,6 +17,15 @@ Status should be one of: |- |ratify||Symlinks ||spot ||2009-01-20 ||[[PackagingDrafts/Symlinks]] |- +|ratify||global preferred over define|| abadger1999 || 2009-02-17 || [[PackagingDrafts/global_preferred_over_define]] +|- +|ratify|| PHP channel || [[User:Remi]] || 2009-02-17 || [[PackagingDrafts/PHP]] +|- +|ratify || Use of Epoch tag || spot || 2009-02-17 || [[PackagingDrafts/Epoch]] +|- +|ratify || Icon Cache update || [[User:Toshio]] || 2009-02-17 || [[PackagingDrafts/Icon_Cache]] +|- +|ratify || Duplicate Files update || [[User:Toshio]] || 2009-02-17 || [[PackagingDrafts/Duplicate Files]] |} {{:PackagingDrafts/DraftsTodo}} @@ -223,6 +232,10 @@ Status should be one of: |- style="color: white; background-color: #3074c2; font-weight: bold" |Task Name||Owner||Resolution Date||Notes |- +|Check for fonts in review || [[Nicolas Mailhot]] || 2009-02-17 || [[PackagingDrafts/ReviewGuideline_for_fonts_(2009-01-22)]] Packagers and reviewers should follow the Font Guidelines, but FPC is looking to phase out ReviewGuidelines, not to add to it. +|- +|User Creation|| abadger1999|| 2009-02-17 ||[[Packaging/UserCreation]] was never passed, and has been removed. +|- | Avoid packing junk in CMake/CPack || dchen ||2008-11-18 || [[PackagingDrafts/CmakeCpack]] isn't relevant for a Fedora Packaging guideline |- |Package Names should be all lowercase||abadger1999|| 2008-04-08 ||["PackagingDrafts/ASCIINamingLowercase"] From 65350f4065535c5da3ac09b5c11a8ab792e96579 Mon Sep 17 00:00:00 2001 From: Spot Date: Feb 18 2009 16:34:58 +0000 Subject: [PATCH 235/3559] *Empty MediaWiki Message* --- diff --git a/Packaging:Guidelines.mw b/Packaging:Guidelines.mw index 35f3ede..b8f72f5 100644 --- a/Packaging:Guidelines.mw +++ b/Packaging:Guidelines.mw @@ -16,6 +16,10 @@ Please remember that any package that you submit must also conform to the [[Pack You should go through the [[Packaging/NamingGuidelines]] to ensure that your package is named appropriately. +== Version and Release == + +Documentation covering the proper way to use the Version and Release fields can be found here: [[Packaging/NamingGuidelines#Package_Version]] + {{Anchor|Legal}} == Legal == From 0deebaaabcc1b4424d29f49a56af5ebb730dce82 Mon Sep 17 00:00:00 2001 From: Toshio Date: Feb 22 2009 19:32:07 +0000 Subject: [PATCH 236/3559] %define => %global --- diff --git a/Packaging:Tcl.mw b/Packaging:Tcl.mw index 04793c9..0326995 100644 --- a/Packaging:Tcl.mw +++ b/Packaging:Tcl.mw @@ -58,8 +58,8 @@ to indicate which Tcl version they were built against. This is necessary becaus The following macros '''must''' be used at the top of the spec file to determine the correct installation paths: 
-%{!?tcl_version: %define tcl_version %(echo 'puts $tcl_version' | tclsh)}
-%{!?tcl_sitelib: %define tcl_sitelib %{_datadir}/tcl%{tcl_version}}
+%{!?tcl_version: %global tcl_version %(echo 'puts $tcl_version' | tclsh)}
+%{!?tcl_sitelib: %global tcl_sitelib %{_datadir}/tcl%{tcl_version}}
In order for the macros to work, the package must also BuildRequires: tcl either directly, or indirectly with BuildRequires: tcl-devel @@ -84,8 +84,8 @@ It may also be acceptible to patch upstream's configure script and The following macros '''must''' be used at the top of the spec file to determine the correct installation paths: 
-%{!?tcl_version: %define tcl_version %(echo 'puts $tcl_version' | tclsh)}
-%{!?tcl_sitearch: %define tcl_sitearch %{_libdir}/tcl%{tcl_version}}
+%{!?tcl_version: %global tcl_version %(echo 'puts $tcl_version' | tclsh)}
+%{!?tcl_sitearch: %global tcl_sitearch %{_libdir}/tcl%{tcl_version}}
In order for the macros to work, the package must also BuildRequires: tcl either directly, or indirectly with BuildRequires: tcl-devel From 9c1d3ca31612661cdfad6aba042b81dad247a771 Mon Sep 17 00:00:00 2001 From: Toshio Date: Feb 22 2009 19:34:21 +0000 Subject: [PATCH 237/3559] %define => %global --- diff --git a/Packaging:Perl.mw b/Packaging:Perl.mw index a9d1c46..181a365 100644 --- a/Packaging:Perl.mw +++ b/Packaging:Perl.mw @@ -72,7 +72,7 @@ cat << \EOF > %{name}-prov sed -e '/perl(unwanted_provide)/d' EOF -%define __perl_provides %{_builddir}/%{name}-%{version}/%{name}-prov +%global __perl_provides %{_builddir}/%{name}-%{version}/%{name}-prov chmod +x %{__perl_provides} @@ -82,7 +82,7 @@ cat << \EOF > %{name}-req sed -e '/perl(unwanted_require)/d' EOF -%define __perl_requires %{_builddir}/%{name}-%{version}/%{name}-req +%global __perl_requires %{_builddir}/%{name}-%{version}/%{name}-req chmod +x %{__perl_requires} @@ -94,8 +94,8 @@ Or the script can be placed in an external file and referenced from the specfile Source98: filter-provides.sh Source99: filter-requires.sh -%define __perl_provides %{SOURCE98} -%define __perl_requires %{SOURCE99} +%global __perl_provides %{SOURCE98} +%global __perl_requires %{SOURCE99} where filter-provides.sh contains: 

From e243721a8e75e2789e4eff15471e3c3b9a2662b0 Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Feb 22 2009 19:34:43 +0000
Subject: [PATCH 238/3559] %define => %global


---

diff --git a/Packaging:GCJGuidelines.mw b/Packaging:GCJGuidelines.mw
index 2633115..dae6bc9 100644
--- a/Packaging:GCJGuidelines.mw
+++ b/Packaging:GCJGuidelines.mw
@@ -17,7 +17,7 @@ Like other Java runtimes, libgcj can load classes from bytecode class files.  Un
 * For packages in which all JAR files are in the main package:
 
 1. Add the following definition: 
-%define with_gcj %{!?_without_gcj:1}%{?_without_gcj:0}
+%global with_gcj %{!?_without_gcj:1}%{?_without_gcj:0}
 

 1. Conditionalize dependencies and be architecture dependent 
 %if %{with_gcj}

From 20791257315fcbe44db0f681ea5f922e1fad3348 Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Feb 22 2009 19:53:09 +0000
Subject: [PATCH 239/3559] %define => %global


---

diff --git a/Packaging:R.mw b/Packaging:R.mw
index 47f7804..25c2886 100644
--- a/Packaging:R.mw
+++ b/Packaging:R.mw
@@ -27,8 +27,8 @@ There are two types of R packages: arch-specific and noarch.
 === Arch specific R packaging spec template ===
 
 
-%define packname foo
-%define packrel 1
+%global packname foo
+%global packrel 1
 
 Name:             R-%{packname}
 Version:          1.6.6

From a056a79e2b2514d81f0269d0e4c729fc37c4ae8c Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Feb 22 2009 19:53:46 +0000
Subject: [PATCH 240/3559] %define => %global


---

diff --git a/Packaging:DistTag.mw b/Packaging:DistTag.mw
index 5db5d52..5288766 100644
--- a/Packaging:DistTag.mw
+++ b/Packaging:DistTag.mw
@@ -114,7 +114,7 @@ Here are some examples of how to use these variables in conditionals:
 %if 0%{?fedora} >= 4
 %endif
 
-%{?fedora:%define _with_xfce --with-xfce}
+%{?fedora:%global _with_xfce --with-xfce}
 
 %if 0%{?rhel}
 %if 0%{?rhl}

From b817db95c54bfa7aaf5b3f073864864c83b7c959 Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Feb 22 2009 19:54:03 +0000
Subject: [PATCH 241/3559] %define => %global


---

diff --git a/Packaging:R.mw b/Packaging:R.mw
index 25c2886..f36df89 100644
--- a/Packaging:R.mw
+++ b/Packaging:R.mw
@@ -95,8 +95,8 @@ rm -rf $RPM_BUILD_ROOT
 === Noarch R packaging spec template ===
 
 
-%define packname foo
-%define packrel 1
+%global packname foo
+%global packrel 1
 
 Name:             R-%{packname}
 Version:          1.6.6

From 040d65a4f77e3459dbb5246546c250eea5b6839e Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Feb 22 2009 19:54:53 +0000
Subject: [PATCH 242/3559] %define => %global


---

diff --git a/Packaging:OCaml.mw b/Packaging:OCaml.mw
index 8b778fe..a6cddf9 100644
--- a/Packaging:OCaml.mw
+++ b/Packaging:OCaml.mw
@@ -115,7 +115,7 @@ The OCaml native code compiler (ocamlopt) contains code generators for popular a
 To test for presence of the native compiler, do:
 
 
-%define opt %(test -x %{_bindir}/ocamlopt && echo 1 || echo 0)
+%global opt %(test -x %{_bindir}/ocamlopt && echo 1 || echo 0)
 

 
 then define conditional sections in %build, %install and %files if necessary.  For example:

From cf00c155ee81eb45bbc57d9d6e1aa687bb17fe73 Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Feb 22 2009 19:55:09 +0000
Subject: [PATCH 243/3559] %define => %global


---

diff --git a/Packaging:Debuginfo.mw b/Packaging:Debuginfo.mw
index d252dbd..8824157 100644
--- a/Packaging:Debuginfo.mw
+++ b/Packaging:Debuginfo.mw
@@ -32,7 +32,7 @@ Empty debuginfo packages may also be generated in situations where there are no 
 * Packages whose only architecture dependent binary part is a static library or many of them
 * R and Mono packages '''TODO: people knowledgeable of R and/or Mono, verify these'''
 
-If you wish to disable generation of the useless debuginfo package while waiting for improvements to find-debuginfo.sh or if it's unlikely that it could be enhanced to produce a good debuginfo for your package (for example no architecture dependent files, but package is not noarch because of the installation paths it uses), use %define debug_package %{nil}  in the specfile, and be sure to add a comment next to it explaining why it was done.
+If you wish to disable generation of the useless debuginfo package while waiting for improvements to find-debuginfo.sh or if it's unlikely that it could be enhanced to produce a good debuginfo for your package (for example no architecture dependent files, but package is not noarch because of the installation paths it uses), use %global debug_package %{nil}  in the specfile, and be sure to add a comment next to it explaining why it was done.
 
 == Missing debuginfo packages ==
 

From 233daa35a31b710542b3384c6b12dcf46e531c3a Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Feb 22 2009 19:56:02 +0000
Subject: [PATCH 244/3559] %define => %global


---

diff --git a/Packaging:OCaml.mw b/Packaging:OCaml.mw
index a6cddf9..d534e26 100644
--- a/Packaging:OCaml.mw
+++ b/Packaging:OCaml.mw
@@ -83,9 +83,9 @@ ocaml(runtime) = 3.10.0
 There are two scripts in the base ocaml package which automatically calculate the right Requires and Provides for a library.  To use them, just add the following to the spec file:
 
 
-%define _use_internal_dependency_generator 0
-%define __find_requires /usr/lib/rpm/ocaml-find-requires.sh
-%define __find_provides /usr/lib/rpm/ocaml-find-provides.sh
+%global _use_internal_dependency_generator 0
+%global __find_requires /usr/lib/rpm/ocaml-find-requires.sh
+%global __find_provides /usr/lib/rpm/ocaml-find-provides.sh
 

 
 Rationale:  OCaml does not offer binary compatibility between releases of the compiler (even between bugfixes).  Furthermore the module system uses a hash over the interface and some internals of a module which basically means a library or program must be linked against the identical modules it was compiled with.  The Requires and Provides lines express the module name and hash so that RPM enforces the same requirements as the OCaml linker itself.  Please see the further reading at the end of this page for more details.

From 97d4f1e5cc9acf42c4f6097b92618013273c22cc Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Feb 22 2009 19:56:16 +0000
Subject: [PATCH 245/3559] %define => %global


---

diff --git a/Packaging:EclipsePlugins.mw b/Packaging:EclipsePlugins.mw
index e1920b7..a1218a6 100644
--- a/Packaging:EclipsePlugins.mw
+++ b/Packaging:EclipsePlugins.mw
@@ -202,7 +202,7 @@ rm -rf $RPM_BUILD_ROOT
 == Tips and Notes ==
 
 === Common Defines ===
-%define eclipse_base %{_libdir}/eclipse.
+%global eclipse_base %{_libdir}/eclipse.
 
 === Requires ===
 Until rpmstubby (see below) is released and/or more widespread, Requires on bits provided by the Eclipse SDK (RCP, SWT, Platform, JDT, PDE, CVS, etc.) should only be on the binary package providing the required functionality (ex. eclipse-cvs-client or eclipse-rcp).  For IDE features, the most common requirement will be eclipse-platform.

From d40630a8fd65df249e5b86442a7e5c10d4f69285 Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Feb 22 2009 20:02:46 +0000
Subject: [PATCH 246/3559] %define => %global


---

diff --git a/Packaging:EclipsePlugins.mw b/Packaging:EclipsePlugins.mw
index a1218a6..656da55 100644
--- a/Packaging:EclipsePlugins.mw
+++ b/Packaging:EclipsePlugins.mw
@@ -134,7 +134,7 @@ See below for a tip on how to deal with the expanded JAR case.
 
 == Specfile Template ==
 
-%define eclipse_base        %{_libdir}/eclipse
+%global eclipse_base        %{_libdir}/eclipse
 
 Name:           eclipse-plugin
 Version:        1.0

From b029ff7b25e1655324adb1ade1b6c5117bb373d1 Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Feb 22 2009 20:03:18 +0000
Subject: [PATCH 247/3559] %define => %global


---

diff --git a/Packaging:SugarActivityGuidelines.mw b/Packaging:SugarActivityGuidelines.mw
index 896c2c4..2367d50 100644
--- a/Packaging:SugarActivityGuidelines.mw
+++ b/Packaging:SugarActivityGuidelines.mw
@@ -10,12 +10,12 @@ Sugar looks for its activities in two fixed locations, which are defined in suga
 
 Architecture Independent (noarch):
 
-%define sugaractivitydir /usr/share/sugar/activities/
+%global sugaractivitydir /usr/share/sugar/activities/
 

 
 Architecture Dependent:
 
-%define sugarlibdir %{_libdir}/sugar/activities
+%global sugarlibdir %{_libdir}/sugar/activities
 

 
 == Necessary BuildRequires ==

From 782e6026eb0d88bee7e756818acb1384f21e6a50 Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Feb 22 2009 20:04:02 +0000
Subject: [PATCH 248/3559] %define => %global


---

diff --git a/Packaging:Ruby.mw b/Packaging:Ruby.mw
index 824095b..9754366 100644
--- a/Packaging:Ruby.mw
+++ b/Packaging:Ruby.mw
@@ -25,12 +25,13 @@ Pure Ruby packages '''must''' be built as noarch packages.
 
 The Ruby library files in a pure Ruby package '''must''' be placed into Config::CONFIG["sitelibdir"] . The specfile '''must''' get that path using
 
-%{!?ruby_sitelib: %define ruby_sitelib %(ruby -rrbconfig -e 'puts Config::CONFIG["sitelibdir"] ')}
+%{!?ruby_sitelib: %global ruby_sitelib %(ruby -rrbconfig -e 'puts Config::CONFIG["sitelibdir"] ')}
 

 
 {{Template:Note}} For Fedora Core 3 and earlier releases, it is not possible to build noarch packages; for those releases, all Ruby packages '''must''' be architecture-specific, even if they only contain Ruby files. (See [https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=184199 bug 184199]  for details)
 
 {{Anchor|ruby_sitearch}}
+
 === Ruby packages with binary content/shared libraries ===
 
 For packages with binary content, e.g., database drivers or any other Ruby bindings to C libraries, the package '''must''' be architecture specific.

From 3373514ec7151ea57758f9e667dadfa654afaa61 Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Feb 22 2009 20:06:15 +0000
Subject: [PATCH 249/3559] %define => %global


---

diff --git a/Packaging:Ruby.mw b/Packaging:Ruby.mw
index 9754366..4fa6504 100644
--- a/Packaging:Ruby.mw
+++ b/Packaging:Ruby.mw
@@ -38,7 +38,7 @@ For packages with binary content, e.g., database drivers or any other Ruby bindi
 
 The binary files in a Ruby package with binary content '''must''' be placed into Config::CONFIG["sitearchdir"] . The Ruby files in such a package '''should''' be placed into that directory, too. The specfile '''must''' get that path using
 
-%{!?ruby_sitearch: %define ruby_sitearch %(ruby -rrbconfig -e 'puts Config::CONFIG["sitearchdir"] ')}
+%{!?ruby_sitearch: %global ruby_sitearch %(ruby -rrbconfig -e 'puts Config::CONFIG["sitearchdir"] ')}
 

 
 For packages which create C shared libraries using extconf.rb

From 3de6035f9928b66dd290419319a3aa8238a47bd7 Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Feb 22 2009 20:10:30 +0000
Subject: [PATCH 250/3559] %define => %global


---

diff --git a/Packaging:Ruby.mw b/Packaging:Ruby.mw
index 4fa6504..9de1369 100644
--- a/Packaging:Ruby.mw
+++ b/Packaging:Ruby.mw
@@ -61,7 +61,7 @@ Both RPM's and Gems use similar terminology --- there's specfiles, package names
 * The %prep and %build sections of the specfile '''should''' be empty.
 * The Gem '''must''' be installed into %{gemdir} defined as
 
-%define gemdir %(ruby -rubygems -e 'puts Gem::dir' 2>/dev/null)
+%global gemdir %(ruby -rubygems -e 'puts Gem::dir' 2>/dev/null)
 

 The install '''should''' be performed with the command
 

From 4cccc2d2e94f59a7d26b4d8a70f3bb95eb2deaad Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Feb 22 2009 20:10:59 +0000
Subject: [PATCH 251/3559] %define => %global


---

diff --git a/Packaging:Haskell.mw b/Packaging:Haskell.mw
index 86a2423..30c6a9d 100644
--- a/Packaging:Haskell.mw
+++ b/Packaging:Haskell.mw
@@ -58,7 +58,7 @@ rm -rf ${RPM_BUILD_ROOT}
 GHC libraries should be installed under libdir/ghc as done by Cabal.
 
 
-%define pkg_libdir %{_libdir}/ghc-%{ghc_version}/%{pkg_name}-%{version}
+%global pkg_libdir %{_libdir}/ghc-%{ghc_version}/%{pkg_name}-%{version}
 

 
 === File lists ===

From b346c24a4d4f102e53c8f28e3842400aa599741e Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Feb 22 2009 20:12:11 +0000
Subject: [PATCH 252/3559] %define => %global


---

diff --git a/Packaging:MinGW_Future.mw b/Packaging:MinGW_Future.mw
index a83a94c..2174afa 100644
--- a/Packaging:MinGW_Future.mw
+++ b/Packaging:MinGW_Future.mw
@@ -232,9 +232,9 @@ All packages should depend on mingw32-filesystem.
 Correct dependency generation is done automatically.  Packagers should
 include these lines in all library packages:
 
- %define _use_internal_dependency_generator 0
- %define __find_requires %{_mingw32_findrequires}
- %define __find_provides %{_mingw32_findprovides}
+ %global _use_internal_dependency_generator 0
+ %global __find_requires %{_mingw32_findrequires}
+ %global __find_provides %{_mingw32_findprovides}
 
 All specfiles should BuildRequire at least:
 
@@ -302,8 +302,8 @@ executables.
 Libraries and executables should be stripped.  This is done correctly
 and automatically if the spec file includes these lines:
 
- %define __strip %{_mingw32_strip}
- %define __objdump %{_mingw32_objdump}
+ %global __strip %{_mingw32_strip}
+ %global __objdump %{_mingw32_objdump}
 
 (Note that if __strip and __objdump are not overridden in the specfile
 then this can sometimes cause Windows binaries to be corrupted).

From a679061dacb611b54b2995a0df89bc4542b647d7 Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Feb 22 2009 20:13:59 +0000
Subject: [PATCH 253/3559] %define => %global


---

diff --git a/Packaging:Emacs_Old.mw b/Packaging:Emacs_Old.mw
index 04d7080..635ee7b 100644
--- a/Packaging:Emacs_Old.mw
+++ b/Packaging:Emacs_Old.mw
@@ -75,11 +75,11 @@ Usually an add-on package will require a startup file, and this should be called
 The following code snippet show how to use macros to determine these at package build time:
 
 %if %($(pkg-config emacs) ; echo $?)
-%define emacs_lispdir %{_datadir}/emacs/site-lisp
-%define emacs_startdir %{_datadir}/emacs/site-lisp/site-start.d
+%global emacs_lispdir %{_datadir}/emacs/site-lisp
+%global emacs_startdir %{_datadir}/emacs/site-lisp/site-start.d
 %else
-%define emacs_lispdir %(pkg-config emacs --variable sitepkglispdir)
-%define emacs_startdir %(pkg-config emacs --variable sitestartdir)
+%global emacs_lispdir %(pkg-config emacs --variable sitepkglispdir)
+%global emacs_startdir %(pkg-config emacs --variable sitestartdir)
 %endif
 ...
 BuildRequires: emacs-el
@@ -94,11 +94,11 @@ Usually an add-on package will require a startup file, and this should be called
 The following code snippet show how to use macros to determine these at package build time:
 
 %if %($(pkg-config xemacs) ; echo $?)
-%define xemacs_lispdir %{_datadir}/xemacs/site-packages
-%define xemacs_startdir %{_datadir}/xemacs/site-packages/site-start.d
+%global xemacs_lispdir %{_datadir}/xemacs/site-packages
+%global xemacs_startdir %{_datadir}/xemacs/site-packages/site-start.d
 %else
-%define xemacs_lispdir %(pkg-config xemacs --variable sitepkglispdir)
-%define xemacs_startdir %(pkg-config xemacs --variable sitestartdir)
+%global xemacs_lispdir %(pkg-config xemacs --variable sitepkglispdir)
+%global xemacs_startdir %(pkg-config xemacs --variable sitestartdir)
 %endif
 ...
 BuildRequires: xemacs-devel
@@ -143,9 +143,9 @@ It is recommended to derive greater-than-or-equal-to valued versioned dependenci
 For Emacs add-ons you will need to add BuildRequires: emacs-el and use the macro below
 
 %if %($(pkg-config emacs) ; echo $?)
-%define emacs_version 22.1
+%global emacs_version 22.1
 %else
-%define emacs_version %(pkg-config emacs --modversion)
+%global emacs_version %(pkg-config emacs --modversion)
 %endif
 ...
 Requires: emacs(bin) >= emacs_version
@@ -156,9 +156,9 @@ BuildRequires: emacs-el
 For Xemacs you will need to add BuildRequires: xemacs-devel and use the macro below
 
 %if %($(pkg-config xemacs) ; echo $?)
-%define xemacs_version 21.5
+%global xemacs_version 21.5
 %else
-%define xemacs_version %(pkg-config xemacs --modversion)
+%global xemacs_version %(pkg-config xemacs --modversion)
 %endif
 ...
 Requires: xemacs(bin) >= xemacs_version
@@ -196,27 +196,27 @@ For the Requires mentioned in 1-5 above, the exact %{version}-%{release} should 
 For convenience, there are two macros at the top of the file which you should customise to your package. You do not have to use the macros placed at the top of the file, but they help readability and make writing a spec file for a new package much quicker.
 
 
-%define pkg foo
-%define pkgname Foo
+%global pkg foo
+%global pkgname Foo
 
 %if %($(pkg-config emacs) ; echo $?)
-%define emacs_version 22.1
-%define emacs_lispdir %{_datadir}/emacs/site-lisp
-%define emacs_startdir %{_datadir}/emacs/site-lisp/site-start.d
+%global emacs_version 22.1
+%global emacs_lispdir %{_datadir}/emacs/site-lisp
+%global emacs_startdir %{_datadir}/emacs/site-lisp/site-start.d
 %else
-%define emacs_version %(pkg-config emacs --modversion)
-%define emacs_lispdir %(pkg-config emacs --variable sitepkglispdir)
-%define emacs_startdir %(pkg-config emacs --variable sitestartdir)
+%global emacs_version %(pkg-config emacs --modversion)
+%global emacs_lispdir %(pkg-config emacs --variable sitepkglispdir)
+%global emacs_startdir %(pkg-config emacs --variable sitestartdir)
 %endif
 
 %if %($(pkg-config xemacs) ; echo $?)
-%define xemacs_version 21.5
-%define xemacs_lispdir %{_datadir}/xemacs/site-packages
-%define xemacs_startdir %{_datadir}/xemacs/site-packages/site-start.d
+%global xemacs_version 21.5
+%global xemacs_lispdir %{_datadir}/xemacs/site-packages
+%global xemacs_startdir %{_datadir}/xemacs/site-packages/site-start.d
 %else
-%define xemacs_version %(pkg-config xemacs --modversion)
-%define xemacs_lispdir %(pkg-config xemacs --variable sitepkglispdir)
-%define xemacs_startdir %(pkg-config xemacs --variable sitestartdir)
+%global xemacs_version %(pkg-config xemacs --modversion)
+%global xemacs_lispdir %(pkg-config xemacs --variable sitepkglispdir)
+%global xemacs_startdir %(pkg-config xemacs --variable sitestartdir)
 %endif
 
 Name:           emacs-common-%{pkg}
@@ -341,17 +341,17 @@ rm -rf $RPM_BUILD_ROOT
 This is a template for a package for GNU Emacs only. The main package is called emacs-foo and contains all files needed to run package foo with GNU Emacs. There is a subpackage called emacs-foo-el which installs the elisp source files. emacs-foo owns the directory into which it is installed (/usr/share/emacs/site-lisp/foo), and so emacs-foo-el Requires emacs-foo with the matching version and release tag.
 
 
-%define pkg foo
-%define pkgname Foo
+%global pkg foo
+%global pkgname Foo
 
 %if %($(pkg-config emacs) ; echo $?)
-%define emacs_version 22.1
-%define emacs_lispdir %{_datadir}/emacs/site-lisp
-%define emacs_startdir %{_datadir}/emacs/site-lisp/site-start.d
+%global emacs_version 22.1
+%global emacs_lispdir %{_datadir}/emacs/site-lisp
+%global emacs_startdir %{_datadir}/emacs/site-lisp/site-start.d
 %else
-%define emacs_version %(pkg-config emacs --modversion)
-%define emacs_lispdir %(pkg-config emacs --variable sitepkglispdir)
-%define emacs_startdir %(pkg-config emacs --variable sitestartdir)
+%global emacs_version %(pkg-config emacs --modversion)
+%global emacs_lispdir %(pkg-config emacs --variable sitepkglispdir)
+%global emacs_startdir %(pkg-config emacs --variable sitestartdir)
 %endif
 
 Name:           emacs-%{pkg}

From fbc27e420ed8736657e40ecd902297471852d3f7 Mon Sep 17 00:00:00 2001
From: Laubersm 
Date: Feb 25 2009 02:21:46 +0000
Subject: [PATCH 254/3559] add [[Category:Packaging guidelines drafts]]


---

diff --git a/Packaging:Octave.mw b/Packaging:Octave.mw
index 6d237e4..bf82dd8 100644
--- a/Packaging:Octave.mw
+++ b/Packaging:Octave.mw
@@ -177,3 +177,5 @@ Octave maintains a list of installed packages in /usr/share/octave/octave_packag
 
 === Documentation files ===
 All package files are installed into the octave directories.  The COPYING and DESCRIPTION files are documentation and need to be marked as %doc.  The others are not.
+
+[[Category:Packaging guidelines drafts]]

From ce20207ad0be5b19d0c0971a3e8b2326f5c4f04b Mon Sep 17 00:00:00 2001
From: Tibbs 
Date: Mar 03 2009 18:48:23 +0000
Subject: [PATCH 255/3559] Really, actually remove the outdated redirect.


---

diff --git a/Packaging:FontsSpecTemplate.mw b/Packaging:FontsSpecTemplate.mw
index 742a9c0..8b13789 100644
--- a/Packaging:FontsSpecTemplate.mw
+++ b/Packaging:FontsSpecTemplate.mw
@@ -1 +1 @@
-#REDIRECT [[Fonts spec template (2007-10-01)]]
+

From cb743194008b2c7354b3f230d565e81ec56f4d79 Mon Sep 17 00:00:00 2001
From: Spot 
Date: Mar 03 2009 19:18:12 +0000
Subject: [PATCH 256/3559] *Empty MediaWiki Message*


---

diff --git a/Packaging:GuidelinesTodo.mw b/Packaging:GuidelinesTodo.mw
index 738ea30..3baa50f 100644
--- a/Packaging:GuidelinesTodo.mw
+++ b/Packaging:GuidelinesTodo.mw
@@ -13,19 +13,19 @@ Status should be one of:
 |-
 |ratify||Explicit Requires || spot || 2009-01-20 ||[[PackagingDrafts/ExplicitRequires]]
 |-
-|ratify||Updated Haskell Guidelines || spot || 2009-01-20 || [[PackagingDrafts/Haskell]]
+|writeup||Updated Haskell Guidelines || spot || 2009-01-20 || [[PackagingDrafts/Haskell]]
 |-
-|ratify||Symlinks ||spot ||2009-01-20 ||[[PackagingDrafts/Symlinks]]
+|writeup||Symlinks ||spot ||2009-01-20 ||[[PackagingDrafts/Symlinks]]
 |-
-|ratify||global preferred over define|| abadger1999 || 2009-02-17 || [[PackagingDrafts/global_preferred_over_define]]
+|writeup||global preferred over define|| abadger1999 || 2009-02-17 || [[PackagingDrafts/global_preferred_over_define]]
 |- 
-|ratify|| PHP channel || [[User:Remi]] || 2009-02-17 || [[PackagingDrafts/PHP]]
+|writeup|| PHP channel || [[User:Remi]] || 2009-02-17 || [[PackagingDrafts/PHP]]
 |-
-|ratify || Use of Epoch tag || spot || 2009-02-17 || [[PackagingDrafts/Epoch]]
+|writeup|| Use of Epoch tag || spot || 2009-02-17 || [[PackagingDrafts/Epoch]]
 |-
-|ratify || Icon Cache update || [[User:Toshio]] || 2009-02-17 || [[PackagingDrafts/Icon_Cache]]
+|writeup|| Icon Cache update || [[User:Toshio]] || 2009-02-17 || [[PackagingDrafts/Icon_Cache]]
 |-
-|ratify || Duplicate Files update || [[User:Toshio]] || 2009-02-17 || [[PackagingDrafts/Duplicate Files]]
+|writeup|| Duplicate Files update || [[User:Toshio]] || 2009-02-17 || [[PackagingDrafts/Duplicate Files]]
 |}
 
 {{:PackagingDrafts/DraftsTodo}}

From d727e30b4c8aa8bd23926bfc08a7fc1f21eabd3c Mon Sep 17 00:00:00 2001
From: Spot 
Date: Mar 03 2009 19:24:49 +0000
Subject: [PATCH 257/3559] /* Action Items */


---

diff --git a/Packaging:GuidelinesTodo.mw b/Packaging:GuidelinesTodo.mw
index 3baa50f..7dab801 100644
--- a/Packaging:GuidelinesTodo.mw
+++ b/Packaging:GuidelinesTodo.mw
@@ -11,7 +11,9 @@ Status should be one of:
 |- style="color: white; background-color: #3074c2; font-weight: bold" 
 |Status||Task Name||Owner||Meeting Date||Notes
 |-
-|ratify||Explicit Requires || spot || 2009-01-20 ||[[PackagingDrafts/ExplicitRequires]]
+|ratify||Explicit Requires || spot || 2009-03-02 ||[[PackagingDrafts/ExplicitRequires]]
+|-
+|ratify||Source URL Update||abadger1999|| 2009-03-02||[[Troublesome source URL packaging guideline draft]]. Section on dealing with URLs that can't go into the Source: line.
 |-
 |writeup||Updated Haskell Guidelines || spot || 2009-01-20 || [[PackagingDrafts/Haskell]]
 |-

From 4647170078a69d81bbfaeb78075b3f6975d55dc9 Mon Sep 17 00:00:00 2001
From: Spot 
Date: Mar 03 2009 19:26:31 +0000
Subject: [PATCH 258/3559] /* Resolved items */


---

diff --git a/Packaging:GuidelinesTodo.mw b/Packaging:GuidelinesTodo.mw
index 7dab801..e4dde6a 100644
--- a/Packaging:GuidelinesTodo.mw
+++ b/Packaging:GuidelinesTodo.mw
@@ -37,6 +37,8 @@ Status should be one of:
 |- style="color: white; background-color: #3074c2; font-weight: bold" 
 |Task Name||Owner||Resolution Date||Notes
 |-
+|FontSpecTemplate outside of Packaging||abadger1999|| 2009-03-02 ||[[Packaging:FontsSpecTemplate]] redirected to a page outside of Packaging. The redirect was dropped.
+|-
 |Update Desktop File Install Usage to Drop Vendor || spot || 2009-01-20 || [[TomCallaway/DesktopFileVendor]]
 |-
 |Font Packaging Naming Guidelines || [[Nicolas Mailhot]] || 2009-01-20 || [[PackagingDrafts/Font_package_naming_%282009-01-13%29]]

From 66c2f28dc77d80139b2ad0c7c0d310b0db5a418d Mon Sep 17 00:00:00 2001
From: Spot 
Date: Mar 04 2009 20:23:14 +0000
Subject: [PATCH 259/3559] /* Generating the search index.txt */


---

diff --git a/Packaging:R.mw b/Packaging:R.mw
index f36df89..7de0cd6 100644
--- a/Packaging:R.mw
+++ b/Packaging:R.mw
@@ -189,7 +189,7 @@ Instead of calling make install, to install the R addon components, you need to 
 Most R addon modules generate a new R.css file, but it would conflict with the master R.css file, included in the main R package. You must delete this file, and do not include it in your package.
 
 === Generating the search index.txt ===
-R keeps a master index.txt, as a search index of which R libraries are installed on the system. This provides the source for the R html help interface that is accessible through the ''help.start()'' command. This index is always located at %{_libdir}/R/doc/html/search/index.txt. All R packages need to update the search index.txt in %post and %postun. The R package provides a macro to make this simple: %{_R_make_search_index}. Simply put this macro in %post and %postun in your R package, and it will update the search index.txt to include arch-specific and noarch R libraries upon install and uninstall. This is demonstrated in the spec templates.
+R keeps a master index.txt, as a search index of which R libraries are installed on the system. This provides the source for the R html help interface that is accessible through the ''help.start()'' command. This index is always located at /usr/share/doc/R-%{version}/html/search/index.txt. All R packages need to update the search index.txt in %post and %postun. The R package provides a macro to make this simple: %{_R_make_search_index}. Simply put this macro in %post and %postun in your R package, and it will update the search index.txt to include arch-specific and noarch R libraries upon install and uninstall. This is demonstrated in the spec templates.
 
 NOTE: R packages will throw the following warning from rpmlint:
 

From cdcf139a10d229d4bdbe6c4614894f292c812fff Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Mar 07 2009 20:27:11 +0000
Subject: [PATCH 260/3559] Update for new rpm versions


---

diff --git a/Packaging:UnownedDirectories.mw b/Packaging:UnownedDirectories.mw
index b241fb1..86128de 100644
--- a/Packaging:UnownedDirectories.mw
+++ b/Packaging:UnownedDirectories.mw
@@ -12,7 +12,7 @@ Unowned directories can cause the following problems.
 
 === Inaccessible Directories ===
 
-A restrictive superuser umask during package installation can create inaccessible directories.  For instance, if the superuser does this:
+A restrictive superuser umask during package installation can create inaccessible directories when installed using the RPM Package Manager older than 4.4.2.3. Fedora 9 and RHEL 5.3 are the first to use RPM 4.4.2.3 which sets umask 0022 always.  On platforms with older versions of RPM if the superuser does this:
 
   umask 077
   yum update

From a305267910cffa4a305816d52a279ccfaa93d378 Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Mar 10 2009 21:17:37 +0000
Subject: [PATCH 261/3559] Update from approved new guidelines


---

diff --git a/Packaging:Scriptlets.mw b/Packaging:Scriptlets.mw
index cff0505..f1b2d1a 100644
--- a/Packaging:Scriptlets.mw
+++ b/Packaging:Scriptlets.mw
@@ -212,22 +212,22 @@ update-mime-database %{_datadir}/mime &> /dev/null || :
 Note that similarly to the gtk-update-icon-cache code, these scriptlets should be run only if the user has update-mime-info installed and without a specific Requires: shared-mime-info.  If shared-mime-info is not installed, update-mime-database won't be run when this package is installed.  This does not matter because it will be run when the shared-mime-info package is installed.
 
 {{Anchor|iconcache}}
-== GTK+ icon cache ==
+== Icon Cache ==
 
-If an application installs icons into one of the subdirectories in %{_datadir}/icons/ (such as hicolor in the following examples), gtk-update-icon-cache should be run after the package is installed/uninstalled on FC4 and later. This is required so that the installed icons show up in GNOME menus right after package installation, and speeds up GTK+ applications' access to the icons. For KDE, just 'touch'ing the top-level icon directory is enough.
+If an application installs icons into one of the subdirectories in %{_datadir}/icons/ (such as hicolor in the following examples), icon caches must be updated so that the installed icons show up in menus right after package installation.  This consists of updating the timestamp of the top-level icon directory where the icons were installed, and running gtk-update-icon-cache.  'touch'ing the top-level dir is done so that environments compatible with the [http://standards.freedesktop.org/icon-theme-spec/latest/ar01s08.html Icon theme specification] can refresh their caches, and gtk-update-icon-cache which is additionally required for GNOME also does its work based on the dir timestamp.
 
-Note that no dependencies should be added for this. If gtk-update-icon-cache is not available, there's nothing that would be needing the cache update. Not adding the dependency on gtk-update-icon-cache (ie. gtk2 >= 2.6.0) makes it easier to use the package (or the same specfile) on systems where it's not available nor needed, such as older distro versions or (very) trimmed down installations.
+Note that no dependencies should be added for this. If gtk-update-icon-cache is not available, there's nothing that would be needing the cache update, ditto if "touch" is not available, there's nothing that would benefit from icon cache updates installed yet either. Not adding the dependency on gtk-update-icon-cache (ie. gtk2 >= 2.6.0) or "touch" makes it easier to use the package (or the same specfile) on systems where it's not available nor needed, such as older distro versions or (very) trimmed down installations, and generally results in less entries in specfiles, rpmdb, and repo metadatas.
 
 
 %post
-touch --no-create %{_datadir}/icons/hicolor
-if [ -x %{_bindir}/gtk-update-icon-cache ] ; then
-  %{_bindir}/gtk-update-icon-cache --quiet %{_datadir}/icons/hicolor || :
-fi
+touch --no-create %{_datadir}/icons/hicolor &>/dev/null || :
 
 %postun
-touch --no-create %{_datadir}/icons/hicolor
-if [ -x %{_bindir}/gtk-update-icon-cache ] ; then
-  %{_bindir}/gtk-update-icon-cache --quiet %{_datadir}/icons/hicolor || :
+if [ $1 -eq 0 ] ; then
+    touch --no-create %{_datadir}/icons/hicolor &>/dev/null
+    gtk-update-icon-cache %{_datadir}/icons/hicolor &>/dev/null || :
 fi
+
+%posttrans
+gtk-update-icon-cache %{_datadir}/icons/hicolor &>/dev/null || :
 


From 11866dccb14f08e701416422a7a49f00f28769b0 Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Mar 10 2009 21:28:35 +0000
Subject: [PATCH 262/3559] duplicate files update


---

diff --git a/Packaging:ReviewGuidelines.mw b/Packaging:ReviewGuidelines.mw
index 64a4054..9d9eb23 100644
--- a/Packaging:ReviewGuidelines.mw
+++ b/Packaging:ReviewGuidelines.mw
@@ -36,7 +36,7 @@ There are many many things to check for a review. This list is provided to assis
 * '''MUST''': Every binary RPM package (or subpackage) which stores shared library files (not just symlinks) in any of the dynamic linker's default paths, must call ldconfig in %post and %postun. [[Packaging/Guidelines#Shared_Libraries|Packaging Guidelines: Shared Libraries]]

 * '''MUST''': If the package is designed to be relocatable, the packager must state this fact in the request for review, along with the rationalization for relocation of that specific package. Without this, use of Prefix: /usr is considered a blocker. [[Packaging/Guidelines#RelocatablePackages|Packaging Guidelines: Relocatable Packages]]

 * '''MUST''': A package must own all directories that it creates. If it does not create a directory that it uses, then it should require a package which does create that directory.  [[Packaging/Guidelines#FileAndDirectoryOwnership|Packaging Guidelines: File And Directory Ownership]]

-* '''MUST''': A package must not contain any duplicate files in the %files listing. [[Packaging/Guidelines#DuplicateFiles|Packaging Guidelines: Duplicate Files]]

+* '''MUST''': A Fedora package must not list a file more than once in the spec file's %files listings. [[Packaging/Guidelines#DuplicateFiles|Packaging Guidelines: Duplicate Files]]

 * '''MUST''': Permissions on files must be set properly. Executables should be set with executable permissions, for example. Every %files section must include a %defattr(...) line. [[Packaging/Guidelines#FilePermissions|Packaging Guidelines: File Permissions]]

 * '''MUST''': Each package must have a %clean section, which contains rm -rf %{buildroot} ([[Packaging/Guidelines#UsingBuildRootOptFlags|or $RPM_BUILD_ROOT]]). [[Packaging/Guidelines#clean|Packaging Guidelines: %clean]]

 * '''MUST''': Each package must consistently use macros. [[Packaging/Guidelines#macros|Packaging Guidelines: Macros]]


From 57fec2dbed9ed8abc422848254ada7ced3ada834 Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Mar 10 2009 21:29:39 +0000
Subject: [PATCH 263/3559] New Duplicate File wording


---

diff --git a/Packaging:Guidelines.mw b/Packaging:Guidelines.mw
index b8f72f5..d1252ff 100644
--- a/Packaging:Guidelines.mw
+++ b/Packaging:Guidelines.mw
@@ -823,9 +823,10 @@ In all cases we are guarding against unowned directories being present on a syst
 
 {{Anchor|DuplicateFiles}}
 === Duplicate Files ===
-A Fedora package must not contain any duplicate files in the %files listing.
+A Fedora package must not list a file more than once in the spec file's %files listings.  If you think your package is a valid exception to this, please bring it to the attention of the Packaging Committee so they can improve on this Guideline.
 
 {{Anchor|FilePermissions}}
+
 === File Permissions ===
 Permissions on files must be set properly. Executables should be set with executable permissions, for example. Every %files section must include a %defattr(...) line. Here is a good default:
 

From 5e610678785816526d29acc2c8ff170f04f7ec51 Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Mar 19 2009 17:32:42 +0000
Subject: [PATCH 264/3559] Fix typo


---

diff --git a/Packaging:Scriptlets.mw b/Packaging:Scriptlets.mw
index f1b2d1a..75516e3 100644
--- a/Packaging:Scriptlets.mw
+++ b/Packaging:Scriptlets.mw
@@ -125,7 +125,7 @@ The next section is for installing the new schema:
 %post
 export GCONF_CONFIG_SOURCE=gconftool-2 --get-default-source
 gconftool-2 --makefile-install-rule \
-%{_sysconfdir}/gconf/schemas/[NAME] .schemas > /dev/null ||| :
+%{_sysconfdir}/gconf/schemas/[NAME] .schemas > /dev/null || :
 

 Here we do the same things as in the %pre section for upgrading except the gconftool-2 switch used is --makefile-install-rule to install the new schemas instead of the uninstall-rule to remove the old schemas.
 
@@ -143,6 +143,7 @@ This snippet is nearly the same as the one for upgrading.  Why can't we just com
 '''Note:''' RHEL4 and FC <= 4 suffer from GConf [https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173869 Bug #173869] .  If you are building for EPEL-4, you need to add  killall -HUP gconfd-2 > /dev/null || :  after the gconftool-2 calls in all the scriptlets.
 
 {{Anchor|info}}
+
 == Texinfo ==
 The GNU project and many other programs use the texinfo file format for much of its documentation. These info files are usually located in /usr/share/info/.
 When installing or removing a package, install-info from the info package takes care of adding the newly installed files to the main info index and removing them again on deinstallation.

From 2f669f7f39a2b55c756c7375e2569846db99db56 Mon Sep 17 00:00:00 2001
From: Ianweller 
Date: Mar 21 2009 03:26:36 +0000
Subject: [PATCH 265/3559] create page


---

diff --git a/Packaging:WordPress_plugin_packaging_guidelines.mw b/Packaging:WordPress_plugin_packaging_guidelines.mw
new file mode 100644
index 0000000..c577bde
--- /dev/null
+++ b/Packaging:WordPress_plugin_packaging_guidelines.mw
@@ -0,0 +1,96 @@
+[http://wordpress.org/extend/plugins/ WordPress plugins] are packaged for Fedora so that the plugin can be used for both {{package|wordpress}} and {{package|wordpress-mu}} without requiring both.
+
+== Requirements for packaging ==
+* Use the [[#Specfile template|specfile template]]
+* Set plugin_name and plugin_human_name by appending the first two lines appropriately
+** plugin_name is the short name used in the URL for the plugin's page on wordpress.org
+** plugin_human_name is the full name of the plugin as displayed on the plugin's page on wordpress.org
+* Fill in the version of the package as it is displayed in the .zip filename
+* Fill in a package description in both places where it says "Your plugin's description goes here."
+
+== Notes ==
+* The spec must be named wordpress-plugin-%{plugin_name}.spec as per the [[Packaging:NamingGuidelines|naming guidelines]]
+* Remember to enter a changelog entry
+
+== Specfile template ==
+
+%global plugin_name
+%global plugin_human_name
+
+Name:		wordpress-plugin-%{plugin_name}
+Version:	
+Release:	1%{?dist}
+Summary:	%{plugin_human_name} plugin for WordPress
+
+Group:		Applications/Publishing
+# According to http://plugins.trac.wordpress.org/ all plugins are licensed
+# under the GPL unless otherwise stated in the plugin source.
+License:	GPLv3+
+URL:		http://wordpress.org/extend/plugins/%{plugin_name}/
+Source0:	http://downloads.wordpress.org/plugin/%{plugin_name}.%{version}.zip
+BuildRoot:	%(mktemp -ud %{_tmppath}/%{name}-%{version}-%{release}-XXXXXX)
+Requires:	wordpress
+BuildArch:	noarch
+
+%description
+Your plugin's description goes here.
+
+This package is built for use with WordPress (wordpress), not WordPress MU. Use
+wordpress-mu-plugin-%{plugin_name} for WordPress MU.
+
+
+%package -n wordpress-mu-plugin-%{plugin_name}
+Summary:	%{plugin_human_name} plugin for WordPress MU
+Group:		Applications/Publishing
+# According to http://plugins.trac.wordpress.org/ all plugins are licensed
+# under the GPL unless otherwise stated in the plugin source.
+License:	GPLv3+
+Requires:	wordpress-mu
+BuildArch:	noarch
+
+%description -n wordpress-mu-plugin-%{plugin_name}
+Your plugin's description goes here.
+
+This package is built for use with WordPress MU (wordpress-mu), not regular
+WordPress. Use wordpress-plugin-%{plugin_name} for regular Wordpress.
+
+
+%prep
+%setup -q -c
+echo 'To enable "%{plugin_human_name}", go to the administrative section
+of your blog, "Plugins", and enable the plugin there.' > README.fedora
+echo 'To allow users to enable "%{plugin_human_name}" for their blogs,
+be sure to enable this plugin in the administrative control panel
+for your website.' > README.fedora.mu
+
+
+%build
+
+
+%install
+rm -rf %{buildroot}
+mkdir -p %{buildroot}%{_datadir}/wordpress/wp-content/plugins/
+cp -a %{plugin_name} %{buildroot}%{_datadir}/wordpress/wp-content/plugins/
+mkdir -p %{buildroot}%{_datadir}/wordpress-mu/wp-content/plugins/
+cp -a %{plugin_name} %{buildroot}%{_datadir}/wordpress-mu/wp-content/plugins/
+
+
+%clean
+rm -rf %{buildroot}
+
+
+%files
+%defattr(-,root,root,-)
+%doc README.fedora
+%{_datadir}/wordpress/wp-content/plugins/%{plugin_name}
+
+
+%files -n wordpress-mu-plugin-%{plugin_name}
+%defattr(-,root,root,-)
+%doc README.fedora.mu
+%{_datadir}/wordpress-mu/wp-content/plugins/%{plugin_name}
+
+
+%changelog
+
+


From 65f0a7ecdd40aaaae706fa5c455eea4d8a16da66 Mon Sep 17 00:00:00 2001
From: Ianweller 
Date: Mar 21 2009 03:30:22 +0000
Subject: [PATCH 266/3559] /* Requirements for packaging */ add example for defining the two variables


---

diff --git a/Packaging:WordPress_plugin_packaging_guidelines.mw b/Packaging:WordPress_plugin_packaging_guidelines.mw
index c577bde..90765aa 100644
--- a/Packaging:WordPress_plugin_packaging_guidelines.mw
+++ b/Packaging:WordPress_plugin_packaging_guidelines.mw
@@ -8,6 +8,14 @@
 * Fill in the version of the package as it is displayed in the .zip filename
 * Fill in a package description in both places where it says "Your plugin's description goes here."
 
+=== Example ===
+http://wordpress.org/extend/plugins/stats/
+
+
+%global plugin_name stats
+%global plugin_human_name WordPress.com Stats
+

+
 == Notes ==
 * The spec must be named wordpress-plugin-%{plugin_name}.spec as per the [[Packaging:NamingGuidelines|naming guidelines]]
 * Remember to enter a changelog entry

From 1b6b7ae329807116c6ffd6908a2d7cf34f3ae92b Mon Sep 17 00:00:00 2001
From: Ianweller 
Date: Mar 21 2009 03:31:37 +0000
Subject: [PATCH 267/3559] +cat


---

diff --git a/Packaging:WordPress_plugin_packaging_guidelines.mw b/Packaging:WordPress_plugin_packaging_guidelines.mw
index 90765aa..6af521d 100644
--- a/Packaging:WordPress_plugin_packaging_guidelines.mw
+++ b/Packaging:WordPress_plugin_packaging_guidelines.mw
@@ -102,3 +102,5 @@ rm -rf %{buildroot}
 %changelog
 
 

+
+[[Category:Packaging guidelines draft|WordPress]]

From b33738530d078ed2014a83c0309a045493c8511b Mon Sep 17 00:00:00 2001
From: Ianweller 
Date: Mar 21 2009 03:34:08 +0000
Subject: [PATCH 268/3559] fix cat


---

diff --git a/Packaging:WordPress_plugin_packaging_guidelines.mw b/Packaging:WordPress_plugin_packaging_guidelines.mw
index 6af521d..e765d57 100644
--- a/Packaging:WordPress_plugin_packaging_guidelines.mw
+++ b/Packaging:WordPress_plugin_packaging_guidelines.mw
@@ -103,4 +103,4 @@ rm -rf %{buildroot}
 
 

 
-[[Category:Packaging guidelines draft|WordPress]]
+[[Category:Packaging guidelines drafts|WordPress]]

From e721bc999ae3756478aa2325cd6700beab178981 Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Mar 30 2009 15:15:53 +0000
Subject: [PATCH 269/3559] WikiName => Namespace


---

diff --git a/Packaging:Guidelines.mw b/Packaging:Guidelines.mw
index d1252ff..9fb1dd7 100644
--- a/Packaging:Guidelines.mw
+++ b/Packaging:Guidelines.mw
@@ -14,7 +14,7 @@ Please remember that any package that you submit must also conform to the [[Pack
 {{Anchor|Naming}}
 == Naming ==
 
-You should go through the [[Packaging/NamingGuidelines]]  to ensure that your package is named appropriately.
+You should go through the [[Packaging:NamingGuidelines]]  to ensure that your package is named appropriately.
 
 == Version and Release ==
 

From bdd50c0738d249c8366cff798346507c5343f140 Mon Sep 17 00:00:00 2001
From: Spot 
Date: Mar 31 2009 19:30:28 +0000
Subject: [PATCH 270/3559] /* Action Items */


---

diff --git a/Packaging:GuidelinesTodo.mw b/Packaging:GuidelinesTodo.mw
index e4dde6a..799507d 100644
--- a/Packaging:GuidelinesTodo.mw
+++ b/Packaging:GuidelinesTodo.mw
@@ -11,6 +11,10 @@ Status should be one of:
 |- style="color: white; background-color: #3074c2; font-weight: bold" 
 |Status||Task Name||Owner||Meeting Date||Notes
 |-
+|ratify||Embedded Desktop Files || spot || 2009-03-31 || [[PackagingDrafts/EmbeddedDesktopFiles]]
+|-
+|ratify||Documentation Naming || spot || 2009-03-31 || [[PackagingDrafts/DocumentationNaming]]
+|-
 |ratify||Explicit Requires || spot || 2009-03-02 ||[[PackagingDrafts/ExplicitRequires]]
 |-
 |ratify||Source URL Update||abadger1999|| 2009-03-02||[[Troublesome source URL packaging guideline draft]]. Section on dealing with URLs that can't go into the Source: line.

From 8d317a90567b7983103527dd4a3dd7366b99eeea Mon Sep 17 00:00:00 2001
From: Ianweller 
Date: Apr 03 2009 01:38:20 +0000
Subject: [PATCH 271/3559] incompatibilities


---

diff --git a/Packaging:WordPress_plugin_packaging_guidelines.mw b/Packaging:WordPress_plugin_packaging_guidelines.mw
index e765d57..08ddbc2 100644
--- a/Packaging:WordPress_plugin_packaging_guidelines.mw
+++ b/Packaging:WordPress_plugin_packaging_guidelines.mw
@@ -21,6 +21,8 @@ http://wordpress.org/extend/plugins/stats/
 * Remember to enter a changelog entry
 
 == Specfile template ==
+{{admon/warning|Non-compatible plugins|If a plugin is not compatible with both WordPress and WordPress MU, create a package for only one or the other that matches the following for that plugin.}}
+
 
 %global plugin_name
 %global plugin_human_name

From 443b8d029f78665eb1ecf1039fba33e66ac4a197 Mon Sep 17 00:00:00 2001
From: Tibbs 
Date: Apr 07 2009 16:24:08 +0000
Subject: [PATCH 272/3559] FESCo ratified two proposals at its meeting on 2009-04-03


---

diff --git a/Packaging:GuidelinesTodo.mw b/Packaging:GuidelinesTodo.mw
index 799507d..0bb3225 100644
--- a/Packaging:GuidelinesTodo.mw
+++ b/Packaging:GuidelinesTodo.mw
@@ -11,9 +11,9 @@ Status should be one of:
 |- style="color: white; background-color: #3074c2; font-weight: bold" 
 |Status||Task Name||Owner||Meeting Date||Notes
 |-
-|ratify||Embedded Desktop Files || spot || 2009-03-31 || [[PackagingDrafts/EmbeddedDesktopFiles]]
+|writeup||Embedded Desktop Files || spot || 2009-03-31 || [[PackagingDrafts/EmbeddedDesktopFiles]]
 |-
-|ratify||Documentation Naming || spot || 2009-03-31 || [[PackagingDrafts/DocumentationNaming]]
+|writeup||Documentation Naming || spot || 2009-03-31 || [[PackagingDrafts/DocumentationNaming]]
 |-
 |ratify||Explicit Requires || spot || 2009-03-02 ||[[PackagingDrafts/ExplicitRequires]]
 |-

From 7c0504356072a93d7afe514e919103c3c2166940 Mon Sep 17 00:00:00 2001
From: Spot 
Date: Apr 08 2009 14:24:02 +0000
Subject: [PATCH 273/3559] cleanups from moinmoin era


---

diff --git a/Packaging:Guidelines.mw b/Packaging:Guidelines.mw
index 9fb1dd7..d4cdcff 100644
--- a/Packaging:Guidelines.mw
+++ b/Packaging:Guidelines.mw
@@ -449,7 +449,7 @@ Packages which explicitly need to link against the static version must Bui
 ==== Programs which don't need to notify FESCo ====
 * Programs written in OCaml do not normally link dynamically to OCaml libraries.  Because of that this requirement is waived.  (OCaml code that calls out to libraries written in C should still link dynamically to the C libraries, however.)
 
-* If a library you depend on '''only''' provides a static version your package can link against it provided that you Build''''''Require the ''*-static'' subpackage. Packagers in such a situation should be aware that if a shared library becomes available, that you should adjust your package to use the shared library.
+* If a library you depend on '''only''' provides a static version your package can link against it provided that you BuildRequire the ''*-static'' subpackage. Packagers in such a situation should be aware that if a shared library becomes available, that you should adjust your package to use the shared library.
 
 {{Anchor|SystemLibraryDuplication}}
 == Duplication of system libraries ==
@@ -585,14 +585,16 @@ rpm -q --specfile foo.spec --qf "$(grep -i ^Source foo.spec)\n"
 
 {{Anchor|UsingBuildRootOptFlags}}
 === Using %{buildroot} and %{optflags} vs $RPM_BUILD_ROOT and $RPM_OPT_FLAGS ===
-There are two styles of defining the rpm Build Root and Optimization Flags in a spec file.
+There are two styles of defining the rpm Build Root and Optimization Flags in a spec file:
 
-
-macro style   variable style
-Build Root  %{buildroot}  $RPM_BUILD_ROOT
-Opt. Flags  %{optflags}   $RPM_OPT_FLAGS
-
-

+{| border="1"
+|-
+| ||macro style ||  variable style
+|-
+|Build Root||%{buildroot}||$RPM_BUILD_ROOT
+|-
+|Opt. Flags||%{optflags}||$RPM_OPT_FLAGS
+|}
 
 There is very little value in choosing one style over the other, since they will resolve to the same values in all scenarios. You should pick a style and use it consistently throughout your packaging.
 

From 5c8063b46bd310fb82b3754ba4d90800bd40ed26 Mon Sep 17 00:00:00 2001
From: Spot 
Date: Apr 14 2009 14:45:05 +0000
Subject: [PATCH 274/3559] 0.99: epochs, symlinks, explicit requires, fix desktop file first sentence, %global


---

diff --git a/Packaging:Guidelines.mw b/Packaging:Guidelines.mw
index d4cdcff..43f2ad1 100644
--- a/Packaging:Guidelines.mw
+++ b/Packaging:Guidelines.mw
@@ -7,9 +7,9 @@ It is the reviewer's responsibility to point out specific problems with a packag
 Please remember that any package that you submit must also conform to the [[Packaging/ReviewGuidelines|  Review Guidelines]] .
 
 '''Author:''' [[TomCallaway|  Tom 'spot' Callaway]]  (based on many other documents)

-'''Revision:''' 0.98

+'''Revision:''' 0.99

 '''Initial Draft:''' Wednesday Feb 23, 2005

-'''Last Revised:''' Tuesday Jan 20, 2009

+'''Last Revised:''' Tuesday Apr 14, 2009

 
 {{Anchor|Naming}}
 == Naming ==
@@ -229,6 +229,33 @@ Packages should not use the PreReq tag. Once upon a time, in dependency loops Pr
 
 Rpm gives you the ability to depend on files instead of packages.  Whenever possible you should avoid file dependencies outside of /etc, /bin, /sbin, /usr/bin, or /usr/sbin.  Using file dependencies outside of those directories requires yum (and other depsolvers using the repomd format) to download and parse a large xml file looking for the dependency. Helping the depsolvers avoid this processing by depending on the package instead of the file saves our end users a lot of time. There are times when other technical considerations outweigh these considerations. One specific example is packages installing into %{_libdir}/mozilla/plugins. In this case, mandating a specific browser in your package just to own this directory could drag in a large amount of needless packages. Requiring the directory to resolve the dependency is the better choice.
 
+{{Anchor|ExplicitRequires}}
+=== Explicit Requires ===
+Packages must not contain explicit ''Requires'' on libraries except when absolutely 
+necessary. When explicit library ''Requires'' are necessary, there should be a spec file comment justifying it.
+
+We generally rely on rpmbuild to automatically add dependencies on library SONAMEs. 
+Modern package management tools are capable of resolving such dependencies to determine 
+the required packages. Explicit dependencies on specific package names may aid the 
+inexperienced user, who attempts at installing RPM packages manually, however, history 
+has shown that such dependencies add confusion when library/files are moved from one 
+package to another, when packages get renamed, when one out of multiple alternative 
+packages would suffice, and when versioned explicit dependencies become out-of-date and 
+inaccurate. Additionally, in some cases, old explicit dependencies on package names 
+require unnecessary updates/rebuilds. For example, Fedora packages are only required 
+to retain historical provides for two full release cycles.
+
+Exemplary rationale for a versioned explicit dependency:
+
+  # The automatic dependency on libfubar.so.1 is insufficient,
+  # as we strictly need at least the release that fixes two segfaults.
+  Requires: libfubar >= 0:1.2.3-7
+

+
+Packagers should revisit an explicit dependency as appropriate to avoid 
+it becoming inaccurate and superfluous.  For instance in the example above, when no current Fedora release shipped with libfubar < 1.2.3-7, it is no longer necessary to list the explicit, versioned requirement.
+
+
 {{Anchor|BuildRequires}}
 == BuildRequires ==
 
@@ -533,7 +560,7 @@ The icon tag can be specified in two ways:
 The short name without file extension is preferred, because it allows for icon theming (it assumes .png by default, then tries .svg and finally .xpm), but either method is acceptable.
 
 === .desktop file creation ===
-If the package doesn't already include and install its own .desktop file, you need to make your own, and include it as a Source: (e.g. Source3: %{name}.desktop).  Here are the contents of a sample .desktop file (comical.desktop):
+If the package doesn't already include and install its own .desktop file, you need to make your own. You can do this by including a .desktop file you create as a Source: (e.g. Source3: %{name}.desktop) or generating it in the spec file. Here are the contents of a sample .desktop file (comical.desktop): 
 
 
 [Desktop Entry]
@@ -610,6 +637,16 @@ Fedora's RPM includes a %makeinstall macro but it must '''NOT''' be
 
 Instead, Fedora packages should use: make DESTDIR=%{buildroot} install or make DESTDIR=$RPM_BUILD_ROOT install
 
+== %global preferred over %define ==
+
+Use %global instead of %define, unless you really need only locally defined submacros within other macro definitions (a very rare case).
+
+Rationale: The two macro defining statements behave the same when they are a the top level of rpm's nesting level.
+
+But when they are used in nested macro expansions (like in  %{!?foo: ... }  constructs, %define theoretically only lasts until the end brace (local scope), while %global definitions have global scope.
+
+The reason this hasn't bitten us as often is that due to a minor bug in rpm the invalidated local macro definition is not garbage collected unless other events force rpm to. So the bug is seldomly triggered, but when it is, it is difficult to diagnose the issue. Using %global by default helps to avoid creation of new latent bugs.
+
 {{Anchor|locales}}
 == Handling Locale Files ==
 
@@ -828,7 +865,6 @@ In all cases we are guarding against unowned directories being present on a syst
 A Fedora package must not list a file more than once in the spec file's %files listings.  If you think your package is a valid exception to this, please bring it to the attention of the Packaging Committee so they can improve on this Guideline.
 
 {{Anchor|FilePermissions}}
-
 === File Permissions ===
 Permissions on files must be set properly. Executables should be set with executable permissions, for example. Every %files section must include a %defattr(...) line. Here is a good default:
 
@@ -926,6 +962,45 @@ It may be that some patches truly are Fedora-specific; in that case, say so:
 Patch0: jna-jni-path.patch
 

 
+{{Anchor|Epochs}}
+== Use of Epochs ==
+The Epoch tag in RPM is to be used only as a last resort, and should be avoided whenever possible. However, it is sometimes necessary to use an Epoch to handle upstream versioning changes or to ease transition from third party repositories. 
+
+=== Epochs from Third Party Repositories ===
+If a package to be imported is or previously was present in a publicly accessible repository, the packager can optionally include an Epoch tag equal to that of the most recent version of the third-party package.
+
+== Symlinks ==
+There are two ways of making a symlink, either as a relative link or an absolute link. In Fedora, neither method is required. Packagers should use their best judgement when deciding which method of symlink creation is appropriate.
+
+=== Relative Symlinks ===
+A relative symlink is a symlink which points to a file or directory relative to the position of the symlink. For example, this command would create a relative symlink:
+
+ln -s ../..%{_bindir}/foo %{buildroot}/bin/foo
+

+
+Pros:
+* Relative symlinks will point to the same file inside or outside of a chroot.
+
+Cons:
+* Much more complicated to create than absolute symlinks
+* Relative symlinks may break or behave unexpectedly when a part of a filesystem is mounted to a custom location.
+* Relative symlinks may break when bind mounting or symlinking directories.
+* Relative symlinks may make it more difficult to use rpm system macros.
+
+=== Absolute Symlinks ===
+An absolute symlink is a symlink which points to an absolute file or directory path. For example, this command would create an absolute symlink:
+
+ln -s %{_bindir}/foo %{buildroot}/bin/foo
+

+
+Pros:
+* Much easier to create than relative symlinks.
+* Absolute symlinks work properly when bind mounting or symlinking directories.
+* Absolute symlinks work well with rpm system macros.
+
+Cons:
+* Absolute symlinks may break when used with chroots.
+
 {{Anchor|ApplicationSpecificGuidelines}}
 == Application Specific Guidelines ==
 

From 60a83bda9e70d7c0409d17c3adce5d3bf2af0ed1 Mon Sep 17 00:00:00 2001
From: Spot 
Date: Apr 14 2009 14:48:14 +0000
Subject: [PATCH 275/3559] *Empty MediaWiki Message*


---

diff --git a/Packaging:GuidelinesTodo.mw b/Packaging:GuidelinesTodo.mw
index 0bb3225..6f32907 100644
--- a/Packaging:GuidelinesTodo.mw
+++ b/Packaging:GuidelinesTodo.mw
@@ -11,27 +11,15 @@ Status should be one of:
 |- style="color: white; background-color: #3074c2; font-weight: bold" 
 |Status||Task Name||Owner||Meeting Date||Notes
 |-
-|writeup||Embedded Desktop Files || spot || 2009-03-31 || [[PackagingDrafts/EmbeddedDesktopFiles]]
-|-
 |writeup||Documentation Naming || spot || 2009-03-31 || [[PackagingDrafts/DocumentationNaming]]
 |-
-|ratify||Explicit Requires || spot || 2009-03-02 ||[[PackagingDrafts/ExplicitRequires]]
-|-
-|ratify||Source URL Update||abadger1999|| 2009-03-02||[[Troublesome source URL packaging guideline draft]]. Section on dealing with URLs that can't go into the Source: line.
+|writeup||Source URL Update||abadger1999|| 2009-03-02||[[Troublesome source URL packaging guideline draft]]. Section on dealing with URLs that can't go into the Source: line.
 |-
 |writeup||Updated Haskell Guidelines || spot || 2009-01-20 || [[PackagingDrafts/Haskell]]
 |-
-|writeup||Symlinks ||spot ||2009-01-20 ||[[PackagingDrafts/Symlinks]]
-|-
-|writeup||global preferred over define|| abadger1999 || 2009-02-17 || [[PackagingDrafts/global_preferred_over_define]]
-|- 
 |writeup|| PHP channel || [[User:Remi]] || 2009-02-17 || [[PackagingDrafts/PHP]]
 |-
-|writeup|| Use of Epoch tag || spot || 2009-02-17 || [[PackagingDrafts/Epoch]]
-|-
 |writeup|| Icon Cache update || [[User:Toshio]] || 2009-02-17 || [[PackagingDrafts/Icon_Cache]]
-|-
-|writeup|| Duplicate Files update || [[User:Toshio]] || 2009-02-17 || [[PackagingDrafts/Duplicate Files]]
 |}
 
 {{:PackagingDrafts/DraftsTodo}}
@@ -41,6 +29,18 @@ Status should be one of:
 |- style="color: white; background-color: #3074c2; font-weight: bold" 
 |Task Name||Owner||Resolution Date||Notes
 |-
+|Embedded Desktop Files || spot || 2009-04-14 || [[PackagingDrafts/EmbeddedDesktopFiles]]
+|-
+|Explicit Requires || spot || 2009-04-14 ||[[PackagingDrafts/ExplicitRequires]]
+|-
+|Symlinks ||spot ||2009-04-14 ||[[PackagingDrafts/Symlinks]]
+|-
+|global preferred over define|| abadger1999 || 2009-04-14 || [[PackagingDrafts/global_preferred_over_define]]
+|- 
+|Use of Epoch tag || spot || 2009-04-14 || [[PackagingDrafts/Epoch]]
+|-
+|Duplicate Files update || [[User:Toshio]] || 2009-04-14 || [[PackagingDrafts/Duplicate Files]]
+|-
 |FontSpecTemplate outside of Packaging||abadger1999|| 2009-03-02 ||[[Packaging:FontsSpecTemplate]] redirected to a page outside of Packaging. The redirect was dropped.
 |-
 |Update Desktop File Install Usage to Drop Vendor || spot || 2009-01-20 || [[TomCallaway/DesktopFileVendor]]

From c992ed626c757fa63d337cbfd0d712844acdfc5b Mon Sep 17 00:00:00 2001
From: Spot 
Date: Apr 14 2009 14:50:07 +0000
Subject: [PATCH 276/3559] *Empty MediaWiki Message*


---

diff --git a/Packaging:SourceURL.mw b/Packaging:SourceURL.mw
index 3abbf54..927bbdc 100644
--- a/Packaging:SourceURL.mw
+++ b/Packaging:SourceURL.mw
@@ -87,5 +87,13 @@ changing ".tar.gz" to whatever matches the upstream distribution.  Note that we 
 == Using %{version} ==
 
 Using %{version} in the SourceX: makes it easier for you to bump the version of a package, because most of the time you do not need to edit SourceX: when editing the specfile for the new package.
+
+== Troublesome URLs ==
+When upstream has URLs for the download that do not end with the tarball name rpm will be unable to parse the tarball out of the source URL.  In these cases, you have to put just the tarball's filename into the Source: field.  To make clear where you got the tarball, you should leave notes in comments above the Source: line to explain the situation to reviewers and future packagers.  Example:
+
+  # Mysql has a mirror redirector for its downloads
+  # You can get this tarball by following a link from:
+  # http://dev.mysql.com/downloads/mysql/5.1.html
+  Source0: mysql-5.1.31.tar.gz
 ----
 [[Category:Extras]]

From ecd1e1fdcb2dffb6ef5c59080edbd01b16a2d75f Mon Sep 17 00:00:00 2001
From: Spot 
Date: Apr 14 2009 14:50:37 +0000
Subject: [PATCH 277/3559] /* Troublesome URLs */


---

diff --git a/Packaging:SourceURL.mw b/Packaging:SourceURL.mw
index 927bbdc..eeb5343 100644
--- a/Packaging:SourceURL.mw
+++ b/Packaging:SourceURL.mw
@@ -89,7 +89,7 @@ changing ".tar.gz" to whatever matches the upstream distribution.  Note that we 
 Using %{version} in the SourceX: makes it easier for you to bump the version of a package, because most of the time you do not need to edit SourceX: when editing the specfile for the new package.
 
 == Troublesome URLs ==
-When upstream has URLs for the download that do not end with the tarball name rpm will be unable to parse the tarball out of the source URL.  In these cases, you have to put just the tarball's filename into the Source: field.  To make clear where you got the tarball, you should leave notes in comments above the Source: line to explain the situation to reviewers and future packagers.  Example:
+When upstream has URLs for the download that do not end with the tarball name, rpm will be unable to parse the tarball out of the source URL.  In these cases, you have to put just the tarball's filename into the Source: field.  To make clear where you got the tarball, you should leave notes in comments above the Source: line to explain the situation to reviewers and future packagers.  Example:
 
   # Mysql has a mirror redirector for its downloads
   # You can get this tarball by following a link from:

From a787a9db99c4c5d06e6eb2f2fd4e82b28ea6aa5b Mon Sep 17 00:00:00 2001
From: Spot 
Date: Apr 14 2009 14:51:10 +0000
Subject: [PATCH 278/3559] *Empty MediaWiki Message*


---

diff --git a/Packaging:GuidelinesTodo.mw b/Packaging:GuidelinesTodo.mw
index 6f32907..715c4f0 100644
--- a/Packaging:GuidelinesTodo.mw
+++ b/Packaging:GuidelinesTodo.mw
@@ -13,8 +13,6 @@ Status should be one of:
 |-
 |writeup||Documentation Naming || spot || 2009-03-31 || [[PackagingDrafts/DocumentationNaming]]
 |-
-|writeup||Source URL Update||abadger1999|| 2009-03-02||[[Troublesome source URL packaging guideline draft]]. Section on dealing with URLs that can't go into the Source: line.
-|-
 |writeup||Updated Haskell Guidelines || spot || 2009-01-20 || [[PackagingDrafts/Haskell]]
 |-
 |writeup|| PHP channel || [[User:Remi]] || 2009-02-17 || [[PackagingDrafts/PHP]]
@@ -41,6 +39,8 @@ Status should be one of:
 |-
 |Duplicate Files update || [[User:Toshio]] || 2009-04-14 || [[PackagingDrafts/Duplicate Files]]
 |-
+|Source URL Update||abadger1999|| 2009-04-14||[[Troublesome source URL packaging guideline draft]]. Section on dealing with URLs that can't go into the Source: line.
+|-
 |FontSpecTemplate outside of Packaging||abadger1999|| 2009-03-02 ||[[Packaging:FontsSpecTemplate]] redirected to a page outside of Packaging. The redirect was dropped.
 |-
 |Update Desktop File Install Usage to Drop Vendor || spot || 2009-01-20 || [[TomCallaway/DesktopFileVendor]]

From 556cf6439c0c98107a031965857d543e96005151 Mon Sep 17 00:00:00 2001
From: Spot 
Date: Apr 14 2009 14:55:04 +0000
Subject: [PATCH 279/3559] 0.30: Add multiple base naming exception for Documentation packages (as approved by Fedora Docs)


---

diff --git a/Packaging:Naming.mw b/Packaging:Naming.mw
index 004c278..74abcad 100644
--- a/Packaging:Naming.mw
+++ b/Packaging:Naming.mw
@@ -1,9 +1,9 @@
 = Package Naming Guidelines =
 
 '''Author:''' [[TomCallaway|  Tom 'spot' Callaway]] 

-'''Revision:''' 0.51

+'''Revision:''' 0.52

 '''Initial Draft:''' Wednesday Feb 23, 2005

-'''Last Revised:''' Tuesday, Jan 20, 2009

+'''Last Revised:''' Tuesday, Apr 14, 2009

 
 
 
@@ -70,6 +70,9 @@ The most current version of openssl has Name: openssl 

 The previous version of openssl has Name: openssl096b 

 Note that we do not use delimiters in the name in this situation, we remove the period '.' from the version number and attach it to the name.
 
+=== Documentation Packages with Embedded OS versioning ===
+Documentation packages (as approved by the Fedora Documentation Project) can be named with the OS version number in the package name to allow parallel installation of multiple versions, in cases where the documentation is specific to a release of Fedora and there is value in having multiple versions simultaneously installed.
+
 {{Anchor|SpecName}}
 == Spec file name ==
 The spec file should be named using the %{name}.spec scheme. This is to make it easier for people to find the appropriate spec when they install a src.rpm.

From e51b0040566dafbac39196c09080637b05e61924 Mon Sep 17 00:00:00 2001
From: Spot 
Date: Apr 14 2009 14:56:04 +0000
Subject: [PATCH 280/3559] *Empty MediaWiki Message*


---

diff --git a/Packaging:GuidelinesTodo.mw b/Packaging:GuidelinesTodo.mw
index 715c4f0..8aa357c 100644
--- a/Packaging:GuidelinesTodo.mw
+++ b/Packaging:GuidelinesTodo.mw
@@ -11,8 +11,6 @@ Status should be one of:
 |- style="color: white; background-color: #3074c2; font-weight: bold" 
 |Status||Task Name||Owner||Meeting Date||Notes
 |-
-|writeup||Documentation Naming || spot || 2009-03-31 || [[PackagingDrafts/DocumentationNaming]]
-|-
 |writeup||Updated Haskell Guidelines || spot || 2009-01-20 || [[PackagingDrafts/Haskell]]
 |-
 |writeup|| PHP channel || [[User:Remi]] || 2009-02-17 || [[PackagingDrafts/PHP]]
@@ -41,6 +39,8 @@ Status should be one of:
 |-
 |Source URL Update||abadger1999|| 2009-04-14||[[Troublesome source URL packaging guideline draft]]. Section on dealing with URLs that can't go into the Source: line.
 |-
+|Documentation Naming || spot || 2009-04-14 || [[PackagingDrafts/DocumentationNaming]]
+|-
 |FontSpecTemplate outside of Packaging||abadger1999|| 2009-03-02 ||[[Packaging:FontsSpecTemplate]] redirected to a page outside of Packaging. The redirect was dropped.
 |-
 |Update Desktop File Install Usage to Drop Vendor || spot || 2009-01-20 || [[TomCallaway/DesktopFileVendor]]

From 078a45e4819548a9d1c886a8ddaa1bac6ef83921 Mon Sep 17 00:00:00 2001
From: Spot 
Date: Apr 14 2009 14:58:43 +0000
Subject: [PATCH 281/3559] *Empty MediaWiki Message*


---

diff --git a/Packaging:Haskell.mw b/Packaging:Haskell.mw
index 30c6a9d..c71576b 100644
--- a/Packaging:Haskell.mw
+++ b/Packaging:Haskell.mw
@@ -1,50 +1,43 @@
 = Haskell Packaging Guidelines =
-
 This documents the guidelines and conventions for packaging Haskell projects in Fedora.
 
-
-
 == What is Haskell? ==
+''"Haskell is an advanced purely functional programming language. The product of more than twenty years of cutting edge research, it allows rapid development of robust, concise, correct software. With strong support for integration with other languages, built-in concurrency, debuggers, profilers, rich libraries and an active community, Haskell makes it easier to produce flexible, maintainable high-quality software."'' -- (from http://haskell.org/)
 
-(from http://haskell.org/)
+=== GHC ===
+[http://haskell.org/ghc GHC], the Glasgow Haskell Compiler, is the most popular and widely used Haskell compiler.  It complies with Haskell 98, the latest official language specification, and also includes various experimental language ideas.  It represents a good picture of what the future of Haskell will look like, so it is a good choice for development.  Most Haskell programs work better or only with GHC.  So currently these guidelines mostly focus on packaging for GHC.  At some later stage if the need arises they may be extended to cover other implementations in more detail.
 
-Haskell is an advanced purely functional programming language. The product of more than twenty years of cutting edge research, it allows rapid development of robust, concise, correct software. With strong support for integration with other languages, built-in concurrency, debuggers, profilers, rich libraries and an active community, Haskell makes it easier to produce flexible, maintainable high-quality software.
+Packages should normally be compiled with GHC where possible.  Some Haskell packages might require some other compiler extension not available in GHC but in another compiler implementation in which case that compiler would have to be included in Fedora first before the package can get added to Fedora.  If a package needs special language features they should be mentioned in the review and documented in comments in the spec file.
 
-GHC, or the Glasgow Haskell Compiler, is the most popular and widely used Haskell compiler.  It complies with Haskell 98, the latest official language specification, and also includes numerous experimental language ideas.  It represents a good picture of what the future of Haskell will look like, so it is a good choice for development.  Many Haskell programs work better or only with GHC.  So currently these guidelines mainly focus on packaging for GHC.  At some later stage if the need arises they may be extended to cover other implementation in more detail.
+''Rationale: GHC is the best supported compiler in Fedora currently.  Therefore, if something goes wrong, we have a larger skill base to ask for help.''
 
-== Base package naming ==
+=== Cabal ===
+''"Cabal is a system for building and packaging Haskell libraries and programs. It defines a common interface for package authors and distributors to easily build their applications in a portable way. Cabal is part of a larger infrastructure for distributing, organizing, and cataloging Haskell libraries and programs.''
 
-=== Libraries ===
-Haskell library packages should be prefixed with the compiler or interpreter they are intended for.  Package names should follow the upstream naming and preserve case.  For example,  the bzlib library from [http://hackage.haskell.org/ Hackage] packaged for GHC would be named ghc-bzlib in Fedora, and the QuickCheck library would be named ghc-QuickCheck.
+''Specifically, the Cabal describes what a Haskell package is, how these packages interact with the language, and what Haskell implementations must do to support packages. The Cabal also specifies some infrastructure (code) that makes it easy for tool authors to build and distribute conforming packages.''
 
-If a library is packaged for more than one Haskell compiler or interpreter, the base name should instead be prefixed with haskell, e.g. haskell-X11.  Such a package would then have subpackages for each compiler and/or interpreter it is built for (e.g. ghc-X11, hug98-X11, etc.
+''The Cabal is only one contribution to the larger goal. In particular, the Cabal says nothing about more global issues such as how authors decide where in the module name space their library should live; how users can find a package they want; how orphan packages find new owners; and so on."''
 
-''Rationale: The Fedora Project tries to follow upstream as closely as possible.  Upstream maintains very consistent naming schemes, and mixed case names are tracked very well.''
+(from http://haskell.org/cabal)
 
-=== Programs ===
-For packages of Haskell programs the usual Fedora Package Naming Guidelines must be followed: ie in they should follow the upstream name. Examples include projects like darcs, haddock, and xmonad.  If the package also generates libraries, then the libraries SHOULD be subpackaged as a Haskell library package named after the compiler or interpreter as above.
-
-''Rationale: Binaries are not dependant on the compiler they were compiled with anymore than a C program is dependant on whether it's been compiled with gcc or icc.''
-
-== Description ==
-When packaging things out of [http://hackage.haskell.org Hackage]  or other sources, you may find that the description is incomplete or improperly labeled.  Please double check all parts of the package description so that it meets Fedora's standards for writing quality.
+== Summary and Description ==
+When packaging things out of [http://hackage.haskell.org Hackage]  or other sources, you may find that the summary or description is incomplete or lacks detail.  Please try to include an appropriate summary and adequate description for Fedora of the library or program in the package so users will know what it does.
 
 == Build and Install ==
-
 %build and %install can be done through a series of macros that ensure correctness.
 
 
 %build
-%cabal_configure
-%cabal_build
-%cabal_haddock
+%cabal_configure --ghc -p
+%cabal build
+%cabal haddock
 

 
-''Note: Please include profiling libraries where possible or include a justification for not doing so.''
+%cabal_configure --ghc -p configures the package for building with ghc and profiling.  ''Note: library packages should include profiling libraries where possible or include a justification for not doing so.''  If you omit profiling libraries (the -p option above), anyone wanting to install a profiling version of a dependent library or application will be unable to do so, which is generally considered bad form.  There is no need to provide profiling for non-library packages.
 
-%cabal_build will build a package without installing it
+%cabal build will build a package without installing it.
 
-%cabal_haddock builds haddock files
+%cabal haddock builds HTML Haddock documentation files.
 
 
 %install
@@ -52,149 +45,159 @@ rm -rf ${RPM_BUILD_ROOT}
 %cabal_install
 

 
-%cabal_install will install the package without including the registration scripts for ghc's library management.  For libraries, see below how to achieve this.
+%cabal_install will install the package without including the registration scripts for ghc's library management.  For libraries there are additional macros for generating the install scripts and filelists: see below.
 
 == Packaging libraries ==
-GHC libraries should be installed under libdir/ghc as done by Cabal.
+=== Naming ===
+The names of Haskell library packages should be prefixed with the compiler or interpreter they are intended for.  Package names should follow the upstream naming and preserve case.  For example,  the bzlib library from [http://hackage.haskell.org/ Hackage] packaged for GHC would be named ghc-bzlib in Fedora, and the QuickCheck library would be named ghc-QuickCheck.
+
+If a library is packaged for more than one Haskell compiler or interpreter, the base name should instead be prefixed with haskell, e.g. haskell-X11.  Such a package would then have subpackages for each compiler and/or interpreter it is built for (e.g. ghc-X11, hugs98-X11, etc.
+
+''Rationale: The Fedora Project tries to follow upstream as closely as possible.  Haskell upstream packages maintain consistent naming schemes across tarball, cabal and ghc package names, and mixed case names are tracked well.''
+
+=== Static vs. Dynamic Linking ===
+Current releases of GHC do not yet support generating shared libraries, so all ghc libraries are static and library packages of them should provide themselves as a -devel package also to allow migrating parts of them to -devel subpackages in the future when shared libraries become the norm:
+
+
+Provides: ghc-%{pkg_name}-devel = %{version}-%{release}
+

+
+Static linking means that when updating any library, all packages that depend on it will also need to be rebuilt before they see any changes, and in the event of a security advisory, all of them need to be rebuilt also.
+
+This is not true for linking to other languages using the Foreign Function Interface (FFI).  When linking to these libraries, the standard dynamic linker is used.
+
+''Note: the situation is similar to OCaml, and the usual rules that apply there apply here as well.''
+
+Keep in mind though, that some special packages may still do code generation at runtime in which case they may need Requires as well as BuildRequires for their dependencies: examples include xmonad and yi which may require certain libraries to be present to work.
+
+=== Package directory ===
+GHC libraries should be installed under %pkg_libdir as done by Cabal.
 
 
 %global pkg_libdir %{_libdir}/ghc-%{ghc_version}/%{pkg_name}-%{version}
 

 
 === File lists ===
-You can generate filelists using the following macro, rather than doing it by hand:
+You can generate filelists for libraries and profiling library subpackages using the following macro, rather than doing it by hand:
 
 
 %ghc_gen_filelists %{name}
 

 
-This macro takes one parameter, which is just a name to be used for the file lists.  This same parameter must be used later in the files section.
+This macro takes one parameter, which is just a name prefix to be used for the file lists.  This same parameter must be used later in the files section.
 
 The files section would then look something like this:
 
 
 %files -f %{name}.files
 %defattr(-,root,root,-)
-%doc dist/doc/html
-%doc LICENSE TODO README
-
+%doc LICENSE README
+%{pkg_docdir}
 
 %files -n %{name}-prof -f %{name}-prof.files
 %defattr(-,root,root,-)
-%doc LICENSE
 

 
 === Install scripts ===
-Libraries must be registered with the installed GHC.
+Libraries must be registered with the installed ghc package.
 
-To generate registration scripts that can be embedded in the package, include the following in %build, and include the following install script macros.
+To generate registration scripts that can be embedded in the package first include the following in %build:
 
 %ghc_gen_scripts
 

-
-To separate the copying phase from the registration phase of installation, include the following in %install
+and then in %install install them with:
 
 %ghc_install_scripts
 

 
-To register packages at install time, make sure to include the following bits:
+Finally the actual registering of packages must be done at install and uninstall time with the following scriplets:
 
-%pre -n ghc-%{pkg_name}
-%ghc_preinst_script
+%post -n ghc-%{pkg_name}
+%ghc_register_pkg
 
+%preun -n ghc-%{pkg_name}
+if [ "$1" -eq 0 ] ; then
+  %ghc_unregister_pkg
+fi
+

 
-%post -n ghc-%{pkg_name}
-%ghc_postinst_script
+=== Documentation ===
+Normal doc files for a package should live in the usual place.  Haskell supports inline API docs using the haddock tool (bundled in the ghc package as of 6.10), for which the situation is somewhat different.  The master directory for Haddock files is %{_docdir}/ghc/libraries, with one directory per package under there.  The index.html file for this directory should be regenerated every time a package is installed, upgraded, or removed.  Since %{_docdir}/ghc/libraries is owned by ghc-doc it is recommended to subpackage haddock documentation in a doc subpackage, which can require ghc-doc.
 
+If a package comes with meaningful Haddock documentation, your spec file should define
 
-%preun -n ghc-%{pkg_name}
-%ghc_preun_script
+
%global pkg_docdir %{_docdir}/ghc/libraries/%{pkg_name}

 
+and the %build section should contain the following:
 
-%postun -n ghc-%{pkg_name}
-%ghc_postun_script
+
%cabal haddock

+
+This will cause the HTML version of the Haddock documentation to be generated.  If built, it will automatically be installed to the correct location by %cabal_install without any further intervention.
+
+To automatically update the master index of all Haddock documentation in /usr/share/doc/ghc/libraries, add the following to your %post and %postun scriptlets:
+
+
+%post 
+%ghc_reindex_haddock
+
+%postun
+if [ "$1" -eq 0 ] ; then
+  %ghc_reindex_haddock
+fi
 

 
+The ghc haddock docs index will then be updated after installation, update, or removal of the package.
+
+Finally, you'll want to add the following to your %files section, so that the Haddock docs will be picked up correctly.
+
+
%{pkg_docdir}

+
 == Packaging programs ==
-Programs are packaged in their simple name, eg xmonad would remain xmonad.  Any libraries should go into a separate subpackage: eg the spec file for xmonad would generate two rpms, both of which are required for runtime, xmonad and ghc-xmonad.  xmonad would require ghc-xmonad, but not visa versa.  ghc-xmonad would contain a line in its description explaining that these are the libraries necessary for xmonad to run.
+=== Naming ===
+For packages of Haskell programs the usual Fedora Package Naming Guidelines must be followed: ie in they should follow the upstream name. Examples include projects like darcs, haddock, and xmonad.  If the package also generates libraries, then the libraries SHOULD be subpackaged as a Haskell library package named after the compiler or interpreter as above.
 
-Binary packages should be compiled with GHC when possible.  Some Haskell packages might require some compiler extension not provided in GHC. Alternate compilers may be used so long as they are packaged for Fedora.  Please make it clear what feature is needed when submitting that package for review, and leave an appropriate comment in the spec file.
+Any libraries provided should go into a separate subpackage: eg the spec file for xmonad would generate three rpm packages: xmonad, ghc-xmonad, and ghc-xmonad-prof.  xmonad would require ghc-xmonad, but not visa versa.  ghc-xmonad would contain a line in its description explaining that these are the libraries necessary for xmonad to run.
 
-If a compiler is not available in Fedora, please submit it for package review as well.  We can block your review request on the compiler, and if they pass review, they can be accepted simultaneously.  Please note that your compiler must follow Fedora's guidelines for packaging and package submission.
+''Rationale: Program packages should be easy to find by their upstream name. Binaries are recognized on their name alone.  Furthermore, they generally do not require a compiler to run.  Therefore the name provided should simply be the upstream name.
 
-''Rationale: Binaries are recognized on their name alone.  Furthermore, they do not require a compiler to run.  Therefore the name provided should simply be the upstream name.  GHC is the best supported compiler in Fedora currently.  Therefore, if something goes wrong, we have a larger skill base to ask for help.''
 
-== Documentation ==
-Packages should try to make sure Haddock document links correctly to other dependent packages.
 
 == Debug Information ==
 Debuginfo packages should not be built for GHC binaries, since they will be empty anyway.
 
+
+%global debug_package %{nil}
+

+
 ''Rationale: GHC does not emit DWARF debug data.''
 
 == Macros ==
-
-A number of macros are defined for cabal packages, per compiler.  They have names like %ghc_build and %ghc_install. Similar macros can be defined for other compilers.  Please stick to this API when implementing macros for other compilers.
+A number of macros are defined for convenince for packaging cabal packages and libraries for ghc.  Similar macros could also be defined for other compilers.  It would be good to follow this scheme as far as possible also when implementing macros for other Haskell compilers or interpreters to keep portability.
 
 * %cabal
 * %cabal_configure
-* %cabal_build
 * %cabal_makefile
-* %cabal_haddock
+* %ghc_gen_scripts
 * %cabal_install
 * %ghc_install_scripts
 * %ghc_gen_filelists()
-* %ghc_preinst_script
-* %ghc_postinst_script
-* %ghc_preun_script
-* %ghc_postun_script
-
-=== Definitions ===
-
-Definitions per compiler go here
+* %ghc_register_pkg
+* %ghc_unregister_pkg
+* %ghc_reindex_haddock
 
-* [[PackagingDrafts/Haskell/GHCMacroDefs | Definitions for GHC Macros ]]
+You can find the current [http://cvs.fedoraproject.org/viewvc/devel/ghc/ghc-rpm-macros.ghc?view=co ghc.macros] definitions in the ghc package.
 
 == Spec Templates ==
-There are three types of packages: Library only, Library and Binary, and Binary only.  The program cabal-rpm can generate a SPEC file suited to all three cases.  The following templates are the output from cabal-rpm with a few minor changes.  These templates should build under mock, and any failure is a bug against these guidelines.
-
-* [[PackagingDrafts/Haskell/LibraryOnlyTemplate|  Library Only Template]] 
-* [[PackagingDrafts/Haskell/BinaryOnlyTemplate|  Binary Only Template]]
-* [[PackagingDrafts/Haskell/LibraryAndBinaryTemplate|  Library and Binary Template]]
-
-== Static vs. Dynamic Linking ==
-
-Currently GHC performs only static linking with other Haskell libraries, partly due to a significant amount of optimizations done when inlining functions from other libraries.  Therefore, when recompiling any library, all packages that depend on it will also need to be recompiled, and in the event of a security advisory, one needs to be applied to all dependencies.
-
-This is not true for libraries linked through other languages using the Foreign Function Interface (FFI).  When linking to these libraries, the standard dynamic linker is used.
-
-''Note: this is very similar to OCaml, and the usual rules that apply there apply here as well.''
-
-Keep in mind though, this does not mean that you can just put all dependencies in the BuildRequires list and be done with it.  Some packages, such as xmonad, perform lots of run time code generation, and may require certain libraries to be present to work.
-
-== Using cabal-rpm ==
-If you use cabal-rpm to generate spec files, there are a few gotchas.  These items are the difference between Yaakov Nemoy's working cabal-rpm and the guidelines.  Since there is little variety in spec files, it might be easier to copy one of the templates from above and make the changes needed.
-
-* The file name of the spec file will be the name of the package.  Make sure to prepend 'ghc-' or the appropriate name for another compiler to the spec file before submitting it for review.  This is necessary for libraries only.  (For example, there would be a collision between ghc-zlib and zlib, but there is only one haddock or darcs.)
-* cabal-rpm is currently only aware of haskell libraries installed by default with GHC.  It will need alot more work to provide automagic dependency detection.
-* cabal-rpm isn't always so intelligent about runtime dependencies for libraries.  For example, it may specify the devel version of a library where the non-devel version is required. (This is important for binaries only.  Libraries require devel versions, of course.)
-* BuildRequires probably needs to be filled out by hand.  One suitable method is to keep testing it in mock until it compiles cleanly.
-* If the source package requires steps besides cabal, report it to upstream, and make sure to include them in the %build and %install sections.
-
-Double check the following:
+There are three types of packages: Library only, Library and Binary, and Binary only.  Templates are provided for all three cases since they are slightly different:
 
-* License
-* Group
-* URL - this can be the Hackage page
-* Source URL - this can be from Hackage
-* Summary
-* Description
-* Files section includes all documentation and LICENSES. If not, please patch it according to the Fedora Packaging Guidelines
+* [http://git.fedorahosted.org/git/cabal2spec.git?p=cabal2spec.git;a=blob_plain;f=spectemplate-ghc-lib.spec;hb=HEAD Library Only Template]
+* [http://git.fedorahosted.org/git/cabal2spec.git?p=cabal2spec.git;a=blob_plain;f=spectemplate-ghc-bin.spec;hb=HEAD Binary Only Template]
+* [http://git.fedorahosted.org/git/cabal2spec.git?p=cabal2spec.git;a=blob_plain;f=spectemplate-ghc-binlib.spec;hb=HEAD Library and Binary Template].
 
-Finally, make sure to include changelog entries to specify what has been changed from the original cabal-rpm output.
+cabal2spec provides a simple script which can generate .spec files using these templates directly out of a Cabal package or .cabal file for any of the three cases.  The .spec files should build for most general Cabal hackage packages with minimal changes: for example you might need to specify BuildRequires for other build dependencies and possibly Requires for any runtime or linking dependencies.  Please report any problems in [https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&component=cabal2spec bugzilla (in the cabal2spec component of the Fedora product)].
 
 == References ==
+* http://petersen.fedorapeople.org/cabal2spec
 * http://urchin.earth.li/~ian/haskell-policy/ - Debian Haskell packaging policy
 * [[Packaging/OCaml|Fedora OCaml Packaging Guidelines]]
 * [[SIGs/Haskell|Fedora Haskell SIG]]
-* [http://ynemoy.fedorapeople.org/haskell Ynemoy's macros and cabal-rpm tree]

From 2f45dcb5b63b81aaa4839f11bcc7643c8a5414e3 Mon Sep 17 00:00:00 2001
From: Spot 
Date: Apr 14 2009 14:59:21 +0000
Subject: [PATCH 282/3559] *Empty MediaWiki Message*


---

diff --git a/Packaging:GuidelinesTodo.mw b/Packaging:GuidelinesTodo.mw
index 8aa357c..47d1ced 100644
--- a/Packaging:GuidelinesTodo.mw
+++ b/Packaging:GuidelinesTodo.mw
@@ -11,8 +11,6 @@ Status should be one of:
 |- style="color: white; background-color: #3074c2; font-weight: bold" 
 |Status||Task Name||Owner||Meeting Date||Notes
 |-
-|writeup||Updated Haskell Guidelines || spot || 2009-01-20 || [[PackagingDrafts/Haskell]]
-|-
 |writeup|| PHP channel || [[User:Remi]] || 2009-02-17 || [[PackagingDrafts/PHP]]
 |-
 |writeup|| Icon Cache update || [[User:Toshio]] || 2009-02-17 || [[PackagingDrafts/Icon_Cache]]
@@ -41,6 +39,8 @@ Status should be one of:
 |-
 |Documentation Naming || spot || 2009-04-14 || [[PackagingDrafts/DocumentationNaming]]
 |-
+|Updated Haskell Guidelines || spot || 2009-04-14 || [[PackagingDrafts/Haskell]]
+|-
 |FontSpecTemplate outside of Packaging||abadger1999|| 2009-03-02 ||[[Packaging:FontsSpecTemplate]] redirected to a page outside of Packaging. The redirect was dropped.
 |-
 |Update Desktop File Install Usage to Drop Vendor || spot || 2009-01-20 || [[TomCallaway/DesktopFileVendor]]

From 5c38364984a95c7a9508860ce4e0840b12cba6d4 Mon Sep 17 00:00:00 2001
From: Spot 
Date: Apr 14 2009 15:05:28 +0000
Subject: [PATCH 283/3559] *Empty MediaWiki Message*


---

diff --git a/Packaging:PHP.mw b/Packaging:PHP.mw
index 354f536..81a6c4d 100644
--- a/Packaging:PHP.mw
+++ b/Packaging:PHP.mw
@@ -1,21 +1,32 @@
 = Guidelines for packaging PHP addon modules =
 
 
-
 == Different kinds of packages ==
 
-There are basically two different kinds of php modules, which are packaged for Fedora Extras:
+There are basically 4 different kinds of php modules, which are packaged for Fedora:
 
 * [http://pecl.php.net PECL]  (PHP Extention Community Library), which are PHP modules usually written in C, which are dynamically loaded by the PHP interpreter on startup.
 * [http://pear.php.net PEAR]  (PHP Extension and Application Repository), which are reusable components written in PHP, usually classes, which can be used in your own PHP applications and scripts by using e.g. the include() directive.
+* CHANNEL : a package which register a channel. A channel is a repository which provides php extensions 
+* Other package providing php extension not handled by pear/pecl mechanisms 
+
+While upstream used the same package and distribution format for PECL and PEAR, creating RPMs has to take some differences into account.
+
+3 channels are defined on installation of php-pear
+* pear.php.net (alias pear) : the default channel for PHP Extension and Application Repository
+* pecl.php.net (alias pecl) : the default channel for PHP Extension Community Library
+* __uri : Pseudo-channel for static packages
 
-While upstream used the same package and distribution format for both, creating RPMs has to take some differences into account.
+Other channels must be configured at RPM build time and at at RPM installation time.
 
 {{Anchor|NamingScheme}}
+
 == Naming scheme ==
 
-* PECL packages should be named ''php-pecl-PECLPackageName-%{version}-%{release}.%{arch}.rpm''.
-* PEAR packages should be named ''php-pear-PEARPackageName-%{version}-%{release}.noarch.rpm''.
+* PECL packages from standard pecl channel should be named php-pecl-PECLPackageName-%{version}-%{release}.%{arch}.rpm.
+* PEAR packages from standard pear channel should be named php-pear-PEARPackageName-%{version}-%{release}.noarch.rpm. 
+* CHANNEL packages should be named php-channel-ChannelAlias-%{version}-%{release}.noarch.rpm
+* Packages from another channel  should be named php-ChannelAlias-PackageName-%{version}-%{release}.noarch.rpm.
 * Other packages should be named ''php-PackageName-%{version}-%{release}.%{arch}.rpm''; %{arch} can be "noarch" where appropriate.
 
 Please make sure that the PEAR package is correctly being built for noarch.
@@ -31,7 +42,7 @@ Non-PEAR PHP extensions should put their Class files in /usr/share/php.
 
 == Requires and Provides ==
 
-=== PEAR Packages ===
+=== PEAR Packages from the standard channel/repository ===
 
 A PEAR package '''MUST''' have:
 
@@ -43,6 +54,30 @@ Requires(postun): %{__pear}
 Provides:     php-pear(foo) = %{version}
 

 
+=== Packages for CHANNEL (repository) configuration  ===
+
+A CHANNEL package ''''MUST''' have :
+
+Requires: php-pear(PEAR)
+Requires(post): %{__pear}
+Requires(postun): %{__pear}
+Provides: php-channel(channelname)
+

+
+=== PEAR Packages from a non standard channel/repository ===
+
+A PEAR package '''MUST''' have:
+
+
+BuildRequires: php-channel(channelname)
+BuildRequires: php-pear(PEAR)
+Requires: php-pear(PEAR)
+Requires(post): %{__pear}
+Requires(postun): %{__pear}
+Requires: php-channel(channelname)
+Provides:     php-pear(channelname/foo) = %{version}
+

+
 === PECL Packages ===
 
 A PECL package '''MUST''' have:
@@ -64,10 +99,28 @@ Provides:     php-pecl(foo) = %{version}
 
 === Other Packages ===
 
-PHP addons which are neither PEAR nor PECL should require what makes sense (either a base PHP version or a php-api as necessary).
+PHP addons which are neither PEAR nor PECL should require what makes sense (either a base PHP version or a php-api, php(zend-abi) as necessary).
 
 == Macros and scriptlets ==
 
+=== Packages for CHANNEL (repository) configuration  ===
+
+Here are some recommended scriptlets for properly registering and unregistering the channel:
+
+
+%post
+if [ $1 -eq  1 ] ; then
+   %{__pear} channel-add %{pear_xmldir}/%{name}.xml > /dev/null || :
+else
+   %{__pear} channel-update %{pear_xmldir}/%{name}.xml > /dev/null ||:
+fi
+
+%postun
+if [ $1 -eq 0 ] ; then
+   %{__pear} channel-delete %{channelname} > /dev/null || :
+fi
+

+
 === PEAR Modules ===
 
 The php-pear package in Fedora Core 5 and above (version 1:1.4.9-1.2) provides several useful macros:
@@ -81,22 +134,33 @@ These defintions for the .spec should be of interest:
 
 BuildRequires:    php-pear >= 1:1.4.9-1.2
 Provides:         php-pear(PackageName) = %{version}
-Requires:         php >= 4.3, php-pear(PEAR)
+Requires:         php-common >= 4.3, php-pear(PEAR)
 Requires(post):   %{_bindir}/pear
 Requires(postun): %{_bindir}/pear
 

 
-And here are some recommended scriptlets for properly registering and unregistering the module:
+Here are some recommended scriptlets for properly registering the module:
 
 %post
-%{_bindir}/pear install --nodeps --soft --force --register-only %{pear_xmldir}/Foo_Bar.xml >/dev/null ||:
+%{_bindir}/pear install --nodeps --soft --force --register-only %{pear_xmldir}/%{name}.xml >/dev/null ||:
+

 
+And here are some recommended scriptlets for properly unregistering the module, from the standard channel:
+
 %postun
 if [ "$1" -eq "0" ] ; then
 %{_bindir}/pear uninstall --nodeps --ignore-errors --register-only Foo_Bar >/dev/null ||:
 fi
 

 
+From a non standard channel (pear command requires the channel):
+
+%postun
+if [ "$1" -eq "0" ] ; then
+%{_bindir}/pear uninstall --nodeps --ignore-errors --register-only Foo_channel/Foo_Bar >/dev/null ||:
+fi
+

+
 === PECL Modules ===
 
 The php-pear package in Fedora Core 5 and above (version 1:1.4.9-1.2) provides several useful macros:

From 0a0e3f6fe40b26ecc28be795f71cbce6a38a267a Mon Sep 17 00:00:00 2001
From: Spot 
Date: Apr 14 2009 15:06:06 +0000
Subject: [PATCH 284/3559] *Empty MediaWiki Message*


---

diff --git a/Packaging:GuidelinesTodo.mw b/Packaging:GuidelinesTodo.mw
index 47d1ced..6373e15 100644
--- a/Packaging:GuidelinesTodo.mw
+++ b/Packaging:GuidelinesTodo.mw
@@ -11,8 +11,6 @@ Status should be one of:
 |- style="color: white; background-color: #3074c2; font-weight: bold" 
 |Status||Task Name||Owner||Meeting Date||Notes
 |-
-|writeup|| PHP channel || [[User:Remi]] || 2009-02-17 || [[PackagingDrafts/PHP]]
-|-
 |writeup|| Icon Cache update || [[User:Toshio]] || 2009-02-17 || [[PackagingDrafts/Icon_Cache]]
 |}
 
@@ -41,6 +39,8 @@ Status should be one of:
 |-
 |Updated Haskell Guidelines || spot || 2009-04-14 || [[PackagingDrafts/Haskell]]
 |-
+|PHP channel || [[User:Remi]] || 2009-04-14 || [[PackagingDrafts/PHP]]
+|-
 |FontSpecTemplate outside of Packaging||abadger1999|| 2009-03-02 ||[[Packaging:FontsSpecTemplate]] redirected to a page outside of Packaging. The redirect was dropped.
 |-
 |Update Desktop File Install Usage to Drop Vendor || spot || 2009-01-20 || [[TomCallaway/DesktopFileVendor]]

From e48c2b29f3142176e98564ba648f54c6db447a14 Mon Sep 17 00:00:00 2001
From: Spot 
Date: Apr 14 2009 15:20:24 +0000
Subject: [PATCH 285/3559] *Empty MediaWiki Message*


---

diff --git a/Packaging:GuidelinesTodo.mw b/Packaging:GuidelinesTodo.mw
index 6373e15..d00ded8 100644
--- a/Packaging:GuidelinesTodo.mw
+++ b/Packaging:GuidelinesTodo.mw
@@ -10,8 +10,6 @@ Status should be one of:
 {| border="1"
 |- style="color: white; background-color: #3074c2; font-weight: bold" 
 |Status||Task Name||Owner||Meeting Date||Notes
-|-
-|writeup|| Icon Cache update || [[User:Toshio]] || 2009-02-17 || [[PackagingDrafts/Icon_Cache]]
 |}
 
 {{:PackagingDrafts/DraftsTodo}}
@@ -41,6 +39,8 @@ Status should be one of:
 |-
 |PHP channel || [[User:Remi]] || 2009-04-14 || [[PackagingDrafts/PHP]]
 |-
+|Icon Cache update || [[User:Toshio]] || 2009-02-17 || [[PackagingDrafts/Icon_Cache]]
+|-
 |FontSpecTemplate outside of Packaging||abadger1999|| 2009-03-02 ||[[Packaging:FontsSpecTemplate]] redirected to a page outside of Packaging. The redirect was dropped.
 |-
 |Update Desktop File Install Usage to Drop Vendor || spot || 2009-01-20 || [[TomCallaway/DesktopFileVendor]]

From f4f6df18866d71e188fb963867c8a6b2393e60c5 Mon Sep 17 00:00:00 2001
From: Spot 
Date: Apr 14 2009 18:05:32 +0000
Subject: [PATCH 286/3559] /* Action Items */


---

diff --git a/Packaging:GuidelinesTodo.mw b/Packaging:GuidelinesTodo.mw
index d00ded8..8e90a18 100644
--- a/Packaging:GuidelinesTodo.mw
+++ b/Packaging:GuidelinesTodo.mw
@@ -10,6 +10,11 @@ Status should be one of:
 {| border="1"
 |- style="color: white; background-color: #3074c2; font-weight: bold" 
 |Status||Task Name||Owner||Meeting Date||Notes
+|ratify||Common Package Names||abadger1999||2009-04-14||[[Common package names packaging guideline draft]]
+|-
+|ratify||Using Alternatives||[[User:Rathann|rathann]]||2009-04-14||[[PackagingDrafts/UsingAlternatives]]
+|-
+|ratify||WordPress plugins||[[User:Ianweller|Ian Weller]]||2009-04-14||[[User:Ianweller/WordPress plugin packaging guidelines (draft)]]
 |}
 
 {{:PackagingDrafts/DraftsTodo}}

From 8f95b7a3e082af2e2302587e4befc252686e8cf4 Mon Sep 17 00:00:00 2001
From: Spot 
Date: Apr 14 2009 18:06:19 +0000
Subject: [PATCH 287/3559] /* Action Items */


---

diff --git a/Packaging:GuidelinesTodo.mw b/Packaging:GuidelinesTodo.mw
index 8e90a18..855eee0 100644
--- a/Packaging:GuidelinesTodo.mw
+++ b/Packaging:GuidelinesTodo.mw
@@ -10,6 +10,7 @@ Status should be one of:
 {| border="1"
 |- style="color: white; background-color: #3074c2; font-weight: bold" 
 |Status||Task Name||Owner||Meeting Date||Notes
+|-
 |ratify||Common Package Names||abadger1999||2009-04-14||[[Common package names packaging guideline draft]]
 |-
 |ratify||Using Alternatives||[[User:Rathann|rathann]]||2009-04-14||[[PackagingDrafts/UsingAlternatives]]

From 166bb6f67b523e188366953dafa86b43fb61c968 Mon Sep 17 00:00:00 2001
From: Ellert 
Date: Apr 16 2009 14:05:39 +0000
Subject: [PATCH 288/3559] Draft Globus Packaging Guidelines - initial version


---

diff --git a/Packaging:Globus.mw b/Packaging:Globus.mw
new file mode 100644
index 0000000..790b58a
--- /dev/null
+++ b/Packaging:Globus.mw
@@ -0,0 +1,819 @@
+{{Draft}}
+
+This document describes the guidelines and conventions for packaging components from the Globus Toolkit in Fedora. The following guidelines applies to the components of the Globus Toolkit written in C. A future version of the guidelines may address the packaging of components written in java as well.
+
+== What is the Globus Toolkit? ==
+
+The Globus Toolkit is a set of libraries and tools used as building blocks for grid computing applications. The toolkit is developed and maintained by the [http://www.globus.org/ Globus Alliance].
+
+== Obtaining sources ==
+
+The sources for the Globus Toolkit are distributed as one big installer tarball that contain the sources for more than 300 packages. Since including this huge tarball in every Globus source RPM and use less than 1% of it to compile a single Globus package would be extremely wasteful in terms of diskspace and bandwidth, the relevant subdirectory from the installer tarball must be extracted and repackaged for each package. This must be documented using comments in the spec file according to the [[Packaging:SourceURL]] guidelines so that the source tarball can be reproduced, as in the following example:
+
+
+#               Source is extracted from the globus toolkit installer:
+#               wget -N http://www-unix.globus.org/ftppub/gt4/4.2.1/installers/src/gt4.2.1-all-source-installer.tar.bz2
+#               tar -jxf gt4.2.1-all-source-installer.tar.bz2
+#               mv gt4.2.1-all-source-installer/source-trees/core/source globus_core-5.15
+#               tar -zcf globus_core-5.15.tar.gz globus_core-5.15
+Source:         %{_name}-%{version}.tar.gz
+

+
+=== Off-release upstream updates ===
+
+Occasionally the Globus Alliance publishes an off-release update of a package. For these updates each updated package is available as a separate tarball, and the repackaging discribed above should not be done:
+
+
+Source:         http://www-unix.globus.org/ftppub/gt4/4.2.1/updates/src/%{_name}-%{version}.tar.gz
+

+
+In order to keep the packaging consistent, the naming of the tarfiles extracted from the installer should use the same naming convention as upstream uses for the tarfiles for these updates, i.e. the upstream package name and version.
+
+== Grid packaging tools ==
+
+The Globus Toolkit uses its own build system called the grid packaging tools (GPT). This is available in Fedora in the '''grid-packaging-tools''' package.
+
+== globus-core ==
+
+The '''globus-core''' package is a development package that provides common build instructions for all globus packages. The globus-core package is not required at runtime and must not be listed as a Requires other than for -devel packages.
+
+== Creating the specfile for a Globus package ==
+
+All metadata about a Globus package needed to create the specfile is available in the package's GPT source package description file, usually obtainable as pkgdata/pkg_data_src.gpt.in in the package's sources. This is an XML file that contains the package's
+
+* Name
+* Version
+* Description
+* Build dependencies
+* Link dependencies
+* Runtime dependencies
+
+The underscores in the upstream package name are changed to dashes in order to comply with the [[Packaging/NamingGuidelines#Separators]] guidelines.
+
+== GPT packages vs. RPM packages ==
+
+GPT has its own packaging mechanism, and automatically distributes the installed files generated from the GPT source package into several GPT binary packages. By taking advantage of this feature the split of the installed files into several binary RPMs can be automatised.
+
+For a globus package that provides libraries the mapping between GPT and RPM packages is as follows:
+
+* %{flavor}_rtl.gpt → main package
+* %{flavor}_dev.gpt → -devel package
+* noflavor_doc.gpt → -doc package
+
+And if the package provides programs as well as libraries:
+
+* %{flavor}_pgm.gpt → -progs package
+
+For a globus package that provides only programs the mapping is as follows:
+
+* %{flavor}_pgm.gpt → main package
+
+== GPT metadata files ==
+
+The grid-packaging-tools install GPT metadata about the binary packages they create. Each GPT binary package has two metadata files in /usr/share/globus/. These files should be packaged in the binary RPMs since they are needed by GPT to resolve build dependencies and by GPT user tools, such as gpt-query.
+
+Some of the GPT metadata files contain information about architecture specific files. However, the metadata itself is architecture independant and therefore belong in /usr/share rather than /usr/lib. GPT uses different filenames for metadata files containing architecture dependent information, so there are no filename clashes in a multi-architecture installation.
+
+These GPT metadata files are also used to generate the RPM filelists. The main difference between the GPT and RPM filelist format is that the prefix (/usr) is missing in the GPT filelist. The translation can be done using a simple sed replacement.
+
+== Doc packages ==
+
+The globus library APIs are documented using doxygen comments. These are used to generate the documentation in the GPT doc packages. For some globus packages these packages are very large, while for others they are quite small. In order to provide consistent and user predictable packaging for all globus packages, the GPT doc packages should be packaged as separate doc RPMs for all globus packages regardless of their size.
+
+== Setup packages ==
+
+Some globus packages has a corresponding setup package. These two packages usually requires each other and it doesn't make sense to create separate RPMs for them. The source RPM should therefore contain the sources for both packages.
+
+A setup package normally contains a postinstall script. Since the install location of the RPM package is known it is on most occasions possible to convert the commands in this postinstall script to commands in the install section of the specfile instead, and not use a postinstall scriptlet. It is usually not a good idea to run the postinstall script provided in the sources as a postinstall scriptlet in the RPM since it often depends on the grid-packaging-tools, which is a development package and should not be Required by a non-devel package.
+
+== Plugins ==
+
+Most globus libraries are simply libraries. However, globus occasionally uses a plugin mechanism based on the libtool dynamic loader library (libltdl). Libraries used as plugins in this way can be recognized by that they have an empty pkg_libs tag in the Build_Environment in the GPT source description file. Since the libtool dynamic loader library requires the libtool archive (.la) files at runtime for proper functionality, these packages as an exception should contain these files.
+
+== Library flavor tags ==
+
+In a default Globus installation a flavor tag, encoding the name of the compiler and the architecture, is added to the name of the libraries in order to allow libraries for multiple architectures to be installed in the same directory. This is not needed in Fedora since in a multi-architecture installation, Fedora installs libraries for different architectures in different directories. Also encoding this information in the library names violates the packaging guidelines.
+
+By adding a ColocateLibraries="no" attribute to the With_Flavors tag in the GPT source package description file, GPT can be told to generate Makefile rules without the flavor tag in the library names.
+
+== GPT glue packages ==
+
+Some of the GPT packages in the huge Globus Toolkit installer tarball contain copies of sources of external libraries the Globus packages depend on. Such code should not be packaged in Fedora, since these libraries are already available in the distribution. However, since building the Globus packages uses GPT, the build process expects that the GPT metadata for these packages exists. In this case, a GPT glue package should be created containing only GPT metadata files. These files should refer to the Fedora version of the library as an external dependency. The version of this package should be the same as the version of the globus package it replaces.
+
+== Autogenerating specfiles (informational) ==
+
+It is possible to autogenerate an initial version of the specfile from the information in the GPT source package description file by running the [http://www.grid.tsl.uu.se/repos/globus/scripts/globus-spec.pl globus-spec.pl] script. Using this script is optional, but provides increased maintainability of the package and reduces the risk of cut and paste errors. The following examples shows the autogenerated specfiles generated by the script in a few cases.
+
+=== Globus package that provides a library ===
+
+
+./globus-spec.pl -g globus_gsi_openssl_error-0.14/pkgdata/pkg_data_src.gpt.in -d gsi/openssl_error/source
+
+
+* The -g option specifies the GPT source package description file
+* The -d option specifies the directory in the installer from where the code was extracted.
+* The -e option can be used to specify the packager's e-mail address (defaults to username@host)
+
+
+%ifarch alpha ia64 ppc64 s390x sparc64 x86_64
+%global flavor gcc64pthr
+%else
+%global flavor gcc32pthr
+%endif
+
+Name:		globus-gsi-openssl-error
+%global _name %(tr - _ <<< %{name})
+Version:	0.14
+Release:	1%{?dist}
+Summary:	Globus Toolkit - Globus OpenSSL Error Handling
+
+Group:		System Environment/Libraries
+License:	ASL 2.0
+URL:		http://www.globus.org/
+#		Source is extracted from the globus toolkit installer:
+#		wget -N http://www-unix.globus.org/ftppub/gt4/4.2.1/installers/src/gt4.2.1-all-source-installer.tar.bz2
+#		tar -jxf gt4.2.1-all-source-installer.tar.bz2
+#		mv gt4.2.1-all-source-installer/source-trees/gsi/openssl_error/source globus_gsi_openssl_error-0.14
+#		tar -zcf globus_gsi_openssl_error-0.14.tar.gz globus_gsi_openssl_error-0.14
+Source:	%{_name}-%{version}.tar.gz
+Source8:	epstopdf-2.9.5gw
+BuildRoot:	%{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
+
+Requires:	globus-openssl >= 1
+BuildRequires:	grid-packaging-tools
+BuildRequires:	globus-common-devel >= 3
+BuildRequires:	globus-openssl-devel >= 1
+BuildRequires:	globus-core >= 4
+BuildRequires:	doxygen
+%if %{?fedora}%{!?fedora:0} >= 3
+BuildRequires:	graphviz
+BuildRequires:	ghostscript
+%else
+%if %{?rhel}%{!?rhel:0} >= 5
+BuildRequires:	graphviz
+BuildRequires:	ghostscript
+%if "%{?rhel}" == "5"
+BuildRequires:	graphviz-gd
+%endif
+%endif
+%endif
+%if %{?fedora}%{!?fedora:0} >= 9
+BuildRequires:	tex(latex)
+%else
+%if %{?rhel}%{!?rhel:0} >= 6
+BuildRequires:	tex(latex)
+%else
+BuildRequires:	tetex-latex
+%endif
+%endif
+
+%package devel
+Summary:	Globus Toolkit - Globus OpenSSL Error Handling Development Files
+Group:		Development/Libraries
+Requires:	%{name} = %{version}-%{release}
+Requires:	globus-common-devel >= 3
+Requires:	globus-openssl-devel >= 1
+Requires:	globus-core >= 4
+
+%package doc
+Summary:	Globus Toolkit - Globus OpenSSL Error Handling Documentation Files
+Group:		Documentation
+Requires:	%{name} = %{version}-%{release}
+
+%description
+The Globus Toolkit is an open source software toolkit used for building Grid
+systems and applications. It is being developed by the Globus Alliance and
+many others all over the world. A growing number of projects and companies are
+using the Globus Toolkit to unlock the potential of grids for their cause.
+
+The %{name} package contains:
+Globus OpenSSL Error Handling
+
+%description devel
+The Globus Toolkit is an open source software toolkit used for building Grid
+systems and applications. It is being developed by the Globus Alliance and
+many others all over the world. A growing number of projects and companies are
+using the Globus Toolkit to unlock the potential of grids for their cause.
+
+The %{name}-devel package contains:
+Globus OpenSSL Error Handling Development Files
+
+%description doc
+The Globus Toolkit is an open source software toolkit used for building Grid
+systems and applications. It is being developed by the Globus Alliance and
+many others all over the world. A growing number of projects and companies are
+using the Globus Toolkit to unlock the potential of grids for their cause.
+
+The %{name}-doc package contains:
+Globus OpenSSL Error Handling Documentation Files
+
+%prep
+%setup -q -n %{_name}-%{version}
+
+# This is a workaround for the broken epstopdf script in RHEL5
+# See: https://bugzilla.redhat.com/show_bug.cgi?id=450388
+%if "%{rhel}" == "5"
+mkdir bin
+install %{SOURCE8} bin/epstopdf
+%endif
+
+%build
+%if "%{rhel}" == "5"
+export PATH=$PWD/bin:$PATH
+%endif
+
+rm -f doxygen/Doxyfile*
+rm -f doxygen/Makefile.am
+rm -f pkgdata/Makefile.am
+rm -f globus_automake*
+rm -rf autom4te.cache
+
+# Remove flavor tags
+for f in `find . -name Makefile.am` ; do
+  sed -e 's!^flavorinclude_HEADERS!include_HEADERS!' \
+      -e 's!\(lib[a-zA-Z_]*\)_$(GLOBUS_FLAVOR_NAME)\.la!\1.la!g' \
+      -e 's!^\(lib[a-zA-Z_]*\)___GLOBUS_FLAVOR_NAME__la_!\1_la_!' -i $f
+done
+sed -e "s! \
+  $RPM_BUILD_ROOT%{_libdir}/pkgconfig/%{name}.pc
+
+# Move documentation to default RPM location
+mv $RPM_BUILD_ROOT%{_docdir}/%{_name} \
+  $RPM_BUILD_ROOT%{_docdir}/%{name}-%{version}
+sed s!doc/%{_name}!doc/%{name}-%{version}! \
+  -i $RPM_BUILD_ROOT%{_datadir}/globus/packages/%{_name}/noflavor_doc.filelist
+
+# Remove unwanted documentation
+rm -f $RPM_BUILD_ROOT%{_mandir}/man3/deprecated.3
+rm -f $RPM_BUILD_ROOT%{_mandir}/man3/*_%{_name}-%{version}_*.3
+sed -e '/deprecated\.3/d' \
+    -e '/_%{_name}-%{version}_.*\.3/d' \
+  -i $RPM_BUILD_ROOT%{_datadir}/globus/packages/%{_name}/noflavor_doc.filelist
+
+# Generate package filelists
+cat $RPM_BUILD_ROOT%{_datadir}/globus/packages/%{_name}/%{flavor}_rtl.filelist \
+  | sed s!^!%{_prefix}! > package.filelist
+cat $RPM_BUILD_ROOT%{_datadir}/globus/packages/%{_name}/%{flavor}_dev.filelist \
+  | sed s!^!%{_prefix}! > package-devel.filelist
+cat $RPM_BUILD_ROOT%{_datadir}/globus/packages/%{_name}/noflavor_doc.filelist \
+  | sed -e 's!/man/.*!&*!' -e 's!^!%doc %{_prefix}!' > package-doc.filelist
+
+%clean
+rm -rf $RPM_BUILD_ROOT
+
+%post -p /sbin/ldconfig
+
+%postun -p /sbin/ldconfig
+
+%files -f package.filelist
+%defattr(-,root,root,-)
+%dir %{_datadir}/globus/packages/%{_name}
+
+%files -f package-devel.filelist devel
+%defattr(-,root,root,-)
+%{_libdir}/pkgconfig/%{name}.pc
+
+%files -f package-doc.filelist doc
+%defattr(-,root,root,-)
+%dir %{_docdir}/%{name}-%{version}
+%dir %{_docdir}/%{name}-%{version}/html
+
+%changelog
+* Wed Apr 15 2009 Mattias Ellert  - 0.14-1
+- Autogenerated
+

+
+=== Globus package that only provides programs ===
+
+
+./globus-spec.pl -g globus_proxy_utils-2.5/pkgdata/pkg_data_src.gpt.in -d gsi/proxy/proxy_utils/source %{name}-ldflag-overwrt.patch
+
+
+This example also illustrates that the names of patches can be listed as arguments to the script. For each patch listed on the command line the autogenerated specfile will contain a stub comment saying "INSERT PATCH DESCRIPTION HERE" and an incomplete reference to the upstream bugzilla where the bug number should be entered.
+
+
+%ifarch alpha ia64 ppc64 s390x sparc64 x86_64
+%global flavor gcc64pthr
+%else
+%global flavor gcc32pthr
+%endif
+
+Name:		globus-proxy-utils
+%global _name %(tr - _ <<< %{name})
+Version:	2.5
+Release:	1%{?dist}
+Summary:	Globus Toolkit - Globus GSI Proxy Utility Programs
+
+Group:		Applications/Internet
+License:	ASL 2.0
+URL:		http://www.globus.org/
+#		Source is extracted from the globus toolkit installer:
+#		wget -N http://www-unix.globus.org/ftppub/gt4/4.2.1/installers/src/gt4.2.1-all-source-installer.tar.bz2
+#		tar -jxf gt4.2.1-all-source-installer.tar.bz2
+#		mv gt4.2.1-all-source-installer/source-trees/gsi/proxy/proxy_utils/source globus_proxy_utils-2.5
+#		tar -zcf globus_proxy_utils-2.5.tar.gz globus_proxy_utils-2.5
+Source:	%{_name}-%{version}.tar.gz
+#		### INSERT PATCH DESCRIPTION HERE ###:
+#		http://bugzilla.globus.org/bugzilla/show_bug.cgi?id=###BUG NUMBER###
+Patch0:	%{name}-ldflag-overwrt.patch
+BuildRoot:	%{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
+
+Requires:	globus-openssl >= 1
+BuildRequires:	grid-packaging-tools
+BuildRequires:	globus-gsi-proxy-ssl-devel >= 1
+BuildRequires:	globus-gsi-credential-devel >= 1
+BuildRequires:	globus-gsi-callback-devel
+BuildRequires:	globus-openssl-module-devel
+BuildRequires:	globus-gss-assist-devel >= 3
+BuildRequires:	globus-gsi-openssl-error-devel
+BuildRequires:	globus-openssl-devel >= 1
+BuildRequires:	globus-gsi-proxy-core-devel >= 1
+BuildRequires:	globus-core >= 4
+BuildRequires:	globus-gsi-cert-utils-devel >= 1
+BuildRequires:	globus-common-devel >= 3
+BuildRequires:	globus-gsi-sysconfig-devel >= 1
+
+%description
+The Globus Toolkit is an open source software toolkit used for building Grid
+systems and applications. It is being developed by the Globus Alliance and
+many others all over the world. A growing number of projects and companies are
+using the Globus Toolkit to unlock the potential of grids for their cause.
+
+The %{name} package contains:
+Globus GSI Proxy Utility Programs
+
+%prep
+%setup -q -n %{_name}-%{version}
+%patch0 -p1
+
+%build
+rm -f doxygen/Doxyfile*
+rm -f doxygen/Makefile.am
+rm -f pkgdata/Makefile.am
+rm -f globus_automake*
+rm -rf autom4te.cache
+
+%{_datadir}/globus/globus-bootstrap.sh
+
+%configure --with-flavor=%{flavor}
+
+make %{?_smp_mflags}
+
+%install
+rm -rf $RPM_BUILD_ROOT
+make install DESTDIR=$RPM_BUILD_ROOT
+
+# Generate package filelists
+cat $RPM_BUILD_ROOT%{_datadir}/globus/packages/%{_name}/%{flavor}_pgm.filelist \
+  | sed s!^!%{_prefix}! > package.filelist
+
+%clean
+rm -rf $RPM_BUILD_ROOT
+
+%files -f package.filelist
+%defattr(-,root,root,-)
+%dir %{_datadir}/globus/packages/%{_name}
+
+%changelog
+* Thu Apr 16 2009 Mattias Ellert  - 2.5-1
+- Autogenerated
+

+
+=== Globus package containing a plugin ===
+
+
+./globus-spec.pl -g globus_xio_popen_driver-0.2/pkgdata/pkg_data_src.gpt.in -d xio/drivers/popen/source -n %{name}-wrong-dep.patch
+
+
+In this case the autogenerated specfile will instead of the commands for deleting the .la files contain a comment explaining why the .la files can not be removed. This example also shows the use of the -n option to disable the generation of a doc package for Globus packages that don't have any doxygen markup in the sources.
+
+
+%ifarch alpha ia64 ppc64 s390x sparc64 x86_64
+%global flavor gcc64pthr
+%else
+%global flavor gcc32pthr
+%endif
+
+Name:		globus-xio-popen-driver
+%global _name %(tr - _ <<< %{name})
+Version:	0.2
+Release:	1%{?dist}
+Summary:	Globus Toolkit - Globus XIO BW Limit Driver
+
+Group:		System Environment/Libraries
+License:	ASL 2.0
+URL:		http://www.globus.org/
+#		Source is extracted from the globus toolkit installer:
+#		wget -N http://www-unix.globus.org/ftppub/gt4/4.2.1/installers/src/gt4.2.1-all-source-installer.tar.bz2
+#		tar -jxf gt4.2.1-all-source-installer.tar.bz2
+#		mv gt4.2.1-all-source-installer/source-trees/xio/drivers/popen/source globus_xio_popen_driver-0.2
+#		tar -zcf globus_xio_popen_driver-0.2.tar.gz globus_xio_popen_driver-0.2
+Source:	%{_name}-%{version}.tar.gz
+#		### INSERT PATCH DESCRIPTION HERE ###:
+#		http://bugzilla.globus.org/bugzilla/show_bug.cgi?id=###BUG NUMBER###
+Patch0:	%{name}-wrong-dep.patch
+BuildRoot:	%{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
+
+BuildRequires:	grid-packaging-tools
+BuildRequires:	globus-xio-devel
+
+%package devel
+Summary:	Globus Toolkit - Globus XIO BW Limit Driver Development Files
+Group:		Development/Libraries
+Requires:	%{name} = %{version}-%{release}
+Requires:	globus-xio-devel
+
+%description
+The Globus Toolkit is an open source software toolkit used for building Grid
+systems and applications. It is being developed by the Globus Alliance and
+many others all over the world. A growing number of projects and companies are
+using the Globus Toolkit to unlock the potential of grids for their cause.
+
+The %{name} package contains:
+Globus XIO BW Limit Driver
+
+%description devel
+The Globus Toolkit is an open source software toolkit used for building Grid
+systems and applications. It is being developed by the Globus Alliance and
+many others all over the world. A growing number of projects and companies are
+using the Globus Toolkit to unlock the potential of grids for their cause.
+
+The %{name}-devel package contains:
+Globus XIO BW Limit Driver Development Files
+
+%prep
+%setup -q -n %{_name}-%{version}
+%patch0 -p1
+
+%build
+rm -f doxygen/Doxyfile*
+rm -f doxygen/Makefile.am
+rm -f pkgdata/Makefile.am
+rm -f globus_automake*
+rm -rf autom4te.cache
+
+# Remove flavor tags
+for f in `find . -name Makefile.am` ; do
+  sed -e 's!^flavorinclude_HEADERS!include_HEADERS!' \
+      -e 's!\(lib[a-zA-Z_]*\)_$(GLOBUS_FLAVOR_NAME)\.la!\1.la!g' \
+      -e 's!^\(lib[a-zA-Z_]*\)___GLOBUS_FLAVOR_NAME__la_!\1_la_!' -i $f
+done
+sed -e "s! \
+  $RPM_BUILD_ROOT%{_libdir}/pkgconfig/%{name}.pc
+
+# Generate package filelists
+cat $RPM_BUILD_ROOT%{_datadir}/globus/packages/%{_name}/%{flavor}_rtl.filelist \
+  | sed s!^!%{_prefix}! > package.filelist
+cat $RPM_BUILD_ROOT%{_datadir}/globus/packages/%{_name}/%{flavor}_dev.filelist \
+  | sed s!^!%{_prefix}! > package-devel.filelist
+
+%clean
+rm -rf $RPM_BUILD_ROOT
+
+%post -p /sbin/ldconfig
+
+%postun -p /sbin/ldconfig
+
+%files -f package.filelist
+%defattr(-,root,root,-)
+%dir %{_datadir}/globus/packages/%{_name}
+
+%files -f package-devel.filelist devel
+%defattr(-,root,root,-)
+%{_libdir}/pkgconfig/%{name}.pc
+
+%changelog
+* Thu Apr 16 2009 Mattias Ellert  - 0.2-1
+- Autogenerated
+

+
+=== Globus package that provides both a library and programs and that has a corresponding setup package ===
+
+
+./globus-spec.pl -g globus_common-10.2/pkgdata/pkg_data_src.gpt.in -s globus_common_setup-2.6/pkgdata/pkg_data_src.gpt.in -r 2 -d common/source
+
+
+* The -s option is used to indicate the GPT source package description file for the setup package
+* The -r option is used to set the release version of the specfile to 2 (default is 1, as in the previous examples)
+
+The patches have been excluded from this example to keep it short. For this package some additional editing is needed. Compare the autogenerated file below with the [http://cvs.fedoraproject.org/viewvc/devel/globus-common/globus-common.spec?view=markup specfile on the actual package] to see the differences.
+
+
+%ifarch alpha ia64 ppc64 s390x sparc64 x86_64
+%global flavor gcc64pthr
+%else
+%global flavor gcc32pthr
+%endif
+
+Name:		globus-common
+%global _name %(tr - _ <<< %{name})
+Version:	10.2
+%global setupversion 2.6
+Release:	2%{?dist}
+Summary:	Globus Toolkit - Common Library
+
+Group:		System Environment/Libraries
+License:	ASL 2.0
+URL:		http://www.globus.org/
+#		Source is extracted from the globus toolkit installer:
+#		wget -N http://www-unix.globus.org/ftppub/gt4/4.2.1/installers/src/gt4.2.1-all-source-installer.tar.bz2
+#		tar -jxf gt4.2.1-all-source-installer.tar.bz2
+#		mv gt4.2.1-all-source-installer/source-trees/common/source globus_common-10.2
+#		tar -zcf globus_common-10.2.tar.gz globus_common-10.2
+Source:	%{_name}-%{version}.tar.gz
+#		Source1 is extracted from the globus toolkit installer:
+#		wget -N http://www-unix.globus.org/ftppub/gt4/4.2.1/installers/src/gt4.2.1-all-source-installer.tar.bz2
+#		tar -jxf gt4.2.1-all-source-installer.tar.bz2
+#		mv gt4.2.1-all-source-installer/source-trees/common/setup globus_common_setup-2.6
+#		tar -zcf globus_common_setup-2.6.tar.gz globus_common_setup-2.6
+Source1:	%{_name}_setup-%{setupversion}.tar.gz
+Source8:	epstopdf-2.9.5gw
+BuildRoot:	%{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
+
+Requires:	globus-libtool >= 1
+BuildRequires:	grid-packaging-tools
+BuildRequires:	globus-libtool-devel >= 1
+BuildRequires:	globus-core >= 4
+BuildRequires:	doxygen
+%if %{?fedora}%{!?fedora:0} >= 3
+BuildRequires:	graphviz
+BuildRequires:	ghostscript
+%else
+%if %{?rhel}%{!?rhel:0} >= 5
+BuildRequires:	graphviz
+BuildRequires:	ghostscript
+%if "%{?rhel}" == "5"
+BuildRequires:	graphviz-gd
+%endif
+%endif
+%endif
+%if %{?fedora}%{!?fedora:0} >= 9
+BuildRequires:	tex(latex)
+%else
+%if %{?rhel}%{!?rhel:0} >= 6
+BuildRequires:	tex(latex)
+%else
+BuildRequires:	tetex-latex
+%endif
+%endif
+
+%package progs
+Summary:	Globus Toolkit - Common Library Programs
+Group:		Applications/Internet
+Provides:	%{name}-setup = %{setupversion}
+Requires:	%{name} = %{version}-%{release}
+Requires:	globus-libtool >= 1
+Requires:	globus-common-progs >= 3
+Requires:	globus-common-setup >= 2
+
+%package devel
+Summary:	Globus Toolkit - Common Library Development Files
+Group:		Development/Libraries
+Requires:	%{name} = %{version}-%{release}
+Requires:	globus-libtool-devel >= 1
+Requires:	globus-core >= 4
+
+%package doc
+Summary:	Globus Toolkit - Common Library Documentation Files
+Group:		Documentation
+Requires:	%{name} = %{version}-%{release}
+
+%description
+The Globus Toolkit is an open source software toolkit used for building Grid
+systems and applications. It is being developed by the Globus Alliance and
+many others all over the world. A growing number of projects and companies are
+using the Globus Toolkit to unlock the potential of grids for their cause.
+
+The %{name} package contains:
+Common Library
+
+%description progs
+The Globus Toolkit is an open source software toolkit used for building Grid
+systems and applications. It is being developed by the Globus Alliance and
+many others all over the world. A growing number of projects and companies are
+using the Globus Toolkit to unlock the potential of grids for their cause.
+
+The %{name}-progs package contains:
+Common Library Programs
+Common Setup
+
+%description devel
+The Globus Toolkit is an open source software toolkit used for building Grid
+systems and applications. It is being developed by the Globus Alliance and
+many others all over the world. A growing number of projects and companies are
+using the Globus Toolkit to unlock the potential of grids for their cause.
+
+The %{name}-devel package contains:
+Common Library Development Files
+
+%description doc
+The Globus Toolkit is an open source software toolkit used for building Grid
+systems and applications. It is being developed by the Globus Alliance and
+many others all over the world. A growing number of projects and companies are
+using the Globus Toolkit to unlock the potential of grids for their cause.
+
+The %{name}-doc package contains:
+Common Library Documentation Files
+
+%prep
+%setup -q -n %{_name}-%{version}
+%setup -D -T -q -n %{_name}-%{version} -a 1
+
+# This is a workaround for the broken epstopdf script in RHEL5
+# See: https://bugzilla.redhat.com/show_bug.cgi?id=450388
+%if "%{rhel}" == "5"
+mkdir bin
+install %{SOURCE8} bin/epstopdf
+%endif
+
+%build
+%if "%{rhel}" == "5"
+export PATH=$PWD/bin:$PATH
+%endif
+
+rm -f doxygen/Doxyfile*
+rm -f doxygen/Makefile.am
+rm -f pkgdata/Makefile.am
+rm -f globus_automake*
+rm -rf autom4te.cache
+
+# Remove flavor tags
+for f in `find . -name Makefile.am` ; do
+  sed -e 's!^flavorinclude_HEADERS!include_HEADERS!' \
+      -e 's!\(lib[a-zA-Z_]*\)_$(GLOBUS_FLAVOR_NAME)\.la!\1.la!g' \
+      -e 's!^\(lib[a-zA-Z_]*\)___GLOBUS_FLAVOR_NAME__la_!\1_la_!' -i $f
+done
+sed -e "s! "%{_name}_setup",
+				     globusdir => "$RPM_BUILD_ROOT%{_prefix}");
+\$metadata->finish();
+EOF
+
+# Create setup files
+
+### INSERT RELEVANT PARTS OF setup-globus-common HERE ###
+
+# Remove libtool archives (.la files)
+find $RPM_BUILD_ROOT%{_libdir} -name 'lib*.la' -exec rm -v '{}' \;
+sed '/lib.*\.la$/d' \
+  -i $RPM_BUILD_ROOT%{_datadir}/globus/packages/%{_name}/%{flavor}_rtl.filelist
+
+# Remove static libraries (.a files)
+find $RPM_BUILD_ROOT%{_libdir} -name 'lib*.a' -exec rm -v '{}' \;
+sed '/lib.*\.a$/d' \
+  -i $RPM_BUILD_ROOT%{_datadir}/globus/packages/%{_name}/%{flavor}_dev.filelist
+
+# Generate pkg-config file from GPT metadata
+mkdir -p $RPM_BUILD_ROOT%{_libdir}/pkgconfig
+%{_datadir}/globus/globus-gpt2pkg-config pkgdata/pkg_data_%{flavor}_dev.gpt > \
+  $RPM_BUILD_ROOT%{_libdir}/pkgconfig/%{name}.pc
+
+# Move documentation to default RPM location
+mv $RPM_BUILD_ROOT%{_docdir}/%{_name} \
+  $RPM_BUILD_ROOT%{_docdir}/%{name}-%{version}
+sed s!doc/%{_name}!doc/%{name}-%{version}! \
+  -i $RPM_BUILD_ROOT%{_datadir}/globus/packages/%{_name}/noflavor_doc.filelist
+
+# Remove unwanted documentation
+rm -f $RPM_BUILD_ROOT%{_mandir}/man3/deprecated.3
+rm -f $RPM_BUILD_ROOT%{_mandir}/man3/*_%{_name}-%{version}_*.3
+sed -e '/deprecated\.3/d' \
+    -e '/_%{_name}-%{version}_.*\.3/d' \
+  -i $RPM_BUILD_ROOT%{_datadir}/globus/packages/%{_name}/noflavor_doc.filelist
+
+# Generate package filelists
+cat $RPM_BUILD_ROOT%{_datadir}/globus/packages/%{_name}/%{flavor}_rtl.filelist \
+  | sed s!^!%{_prefix}! > package.filelist
+cat $RPM_BUILD_ROOT%{_datadir}/globus/packages/%{_name}/%{flavor}_pgm.filelist \
+    $RPM_BUILD_ROOT%{_datadir}/globus/packages/%{_name}_setup/noflavor_pgm.filelist \
+  | sed s!^!%{_prefix}! > package-progs.filelist
+cat $RPM_BUILD_ROOT%{_datadir}/globus/packages/%{_name}/%{flavor}_dev.filelist \
+  | sed s!^!%{_prefix}! > package-devel.filelist
+cat $RPM_BUILD_ROOT%{_datadir}/globus/packages/%{_name}/noflavor_doc.filelist \
+  | sed -e 's!/man/.*!&*!' -e 's!^!%doc %{_prefix}!' > package-doc.filelist
+
+%clean
+rm -rf $RPM_BUILD_ROOT
+
+%post -p /sbin/ldconfig
+
+%postun -p /sbin/ldconfig
+
+%files -f package.filelist
+%defattr(-,root,root,-)
+%dir %{_datadir}/globus/packages/%{_name}
+
+%files -f package-progs.filelist progs
+%defattr(-,root,root,-)
+%dir %{_datadir}/globus/packages/%{_name}_setup
+%{_datadir}/globus/packages/setup
+%dir %{_datadir}/globus/setup
+
+%files -f package-devel.filelist devel
+%defattr(-,root,root,-)
+%{_libdir}/pkgconfig/%{name}.pc
+
+%files -f package-doc.filelist doc
+%defattr(-,root,root,-)
+%dir %{_docdir}/%{name}-%{version}
+%dir %{_docdir}/%{name}-%{version}/html
+
+%changelog
+* Thu Apr 16 2009 Mattias Ellert  - 10.2-2
+- Autogenerated
+


From 26186af3f54bcb93df1c759e0110ae6996198cbc Mon Sep 17 00:00:00 2001
From: Ellert 
Date: Apr 16 2009 17:57:03 +0000
Subject: [PATCH 289/3559] Minor tweaks to the example descriptions


---

diff --git a/Packaging:Globus.mw b/Packaging:Globus.mw
index 790b58a..393de88 100644
--- a/Packaging:Globus.mw
+++ b/Packaging:Globus.mw
@@ -111,7 +111,7 @@ It is possible to autogenerate an initial version of the specfile from the infor
 
 
 * The -g option specifies the GPT source package description file
-* The -d option specifies the directory in the installer from where the code was extracted.
+* The -d option specifies the directory in the installer from where the code was extracted
 * The -e option can be used to specify the packager's e-mail address (defaults to username@host)
 
 
@@ -135,7 +135,7 @@ URL:		http://www.globus.org/
 #		tar -jxf gt4.2.1-all-source-installer.tar.bz2
 #		mv gt4.2.1-all-source-installer/source-trees/gsi/openssl_error/source globus_gsi_openssl_error-0.14
 #		tar -zcf globus_gsi_openssl_error-0.14.tar.gz globus_gsi_openssl_error-0.14
-Source:	%{_name}-%{version}.tar.gz
+Source: 	%{_name}-%{version}.tar.gz
 Source8:	epstopdf-2.9.5gw
 BuildRoot:	%{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
 
@@ -315,11 +315,9 @@ rm -rf $RPM_BUILD_ROOT
 === Globus package that only provides programs ===
 
 
-./globus-spec.pl -g globus_proxy_utils-2.5/pkgdata/pkg_data_src.gpt.in -d gsi/proxy/proxy_utils/source %{name}-ldflag-overwrt.patch
+./globus-spec.pl -g globus_proxy_utils-2.5/pkgdata/pkg_data_src.gpt.in -d gsi/proxy/proxy_utils/source
 
 
-This example also illustrates that the names of patches can be listed as arguments to the script. For each patch listed on the command line the autogenerated specfile will contain a stub comment saying "INSERT PATCH DESCRIPTION HERE" and an incomplete reference to the upstream bugzilla where the bug number should be entered.
-
 
 %ifarch alpha ia64 ppc64 s390x sparc64 x86_64
 %global flavor gcc64pthr
@@ -341,10 +339,7 @@ URL:		http://www.globus.org/
 #		tar -jxf gt4.2.1-all-source-installer.tar.bz2
 #		mv gt4.2.1-all-source-installer/source-trees/gsi/proxy/proxy_utils/source globus_proxy_utils-2.5
 #		tar -zcf globus_proxy_utils-2.5.tar.gz globus_proxy_utils-2.5
-Source:	%{_name}-%{version}.tar.gz
-#		### INSERT PATCH DESCRIPTION HERE ###:
-#		http://bugzilla.globus.org/bugzilla/show_bug.cgi?id=###BUG NUMBER###
-Patch0:	%{name}-ldflag-overwrt.patch
+Source: 	%{_name}-%{version}.tar.gz
 BuildRoot:	%{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
 
 Requires:	globus-openssl >= 1
@@ -373,7 +368,6 @@ Globus GSI Proxy Utility Programs
 
 %prep
 %setup -q -n %{_name}-%{version}
-%patch0 -p1
 
 %build
 rm -f doxygen/Doxyfile*
@@ -414,7 +408,11 @@ rm -rf $RPM_BUILD_ROOT
 ./globus-spec.pl -g globus_xio_popen_driver-0.2/pkgdata/pkg_data_src.gpt.in -d xio/drivers/popen/source -n %{name}-wrong-dep.patch
 
 
-In this case the autogenerated specfile will instead of the commands for deleting the .la files contain a comment explaining why the .la files can not be removed. This example also shows the use of the -n option to disable the generation of a doc package for Globus packages that don't have any doxygen markup in the sources.
+* The -n option can be used to disable the generation of a doc package for Globus packages that don't have any doxygen markup in the sources.
+
+In this case the autogenerated specfile will instead of the commands for deleting the .la files contain a comment explaining why the .la files can not be removed.
+
+This example also illustrates that the names of patches can be listed as arguments to the script. For each patch listed on the command line the autogenerated specfile will contain a stub comment saying "INSERT PATCH DESCRIPTION HERE" and an incomplete reference to the upstream bugzilla where the bug number should be entered.
 
 
 %ifarch alpha ia64 ppc64 s390x sparc64 x86_64
@@ -437,10 +435,10 @@ URL:		http://www.globus.org/
 #		tar -jxf gt4.2.1-all-source-installer.tar.bz2
 #		mv gt4.2.1-all-source-installer/source-trees/xio/drivers/popen/source globus_xio_popen_driver-0.2
 #		tar -zcf globus_xio_popen_driver-0.2.tar.gz globus_xio_popen_driver-0.2
-Source:	%{_name}-%{version}.tar.gz
+Source: 	%{_name}-%{version}.tar.gz
 #		### INSERT PATCH DESCRIPTION HERE ###:
 #		http://bugzilla.globus.org/bugzilla/show_bug.cgi?id=###BUG NUMBER###
-Patch0:	%{name}-wrong-dep.patch
+Patch0: 	%{name}-wrong-dep.patch
 BuildRoot:	%{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
 
 BuildRequires:	grid-packaging-tools
@@ -551,7 +549,7 @@ rm -rf $RPM_BUILD_ROOT
 * The -s option is used to indicate the GPT source package description file for the setup package
 * The -r option is used to set the release version of the specfile to 2 (default is 1, as in the previous examples)
 
-The patches have been excluded from this example to keep it short. For this package some additional editing is needed. Compare the autogenerated file below with the [http://cvs.fedoraproject.org/viewvc/devel/globus-common/globus-common.spec?view=markup specfile on the actual package] to see the differences.
+The patches have been excluded from this example to keep it short. For this package some additional editing is needed. Compare the autogenerated file below with the [http://cvs.fedoraproject.org/viewvc/devel/globus-common/globus-common.spec?view=markup specfile in the actual package] to see the differences.
 
 
 %ifarch alpha ia64 ppc64 s390x sparc64 x86_64
@@ -575,7 +573,7 @@ URL:		http://www.globus.org/
 #		tar -jxf gt4.2.1-all-source-installer.tar.bz2
 #		mv gt4.2.1-all-source-installer/source-trees/common/source globus_common-10.2
 #		tar -zcf globus_common-10.2.tar.gz globus_common-10.2
-Source:	%{_name}-%{version}.tar.gz
+Source: 	%{_name}-%{version}.tar.gz
 #		Source1 is extracted from the globus toolkit installer:
 #		wget -N http://www-unix.globus.org/ftppub/gt4/4.2.1/installers/src/gt4.2.1-all-source-installer.tar.bz2
 #		tar -jxf gt4.2.1-all-source-installer.tar.bz2

From b4f9cc5b012bfe87b7df74c60498a27570c5c9c1 Mon Sep 17 00:00:00 2001
From: Ellert 
Date: Apr 17 2009 11:33:23 +0000
Subject: [PATCH 290/3559] Updated examples after review feedback


---

diff --git a/Packaging:Globus.mw b/Packaging:Globus.mw
index 393de88..ea81ab0 100644
--- a/Packaging:Globus.mw
+++ b/Packaging:Globus.mw
@@ -11,12 +11,12 @@ The Globus Toolkit is a set of libraries and tools used as building blocks for g
 The sources for the Globus Toolkit are distributed as one big installer tarball that contain the sources for more than 300 packages. Since including this huge tarball in every Globus source RPM and use less than 1% of it to compile a single Globus package would be extremely wasteful in terms of diskspace and bandwidth, the relevant subdirectory from the installer tarball must be extracted and repackaged for each package. This must be documented using comments in the spec file according to the [[Packaging:SourceURL]] guidelines so that the source tarball can be reproduced, as in the following example:
 
 
-#               Source is extracted from the globus toolkit installer:
-#               wget -N http://www-unix.globus.org/ftppub/gt4/4.2.1/installers/src/gt4.2.1-all-source-installer.tar.bz2
-#               tar -jxf gt4.2.1-all-source-installer.tar.bz2
-#               mv gt4.2.1-all-source-installer/source-trees/core/source globus_core-5.15
-#               tar -zcf globus_core-5.15.tar.gz globus_core-5.15
-Source:         %{_name}-%{version}.tar.gz
+#		Source is extracted from the globus toolkit installer:
+#		wget -N http://www-unix.globus.org/ftppub/gt4/4.2.1/installers/src/gt4.2.1-all-source-installer.tar.bz2
+#		tar -jxf gt4.2.1-all-source-installer.tar.bz2
+#		mv gt4.2.1-all-source-installer/source-trees/core/source globus_core-5.15
+#		tar -zcf globus_core-5.15.tar.gz globus_core-5.15
+Source: 	%{_name}-%{version}.tar.gz
 

 
 === Off-release upstream updates ===
@@ -24,7 +24,7 @@ Source:         %{_name}-%{version}.tar.gz
 Occasionally the Globus Alliance publishes an off-release update of a package. For these updates each updated package is available as a separate tarball, and the repackaging discribed above should not be done:
 
 
-Source:         http://www-unix.globus.org/ftppub/gt4/4.2.1/updates/src/%{_name}-%{version}.tar.gz
+Source: 	http://www-unix.globus.org/ftppub/gt4/4.2.1/updates/src/%{_name}-%{version}.tar.gz
 

 
 In order to keep the packaging consistent, the naming of the tarfiles extracted from the installer should use the same naming convention as upstream uses for the tarfiles for these updates, i.e. the upstream package name and version.
@@ -56,17 +56,17 @@ GPT has its own packaging mechanism, and automatically distributes the installed
 
 For a globus package that provides libraries the mapping between GPT and RPM packages is as follows:
 
-* %{flavor}_rtl.gpt → main package
-* %{flavor}_dev.gpt → -devel package
-* noflavor_doc.gpt → -doc package
+*%{flavor}_rtl.gpt → main package
+*%{flavor}_dev.gpt → -devel package
+*noflavor_doc.gpt → -doc package
 
 And if the package provides programs as well as libraries:
 
-* %{flavor}_pgm.gpt → -progs package
+*%{flavor}_pgm.gpt → -progs package
 
 For a globus package that provides only programs the mapping is as follows:
 
-* %{flavor}_pgm.gpt → main package
+*%{flavor}_pgm.gpt → main package
 
 == GPT metadata files ==
 
@@ -136,6 +136,8 @@ URL:		http://www.globus.org/
 #		mv gt4.2.1-all-source-installer/source-trees/gsi/openssl_error/source globus_gsi_openssl_error-0.14
 #		tar -zcf globus_gsi_openssl_error-0.14.tar.gz globus_gsi_openssl_error-0.14
 Source: 	%{_name}-%{version}.tar.gz
+#		This is a workaround for the broken epstopdf script in RHEL5
+#		See: https://bugzilla.redhat.com/show_bug.cgi?id=450388
 Source8:	epstopdf-2.9.5gw
 BuildRoot:	%{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
 
@@ -210,8 +212,6 @@ Globus OpenSSL Error Handling Documentation Files
 %prep
 %setup -q -n %{_name}-%{version}
 
-# This is a workaround for the broken epstopdf script in RHEL5
-# See: https://bugzilla.redhat.com/show_bug.cgi?id=450388
 %if "%{rhel}" == "5"
 mkdir bin
 install %{SOURCE8} bin/epstopdf
@@ -222,6 +222,7 @@ install %{SOURCE8} bin/epstopdf
 export PATH=$PWD/bin:$PATH
 %endif
 
+# Remove files that should be replaced during bootstrap
 rm -f doxygen/Doxyfile*
 rm -f doxygen/Makefile.am
 rm -f pkgdata/Makefile.am
@@ -370,6 +371,7 @@ Globus GSI Proxy Utility Programs
 %setup -q -n %{_name}-%{version}
 
 %build
+# Remove files that should be replaced during bootstrap
 rm -f doxygen/Doxyfile*
 rm -f doxygen/Makefile.am
 rm -f pkgdata/Makefile.am
@@ -473,6 +475,7 @@ Globus XIO BW Limit Driver Development Files
 %patch0 -p1
 
 %build
+# Remove files that should be replaced during bootstrap
 rm -f doxygen/Doxyfile*
 rm -f doxygen/Makefile.am
 rm -f pkgdata/Makefile.am
@@ -580,6 +583,8 @@ Source: 	%{_name}-%{version}.tar.gz
 #		mv gt4.2.1-all-source-installer/source-trees/common/setup globus_common_setup-2.6
 #		tar -zcf globus_common_setup-2.6.tar.gz globus_common_setup-2.6
 Source1:	%{_name}_setup-%{setupversion}.tar.gz
+#		This is a workaround for the broken epstopdf script in RHEL5
+#		See: https://bugzilla.redhat.com/show_bug.cgi?id=450388
 Source8:	epstopdf-2.9.5gw
 BuildRoot:	%{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
 
@@ -672,8 +677,6 @@ Common Library Documentation Files
 %setup -q -n %{_name}-%{version}
 %setup -D -T -q -n %{_name}-%{version} -a 1
 
-# This is a workaround for the broken epstopdf script in RHEL5
-# See: https://bugzilla.redhat.com/show_bug.cgi?id=450388
 %if "%{rhel}" == "5"
 mkdir bin
 install %{SOURCE8} bin/epstopdf
@@ -684,6 +687,7 @@ install %{SOURCE8} bin/epstopdf
 export PATH=$PWD/bin:$PATH
 %endif
 
+# Remove files that should be replaced during bootstrap
 rm -f doxygen/Doxyfile*
 rm -f doxygen/Makefile.am
 rm -f pkgdata/Makefile.am
@@ -708,6 +712,7 @@ make %{?_smp_mflags}
 # setup package
 cd %{_name}_setup-%{setupversion}
 
+# Remove files that should be replaced during bootstrap
 rm -f doxygen/Doxyfile*
 rm -f doxygen/Makefile.am
 rm -f pkgdata/Makefile.am

From 099d668f92592542e0d9bdb04d8fef7366810319 Mon Sep 17 00:00:00 2001
From: Ellert 
Date: Apr 18 2009 05:24:47 +0000
Subject: [PATCH 291/3559] Add Requires to example for directory ownership


---

diff --git a/Packaging:Globus.mw b/Packaging:Globus.mw
index ea81ab0..a342031 100644
--- a/Packaging:Globus.mw
+++ b/Packaging:Globus.mw
@@ -443,6 +443,7 @@ Source: 	%{_name}-%{version}.tar.gz
 Patch0: 	%{name}-wrong-dep.patch
 BuildRoot:	%{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
 
+Requires:	globus-common
 BuildRequires:	grid-packaging-tools
 BuildRequires:	globus-xio-devel
 

From 7f57b8a72abae5bca7c20525432bc987e49bacc3 Mon Sep 17 00:00:00 2001
From: Ellert 
Date: Apr 22 2009 10:56:52 +0000
Subject: [PATCH 292/3559] Update source retrieval instructions and examples to reflect the concensus on the fedora-packaging mailing list


---

diff --git a/Packaging:Globus.mw b/Packaging:Globus.mw
index a342031..349893e 100644
--- a/Packaging:Globus.mw
+++ b/Packaging:Globus.mw
@@ -8,14 +8,15 @@ The Globus Toolkit is a set of libraries and tools used as building blocks for g
 
 == Obtaining sources ==
 
-The sources for the Globus Toolkit are distributed as one big installer tarball that contain the sources for more than 300 packages. Since including this huge tarball in every Globus source RPM and use less than 1% of it to compile a single Globus package would be extremely wasteful in terms of diskspace and bandwidth, the relevant subdirectory from the installer tarball must be extracted and repackaged for each package. This must be documented using comments in the spec file according to the [[Packaging:SourceURL]] guidelines so that the source tarball can be reproduced, as in the following example:
+The sources for the Globus Toolkit are distributed as one big installer tarball that contain the sources for more than 300 packages. Since including this huge tarball in every Globus source RPM and use less than 1% of it to compile a single Globus package would be extremely wasteful in terms of diskspace and bandwidth, the relevant subdirectory from the installer tarball must be extracted and repackaged for each package. The GLOBUS_LICENSE file must also be copied into the extracted source tree since it is part of the upstream installer. This must be documented using comments in the spec file according to the [[Packaging:SourceURL]] guidelines so that the source tarball can be reproduced, as in the following example:
 
 
 #		Source is extracted from the globus toolkit installer:
 #		wget -N http://www-unix.globus.org/ftppub/gt4/4.2.1/installers/src/gt4.2.1-all-source-installer.tar.bz2
 #		tar -jxf gt4.2.1-all-source-installer.tar.bz2
-#		mv gt4.2.1-all-source-installer/source-trees/core/source globus_core-5.15
-#		tar -zcf globus_core-5.15.tar.gz globus_core-5.15
+#		mv gt4.2.1-all-source-installer/source-trees/common/source globus_common-10.2
+#		cp -p gt4.2.1-all-source-installer/source-trees/core/source/GLOBUS_LICENSE globus_common-10.2
+#		tar -zcf globus_common-10.2.tar.gz globus_common-10.2
 Source: 	%{_name}-%{version}.tar.gz
 

 
@@ -134,11 +135,12 @@ URL:		http://www.globus.org/
 #		wget -N http://www-unix.globus.org/ftppub/gt4/4.2.1/installers/src/gt4.2.1-all-source-installer.tar.bz2
 #		tar -jxf gt4.2.1-all-source-installer.tar.bz2
 #		mv gt4.2.1-all-source-installer/source-trees/gsi/openssl_error/source globus_gsi_openssl_error-0.14
+#		cp -p gt4.2.1-all-source-installer/source-trees/core/source/GLOBUS_LICENSE globus_gsi_openssl_error-0.14
 #		tar -zcf globus_gsi_openssl_error-0.14.tar.gz globus_gsi_openssl_error-0.14
 Source: 	%{_name}-%{version}.tar.gz
 #		This is a workaround for the broken epstopdf script in RHEL5
 #		See: https://bugzilla.redhat.com/show_bug.cgi?id=450388
-Source8:	epstopdf-2.9.5gw
+Source9:	epstopdf-2.9.5gw
 BuildRoot:	%{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
 
 Requires:	globus-openssl >= 1
@@ -214,7 +216,7 @@ Globus OpenSSL Error Handling Documentation Files
 
 %if "%{rhel}" == "5"
 mkdir bin
-install %{SOURCE8} bin/epstopdf
+install %{SOURCE9} bin/epstopdf
 %endif
 
 %build
@@ -280,6 +282,10 @@ sed -e '/deprecated\.3/d' \
     -e '/_%{_name}-%{version}_.*\.3/d' \
   -i $RPM_BUILD_ROOT%{_datadir}/globus/packages/%{_name}/noflavor_doc.filelist
 
+# Install license file
+mkdir -p $RPM_BUILD_ROOT%{_docdir}/%{name}-%{version}
+install -m 644 -p GLOBUS_LICENSE $RPM_BUILD_ROOT%{_docdir}/%{name}-%{version}
+
 # Generate package filelists
 cat $RPM_BUILD_ROOT%{_datadir}/globus/packages/%{_name}/%{flavor}_rtl.filelist \
   | sed s!^!%{_prefix}! > package.filelist
@@ -298,6 +304,8 @@ rm -rf $RPM_BUILD_ROOT
 %files -f package.filelist
 %defattr(-,root,root,-)
 %dir %{_datadir}/globus/packages/%{_name}
+%dir %{_docdir}/%{name}-%{version}
+%doc %{_docdir}/%{name}-%{version}/GLOBUS_LICENSE
 
 %files -f package-devel.filelist devel
 %defattr(-,root,root,-)
@@ -305,7 +313,6 @@ rm -rf $RPM_BUILD_ROOT
 
 %files -f package-doc.filelist doc
 %defattr(-,root,root,-)
-%dir %{_docdir}/%{name}-%{version}
 %dir %{_docdir}/%{name}-%{version}/html
 
 %changelog
@@ -339,6 +346,7 @@ URL:		http://www.globus.org/
 #		wget -N http://www-unix.globus.org/ftppub/gt4/4.2.1/installers/src/gt4.2.1-all-source-installer.tar.bz2
 #		tar -jxf gt4.2.1-all-source-installer.tar.bz2
 #		mv gt4.2.1-all-source-installer/source-trees/gsi/proxy/proxy_utils/source globus_proxy_utils-2.5
+#		cp -p gt4.2.1-all-source-installer/source-trees/core/source/GLOBUS_LICENSE globus_proxy_utils-2.5
 #		tar -zcf globus_proxy_utils-2.5.tar.gz globus_proxy_utils-2.5
 Source: 	%{_name}-%{version}.tar.gz
 BuildRoot:	%{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
@@ -388,6 +396,10 @@ make %{?_smp_mflags}
 rm -rf $RPM_BUILD_ROOT
 make install DESTDIR=$RPM_BUILD_ROOT
 
+# Install license file
+mkdir -p $RPM_BUILD_ROOT%{_docdir}/%{name}-%{version}
+install -m 644 -p GLOBUS_LICENSE $RPM_BUILD_ROOT%{_docdir}/%{name}-%{version}
+
 # Generate package filelists
 cat $RPM_BUILD_ROOT%{_datadir}/globus/packages/%{_name}/%{flavor}_pgm.filelist \
   | sed s!^!%{_prefix}! > package.filelist
@@ -398,6 +410,8 @@ rm -rf $RPM_BUILD_ROOT
 %files -f package.filelist
 %defattr(-,root,root,-)
 %dir %{_datadir}/globus/packages/%{_name}
+%dir %{_docdir}/%{name}-%{version}
+%doc %{_docdir}/%{name}-%{version}/GLOBUS_LICENSE
 
 %changelog
 * Thu Apr 16 2009 Mattias Ellert  - 2.5-1
@@ -436,6 +450,7 @@ URL:		http://www.globus.org/
 #		wget -N http://www-unix.globus.org/ftppub/gt4/4.2.1/installers/src/gt4.2.1-all-source-installer.tar.bz2
 #		tar -jxf gt4.2.1-all-source-installer.tar.bz2
 #		mv gt4.2.1-all-source-installer/source-trees/xio/drivers/popen/source globus_xio_popen_driver-0.2
+#		cp -p gt4.2.1-all-source-installer/source-trees/core/source/GLOBUS_LICENSE globus_xio_popen_driver-0.2
 #		tar -zcf globus_xio_popen_driver-0.2.tar.gz globus_xio_popen_driver-0.2
 Source: 	%{_name}-%{version}.tar.gz
 #		### INSERT PATCH DESCRIPTION HERE ###:
@@ -518,6 +533,10 @@ mkdir -p $RPM_BUILD_ROOT%{_libdir}/pkgconfig
 %{_datadir}/globus/globus-gpt2pkg-config pkgdata/pkg_data_%{flavor}_dev.gpt > \
   $RPM_BUILD_ROOT%{_libdir}/pkgconfig/%{name}.pc
 
+# Install license file
+mkdir -p $RPM_BUILD_ROOT%{_docdir}/%{name}-%{version}
+install -m 644 -p GLOBUS_LICENSE $RPM_BUILD_ROOT%{_docdir}/%{name}-%{version}
+
 # Generate package filelists
 cat $RPM_BUILD_ROOT%{_datadir}/globus/packages/%{_name}/%{flavor}_rtl.filelist \
   | sed s!^!%{_prefix}! > package.filelist
@@ -534,6 +553,8 @@ rm -rf $RPM_BUILD_ROOT
 %files -f package.filelist
 %defattr(-,root,root,-)
 %dir %{_datadir}/globus/packages/%{_name}
+%dir %{_docdir}/%{name}-%{version}
+%doc %{_docdir}/%{name}-%{version}/GLOBUS_LICENSE
 
 %files -f package-devel.filelist devel
 %defattr(-,root,root,-)
@@ -547,11 +568,11 @@ rm -rf $RPM_BUILD_ROOT
 === Globus package that provides both a library and programs and that has a corresponding setup package ===
 
 
-./globus-spec.pl -g globus_common-10.2/pkgdata/pkg_data_src.gpt.in -s globus_common_setup-2.6/pkgdata/pkg_data_src.gpt.in -r 2 -d common/source
+./globus-spec.pl -g globus_common-10.2/pkgdata/pkg_data_src.gpt.in -s globus_common_setup-2.6/pkgdata/pkg_data_src.gpt.in -r 3 -d common/source
 
 
 * The -s option is used to indicate the GPT source package description file for the setup package
-* The -r option is used to set the release version of the specfile to 2 (default is 1, as in the previous examples)
+* The -r option is used to set the release version of the specfile to 3 (default is 1, as in the previous examples)
 
 The patches have been excluded from this example to keep it short. For this package some additional editing is needed. Compare the autogenerated file below with the [http://cvs.fedoraproject.org/viewvc/devel/globus-common/globus-common.spec?view=markup specfile in the actual package] to see the differences.
 
@@ -566,7 +587,7 @@ Name:		globus-common
 %global _name %(tr - _ <<< %{name})
 Version:	10.2
 %global setupversion 2.6
-Release:	2%{?dist}
+Release:	3%{?dist}
 Summary:	Globus Toolkit - Common Library
 
 Group:		System Environment/Libraries
@@ -576,17 +597,19 @@ URL:		http://www.globus.org/
 #		wget -N http://www-unix.globus.org/ftppub/gt4/4.2.1/installers/src/gt4.2.1-all-source-installer.tar.bz2
 #		tar -jxf gt4.2.1-all-source-installer.tar.bz2
 #		mv gt4.2.1-all-source-installer/source-trees/common/source globus_common-10.2
+#		cp -p gt4.2.1-all-source-installer/source-trees/core/source/GLOBUS_LICENSE globus_common-10.2
 #		tar -zcf globus_common-10.2.tar.gz globus_common-10.2
 Source: 	%{_name}-%{version}.tar.gz
 #		Source1 is extracted from the globus toolkit installer:
 #		wget -N http://www-unix.globus.org/ftppub/gt4/4.2.1/installers/src/gt4.2.1-all-source-installer.tar.bz2
 #		tar -jxf gt4.2.1-all-source-installer.tar.bz2
 #		mv gt4.2.1-all-source-installer/source-trees/common/setup globus_common_setup-2.6
+#		cp -p gt4.2.1-all-source-installer/source-trees/core/source/GLOBUS_LICENSE globus_common_setup-2.6
 #		tar -zcf globus_common_setup-2.6.tar.gz globus_common_setup-2.6
 Source1:	%{_name}_setup-%{setupversion}.tar.gz
 #		This is a workaround for the broken epstopdf script in RHEL5
 #		See: https://bugzilla.redhat.com/show_bug.cgi?id=450388
-Source8:	epstopdf-2.9.5gw
+Source9:	epstopdf-2.9.5gw
 BuildRoot:	%{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
 
 Requires:	globus-libtool >= 1
@@ -680,7 +703,7 @@ Common Library Documentation Files
 
 %if "%{rhel}" == "5"
 mkdir bin
-install %{SOURCE8} bin/epstopdf
+install %{SOURCE9} bin/epstopdf
 %endif
 
 %build
@@ -780,6 +803,10 @@ sed -e '/deprecated\.3/d' \
     -e '/_%{_name}-%{version}_.*\.3/d' \
   -i $RPM_BUILD_ROOT%{_datadir}/globus/packages/%{_name}/noflavor_doc.filelist
 
+# Install license file
+mkdir -p $RPM_BUILD_ROOT%{_docdir}/%{name}-%{version}
+install -m 644 -p GLOBUS_LICENSE $RPM_BUILD_ROOT%{_docdir}/%{name}-%{version}
+
 # Generate package filelists
 cat $RPM_BUILD_ROOT%{_datadir}/globus/packages/%{_name}/%{flavor}_rtl.filelist \
   | sed s!^!%{_prefix}! > package.filelist
@@ -801,6 +828,8 @@ rm -rf $RPM_BUILD_ROOT
 %files -f package.filelist
 %defattr(-,root,root,-)
 %dir %{_datadir}/globus/packages/%{_name}
+%dir %{_docdir}/%{name}-%{version}
+%doc %{_docdir}/%{name}-%{version}/GLOBUS_LICENSE
 
 %files -f package-progs.filelist progs
 %defattr(-,root,root,-)
@@ -814,10 +843,9 @@ rm -rf $RPM_BUILD_ROOT
 
 %files -f package-doc.filelist doc
 %defattr(-,root,root,-)
-%dir %{_docdir}/%{name}-%{version}
 %dir %{_docdir}/%{name}-%{version}/html
 
 %changelog
-* Thu Apr 16 2009 Mattias Ellert  - 10.2-2
+* Tue Apr 21 2009 Mattias Ellert  - 10.2-3
 - Autogenerated
 


From e799f3170cb90e09f3fc4685e7e2026fbd55e784 Mon Sep 17 00:00:00 2001
From: Tibbs 
Date: Apr 24 2009 21:57:49 +0000
Subject: [PATCH 293/3559] Note FESCo approvals from https://fedorahosted.org/fesco/ticket/136


---

diff --git a/Packaging:GuidelinesTodo.mw b/Packaging:GuidelinesTodo.mw
index 855eee0..082d939 100644
--- a/Packaging:GuidelinesTodo.mw
+++ b/Packaging:GuidelinesTodo.mw
@@ -11,11 +11,11 @@ Status should be one of:
 |- style="color: white; background-color: #3074c2; font-weight: bold" 
 |Status||Task Name||Owner||Meeting Date||Notes
 |-
-|ratify||Common Package Names||abadger1999||2009-04-14||[[Common package names packaging guideline draft]]
+|writeup||Common Package Names||abadger1999||2009-04-14||[[Common package names packaging guideline draft]]
 |-
-|ratify||Using Alternatives||[[User:Rathann|rathann]]||2009-04-14||[[PackagingDrafts/UsingAlternatives]]
+|writeup||Using Alternatives||[[User:Rathann|rathann]]||2009-04-14||[[PackagingDrafts/UsingAlternatives]]
 |-
-|ratify||WordPress plugins||[[User:Ianweller|Ian Weller]]||2009-04-14||[[User:Ianweller/WordPress plugin packaging guidelines (draft)]]
+|writeup||WordPress plugins||[[User:Ianweller|Ian Weller]]||2009-04-14||[[User:Ianweller/WordPress plugin packaging guidelines (draft)]]
 |}
 
 {{:PackagingDrafts/DraftsTodo}}

From 6220f299142d73a2c6bdf4909ad0a7e90d0bc5ad Mon Sep 17 00:00:00 2001
From: Ellert 
Date: Apr 28 2009 15:44:58 +0000
Subject: [PATCH 294/3559] globus-spec-creator is now part of globus-core


---

diff --git a/Packaging:Globus.mw b/Packaging:Globus.mw
index 349893e..6b12bdb 100644
--- a/Packaging:Globus.mw
+++ b/Packaging:Globus.mw
@@ -103,12 +103,12 @@ Some of the GPT packages in the huge Globus Toolkit installer tarball contain co
 
 == Autogenerating specfiles (informational) ==
 
-It is possible to autogenerate an initial version of the specfile from the information in the GPT source package description file by running the [http://www.grid.tsl.uu.se/repos/globus/scripts/globus-spec.pl globus-spec.pl] script. Using this script is optional, but provides increased maintainability of the package and reduces the risk of cut and paste errors. The following examples shows the autogenerated specfiles generated by the script in a few cases.
+It is possible to autogenerate an initial version of the specfile from the information in the GPT source package description file by running the globus-spec-creator script, which is installed as part of the '''globus-core''' package. Using this script is optional, but provides increased maintainability of the package and reduces the risk of cut and paste errors. The following examples shows the autogenerated specfiles generated by the script in a few cases.
 
 === Globus package that provides a library ===
 
 
-./globus-spec.pl -g globus_gsi_openssl_error-0.14/pkgdata/pkg_data_src.gpt.in -d gsi/openssl_error/source
+globus-spec-creator -g globus_gsi_openssl_error-0.14/pkgdata/pkg_data_src.gpt.in -d gsi/openssl_error/source
 
 
 * The -g option specifies the GPT source package description file
@@ -323,7 +323,7 @@ rm -rf $RPM_BUILD_ROOT
 === Globus package that only provides programs ===
 
 
-./globus-spec.pl -g globus_proxy_utils-2.5/pkgdata/pkg_data_src.gpt.in -d gsi/proxy/proxy_utils/source
+globus-spec-creator -g globus_proxy_utils-2.5/pkgdata/pkg_data_src.gpt.in -d gsi/proxy/proxy_utils/source
 
 
 
@@ -421,9 +421,10 @@ rm -rf $RPM_BUILD_ROOT
 === Globus package containing a plugin ===
 
 
-./globus-spec.pl -g globus_xio_popen_driver-0.2/pkgdata/pkg_data_src.gpt.in -d xio/drivers/popen/source -n %{name}-wrong-dep.patch
+globus-spec-creator -g globus_xio_popen_driver-0.2/pkgdata/pkg_data_src.gpt.in -d xio/drivers/popen/source -r 2 -n %{name}-wrong-dep.patch %{name}-wrong-desc.patch
 
 
+* The -r option is used to set the release version of the specfile to 2 (default is 1, as in the previous examples)
 * The -n option can be used to disable the generation of a doc package for Globus packages that don't have any doxygen markup in the sources.
 
 In this case the autogenerated specfile will instead of the commands for deleting the .la files contain a comment explaining why the .la files can not be removed.
@@ -440,8 +441,8 @@ This example also illustrates that the names of patches can be listed as argumen
 Name:		globus-xio-popen-driver
 %global _name %(tr - _ <<< %{name})
 Version:	0.2
-Release:	1%{?dist}
-Summary:	Globus Toolkit - Globus XIO BW Limit Driver
+Release:	2%{?dist}
+Summary:	Globus Toolkit - Globus XIO Pipe Open Driver
 
 Group:		System Environment/Libraries
 License:	ASL 2.0
@@ -456,6 +457,9 @@ Source: 	%{_name}-%{version}.tar.gz
 #		### INSERT PATCH DESCRIPTION HERE ###:
 #		http://bugzilla.globus.org/bugzilla/show_bug.cgi?id=###BUG NUMBER###
 Patch0: 	%{name}-wrong-dep.patch
+#		### INSERT PATCH DESCRIPTION HERE ###:
+#		http://bugzilla.globus.org/bugzilla/show_bug.cgi?id=###BUG NUMBER###
+Patch1: 	%{name}-wrong-desc.patch
 BuildRoot:	%{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
 
 Requires:	globus-common
@@ -463,7 +467,7 @@ BuildRequires:	grid-packaging-tools
 BuildRequires:	globus-xio-devel
 
 %package devel
-Summary:	Globus Toolkit - Globus XIO BW Limit Driver Development Files
+Summary:	Globus Toolkit - Globus XIO Pipe Open Driver Development Files
 Group:		Development/Libraries
 Requires:	%{name} = %{version}-%{release}
 Requires:	globus-xio-devel
@@ -475,7 +479,7 @@ many others all over the world. A growing number of projects and companies are
 using the Globus Toolkit to unlock the potential of grids for their cause.
 
 The %{name} package contains:
-Globus XIO BW Limit Driver
+Globus XIO Pipe Open Driver
 
 %description devel
 The Globus Toolkit is an open source software toolkit used for building Grid
@@ -484,11 +488,12 @@ many others all over the world. A growing number of projects and companies are
 using the Globus Toolkit to unlock the potential of grids for their cause.
 
 The %{name}-devel package contains:
-Globus XIO BW Limit Driver Development Files
+Globus XIO Pipe Open Driver Development Files
 
 %prep
 %setup -q -n %{_name}-%{version}
 %patch0 -p1
+%patch1 -p1
 
 %build
 # Remove files that should be replaced during bootstrap
@@ -561,18 +566,17 @@ rm -rf $RPM_BUILD_ROOT
 %{_libdir}/pkgconfig/%{name}.pc
 
 %changelog
-* Thu Apr 16 2009 Mattias Ellert  - 0.2-1
+* Fri Apr 24 2009 Mattias Ellert  - 0.2-2
 - Autogenerated
 

 
 === Globus package that provides both a library and programs and that has a corresponding setup package ===
 
 
-./globus-spec.pl -g globus_common-10.2/pkgdata/pkg_data_src.gpt.in -s globus_common_setup-2.6/pkgdata/pkg_data_src.gpt.in -r 3 -d common/source
+globus-spec-creator -g globus_common-10.2/pkgdata/pkg_data_src.gpt.in -s globus_common_setup-2.6/pkgdata/pkg_data_src.gpt.in -r 3 -d common/source
 
 
 * The -s option is used to indicate the GPT source package description file for the setup package
-* The -r option is used to set the release version of the specfile to 3 (default is 1, as in the previous examples)
 
 The patches have been excluded from this example to keep it short. For this package some additional editing is needed. Compare the autogenerated file below with the [http://cvs.fedoraproject.org/viewvc/devel/globus-common/globus-common.spec?view=markup specfile in the actual package] to see the differences.
 

From dadcb9e4ee5f0e1544dedd441b27ee732d42165b Mon Sep 17 00:00:00 2001
From: Spot 
Date: Apr 28 2009 18:18:35 +0000
Subject: [PATCH 295/3559] *Empty MediaWiki Message*


---

diff --git a/Packaging:GuidelinesTodo.mw b/Packaging:GuidelinesTodo.mw
index 082d939..bc0663e 100644
--- a/Packaging:GuidelinesTodo.mw
+++ b/Packaging:GuidelinesTodo.mw
@@ -246,6 +246,8 @@ Status should be one of:
 |- style="color: white; background-color: #3074c2; font-weight: bold" 
 |Task Name||Owner||Resolution Date||Notes
 |-
+|Compiler Flags||abadger1999|| 2009-04-28 ||[[Compiler_Flags_(draft)]] || A more thorough document on how to ensure optflags are being used should be generated in the open Packagers/ namespace, then please request that FPC add a link to that package from the relevant section of the Packaging Guidelines.
+|-
 |Check for fonts in review || [[Nicolas Mailhot]] || 2009-02-17 || [[PackagingDrafts/ReviewGuideline_for_fonts_(2009-01-22)]] Packagers and reviewers should follow the Font Guidelines, but FPC is looking to phase out ReviewGuidelines, not to add to it.
 |-
 |User Creation|| abadger1999|| 2009-02-17 ||[[Packaging/UserCreation]] was never passed, and has been removed.

From 3539d030e1b38369fa9cf6998e84747e1fdfe643 Mon Sep 17 00:00:00 2001
From: Spot 
Date: Apr 30 2009 14:16:13 +0000
Subject: [PATCH 296/3559] /* Exceptions */


---

diff --git a/Packaging:Guidelines.mw b/Packaging:Guidelines.mw
index 43f2ad1..3a91cd6 100644
--- a/Packaging:Guidelines.mw
+++ b/Packaging:Guidelines.mw
@@ -47,7 +47,7 @@ Packages which require non-open source components to build are also not permitte
 
 {{Anchor|SourceRequirementExceptions}}
 === Exceptions ===
-* Some software (usually related to compilers or cross-compiler environments) cannot be build without the use of a previous toolchain or development environment (open source). If you have a package which meets this criteria, contact the Fedora Packaging Committee for approval.
+* Some software (usually related to compilers or cross-compiler environments) cannot be built without the use of a previous toolchain or development environment (open source). If you have a package which meets this criteria, contact the Fedora Packaging Committee for approval.
 * An exception is made for binary firmware, as long as it meets the requirements documented here: [[Packaging/LicensingGuidelines#BinaryFirmware|BinaryFirmware]]
 
 {{Anchor|Spec Legibility}}

From 99ea475732abe21e9827147f41a39bef5e3d7f47 Mon Sep 17 00:00:00 2001
From: Ellert 
Date: May 05 2009 11:26:01 +0000
Subject: [PATCH 297/3559] Update examples after feedback from the Fedora Packaging Committee


---

diff --git a/Packaging:Globus.mw b/Packaging:Globus.mw
index 6b12bdb..a186ec4 100644
--- a/Packaging:Globus.mw
+++ b/Packaging:Globus.mw
@@ -149,18 +149,11 @@ BuildRequires:	globus-common-devel >= 3
 BuildRequires:	globus-openssl-devel >= 1
 BuildRequires:	globus-core >= 4
 BuildRequires:	doxygen
-%if %{?fedora}%{!?fedora:0} >= 3
-BuildRequires:	graphviz
-BuildRequires:	ghostscript
-%else
-%if %{?rhel}%{!?rhel:0} >= 5
 BuildRequires:	graphviz
 BuildRequires:	ghostscript
 %if "%{?rhel}" == "5"
 BuildRequires:	graphviz-gd
 %endif
-%endif
-%endif
 %if %{?fedora}%{!?fedora:0} >= 9
 BuildRequires:	tex(latex)
 %else
@@ -254,15 +247,15 @@ export PATH=$PWD/bin:$PATH
 rm -rf $RPM_BUILD_ROOT
 make install DESTDIR=$RPM_BUILD_ROOT
 
+GLOBUSPACKAGEDIR=$RPM_BUILD_ROOT%{_datadir}/globus/packages
+
 # Remove libtool archives (.la files)
 find $RPM_BUILD_ROOT%{_libdir} -name 'lib*.la' -exec rm -v '{}' \;
-sed '/lib.*\.la$/d' \
-  -i $RPM_BUILD_ROOT%{_datadir}/globus/packages/%{_name}/%{flavor}_rtl.filelist
+sed '/lib.*\.la$/d' -i $GLOBUSPACKAGEDIR/%{_name}/%{flavor}_rtl.filelist
 
 # Remove static libraries (.a files)
 find $RPM_BUILD_ROOT%{_libdir} -name 'lib*.a' -exec rm -v '{}' \;
-sed '/lib.*\.a$/d' \
-  -i $RPM_BUILD_ROOT%{_datadir}/globus/packages/%{_name}/%{flavor}_dev.filelist
+sed '/lib.*\.a$/d' -i $GLOBUSPACKAGEDIR/%{_name}/%{flavor}_dev.filelist
 
 # Generate pkg-config file from GPT metadata
 mkdir -p $RPM_BUILD_ROOT%{_libdir}/pkgconfig
@@ -273,25 +266,23 @@ mkdir -p $RPM_BUILD_ROOT%{_libdir}/pkgconfig
 mv $RPM_BUILD_ROOT%{_docdir}/%{_name} \
   $RPM_BUILD_ROOT%{_docdir}/%{name}-%{version}
 sed s!doc/%{_name}!doc/%{name}-%{version}! \
-  -i $RPM_BUILD_ROOT%{_datadir}/globus/packages/%{_name}/noflavor_doc.filelist
+  -i $GLOBUSPACKAGEDIR/%{_name}/noflavor_doc.filelist
 
-# Remove unwanted documentation
-rm -f $RPM_BUILD_ROOT%{_mandir}/man3/deprecated.3
+# Remove unwanted documentation (needed for RHEL4)
 rm -f $RPM_BUILD_ROOT%{_mandir}/man3/*_%{_name}-%{version}_*.3
-sed -e '/deprecated\.3/d' \
-    -e '/_%{_name}-%{version}_.*\.3/d' \
-  -i $RPM_BUILD_ROOT%{_datadir}/globus/packages/%{_name}/noflavor_doc.filelist
+sed -e '/_%{_name}-%{version}_.*\.3/d' \
+  -i $GLOBUSPACKAGEDIR/%{_name}/noflavor_doc.filelist
 
 # Install license file
 mkdir -p $RPM_BUILD_ROOT%{_docdir}/%{name}-%{version}
 install -m 644 -p GLOBUS_LICENSE $RPM_BUILD_ROOT%{_docdir}/%{name}-%{version}
 
 # Generate package filelists
-cat $RPM_BUILD_ROOT%{_datadir}/globus/packages/%{_name}/%{flavor}_rtl.filelist \
+cat $GLOBUSPACKAGEDIR/%{_name}/%{flavor}_rtl.filelist \
   | sed s!^!%{_prefix}! > package.filelist
-cat $RPM_BUILD_ROOT%{_datadir}/globus/packages/%{_name}/%{flavor}_dev.filelist \
+cat $GLOBUSPACKAGEDIR/%{_name}/%{flavor}_dev.filelist \
   | sed s!^!%{_prefix}! > package-devel.filelist
-cat $RPM_BUILD_ROOT%{_datadir}/globus/packages/%{_name}/noflavor_doc.filelist \
+cat $GLOBUSPACKAGEDIR/%{_name}/noflavor_doc.filelist \
   | sed -e 's!/man/.*!&*!' -e 's!^!%doc %{_prefix}!' > package-doc.filelist
 
 %clean
@@ -316,7 +307,7 @@ rm -rf $RPM_BUILD_ROOT
 %dir %{_docdir}/%{name}-%{version}/html
 
 %changelog
-* Wed Apr 15 2009 Mattias Ellert  - 0.14-1
+* Tue May  5 2009 Mattias Ellert  - 0.14-1
 - Autogenerated
 

 
@@ -396,12 +387,14 @@ make %{?_smp_mflags}
 rm -rf $RPM_BUILD_ROOT
 make install DESTDIR=$RPM_BUILD_ROOT
 
+GLOBUSPACKAGEDIR=$RPM_BUILD_ROOT%{_datadir}/globus/packages
+
 # Install license file
 mkdir -p $RPM_BUILD_ROOT%{_docdir}/%{name}-%{version}
 install -m 644 -p GLOBUS_LICENSE $RPM_BUILD_ROOT%{_docdir}/%{name}-%{version}
 
 # Generate package filelists
-cat $RPM_BUILD_ROOT%{_datadir}/globus/packages/%{_name}/%{flavor}_pgm.filelist \
+cat $GLOBUSPACKAGEDIR/%{_name}/%{flavor}_pgm.filelist \
   | sed s!^!%{_prefix}! > package.filelist
 
 %clean
@@ -414,7 +407,7 @@ rm -rf $RPM_BUILD_ROOT
 %doc %{_docdir}/%{name}-%{version}/GLOBUS_LICENSE
 
 %changelog
-* Thu Apr 16 2009 Mattias Ellert  - 2.5-1
+* Tue May  5 2009 Mattias Ellert  - 2.5-1
 - Autogenerated
 

 
@@ -522,6 +515,8 @@ make %{?_smp_mflags}
 rm -rf $RPM_BUILD_ROOT
 make install DESTDIR=$RPM_BUILD_ROOT
 
+GLOBUSPACKAGEDIR=$RPM_BUILD_ROOT%{_datadir}/globus/packages
+
 # This library is opened using lt_dlopenext, so the libtool archives
 # (.la files) can not be removed - fix the libdir...
 for lib in `find $RPM_BUILD_ROOT%{_libdir} -name 'lib*.la'` ; do
@@ -530,8 +525,7 @@ done
 
 # Remove static libraries (.a files)
 find $RPM_BUILD_ROOT%{_libdir} -name 'lib*.a' -exec rm -v '{}' \;
-sed '/lib.*\.a$/d' \
-  -i $RPM_BUILD_ROOT%{_datadir}/globus/packages/%{_name}/%{flavor}_dev.filelist
+sed '/lib.*\.a$/d' -i $GLOBUSPACKAGEDIR/%{_name}/%{flavor}_dev.filelist
 
 # Generate pkg-config file from GPT metadata
 mkdir -p $RPM_BUILD_ROOT%{_libdir}/pkgconfig
@@ -543,9 +537,9 @@ mkdir -p $RPM_BUILD_ROOT%{_docdir}/%{name}-%{version}
 install -m 644 -p GLOBUS_LICENSE $RPM_BUILD_ROOT%{_docdir}/%{name}-%{version}
 
 # Generate package filelists
-cat $RPM_BUILD_ROOT%{_datadir}/globus/packages/%{_name}/%{flavor}_rtl.filelist \
+cat $GLOBUSPACKAGEDIR/%{_name}/%{flavor}_rtl.filelist \
   | sed s!^!%{_prefix}! > package.filelist
-cat $RPM_BUILD_ROOT%{_datadir}/globus/packages/%{_name}/%{flavor}_dev.filelist \
+cat $GLOBUSPACKAGEDIR/%{_name}/%{flavor}_dev.filelist \
   | sed s!^!%{_prefix}! > package-devel.filelist
 
 %clean
@@ -566,7 +560,7 @@ rm -rf $RPM_BUILD_ROOT
 %{_libdir}/pkgconfig/%{name}.pc
 
 %changelog
-* Fri Apr 24 2009 Mattias Ellert  - 0.2-2
+* Tue May  5 2009 Mattias Ellert  - 0.2-2
 - Autogenerated
 

 
@@ -621,18 +615,11 @@ BuildRequires:	grid-packaging-tools
 BuildRequires:	globus-libtool-devel >= 1
 BuildRequires:	globus-core >= 4
 BuildRequires:	doxygen
-%if %{?fedora}%{!?fedora:0} >= 3
-BuildRequires:	graphviz
-BuildRequires:	ghostscript
-%else
-%if %{?rhel}%{!?rhel:0} >= 5
 BuildRequires:	graphviz
 BuildRequires:	ghostscript
 %if "%{?rhel}" == "5"
 BuildRequires:	graphviz-gd
 %endif
-%endif
-%endif
 %if %{?fedora}%{!?fedora:0} >= 9
 BuildRequires:	tex(latex)
 %else
@@ -779,15 +766,15 @@ EOF
 
 ### INSERT RELEVANT PARTS OF setup-globus-common HERE ###
 
+GLOBUSPACKAGEDIR=$RPM_BUILD_ROOT%{_datadir}/globus/packages
+
 # Remove libtool archives (.la files)
 find $RPM_BUILD_ROOT%{_libdir} -name 'lib*.la' -exec rm -v '{}' \;
-sed '/lib.*\.la$/d' \
-  -i $RPM_BUILD_ROOT%{_datadir}/globus/packages/%{_name}/%{flavor}_rtl.filelist
+sed '/lib.*\.la$/d' -i $GLOBUSPACKAGEDIR/%{_name}/%{flavor}_rtl.filelist
 
 # Remove static libraries (.a files)
 find $RPM_BUILD_ROOT%{_libdir} -name 'lib*.a' -exec rm -v '{}' \;
-sed '/lib.*\.a$/d' \
-  -i $RPM_BUILD_ROOT%{_datadir}/globus/packages/%{_name}/%{flavor}_dev.filelist
+sed '/lib.*\.a$/d' -i $GLOBUSPACKAGEDIR/%{_name}/%{flavor}_dev.filelist
 
 # Generate pkg-config file from GPT metadata
 mkdir -p $RPM_BUILD_ROOT%{_libdir}/pkgconfig
@@ -798,28 +785,26 @@ mkdir -p $RPM_BUILD_ROOT%{_libdir}/pkgconfig
 mv $RPM_BUILD_ROOT%{_docdir}/%{_name} \
   $RPM_BUILD_ROOT%{_docdir}/%{name}-%{version}
 sed s!doc/%{_name}!doc/%{name}-%{version}! \
-  -i $RPM_BUILD_ROOT%{_datadir}/globus/packages/%{_name}/noflavor_doc.filelist
+  -i $GLOBUSPACKAGEDIR/%{_name}/noflavor_doc.filelist
 
-# Remove unwanted documentation
-rm -f $RPM_BUILD_ROOT%{_mandir}/man3/deprecated.3
+# Remove unwanted documentation (needed for RHEL4)
 rm -f $RPM_BUILD_ROOT%{_mandir}/man3/*_%{_name}-%{version}_*.3
-sed -e '/deprecated\.3/d' \
-    -e '/_%{_name}-%{version}_.*\.3/d' \
-  -i $RPM_BUILD_ROOT%{_datadir}/globus/packages/%{_name}/noflavor_doc.filelist
+sed -e '/_%{_name}-%{version}_.*\.3/d' \
+  -i $GLOBUSPACKAGEDIR/%{_name}/noflavor_doc.filelist
 
 # Install license file
 mkdir -p $RPM_BUILD_ROOT%{_docdir}/%{name}-%{version}
 install -m 644 -p GLOBUS_LICENSE $RPM_BUILD_ROOT%{_docdir}/%{name}-%{version}
 
 # Generate package filelists
-cat $RPM_BUILD_ROOT%{_datadir}/globus/packages/%{_name}/%{flavor}_rtl.filelist \
+cat $GLOBUSPACKAGEDIR/%{_name}/%{flavor}_rtl.filelist \
   | sed s!^!%{_prefix}! > package.filelist
-cat $RPM_BUILD_ROOT%{_datadir}/globus/packages/%{_name}/%{flavor}_pgm.filelist \
-    $RPM_BUILD_ROOT%{_datadir}/globus/packages/%{_name}_setup/noflavor_pgm.filelist \
+cat $GLOBUSPACKAGEDIR/%{_name}/%{flavor}_pgm.filelist \
+    $GLOBUSPACKAGEDIR/%{_name}_setup/noflavor_pgm.filelist \
   | sed s!^!%{_prefix}! > package-progs.filelist
-cat $RPM_BUILD_ROOT%{_datadir}/globus/packages/%{_name}/%{flavor}_dev.filelist \
+cat $GLOBUSPACKAGEDIR/%{_name}/%{flavor}_dev.filelist \
   | sed s!^!%{_prefix}! > package-devel.filelist
-cat $RPM_BUILD_ROOT%{_datadir}/globus/packages/%{_name}/noflavor_doc.filelist \
+cat $GLOBUSPACKAGEDIR/%{_name}/noflavor_doc.filelist \
   | sed -e 's!/man/.*!&*!' -e 's!^!%doc %{_prefix}!' > package-doc.filelist
 
 %clean
@@ -850,6 +835,6 @@ rm -rf $RPM_BUILD_ROOT
 %dir %{_docdir}/%{name}-%{version}/html
 
 %changelog
-* Tue Apr 21 2009 Mattias Ellert  - 10.2-3
+* Tue May  5 2009 Mattias Ellert  - 10.2-3
 - Autogenerated
 


From 25eed97c5f01f7f25af88a1505fb9b094152067c Mon Sep 17 00:00:00 2001
From: Tibbs 
Date: May 08 2009 18:21:16 +0000
Subject: [PATCH 298/3559] Actually link to DistTag document.


---

diff --git a/Packaging:Naming.mw b/Packaging:Naming.mw
index 74abcad..80d86e1 100644
--- a/Packaging:Naming.mw
+++ b/Packaging:Naming.mw
@@ -233,9 +233,10 @@ Also, packagers using the post-release scheme should put a comment in their spec
 {{Anchor|DistTag}}
 === Using the %{?dist} Tag ===
 If you wish to use a single spec file to build for multiple distributions, you can use the %{?dist} tag in the Release field.
-Please refer to the DistTag documentation for the details on the appropriate way to do this.
+Please refer to the [[Packaging:DistTag]] documentation for the details on the appropriate way to do this.
 
 {{Anchor|DistBump}}
+
 === Minor release bumps for old branches ===
 Sometimes, you may find yourself in a situation where an older branch needs a fix, but the newer branches are fine. For example, if foo = 1.0-1%{?dist} in FC-4 and FC-5, and only FC-4 needs a fix. Normally, you would need to bump the release in each of the branches to ensure that FC-4 < FC-5, but that is a waste of time and energy for the newer branches which do not need to be touched.
 

From e363355d65c869b7a6feb8f4385331342e70fccb Mon Sep 17 00:00:00 2001
From: Toshio 
Date: May 08 2009 19:00:44 +0000
Subject: [PATCH 299/3559] namespace on links


---

diff --git a/Packaging:Guidelines.mw b/Packaging:Guidelines.mw
index 3a91cd6..21979ce 100644
--- a/Packaging:Guidelines.mw
+++ b/Packaging:Guidelines.mw
@@ -28,7 +28,7 @@ There are various legal concerns to consider when packaging for Fedora.
 {{Anchor|LegalLicensing}}
 === Licensing ===
 
-You should review [[Licensing]]  and the [[Packaging/LicensingGuidelines]]  to ensure that your package is licensed appropriately.
+You should review [[Licensing:Main]]  and the [[Packaging:LicensingGuidelines]]  to ensure that your package is licensed appropriately.
 
 {{Anchor|SourceRequirement}}
 

From eefe9b94068957629e77dba9d3ee567f6e2baa85 Mon Sep 17 00:00:00 2001
From: Spot 
Date: May 12 2009 18:18:05 +0000
Subject: [PATCH 300/3559] *Empty MediaWiki Message*


---

diff --git a/Packaging:GuidelinesTodo.mw b/Packaging:GuidelinesTodo.mw
index bc0663e..e86665e 100644
--- a/Packaging:GuidelinesTodo.mw
+++ b/Packaging:GuidelinesTodo.mw
@@ -16,6 +16,10 @@ Status should be one of:
 |writeup||Using Alternatives||[[User:Rathann|rathann]]||2009-04-14||[[PackagingDrafts/UsingAlternatives]]
 |-
 |writeup||WordPress plugins||[[User:Ianweller|Ian Weller]]||2009-04-14||[[User:Ianweller/WordPress plugin packaging guidelines (draft)]]
+|-
+|ratify||GConf scriptlets||abadger1999||2009-05-12||[[GConf Scriptlets (draft)]] Proposal to move GConf schema registration to %posttrans and more.
+|-
+|ratify||Globus||ellert||2009-05-12||[[PackagingDrafts/Globus]] Draft packaging guidelines for packages from the Globus Toolkit.
 |}
 
 {{:PackagingDrafts/DraftsTodo}}
@@ -25,6 +29,8 @@ Status should be one of:
 |- style="color: white; background-color: #3074c2; font-weight: bold" 
 |Task Name||Owner||Resolution Date||Notes
 |-
+|Guidelines for Pre-Review||abadger1999|| 2009-05-12 ||[[Pre-review Guidelines (draft)]] Approved by FPC, given to FESCo, not put into guidelines because it is a one-off.
+|-
 |Embedded Desktop Files || spot || 2009-04-14 || [[PackagingDrafts/EmbeddedDesktopFiles]]
 |-
 |Explicit Requires || spot || 2009-04-14 ||[[PackagingDrafts/ExplicitRequires]]
@@ -246,6 +252,8 @@ Status should be one of:
 |- style="color: white; background-color: #3074c2; font-weight: bold" 
 |Task Name||Owner||Resolution Date||Notes
 |-
+|Guidelines for MAN pages||hubbitus||2009-05-12||[[MAN pages which exists in_other places(draft)]] This draft conflicts with the general practice that Fedora packagers should be working to send improvements directly to upstream. Anyone who feels motivated to dig in other distributions for patches or improvements should feel free to do so, but it is not something that the FPC felt should be codified into the guidelines.
+|-
 |Compiler Flags||abadger1999|| 2009-04-28 ||[[Compiler_Flags_(draft)]] || A more thorough document on how to ensure optflags are being used should be generated in the open Packagers/ namespace, then please request that FPC add a link to that package from the relevant section of the Packaging Guidelines.
 |-
 |Check for fonts in review || [[Nicolas Mailhot]] || 2009-02-17 || [[PackagingDrafts/ReviewGuideline_for_fonts_(2009-01-22)]] Packagers and reviewers should follow the Font Guidelines, but FPC is looking to phase out ReviewGuidelines, not to add to it.

From 25b50cc69cf3423a25e2fbee90a7980e93289863 Mon Sep 17 00:00:00 2001
From: Spot 
Date: May 12 2009 18:18:40 +0000
Subject: [PATCH 301/3559] /* Action Items */


---

diff --git a/Packaging:GuidelinesTodo.mw b/Packaging:GuidelinesTodo.mw
index e86665e..f3dbef0 100644
--- a/Packaging:GuidelinesTodo.mw
+++ b/Packaging:GuidelinesTodo.mw
@@ -17,7 +17,7 @@ Status should be one of:
 |-
 |writeup||WordPress plugins||[[User:Ianweller|Ian Weller]]||2009-04-14||[[User:Ianweller/WordPress plugin packaging guidelines (draft)]]
 |-
-|ratify||GConf scriptlets||abadger1999||2009-05-12||[[GConf Scriptlets (draft)]] Proposal to move GConf schema registration to %posttrans and more.
+|ratify||GConf scriptlets||abadger1999||2009-05-12||[[GConf Scriptlets (draft)]] Improve GConf scriplet handling.
 |-
 |ratify||Globus||ellert||2009-05-12||[[PackagingDrafts/Globus]] Draft packaging guidelines for packages from the Globus Toolkit.
 |}

From e4084df6319fc64761dcfaccbad2b489876ea0fa Mon Sep 17 00:00:00 2001
From: Tibbs 
Date: May 15 2009 19:55:49 +0000
Subject: [PATCH 302/3559] Note approved items from 2009-05-15 FESCo meeting.


---

diff --git a/Packaging:GuidelinesTodo.mw b/Packaging:GuidelinesTodo.mw
index f3dbef0..3a888a0 100644
--- a/Packaging:GuidelinesTodo.mw
+++ b/Packaging:GuidelinesTodo.mw
@@ -17,9 +17,9 @@ Status should be one of:
 |-
 |writeup||WordPress plugins||[[User:Ianweller|Ian Weller]]||2009-04-14||[[User:Ianweller/WordPress plugin packaging guidelines (draft)]]
 |-
-|ratify||GConf scriptlets||abadger1999||2009-05-12||[[GConf Scriptlets (draft)]] Improve GConf scriplet handling.
+|writeup||GConf scriptlets||abadger1999||2009-05-12||[[GConf Scriptlets (draft)]] Improve GConf scriplet handling.
 |-
-|ratify||Globus||ellert||2009-05-12||[[PackagingDrafts/Globus]] Draft packaging guidelines for packages from the Globus Toolkit.
+|writeup||Globus||ellert||2009-05-12||[[PackagingDrafts/Globus]] Draft packaging guidelines for packages from the Globus Toolkit.
 |}
 
 {{:PackagingDrafts/DraftsTodo}}

From e3d6c8565456e10f6bb7c7c39abb4a7457212988 Mon Sep 17 00:00:00 2001
From: Spot 
Date: May 19 2009 15:46:13 +0000
Subject: [PATCH 303/3559] *Empty MediaWiki Message*


---

diff --git a/Packaging:RPMMacros.mw b/Packaging:RPMMacros.mw
index 928dd42..f3d993d 100644
--- a/Packaging:RPMMacros.mw
+++ b/Packaging:RPMMacros.mw
@@ -8,7 +8,7 @@ Here are the definitions for some common specfile macros as they are defined on 
 === Macros mimicking autoconf variables ===
 
 %{_sysconfdir}        /etc
-%{_initrddir}         %{_sysconfdir}/rc.d/init.d
+%{_initddir}          %{_sysconfdir}/rc.d/init.d
 %{_prefix}            /usr
 %{_exec_prefix}       %{_prefix}
 %{_bindir}            %{_exec_prefix}/bin

From c55dff131ee935fa99280b82b03632a526c5aac7 Mon Sep 17 00:00:00 2001
From: Spot 
Date: May 20 2009 14:06:05 +0000
Subject: [PATCH 304/3559] /* Valid RPM Macros */


---

diff --git a/Packaging:RPMMacros.mw b/Packaging:RPMMacros.mw
index f3d993d..696a164 100644
--- a/Packaging:RPMMacros.mw
+++ b/Packaging:RPMMacros.mw
@@ -2,13 +2,13 @@
 -->
 = Valid RPM Macros =
 
-Here are the definitions for some common specfile macros as they are defined on Fedora Core 3 (rpm-4.3.2-21). For definitions of more macros, examine the output of "rpm --showrc". To see the expanded definition of a macro use the command "rpm --eval ''''%{macro}''''".  Note that neither command will take into account macros defined inside specfiles, but both will take into account macros defined in your ~/.rpmmacros file and macros defined on the command line.
+Here are the definitions for some common specfile macros as they are defined on Fedora Core 11 (rpm-4.7.0-1.fc11). For definitions of more macros, examine the output of "rpm --showrc". To see the expanded definition of a macro use the command "rpm --eval ''''%{macro}''''".  Note that neither command will take into account macros defined inside specfiles, but both will take into account macros defined in your ~/.rpmmacros file and macros defined on the command line.
 
+Keep in mind that some of these macros may evaluate differently on older Fedora or EPEL releases. 
 
 === Macros mimicking autoconf variables ===
 
 %{_sysconfdir}        /etc
-%{_initddir}          %{_sysconfdir}/rc.d/init.d
 %{_prefix}            /usr
 %{_exec_prefix}       %{_prefix}
 %{_bindir}            %{_exec_prefix}/bin
@@ -16,24 +16,28 @@ Here are the definitions for some common specfile macros as they are defined on 
 %{_libdir}            %{_exec_prefix}/%{_lib}
 %{_libexecdir}        %{_exec_prefix}/libexec
 %{_sbindir}           %{_exec_prefix}/sbin
-%{_sharedstatedir}    %{_prefix}/com
+%{_sharedstatedir}    /var/lib
 %{_datadir}           %{_prefix}/share
 %{_includedir}        %{_prefix}/include
 %{_oldincludedir}     /usr/include
 %{_infodir}           /usr/share/info
 %{_mandir}            /usr/share/man
 %{_localstatedir}     /var
+%{_initddir}          %{_sysconfdir}/rc.d/init.d
 

+Note: On releases older than Fedora 10 (and EPEL), %{_initddir} does not exist. Instead, you should use the deprecated %{_initrddir} macro.
 
 === RPM directory macros ===
 
-%{_topdir}            %{_usrsrc}/redhat
+%{_topdir}            %{getenv:HOME}/rpmbuild
 %{_builddir}          %{_topdir}/BUILD
 %{_rpmdir}            %{_topdir}/RPMS
 %{_sourcedir}         %{_topdir}/SOURCES
 %{_specdir}           %{_topdir}/SPECS
 %{_srcrpmdir}         %{_topdir}/SRPMS
+%{_buildrootdir}      %{_topdir}/BUILDROOT
 

+Note: On releases older than Fedora 10 (and EPEL), %{_buildrootdir} does not exist.
 
 === Build flags macros ===
 
@@ -56,4 +60,3 @@ Here are macros from other distributions to aid you in package conversion:
 * [[Extras/ReferencePLDRPMMacros| PLD RPM Macros]] 
 * [[Extras/ReferenceMandrakeRPMMacros| Mandrake RPM Macros]] 
 ----
-[[Category:Extras]]

From 1e9a2324746641275f62b021be0e7bcebcf715ff Mon Sep 17 00:00:00 2001
From: Spot 
Date: May 20 2009 14:06:45 +0000
Subject: [PATCH 305/3559] /* Valid RPM Macros */


---

diff --git a/Packaging:RPMMacros.mw b/Packaging:RPMMacros.mw
index 696a164..13f13d2 100644
--- a/Packaging:RPMMacros.mw
+++ b/Packaging:RPMMacros.mw
@@ -2,7 +2,7 @@
 -->
 = Valid RPM Macros =
 
-Here are the definitions for some common specfile macros as they are defined on Fedora Core 11 (rpm-4.7.0-1.fc11). For definitions of more macros, examine the output of "rpm --showrc". To see the expanded definition of a macro use the command "rpm --eval ''''%{macro}''''".  Note that neither command will take into account macros defined inside specfiles, but both will take into account macros defined in your ~/.rpmmacros file and macros defined on the command line.
+Here are the definitions for some common specfile macros as they are defined on Fedora Core 11 (rpm-4.7.0-1.fc11). For definitions of more macros, examine the output of "rpm --showrc". To see the expanded definition of a macro use the command rpm --eval "%{macro}".  Note that neither command will take into account macros defined inside specfiles, but both will take into account macros defined in your ~/.rpmmacros file and macros defined on the command line.
 
 Keep in mind that some of these macros may evaluate differently on older Fedora or EPEL releases. 
 

From 8cb0bb819dba07626f33bd1471d11bff280b6b00 Mon Sep 17 00:00:00 2001
From: Spot 
Date: Jun 02 2009 17:53:25 +0000
Subject: [PATCH 306/3559] *Empty MediaWiki Message*


---

diff --git a/Packaging:GuidelinesTodo.mw b/Packaging:GuidelinesTodo.mw
index 3a888a0..5e47981 100644
--- a/Packaging:GuidelinesTodo.mw
+++ b/Packaging:GuidelinesTodo.mw
@@ -11,6 +11,8 @@ Status should be one of:
 |- style="color: white; background-color: #3074c2; font-weight: bold" 
 |Status||Task Name||Owner||Meeting Date||Notes
 |-
+|ratify||Phase out Buildroot||abadger1999||2009-06-02||https://fedoraproject.org/wiki/Phase_out_buildroot_tag_%28draft%29
+|-
 |writeup||Common Package Names||abadger1999||2009-04-14||[[Common package names packaging guideline draft]]
 |-
 |writeup||Using Alternatives||[[User:Rathann|rathann]]||2009-04-14||[[PackagingDrafts/UsingAlternatives]]

From 34ee331ce710e0cdc946d8bbedb4ed0752ebe122 Mon Sep 17 00:00:00 2001
From: Cweyl 
Date: Jun 06 2009 19:53:58 +0000
Subject: [PATCH 307/3559] draft save; not ready


---

diff --git a/Packaging:AutoProvidesAndRequiresFiltering.mw b/Packaging:AutoProvidesAndRequiresFiltering.mw
new file mode 100644
index 0000000..39caa6f
--- /dev/null
+++ b/Packaging:AutoProvidesAndRequiresFiltering.mw
@@ -0,0 +1,95 @@
+== Summary ==
+
+RPM has no general, standard mechanism to enable filtering of auto-generated requires and provides; this guideline describes how Fedora has implemented such a system.
+
+* '''MUST:''' Packages must not provide RPM dependencies things that are not global in nature, or are otherwise indicated (e.g. through a virtual provides system).  e.g. a plugin package containing a binary shared library must not "provide" that library unless it is accessible through the system library paths.
+* '''MUST:''' Where filtering automatically generated RPM dependency information, the filtering system implemented by Fedora must be used, except where there is a compelling reason to deviate from it.
+
+== Rationale ==
+
+RPM has no general mechanism to enable filtering of auto-generated requires and provides; this feature aims to implement one. 
+
+The auto requires and provides system contained in RPM is quite useful; however, it often picks up "private" package capabilities that shouldn't be advertised as global, things that are "just wrong", or things prohibited by policy (e.g. deps from inside %{_docdir}).
+
+For example:
+
+* Various "plugin" packages (e.g. Pidgin, Perl, Apache, KDE) are marked as "providing" private shared libraries outside the system path.
+* Files in %{_docdir} are routinely scanned, and can trigger prov/req when this is explicitly forbidden by policy.
+
+As it stands, filtering these auto-generated requires and provides is difficult and messy at best, and horribly deep magic in many cases; with little guidance on how to do it.{{ref|1}}  This feature aims to make the following tasks easy:
+
+* preventing files/directories from being scanned for requires (pre-scan filtering)
+* preventing files/directories from being scanned for provides (pre-scan filtering)
+* removing items from the requires stream (post-scan filtering)
+* removing items from the provides stream (post-scan filtering)
+
+'''Macros defining the filtering system: [http://fedorapeople.org/~cweyl/macros.filtering macros.filtering]'''
+
+== Examples ==
+
+e.g. to ensure an arch-specific perl-* package won't provide or require things that it shouldn't, we could use an invocation as such:
+
+
+# we don't want to provide private Perl extension libs
+%filter_provides_in %{perl_vendorarch}/.*\\.so$ 
+%filter_provides_in -P %{perl_archlib}/(?!CORE/libperl).*\\.so$ 
+
+# we don't want to either provide or require anything from _docdir, per policy
+%filter_provides_in %{_docdir} 
+%filter_requires_in %{_docdir}
+
+# actually set up the filtering
+%filter_setup
+
+%description
+...
+

+
+Or better yet, have all that centralized, so any package providing a Perl extension{{ref|2}} can easily invoke the correct filtering incantations:
+
+
+%{?perl_default_filter}
+
+%description
+...
+

+
+A brief comparison of [[Features/BetterRpmAutoReqProvFiltering/OtherFilteringSystems|other auto req/prov filtering systems]].
+
+== Usage ==
+
+=== Location of macros ===
+
+It's strongly recommended that these filtering macros be invoked before %description, but after any other definitions.
+
+=== Preventing files/directories from being scanned for provides (pre-scan filtering) ===
+
+The '''%filter_provides_in''' macro is used to define the files or directories that should not be scanned for any "provides" information.  This macro may be safely invoked multiple times, and can handle regular expressions.  (The -P flag can be passed to specify that a PCRE is being used.)
+
+We can filter by regex:
+
+# we don't want to provide private Perl extension libs
+%filter_provides_in %{perl_vendorarch}/.*\\.so$ 
+%filter_provides_in -P %{perl_archlib}/(?!CORE/libperl).*\\.so$ 
+

+
+Or by anything matching, say, a directory:
+
+# we don't want to either provide or require anything from _docdir, per policy
+%filter_provides_in %{_docdir}
+

+
+=== Preventing files/directories from being scanned for requires (pre-scan filtering) ===
+
+The '''%filter_requires_in''' macro is used to define the files or directories that should not be scanned for any "requires" information; it does for requires what the %filter_provides_in macro does for provides.
+
+=== Removing items from the requires stream (post-scan filtering) ===
+=== Removing items from the provides stream (post-scan filtering) ===
+=== General filter setup ===
+
+The %{filter_setup} macro must be invoked after defining any specific overrides; this macro does all the heavy lifting of implementing the filtering desired:
+
+
+# ... filtering defines here
+%filter_setup
+


From 92f779c4e6610a6b536673e9c819d1e7d92ca114 Mon Sep 17 00:00:00 2001
From: Cweyl 
Date: Jun 07 2009 01:07:11 +0000
Subject: [PATCH 308/3559] /* Usage */


---

diff --git a/Packaging:AutoProvidesAndRequiresFiltering.mw b/Packaging:AutoProvidesAndRequiresFiltering.mw
index 39caa6f..58e6be3 100644
--- a/Packaging:AutoProvidesAndRequiresFiltering.mw
+++ b/Packaging:AutoProvidesAndRequiresFiltering.mw
@@ -58,13 +58,15 @@ A brief comparison of [[Features/BetterRpmAutoReqProvFiltering/OtherFilteringSys
 
 == Usage ==
 
-=== Location of macros ===
+{{admon/warning|Beware of Multilib|Be careful of using these macros in a multilib situation, as they may interfere with the "coloring" done internally by RPM to support multilib installs.}}
 
-It's strongly recommended that these filtering macros be invoked before %description, but after any other definitions.
+=== Location of macro invocation ===
+
+It's strongly recommended that these filtering macros be invoked before %description, but after any other definitions.  This will keep them in a consistent place across packages, and help prevent them from being mixed up with other sections.
 
 === Preventing files/directories from being scanned for provides (pre-scan filtering) ===
 
-The '''%filter_provides_in''' macro is used to define the files or directories that should not be scanned for any "provides" information.  This macro may be safely invoked multiple times, and can handle regular expressions.  (The -P flag can be passed to specify that a PCRE is being used.)
+The '''%filter_provides_in''' macro is used to define the files or directories that should not be scanned for any "provides" information.  This macro may be safely invoked multiple times, and can handle regular expressions.  The -P flag can be passed to specify that a PCRE is being used.
 
 We can filter by regex:
 
@@ -81,10 +83,24 @@ Or by anything matching, say, a directory:
 
 === Preventing files/directories from being scanned for requires (pre-scan filtering) ===
 
-The '''%filter_requires_in''' macro is used to define the files or directories that should not be scanned for any "requires" information; it does for requires what the %filter_provides_in macro does for provides.
+The '''%filter_requires_in''' macro is used to define the files or directories that should not be scanned for any "requires" information; it does for requires what the %filter_provides_in macro does for provides and is invoked in the same fashion.
 
-=== Removing items from the requires stream (post-scan filtering) ===
 === Removing items from the provides stream (post-scan filtering) ===
+
+Post-scan provides filtering is invoked through the '''%filter_from_provides'''.  This macro can be fed PCRE's to filter from the stream of auto-found provides.
+
+For example, if we're finding that the auto-prov system is finding an incorrect provide, we can filter it:
+
+
+%filter_from_provides /bad-provide/d
+

+
+Note that we should always specify this in terms of a regexp.
+
+=== Removing items from the requires stream (post-scan filtering) ===
+
+The '''%filter_from_requires''' macro is used to filter "requires"; it does for requires what the %filter_from_provides macro does for provides and is invoked in the same fashion.
+
 === General filter setup ===
 
 The %{filter_setup} macro must be invoked after defining any specific overrides; this macro does all the heavy lifting of implementing the filtering desired:

From af4ea235a7a1d06a0df820cd5f64eb031f0f292a Mon Sep 17 00:00:00 2001
From: Cweyl 
Date: Jun 07 2009 01:11:59 +0000
Subject: [PATCH 309/3559] /* Summary */


---

diff --git a/Packaging:AutoProvidesAndRequiresFiltering.mw b/Packaging:AutoProvidesAndRequiresFiltering.mw
index 58e6be3..e422479 100644
--- a/Packaging:AutoProvidesAndRequiresFiltering.mw
+++ b/Packaging:AutoProvidesAndRequiresFiltering.mw
@@ -1,9 +1,9 @@
 == Summary ==
 
-RPM has no general, standard mechanism to enable filtering of auto-generated requires and provides; this guideline describes how Fedora has implemented such a system.
+RPM has no general or standard mechanism to enable filtering of auto-generated requires and provides; this guideline describes how Fedora has implemented such a system.
 
-* '''MUST:''' Packages must not provide RPM dependencies things that are not global in nature, or are otherwise indicated (e.g. through a virtual provides system).  e.g. a plugin package containing a binary shared library must not "provide" that library unless it is accessible through the system library paths.
-* '''MUST:''' Where filtering automatically generated RPM dependency information, the filtering system implemented by Fedora must be used, except where there is a compelling reason to deviate from it.
+* '''MUST:''' Packages must not provide RPM dependency information when that information is not global in nature, or are otherwise handled (e.g. through a virtual provides system).  e.g. a plugin package containing a binary shared library must not "provide" that library unless it is accessible through the system library paths.
+* '''MUST:''' When filtering automatically generated RPM dependency information, the filtering system implemented by Fedora must be used, except where there is a compelling reason to deviate from it.
 
 == Rationale ==
 

From 0e25acf7305e830fd50de097576e24b4577fe5e9 Mon Sep 17 00:00:00 2001
From: Cweyl 
Date: Jun 07 2009 01:25:14 +0000
Subject: [PATCH 310/3559] /* Usage */


---

diff --git a/Packaging:AutoProvidesAndRequiresFiltering.mw b/Packaging:AutoProvidesAndRequiresFiltering.mw
index e422479..5a1fd8b 100644
--- a/Packaging:AutoProvidesAndRequiresFiltering.mw
+++ b/Packaging:AutoProvidesAndRequiresFiltering.mw
@@ -58,7 +58,7 @@ A brief comparison of [[Features/BetterRpmAutoReqProvFiltering/OtherFilteringSys
 
 == Usage ==
 
-{{admon/warning|Beware of Multilib|Be careful of using these macros in a multilib situation, as they may interfere with the "coloring" done internally by RPM to support multilib installs.}}
+{{admon/warning|Beware of Multilib|Be careful of using these macros in a multilib situation, as they may interfere with the "coloring" of elf32/64 executables done internally by RPM to support multilib installs.}}
 
 === Location of macro invocation ===
 
@@ -103,7 +103,7 @@ The '''%filter_from_requires''' macro is used to filter "requires"; it does for 
 
 === General filter setup ===
 
-The %{filter_setup} macro must be invoked after defining any specific overrides; this macro does all the heavy lifting of implementing the filtering desired:
+The '''%filter_setup''' macro must be invoked after defining any specific overrides; this macro does all the heavy lifting of implementing the filtering desired:
 
 
 # ... filtering defines here

From 618ddf74d72f63c78bc364c64c2a6570b2da2555 Mon Sep 17 00:00:00 2001
From: Cweyl 
Date: Jun 07 2009 01:26:27 +0000
Subject: [PATCH 311/3559] /* Examples */


---

diff --git a/Packaging:AutoProvidesAndRequiresFiltering.mw b/Packaging:AutoProvidesAndRequiresFiltering.mw
index 5a1fd8b..545d932 100644
--- a/Packaging:AutoProvidesAndRequiresFiltering.mw
+++ b/Packaging:AutoProvidesAndRequiresFiltering.mw
@@ -45,15 +45,6 @@ e.g. to ensure an arch-specific perl-* package won't provide or require things t
 ...
 

 
-Or better yet, have all that centralized, so any package providing a Perl extension{{ref|2}} can easily invoke the correct filtering incantations:
-
-
-%{?perl_default_filter}
-
-%description
-...
-

-
 A brief comparison of [[Features/BetterRpmAutoReqProvFiltering/OtherFilteringSystems|other auto req/prov filtering systems]].
 
 == Usage ==

From 4d42ca8117944cd1bb575a2f921edcdaa866601e Mon Sep 17 00:00:00 2001
From: Cweyl 
Date: Jun 07 2009 19:51:01 +0000
Subject: [PATCH 312/3559] /* Examples */


---

diff --git a/Packaging:AutoProvidesAndRequiresFiltering.mw b/Packaging:AutoProvidesAndRequiresFiltering.mw
index 545d932..e91f20a 100644
--- a/Packaging:AutoProvidesAndRequiresFiltering.mw
+++ b/Packaging:AutoProvidesAndRequiresFiltering.mw
@@ -27,6 +27,21 @@ As it stands, filtering these auto-generated requires and provides is difficult 
 
 == Examples ==
 
+A brief comparison of [[Features/BetterRpmAutoReqProvFiltering/OtherFilteringSystems|other auto req/prov filtering systems]].
+
+=== Pidigin plugin package ===
+
+On a x86_64 machine, the pidgin-libnotify provides pidgin-libnotify.so()(64bit), which it shouldn't, as this library is not inside the paths searched by the system for libraries; that is, it's a private, not global, "provides" and as such must not be exposed globally by RPM.
+
+To filter this out, we could use:
+
+
+%filter_provides_in %{_libdir}/purple-2/.*\\.so$
+%filter_setup
+

+
+=== Arch-specific perl-* package ===
+
 e.g. to ensure an arch-specific perl-* package won't provide or require things that it shouldn't, we could use an invocation as such:
 
 
@@ -34,19 +49,23 @@ e.g. to ensure an arch-specific perl-* package won't provide or require things t
 %filter_provides_in %{perl_vendorarch}/.*\\.so$ 
 %filter_provides_in -P %{perl_archlib}/(?!CORE/libperl).*\\.so$ 
 
+# actually set up the filtering
+%filter_setup
+

+
+=== %_docdir filtering ===
+
+By policy, nothing under %_docdir is allowed to either "provide" or "require" anything.  We can prevent this from happening by preventing anything under %_docdir from being scanned:
+
+
 # we don't want to either provide or require anything from _docdir, per policy
 %filter_provides_in %{_docdir} 
 %filter_requires_in %{_docdir}
 
 # actually set up the filtering
 %filter_setup
-
-%description
-...
 

 
-A brief comparison of [[Features/BetterRpmAutoReqProvFiltering/OtherFilteringSystems|other auto req/prov filtering systems]].
-
 == Usage ==
 
 {{admon/warning|Beware of Multilib|Be careful of using these macros in a multilib situation, as they may interfere with the "coloring" of elf32/64 executables done internally by RPM to support multilib installs.}}

From 4c84b95a4e244356fd5e7fd6282fd945097bc430 Mon Sep 17 00:00:00 2001
From: Cweyl 
Date: Jun 07 2009 19:52:34 +0000
Subject: [PATCH 313/3559] /* Preventing files/directories from being scanned for provides (pre-scan filtering) */


---

diff --git a/Packaging:AutoProvidesAndRequiresFiltering.mw b/Packaging:AutoProvidesAndRequiresFiltering.mw
index e91f20a..2eda7b9 100644
--- a/Packaging:AutoProvidesAndRequiresFiltering.mw
+++ b/Packaging:AutoProvidesAndRequiresFiltering.mw
@@ -80,14 +80,12 @@ The '''%filter_provides_in''' macro is used to define the files or directories t
 
 We can filter by regex:
 
-# we don't want to provide private Perl extension libs
 %filter_provides_in %{perl_vendorarch}/.*\\.so$ 
 %filter_provides_in -P %{perl_archlib}/(?!CORE/libperl).*\\.so$ 
 

 
 Or by anything matching, say, a directory:
 
-# we don't want to either provide or require anything from _docdir, per policy
 %filter_provides_in %{_docdir}
 

 

From e5b72bfa66af187ab6fac475bcc7fc79c6f11a29 Mon Sep 17 00:00:00 2001
From: Cweyl 
Date: Jun 07 2009 19:54:49 +0000
Subject: [PATCH 314/3559] /* Summary */ add to Category:Packaging_guidelines_drafts


---

diff --git a/Packaging:AutoProvidesAndRequiresFiltering.mw b/Packaging:AutoProvidesAndRequiresFiltering.mw
index 2eda7b9..8f90a76 100644
--- a/Packaging:AutoProvidesAndRequiresFiltering.mw
+++ b/Packaging:AutoProvidesAndRequiresFiltering.mw
@@ -1,3 +1,5 @@
+[[Category:Packaging_guidelines_drafts]]
+
 == Summary ==
 
 RPM has no general or standard mechanism to enable filtering of auto-generated requires and provides; this guideline describes how Fedora has implemented such a system.

From 4f8cc14af4aa5bdb9ed6a714dd840bfe18517435 Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Jun 12 2009 13:21:29 +0000
Subject: [PATCH 315/3559] Add upstream, conflicting package name, potentially conflicting files sections


---

diff --git a/Packaging:Conflicts.mw b/Packaging:Conflicts.mw
index 4c98084..7a1b2cf 100644
--- a/Packaging:Conflicts.mw
+++ b/Packaging:Conflicts.mw
@@ -5,7 +5,7 @@
 '''Author:''' [[TomCallaway|  Tom 'spot' Callaway]] 

 '''Revision:''' 0.06

 '''Initial Draft:''' Tuesday Dec 5, 2006

-'''Last Revised:''' Tuesday Apr 10, 2007

+'''Last Revised:''' Friday June 12, 2009

 
 
 
@@ -71,6 +71,46 @@ There are many types of files which can conflict between multiple packages. Fedo
 * Convince upstream to rename the binaries to something less generic (or just less conflicting).
 * In the case where the conflicting binaries provide the same functionality, you can then rename the binaries with a prefix, and use "alternatives" to let the end user to select which generic name is the default. Note that this is usually not the case.
 
+=== Approaching Upstream ===
+
+When renaming or putting files into subdirectories, it is a good idea to try
+to get upstream to rename their conflicting files (for instance if they both had commands named %{_bindir}/trash).  Doing some research about which has been around longer may be useful in this case but may or may not be persuasive to upstream.
+
+If neither upstream renames, we would then approach other distributions (distributions-list[at]freedesktop.org is a good place to discuss this) about renaming that can be done in all distros.  That helps end users going from one distro to another to have consistency.  Length of time that the projects have been around, how popular each is, and numerous other factors may play a role in this decision.  Once a decision is made, we would rename the Fedora packages to match.
+
+== Potential Conflicting Files ==
+
+We don't just try to avoid conflicts with existing packages within Fedora but
+also potential conflicts.  This is because the first package to enter Fedora is
+not always the one that should take on the name.  There are several scenarios
+in which this could come into play:
+
+# There is a conflicting package that is not in Fedora yet (found by doing a web search, for instance)
+# There is no conflict yet but the filename is likely to be used by another project (something like /usr/bin/parser)
+
+In the first case, where a conflicting package is known to exist but is not yet in Fedora, we should go through the process of determining which package has a more valid claim to the name and rename the files in the package we're including if it doesn't have the more valid claim.  If you think your situation is unique, please send email to fedora-devel-list[at]redhat.com to make your case.
+
+In the second case, where there is no known package to conflict with at this time, it is up to the packager to make a decision.  Note that it is encouraged that you at least speak to upstream about the potential for conflicts.  However, we can hope that any later projects that attempt to use that name can be persuaded to rename based on this project being around longer.
+
+=== Standard Commands ===
+
+Common names are allowed for standard commands since those will be the
+only commands to implement them.  Standard commands include things
+provided for in published and widely implemented standards like POSIX
+and de facto standards such as a program that has traditionally been
+shipped with a certain filename as part of a large number of Unix
+variants.  If in doubt, send a message to fedora-devel-list[at]redhat.com
+with details of what standards
+the command appears in, how long it's been available on what Unix
+systems, and whether you've found any conflicting programs that
+implement a substantially different command with the same filename.
+
+== Conflicting Package Names ==
+
+Just as files can conflict, package names can as well. Conflicting package names '''MUST''' be resolved. Package names which differ only in case are still considered to be conflicting. You should follow the same basic steps outlined in [[#Approaching_Upstream]]
+
+Renaming packages and replacing them with others can be difficult if it has to occur at a later time (for instance, upgrade paths can become complex in these situations) so it is even more important to be aware of potential conflicts here than it is with filenames.
+
 {{Anchor|OtherUsesOfConflicts}}
 == Other Uses of Conflicts: ==
 If you find yourself in a situation where you feel that your package has to conflict with another package (either explicitly or implicitly), but does not fit the documented accepted cases above, then you need to make your case to the [[Packaging/Committee |Fedora Packaging Committee]]. If they agree, then, and only then can you use Conflicts: in a Fedora package. Remember, whenever you use Conflicts:, you are also required to include the reasoning in a comment next to the Conflicts: entry, so that it will be abundantly clear why it needed to exist.

From 7d41c2b88e17cb44db842c684ecd7b7a6b6fffc4 Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Jun 12 2009 13:26:47 +0000
Subject: [PATCH 316/3559] Add link to package conflicts


---

diff --git a/Packaging:Naming.mw b/Packaging:Naming.mw
index 80d86e1..50637de 100644
--- a/Packaging:Naming.mw
+++ b/Packaging:Naming.mw
@@ -60,6 +60,9 @@ When deciding how to transliterate a package name, the Fedora packager should lo
 === Extra Provides ===
 Transliterated packages may Provide: the original, non-transliterated name, but are not required to do so.
 
+== Conflicting Package Names ==
+Conflicting package names, even if they differ by case alone, are not allowed.  Please see [[Packaging:Conflicts#Conflicting Package Names]] for more details.
+
 {{Anchor|MultiplePackages}}
 == Multiple packages with the same base name ==
 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. One package should use the base name with no versions and all other addons should note their version in the name.

From 314e74b8c246418e9624506265fc0313089d34a9 Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Jun 12 2009 13:30:54 +0000
Subject: [PATCH 317/3559] Conflcts Guidelines done


---

diff --git a/Packaging:GuidelinesTodo.mw b/Packaging:GuidelinesTodo.mw
index 5e47981..4054aaf 100644
--- a/Packaging:GuidelinesTodo.mw
+++ b/Packaging:GuidelinesTodo.mw
@@ -13,7 +13,7 @@ Status should be one of:
 |-
 |ratify||Phase out Buildroot||abadger1999||2009-06-02||https://fedoraproject.org/wiki/Phase_out_buildroot_tag_%28draft%29
 |-
-|writeup||Common Package Names||abadger1999||2009-04-14||[[Common package names packaging guideline draft]]
+|announce||Common Package Names||abadger1999||2009-04-14||[[Common package names packaging guideline draft]]
 |-
 |writeup||Using Alternatives||[[User:Rathann|rathann]]||2009-04-14||[[PackagingDrafts/UsingAlternatives]]
 |-

From 222db5408febbf376bd928100e123944d52332b6 Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Jun 12 2009 13:36:01 +0000
Subject: [PATCH 318/3559] This was approved


---

diff --git a/Packaging:Globus.mw b/Packaging:Globus.mw
index a186ec4..5044ded 100644
--- a/Packaging:Globus.mw
+++ b/Packaging:Globus.mw
@@ -1,5 +1,3 @@
-{{Draft}}
-
 This document describes the guidelines and conventions for packaging components from the Globus Toolkit in Fedora. The following guidelines applies to the components of the Globus Toolkit written in C. A future version of the guidelines may address the packaging of components written in java as well.
 
 == What is the Globus Toolkit? ==
@@ -838,3 +836,5 @@ rm -rf $RPM_BUILD_ROOT
 * Tue May  5 2009 Mattias Ellert  - 10.2-3
 - Autogenerated
 

+
+[[Category:Packaging guidelines]]

From 14d207abae782c9654e15a96c44db50293984841 Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Jun 12 2009 13:36:35 +0000
Subject: [PATCH 319/3559] Add Packaging Guideline Category


---

diff --git a/Packaging:Naming.mw b/Packaging:Naming.mw
index 50637de..1cafe78 100644
--- a/Packaging:Naming.mw
+++ b/Packaging:Naming.mw
@@ -451,4 +451,4 @@ As Fedora has switched TeX environments in the past, TeX packages should not
 be named after the TeX environment (TeX Live or teTeX) but instead should
 carry the prefix "tex-".
 
-[[Category:Extras]]
+[[Category:Packaging_guidelines]]

From 3e15a505c4e6ed0f1ea7ebe317c7199344ed0670 Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Jun 12 2009 13:39:04 +0000
Subject: [PATCH 321/3559] Add Globus Toolkit; category


---

diff --git a/Packaging:Guidelines.mw b/Packaging:Guidelines.mw
index 21979ce..dcd798d 100644
--- a/Packaging:Guidelines.mw
+++ b/Packaging:Guidelines.mw
@@ -1018,6 +1018,10 @@ Guidelines for Emacs/X-Emacs packages: [[Packaging/Emacs]]
 === Fonts ===
 Guidelines for font packages: [[Packaging/FontsPolicy]] 
 
+{{Anchor|GlobusGuidelines}}
+=== Globus Toolkit ===
+Guidelines for packaging pieces of the Globus Toolkit [[Packaging:Globus]]
+
 {{Anchor|HaskellGuidelines}}
 === Haskell ===
 Guidelines for Haskell packages: [[Packaging/Haskell]]
@@ -1069,3 +1073,5 @@ Guidelines for Sugar Activity packages: [[Packaging/SugarActivityGuidelines]]
 {{Anchor|TclGuidelines}}
 === Tcl/Tk ===
 Guidelines for Tcl/Tk extension packages: [[Packaging/Tcl]]
+
+[[Category:Packaging guidelines]]

From 3481c74dcf18da7686014d43c5b1ddabc84c3b0e Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Jun 12 2009 13:42:48 +0000
Subject: [PATCH 322/3559] Change Packaging/ to Packaging:


---

diff --git a/Packaging:Guidelines.mw b/Packaging:Guidelines.mw
index dcd798d..d097a4f 100644
--- a/Packaging:Guidelines.mw
+++ b/Packaging:Guidelines.mw
@@ -4,12 +4,12 @@
 
 It is the reviewer's responsibility to point out specific problems with a package and a packager's responsibility to deal with those issues. The reviewer and packager work together to determine the severity of the issues (whether they block a package or can be worked on after the package is in the repository.) The Packaging Guidelines are a collection of common issues and the severity that should be placed on them. While these guidelines should not be ignored, they should also not be blindly followed. If you think that your package should be exempt from part of the Guidelines, please bring the issue to the Fedora Packaging Committee.
 
-Please remember that any package that you submit must also conform to the [[Packaging/ReviewGuidelines|  Review Guidelines]] .
+Please remember that any package that you submit must also conform to the [[Packaging:ReviewGuidelines|  Review Guidelines]] .
 
 '''Author:''' [[TomCallaway|  Tom 'spot' Callaway]]  (based on many other documents)

 '''Revision:''' 0.99

 '''Initial Draft:''' Wednesday Feb 23, 2005

-'''Last Revised:''' Tuesday Apr 14, 2009

+'''Last Revised:''' Friday June 12, 2009

 
 {{Anchor|Naming}}
 == Naming ==
@@ -18,7 +18,7 @@ You should go through the [[Packaging:NamingGuidelines]]  to ensure that your pa
 
 == Version and Release ==
 
-Documentation covering the proper way to use the Version and Release fields can be found here: [[Packaging/NamingGuidelines#Package_Version]]
+Documentation covering the proper way to use the Version and Release fields can be found here: [[Packaging:NamingGuidelines#Package_Version]]
 
 {{Anchor|Legal}}
 == Legal ==
@@ -48,7 +48,7 @@ Packages which require non-open source components to build are also not permitte
 {{Anchor|SourceRequirementExceptions}}
 === Exceptions ===
 * Some software (usually related to compilers or cross-compiler environments) cannot be built without the use of a previous toolchain or development environment (open source). If you have a package which meets this criteria, contact the Fedora Packaging Committee for approval.
-* An exception is made for binary firmware, as long as it meets the requirements documented here: [[Packaging/LicensingGuidelines#BinaryFirmware|BinaryFirmware]]
+* An exception is made for binary firmware, as long as it meets the requirements documented here: [[Packaging:LicensingGuidelines#BinaryFirmware|BinaryFirmware]]
 
 {{Anchor|Spec Legibility}}
 
@@ -146,10 +146,10 @@ You must use one of the following formats:
 == Tags ==
 *The ''Packager'' tag should not be used in spec files. The identities of the packagers are evident from the changelog entries. By not using the ''Packager'' tag, you also avoid seeing bad binaries rebuilt by someone else with your name in the header.  See also the '''Maximum RPM definition of the Packager tag''' at [http://www.rpm.org/max-rpm/s1-rpm-inside-tags.html#S3-RPM-INSIDE-PACKAGER-TAG www.rpm.org] .  If you need to include information about the packager in the rpms ''you'' built, use %packager in your ~/.rpmmacros instead.
 *The ''Vendor'' tag should not be used. It is set automatically by the build system.
-*The ''Copyright'' tag is deprecated. Use the ''License'' tag instead, as detailed in [[Packaging/LicensingGuidelines]] . Contact the upstream author if there is any doubt about what license the software is distributed under.
+*The ''Copyright'' tag is deprecated. Use the ''License'' tag instead, as detailed in [[Packaging:LicensingGuidelines]] . Contact the upstream author if there is any doubt about what license the software is distributed under.
 *The ''Summary'' tag value should not end in a period. If this bothers you from a grammatical point of view, sit down, take a deep breath, and get over it.
 *Usually, the ''PreReq'' tag should be replaced by plain ''Requires''.   For more info, see Maximum RPM snapshot's  [http://www.rpm.org/max-rpm-snapshot/s1-rpm-depend-manual-dependencies.html#S3-RPM-DEPEND-FINE-GRAINED fine grained dependencies chapter] .
-* The ''Source'' tag documents where to find the upstream sources for the rpm.  In most cases this should be a complete URL to the upstream tarball.  For special cases, please see the [[Packaging/SourceURL]]  Guidelines
+* The ''Source'' tag documents where to find the upstream sources for the rpm.  In most cases this should be a complete URL to the upstream tarball.  For special cases, please see the [[Packaging:SourceURL]]  Guidelines
 
 {{Anchor|BuildRoot}}
 
@@ -186,10 +186,10 @@ This is to ensure that the ''BuildRoot'' will be created fresh during the 
 
 {{Anchor|Clean}}
 == %clean ==
-Each package must have a %clean section, which contains rm -rf %{buildroot} ([[Packaging/Guidelines#UsingBuildRootOptFlags|or $RPM_BUILD_ROOT]]).

+Each package must have a %clean section, which contains rm -rf %{buildroot} ([[Packaging:Guidelines#UsingBuildRootOptFlags|or $RPM_BUILD_ROOT]]).

 

 In the past, some packages checked that %{buildroot} was not / before deleting it. This is not necessary in Fedora, for several reasons:
-* All Fedora packages are required to have a sane ''BuildRoot'', see: [[Packaging/Guidelines#BuildRoot]]
+* All Fedora packages are required to have a sane ''BuildRoot'', see: [[Packaging:Guidelines#BuildRoot]]
 * In Fedora 10 (and newer), rpm sets a sane ''BuildRoot'' by default (and ignores any spec defined ''BuildRoot'')
 
 {{Anchor|Requires}}
@@ -341,7 +341,7 @@ An example of this are the gettext and libgcj packages. gettext is usually a dev
 {{Anchor|Exceptions}}
 === Exceptions ===
 
-There is no need to include the following packages or their dependencies as BuildRequires because they would occur too often. These packages are considered the minimum build environment.  The derived list of all deps pulled in by this list is on [[Packaging/FullExceptionList]] .
+There is no need to include the following packages or their dependencies as BuildRequires because they would occur too often. These packages are considered the minimum build environment.  The derived list of all deps pulled in by this list is on [[Packaging:FullExceptionList]] .
 
 
 bash
@@ -409,7 +409,7 @@ Compilers used to build packages should honor the applicable compiler flags set 
 
 {{Anchor|Debuginfo}}
 == Debuginfo packages ==
-Packages should produce useful -debuginfo packages, or explicitly disable them when it is not possible to generate a useful one but rpmbuild would do it anyway.  Whenever a -debuginfo package is explicitly disabled, an explanation why it was done is required in the specfile.  Debuginfo packages are discussed in more detail in a separate document, [[Packaging/Debuginfo]] .
+Packages should produce useful -debuginfo packages, or explicitly disable them when it is not possible to generate a useful one but rpmbuild would do it anyway.  Whenever a -debuginfo package is explicitly disabled, an explanation why it was done is required in the specfile.  Debuginfo packages are discussed in more detail in a separate document, [[Packaging:Debuginfo]] .
 
 {{Anchor|DevelPackages}}
 == Devel Packages ==
@@ -539,7 +539,7 @@ Don't use %config or %config(noreplace) under /usr. /usr is deemed to not contai
 {{Anchor|Initscripts}}
 == Initscripts ==
 
-Currently, only SystemV-style initscripts are supported in Fedora. There are detailed guidelines for SysV-style initscripts here: [[Packaging/SysVInitScript]] 
+Currently, only SystemV-style initscripts are supported in Fedora. There are detailed guidelines for SysV-style initscripts here: [[Packaging:SysVInitScript]] 
 
 {{Anchor|desktop}}
 == Desktop files ==
@@ -601,7 +601,7 @@ desktop-file-validate %{buildroot}/%{_datadir}/applications/foo.desktop
 {{Anchor|macros}}
 
 == Macros ==
-Use macros instead of hard-coded directory names (see [[Packaging/RPMMacros]] ).
+Use macros instead of hard-coded directory names (see [[Packaging:RPMMacros]] ).
 
 Having macros in a Source: or Patch: line is a matter of style.  Some people enjoy the ready readability of a source line without macros. Others prefer the ease of updating for new versions when macros are used.  In all cases, remember to be consistent in your spec file and verify that the URLs you list are valid.  spectool (from the rpmdevtools package) can aid you in checking that whether the URL contains macros or not.
 
@@ -739,7 +739,7 @@ to your ~/.rpmmacros file -- even on UP machines -- as this will ex
 
 {{Anchor|Scriptlets}}
 == Scriptlets ==
-Great care should be taken when using scriptlets in Fedora packages. If scriptlets are used, those scriptlets must be sane. Some common scriptlets are documented here: [[Packaging/ScriptletSnippets]].
+Great care should be taken when using scriptlets in Fedora packages. If scriptlets are used, those scriptlets must be sane. Some common scriptlets are documented here: [[Packaging:ScriptletSnippets]].
 
 {{Anchor|reqprepost}}
 === Scriptlets requirements ===
@@ -858,7 +858,7 @@ Foo-Animal-Llama puts files into /usr/share/Foo/Animal/Llama
 

 Neither package depends on the other one. Neither package depends on any other package which owns the /usr/share/Foo/Animal/ directory. In this case, each package must own the /usr/share/Foo/Animal/ directory.
 
-In all cases we are guarding against unowned directories being present on a system.  Please see [[Packaging/UnownedDirectories]] for the details.
+In all cases we are guarding against unowned directories being present on a system.  Please see [[Packaging:UnownedDirectories]] for the details.
 
 {{Anchor|DuplicateFiles}}
 === Duplicate Files ===
@@ -876,7 +876,7 @@ Unless you have a very good reason to deviate from that, you should use %d
 {{Anchor|UsersAndGroups}}
 == Users and Groups ==
 
-Some packages require or benefit from dedicated runtime user and/or group accounts.  Guidelines for handling these cases are in a separate [[Packaging/UsersAndGroups]]  document.
+Some packages require or benefit from dedicated runtime user and/or group accounts.  Guidelines for handling these cases are in a separate [[Packaging:UsersAndGroups]]  document.
 
 {{Anchor|WebApplications}}
 == Web Applications ==
@@ -890,10 +890,10 @@ Web applications packaged in Fedora should put their content into /usr/share/%{n
 {{Anchor|Conflicts}}
 == Conflicts ==
 
-Whenever possible, Fedora packages should avoid conflicting with each other. Unfortunately, this is not always possible. For full details on Fedora's Conflicts policy, see: [[Packaging/Conflicts]] .
+Whenever possible, Fedora packages should avoid conflicting with each other. Unfortunately, this is not always possible. For full details on Fedora's Conflicts policy, see: [[Packaging:Conflicts]] .
 
 == No External Kernel Modules ==
-{{:Packaging/KernelModules}}
+{{:Packaging:KernelModules}}
 
 {{Anchor|NoFilesOrDirectoriesUnderSrv}}
 == No Files or Directories under /srv ==
@@ -919,7 +919,7 @@ Fedora packages should make every effort to avoid having multiple, separate, ups
 
 {{Anchor|AvoidFontBundling}}
 === Avoid bundling of fonts in other packages ===
-Fonts in general-purpose formats such as Type1, OpenType TT (TTF) or OpenType CFF (OTF) are subject to specific packaging guidelines ([[Packaging/FontsPolicy|1]]), and should never be packaged in a private application directory instead of the system-wide font repositories.
+Fonts in general-purpose formats such as Type1, OpenType TT (TTF) or OpenType CFF (OTF) are subject to specific packaging guidelines ([[Packaging:FontsPolicy|1]]), and should never be packaged in a private application directory instead of the system-wide font repositories.
 For more information, see: [[Packaging:FontsPolicy#Package_layout_for_fonts]].
 
 == All patches should have an upstream bug link or comment ==
@@ -1004,19 +1004,19 @@ Cons:
 {{Anchor|ApplicationSpecificGuidelines}}
 == Application Specific Guidelines ==
 
-Some applications have specific guidelines written for them, located on their own pages in the Packaging/ hierarchy.
+Some applications have specific guidelines written for them, located on their own pages in the Packaging: Namespace.
 
 {{Anchor|EclipseGuidelines}}
 === Eclipse ===
-Guidelines for Eclipse plugin packages: [[Packaging/EclipsePlugins]] 
+Guidelines for Eclipse plugin packages: [[Packaging:EclipsePlugins]] 
 
 {{Anchor|EmacsGuidelines}}
 === Emacs ===
-Guidelines for Emacs/X-Emacs packages: [[Packaging/Emacs]] 
+Guidelines for Emacs/X-Emacs packages: [[Packaging:Emacs]] 
 
 {{Anchor|FontGuidelines}}
 === Fonts ===
-Guidelines for font packages: [[Packaging/FontsPolicy]] 
+Guidelines for font packages: [[Packaging:FontsPolicy]] 
 
 {{Anchor|GlobusGuidelines}}
 === Globus Toolkit ===
@@ -1024,54 +1024,54 @@ Guidelines for packaging pieces of the Globus Toolkit [[Packaging:Globus]]
 
 {{Anchor|HaskellGuidelines}}
 === Haskell ===
-Guidelines for Haskell packages: [[Packaging/Haskell]]
+Guidelines for Haskell packages: [[Packaging:Haskell]]
 
 {{Anchor|JavaGuidelines}}
 === Java ===
-Guidelines for java packages: [[Packaging/Java]] 
+Guidelines for java packages: [[Packaging:Java]] 
 
 {{Anchor|LispGuidelines}}
 === Lisp ===
-Guidelines for lisp packages: [[Packaging/Lisp]]
+Guidelines for lisp packages: [[Packaging:Lisp]]
 
 {{Anchor|MonoGuidelines}}
 === Mono ===
-Guidelines for Mono packages: [[Packaging/Mono]] 
+Guidelines for Mono packages: [[Packaging:Mono]] 
 
 {{Anchor|OCamlGuidelines}}
 === OCaml ===
-Guidelines for OCaml packages: [[Packaging/OCaml]] 
+Guidelines for OCaml packages: [[Packaging:OCaml]] 
 
 {{Anchor|OpenOffice.orgGuidelines}}
 === OpenOffice.org ===
-Guidelines for OpenOffice.org extension packages: [[Packaging/OpenOffice.orgExtensions]] 
+Guidelines for OpenOffice.org extension packages: [[Packaging:OpenOffice.orgExtensions]] 
 
 {{Anchor|PerlGuidelines}}
 === Perl ===
-Guidelines for Perl packages: [[Packaging/Perl]] 
+Guidelines for Perl packages: [[Packaging:Perl]] 
 
 {{Anchor|PHPGuidelines}}
 === PHP ===
-Guidelines for PHP packages: [[Packaging/PHP]] 
+Guidelines for PHP packages: [[Packaging:PHP]] 
 
 {{Anchor|PythonGuidelines}}
 === Python ===
-Guidelines for Python addon modules: [[Packaging/Python]] 
+Guidelines for Python addon modules: [[Packaging:Python]] 
 
 {{Anchor|RGuidelines}}
 === R ===
-Guidelines for R module packages: [[Packaging/R]] 
+Guidelines for R module packages: [[Packaging:R]] 
 
 {{Anchor|RubyGuidelines}}
 === Ruby ===
-Guidelines for Ruby packages: [[Packaging/Ruby]] 
+Guidelines for Ruby packages: [[Packaging:Ruby]] 
 
 {{Anchor|SugarGuidelines}}
 === Sugar ===
-Guidelines for Sugar Activity packages: [[Packaging/SugarActivityGuidelines]] 
+Guidelines for Sugar Activity packages: [[Packaging:SugarActivityGuidelines]] 
 
 {{Anchor|TclGuidelines}}
 === Tcl/Tk ===
-Guidelines for Tcl/Tk extension packages: [[Packaging/Tcl]]
+Guidelines for Tcl/Tk extension packages: [[Packaging:Tcl]]
 
 [[Category:Packaging guidelines]]

From 9f63ca2ad5b86d4bb850ce555a2c35145c78d68e Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Jun 12 2009 13:45:19 +0000
Subject: [PATCH 323/3559] Add Packaging Guideline Category


---

diff --git a/Packaging:Conflicts.mw b/Packaging:Conflicts.mw
index 7a1b2cf..04b67ac 100644
--- a/Packaging:Conflicts.mw
+++ b/Packaging:Conflicts.mw
@@ -114,3 +114,5 @@ Renaming packages and replacing them with others can be difficult if it has to o
 {{Anchor|OtherUsesOfConflicts}}
 == Other Uses of Conflicts: ==
 If you find yourself in a situation where you feel that your package has to conflict with another package (either explicitly or implicitly), but does not fit the documented accepted cases above, then you need to make your case to the [[Packaging/Committee |Fedora Packaging Committee]]. If they agree, then, and only then can you use Conflicts: in a Fedora package. Remember, whenever you use Conflicts:, you are also required to include the reasoning in a comment next to the Conflicts: entry, so that it will be abundantly clear why it needed to exist.
+
+[[Category: Packaging guidelines]]

From cb5536b408e0c84ab71bfbee6a23b9f5a9e20014 Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Jun 12 2009 13:47:59 +0000
Subject: [PATCH 324/3559] Approved.  Change Category


---

diff --git a/Packaging:WordPress_plugin_packaging_guidelines.mw b/Packaging:WordPress_plugin_packaging_guidelines.mw
index 08ddbc2..c695c81 100644
--- a/Packaging:WordPress_plugin_packaging_guidelines.mw
+++ b/Packaging:WordPress_plugin_packaging_guidelines.mw
@@ -105,4 +105,4 @@ rm -rf %{buildroot}
 
 

 
-[[Category:Packaging guidelines drafts|WordPress]]
+[[Category:Packaging guidelines]]

From 835beb595046e066d3e829e99ea35e41f694dac4 Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Jun 12 2009 13:50:00 +0000
Subject: [PATCH 326/3559] Add Wordpress


---

diff --git a/Packaging:Guidelines.mw b/Packaging:Guidelines.mw
index d097a4f..8b32ac2 100644
--- a/Packaging:Guidelines.mw
+++ b/Packaging:Guidelines.mw
@@ -1073,5 +1073,9 @@ Guidelines for Sugar Activity packages: [[Packaging:SugarActivityGuidelines]]
 {{Anchor|TclGuidelines}}
 === Tcl/Tk ===
 Guidelines for Tcl/Tk extension packages: [[Packaging:Tcl]]
+{{Anchor|TclGuidelines}}
+
+=== Wordpress ===
+Guidelines for Wordpress extension packages: [[Packaging:WordPress plugin packaging guidelines]]
 
 [[Category:Packaging guidelines]]

From c6b895e1a33e4d1ff2c97818476cd8d5acef1f2d Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Jun 12 2009 13:50:46 +0000
Subject: [PATCH 327/3559] Globus and Wordpress written up


---

diff --git a/Packaging:GuidelinesTodo.mw b/Packaging:GuidelinesTodo.mw
index 4054aaf..a1f770c 100644
--- a/Packaging:GuidelinesTodo.mw
+++ b/Packaging:GuidelinesTodo.mw
@@ -17,11 +17,11 @@ Status should be one of:
 |-
 |writeup||Using Alternatives||[[User:Rathann|rathann]]||2009-04-14||[[PackagingDrafts/UsingAlternatives]]
 |-
-|writeup||WordPress plugins||[[User:Ianweller|Ian Weller]]||2009-04-14||[[User:Ianweller/WordPress plugin packaging guidelines (draft)]]
+|announce||WordPress plugins||[[User:Ianweller|Ian Weller]]||2009-04-14||[[User:Ianweller/WordPress plugin packaging guidelines (draft)]]
 |-
 |writeup||GConf scriptlets||abadger1999||2009-05-12||[[GConf Scriptlets (draft)]] Improve GConf scriplet handling.
 |-
-|writeup||Globus||ellert||2009-05-12||[[PackagingDrafts/Globus]] Draft packaging guidelines for packages from the Globus Toolkit.
+|announce||Globus||ellert||2009-05-12||[[PackagingDrafts/Globus]] Draft packaging guidelines for packages from the Globus Toolkit.
 |}
 
 {{:PackagingDrafts/DraftsTodo}}

From 1752f1d238da81a69e01b19e6f642a5011515127 Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Jun 12 2009 17:41:23 +0000
Subject: [PATCH 328/3559] Add No bundling rule


---

diff --git a/Packaging:ReviewGuidelines.mw b/Packaging:ReviewGuidelines.mw
index 9d9eb23..fc4fc41 100644
--- a/Packaging:ReviewGuidelines.mw
+++ b/Packaging:ReviewGuidelines.mw
@@ -45,6 +45,7 @@ There are many many things to check for a review. This list is provided to assis
 * '''MUST''': If a package includes something as %doc, it must not affect the runtime of the application. To summarize: If it is in %doc, the program must run properly if it is not present. [[Packaging/Guidelines#PackageDocumentation|Packaging Guidelines: Package Documentation]]

 * '''MUST''': Header files must be in a -devel package. [[Packaging/Guidelines#DevelPackages|Packaging Guidelines: Devel Packages]]

 * '''MUST''': Static libraries must be in a -static package. [[Packaging/Guidelines#StaticLibraries|Packaging Guidelines: Packaging Static Libraries]]

+* '''MUST''': Packages must NOT bundle copies of system libraries.[[Packaging:Guidelines#Duplication_of_system_libraries|Packaging Guidelines: Duplication of System Libraries]]

 * '''MUST''': Packages containing pkgconfig(.pc) files must 'Requires: pkgconfig' (for directory ownership and usability). [[Packaging/Guidelines#PkgconfigFiles|Packaging Guidelines: Pkgconfig Files]]

 * '''MUST''': If a package contains library files with a suffix (e.g. libfoo.so.1.1), then library files that end in .so (without suffix) must go in a -devel package. [[Packaging/Guidelines#DevelPackages|Packaging Guidelines: Devel Packages]]

 * '''MUST''': In the vast majority of cases, devel packages must require the base package using a fully versioned dependency: Requires: %{name} = %{version}-%{release}  [[Packaging/Guidelines#RequiringBasePackage|Packaging Guidelines: Requiring Base Package]]


From 060e5843a61972c625fbd3d181e3adf0d27b867e Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Jun 13 2009 00:06:08 +0000
Subject: [PATCH 329/3559] Undo revision 107950 by [[Special:Contributions/Toshio|Toshio]] ([[User talk:Toshio|Talk]])


---

diff --git a/Packaging:ReviewGuidelines.mw b/Packaging:ReviewGuidelines.mw
index fc4fc41..9d9eb23 100644
--- a/Packaging:ReviewGuidelines.mw
+++ b/Packaging:ReviewGuidelines.mw
@@ -45,7 +45,6 @@ There are many many things to check for a review. This list is provided to assis
 * '''MUST''': If a package includes something as %doc, it must not affect the runtime of the application. To summarize: If it is in %doc, the program must run properly if it is not present. [[Packaging/Guidelines#PackageDocumentation|Packaging Guidelines: Package Documentation]]

 * '''MUST''': Header files must be in a -devel package. [[Packaging/Guidelines#DevelPackages|Packaging Guidelines: Devel Packages]]

 * '''MUST''': Static libraries must be in a -static package. [[Packaging/Guidelines#StaticLibraries|Packaging Guidelines: Packaging Static Libraries]]

-* '''MUST''': Packages must NOT bundle copies of system libraries.[[Packaging:Guidelines#Duplication_of_system_libraries|Packaging Guidelines: Duplication of System Libraries]]

 * '''MUST''': Packages containing pkgconfig(.pc) files must 'Requires: pkgconfig' (for directory ownership and usability). [[Packaging/Guidelines#PkgconfigFiles|Packaging Guidelines: Pkgconfig Files]]

 * '''MUST''': If a package contains library files with a suffix (e.g. libfoo.so.1.1), then library files that end in .so (without suffix) must go in a -devel package. [[Packaging/Guidelines#DevelPackages|Packaging Guidelines: Devel Packages]]

 * '''MUST''': In the vast majority of cases, devel packages must require the base package using a fully versioned dependency: Requires: %{name} = %{version}-%{release}  [[Packaging/Guidelines#RequiringBasePackage|Packaging Guidelines: Requiring Base Package]]


From ba9ba8d9fa0a33bc4ff72a82896bdb615cea5d7b Mon Sep 17 00:00:00 2001
From: Spot 
Date: Jul 06 2009 20:34:34 +0000
Subject: [PATCH 330/3559] 0.16: Update new tags


---

diff --git a/Packaging:DistTag.mw b/Packaging:DistTag.mw
index 5288766..45ba47d 100644
--- a/Packaging:DistTag.mw
+++ b/Packaging:DistTag.mw
@@ -6,9 +6,9 @@ These are the guidelines for using the %{dist} tag in Fedora. Using
 You should consider this document as an addendum to the [[Packaging/NamingGuidelines]] .
 
 '''Author:''' [[User:Spot|  Tom 'spot' Callaway]]  

-'''Revision:''' 0.15 

+'''Revision:''' 0.16 

 '''Initial Draft:''' Monday Mar 21, 2005

-'''Last Revised:''' Tuesday, June 03 2008

+'''Last Revised:''' Monday, July 06 2008

 
 
 
@@ -56,6 +56,8 @@ Fedora, Fedora Core:
 8: .fc8
 9: .fc9
 10: .fc10
+11: .fc11
+12: .fc12
 
 Development:
 

From dc4a3086fa96974727e5cff72c9e5475e30fe569 Mon Sep 17 00:00:00 2001
From: Spot 
Date: Jul 06 2009 20:35:00 +0000
Subject: [PATCH 331/3559] *Empty MediaWiki Message*


---

diff --git a/Packaging:DistTag.mw b/Packaging:DistTag.mw
index 45ba47d..2f93fb2 100644
--- a/Packaging:DistTag.mw
+++ b/Packaging:DistTag.mw
@@ -8,7 +8,7 @@ You should consider this document as an addendum to the [[Packaging/NamingGuidel
 '''Author:''' [[User:Spot|  Tom 'spot' Callaway]]  

 '''Revision:''' 0.16 

 '''Initial Draft:''' Monday Mar 21, 2005

-'''Last Revised:''' Monday, July 06 2008

+'''Last Revised:''' Monday, July 06 2009

 
 
 

From 9e09f5b320503e33ef72748ae030ceea1c33b582 Mon Sep 17 00:00:00 2001
From: Tibbs 
Date: Jul 13 2009 00:11:14 +0000
Subject: [PATCH 332/3559] Indent the scriptlets to be slightly more readable.


---

diff --git a/Packaging:GCJGuidelines.mw b/Packaging:GCJGuidelines.mw
index dae6bc9..b6a338b 100644
--- a/Packaging:GCJGuidelines.mw
+++ b/Packaging:GCJGuidelines.mw
@@ -35,10 +35,10 @@ BuildArch:      noarch
 

 1. Add the following to the package's %post and %postun sections, creating the sections if necessary:
 %if %{with_gcj}
-if [ -x %{_bindir}/rebuild-gcj-db ] 
-then
-%{_bindir}/rebuild-gcj-db
-fi
+  if [ -x %{_bindir}/rebuild-gcj-db ] 
+  then
+    %{_bindir}/rebuild-gcj-db
+  fi
 %endif
 

 1. Add the following to the %files section:

From d439989320c9517ff49f7051b9a786e3cf76c9b0 Mon Sep 17 00:00:00 2001
From: Spot 
Date: Jul 21 2009 18:06:21 +0000
Subject: [PATCH 333/3559] 1.0 Add notes about buildroot no longer being required in F10+, no need to delete %buildroot as first step in %install for F10+


---

diff --git a/Packaging:Guidelines.mw b/Packaging:Guidelines.mw
index 8b32ac2..e5a3d20 100644
--- a/Packaging:Guidelines.mw
+++ b/Packaging:Guidelines.mw
@@ -7,9 +7,9 @@ It is the reviewer's responsibility to point out specific problems with a packag
 Please remember that any package that you submit must also conform to the [[Packaging:ReviewGuidelines|  Review Guidelines]] .
 
 '''Author:''' [[TomCallaway|  Tom 'spot' Callaway]]  (based on many other documents)

-'''Revision:''' 0.99

+'''Revision:''' 1.00

 '''Initial Draft:''' Wednesday Feb 23, 2005

-'''Last Revised:''' Friday June 12, 2009

+'''Last Revised:''' Tuesday July 21, 2009

 
 {{Anchor|Naming}}
 == Naming ==
@@ -154,6 +154,7 @@ You must use one of the following formats:
 {{Anchor|BuildRoot}}
 
 == BuildRoot tag ==
+{{admon/note|The RPM in Fedora 10 defines a default buildroot so in Fedora 10 and above it is no longer necessary to define a buildroot tag. Fedora < 10 and EPEL <= 5 still need to have the tag.}}
 
 The ''BuildRoot'' value MUST be below %{_tmppath}/ and MUST contain at least %{name}, %{version} and %{release}. It may invoke mktemp since this is guaranteed to exist on every system. From there, packagers are expected to use a sane ''BuildRoot''.
 
@@ -168,6 +169,8 @@ At one point, the second was a mandatory value, but it is now left to the packag
 
 {{Anchor|PreppingBuildRootForInstall}}
 === Prepping BuildRoot For %install ===
+{{admon/note|The current redhat-rpm-config package in Fedora 10 and newer automatically deletes and creates the buildroot at %install, so in Fedora 10 and newer, it is not necessary for packages to manually Prepare the BuildRoot for install as described below. Fedora < 10 and EPEL <= 5 still need to follow the below guidelines.}}
+
 It is important to properly prepare the ''BuildRoot'' in the %install section of your package before it is used. Every Fedora package MUST have an %install section that begins with either:
 
 

From 937c14d0145f1c063498da41dbb2b2ad77f35dd3 Mon Sep 17 00:00:00 2001
From: Spot 
Date: Jul 21 2009 18:13:56 +0000
Subject: [PATCH 334/3559] *Empty MediaWiki Message*


---

diff --git a/Packaging:Guidelines.mw b/Packaging:Guidelines.mw
index e5a3d20..480af7c 100644
--- a/Packaging:Guidelines.mw
+++ b/Packaging:Guidelines.mw
@@ -154,7 +154,7 @@ You must use one of the following formats:
 {{Anchor|BuildRoot}}
 
 == BuildRoot tag ==
-{{admon/note|The RPM in Fedora 10 defines a default buildroot so in Fedora 10 and above it is no longer necessary to define a buildroot tag. Fedora < 10 and EPEL <= 5 still need to have the tag.}}
+{{admon/note|The RPM in Fedora 10 defines a default buildroot so in Fedora 10 and above it is no longer necessary to define a buildroot tag. Fedora releases older than 10 and EPEL releases older than or equal to 5 still need to have the tag.}}
 
 The ''BuildRoot'' value MUST be below %{_tmppath}/ and MUST contain at least %{name}, %{version} and %{release}. It may invoke mktemp since this is guaranteed to exist on every system. From there, packagers are expected to use a sane ''BuildRoot''.
 
@@ -169,7 +169,7 @@ At one point, the second was a mandatory value, but it is now left to the packag
 
 {{Anchor|PreppingBuildRootForInstall}}
 === Prepping BuildRoot For %install ===
-{{admon/note|The current redhat-rpm-config package in Fedora 10 and newer automatically deletes and creates the buildroot at %install, so in Fedora 10 and newer, it is not necessary for packages to manually Prepare the BuildRoot for install as described below. Fedora < 10 and EPEL <= 5 still need to follow the below guidelines.}}
+{{admon/note|The current redhat-rpm-config package in Fedora 10 and newer automatically deletes and creates the buildroot at %install, so in Fedora 10 and newer, it is not necessary for packages to manually Prepare the BuildRoot for install as described below. Fedora releases older than 10 and EPEL releases older than or equal to 5 still need to follow the below guidelines.}}
 
 It is important to properly prepare the ''BuildRoot'' in the %install section of your package before it is used. Every Fedora package MUST have an %install section that begins with either:
 

From 42b1bb7fc8413e760347b2c35f8ef71ffbcbded5 Mon Sep 17 00:00:00 2001
From: Spot 
Date: Jul 21 2009 20:05:59 +0000
Subject: [PATCH 335/3559] *Empty MediaWiki Message*


---

diff --git a/Packaging:GuidelinesTodo.mw b/Packaging:GuidelinesTodo.mw
index a1f770c..255dd46 100644
--- a/Packaging:GuidelinesTodo.mw
+++ b/Packaging:GuidelinesTodo.mw
@@ -11,7 +11,7 @@ Status should be one of:
 |- style="color: white; background-color: #3074c2; font-weight: bold" 
 |Status||Task Name||Owner||Meeting Date||Notes
 |-
-|ratify||Phase out Buildroot||abadger1999||2009-06-02||https://fedoraproject.org/wiki/Phase_out_buildroot_tag_%28draft%29
+|announce||Phase out Buildroot||abadger1999||2009-06-02||https://fedoraproject.org/wiki/Phase_out_buildroot_tag_%28draft%29
 |-
 |announce||Common Package Names||abadger1999||2009-04-14||[[Common package names packaging guideline draft]]
 |-

From 37070cceb1e402530f8ada29d369dfb79e31c335 Mon Sep 17 00:00:00 2001
From: Jussilehtola 
Date: Jul 26 2009 12:12:11 +0000
Subject: [PATCH 336/3559] Created page with '== Introduction ==  FORTRAN (short for FORmula TRANslator) was the first programming language ever, invented in 1957 and standardized in 1966 [http://en.wikipedia.org/wiki/Fortra...'


---

diff --git a/Packaging:Fortran.mw b/Packaging:Fortran.mw
new file mode 100644
index 0000000..447a375
--- /dev/null
+++ b/Packaging:Fortran.mw
@@ -0,0 +1,22 @@
+== Introduction ==
+
+FORTRAN (short for FORmula TRANslator) was the first programming language ever, invented in 1957 and standardized in 1966 [http://en.wikipedia.org/wiki/Fortran]. The Fortran 77 standard introduced improved support for structured programming such if clauses.
+
+Fortran natively handles matrices, is rather easy to program and was widely adopted in the scientific community. Due to the large amount of legacy code, Fortran is still widely used in computational science.
+
+Fortran 90 presented a modernization of the language to support among others dynamic memory allocation, free-form source input and an argument passing mechanism to support compile time interface checking. Fortran 95 introduced many useful features such as vectorization constructs for high performance computing. 
+
+The Fortran 2003 standard added e.g. access to command line arguments and environment variables. The current standard under development is Fortran 2008.
+
+
+== Fortran packaging ==
+
+Fortran programs in Fedora MUST be compiled using the default Fortran compiler 'gfortran'. As usual, standard Fedora optimization flags %{optflags} MUST be used in the compilation.
+
+The fortran modules files, ending in .mod are files describing a fortran 90 (and above) module API and ABI. These are not like C header files describing an API, they are compiler dependent and arch dependent, and not easily readable by a human being. They are nevertheless searched for in the includes directories by gfortran (in directories specified with -I). Each gfortran release (e.g. from 4.4 to 4.5) may lead to an incompatible change in the .mod files, therefore mass rebuilds of Fortran packages must take place when gfortran is updated.
+
+Fortran can also utilize include files, similar to C headers. The most common filename suffix is '.inc' or '.h', although '.fh' has been used for files that are designed to function as public headers.
+
+Generally Fortran modules that are generated have very general names, thus placing them in the same directory is troublesome. Fortran include files and modules MUST be placed into %{_libdir}/gfortran/%{name}.
+
+To use the modules and include files of foo, one needs to add -I%{_libdir}/gfortran/foo to the compiler flags.

From edd973de71ebc66fe61a72d18fba0c748d6b910a Mon Sep 17 00:00:00 2001
From: Jussilehtola 
Date: Jul 26 2009 12:12:42 +0000
Subject: [PATCH 337/3559] /* Fortran packaging */


---

diff --git a/Packaging:Fortran.mw b/Packaging:Fortran.mw
index 447a375..6bdddde 100644
--- a/Packaging:Fortran.mw
+++ b/Packaging:Fortran.mw
@@ -15,7 +15,7 @@ Fortran programs in Fedora MUST be compiled using the default Fortran com
 
 The fortran modules files, ending in .mod are files describing a fortran 90 (and above) module API and ABI. These are not like C header files describing an API, they are compiler dependent and arch dependent, and not easily readable by a human being. They are nevertheless searched for in the includes directories by gfortran (in directories specified with -I). Each gfortran release (e.g. from 4.4 to 4.5) may lead to an incompatible change in the .mod files, therefore mass rebuilds of Fortran packages must take place when gfortran is updated.
 
-Fortran can also utilize include files, similar to C headers. The most common filename suffix is '.inc' or '.h', although '.fh' has been used for files that are designed to function as public headers.
+Fortran can also use include files, similar to C headers. The most common filename suffix is '.inc' or '.h', although '.fh' has been used for files that are designed to function as public headers.
 
 Generally Fortran modules that are generated have very general names, thus placing them in the same directory is troublesome. Fortran include files and modules MUST be placed into %{_libdir}/gfortran/%{name}.
 

From c9260e4e10436c2cfc15d9aba838d773fabcbfed Mon Sep 17 00:00:00 2001
From: Jussilehtola 
Date: Jul 26 2009 12:13:35 +0000
Subject: [PATCH 338/3559] /* Introduction */


---

diff --git a/Packaging:Fortran.mw b/Packaging:Fortran.mw
index 6bdddde..6e2caa0 100644
--- a/Packaging:Fortran.mw
+++ b/Packaging:Fortran.mw
@@ -1,6 +1,8 @@
+{{admon/warning|This is a draft document}}
+
 == Introduction ==
 
-FORTRAN (short for FORmula TRANslator) was the first programming language ever, invented in 1957 and standardized in 1966 [http://en.wikipedia.org/wiki/Fortran]. The Fortran 77 standard introduced improved support for structured programming such if clauses.
+FORTRAN [http://en.wikipedia.org/wiki/Fortran] (short for FORmula TRANslator) was the first programming language ever, invented in 1957 and standardized in 1966. The Fortran 77 standard introduced improved support for structured programming such if clauses.
 
 Fortran natively handles matrices, is rather easy to program and was widely adopted in the scientific community. Due to the large amount of legacy code, Fortran is still widely used in computational science.
 
@@ -8,7 +10,6 @@ Fortran 90 presented a modernization of the language to support among others dyn
 
 The Fortran 2003 standard added e.g. access to command line arguments and environment variables. The current standard under development is Fortran 2008.
 
-
 == Fortran packaging ==
 
 Fortran programs in Fedora MUST be compiled using the default Fortran compiler 'gfortran'. As usual, standard Fedora optimization flags %{optflags} MUST be used in the compilation.

From a0c0e534277f13cb9b7b247511fc7a4c225c75f1 Mon Sep 17 00:00:00 2001
From: Jussilehtola 
Date: Jul 26 2009 12:15:31 +0000
Subject: [PATCH 339/3559] /* Introduction */


---

diff --git a/Packaging:Fortran.mw b/Packaging:Fortran.mw
index 6e2caa0..c3a1c99 100644
--- a/Packaging:Fortran.mw
+++ b/Packaging:Fortran.mw
@@ -2,9 +2,9 @@
 
 == Introduction ==
 
-FORTRAN [http://en.wikipedia.org/wiki/Fortran] (short for FORmula TRANslator) was the first programming language ever, invented in 1957 and standardized in 1966. The Fortran 77 standard introduced improved support for structured programming such if clauses.
+FORTRAN [http://en.wikipedia.org/wiki/Fortran] (short for FORmula TRANslator) was the first programming language ever, invented in 1957 and standardized in 1966. The Fortran 77 standard introduced improved support for structured programming such as if clauses.
 
-Fortran natively handles matrices, is rather easy to program and was widely adopted in the scientific community. Due to the large amount of legacy code, Fortran is still widely used in computational science.
+Fortran natively handles matrices and is rather easy to program and for these reasons it was widely adopted in the scientific community. Due to the large amount of legacy code, Fortran is still widely used in computational science. Some modernization has taken place, though:
 
 Fortran 90 presented a modernization of the language to support among others dynamic memory allocation, free-form source input and an argument passing mechanism to support compile time interface checking. Fortran 95 introduced many useful features such as vectorization constructs for high performance computing. 
 

From 5978fe6bcdf097ea04e05a1cdefe0fa86e827128 Mon Sep 17 00:00:00 2001
From: Jussilehtola 
Date: Jul 26 2009 12:15:51 +0000
Subject: [PATCH 340/3559] /* Introduction */


---

diff --git a/Packaging:Fortran.mw b/Packaging:Fortran.mw
index c3a1c99..7e9a1cc 100644
--- a/Packaging:Fortran.mw
+++ b/Packaging:Fortran.mw
@@ -4,7 +4,7 @@
 
 FORTRAN [http://en.wikipedia.org/wiki/Fortran] (short for FORmula TRANslator) was the first programming language ever, invented in 1957 and standardized in 1966. The Fortran 77 standard introduced improved support for structured programming such as if clauses.
 
-Fortran natively handles matrices and is rather easy to program and for these reasons it was widely adopted in the scientific community. Due to the large amount of legacy code, Fortran is still widely used in computational science. Some modernization has taken place, though:
+Fortran natively handles matrices and is rather easy to program and for these reasons it was widely adopted in the scientific community. Due to the large amount of legacy code, Fortran is still widely used in computational science. Some modernization has taken place, though.
 
 Fortran 90 presented a modernization of the language to support among others dynamic memory allocation, free-form source input and an argument passing mechanism to support compile time interface checking. Fortran 95 introduced many useful features such as vectorization constructs for high performance computing. 
 

From cf8fb58ad6cc2f7b56019a18f303b3931bfcc790 Mon Sep 17 00:00:00 2001
From: Jussilehtola 
Date: Jul 26 2009 12:16:11 +0000
Subject: [PATCH 341/3559] /* Fortran packaging */


---

diff --git a/Packaging:Fortran.mw b/Packaging:Fortran.mw
index 7e9a1cc..cec3cf3 100644
--- a/Packaging:Fortran.mw
+++ b/Packaging:Fortran.mw
@@ -18,6 +18,6 @@ The fortran modules files, ending in .mod are files describing a fortran 90 (and
 
 Fortran can also use include files, similar to C headers. The most common filename suffix is '.inc' or '.h', although '.fh' has been used for files that are designed to function as public headers.
 
-Generally Fortran modules that are generated have very general names, thus placing them in the same directory is troublesome. Fortran include files and modules MUST be placed into %{_libdir}/gfortran/%{name}.
+Generally Fortran modules that are generated have very general names, thus placing them in the same directory is troublesome. For this reason Fortran include files and modules MUST be placed into %{_libdir}/gfortran/%{name}.
 
 To use the modules and include files of foo, one needs to add -I%{_libdir}/gfortran/foo to the compiler flags.

From e4bd4586f132cc1afda103cef09dffbe9bd5e285 Mon Sep 17 00:00:00 2001
From: Jussilehtola 
Date: Jul 26 2009 12:20:04 +0000
Subject: [PATCH 342/3559] *Empty MediaWiki Message*


---

diff --git a/Packaging:Fortran.mw b/Packaging:Fortran.mw
index cec3cf3..ce73593 100644
--- a/Packaging:Fortran.mw
+++ b/Packaging:Fortran.mw
@@ -1,5 +1,7 @@
 {{admon/warning|This is a draft document}}
 
+''This document is loosely based on the old drafts [[PackagingDrafts/FortranLibraries|Fortran libraries]] and [[PackagingDrafts/FortranModulesDir|Fortran modules directory]].''
+
 == Introduction ==
 
 FORTRAN [http://en.wikipedia.org/wiki/Fortran] (short for FORmula TRANslator) was the first programming language ever, invented in 1957 and standardized in 1966. The Fortran 77 standard introduced improved support for structured programming such as if clauses.
@@ -14,7 +16,9 @@ The Fortran 2003 standard added e.g. access to command line arguments and enviro
 
 Fortran programs in Fedora MUST be compiled using the default Fortran compiler 'gfortran'. As usual, standard Fedora optimization flags %{optflags} MUST be used in the compilation.
 
-The fortran modules files, ending in .mod are files describing a fortran 90 (and above) module API and ABI. These are not like C header files describing an API, they are compiler dependent and arch dependent, and not easily readable by a human being. They are nevertheless searched for in the includes directories by gfortran (in directories specified with -I). Each gfortran release (e.g. from 4.4 to 4.5) may lead to an incompatible change in the .mod files, therefore mass rebuilds of Fortran packages must take place when gfortran is updated.
+The fortran modules files, ending in .mod are files describing a fortran 90 (and above) module API and ABI. These are not like C header files describing an API, they are compiler dependent and arch dependent, and not easily readable by a human being. They are nevertheless searched for in the includes directories by gfortran (in directories specified with -I).
+
+Due to the ABI specificity, the module directory used must be architecture specific. In addition each gfortran release (e.g. from 4.4 to 4.5) may lead to an incompatible change in the .mod files, therefore mass rebuilds of Fortran packages must take place when gfortran is updated.
 
 Fortran can also use include files, similar to C headers. The most common filename suffix is '.inc' or '.h', although '.fh' has been used for files that are designed to function as public headers.
 

From ac67a6ea03968a076e56a4330276b20dc470e770 Mon Sep 17 00:00:00 2001
From: Jussilehtola 
Date: Jul 26 2009 12:20:53 +0000
Subject: [PATCH 343/3559] /* Fortran packaging */


---

diff --git a/Packaging:Fortran.mw b/Packaging:Fortran.mw
index ce73593..6670446 100644
--- a/Packaging:Fortran.mw
+++ b/Packaging:Fortran.mw
@@ -22,6 +22,6 @@ Due to the ABI specificity, the module directory used must be architecture speci
 
 Fortran can also use include files, similar to C headers. The most common filename suffix is '.inc' or '.h', although '.fh' has been used for files that are designed to function as public headers.
 
-Generally Fortran modules that are generated have very general names, thus placing them in the same directory is troublesome. For this reason Fortran include files and modules MUST be placed into %{_libdir}/gfortran/%{name}.
+Generally Fortran modules that are generated have very general names, thus placing them in the same directory is troublesome. For this reason Fortran include files and modules MUST be placed into %{_libdir}/gfortran/%{name}. The directory %{_libdir}/gfortran MUST be owned by gfortran.
 
 To use the modules and include files of foo, one needs to add -I%{_libdir}/gfortran/foo to the compiler flags.

From 7ebd883f89d305417403d17cefc0014d72481c65 Mon Sep 17 00:00:00 2001
From: Jussilehtola 
Date: Jul 26 2009 12:22:17 +0000
Subject: [PATCH 344/3559] /* Fortran packaging */


---

diff --git a/Packaging:Fortran.mw b/Packaging:Fortran.mw
index 6670446..1665089 100644
--- a/Packaging:Fortran.mw
+++ b/Packaging:Fortran.mw
@@ -24,4 +24,6 @@ Fortran can also use include files, similar to C headers. The most common filena
 
 Generally Fortran modules that are generated have very general names, thus placing them in the same directory is troublesome. For this reason Fortran include files and modules MUST be placed into %{_libdir}/gfortran/%{name}. The directory %{_libdir}/gfortran MUST be owned by gfortran.
 
+The preexisting %{_fmoddir} macro should be either removed or replaced with a %{_flibdir} macro which evaluates to %{_libdir}/gfortran.
+
 To use the modules and include files of foo, one needs to add -I%{_libdir}/gfortran/foo to the compiler flags.

From 5a08c25160a7ec85a48d7275c7e6e7dc632dd58b Mon Sep 17 00:00:00 2001
From: Spot 
Date: Jul 27 2009 14:00:28 +0000
Subject: [PATCH 345/3559] /* GConf */


---

diff --git a/Packaging:Scriptlets.mw b/Packaging:Scriptlets.mw
index 75516e3..0d09d3b 100644
--- a/Packaging:Scriptlets.mw
+++ b/Packaging:Scriptlets.mw
@@ -123,7 +123,7 @@ In this section we uninstall the old schemas when we upgrade.  The way we do thi
 The next section is for installing the new schema:
 
 %post
-export GCONF_CONFIG_SOURCE=gconftool-2 --get-default-source
+export GCONF_CONFIG_SOURCE=gconftool-2 --get-default-source
 gconftool-2 --makefile-install-rule \
 %{_sysconfdir}/gconf/schemas/[NAME] .schemas > /dev/null || :
 


From 0e0309be7ec0b9d0be3ac7cda9897ff3b116668f Mon Sep 17 00:00:00 2001
From: Spot 
Date: Jul 27 2009 14:01:33 +0000
Subject: [PATCH 346/3559] /* GConf */


---

diff --git a/Packaging:Scriptlets.mw b/Packaging:Scriptlets.mw
index 0d09d3b..b4dedb7 100644
--- a/Packaging:Scriptlets.mw
+++ b/Packaging:Scriptlets.mw
@@ -113,7 +113,7 @@ Requires(preun): GConf2
 ...
 %pre
 if [ "$1" -gt 1 ] ; then
-export GCONF_CONFIG_SOURCE=gconftool-2 --get-default-source
+export GCONF_CONFIG_SOURCE=gconftool-2 --get-default-source
 gconftool-2 --makefile-uninstall-rule \
 %{_sysconfdir}/gconf/schemas/[NAME] .schemas >/dev/null || :
 fi
@@ -133,7 +133,7 @@ The last section deals with deleting the schemas on package removal:
 
 %preun
 if [ "$1" -eq 0 ] ; then
-export GCONF_CONFIG_SOURCE=gconftool-2 --get-default-source
+export GCONF_CONFIG_SOURCE=gconftool-2 --get-default-source
 gconftool-2 --makefile-uninstall-rule \
 %{_sysconfdir}/gconf/schemas/[NAME] .schemas > /dev/null || :
 fi

From 39033158c363688613a9809facc8f85f829b60fa Mon Sep 17 00:00:00 2001
From: Jussilehtola 
Date: Jul 27 2009 19:45:50 +0000
Subject: [PATCH 347/3559] /* Fortran packaging */


---

diff --git a/Packaging:Fortran.mw b/Packaging:Fortran.mw
index 1665089..e839e86 100644
--- a/Packaging:Fortran.mw
+++ b/Packaging:Fortran.mw
@@ -12,18 +12,22 @@ Fortran 90 presented a modernization of the language to support among others dyn
 
 The Fortran 2003 standard added e.g. access to command line arguments and environment variables. The current standard under development is Fortran 2008.
 
-== Fortran packaging ==
-
-Fortran programs in Fedora MUST be compiled using the default Fortran compiler 'gfortran'. As usual, standard Fedora optimization flags %{optflags} MUST be used in the compilation.
+== Modules and include files ==
 
 The fortran modules files, ending in .mod are files describing a fortran 90 (and above) module API and ABI. These are not like C header files describing an API, they are compiler dependent and arch dependent, and not easily readable by a human being. They are nevertheless searched for in the includes directories by gfortran (in directories specified with -I).
 
 Due to the ABI specificity, the module directory used must be architecture specific. In addition each gfortran release (e.g. from 4.4 to 4.5) may lead to an incompatible change in the .mod files, therefore mass rebuilds of Fortran packages must take place when gfortran is updated.
 
-Fortran can also use include files, similar to C headers. The most common filename suffix is '.inc' or '.h', although '.fh' has been used for files that are designed to function as public headers.
+Fortran can also use include files, similar to C headers. The most common filename suffix is '.inc' or '.h', although '.fh' has been used for files that are designed to function as public headers. 
+
+== Packaging of Fortran programs ==
+
+Fortran programs in Fedora MUST be compiled using the default Fortran compiler 'gfortran'. As usual, standard Fedora optimization flags %{optflags} MUST be used in the compilation.
+
+Fortran include files MUST be placed in the standard include directory: either directly in %{_includedir}, or if headers have general names or upstream recommends having an own directory, in e.g. %{_includedir}/%{name}.
 
-Generally Fortran modules that are generated have very general names, thus placing them in the same directory is troublesome. For this reason Fortran include files and modules MUST be placed into %{_libdir}/gfortran/%{name}. The directory %{_libdir}/gfortran MUST be owned by gfortran.
+As Fortran modules are architecture and GCC version specific, they MUST be placed into /usr/lib/gcc///finclude, which is owned by 'gcc-gfortran'. For directory ownership any packages containing Fortran modules MUST Requires: gcc-gfortran%{_isa}.
 
-The preexisting %{_fmoddir} macro should be either removed or replaced with a %{_flibdir} macro which evaluates to %{_libdir}/gfortran.
+The preexisting %{_fmoddir} macro should be modified to evaluate to the aforementioned directory.
 
-To use the modules and include files of foo, one needs to add -I%{_libdir}/gfortran/foo to the compiler flags.
+To use the modules in the Fortran module directory, one needs to add -I%{_fmoddir} to the compiler flags (this is already included in FFLAGS used by %configure).

From d9adb7d6faf21012b4f6fa906e073d4b6b887b6d Mon Sep 17 00:00:00 2001
From: Jussilehtola 
Date: Jul 27 2009 19:46:30 +0000
Subject: [PATCH 348/3559] /* Packaging of Fortran programs */


---

diff --git a/Packaging:Fortran.mw b/Packaging:Fortran.mw
index e839e86..4c0e4db 100644
--- a/Packaging:Fortran.mw
+++ b/Packaging:Fortran.mw
@@ -22,7 +22,7 @@ Fortran can also use include files, similar to C headers. The most common filena
 
 == Packaging of Fortran programs ==
 
-Fortran programs in Fedora MUST be compiled using the default Fortran compiler 'gfortran'. As usual, standard Fedora optimization flags %{optflags} MUST be used in the compilation.
+Fortran programs in Fedora MUST be compiled, if possible, using the default Fortran compiler in Fedora, 'gfortran'. As usual, standard Fedora optimization flags %{optflags} MUST be used in the compilation.
 
 Fortran include files MUST be placed in the standard include directory: either directly in %{_includedir}, or if headers have general names or upstream recommends having an own directory, in e.g. %{_includedir}/%{name}.
 

From fcd78d71f541f70fcc6a3fd53dd205d44b54254d Mon Sep 17 00:00:00 2001
From: Jussilehtola 
Date: Jul 27 2009 19:48:42 +0000
Subject: [PATCH 349/3559] /* Packaging of Fortran programs */


---

diff --git a/Packaging:Fortran.mw b/Packaging:Fortran.mw
index 4c0e4db..4e17729 100644
--- a/Packaging:Fortran.mw
+++ b/Packaging:Fortran.mw
@@ -28,6 +28,8 @@ Fortran include files MUST be placed in the standard include directory: e
 
 As Fortran modules are architecture and GCC version specific, they MUST be placed into /usr/lib/gcc///finclude, which is owned by 'gcc-gfortran'. For directory ownership any packages containing Fortran modules MUST Requires: gcc-gfortran%{_isa}.
 
-The preexisting %{_fmoddir} macro should be modified to evaluate to the aforementioned directory.
-
 To use the modules in the Fortran module directory, one needs to add -I%{_fmoddir} to the compiler flags (this is already included in FFLAGS used by %configure).
+
+== Required changes ==
+
+The preexisting %{_fmoddir} macro must be changed from %{_libdir}/gfortran/modules to /usr/lib/gcc///finclude.

From cfcf0f6001fb2703baaa00ba1c84ba350eb20724 Mon Sep 17 00:00:00 2001
From: Jussilehtola 
Date: Jul 27 2009 19:49:31 +0000
Subject: [PATCH 350/3559] /* Modules and include files */


---

diff --git a/Packaging:Fortran.mw b/Packaging:Fortran.mw
index 4e17729..d395e62 100644
--- a/Packaging:Fortran.mw
+++ b/Packaging:Fortran.mw
@@ -18,7 +18,7 @@ The fortran modules files, ending in .mod are files describing a fortran 90 (and
 
 Due to the ABI specificity, the module directory used must be architecture specific. In addition each gfortran release (e.g. from 4.4 to 4.5) may lead to an incompatible change in the .mod files, therefore mass rebuilds of Fortran packages must take place when gfortran is updated.
 
-Fortran can also use include files, similar to C headers. The most common filename suffix is '.inc' or '.h', although '.fh' has been used for files that are designed to function as public headers. 
+Fortran can also use include files, similar to C headers. Common used filename suffixes are '.inc' and '.h', although '.fh' has been used for files that are designed to function as public headers.
 
 == Packaging of Fortran programs ==
 

From 22ae48b2e171681a270a77e5d67227c3a63856af Mon Sep 17 00:00:00 2001
From: Jussilehtola 
Date: Jul 27 2009 19:58:27 +0000
Subject: [PATCH 351/3559] /* Required changes */


---

diff --git a/Packaging:Fortran.mw b/Packaging:Fortran.mw
index d395e62..122b19e 100644
--- a/Packaging:Fortran.mw
+++ b/Packaging:Fortran.mw
@@ -32,4 +32,4 @@ To use the modules in the Fortran module directory, one needs to add -I%{_
 
 == Required changes ==
 
-The preexisting %{_fmoddir} macro must be changed from %{_libdir}/gfortran/modules to /usr/lib/gcc///finclude.
+The preexisting %{_fmoddir} macro must be changed from %{_libdir}/gfortran/modules to /usr/lib/gcc///finclude. Packages that contain modules in the wrong place must be found and corrected (find all packages that BR: gcc-gfortran and contain '.mod' files). Finally, a rebuild of all packages containing Fortran modules must be performed.

From 5cf9497eae34e3bc70b20868e396698446d8fcfc Mon Sep 17 00:00:00 2001
From: Jussilehtola 
Date: Jul 27 2009 19:59:26 +0000
Subject: [PATCH 352/3559] *Empty MediaWiki Message*


---

diff --git a/Packaging:Fortran.mw b/Packaging:Fortran.mw
index 122b19e..e21d30a 100644
--- a/Packaging:Fortran.mw
+++ b/Packaging:Fortran.mw
@@ -1,6 +1,6 @@
 {{admon/warning|This is a draft document}}
 
-''This document is loosely based on the old drafts [[PackagingDrafts/FortranLibraries|Fortran libraries]] and [[PackagingDrafts/FortranModulesDir|Fortran modules directory]].''
+''This document is loosely based on the [[PackagingDrafts/FortranLibraries|Fortran library draft]] and the [[PackagingDrafts/FortranModulesDir|Fortran modules directory guideline]]. It is supposed to replace both of them.''
 
 == Introduction ==
 

From 0235af0ad8e4b2e25ad289e46fa0b4fc42c6650b Mon Sep 17 00:00:00 2001
From: Jussilehtola 
Date: Jul 27 2009 20:00:38 +0000
Subject: [PATCH 353/3559] /* Packaging of Fortran programs */


---

diff --git a/Packaging:Fortran.mw b/Packaging:Fortran.mw
index e21d30a..bc7c255 100644
--- a/Packaging:Fortran.mw
+++ b/Packaging:Fortran.mw
@@ -26,7 +26,7 @@ Fortran programs in Fedora MUST be compiled, if possible, using the defau
 
 Fortran include files MUST be placed in the standard include directory: either directly in %{_includedir}, or if headers have general names or upstream recommends having an own directory, in e.g. %{_includedir}/%{name}.
 
-As Fortran modules are architecture and GCC version specific, they MUST be placed into /usr/lib/gcc///finclude, which is owned by 'gcc-gfortran'. For directory ownership any packages containing Fortran modules MUST Requires: gcc-gfortran%{_isa}.
+As Fortran modules are architecture and GCC version specific, they MUST be placed into %{_fmoddir} (or its package-specific subfolder in case the modules have generic names), which is owned by 'gcc-gfortran'. For directory ownership any packages containing Fortran modules MUST Requires: gcc-gfortran%{_isa}.
 
 To use the modules in the Fortran module directory, one needs to add -I%{_fmoddir} to the compiler flags (this is already included in FFLAGS used by %configure).
 

From a4c5c77d087dad25ff9c09ff28058f97d7a94e3d Mon Sep 17 00:00:00 2001
From: Jussilehtola 
Date: Jul 27 2009 20:01:32 +0000
Subject: [PATCH 354/3559] /* Required changes */


---

diff --git a/Packaging:Fortran.mw b/Packaging:Fortran.mw
index bc7c255..c1d9f35 100644
--- a/Packaging:Fortran.mw
+++ b/Packaging:Fortran.mw
@@ -32,4 +32,4 @@ To use the modules in the Fortran module directory, one needs to add -I%{_
 
 == Required changes ==
 
-The preexisting %{_fmoddir} macro must be changed from %{_libdir}/gfortran/modules to /usr/lib/gcc///finclude. Packages that contain modules in the wrong place must be found and corrected (find all packages that BR: gcc-gfortran and contain '.mod' files). Finally, a rebuild of all packages containing Fortran modules must be performed.
+The preexisting %{_fmoddir} macro in redhat-rpm-macros must be changed from %{_libdir}/gfortran/modules to /usr/lib/gcc///finclude. Packages that contain modules in the wrong place must be found and corrected (find all packages that BR: gcc-gfortran and contain '.mod' files). Finally, a rebuild of all packages containing Fortran modules must be performed.

From b3e5c062b206929f9dd9e999aad0238e7f3abebf Mon Sep 17 00:00:00 2001
From: Jussilehtola 
Date: Jul 27 2009 20:25:51 +0000
Subject: [PATCH 355/3559] *Empty MediaWiki Message*


---

diff --git a/Packaging:Fortran.mw b/Packaging:Fortran.mw
index c1d9f35..0012203 100644
--- a/Packaging:Fortran.mw
+++ b/Packaging:Fortran.mw
@@ -1,6 +1,6 @@
 {{admon/warning|This is a draft document}}
 
-''This document is loosely based on the [[PackagingDrafts/FortranLibraries|Fortran library draft]] and the [[PackagingDrafts/FortranModulesDir|Fortran modules directory guideline]]. It is supposed to replace both of them.''
+''This document is loosely based on the [[PackagingDrafts/FortranLibraries|Fortran library draft]] and the [[PackagingDrafts/FortranModulesDir|Fortran modules directory guideline]]. It is supposed to replace both of them, due to [https://bugzilla.redhat.com/show_bug.cgi?id=483765 the bug in the Fortran modules directory guidelines].''
 
 == Introduction ==
 

From 1f8ed9bb7526891ff72cfc05781a38f3204e76ff Mon Sep 17 00:00:00 2001
From: Spot 
Date: Jul 28 2009 18:51:32 +0000
Subject: [PATCH 356/3559] *Empty MediaWiki Message*


---

diff --git a/Packaging:AutoProvidesAndRequiresFiltering.mw b/Packaging:AutoProvidesAndRequiresFiltering.mw
index 8f90a76..cbb8a1f 100644
--- a/Packaging:AutoProvidesAndRequiresFiltering.mw
+++ b/Packaging:AutoProvidesAndRequiresFiltering.mw
@@ -27,50 +27,13 @@ As it stands, filtering these auto-generated requires and provides is difficult 
 
 '''Macros defining the filtering system: [http://fedorapeople.org/~cweyl/macros.filtering macros.filtering]'''
 
-== Examples ==
-
-A brief comparison of [[Features/BetterRpmAutoReqProvFiltering/OtherFilteringSystems|other auto req/prov filtering systems]].
-
-=== Pidigin plugin package ===
-
-On a x86_64 machine, the pidgin-libnotify provides pidgin-libnotify.so()(64bit), which it shouldn't, as this library is not inside the paths searched by the system for libraries; that is, it's a private, not global, "provides" and as such must not be exposed globally by RPM.
-
-To filter this out, we could use:
-
-
-%filter_provides_in %{_libdir}/purple-2/.*\\.so$
-%filter_setup
-

-
-=== Arch-specific perl-* package ===
-
-e.g. to ensure an arch-specific perl-* package won't provide or require things that it shouldn't, we could use an invocation as such:
-
-
-# we don't want to provide private Perl extension libs
-%filter_provides_in %{perl_vendorarch}/.*\\.so$ 
-%filter_provides_in -P %{perl_archlib}/(?!CORE/libperl).*\\.so$ 
-
-# actually set up the filtering
-%filter_setup
-

-
-=== %_docdir filtering ===
-
-By policy, nothing under %_docdir is allowed to either "provide" or "require" anything.  We can prevent this from happening by preventing anything under %_docdir from being scanned:
-
-
-# we don't want to either provide or require anything from _docdir, per policy
-%filter_provides_in %{_docdir} 
-%filter_requires_in %{_docdir}
-
-# actually set up the filtering
-%filter_setup
-

-
 == Usage ==
 
-{{admon/warning|Beware of Multilib|Be careful of using these macros in a multilib situation, as they may interfere with the "coloring" of elf32/64 executables done internally by RPM to support multilib installs.}}
+These filtering macros '''MUST''' only be used with packages which meet the following criteria:
+* Noarch packages
+* Architecture specific packages with no binaries in $PATH (e.g. /bin, /usr/bin, /sbin, /sbin) or libexecdir and no system libs in libdir. This includes all of the subpackages generated from the spec file.
+
+They are not permitted in any other cases, because the macros interfere with the "coloring" of elf32/64 executables done internally by RPM to support multilib installs.
 
 === Location of macro invocation ===
 
@@ -119,3 +82,43 @@ The '''%filter_setup''' macro must be invoked after defining any specific overri
 # ... filtering defines here
 %filter_setup
 

+
+== Examples ==
+
+
+=== Pidgin plugin package ===
+
+On a x86_64 machine, the pidgin-libnotify provides pidgin-libnotify.so()(64bit), which it shouldn't, as this library is not inside the paths searched by the system for libraries; that is, it's a private, not global, "provides" and as such must not be exposed globally by RPM.
+
+To filter this out, we could use:
+
+
+%filter_provides_in %{_libdir}/purple-2/.*\\.so$
+%filter_setup
+

+
+=== Arch-specific perl-* package ===
+
+e.g. to ensure an arch-specific perl-* package won't provide or require things that it shouldn't, we could use an invocation as such:
+
+
+# we don't want to provide private Perl extension libs
+%filter_provides_in %{perl_vendorarch}/.*\\.so$ 
+%filter_provides_in -P %{perl_archlib}/(?!CORE/libperl).*\\.so$ 
+
+# actually set up the filtering
+%filter_setup
+

+
+=== %_docdir filtering ===
+
+By policy, nothing under %_docdir is allowed to either "provide" or "require" anything.  We can prevent this from happening by preventing anything under %_docdir from being scanned:
+
+
+# we don't want to either provide or require anything from _docdir, per policy
+%filter_provides_in %{_docdir} 
+%filter_requires_in %{_docdir}
+
+# actually set up the filtering
+%filter_setup
+


From 79fc5c831014a0088b47f9a2561df109ff4da381 Mon Sep 17 00:00:00 2001
From: Spot 
Date: Jul 28 2009 18:54:09 +0000
Subject: [PATCH 357/3559] *Empty MediaWiki Message*


---

diff --git a/Packaging:AutoProvidesAndRequiresFiltering.mw b/Packaging:AutoProvidesAndRequiresFiltering.mw
index cbb8a1f..5a3068a 100644
--- a/Packaging:AutoProvidesAndRequiresFiltering.mw
+++ b/Packaging:AutoProvidesAndRequiresFiltering.mw
@@ -18,7 +18,7 @@ For example:
 * Various "plugin" packages (e.g. Pidgin, Perl, Apache, KDE) are marked as "providing" private shared libraries outside the system path.
 * Files in %{_docdir} are routinely scanned, and can trigger prov/req when this is explicitly forbidden by policy.
 
-As it stands, filtering these auto-generated requires and provides is difficult and messy at best, and horribly deep magic in many cases; with little guidance on how to do it.{{ref|1}}  This feature aims to make the following tasks easy:
+As it stands, filtering these auto-generated requires and provides is difficult and messy at best, and horribly deep magic in many cases; with little guidance on how to do it. This feature aims to make the following tasks easy:
 
 * preventing files/directories from being scanned for requires (pre-scan filtering)
 * preventing files/directories from being scanned for provides (pre-scan filtering)

From c41efbf53d91989c6eb86af578ebcf91bc1db943 Mon Sep 17 00:00:00 2001
From: Spot 
Date: Jul 28 2009 19:01:06 +0000
Subject: [PATCH 358/3559] *Empty MediaWiki Message*


---

diff --git a/Packaging:GuidelinesTodo.mw b/Packaging:GuidelinesTodo.mw
index 255dd46..bfd8d5c 100644
--- a/Packaging:GuidelinesTodo.mw
+++ b/Packaging:GuidelinesTodo.mw
@@ -6,11 +6,20 @@ Status should be one of:
 * ratify -- Change needs be presented to FESCo for objections.
 * followup -- There are questions or concerns that need to be addressed.
 * writeup -- Change needs to be written into the official guidelines.
+* announce -- Change has been written up, but needs to be announced.
 
 {| border="1"
 |- style="color: white; background-color: #3074c2; font-weight: bold" 
 |Status||Task Name||Owner||Meeting Date||Notes
 |-
+|ratify||dos2unix||atorkhov|| 2009-07-28||[[PackagingDrafts/Dos2unix]]
+|-
+|ratify||Filtering auto-provides||cweyl||2009-07-28||[[PackagingDrafts/AutoProvidesAndRequiresFiltering]]
+|-
+|ratify||Explanation of no bundled libraries||abadger1999||2009-07-28||[[No_Bundled_Libraries]]
+|-
+|ratify||pre-built binaries||oget||2009-07-28||[[PackagingDrafts/Removal_of_pre-built_binaries]]
+|-
 |announce||Phase out Buildroot||abadger1999||2009-06-02||https://fedoraproject.org/wiki/Phase_out_buildroot_tag_%28draft%29
 |-
 |announce||Common Package Names||abadger1999||2009-04-14||[[Common package names packaging guideline draft]]

From 2ab8dea8ae521f83b750422417166bf189916bf1 Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Jul 29 2009 14:23:42 +0000
Subject: [PATCH 359/3559] Missing backticks; remove FC <=4 note


---

diff --git a/Packaging:Scriptlets.mw b/Packaging:Scriptlets.mw
index b4dedb7..ded91ec 100644
--- a/Packaging:Scriptlets.mw
+++ b/Packaging:Scriptlets.mw
@@ -113,7 +113,7 @@ Requires(preun): GConf2
 ...
 %pre
 if [ "$1" -gt 1 ] ; then
-export GCONF_CONFIG_SOURCE=gconftool-2 --get-default-source
+export GCONF_CONFIG_SOURCE=`gconftool-2 --get-default-source`
 gconftool-2 --makefile-uninstall-rule \
 %{_sysconfdir}/gconf/schemas/[NAME] .schemas >/dev/null || :
 fi
@@ -123,7 +123,7 @@ In this section we uninstall the old schemas when we upgrade.  The way we do thi
 The next section is for installing the new schema:
 
 %post
-export GCONF_CONFIG_SOURCE=gconftool-2 --get-default-source
+export GCONF_CONFIG_SOURCE=`gconftool-2 --get-default-source`
 gconftool-2 --makefile-install-rule \
 %{_sysconfdir}/gconf/schemas/[NAME] .schemas > /dev/null || :
 

@@ -133,14 +133,14 @@ The last section deals with deleting the schemas on package removal:
 
 %preun
 if [ "$1" -eq 0 ] ; then
-export GCONF_CONFIG_SOURCE=gconftool-2 --get-default-source
+export GCONF_CONFIG_SOURCE=`gconftool-2 --get-default-source`
 gconftool-2 --makefile-uninstall-rule \
 %{_sysconfdir}/gconf/schemas/[NAME] .schemas > /dev/null || :
 fi
 

 This snippet is nearly the same as the one for upgrading.  Why can't we just combine this portion with the  %pre portion?  The answer is that we want to delete any old versions of the schema during an upgrade.  But this has to happen before we install the new version (in the %post script) otherwise we end up removing the schema that the upgrading package installs.  However, if it really is a removal that will leave no other instances of this package on the system, we have to clean up the schema before deleting it.
 
-'''Note:''' RHEL4 and FC <= 4 suffer from GConf [https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173869 Bug #173869] .  If you are building for EPEL-4, you need to add  killall -HUP gconfd-2 > /dev/null || :  after the gconftool-2 calls in all the scriptlets.
+'''Note:''' RHEL4 suffers from GConf [https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173869 Bug #173869] .  If you are building for EPEL-4, you need to add  killall -HUP gconfd-2 > /dev/null || :  after the gconftool-2 calls in all the scriptlets.
 
 {{Anchor|info}}
 

From 26d70d11593e91465d44dbc00aa169cdce36df0e Mon Sep 17 00:00:00 2001
From: Jussilehtola 
Date: Aug 04 2009 17:49:14 +0000
Subject: [PATCH 360/3559] /* Required changes */  - Versioned %{_fmoddir} or not?


---

diff --git a/Packaging:Fortran.mw b/Packaging:Fortran.mw
index 0012203..cd1eab2 100644
--- a/Packaging:Fortran.mw
+++ b/Packaging:Fortran.mw
@@ -32,4 +32,10 @@ To use the modules in the Fortran module directory, one needs to add -I%{_
 
 == Required changes ==
 
-The preexisting %{_fmoddir} macro in redhat-rpm-macros must be changed from %{_libdir}/gfortran/modules to /usr/lib/gcc///finclude. Packages that contain modules in the wrong place must be found and corrected (find all packages that BR: gcc-gfortran and contain '.mod' files). Finally, a rebuild of all packages containing Fortran modules must be performed.
+Packages that contain modules in the wrong place must be found and fixed (e.g. find all packages that BR: gcc-gfortran and contain '.mod' files).
+
+The module files depend on the used compiler version and the architecture. The versioning should not matter, as mass rebuilds are done anyway whenever GCC is updated to a newer version. It is important, however, if there are multiple Fortran compilers present on the system.
+
+
+* If it is decided to keep using an unversioned, multilib compatible %{_fmoddir}, the ''gcc-gfortran'' package must be changed to own %{_fmoddir} and all package containing modules must Requires: gcc-gfortran.
+* If it is decided to use a GCC-versioned %{_fmoddir}, the preexisting %{_fmoddir} macro in redhat-rpm-macros must be changed from %{_libdir}/gfortran/modules to /usr/lib/gcc///finclude which is already used and owned by gfortran. After that a mass rebuild of all packages containing Fortran modules must be performed.

From d0e6e4806725207bcca9f64d6bdda5b86025df2a Mon Sep 17 00:00:00 2001
From: Mycae 
Date: Aug 08 2009 04:51:29 +0000
Subject: [PATCH 361/3559] /* Updating the octave package database */ dist-admin does not handle it. Looking at dist-admin, it is a small shell script that exes octave's rebuild functions which are called from the spec already


---

diff --git a/Packaging:Octave.mw b/Packaging:Octave.mw
index bf82dd8..985383d 100644
--- a/Packaging:Octave.mw
+++ b/Packaging:Octave.mw
@@ -173,7 +173,15 @@ octave-gsl (Octave package named gsl)
 Due to an issue with octave emitting an escape sequence (due to readline library) on startup, you need to unset the TERM variable in the %build and %install sections.
 
 === Updating the octave package database ===
-Octave maintains a list of installed packages in /usr/share/octave/octave_packages that needs to be updated on package install and removal.  This is handled by the dist_admin script in each package.
+Octave maintains a list of installed packages in /usr/share/octave/octave_packages that needs to be updated on package install and removal.  This file is in an octave plain-text format. 
+
+The contents of the /usr/share/octave/packages/ directory are scanned for the follwing files when performing a pkg('rebuild') from within octave.
+* /usr/share/octave/packages/''NAMEOFPACKAGE''/packinfo/COPYING
+* /usr/share/octave/packages/''NAMEOFPACKAGE''/packinfo/DESCRIPTION
+
+If these files are not present in any give NAMEOFPACKAGE directory, then octave will silently skip the folder and fail to index it correctly. 
+
+Octave will use the contents of octave_packages to modify its path at startup, allowing octave to find plugins.
 
 === Documentation files ===
 All package files are installed into the octave directories.  The COPYING and DESCRIPTION files are documentation and need to be marked as %doc.  The others are not.

From 1d441ef46e28471cf6d170b35be2f3cd7a68253b Mon Sep 17 00:00:00 2001
From: Mycae 
Date: Aug 08 2009 04:51:51 +0000
Subject: [PATCH 362/3559] /* Updating the octave package database */ typo


---

diff --git a/Packaging:Octave.mw b/Packaging:Octave.mw
index 985383d..21b4f12 100644
--- a/Packaging:Octave.mw
+++ b/Packaging:Octave.mw
@@ -179,7 +179,7 @@ The contents of the /usr/share/octave/packages/ directory are scanned for the fo
 * /usr/share/octave/packages/''NAMEOFPACKAGE''/packinfo/COPYING
 * /usr/share/octave/packages/''NAMEOFPACKAGE''/packinfo/DESCRIPTION
 
-If these files are not present in any give NAMEOFPACKAGE directory, then octave will silently skip the folder and fail to index it correctly. 
+If these files are not present in any given ''NAMEOFPACKAGE'' directory, then octave will silently skip the folder and fail to index it correctly. 
 
 Octave will use the contents of octave_packages to modify its path at startup, allowing octave to find plugins.
 

From bee7ef0f2af7a79c177be2e25ad76e4981fef807 Mon Sep 17 00:00:00 2001
From: Spot 
Date: Aug 12 2009 17:45:05 +0000
Subject: [PATCH 363/3559] *Empty MediaWiki Message*


---

diff --git a/Packaging:GuidelinesTodo.mw b/Packaging:GuidelinesTodo.mw
index bfd8d5c..a5681fb 100644
--- a/Packaging:GuidelinesTodo.mw
+++ b/Packaging:GuidelinesTodo.mw
@@ -12,13 +12,25 @@ Status should be one of:
 |- style="color: white; background-color: #3074c2; font-weight: bold" 
 |Status||Task Name||Owner||Meeting Date||Notes
 |-
-|ratify||dos2unix||atorkhov|| 2009-07-28||[[PackagingDrafts/Dos2unix]]
+|ratify||MPI packaging||[[User:jussilehtola|Jussi Lehtola]]||2009-08-12||[[PackagingDrafts/MPI]]
 |-
-|ratify||Filtering auto-provides||cweyl||2009-07-28||[[PackagingDrafts/AutoProvidesAndRequiresFiltering]]
+|ratify||Environment modules||[[User:jussilehtola|Jussi Lehtola]]||2009-08-12||[[PackagingDrafts/EnvironmentModules]]
 |-
-|ratify||Explanation of no bundled libraries||abadger1999||2009-07-28||[[No_Bundled_Libraries]]
+|ratify||Correct ant sample spec||[[User:jussilehtola|Jussi Lehtola]]||2009-08-12||[[PackagingDrafts/JavaAntSampleSpec]]
 |-
-|ratify||pre-built binaries||oget||2009-07-28||[[PackagingDrafts/Removal_of_pre-built_binaries]]
+|ratify||Update R guidelines||[[User:pingou|pingou]]||2009-08-12|| [[ProposalUpdateRGuidelines]]
+|-
+|ratify||Drop Scrollkeeper Scriptlets||[[User:spot|spot]]||2009-08-12|| [[PackagingDrafts/DropScrollkeeperUpdate]]
+|-
+|ratify||Numpy and pygtk2 ||[User:spot|spot]]||2009-08-12|| [[PackagingDrafts/PythonNumpy]]
+|-
+|writeup||dos2unix||atorkhov|| 2009-07-28||[[PackagingDrafts/Dos2unix]]
+|-
+|writeup||Filtering auto-provides||cweyl||2009-07-28||[[PackagingDrafts/AutoProvidesAndRequiresFiltering]]
+|-
+|writeup||Explanation of no bundled libraries||abadger1999||2009-07-28||[[No_Bundled_Libraries]]
+|-
+|writeup||pre-built binaries||oget||2009-07-28||[[PackagingDrafts/Removal_of_pre-built_binaries]]
 |-
 |announce||Phase out Buildroot||abadger1999||2009-06-02||https://fedoraproject.org/wiki/Phase_out_buildroot_tag_%28draft%29
 |-
@@ -263,6 +275,8 @@ Status should be one of:
 |- style="color: white; background-color: #3074c2; font-weight: bold" 
 |Task Name||Owner||Resolution Date||Notes
 |-
+|filesystem subpackages||s4504kr||2009-08-12||[[PackagingDrafts/CreatingFilesystemSubpackages]] Instead of mandating many smaller -filesystem packages, it is preferred to improve the base system filesystem package to own common directories. Maintainers can still create -filesystem/-common packages as appropriate.
+|-
 |Guidelines for MAN pages||hubbitus||2009-05-12||[[MAN pages which exists in_other places(draft)]] This draft conflicts with the general practice that Fedora packagers should be working to send improvements directly to upstream. Anyone who feels motivated to dig in other distributions for patches or improvements should feel free to do so, but it is not something that the FPC felt should be codified into the guidelines.
 |-
 |Compiler Flags||abadger1999|| 2009-04-28 ||[[Compiler_Flags_(draft)]] || A more thorough document on how to ensure optflags are being used should be generated in the open Packagers/ namespace, then please request that FPC add a link to that package from the relevant section of the Packaging Guidelines.

From 00c70f314141c352006e8f8b4f3ed628b94eeaed Mon Sep 17 00:00:00 2001
From: Spot 
Date: Aug 12 2009 17:46:01 +0000
Subject: [PATCH 364/3559] /* Action Items */


---

diff --git a/Packaging:GuidelinesTodo.mw b/Packaging:GuidelinesTodo.mw
index a5681fb..90d4ca8 100644
--- a/Packaging:GuidelinesTodo.mw
+++ b/Packaging:GuidelinesTodo.mw
@@ -22,7 +22,7 @@ Status should be one of:
 |-
 |ratify||Drop Scrollkeeper Scriptlets||[[User:spot|spot]]||2009-08-12|| [[PackagingDrafts/DropScrollkeeperUpdate]]
 |-
-|ratify||Numpy and pygtk2 ||[User:spot|spot]]||2009-08-12|| [[PackagingDrafts/PythonNumpy]]
+|ratify||Numpy and pygtk2||[[User:spot|spot]]||2009-08-12|| [[PackagingDrafts/PythonNumpy]]
 |-
 |writeup||dos2unix||atorkhov|| 2009-07-28||[[PackagingDrafts/Dos2unix]]
 |-

From 14ccb3d9cceea3d2d145477e3aeb83ecc17c0920 Mon Sep 17 00:00:00 2001
From: Mycae 
Date: Aug 15 2009 00:40:18 +0000
Subject: [PATCH 365/3559] /* Naming of Octave packages */ versioning problem


---

diff --git a/Packaging:Octave.mw b/Packaging:Octave.mw
index 21b4f12..db8a353 100644
--- a/Packaging:Octave.mw
+++ b/Packaging:Octave.mw
@@ -169,6 +169,8 @@ octave-java (Octave package named java)
 octave-gsl (Octave package named gsl)
 

 
+Limitations in the pkg function of octave (pkg.m) means that versioning of octave packages requires that the package version must have a MAJOR.MINOR.MICRO format. Failing to use this format results in octave not recognising binary package components in %prefix/libexec.
+
 === unset TERM ===
 Due to an issue with octave emitting an escape sequence (due to readline library) on startup, you need to unset the TERM variable in the %build and %install sections.
 

From f58b8fc434ff151b8a5b9300e6125986a4c9d5c5 Mon Sep 17 00:00:00 2001
From: Spot 
Date: Aug 18 2009 15:49:06 +0000
Subject: [PATCH 366/3559] /* We are Upstream */


---

diff --git a/Packaging:SourceURL.mw b/Packaging:SourceURL.mw
index eeb5343..f9ff4de 100644
--- a/Packaging:SourceURL.mw
+++ b/Packaging:SourceURL.mw
@@ -63,18 +63,8 @@ tar -czvf libfoo-$VERSION-nopatents.tar.gz libfoo-$VERSION
 

 
 {{Anchor|WeAreUpstream}}
-== We are Upstream ==
-
-For some packages where we are the upstream authors, for instance, the system-config-* tools, the source rpm that we distribute is the canonical source of the files.  There is no public revision control system or publically released tarball for these programs so there is no tarball to list.  Add a comment like the following to the spec:
-
-
-# This is a Red Hat maintained package which is specific to
-# our distribution.  Thus the source is only available from
-# within this srpm.
-Source0: system-config-foo-1.0.tar.gz
-

-
 {{Anchor|Sourceforge}}
+
 == Sourceforge.net ==
 
 For packages hosted on sourceforge, use

From 5545bdfa1af2fb1ec7f60cdda164bf4faa2f07d1 Mon Sep 17 00:00:00 2001
From: Spot 
Date: Aug 19 2009 16:55:49 +0000
Subject: [PATCH 367/3559] *Empty MediaWiki Message*


---

diff --git a/Packaging:Fortran.mw b/Packaging:Fortran.mw
index cd1eab2..73b9e50 100644
--- a/Packaging:Fortran.mw
+++ b/Packaging:Fortran.mw
@@ -2,16 +2,6 @@
 
 ''This document is loosely based on the [[PackagingDrafts/FortranLibraries|Fortran library draft]] and the [[PackagingDrafts/FortranModulesDir|Fortran modules directory guideline]]. It is supposed to replace both of them, due to [https://bugzilla.redhat.com/show_bug.cgi?id=483765 the bug in the Fortran modules directory guidelines].''
 
-== Introduction ==
-
-FORTRAN [http://en.wikipedia.org/wiki/Fortran] (short for FORmula TRANslator) was the first programming language ever, invented in 1957 and standardized in 1966. The Fortran 77 standard introduced improved support for structured programming such as if clauses.
-
-Fortran natively handles matrices and is rather easy to program and for these reasons it was widely adopted in the scientific community. Due to the large amount of legacy code, Fortran is still widely used in computational science. Some modernization has taken place, though.
-
-Fortran 90 presented a modernization of the language to support among others dynamic memory allocation, free-form source input and an argument passing mechanism to support compile time interface checking. Fortran 95 introduced many useful features such as vectorization constructs for high performance computing. 
-
-The Fortran 2003 standard added e.g. access to command line arguments and environment variables. The current standard under development is Fortran 2008.
-
 == Modules and include files ==
 
 The fortran modules files, ending in .mod are files describing a fortran 90 (and above) module API and ABI. These are not like C header files describing an API, they are compiler dependent and arch dependent, and not easily readable by a human being. They are nevertheless searched for in the includes directories by gfortran (in directories specified with -I).

From aee1ac4d0d0721bbdba4aa97cf608f038aa35560 Mon Sep 17 00:00:00 2001
From: Spot 
Date: Aug 19 2009 17:02:22 +0000
Subject: [PATCH 368/3559] *Empty MediaWiki Message*


---

diff --git a/Packaging:GuidelinesTodo.mw b/Packaging:GuidelinesTodo.mw
index 90d4ca8..bf6af6c 100644
--- a/Packaging:GuidelinesTodo.mw
+++ b/Packaging:GuidelinesTodo.mw
@@ -12,6 +12,8 @@ Status should be one of:
 |- style="color: white; background-color: #3074c2; font-weight: bold" 
 |Status||Task Name||Owner||Meeting Date||Notes
 |-
+|ratify||Fortran||[[User:jussilehtola|Jussi Lehtola]]||2009-08-19||[[PackagingDrafts/Fortran]]
+|-
 |ratify||MPI packaging||[[User:jussilehtola|Jussi Lehtola]]||2009-08-12||[[PackagingDrafts/MPI]]
 |-
 |ratify||Environment modules||[[User:jussilehtola|Jussi Lehtola]]||2009-08-12||[[PackagingDrafts/EnvironmentModules]]

From 2476de41d1feeef313df1ba338b375b18e30d147 Mon Sep 17 00:00:00 2001
From: Spot 
Date: Aug 19 2009 17:04:51 +0000
Subject: [PATCH 369/3559] *Empty MediaWiki Message*


---

diff --git a/Packaging:GuidelinesTodo.mw b/Packaging:GuidelinesTodo.mw
index bf6af6c..0707379 100644
--- a/Packaging:GuidelinesTodo.mw
+++ b/Packaging:GuidelinesTodo.mw
@@ -277,6 +277,8 @@ Status should be one of:
 |- style="color: white; background-color: #3074c2; font-weight: bold" 
 |Task Name||Owner||Resolution Date||Notes
 |-
+|Prohibit /usr/bin/env in shebang||abadger1999||2009-08-19||[[Script_Interpreters_(draft)]] This was rejected as a MUST, a SHOULD might be acceptable however.
+|-
 |filesystem subpackages||s4504kr||2009-08-12||[[PackagingDrafts/CreatingFilesystemSubpackages]] Instead of mandating many smaller -filesystem packages, it is preferred to improve the base system filesystem package to own common directories. Maintainers can still create -filesystem/-common packages as appropriate.
 |-
 |Guidelines for MAN pages||hubbitus||2009-05-12||[[MAN pages which exists in_other places(draft)]] This draft conflicts with the general practice that Fedora packagers should be working to send improvements directly to upstream. Anyone who feels motivated to dig in other distributions for patches or improvements should feel free to do so, but it is not something that the FPC felt should be codified into the guidelines.

From 415df525c17811a7ad1851054e53b3b9094af225 Mon Sep 17 00:00:00 2001
From: Spot 
Date: Aug 19 2009 17:05:57 +0000
Subject: [PATCH 370/3559] *Empty MediaWiki Message*


---

diff --git a/Packaging:GuidelinesTodo.mw b/Packaging:GuidelinesTodo.mw
index 0707379..973594c 100644
--- a/Packaging:GuidelinesTodo.mw
+++ b/Packaging:GuidelinesTodo.mw
@@ -54,6 +54,8 @@ Status should be one of:
 |- style="color: white; background-color: #3074c2; font-weight: bold" 
 |Task Name||Owner||Resolution Date||Notes
 |-
+|Drop special provision for when Red Hat is upstream||mether||2009-08-20|| https://fedoraproject.org/wiki/No_more_exception_where_we_are_upstream%28draft%29 FESCo decided to drop this requirement.
+|-
 |Guidelines for Pre-Review||abadger1999|| 2009-05-12 ||[[Pre-review Guidelines (draft)]] Approved by FPC, given to FESCo, not put into guidelines because it is a one-off.
 |-
 |Embedded Desktop Files || spot || 2009-04-14 || [[PackagingDrafts/EmbeddedDesktopFiles]]

From fc72bec0b43bdcd51834330df403def28a1e2adc Mon Sep 17 00:00:00 2001
From: Tibbs 
Date: Aug 20 2009 18:21:39 +0000
Subject: [PATCH 371/3559] Change tetex-latex dependencies in spec templates to tex(latex).


---

diff --git a/Packaging:R.mw b/Packaging:R.mw
index 7de0cd6..9cbbd99 100644
--- a/Packaging:R.mw
+++ b/Packaging:R.mw
@@ -38,7 +38,7 @@ License:          GPL
 URL:              http://cran.r-project.org/src/contrib
 Group:            Applications/Engineering
 Summary:          Adds foo functionality for R
-BuildRequires:    R-devel, tetex-latex
+BuildRequires:    R-devel, tex(latex)
 BuildRoot:        %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
 Requires(post):   R
 Requires(postun): R
@@ -106,7 +106,7 @@ License:          GPL
 URL:              http://cran.r-project.org/src/contrib
 Group:            Applications/Engineering
 Summary:          Adds foo functionality for R
-BuildRequires:    R-devel, tetex-latex
+BuildRequires:    R-devel, tex(latex)
 BuildRoot:        %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
 BuildArch:        noarch
 Requires(post):   R

From 2eee0185a1e6efa4151e988c453d61bf87e120b2 Mon Sep 17 00:00:00 2001
From: Tibbs 
Date: Aug 21 2009 20:22:27 +0000
Subject: [PATCH 372/3559] Correct specfile template to reference site-packages/lisp.


---

diff --git a/Packaging:Emacs_Old.mw b/Packaging:Emacs_Old.mw
index 635ee7b..ec0d5f9 100644
--- a/Packaging:Emacs_Old.mw
+++ b/Packaging:Emacs_Old.mw
@@ -94,8 +94,8 @@ Usually an add-on package will require a startup file, and this should be called
 The following code snippet show how to use macros to determine these at package build time:
 
 %if %($(pkg-config xemacs) ; echo $?)
-%global xemacs_lispdir %{_datadir}/xemacs/site-packages
-%global xemacs_startdir %{_datadir}/xemacs/site-packages/site-start.d
+%global xemacs_lispdir %{_datadir}/xemacs/site-packages/lisp
+%global xemacs_startdir %{_datadir}/xemacs/site-packages/lisp/site-start.d
 %else
 %global xemacs_lispdir %(pkg-config xemacs --variable sitepkglispdir)
 %global xemacs_startdir %(pkg-config xemacs --variable sitestartdir)

From ed81171d2eabe1e66514958933e52160818915d7 Mon Sep 17 00:00:00 2001
From: Tibbs 
Date: Aug 21 2009 20:23:26 +0000
Subject: [PATCH 373/3559] Correct specfile template to reference site-packages/lisp.


---

diff --git a/Packaging:Emacs_Old.mw b/Packaging:Emacs_Old.mw
index ec0d5f9..dc2920f 100644
--- a/Packaging:Emacs_Old.mw
+++ b/Packaging:Emacs_Old.mw
@@ -211,8 +211,8 @@ For convenience, there are two macros at the top of the file which you should cu
 
 %if %($(pkg-config xemacs) ; echo $?)
 %global xemacs_version 21.5
-%global xemacs_lispdir %{_datadir}/xemacs/site-packages
-%global xemacs_startdir %{_datadir}/xemacs/site-packages/site-start.d
+%global xemacs_lispdir %{_datadir}/xemacs/site-packages/lisp
+%global xemacs_startdir %{_datadir}/xemacs/site-packages/lisp/site-start.d
 %else
 %global xemacs_version %(pkg-config xemacs --modversion)
 %global xemacs_lispdir %(pkg-config xemacs --variable sitepkglispdir)

From 986cc3c7e6512b5c0f3b6c7a07c224cb9e87fe95 Mon Sep 17 00:00:00 2001
From: Mjakubicek 
Date: Aug 26 2009 22:10:17 +0000
Subject: [PATCH 374/3559] removed draft warning as this has been approved both by FPC and FESCo


---

diff --git a/Packaging:Fortran.mw b/Packaging:Fortran.mw
index 73b9e50..527a62b 100644
--- a/Packaging:Fortran.mw
+++ b/Packaging:Fortran.mw
@@ -1,7 +1,3 @@
-{{admon/warning|This is a draft document}}
-
-''This document is loosely based on the [[PackagingDrafts/FortranLibraries|Fortran library draft]] and the [[PackagingDrafts/FortranModulesDir|Fortran modules directory guideline]]. It is supposed to replace both of them, due to [https://bugzilla.redhat.com/show_bug.cgi?id=483765 the bug in the Fortran modules directory guidelines].''
-
 == Modules and include files ==
 
 The fortran modules files, ending in .mod are files describing a fortran 90 (and above) module API and ABI. These are not like C header files describing an API, they are compiler dependent and arch dependent, and not easily readable by a human being. They are nevertheless searched for in the includes directories by gfortran (in directories specified with -I).

From b94b5bf2225f11ebf65becdf98b726b6874b5a92 Mon Sep 17 00:00:00 2001
From: Tibbs 
Date: Aug 31 2009 20:27:47 +0000
Subject: [PATCH 375/3559] Clarify that License: can differ per subpackage.


---

diff --git a/Packaging:LicensingGuidelines.mw b/Packaging:LicensingGuidelines.mw
index f01faa1..1615a7d 100644
--- a/Packaging:LicensingGuidelines.mw
+++ b/Packaging:LicensingGuidelines.mw
@@ -23,6 +23,8 @@ Every Fedora package must contain a License: entry. Maintainers sho
 
 The License: field refers to the licenses of the contents of the '''''binary''''' rpm. When in doubt, ask.
 
+If a source package generates multiple binary packages, the License: field may differ between them if necessary.  This implies that a single spec may have multiple per-subpackage License: tags.  Each of those License: tags must comply with all applicable guidelines.
+
 {{Anchor|ValidLicenseShortNames}}
 === Valid License Short Names ===
 The License: field must be filled with the appropriate license Short License identifier(s) from the "Good License" tables on the [[Licensing|  Fedora Licensing]]  page. If your license does not appear in the tables, it needs to be sent to fedora-legal-list@redhat.com (note that this list is moderated, only members may directly post). If the license is approved, it will be added to the appropriate table.

From 0957e36285f50dff5e0a5b63cbb8befdf25048bc Mon Sep 17 00:00:00 2001
From: Scop 
Date: Sep 03 2009 16:19:52 +0000
Subject: [PATCH 376/3559] /* Usage */ https://www.redhat.com/archives/fedora-packaging/2009-September/msg00018.html


---

diff --git a/Packaging:AutoProvidesAndRequiresFiltering.mw b/Packaging:AutoProvidesAndRequiresFiltering.mw
index 5a3068a..10db615 100644
--- a/Packaging:AutoProvidesAndRequiresFiltering.mw
+++ b/Packaging:AutoProvidesAndRequiresFiltering.mw
@@ -29,7 +29,7 @@ As it stands, filtering these auto-generated requires and provides is difficult 
 
 == Usage ==
 
-These filtering macros '''MUST''' only be used with packages which meet the following criteria:
+These filtering macros '''MUST''' only be used with packages which meet one of the following criteria:
 * Noarch packages
 * Architecture specific packages with no binaries in $PATH (e.g. /bin, /usr/bin, /sbin, /sbin) or libexecdir and no system libs in libdir. This includes all of the subpackages generated from the spec file.
 

From 85173d9a7a21f255ffe35aeedd6c18879ad8e45b Mon Sep 17 00:00:00 2001
From: Scop 
Date: Sep 03 2009 16:20:53 +0000
Subject: [PATCH 377/3559] /* Removing items from the provides stream (post-scan filtering) */ https://www.redhat.com/archives/fedora-packaging/2009-September/msg00020.html


---

diff --git a/Packaging:AutoProvidesAndRequiresFiltering.mw b/Packaging:AutoProvidesAndRequiresFiltering.mw
index 10db615..9e39850 100644
--- a/Packaging:AutoProvidesAndRequiresFiltering.mw
+++ b/Packaging:AutoProvidesAndRequiresFiltering.mw
@@ -60,7 +60,7 @@ The '''%filter_requires_in''' macro is used to define the files or directories t
 
 === Removing items from the provides stream (post-scan filtering) ===
 
-Post-scan provides filtering is invoked through the '''%filter_from_provides'''.  This macro can be fed PCRE's to filter from the stream of auto-found provides.
+Post-scan provides filtering is invoked through the '''%filter_from_provides'''.  This macro can be fed a sed expression to filter from the stream of auto-found provides.
 
 For example, if we're finding that the auto-prov system is finding an incorrect provide, we can filter it:
 

From aaedb9d5b19808ca23438ce249a0f6788e3ede77 Mon Sep 17 00:00:00 2001
From: Scop 
Date: Sep 03 2009 19:27:33 +0000
Subject: [PATCH 378/3559] /* Preventing files/directories from being scanned for provides (pre-scan filtering) */ Remove extra backslashes from examples


---

diff --git a/Packaging:AutoProvidesAndRequiresFiltering.mw b/Packaging:AutoProvidesAndRequiresFiltering.mw
index 9e39850..59dacd7 100644
--- a/Packaging:AutoProvidesAndRequiresFiltering.mw
+++ b/Packaging:AutoProvidesAndRequiresFiltering.mw
@@ -45,8 +45,8 @@ The '''%filter_provides_in''' macro is used to define the files or directories t
 
 We can filter by regex:
 
-%filter_provides_in %{perl_vendorarch}/.*\\.so$ 
-%filter_provides_in -P %{perl_archlib}/(?!CORE/libperl).*\\.so$ 
+%filter_provides_in %{perl_vendorarch}/.*\.so$ 
+%filter_provides_in -P %{perl_archlib}/(?!CORE/libperl).*\.so$ 
 

 
 Or by anything matching, say, a directory:

From 7c11a5141ddf923cd5fe96f888e81185bd7dfbd4 Mon Sep 17 00:00:00 2001
From: Scop 
Date: Sep 03 2009 19:27:50 +0000
Subject: [PATCH 379/3559] /* Pidgin plugin package */ Remove extra backslashes from examples


---

diff --git a/Packaging:AutoProvidesAndRequiresFiltering.mw b/Packaging:AutoProvidesAndRequiresFiltering.mw
index 59dacd7..8f07d7a 100644
--- a/Packaging:AutoProvidesAndRequiresFiltering.mw
+++ b/Packaging:AutoProvidesAndRequiresFiltering.mw
@@ -93,7 +93,7 @@ On a x86_64 machine, the pidgin-libnotify provides pidgin-libnotify.so()(64bit),
 To filter this out, we could use:
 
 
-%filter_provides_in %{_libdir}/purple-2/.*\\.so$
+%filter_provides_in %{_libdir}/purple-2/.*\.so$
 %filter_setup
 

 

From 77754f6406a715c7a3a7b5a56fae3aa04c464541 Mon Sep 17 00:00:00 2001
From: Scop 
Date: Sep 03 2009 19:28:10 +0000
Subject: [PATCH 380/3559] /* Arch-specific perl-* package */ Remove extra backslashes from examples


---

diff --git a/Packaging:AutoProvidesAndRequiresFiltering.mw b/Packaging:AutoProvidesAndRequiresFiltering.mw
index 8f07d7a..6d97185 100644
--- a/Packaging:AutoProvidesAndRequiresFiltering.mw
+++ b/Packaging:AutoProvidesAndRequiresFiltering.mw
@@ -103,8 +103,8 @@ e.g. to ensure an arch-specific perl-* package won't provide or require things t
 
 
 # we don't want to provide private Perl extension libs
-%filter_provides_in %{perl_vendorarch}/.*\\.so$ 
-%filter_provides_in -P %{perl_archlib}/(?!CORE/libperl).*\\.so$ 
+%filter_provides_in %{perl_vendorarch}/.*\.so$ 
+%filter_provides_in -P %{perl_archlib}/(?!CORE/libperl).*\.so$ 
 
 # actually set up the filtering
 %filter_setup

From 4797b4229efbcdc6c40657d2c061cd82b997b3e8 Mon Sep 17 00:00:00 2001
From: Spot 
Date: Sep 09 2009 20:55:12 +0000
Subject: [PATCH 381/3559] *Empty MediaWiki Message*


---

diff --git a/Packaging:GuidelinesTodo.mw b/Packaging:GuidelinesTodo.mw
index 973594c..5e5892a 100644
--- a/Packaging:GuidelinesTodo.mw
+++ b/Packaging:GuidelinesTodo.mw
@@ -12,19 +12,21 @@ Status should be one of:
 |- style="color: white; background-color: #3074c2; font-weight: bold" 
 |Status||Task Name||Owner||Meeting Date||Notes
 |-
-|ratify||Fortran||[[User:jussilehtola|Jussi Lehtola]]||2009-08-19||[[PackagingDrafts/Fortran]]
+|ratify||Use the better source||mether||2009-09-09|| Draft available at https://fedoraproject.org/wiki/PackagingDrafts/Use_Better_Source 
 |-
-|ratify||MPI packaging||[[User:jussilehtola|Jussi Lehtola]]||2009-08-12||[[PackagingDrafts/MPI]]
+|writeup||Fortran||[[User:jussilehtola|Jussi Lehtola]]||2009-08-19||[[PackagingDrafts/Fortran]]
 |-
-|ratify||Environment modules||[[User:jussilehtola|Jussi Lehtola]]||2009-08-12||[[PackagingDrafts/EnvironmentModules]]
+|writeup||MPI packaging||[[User:jussilehtola|Jussi Lehtola]]||2009-08-12||[[PackagingDrafts/MPI]]
 |-
-|ratify||Correct ant sample spec||[[User:jussilehtola|Jussi Lehtola]]||2009-08-12||[[PackagingDrafts/JavaAntSampleSpec]]
+|writeup||Environment modules||[[User:jussilehtola|Jussi Lehtola]]||2009-08-12||[[PackagingDrafts/EnvironmentModules]]
 |-
-|ratify||Update R guidelines||[[User:pingou|pingou]]||2009-08-12|| [[ProposalUpdateRGuidelines]]
+|writeup||Correct ant sample spec||[[User:jussilehtola|Jussi Lehtola]]||2009-08-12||[[PackagingDrafts/JavaAntSampleSpec]]
 |-
-|ratify||Drop Scrollkeeper Scriptlets||[[User:spot|spot]]||2009-08-12|| [[PackagingDrafts/DropScrollkeeperUpdate]]
+|writeup||Update R guidelines||[[User:pingou|pingou]]||2009-08-12|| [[ProposalUpdateRGuidelines]]
 |-
-|ratify||Numpy and pygtk2||[[User:spot|spot]]||2009-08-12|| [[PackagingDrafts/PythonNumpy]]
+|writeup||Drop Scrollkeeper Scriptlets||[[User:spot|spot]]||2009-08-12|| [[PackagingDrafts/DropScrollkeeperUpdate]]
+|-
+|writeup||Numpy and pygtk2||[[User:spot|spot]]||2009-08-12|| [[PackagingDrafts/PythonNumpy]]
 |-
 |writeup||dos2unix||atorkhov|| 2009-07-28||[[PackagingDrafts/Dos2unix]]
 |-
@@ -279,6 +281,8 @@ Status should be one of:
 |- style="color: white; background-color: #3074c2; font-weight: bold" 
 |Task Name||Owner||Resolution Date||Notes
 |-
+|Games||mether||2009-09-09|| https://fedoraproject.org/w/index.php?title=SIGs/Games/Packaging is not a set of guidelines, just strong recommendations from the Games SIG. As is, it is not appropriate as Guidelines. If the Games SIG wishes to make them required guidelines, they can resubmit them for inclusion.
+|-
 |Prohibit /usr/bin/env in shebang||abadger1999||2009-08-19||[[Script_Interpreters_(draft)]] This was rejected as a MUST, a SHOULD might be acceptable however.
 |-
 |filesystem subpackages||s4504kr||2009-08-12||[[PackagingDrafts/CreatingFilesystemSubpackages]] Instead of mandating many smaller -filesystem packages, it is preferred to improve the base system filesystem package to own common directories. Maintainers can still create -filesystem/-common packages as appropriate.

From 7eb98744d3d5860bd71cfa40b1d91f893df81549 Mon Sep 17 00:00:00 2001
From: Tibbs 
Date: Sep 11 2009 20:59:59 +0000
Subject: [PATCH 382/3559] Note the approved guideline from the 2009-09-11 FESCo meeting.


---

diff --git a/Packaging:GuidelinesTodo.mw b/Packaging:GuidelinesTodo.mw
index 5e5892a..75c2dc9 100644
--- a/Packaging:GuidelinesTodo.mw
+++ b/Packaging:GuidelinesTodo.mw
@@ -12,7 +12,7 @@ Status should be one of:
 |- style="color: white; background-color: #3074c2; font-weight: bold" 
 |Status||Task Name||Owner||Meeting Date||Notes
 |-
-|ratify||Use the better source||mether||2009-09-09|| Draft available at https://fedoraproject.org/wiki/PackagingDrafts/Use_Better_Source 
+|writeup||Use the better source||mether||2009-09-09|| Draft available at https://fedoraproject.org/wiki/PackagingDrafts/Use_Better_Source 
 |-
 |writeup||Fortran||[[User:jussilehtola|Jussi Lehtola]]||2009-08-19||[[PackagingDrafts/Fortran]]
 |-

From 8f5901c261e0e334a2dcd939fd2b3e30b2b625bf Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Sep 15 2009 18:22:21 +0000
Subject: [PATCH 383/3559] Add MUST no bundling of libraries


---

diff --git a/Packaging:ReviewGuidelines.mw b/Packaging:ReviewGuidelines.mw
index 9d9eb23..c030ff5 100644
--- a/Packaging:ReviewGuidelines.mw
+++ b/Packaging:ReviewGuidelines.mw
@@ -34,6 +34,7 @@ There are many many things to check for a review. This list is provided to assis
 * '''MUST''': All build dependencies must be listed in BuildRequires, except for any that are listed in the [[Packaging/Guidelines#Exceptions_2|exceptions section of the Packaging Guidelines]] ; inclusion of those as BuildRequires is optional. Apply common sense.

 * '''MUST''': The spec file MUST handle locales properly. This is done by using the %find_lang macro. Using %{_datadir}/locale/* is strictly forbidden.[[Packaging/Guidelines#Handling_Locale_Files|Packaging Guidelines: Handling Locale Files]]

 * '''MUST''': Every binary RPM package (or subpackage) which stores shared library files (not just symlinks) in any of the dynamic linker's default paths, must call ldconfig in %post and %postun. [[Packaging/Guidelines#Shared_Libraries|Packaging Guidelines: Shared Libraries]]

+* '''MUST''': Packages must NOT bundle copies of system libraries.[[Packaging:Guidelines#Duplication_of_system_libraries|Packaging Guidelines: Duplication of System Libraries]]

 * '''MUST''': If the package is designed to be relocatable, the packager must state this fact in the request for review, along with the rationalization for relocation of that specific package. Without this, use of Prefix: /usr is considered a blocker. [[Packaging/Guidelines#RelocatablePackages|Packaging Guidelines: Relocatable Packages]]

 * '''MUST''': A package must own all directories that it creates. If it does not create a directory that it uses, then it should require a package which does create that directory.  [[Packaging/Guidelines#FileAndDirectoryOwnership|Packaging Guidelines: File And Directory Ownership]]

 * '''MUST''': A Fedora package must not list a file more than once in the spec file's %files listings. [[Packaging/Guidelines#DuplicateFiles|Packaging Guidelines: Duplicate Files]]


From bbae619b20d58c82d3e3b5fabe151e1d2f70f0ad Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Sep 15 2009 18:24:23 +0000
Subject: [PATCH 384/3559] Add link to no bundled libraries


---

diff --git a/Packaging:Guidelines.mw b/Packaging:Guidelines.mw
index 480af7c..0e6f54a 100644
--- a/Packaging:Guidelines.mw
+++ b/Packaging:Guidelines.mw
@@ -484,11 +484,9 @@ Packages which explicitly need to link against the static version must Bui
 {{Anchor|SystemLibraryDuplication}}
 == Duplication of system libraries ==
 
-For several reasons, a package should not include or build against a local copy of a library that exists on a system. The package should be patched to use the system libraries.
-
-This prevents old bugs and security holes from living on after the core system libraries have been fixed.
-
+A package should not include or build against a local copy of a library that exists on a system. The package should be patched to use the system libraries.  This prevents old bugs and security holes from living on after the core system libraries have been fixed.  More rationale for this is on the [[Packaging:No Bundled Libraries|No Bundled Libraries]] page.
 {{Anchor|Rpath}}
+
 == Beware of Rpath ==
 Sometimes, code will hardcode specific library paths when linking binaries (using the -rpath or -R flag). This is commonly referred to as an rpath, and in Fedora it is forbidden. Normally, the dynamic linker and loader (ld.so) resolve the executable's dependencies on shared libraries and load what is required. However, when -rpath or -R is used, the location information is then hardcoded into the binary and is examined by ld.so in the beginning of the execution. Since the Linux dynamic linker is usually smarter than a hardcoded path, we do not permit the use of rpath in Fedora.
 

From 491c2f7fa334e08052e7ff6e5e0de249e20417bc Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Sep 15 2009 18:25:51 +0000
Subject: [PATCH 385/3559] No bundled libraries written up


---

diff --git a/Packaging:GuidelinesTodo.mw b/Packaging:GuidelinesTodo.mw
index 75c2dc9..543d6fc 100644
--- a/Packaging:GuidelinesTodo.mw
+++ b/Packaging:GuidelinesTodo.mw
@@ -32,7 +32,7 @@ Status should be one of:
 |-
 |writeup||Filtering auto-provides||cweyl||2009-07-28||[[PackagingDrafts/AutoProvidesAndRequiresFiltering]]
 |-
-|writeup||Explanation of no bundled libraries||abadger1999||2009-07-28||[[No_Bundled_Libraries]]
+|announce||Explanation of no bundled libraries||abadger1999||2009-07-28||[[No_Bundled_Libraries]]
 |-
 |writeup||pre-built binaries||oget||2009-07-28||[[PackagingDrafts/Removal_of_pre-built_binaries]]
 |-

From 2672744cefb819fcef826e7c9c87422fe1f7b220 Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Sep 15 2009 18:43:19 +0000
Subject: [PATCH 386/3559] Update from Removal of pre-built binaries


---

diff --git a/Packaging:Guidelines.mw b/Packaging:Guidelines.mw
index 0e6f54a..16c3e92 100644
--- a/Packaging:Guidelines.mw
+++ b/Packaging:Guidelines.mw
@@ -34,21 +34,30 @@ You should review [[Licensing:Main]]  and the [[Packaging:LicensingGuidelines]] 
 
 == No inclusion of pre-built binaries or libraries ==
 
-All binaries or libraries included with Fedora packages must have been built from sourcecode included in the source package. This is a requirement for the following reasons:
-* Security: Pre-packaged binaries and libraries not built from source could include anything, malicious, dangerous, or just broken. Also, these are functionally impossible to patch.
-* Compiler Flags: Pre-packaged binaries and libraries not built from source probably don't have the standard Fedora compiler flags for security and optimization.
+All program binaries and program libraries included in Fedora packages must be built from the source code that is included in the source package. This is a requirement for the following reasons:
+* Security: Pre-packaged program binaries and program libraries not built from the source code could contain parts that are malicious, dangerous, or just broken. Also, these are functionally impossible to patch.
+* Compiler Flags: Pre-packaged program binaries and program libraries not built from the source code were probably not compiled with standard Fedora compiler flags for security and optimization.
 
-If you are in doubt as to whether something is considered a binary or library, here is some helpful criteria:
-* Is it executable? If so, it is probably a binary.
-* Does it contain a .so, ,so.#, or .so.#.#.# extension? If so, it is probably a library.
+Content binaries (such as .mo, .pdf, .png, .ps files) are ''not'' required to be rebuilt from the source code.
+
+If you are in doubt as to whether something is considered a program binary or a program library, here is some helpful criteria:
+* Is it executable? If so, it is probably a program binary.
+* Does it contain a .so, ,so.#, or .so.#.#.# extension? If so, it is probably a program library.
 * If in doubt, ask your reviewer. If the reviewer is not sure, they should ask the Fedora Packaging Committee.
 
 Packages which require non-open source components to build are also not permitted (e.g. proprietary compiler required).
 
+When you encounter prebuilt binaries in a package you '''MUST''':
+
+* Remove all pre-built program binaries and program libraries in %prep prior to the building of the package. Examples include, but are not limited to, *.class, *.dll, *.DS_Store, *.exe, *.jar, *.o, *.pyc, *.pyo, *.so files.
+* Ask upstream to remove the binaries in their next release.
+
 {{Anchor|SourceRequirementExceptions}}
 === Exceptions ===
+
 * Some software (usually related to compilers or cross-compiler environments) cannot be built without the use of a previous toolchain or development environment (open source). If you have a package which meets this criteria, contact the Fedora Packaging Committee for approval.
-* An exception is made for binary firmware, as long as it meets the requirements documented here: [[Packaging:LicensingGuidelines#BinaryFirmware|BinaryFirmware]]
+* An exception is made for binary firmware, as long as it meets the requirements documented here: [[Licensing:Main#Binary_Firmware]]
+* Some pre-packaged program binaries or program libraries may be under terms which do not permit redistribution, or be affected by legal scenarios such as patents. In such situations, simply deleting these files in %prep is not sufficient, the maintainer will need to make a modified source that does not contain these files. See: [[Packaging:SourceURL#When_Upstream_uses_Prohibited_Code]]
 
 {{Anchor|Spec Legibility}}
 

From 7a3a7f15773c88bb79600d43130ead7bf3ead4a5 Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Sep 15 2009 18:46:04 +0000
Subject: [PATCH 387/3559] prebuilt-binaries done


---

diff --git a/Packaging:GuidelinesTodo.mw b/Packaging:GuidelinesTodo.mw
index 543d6fc..246958a 100644
--- a/Packaging:GuidelinesTodo.mw
+++ b/Packaging:GuidelinesTodo.mw
@@ -34,7 +34,7 @@ Status should be one of:
 |-
 |announce||Explanation of no bundled libraries||abadger1999||2009-07-28||[[No_Bundled_Libraries]]
 |-
-|writeup||pre-built binaries||oget||2009-07-28||[[PackagingDrafts/Removal_of_pre-built_binaries]]
+|announce||pre-built binaries||oget||2009-07-28||[[PackagingDrafts/Removal_of_pre-built_binaries]]
 |-
 |announce||Phase out Buildroot||abadger1999||2009-06-02||https://fedoraproject.org/wiki/Phase_out_buildroot_tag_%28draft%29
 |-

From 1edeb6ccfebc4fadcee6dfbc81f400cf8b082be7 Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Sep 15 2009 18:49:10 +0000
Subject: [PATCH 388/3559] Update since dos2unix has been reliable for a while


---

diff --git a/Packaging:Guidelines.mw b/Packaging:Guidelines.mw
index 16c3e92..62c8378 100644
--- a/Packaging:Guidelines.mw
+++ b/Packaging:Guidelines.mw
@@ -119,10 +119,12 @@ Rpmlint has the ability to make a lot of noise when it is run, even on perfectly
 * E: foo-package no-packager-tag: This error occurs because no Packager: value is defined in the spec file. In Fedora, we do not use the Packager tag, so you can ignore this error.
 * E: foo-package no-signature: This error occurs because your package is not signed. Since Fedora doesn't store SRPMS in CVS (only the files inside them), you do not need to sign your package, and you can ignore this error.
 * W: foo-package summary-ended-with-dot Summary of my package.: This error occurs because the entry in your spec for Summary: ended with a period. Just get rid of the period at the end of the line.
-* E: foo-package wrong-script-end-of-line-encoding /path/to/somefile: This error occurs because of DOS line breaks in a file. Fix it with sed in the %prep section: %{__sed} -i 's/\r//' src/somefile -- DONT use dos2unix, that can cause build fail on FC3.
+* E: foo-package wrong-script-end-of-line-encoding /path/to/somefile: This error occurs because of DOS line breaks in a file. Fix it in the %prep section with sed: %{__sed} -i 's/\r//' src/somefile or dos2unix.
+
 * E: foo-package invalid-lc-messages-dir /usr/share/locale/xx_XX/LC_MESSAGES/foo.mo: This error is a common false positive and usually should be ignored.
 
 {{Anchor|Changelogs}}
+
 == Changelogs ==
 ''Every time'' you make changes, that is, whenever you increment the E-V-R of a package, add a changelog entry. This is important not only to have an idea about the history of a package, but also to enable users, fellow packages, and QA people to easily spot the changes that you make.
 

From bc74065be2915731b6bad91df67e1d3a1bd98f4c Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Sep 15 2009 18:52:58 +0000
Subject: [PATCH 389/3559] dos2unix merged


---

diff --git a/Packaging:GuidelinesTodo.mw b/Packaging:GuidelinesTodo.mw
index 246958a..3a6f58f 100644
--- a/Packaging:GuidelinesTodo.mw
+++ b/Packaging:GuidelinesTodo.mw
@@ -28,7 +28,7 @@ Status should be one of:
 |-
 |writeup||Numpy and pygtk2||[[User:spot|spot]]||2009-08-12|| [[PackagingDrafts/PythonNumpy]]
 |-
-|writeup||dos2unix||atorkhov|| 2009-07-28||[[PackagingDrafts/Dos2unix]]
+|announce||dos2unix||atorkhov|| 2009-07-28||[[PackagingDrafts/Dos2unix]]
 |-
 |writeup||Filtering auto-provides||cweyl||2009-07-28||[[PackagingDrafts/AutoProvidesAndRequiresFiltering]]
 |-

From a8802fa82877d6d29eebc240df45b3ee2b223400 Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Sep 15 2009 19:11:18 +0000
Subject: [PATCH 390/3559] numpy merged


---

diff --git a/Packaging:GuidelinesTodo.mw b/Packaging:GuidelinesTodo.mw
index 3a6f58f..032d438 100644
--- a/Packaging:GuidelinesTodo.mw
+++ b/Packaging:GuidelinesTodo.mw
@@ -26,7 +26,7 @@ Status should be one of:
 |-
 |writeup||Drop Scrollkeeper Scriptlets||[[User:spot|spot]]||2009-08-12|| [[PackagingDrafts/DropScrollkeeperUpdate]]
 |-
-|writeup||Numpy and pygtk2||[[User:spot|spot]]||2009-08-12|| [[PackagingDrafts/PythonNumpy]]
+|announce||Numpy and pygtk2||[[User:spot|spot]]||2009-08-12|| [[PackagingDrafts/PythonNumpy]]
 |-
 |announce||dos2unix||atorkhov|| 2009-07-28||[[PackagingDrafts/Dos2unix]]
 |-

From 5197b51b7a20d40143abf51e700e23c48534a3c1 Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Sep 15 2009 19:18:27 +0000
Subject: [PATCH 391/3559] scrollkeeper no longer needed


---

diff --git a/Packaging:Scriptlets.mw b/Packaging:Scriptlets.mw
index ded91ec..a2b5264 100644
--- a/Packaging:Scriptlets.mw
+++ b/Packaging:Scriptlets.mw
@@ -164,24 +164,8 @@ fi
 These two scriptlets tell install-info to add entries for the info pages to the main index file on installation and remove them at erase time.  The "|| :" in this case prevents failures that would typically affect systems that have been configured not to install any %doc files, or have read-only mounted, %_netsharedpath /usr/share.
 
 {{Anchor|scrollkeeper}}
-
 == Scrollkeeper ==
-Gnome and KDE use the scrollkeeper cataloging system to keep track of documentation installed on the system.  Scrollkeeper allows the help system to sort and search documentation metadata stored in .omf files.  When you add documentation in these systems you need to make scrollkeeper aware that the documentation has been changed.
-
-Note that we ''''''BuildRequires scrollkeeper as most Makefile's are setup to install the necessary scrollkeeper files only if scrollkeeper is present at install time.
-
-BuildRequires:  scrollkeeper
-Requires(post): scrollkeeper
-Requires(postun): scrollkeeper
-...
-%post
-scrollkeeper-update -q -o %{_datadir}/omf/%{name} || :
-
-%postun
-scrollkeeper-update -q || :
-

-These two scriptlets tell scrollkeeper to update its indexes to account for the new scrollkeeper files.
-
+In all current Fedora, rarian has replaced scrollkeeper.  There is no scriptlet needed for rarian.  For instructions on what to do in EPEL releases, see [[Packaging:EPEL#Scrollkeeper]]
 
 {{Anchor|desktopdb}}
 == desktop-database ==

From fb21747117aa2823aff8f180f4dec0a258c38916 Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Sep 15 2009 19:26:04 +0000
Subject: [PATCH 392/3559] scrollkeeper changes merged


---

diff --git a/Packaging:GuidelinesTodo.mw b/Packaging:GuidelinesTodo.mw
index 032d438..102d279 100644
--- a/Packaging:GuidelinesTodo.mw
+++ b/Packaging:GuidelinesTodo.mw
@@ -24,7 +24,7 @@ Status should be one of:
 |-
 |writeup||Update R guidelines||[[User:pingou|pingou]]||2009-08-12|| [[ProposalUpdateRGuidelines]]
 |-
-|writeup||Drop Scrollkeeper Scriptlets||[[User:spot|spot]]||2009-08-12|| [[PackagingDrafts/DropScrollkeeperUpdate]]
+|announce||Drop Scrollkeeper Scriptlets||[[User:spot|spot]]||2009-08-12|| [[PackagingDrafts/DropScrollkeeperUpdate]]
 |-
 |announce||Numpy and pygtk2||[[User:spot|spot]]||2009-08-12|| [[PackagingDrafts/PythonNumpy]]
 |-

From d96366e157f347f2e69b412be91d6a283f0363a1 Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Sep 15 2009 19:46:19 +0000
Subject: [PATCH 393/3559] Merge R Guideline changes


---

diff --git a/Packaging:R.mw b/Packaging:R.mw
index 9cbbd99..f82ec11 100644
--- a/Packaging:R.mw
+++ b/Packaging:R.mw
@@ -1,7 +1,3 @@
-= How to package R modules =
-
-
-
 == What is R? ==
 The definition from [http://www.r-project.org/ The R-Project website]  says that R is:
 
@@ -19,6 +15,8 @@ If you are looking for more information on R, you can go to:
 If you are interested in packaging R modules, or if you are looking for R libraries, you should check here for upstream sources:
 * [http://www.bioconductor.org/ The bioconductor website] 
 * [http://cran.r-project.org/ The CRAN website] 
+* [http://r-forge.r-project.org/ The R-forge from the R-Project website]
+* [http://www.rforge.net/ The RForge website]
 
 == Spec Templates for R packages ==
 
@@ -167,6 +165,10 @@ rm -rf $RPM_BUILD_ROOT
 * Noarch packages set BuildArch: noarch
 * Noarch packages install into %{_datadir}/R/library/%{packname}, arch-specific packages install into %{_libdir}/R/library/%{packname}
 
+=== R2spec ===
+R2spec is an excellent little tool to assist in creating Fedora-compliant packages for R libraries. Using it as a starting point is recommended (but certainly not mandated).
+More information here : https://fedorahosted.org/r2spec/
+
 == R packaging tips ==
 
 === Naming of R packages ===
@@ -179,6 +181,17 @@ R-RScaLAPACK (R module named RScaLAPACK)
 R-waveslim (R module named waveslim)
 

 
+=== R version ===
+Many R packages contain '-' in their version. Usually, the versioning used is a sequence of at least two (and usually three) non-negative integers separated by single '.' or '-' characters.
+
+To be consistent with the versioning system used in Fedora, you should simply replace dashes with dots.
+
+Example:
+
+Upstream tarball: Rfoo-0.5-8.tar.gz
+Fedora Version: 0.5.8
+

+
 === Empty %build section ===
 Unlike normal Fedora packages, there is normally no separate %build actions (e.g. %configure)that need to be taken for an R package. However, it is important that all R module packages include an empty %build section, as shown in the spec templates.
 
@@ -223,5 +236,13 @@ Note that frequently, R packages have circular dependency loops when running R CMD INSTALL operation will install all of the files, including documentation files. The latex, doc, html, man, NEWS, and DESCRIPTION files/directories need to be marked as %doc.
 Note that other files, such as CONTENTS, INDEX, NAMESPACE, and help/ are not %doc, since proper R functionality depends on their presence. Be careful not to duplicate %doc files in the package, the spec templates provide good examples on how to package the R addon files without duplications.
 
+==== R documentation ====
+R documentation is written in Tex. rpmlint sometimes complains that these Tex files are not utf-8 files, but the encoding is normally specified in the file when needed, so this error is safe to ignore (and you should not try to re-encode the files).
+
 === Optimization flags ===
 R packages inherit their optimization flags from the main R package, which stores them in %{_libdir}/R/etc/Makeconf. The design of R is such that all R addon library modules use the same optimization flags that the main R package was built with. Accordingly, this is why R addon packages do not pass $RPM_OPT_FLAGS. Also, there is no simple way to pass special optimization flags to R CMD INSTALL.
+
+=== R headers ===
+R packages usually expect to find their header files in %{_libdir}/R/library/*/. rpmlint will complain that these files are misplaced, but this is safe to ignore.
+
+You should still separate these header files into a -devel subpackage.

From f984b1e12ad2de78f4f740465404ae730b7435fe Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Sep 15 2009 19:46:55 +0000
Subject: [PATCH 394/3559] Add Category


---

diff --git a/Packaging:R.mw b/Packaging:R.mw
index f82ec11..95480be 100644
--- a/Packaging:R.mw
+++ b/Packaging:R.mw
@@ -246,3 +246,5 @@ R packages inherit their optimization flags from the main R package, which store
 R packages usually expect to find their header files in %{_libdir}/R/library/*/. rpmlint will complain that these files are misplaced, but this is safe to ignore.
 
 You should still separate these header files into a -devel subpackage.
+
+[[Category:Packaging guidelines]]

From a4708f5b7b7157c1a0f3cb2f2b416c56cb494898 Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Sep 15 2009 19:55:58 +0000
Subject: [PATCH 395/3559] Add smallest compressed archive tip


---

diff --git a/Packaging:SourceURL.mw b/Packaging:SourceURL.mw
index f9ff4de..0d8f7b2 100644
--- a/Packaging:SourceURL.mw
+++ b/Packaging:SourceURL.mw
@@ -13,6 +13,8 @@ Source0: http://downloads.sourceforge.net/%{name}/%{name}-%{version}.tar.gz
 Source0: http://ftp.gnome.org/pub/GNOME/sources/gnome-common/2.12/gnome-common-2.12.0.tar.bz2
 

 
+{{admon/tip|Smallest Compressed Archive|If the upstream source archive is available in multiple compressed formats that our tools can decompress it's best to use the one that is smallest in size. This ensures the smallest source rpm to save space on the mirrors and downloads of source RPM packages.}}
+
 There are several cases where upstream is not providing the source to you in an upstream tarball.  In these cases you must document how to generate the tarball used in the rpm either through a spec file comment or a script included as a separate SourceX:.
 
 Here are some specific examples:
@@ -86,4 +88,4 @@ When upstream has URLs for the download that do not end with the tarball name, r
   # http://dev.mysql.com/downloads/mysql/5.1.html
   Source0: mysql-5.1.31.tar.gz
 ----
-[[Category:Extras]]
+[[Category:Packaging guidelines]]

From ea23d565255966dca6275bafc3be7a8db5793c93 Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Sep 15 2009 20:00:13 +0000
Subject: [PATCH 396/3559] Update to fix find command in the spec template


---

diff --git a/Packaging:Java.mw b/Packaging:Java.mw
index 2f1780d..6b79d26 100644
--- a/Packaging:Java.mw
+++ b/Packaging:Java.mw
@@ -190,7 +190,9 @@ The manual for %{name}.
 %setup -q
 
 
-find -name '*.jar' -o -name '*.class' -exec rm -f '{}' \;
+find -name '*.class' -exec rm -f '{}' \;
+find -name '*.jar' -exec rm -f '{}' \;
+
 
 
 %build

From 1d7ad92deb0a630442121a00036f34a8f120a69c Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Sep 15 2009 20:01:01 +0000
Subject: [PATCH 397/3559] ant spec sample ; R update; Smaller archives


---

diff --git a/Packaging:GuidelinesTodo.mw b/Packaging:GuidelinesTodo.mw
index 102d279..86b5c47 100644
--- a/Packaging:GuidelinesTodo.mw
+++ b/Packaging:GuidelinesTodo.mw
@@ -12,7 +12,7 @@ Status should be one of:
 |- style="color: white; background-color: #3074c2; font-weight: bold" 
 |Status||Task Name||Owner||Meeting Date||Notes
 |-
-|writeup||Use the better source||mether||2009-09-09|| Draft available at https://fedoraproject.org/wiki/PackagingDrafts/Use_Better_Source 
+|announce||Use the better source||mether||2009-09-09|| Draft available at https://fedoraproject.org/wiki/PackagingDrafts/Use_Better_Source 
 |-
 |writeup||Fortran||[[User:jussilehtola|Jussi Lehtola]]||2009-08-19||[[PackagingDrafts/Fortran]]
 |-
@@ -20,9 +20,9 @@ Status should be one of:
 |-
 |writeup||Environment modules||[[User:jussilehtola|Jussi Lehtola]]||2009-08-12||[[PackagingDrafts/EnvironmentModules]]
 |-
-|writeup||Correct ant sample spec||[[User:jussilehtola|Jussi Lehtola]]||2009-08-12||[[PackagingDrafts/JavaAntSampleSpec]]
+|announce||Correct ant sample spec||[[User:jussilehtola|Jussi Lehtola]]||2009-08-12||[[PackagingDrafts/JavaAntSampleSpec]]
 |-
-|writeup||Update R guidelines||[[User:pingou|pingou]]||2009-08-12|| [[ProposalUpdateRGuidelines]]
+|announce||Update R guidelines||[[User:pingou|pingou]]||2009-08-12|| [[ProposalUpdateRGuidelines]]
 |-
 |announce||Drop Scrollkeeper Scriptlets||[[User:spot|spot]]||2009-08-12|| [[PackagingDrafts/DropScrollkeeperUpdate]]
 |-

From 94fd0bd6f37fefe50c0b9f13a35d789828c5ed2d Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Sep 15 2009 20:02:19 +0000
Subject: [PATCH 398/3559] Add category


---

diff --git a/Packaging:Java.mw b/Packaging:Java.mw
index 6b79d26..ad966c5 100644
--- a/Packaging:Java.mw
+++ b/Packaging:Java.mw
@@ -1,10 +1,5 @@
-
-= Java Packaging Guidelines =
 These guidelines are laid out in order of relevance to packaging.
 
-
-
 == Introduction ==
 
 === Background ===
@@ -395,3 +390,5 @@ Use sed to remove class-path elements in MANIFES
 sed -i '/class-path/I d' META-INF/MANIFEST.MF
 

 '''Will this preserve the line ending as the [http://java.sun.com/docs/books/tutorial/deployment/jar/downman.html this page]  says it must?'''
+
+[[Category:Packaging guidelines]]

From 9aa6ba18bab0e28ca95d7663b9da65ab2c2afe33 Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Sep 15 2009 20:10:02 +0000
Subject: [PATCH 400/3559] Add category


---

diff --git a/Packaging:Fortran.mw b/Packaging:Fortran.mw
index 527a62b..108c942 100644
--- a/Packaging:Fortran.mw
+++ b/Packaging:Fortran.mw
@@ -25,3 +25,5 @@ The module files depend on the used compiler version and the architecture. The v
 
 * If it is decided to keep using an unversioned, multilib compatible %{_fmoddir}, the ''gcc-gfortran'' package must be changed to own %{_fmoddir} and all package containing modules must Requires: gcc-gfortran.
 * If it is decided to use a GCC-versioned %{_fmoddir}, the preexisting %{_fmoddir} macro in redhat-rpm-macros must be changed from %{_libdir}/gfortran/modules to /usr/lib/gcc///finclude which is already used and owned by gfortran. After that a mass rebuild of all packages containing Fortran modules must be performed.
+
+[[Category:Packaging guidelines]]

From 5831e5e1c8eaffb810dec1623856b3a568b4b870 Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Sep 15 2009 20:18:17 +0000
Subject: [PATCH 401/3559] Fortran Guidelines


---

diff --git a/Packaging:Fortran.mw b/Packaging:Fortran.mw
index 108c942..8555237 100644
--- a/Packaging:Fortran.mw
+++ b/Packaging:Fortran.mw
@@ -16,14 +16,4 @@ As Fortran modules are architecture and GCC version specific, they MUST b
 
 To use the modules in the Fortran module directory, one needs to add -I%{_fmoddir} to the compiler flags (this is already included in FFLAGS used by %configure).
 
-== Required changes ==
-
-Packages that contain modules in the wrong place must be found and fixed (e.g. find all packages that BR: gcc-gfortran and contain '.mod' files).
-
-The module files depend on the used compiler version and the architecture. The versioning should not matter, as mass rebuilds are done anyway whenever GCC is updated to a newer version. It is important, however, if there are multiple Fortran compilers present on the system.
-
-
-* If it is decided to keep using an unversioned, multilib compatible %{_fmoddir}, the ''gcc-gfortran'' package must be changed to own %{_fmoddir} and all package containing modules must Requires: gcc-gfortran.
-* If it is decided to use a GCC-versioned %{_fmoddir}, the preexisting %{_fmoddir} macro in redhat-rpm-macros must be changed from %{_libdir}/gfortran/modules to /usr/lib/gcc///finclude which is already used and owned by gfortran. After that a mass rebuild of all packages containing Fortran modules must be performed.
-
 [[Category:Packaging guidelines]]

From b18a66bce350e6b1584def1b9961727d76390279 Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Sep 15 2009 20:19:45 +0000
Subject: [PATCH 402/3559] Fortran


---

diff --git a/Packaging:Guidelines.mw b/Packaging:Guidelines.mw
index 62c8378..8140d7d 100644
--- a/Packaging:Guidelines.mw
+++ b/Packaging:Guidelines.mw
@@ -1030,7 +1030,12 @@ Guidelines for Emacs/X-Emacs packages: [[Packaging:Emacs]]
 === Fonts ===
 Guidelines for font packages: [[Packaging:FontsPolicy]] 
 
+{{Anchor|FortranGuidelines}}
+=== Fortran ===
+Guidelines for Fortran packages: [[Packaging:Fortran]]
+
 {{Anchor|GlobusGuidelines}}
+
 === Globus Toolkit ===
 Guidelines for packaging pieces of the Globus Toolkit [[Packaging:Globus]]
 

From 3be4d90fee5f998161db6117a6b225a35ced223d Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Sep 15 2009 20:25:39 +0000
Subject: [PATCH 403/3559] Fortran merged


---

diff --git a/Packaging:GuidelinesTodo.mw b/Packaging:GuidelinesTodo.mw
index 86b5c47..d08284d 100644
--- a/Packaging:GuidelinesTodo.mw
+++ b/Packaging:GuidelinesTodo.mw
@@ -14,7 +14,7 @@ Status should be one of:
 |-
 |announce||Use the better source||mether||2009-09-09|| Draft available at https://fedoraproject.org/wiki/PackagingDrafts/Use_Better_Source 
 |-
-|writeup||Fortran||[[User:jussilehtola|Jussi Lehtola]]||2009-08-19||[[PackagingDrafts/Fortran]]
+|announce||Fortran||[[User:jussilehtola|Jussi Lehtola]]||2009-08-19||[[PackagingDrafts/Fortran]]
 |-
 |writeup||MPI packaging||[[User:jussilehtola|Jussi Lehtola]]||2009-08-12||[[PackagingDrafts/MPI]]
 |-

From 68667b949e526d8454793d6f3f6a70177f8ade67 Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Sep 15 2009 20:32:03 +0000
Subject: [PATCH 404/3559] Fortran note


---

diff --git a/Packaging:GuidelinesTodo.mw b/Packaging:GuidelinesTodo.mw
index d08284d..ae80eac 100644
--- a/Packaging:GuidelinesTodo.mw
+++ b/Packaging:GuidelinesTodo.mw
@@ -49,6 +49,11 @@ Status should be one of:
 |announce||Globus||ellert||2009-05-12||[[PackagingDrafts/Globus]] Draft packaging guidelines for packages from the Globus Toolkit.
 |}
 
+== Other TODO ==
+Emailed Jussi Lehtola about the required changes to packages listed which are still listed here: [[PackagingDrafts/Fortran]]
+
+
+
 {{:PackagingDrafts/DraftsTodo}}
 
 == Resolved items ==

From 6b7241953d079ad84bbeb7742eb972b1e3fe5726 Mon Sep 17 00:00:00 2001
From: Spot 
Date: Oct 06 2009 19:24:28 +0000
Subject: [PATCH 405/3559] /* desktop-file-install usage */


---

diff --git a/Packaging:Guidelines.mw b/Packaging:Guidelines.mw
index 8140d7d..13f6bb3 100644
--- a/Packaging:Guidelines.mw
+++ b/Packaging:Guidelines.mw
@@ -598,7 +598,7 @@ desktop-file-install                                    \
 
 
 desktop-file-install                                    \
---add-category="Multimedia"                             \
+--add-category="AudioVideo"                             \
 --delete-original                                       \
 --dir=%{buildroot}%{_datadir}/applications              \
 %{buildroot}/%{_datadir}/applnk/Multimedia/foo.desktop

From 646ee22f68b6e99095cad08603ef4b4458812679 Mon Sep 17 00:00:00 2001
From: Spot 
Date: Oct 06 2009 19:26:28 +0000
Subject: [PATCH 406/3559] /* desktop-file-install usage */


---

diff --git a/Packaging:Guidelines.mw b/Packaging:Guidelines.mw
index 13f6bb3..58f5f14 100644
--- a/Packaging:Guidelines.mw
+++ b/Packaging:Guidelines.mw
@@ -601,7 +601,7 @@ desktop-file-install                                    \
 --add-category="AudioVideo"                             \
 --delete-original                                       \
 --dir=%{buildroot}%{_datadir}/applications              \
-%{buildroot}/%{_datadir}/applnk/Multimedia/foo.desktop
+%{buildroot}/%{_datadir}/foo.desktop
 

 
 

From 58edab36574633ad01b44ec4f38975f8ec8eb29f Mon Sep 17 00:00:00 2001
From: Spot 
Date: Oct 07 2009 18:30:21 +0000
Subject: [PATCH 407/3559] *Empty MediaWiki Message*


---

diff --git a/Packaging:GuidelinesTodo.mw b/Packaging:GuidelinesTodo.mw
index ae80eac..b52471e 100644
--- a/Packaging:GuidelinesTodo.mw
+++ b/Packaging:GuidelinesTodo.mw
@@ -47,6 +47,10 @@ Status should be one of:
 |writeup||GConf scriptlets||abadger1999||2009-05-12||[[GConf Scriptlets (draft)]] Improve GConf scriplet handling.
 |-
 |announce||Globus||ellert||2009-05-12||[[PackagingDrafts/Globus]] Draft packaging guidelines for packages from the Globus Toolkit.
+|-
+|ratify||RPath Relaxation||abadger1999||2009-10-07|| [[RPath Packaging Draft]]
+|-
+|ratify||Directory ownership||notting||2009-10-07|| [[User:Notting/DirectoryDraft]]
 |}
 
 == Other TODO ==

From 00d2f3ab1e11644db1174437827896fa3235eeb3 Mon Sep 17 00:00:00 2001
From: Spot 
Date: Oct 19 2009 17:43:15 +0000
Subject: [PATCH 408/3559] *Empty MediaWiki Message*


---

diff --git a/Packaging:LicensingGuidelines.mw b/Packaging:LicensingGuidelines.mw
index 1615a7d..b9c323a 100644
--- a/Packaging:LicensingGuidelines.mw
+++ b/Packaging:LicensingGuidelines.mw
@@ -1,9 +1,9 @@
 = Licensing Guidelines =
 
 '''Author:''' [[TomCallaway|  Tom 'spot' Callaway]]  

-'''Revision:''' 0.05

+'''Revision:''' 0.06

 '''Initial Draft:''' Thursday August 2, 2007

-'''Last Revised:''' Monday March 31, 2008

+'''Last Revised:''' Monday October 19, 2008

 
 
 
@@ -33,6 +33,10 @@ The License: field must be filled with the appropriate license Shor
 === License Text ===
 If (and only if) the source package includes the text of the license(s) in its own file, then that file, containing the text of the license(s) for the package must be included in %doc. If the source package does not include the text of the license(s), the packager should contact upstream and encourage them to correct this mistake.
 
+{{Anchor|Clarification}}
+=== License Clarification ===
+In cases where the licensing is unclear, it may be necessary to contact the copyright holders to confirm the licensing of code or content. In those situations, it is _always_ preferred to ask upstream to resolve the licensing confusion by documenting the licensing and releasing an updated tarball. However, this is not always possible to achieve. In such cases, it is acceptable to receive confirmation of licensing via email. A copy of the email, containing full headers, must be included as a source file (marked as %doc) in the package. This file is considered part of the license text.
+
 {{Anchor|Distributable}}
 === "Distributable" ===
 In the past, Fedora (and Red Hat Linux) packages have used "Distributable" in the License: field. In virtually all of these cases, this was not correct. Fedora no longer permits packages to use "Distributable" as a valid License. If your package contains content which is freely redistributable without restrictions, but does not contain any license other than explicit permission from the content owner/creator, then that package can use "Freely redistributable without restriction" as its License: identifier.

From 40e70a9f00ba8862d7a4f3b676c19959c3a569db Mon Sep 17 00:00:00 2001
From: Spot 
Date: Nov 03 2009 19:30:02 +0000
Subject: [PATCH 409/3559] /* Legal */


---

diff --git a/Packaging:Guidelines.mw b/Packaging:Guidelines.mw
index 58f5f14..691b843 100644
--- a/Packaging:Guidelines.mw
+++ b/Packaging:Guidelines.mw
@@ -30,6 +30,14 @@ There are various legal concerns to consider when packaging for Fedora.
 
 You should review [[Licensing:Main]]  and the [[Packaging:LicensingGuidelines]]  to ensure that your package is licensed appropriately.
 
+
+{{Anchor|External Bits}}
+=== Packages which are not useful without external bits ===
+
+Some software is not functional or useful without the presence of external code dependencies in the runtime operating system environment. When those external code dependencies are non-free, legally unacceptable, or binary-only (with the exception of permissible firmware), then the dependent software is not acceptable for inclusion in Fedora. If the code dependencies are acceptable for Fedora, then they should be packaged and included in Fedora as a pre-requisite for inclusion of the dependent software. Software which downloads code bundles from the internet in order to be functional or useful is not acceptable for inclusion in Fedora (regardless of whether the downloaded code would be acceptable to be packaged in Fedora as a proper dependency).
+
+This also means that packages which are not functional or useful without code or packages from third-party sources are not acceptable for inclusion in Fedora. 
+
 {{Anchor|SourceRequirement}}
 
 == No inclusion of pre-built binaries or libraries ==

From cc9aaf602d21ca435b07209525cba2f6be0bc83d Mon Sep 17 00:00:00 2001
From: Spot 
Date: Nov 20 2009 19:17:56 +0000
Subject: [PATCH 410/3559] *Empty MediaWiki Message*


---

diff --git a/Packaging:R.mw b/Packaging:R.mw
index 95480be..c78313f 100644
--- a/Packaging:R.mw
+++ b/Packaging:R.mw
@@ -32,14 +32,14 @@ Name:             R-%{packname}
 Version:          1.6.6
 Release:          1%{?dist}
 Source0:          ftp://cran.r-project.org/pub/R/contrib/main/%{packname}_%{version}-%{packrel}.tar.gz
-License:          GPL
+License:          GPLv2+
 URL:              http://cran.r-project.org/src/contrib
 Group:            Applications/Engineering
 Summary:          Adds foo functionality for R
 BuildRequires:    R-devel, tex(latex)
 BuildRoot:        %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
-Requires(post):   R
-Requires(postun): R
+Requires(post):   R-core
+Requires(postun): R-core
 
 %description
 R Interface to foo, enables bar!
@@ -62,22 +62,13 @@ rm -rf $RPM_BUILD_ROOT%{_libdir}/R/library/R.css
 %clean
 rm -rf $RPM_BUILD_ROOT
 
-%post
-%{_R_make_search_index}
-
-%postun
-%{_R_make_search_index}
-
 %files
 %defattr(-, root, root, -)
 %dir %{_libdir}/R/library/%{packname}
-%doc %{_libdir}/R/library/%{packname}/latex
 %doc %{_libdir}/R/library/%{packname}/doc
 %doc %{_libdir}/R/library/%{packname}/html
-%doc %{_libdir}/R/library/%{packname}/man
 %doc %{_libdir}/R/library/%{packname}/DESCRIPTION
 %doc %{_libdir}/R/library/%{packname}/NEWS
-%{_libdir}/R/library/%{packname}/CONTENTS
 %{_libdir}/R/library/%{packname}/INDEX
 %{_libdir}/R/library/%{packname}/NAMESPACE
 %{_libdir}/R/library/%{packname}/Meta
@@ -100,16 +91,16 @@ Name:             R-%{packname}
 Version:          1.6.6
 Release:          1%{?dist}
 Source0:          ftp://cran.r-project.org/pub/R/contrib/main/%{packname}_%{version}-%{packrel}.tar.gz
-License:          GPL
+License:          GPLv2+
 URL:              http://cran.r-project.org/src/contrib
 Group:            Applications/Engineering
 Summary:          Adds foo functionality for R
 BuildRequires:    R-devel, tex(latex)
 BuildRoot:        %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
 BuildArch:        noarch
-Requires(post):   R
-Requires(postun): R
-Requires:         R
+Requires(post):   R-core
+Requires(postun): R-core
+Requires:         R-core
 
 %description
 R Interface to foo, enables bar!
@@ -132,22 +123,13 @@ rm -rf $RPM_BUILD_ROOT%{_datadir}/R/library/R.css
 %clean
 rm -rf $RPM_BUILD_ROOT
 
-%post
-%{_R_make_search_index}
-
-%postun
-%{_R_make_search_index}
-
 %files
 %defattr(-, root, root, -)
 %dir %{_datadir}/R/library/%{packname}
-%doc %{_datadir}/R/library/%{packname}/latex
 %doc %{_datadir}/R/library/%{packname}/doc
 %doc %{_datadir}/R/library/%{packname}/html
-%doc %{_datadir}/R/library/%{packname}/man
 %doc %{_datadir}/R/library/%{packname}/DESCRIPTION
 %doc %{_datadir}/R/library/%{packname}/NEWS
-%{_datadir}/R/library/%{packname}/CONTENTS
 %{_datadir}/R/library/%{packname}/INDEX
 %{_datadir}/R/library/%{packname}/NAMESPACE
 %{_datadir}/R/library/%{packname}/Meta
@@ -201,18 +183,6 @@ Instead of calling make install, to install the R addon components, you need to 
 === Deleting the R.css file ===
 Most R addon modules generate a new R.css file, but it would conflict with the master R.css file, included in the main R package. You must delete this file, and do not include it in your package.
 
-=== Generating the search index.txt ===
-R keeps a master index.txt, as a search index of which R libraries are installed on the system. This provides the source for the R html help interface that is accessible through the ''help.start()'' command. This index is always located at /usr/share/doc/R-%{version}/html/search/index.txt. All R packages need to update the search index.txt in %post and %postun. The R package provides a macro to make this simple: %{_R_make_search_index}. Simply put this macro in %post and %postun in your R package, and it will update the search index.txt to include arch-specific and noarch R libraries upon install and uninstall. This is demonstrated in the spec templates.
-
-NOTE: R packages will throw the following warning from rpmlint:
-
-W: R-widgetTools one-line-command-in-%post
-/usr/lib/rpm/R-make-search-index.sh
-

-
-Normally, this would be resolved by running %post -p foo, but this will not work with our script.
-Just ignore this warning.
-
 === Cleaning the R directory of binaries ===
 It is important to clean the R directory of binary files (*.o *.so) before running R CMD CHECK. Otherwise, the CHECK command will throw a warning about finding binaries in the source dir. This is accomplished by running (in %install):
 
@@ -233,8 +203,8 @@ Most (if not all) R addon modules come with a built-in check. This can be trigge
 Note that frequently, R packages have circular dependency loops when running R CMD check. If you hit such a case, you can comment out the check to break the dependency loop, and leave a comment explaining the circular dependency problem.
 
 === Documentation files ===
-The R CMD INSTALL operation will install all of the files, including documentation files. The latex, doc, html, man, NEWS, and DESCRIPTION files/directories need to be marked as %doc.
-Note that other files, such as CONTENTS, INDEX, NAMESPACE, and help/ are not %doc, since proper R functionality depends on their presence. Be careful not to duplicate %doc files in the package, the spec templates provide good examples on how to package the R addon files without duplications.
+The R CMD INSTALL operation will install all of the files, including documentation files. The doc, html, NEWS, and DESCRIPTION files/directories need to be marked as %doc.
+Note that other files, such as INDEX, NAMESPACE, and help/ are not %doc, since proper R functionality depends on their presence. Be careful not to duplicate %doc files in the package, the spec templates provide good examples on how to package the R addon files without duplications.
 
 ==== R documentation ====
 R documentation is written in Tex. rpmlint sometimes complains that these Tex files are not utf-8 files, but the encoding is normally specified in the file when needed, so this error is safe to ignore (and you should not try to re-encode the files).

From 08e1de0e8c46ed910082339185770212060a3ebc Mon Sep 17 00:00:00 2001
From: Spot 
Date: Dec 02 2009 19:59:06 +0000
Subject: [PATCH 411/3559] *Empty MediaWiki Message*


---

diff --git a/Packaging:GuidelinesTodo.mw b/Packaging:GuidelinesTodo.mw
index b52471e..e0f530b 100644
--- a/Packaging:GuidelinesTodo.mw
+++ b/Packaging:GuidelinesTodo.mw
@@ -48,9 +48,15 @@ Status should be one of:
 |-
 |announce||Globus||ellert||2009-05-12||[[PackagingDrafts/Globus]] Draft packaging guidelines for packages from the Globus Toolkit.
 |-
-|ratify||RPath Relaxation||abadger1999||2009-10-07|| [[RPath Packaging Draft]]
+|writeup||RPath Relaxation||abadger1999||2009-10-07|| [[RPath Packaging Draft]]
 |-
-|ratify||Directory ownership||notting||2009-10-07|| [[User:Notting/DirectoryDraft]]
+|writeup||Directory ownership||notting||2009-10-07|| [[User:Notting/DirectoryDraft]]
+|- 
+|ratify||RPM handling of pkgconfig requires|| ajax, abadger1999 || 2009-12-02 || [[PackagingDrafts/PkgconfigAutoRequires|pkgconfig autorequires]] 
+|-
+|ratify||Revised Emacs add-on guidelines||[[User:jgu|jgu]]|| 2009-12-02 ||[[PackagingDrafts/EmacsPackagingRevised]]
+|-
+|ratify||PHP guidelines||[[User:Remi|Remi]]|| 2009-12-02 ||[[PackagingDrafts/PHP]]
 |}
 
 == Other TODO ==
@@ -290,6 +296,8 @@ Emailed Jussi Lehtola about the required changes to packages listed which are st
 |- style="color: white; background-color: #3074c2; font-weight: bold" 
 |Task Name||Owner||Resolution Date||Notes
 |-
+|man-pages guidelines||[[User:Varekova|varekova]]||2009-12-02||[[User:Varekova/man-pages/missing-man-pages]] This was similar to the Guidelines for Man pages, rejected on 2009-05-12. This draft conflicts with the general practice that Fedora packagers should be working to send improvements directly to upstream. Anyone who feels motivated to dig in other distributions for patches or improvements should feel free to do so, but it is not something that the FPC felt should be codified into the guidelines. However, it was added that if FESCo decided to take a stance around man page requirements in packages, the FPC would be willing to revisit the guideline aspect in the future.
+|-
 |Games||mether||2009-09-09|| https://fedoraproject.org/w/index.php?title=SIGs/Games/Packaging is not a set of guidelines, just strong recommendations from the Games SIG. As is, it is not appropriate as Guidelines. If the Games SIG wishes to make them required guidelines, they can resubmit them for inclusion.
 |-
 |Prohibit /usr/bin/env in shebang||abadger1999||2009-08-19||[[Script_Interpreters_(draft)]] This was rejected as a MUST, a SHOULD might be acceptable however.

From 90c9b6d560cc3b8684ca029dade75fd131703461 Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Jan 08 2010 19:51:36 +0000
Subject: [PATCH 412/3559] Note rpm bug fixed in F13


---

diff --git a/Packaging:Guidelines.mw b/Packaging:Guidelines.mw
index 691b843..8e80e53 100644
--- a/Packaging:Guidelines.mw
+++ b/Packaging:Guidelines.mw
@@ -665,9 +665,10 @@ Rationale: The two macro defining statements behave the same when they are a the
 
 But when they are used in nested macro expansions (like in  %{!?foo: ... }  constructs, %define theoretically only lasts until the end brace (local scope), while %global definitions have global scope.
 
-The reason this hasn't bitten us as often is that due to a minor bug in rpm the invalidated local macro definition is not garbage collected unless other events force rpm to. So the bug is seldomly triggered, but when it is, it is difficult to diagnose the issue. Using %global by default helps to avoid creation of new latent bugs.
+{{admon/note||In Fedora 12 and earlier, a minor bug in rpm caused the local macro definition to not be garbage collected unless other events forced rpm to. So the bug is seldom triggered but when it is it is difficult to diagnose the issue. Using %global by default helps to avoid creation of new latent bugs. [[https://www.redhat.com/archives/fedora-devel-list/2010-January/msg00093.html| Bugfix description]]}}
 
 {{Anchor|locales}}
+
 == Handling Locale Files ==
 
 If the package includes translations, add

From 2b6c3b9c646d9a1564b2a35b1c7eb5e55cae7e3b Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Jan 12 2010 15:24:41 +0000
Subject: [PATCH 413/3559] Updated pkgconfig guidelines


---

diff --git a/Packaging:Guidelines.mw b/Packaging:Guidelines.mw
index 8e80e53..311a252 100644
--- a/Packaging:Guidelines.mw
+++ b/Packaging:Guidelines.mw
@@ -444,9 +444,12 @@ A good rule of thumb is if the file is used for development and not needed for t
 {{Anchor|PkgconfigFiles}}
 === Pkgconfig Files ===
 The placement of pkgconfig(.pc) files depends on their usecase. Since they are almost always used for development purposes, they should be placed in a -devel package.
-A reasonable exception is when the main package itself is a development tool not installed in a user runtime, e.g. gcc or gdb. Packages containing pkgconfig(.pc) files must Requires: pkgconfig (for directory ownership and usability). 
+A reasonable exception is when the main package itself is a development tool not installed in a user runtime, e.g. gcc or gdb.
+
+{{admon/note|EPEL difference|rpm in Fedora automatically detects dependencies on pkgconfig and between pkgconfig files.  rpm in EPEL5 and below do not have this ability and should follow the [[EPEL/GuidelinesAndPolicies#Distribution_specific_guidelines|EPEL Guidelines]].}}
 
 {{Anchor|RequiringBasePackage}}
+
 == Requiring Base Package ==
 Devel packages must require the base package using a fully versioned dependency: Requires: %{name} = %{version}-%{release}.
 Usually, subpackages other than -devel should also require the base package using a fully versioned dependency.

From 7fe209ec778ea7312f98b59b5338fb6a39986f70 Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Jan 12 2010 15:27:59 +0000
Subject: [PATCH 414/3559] pkgconfig writtenup


---

diff --git a/Packaging:GuidelinesTodo.mw b/Packaging:GuidelinesTodo.mw
index e0f530b..f95cf33 100644
--- a/Packaging:GuidelinesTodo.mw
+++ b/Packaging:GuidelinesTodo.mw
@@ -16,10 +16,6 @@ Status should be one of:
 |-
 |announce||Fortran||[[User:jussilehtola|Jussi Lehtola]]||2009-08-19||[[PackagingDrafts/Fortran]]
 |-
-|writeup||MPI packaging||[[User:jussilehtola|Jussi Lehtola]]||2009-08-12||[[PackagingDrafts/MPI]]
-|-
-|writeup||Environment modules||[[User:jussilehtola|Jussi Lehtola]]||2009-08-12||[[PackagingDrafts/EnvironmentModules]]
-|-
 |announce||Correct ant sample spec||[[User:jussilehtola|Jussi Lehtola]]||2009-08-12||[[PackagingDrafts/JavaAntSampleSpec]]
 |-
 |announce||Update R guidelines||[[User:pingou|pingou]]||2009-08-12|| [[ProposalUpdateRGuidelines]]
@@ -30,8 +26,6 @@ Status should be one of:
 |-
 |announce||dos2unix||atorkhov|| 2009-07-28||[[PackagingDrafts/Dos2unix]]
 |-
-|writeup||Filtering auto-provides||cweyl||2009-07-28||[[PackagingDrafts/AutoProvidesAndRequiresFiltering]]
-|-
 |announce||Explanation of no bundled libraries||abadger1999||2009-07-28||[[No_Bundled_Libraries]]
 |-
 |announce||pre-built binaries||oget||2009-07-28||[[PackagingDrafts/Removal_of_pre-built_binaries]]
@@ -40,23 +34,29 @@ Status should be one of:
 |-
 |announce||Common Package Names||abadger1999||2009-04-14||[[Common package names packaging guideline draft]]
 |-
-|writeup||Using Alternatives||[[User:Rathann|rathann]]||2009-04-14||[[PackagingDrafts/UsingAlternatives]]
-|-
 |announce||WordPress plugins||[[User:Ianweller|Ian Weller]]||2009-04-14||[[User:Ianweller/WordPress plugin packaging guidelines (draft)]]
 |-
-|writeup||GConf scriptlets||abadger1999||2009-05-12||[[GConf Scriptlets (draft)]] Improve GConf scriplet handling.
-|-
 |announce||Globus||ellert||2009-05-12||[[PackagingDrafts/Globus]] Draft packaging guidelines for packages from the Globus Toolkit.
 |-
+|announce||RPM handling of pkgconfig requires|| ajax, abadger1999 || 2009-12-02 || [[PackagingDrafts/PkgconfigAutoRequires|pkgconfig autorequires]] 
+|-
+|writeup||MPI packaging||[[User:jussilehtola|Jussi Lehtola]]||2009-08-12||[[PackagingDrafts/MPI]]
+|-
+|writeup||Environment modules||[[User:jussilehtola|Jussi Lehtola]]||2009-08-12||[[PackagingDrafts/EnvironmentModules]]
+|-
+|writeup||Filtering auto-provides||cweyl||2009-07-28||[[PackagingDrafts/AutoProvidesAndRequiresFiltering]]
+|-
+|writeup||Using Alternatives||[[User:Rathann|rathann]]||2009-04-14||[[PackagingDrafts/UsingAlternatives]]
+|-
+|writeup||GConf scriptlets||abadger1999||2009-05-12||[[GConf Scriptlets (draft)]] Improve GConf scriplet handling.
+|-
 |writeup||RPath Relaxation||abadger1999||2009-10-07|| [[RPath Packaging Draft]]
 |-
 |writeup||Directory ownership||notting||2009-10-07|| [[User:Notting/DirectoryDraft]]
 |- 
-|ratify||RPM handling of pkgconfig requires|| ajax, abadger1999 || 2009-12-02 || [[PackagingDrafts/PkgconfigAutoRequires|pkgconfig autorequires]] 
-|-
-|ratify||Revised Emacs add-on guidelines||[[User:jgu|jgu]]|| 2009-12-02 ||[[PackagingDrafts/EmacsPackagingRevised]]
+|writeup||Revised Emacs add-on guidelines||[[User:jgu|jgu]]|| 2009-12-02 ||[[PackagingDrafts/EmacsPackagingRevised]]
 |-
-|ratify||PHP guidelines||[[User:Remi|Remi]]|| 2009-12-02 ||[[PackagingDrafts/PHP]]
+|writeup||PHP guidelines||[[User:Remi|Remi]]|| 2009-12-02 ||[[PackagingDrafts/PHP]]
 |}
 
 == Other TODO ==

From 21a7c0f1e287770cfff8f20042bc7db6bdaabb1e Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Jan 20 2010 16:56:19 +0000
Subject: [PATCH 415/3559] Add man pages


---

diff --git a/Packaging:ReviewGuidelines.mw b/Packaging:ReviewGuidelines.mw
index c030ff5..14d2945 100644
--- a/Packaging:ReviewGuidelines.mw
+++ b/Packaging:ReviewGuidelines.mw
@@ -69,7 +69,8 @@ There are many many things to check for a review. This list is provided to assis
 * '''SHOULD''': If scriptlets are used, those scriptlets must be sane. This is vague, and left up to the reviewers judgement to determine sanity. [[Packaging/Guidelines#Scriptlets|Packaging Guidelines: Scriptlets]]

 * '''SHOULD''': Usually, subpackages other than devel should require the base package using a fully versioned dependency. [[Packaging/Guidelines#RequiringBasePackage|Packaging Guidelines: Requiring Base Package]]

 * '''SHOULD''': The placement of pkgconfig(.pc) files depends on their usecase, and this is usually for development purposes, so should be placed in a -devel pkg.  A reasonable exception is that the main pkg itself is a devel tool not installed in a user runtime, e.g. gcc or gdb. [[Packaging/Guidelines#PkgconfigFiles|Packaging Guidelines: Pkgconfig Files]]

-* '''SHOULD''': If the package has file dependencies outside of /etc, /bin, /sbin, /usr/bin, or /usr/sbin consider requiring the package which provides the file instead of the file itself. [[Packaging/Guidelines#FileDeps|Packaging Guidelines: File Dependencies]]
+* '''SHOULD''': If the package has file dependencies outside of /etc, /bin, /sbin, /usr/bin, or /usr/sbin consider requiring the package which provides the file instead of the file itself. [[Packaging/Guidelines#FileDeps|Packaging Guidelines: File Dependencies]]

+* '''SHOULD''': your package should contain man pages for binaries/scripts. If it doesn't, work with upstream to add them where they make sense.[[Packaging/Guidelines#Man_pages|Packaging Guidelines: Man Pages]]

 
 == References to the Fedora Packaging Guidelines ==
 

From a025fa03d312b24728391060b7fcf45010ed9246 Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Jan 20 2010 16:56:58 +0000
Subject: [PATCH 416/3559] Add man page guidelines


---

diff --git a/Packaging:Guidelines.mw b/Packaging:Guidelines.mw
index 311a252..1a1351a 100644
--- a/Packaging:Guidelines.mw
+++ b/Packaging:Guidelines.mw
@@ -1025,7 +1025,11 @@ Pros:
 Cons:
 * Absolute symlinks may break when used with chroots.
 
+== Man pages ==
+Man pages are the traditional method of getting help on a unix system.  Packages should contain man pages for all binaries/scripts.  If it doesn't, work with upstream to add them.  Sometimes, other distributions (notably Debian), have man pages for programs.  You can use those as a starting point.
+
 {{Anchor|ApplicationSpecificGuidelines}}
+
 == Application Specific Guidelines ==
 
 Some applications have specific guidelines written for them, located on their own pages in the Packaging: Namespace.

From 16ff1a14a5cf826ba4c7f250ea55a3812ee2b06c Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Jan 20 2010 17:01:39 +0000
Subject: [PATCH 417/3559] Add man pages guideline


---

diff --git a/Packaging:GuidelinesTodo.mw b/Packaging:GuidelinesTodo.mw
index f95cf33..b2790b6 100644
--- a/Packaging:GuidelinesTodo.mw
+++ b/Packaging:GuidelinesTodo.mw
@@ -40,6 +40,8 @@ Status should be one of:
 |-
 |announce||RPM handling of pkgconfig requires|| ajax, abadger1999 || 2009-12-02 || [[PackagingDrafts/PkgconfigAutoRequires|pkgconfig autorequires]] 
 |-
+|announce||Man pages|| FESCo, varekova|| ||[https://fedorahosted.org/fesco/ticket/291|FESCo ticket] [[Packaging:Guidelines#Man_pages Guideline]]
+|-
 |writeup||MPI packaging||[[User:jussilehtola|Jussi Lehtola]]||2009-08-12||[[PackagingDrafts/MPI]]
 |-
 |writeup||Environment modules||[[User:jussilehtola|Jussi Lehtola]]||2009-08-12||[[PackagingDrafts/EnvironmentModules]]

From 20eeb7f7413e578d52faf24614b4642b39097b26 Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Jan 20 2010 17:15:59 +0000
Subject: [PATCH 418/3559] Link to FESCo Policy


---

diff --git a/Packaging:Naming.mw b/Packaging:Naming.mw
index 1cafe78..c890980 100644
--- a/Packaging:Naming.mw
+++ b/Packaging:Naming.mw
@@ -273,6 +273,7 @@ The exception to this is for perl module packaging. The CPAN Group and Type shou
 
 == Renaming/replacing existing packages ==
 
+{{admon/note|FESCo Policy|FESCo has a [[Package_Renaming_Process#Re-review_required package renaming policy]] that should be followed when renaming an existing package.}}
 In the event that it becomes necessary to rename or replace an existing package, the new package should make the change transparent to end users to the extent applicable.
 
 If a package is being renamed without any functional changes, or is a compatible enough replacement to an existing package (where "enough" means that it includes only changes of magnitude that are commonly found in version upgrade changes), provide clean upgrade paths and compatibility with:
@@ -302,6 +303,7 @@ If there is no standard naming for a package or other long term naming compatibi
 For packages that are not usually pulled in by using the package name as the dependency such as library only packages (which are pulled in through library soname depenencies), there's usually no need to add the Provides.  Note however that the -devel subpackages of lib packages are pulled in as build dependencies using the package name, so adding the Provides is often appropriate there.
 
 {{Anchor|DocumentationSubPackages}}
+
 == Documentation SubPackages ==
 Large documentation files should go in a subpackage. This subpackage must be named with the format: %{name}-doc .
 The definition of large is left up to the packager's best judgement, but is not restricted to size. Large can refer to either size or quantity.

From 3bc8eaaa19aad3544ecca21e225de1bb3a041896 Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Jan 20 2010 17:16:38 +0000
Subject: [PATCH 419/3559] Fix link format


---

diff --git a/Packaging:Naming.mw b/Packaging:Naming.mw
index c890980..256f2b5 100644
--- a/Packaging:Naming.mw
+++ b/Packaging:Naming.mw
@@ -273,7 +273,7 @@ The exception to this is for perl module packaging. The CPAN Group and Type shou
 
 == Renaming/replacing existing packages ==
 
-{{admon/note|FESCo Policy|FESCo has a [[Package_Renaming_Process#Re-review_required package renaming policy]] that should be followed when renaming an existing package.}}
+{{admon/note|FESCo Policy|FESCo has a [[Package_Renaming_Process#Re-review_required| package renaming policy]] that should be followed when renaming an existing package.}}
 In the event that it becomes necessary to rename or replace an existing package, the new package should make the change transparent to end users to the extent applicable.
 
 If a package is being renamed without any functional changes, or is a compatible enough replacement to an existing package (where "enough" means that it includes only changes of magnitude that are commonly found in version upgrade changes), provide clean upgrade paths and compatibility with:

From 9dc4a606deba660cff6887f9432143c9a122b4ba Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Jan 31 2010 18:39:24 +0000
Subject: [PATCH 420/3559] Fix ml link


---

diff --git a/Packaging:Guidelines.mw b/Packaging:Guidelines.mw
index 1a1351a..1ca98ca 100644
--- a/Packaging:Guidelines.mw
+++ b/Packaging:Guidelines.mw
@@ -668,7 +668,7 @@ Rationale: The two macro defining statements behave the same when they are a the
 
 But when they are used in nested macro expansions (like in  %{!?foo: ... }  constructs, %define theoretically only lasts until the end brace (local scope), while %global definitions have global scope.
 
-{{admon/note||In Fedora 12 and earlier, a minor bug in rpm caused the local macro definition to not be garbage collected unless other events forced rpm to. So the bug is seldom triggered but when it is it is difficult to diagnose the issue. Using %global by default helps to avoid creation of new latent bugs. [[https://www.redhat.com/archives/fedora-devel-list/2010-January/msg00093.html| Bugfix description]]}}
+{{admon/note||In Fedora 12 and earlier, a minor bug in rpm caused the local macro definition to not be garbage collected unless other events forced rpm to. So the bug is seldom triggered but when it is it is difficult to diagnose the issue. Using %global by default helps to avoid creation of new latent bugs. [https://www.redhat.com/archives/fedora-devel-list/2010-January/msg00093.html Bugfix description]}}
 
 {{Anchor|locales}}
 

From e3096f30b2025ce69e65589c23c16b42241a06c9 Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Feb 01 2010 16:39:02 +0000
Subject: [PATCH 421/3559] Formatting fixes


---

diff --git a/Packaging:Python_Eggs.mw b/Packaging:Python_Eggs.mw
index bb93abf..90162e2 100644
--- a/Packaging:Python_Eggs.mw
+++ b/Packaging:Python_Eggs.mw
@@ -6,9 +6,11 @@ Python packages have started to use setuptools in their package build scripts.  
 
 == Why Eggs ==
 Eggs have several uses including:
-1. Allowing end users to install eggs not made from rpms or install eggs into their home directories.  This is an important feature for people working within a shared hosting environment.
-1. Giving python packages an easy way to support plugins.
-1. Giving us a way to support multiple versions of a python module for compat libraries.
+
    
+
  1. Allowing end users to install eggs not made from rpms or install eggs into their home directories.  This is an important feature for people working within a shared hosting environment.
+
  2. Giving python packages an easy way to support plugins.
+
  3. Giving us a way to support multiple versions of a python module for compat libraries.
+

 
 == What are Eggs ==
 Eggs can be placed on disk in several formats:
@@ -24,7 +26,7 @@ In Fedora Packages, these will be installed to %{python_sitelib} or %{python_sit
 Since eggs establish a base of functionality that upstream authors can expect, we need to be sure to include the egg files if a package builds them.  Starting with Fedora 9 any package that uses setuptools or distutils will build egg-info.  In Fedora 8 or less, only setuptools packages build egg-info.  If you need to provide egg-info for a distutils package on Fedora 8 or less, [[#Providing_Eggs_for_non-setuptools_packages|  Providing Eggs using Setuptools]]  describes a method of substituting setuptools for distutils in the build process so egg-info is created.
 
 
-{{admon/note| In the past, when there was a requirement for an egg which was not provided by upstream we would patch the requiring package to not require that package.  This behaviour is deprecated and as packages are updated maintainers should follow the below guidelines to install eggs for the required packages.  Please see [[#Providing_Eggs_for_non-setuptools_packages|  Creating Eggs for Non-setuptools Packages]] 
+{{admon/note|| In the past, when there was a requirement for an egg which was not provided by upstream we would patch the requiring package to not require that package.  This behaviour is deprecated and as packages are updated maintainers should follow the below guidelines to install eggs for the required packages.  Please see [[#Providing_Eggs_for_non-setuptools_packages|  Creating Eggs for Non-setuptools Packages]] 
 }}
 
 == Upstream Eggs ==
@@ -56,14 +58,14 @@ BuildRequires: python-setuptools-devel
 %{python_sitelib}/*
 

 
-{{admon/note|Note: older versions of setuptools used the --single-version-externally-managed commandline argument to create egg info and an expanded directory directly in site-packages. This is no longer necessary as --root creates things the way we want for packaging.
+{{admon/note||Older versions of setuptools used the --single-version-externally-managed commandline argument to create egg info and an expanded directory directly in site-packages. This is no longer necessary as --root creates things the way we want for packaging.
 }}
 
 {{Anchor|NonSetuptoolsEggs}}
 
 == Providing Eggs for non-setuptools packages ==
 
-{{admon/note|These instructions are only for distutils in RHEL4 & 5.  Fedora 9 and above will automatically generate egg-info files.}}
+{{admon/note||These instructions are only for distutils in RHEL4 & 5.  Fedora 9 and above will automatically generate egg-info files.}}
 
 When we need to provide eggs in a non-setuptools package because another package requires that functionality we can modify our spec files to generate the egg-info:
 

From 5541fc1c2991f9bc748ecd513792ab1d9585e780 Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Feb 02 2010 16:05:41 +0000
Subject: [PATCH 422/3559] /* No inclusion of pre-built binaries or libraries */  -- Add egg files


---

diff --git a/Packaging:Guidelines.mw b/Packaging:Guidelines.mw
index 1ca98ca..6cf2999 100644
--- a/Packaging:Guidelines.mw
+++ b/Packaging:Guidelines.mw
@@ -57,7 +57,7 @@ Packages which require non-open source components to build are also not permitte
 
 When you encounter prebuilt binaries in a package you '''MUST''':
 
-* Remove all pre-built program binaries and program libraries in %prep prior to the building of the package. Examples include, but are not limited to, *.class, *.dll, *.DS_Store, *.exe, *.jar, *.o, *.pyc, *.pyo, *.so files.
+* Remove all pre-built program binaries and program libraries in %prep prior to the building of the package. Examples include, but are not limited to, *.class, *.dll, *.DS_Store, *.exe, *.jar, *.o, *.pyc, *.pyo, *.egg, *.so files.
 * Ask upstream to remove the binaries in their next release.
 
 {{Anchor|SourceRequirementExceptions}}

From 42354a3bb92735d49be1578cca91459ac3793e14 Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Feb 03 2010 19:05:45 +0000
Subject: [PATCH 423/3559] Two issues passed FPC today


---

diff --git a/Packaging:GuidelinesTodo.mw b/Packaging:GuidelinesTodo.mw
index b2790b6..232bc24 100644
--- a/Packaging:GuidelinesTodo.mw
+++ b/Packaging:GuidelinesTodo.mw
@@ -59,6 +59,10 @@ Status should be one of:
 |writeup||Revised Emacs add-on guidelines||[[User:jgu|jgu]]|| 2009-12-02 ||[[PackagingDrafts/EmacsPackagingRevised]]
 |-
 |writeup||PHP guidelines||[[User:Remi|Remi]]|| 2009-12-02 ||[[PackagingDrafts/PHP]]
+|-
+|ratify||SRPM Buildtime macros||abadger1999||2010-02-03||[[SRPM_Buildtime_macros]]
+|-
+|ratify||Emphasize correct SF.net SourceURL||[[User:till]]||2010-02-03||[[PackagingDrafts/SourceURL_sourceforge_downloads_admonition]]
 |}
 
 == Other TODO ==

From f72b3ecd2902359ae8c56dbbf17f7f53eab4a5b2 Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Feb 03 2010 22:02:56 +0000
Subject: [PATCH 424/3559] Python Guidelines also done


---

diff --git a/Packaging:GuidelinesTodo.mw b/Packaging:GuidelinesTodo.mw
index 232bc24..4497c5b 100644
--- a/Packaging:GuidelinesTodo.mw
+++ b/Packaging:GuidelinesTodo.mw
@@ -63,6 +63,8 @@ Status should be one of:
 |ratify||SRPM Buildtime macros||abadger1999||2010-02-03||[[SRPM_Buildtime_macros]]
 |-
 |ratify||Emphasize correct SF.net SourceURL||[[User:till]]||2010-02-03||[[PackagingDrafts/SourceURL_sourceforge_downloads_admonition]]
+|-
+|ratify||Python guideline update||abadger1999||2010-02-03 (vote taken on mailing list)|| https://fedoraproject.org/wiki/PackagingDrafts/Python3
 |}
 
 == Other TODO ==

From b88396c06876fd7bd2e60f2d37189801aabb95d1 Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Feb 11 2010 17:35:42 +0000
Subject: [PATCH 425/3559] moved [[Packaging:Python]] to [[Archive:Packaging:Python]]: Replaced with new Guideline.  Chose to keep the new page's history instead of this one.


---

diff --git a/Packaging:Python.mw b/Packaging:Python.mw
new file mode 100644
index 0000000..f91703f
--- /dev/null
+++ b/Packaging:Python.mw
@@ -0,0 +1 @@
+#REDIRECT [[Archive:Packaging:Python]]

From 4ae8cf11e2c8a61b157a2cf17acd9cbd03627500 Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Feb 11 2010 17:37:01 +0000
Subject: [PATCH 426/3559] Remove redirect


---

diff --git a/Packaging:Python.mw b/Packaging:Python.mw
index f91703f..8b13789 100644
--- a/Packaging:Python.mw
+++ b/Packaging:Python.mw
@@ -1 +1 @@
-#REDIRECT [[Archive:Packaging:Python]]
+

From bc51b3130cbc3481440eaf369a27a4c21029da9c Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Feb 11 2010 17:57:50 +0000
Subject: [PATCH 427/3559] Import new python guidelines


---

diff --git a/Packaging:Python.mw b/Packaging:Python.mw
index 8b13789..09d5a87 100644
--- a/Packaging:Python.mw
+++ b/Packaging:Python.mw
@@ -1 +1,484 @@
+== Multiple Python Runtimes ==
 
+In Fedora we have multiple python runtimes, one for each supported major release.  At this point that's one for python2.x and one for python3.x
+
+Each runtime corresponds to a binary of the form /usr/bin/python$MAJOR.$MINOR
+
+One of these python runtimes is the "system runtime".  It can be identified by the destination of the symlink /usr/bin/python.  Currently this is /usr/bin/python-2.6
+
+{{admon/note||Currently /usr/bin/python is actually a duplicate copy of the ELF file, rather than a symlink.  This shouldn't cause any problems for packagers of python modules but we see this as [[https://bugzilla.redhat.com/show_bug.cgi?id=556970 a bug]] that needs fixing.}}
+
+All python runtimes have a virtual provide for python(abi) = $MAJOR-$MINOR.  For example, the python-3.1 runtime rpm has:
+  $ rpm -q --provides python3 |grep -i abi
+  python(abi) = 3.1
+
+python modules using these runtimes should have a corresponding "Requires" line on the python runtime that they are used with.  This is done automatically for files below /usr/lib[^/]*/python${PYVER}
+
+{{admon/warning|Test your work| Remember to test the built RPMs and verify that they actually work!  For instance, when you're packaging a python module that builds for both python2 and python3, don't test the python2 module but ship the python3 module without testing that it does what it's supposed to.  If you are requesting that an application '''switch''' from Python 2 to Python 3 for its Python implementation, please provide supporting material (e.g. a list of tests performed, and their outcome).  Simply getting a package to build against Python 3 is no guarantee that the package's functionality still works.}}
+
+{{admon/note|For packagers of the python interpreter|Unlike the Requires lines, the "Provides" for each runtime are manually entered into the specfile for each runtime.  In theory /usr/lib/rpm/pythondeps.sh would also automatically generate "Provides" lines for the runtime, but in practice rpmbuild only invokes it for files in the rpm payload identified as "python" by the file utility, and the runtime is an ELF binary, not a python script, hence it isn't passed.  It's simplest to manually supply the Provides line, rather than change these innards of rpmbuild.  See [[https://bugzilla.redhat.com/show_bug.cgi?id=532118 bug 532118]].}}
+
+== BuildRequires ==
+To build a package containing python2 files, you need to have
+
+BuildRequires: python2-devel
+

+
+Similarly, when building a package which ships python3 files, you need
+
+BuildRequires: python3-devel
+

+
+A package that has both python2 and python3 files will need to BuildRequire both.
+
+== Macros ==
+In Fedora less than 12 and RHEL less than 5, python2 packages that install python modules need to define python_sitelib or python_sitearch macros that tell where to find the python directory that modules are installed in.  This is not needed in Fedora 13 or with python3 modules as the macros are defined by rpm and the python3-devel package.  To define those conditionally you can use this:
+
+
+%if ! (0%{?fedora} > 12 || 0%{?rhel} > 5)
+%{!?python_sitelib: %global python_sitelib %(%{__python} -c "from distutils.sysconfig import get_python_lib; print(get_python_lib())")}
+%{!?python_sitearch: %global python_sitearch %(%{__python} -c "from distutils.sysconfig import get_python_lib; print(get_python_lib(1))")}
+%endif
+

+
+Note that the use of %{!? [...]} does allow this to work without the check for fedora and rhel versions but putting the conditional in documents when we can remove the entire stanza from the spec file.
+
+In Fedora 13 and greater, the following macros are defined for you:
+{|
+!Macro!!Normal Definition!!Notes
+|-
+|__python||/usr/bin/python||Python 2 interpreter.  Also the default python interpreter
+|-
+|__python3||/usr/bin/python3||Python 3 interpreter
+|-
+|python_sitelib||/usr/lib/python2.X/site-packages||Where pure python2 modules are installed
+|-
+|python_sitearch||/usr/lib64/python2.X/site-packages on x86_64
/usr/lib/python2.X/site-packages on x86||Where python2 extension modules that are compiled C are installed
+|-
+|python3_sitelib||/usr/lib/python3.X/site-packages||Where pure python3 modules are installed
+|-
+|python3_sitearch||/usr/lib64/python3.X/site-packages on x86_64
/usr/lib/python3.X/site-packages on x86||Where python3 extension modules that are compiled C are installed
+|-
+|py3dir||%{_builddir}/python3-%{name}-%{version}-%{release}||Directory to use when building python3 modules from the same source tarball as python2 modules
+|-
+|py_byte_compile|| (script) ||Defined in python3-devel.  See the [#Bytecompiling_with_the_correct_python_version bytecompiling] section for usage
+|}
+
+During %install or when listing %files you can use the python_sitearch and python_sitelib macros to specify where the installed modules are to be found.  For instance:
+
+
+
+
+%files
+%defattr(-,root,root,-)
+# A pure python2 module
+%{python_sitelib}/foomodule/
+# A compiled python2 extension module
+%{python_sitearch}/barmodule/
+# A compiled python3 extension module
+%{python3_sitearch}/bazmodule/
+

+
+Using the macros has several benefits.
+
    
+
  1. It ensures that the packages are installed correctly on multilib architectures.
    2. 
+
  2. Using these macros instead of hardcoding the directory in the specfile ensures your spec remains compatible with the installed python version even if the directory structure changes radically (for instance, if python_sitelib moves into %{_datadir})
    3. 
+

+
+== Byte compiling ==
+
+Python will automatically try to byte compile files when it runs in order to speed up startup the next time it is run.  These files are saved in files with the extension of .pyc (compiled python) or .pyo (optimized compiled python).  These files are a byte code that is portable across OSes.  If you do not include them in your packages, python will try to create them when the user runs the program.  If the system administrator uses them, then the files will be successfully written.  Later, when the package is removed, the .pyc and .pyo files will be left behind on the filesystem.  To prevent that the byte compiled files need to be compiled and included in the %files section.  Normally, byte compilation is done for you by the brp-python-bytecompile script. This script runs after the %install section of the spec file has been processed and byte compiles any .py files that it finds (this recompilation puts the proper filesystem paths into the modules otherwise tracebacks would include the %{buildroot} in them).  All that you need to do is include the files in the %files section.  The following are all acceptable ways to accomplish this:
+
+
+%install
+install -d $RPM_BUILD_ROOT%{python_sitelib}/foo
+install -pm 0644 foo.py $RPM_BUILD_ROOT%{python_sitelib}/foo/
+
+Either:
+
+%files
+%{python_sitelib}/foo/
+
+Or:
+
+%files
+%dir %{python_sitelib}/foo
+%{python_sitelib}/foo/*
+
+Or even:
+
+%files
+%dir %{python_sitelib}/foo
+%{python_sitelib}/foo/foo.py
+%{python_sitelib}/foo/foo.pyc
+%{python_sitelib}/foo/foo.pyo
+

+
+{{admon/warning|Avoid INSTALLED_FILES|python's distutils has an INSTALLED_FILES feature that lists which files are installed when you run python setup.py install.  Do not use it for packaging as that will not list the directories which need to be specified in the %files section as well. Using globs in the %files section is simpler and safer.}}
+
+{{admon/warning|Including egg info|When you run %{__python} setup.py install in any current Fedora, distutils generates a .egg-info file with metadata about the python module that is installed.  These files need to be included as well. (See [#Packaging_eggs_and_setuptools_concerns])}}
+
+=== Bytecompiling with the correct python version ===
+
+When byte compiling a .py file, python embeds a magic number in the byte compiled files that correspond to the runtime.  Files in {%python_sitelib} and %{python_sitearch} must correspond to the runtime for which they were built.  For instance, a pure python module compiled for the 3.1 runtime needs to be below %{_usr}/lib/python3.1/site-packages
+
+The brp-python-bytecompile script tries to figure this out for you.  The script determines which interpreter to use when byte compiling the module by following these steps:
+
+
    
+
  1. what directory is the module installed in?  If it's /usr/lib{,64}/pythonX.Y, then pythonX.Y is used to byte compile the module.  If pythonX.Y is not installed, then an error is returned and the rpm build process will exit on an error so remember to BuildRequire the proper python package.
    2. 
+
+
  2. the script interpreter defined in %{__python} is used to compile the modules.  This defaults to the latest python2 version on Fedora.  If you need to compile this module for python3, set it to /usr/bin/python3 instead:
+
+
    +%global __python %{__python3}
+
    
+
+Doing this is useful when you have a python3 application that's installing a private module into its own directory.  For instance, if the foobar application installs a module for use only by the command line application in %{_datadir}/foobar.  Since these files are not in one of the python3 library paths (ie. /usr/lib/python3.1) you have to override %{__python} to tell brp-python-bytecompile to use the python3 interpreter for byte compiling.
+
    3. 
+

+
+These settings are enough to properly byte compile any package that builds python modules in %{python_sitelib} or %{python_sitearch} or builds for only a single python interpreter.  However, if the application you're packaging needs to build with both python2 and python3 and install into a private module directory (perhaps because it provides one utility written in python2 and a second utility written in python3) then you need to do this manually. Here's a sample spec file snippet that shows what to do:
+
+
+# Turn off the brp-python-bytecompile script
+%global __os_install_post %(echo '%{__os_install_post}' | sed -e 's!/usr/lib[^[:space:]]*/brp-python-bytecompile!!g')
+# Buildrequire both python2 and python3
+BuildRequires: python2-devel python3-devel
+[...]
+
+%install
+# Installs a python2 private module into %{buildroot}%{_datadir}/mypackage/foo
+# and installs a python3 private module into %{buildroot}%{_datadir}/mypackage/bar
+make install DESTDIR=%{buildroot}
+
+# Manually invoke the python byte compile macro for each path that needs byte
+# compilation.
+%{py_byte_compile} %{__python} %{buildroot}%{_datadir}/mypackage/foo
+%{py_byte_compile} %{__python3} %{buildroot}%{_datadir}/mypackage/bar
+

+
+The %{py_byte_compile macro takes two arguments.  The first is the python interpreter to use for byte compiling.  The second is a file or directory to byte compile.  If the second argument is a directory, the macro will recursively byte compile any *.py file in the directory.
+
+=== Including pyos ===
+In the past it was common practice to %ghost .pyo files in order to save a small amount of space on the users filesystem.  However, this has two issues:
+
    
+
  1. With SELinux, if a user is running python -O [APP]  it will try to write the .pyos when they don't exist.  This leads to AVC denial records in the logs.
    2. 
+
  2. If the system administrator runs python -OO [APP]  the .pyos will get created with no docstrings.  Some programs require docstrings in order to function.  On subsequent runs with python -O [APP]  python will use the cached .pyos even though a different optimization level has been requested.  The only way to fix this is to find out where the .pyos are and delete them.
    3. 
+

+
+The current method of dealing with pyo files is to '''include them as is; no %ghosting'''.
+
+== Common SRPM vs split SRPMs ==
+
+Many times when you package a python module you will want to create a module for python2 and a module for python3.  There are two ways of doing this: either from a single SRPM or from multiple.  The rule to choose which method is simple: if the python2 and python3 modules are distributed as a single tarball (many times as a single directory of source where the /usr/bin/2to3 program is used to transform the code at buildtime) then you must package them as subpackages built from a single SRPM.  If they come in multiple tarballs then package them from multiple SRPMs.
+
+{{admon/note|Python Bindings|python bindings are sometimes built as part of the C library's build.  The ideal for these is to patch the code so it will build against both python2 and python3.  Then take a copy of the sources during the %prep phase, and configure one subdirectory to build against python 2, another to build against python 3.  These changes should be upstreamed.  Example: the build of rpm itself emits an rpm-python subpackage (see [[https://bugzilla.redhat.com/show_bug.cgi?id=531543  bug 531543]])}}
+
+=== Multiple SRPMS ===
+
+When upstream ships multiple tarballs with one tarball containing python2 code and a different tarball containing python3 code, we should ship those as multiple SRPMs.  The two SRPMs could have different maintainers within Fedora and the two packages need not upgrade at the same time.  Building from multiple SRPMs has some advantages and disadvantages:
+
+'''Advantages''':
+* There can be separate maintainers for python2 and python3 so each maintainer can concentrate on one stack.
+* The two packages can evolve separately; if 2 and 3 need to have different versions, they can.
+
+'''Disadvantages''':
+* The two specfiles have to be maintained separately
+* When upstream releases e.g. security fixes, they have to be tracked in two places
+
+The following practices are designed to help mitigate the disadvantages listed above:
+
+* When packaging a module for python3 contact the maintainers for the python2 module and try to coordinate with them.
+* Request at least watchbugzilla and watchcommit acls on each other's packages so you're aware of outstanding bugs.
+* Complete any python 2 Merge Review when doing the python 3 version.  Doing this gets issues that apply to both packages addressed at the same time.
+* Add a link to the python 2 Merge Review/Package Review to the python 3 Package Review
+
+=== Subpackages ===
+
+{{admon/warning|Do not build python3 modules without upstream support|If upstream is shipping a module for python2 and does not support making that module run on python3, do not package a python3 version of it in Fedora.  If running 2to3 or adding a patch enables the code to work, you can certainly tell upstream that it works to encourage them to support python3.  However, doing this on our own in Fedora is essentially creating a fork.  That has a large burden for maintaining the code, fixing bugs, porting when a new version of upstream's code appears, managing a release schedule, and other tasks normally handled by upstream.  It's much better if we can cooperate with upstream to share this work than doing it all on our own.}}
+
+Sometimes upstream will ship one tarball that builds both a python2 and a python3 module.  There's several ways that upstream can structure this.  When upstream writes their build scripts to build both python2 and python3 modules in a single build this is just like building subpackages for any other package.  You expand the tarball and patch the source in %prep, run upstream's build scripts to build the package in %build, and then run upstream's build scripts to install it in %install.
+
+'''Advantages''':
+* Single src.rpm to review and build
+* Avoids having to update multiple packages when things change.
+
+'''Disadvantages''':
+* The Fedora maintainer needs to care about both python 2 and python 3 modules which makes more work to maintain that package.
+* The 2 and 3 versions are in lockstep.  Bugfixes need to apply to python2 while not breaking the translation into python3.
+* Bugzilla components are set up according to source RPM, so they will have a single shared bugzilla component.  This could be confusing to end-users, as it would be more difficult to figure out e.g. that a bug with python3-foo needs to be filed against python-foo.  There's a similar problem with checking out package sources from CVS, though this is less serious as it is less visible to end users.
+
+Two other ways exist for the upstream to support building python3 modules from a single source:
+
+==== Building more than once ====
+
+One way that's currently very common is for the build scripts to create either a python2 or python3 module based on which interpreter is used to run the setup.py script.  (The [http://cvs.fedoraproject.org/viewvc/rpms/python-setuptools/devel/python-setuptools.spec?revision=1.31&view=markup python-setuptools package] is currently built this way).
+
+===== Example spec file =====
+
+
+%if 0%{?fedora} > 12 || 0%{?rhel} > 6
+%global with_python3 1
+%else
+%{!?python_sitelib: %global python_sitelib %(%{__python} -c "from distutils.sysconfig import get_python_lib; print (get_python_lib())")}
+%endif
+
+%global srcname distribute
+

+
+At the top of our spec file we have the standard define for python_sitelib on older Fedora releases.  We also define with_python3 which we'll use to conditionalize the build whenever we have a section that is only useful when building a python3 module.  Using with_python3 allows us to do two things:
+
+
    
+
  1. It makes it easy to turn off the python3 build when tracking down problems.
    2. 
+
  2. The conditionals also make it easy to use the same spec for older releases of Fedora and EPEL.
    3. .
+

+
+{{admon/warning|Leave python3 module enabled in releases|Once python 3 support has been added to a package, you must leave it enabled.  End users could be using the python3 subpackage that is being built.  If you turn the subpackage build on and off it will cause the package to unexpectedly disappear from the repos.  You should only turn off with_python3 as a debugging measure within scratch builds, for releases that do not support python 3, or when moving a python3 module into its own, independent package.}}
+
+
+Name:           python-setuptools
+Version:        0.6.10
+Release:        2%{?dist}
+Summary:        Easily build and distribute Python packages
+
+Group:          Applications/System
+License:        Python or ZPLv2.0
+URL:            http://pypi.python.org/pypi/%{srcname}
+Source0:        http://pypi.python.org/packages/source/d/%{srcname}/%{srcname}-%{version}.tar.gz
+# Fix a failing test case
+Patch0:         python-setuptools-test.patch
+BuildRoot:      %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
+
+BuildArch:      noarch
+BuildRequires:  python2-devel
+%if 0%{?with_python3}
+BuildRequires:  python3-devel
+%endif # if with_python3
+

+
+When we build the python3 module in addition to the python3 module we need both python2-devel and python3-devel.
+
+
+%description
+Setuptools is a collection of enhancements to the Python distutils that allow
+you to more easily build and distribute Python packages, especially ones that
+have dependencies on other packages.
+
+This package contains the runtime components of setuptools, necessary to
+execute the software that requires pkg_resources.py.
+
+%if 0%{?with_python3}
+%package -n python3-setuptools
+Summary:        Easily build and distribute Python 3 packages
+Group:          Applications/System
+
+%description -n python3-setuptools
+Setuptools is a collection of enhancements to the Python 3 distutils that allow
+you to more easily build and distribute Python 3 packages, especially ones that
+have dependencies on other packages.
+
+This package contains the runtime components of setuptools, necessary to
+execute the software that requires pkg_resources.py.
+%endif # with_python3
+

+
+Here we define the python3 subpackage.  Note that we use %package -n to name the module appropriately.
+
+
+%prep
+%setup -q -n %{srcname}-%{version}
+
+%patch0 -p1 -b .testfix
+
+find -name '*.txt' | xargs chmod -x
+
+%if 0%{?with_python3}
+rm -rf %{py3dir}
+cp -a . %{py3dir}
+find %{py3dir} -name '*.py' | xargs sed -i '1s|^#!python|#!%{__python3}|'
+%endif # with_python3
+
+find -name '*.py' | xargs sed -i '1s|^#!python|#!%{__python}|'
+

+
+
+Our method in building from the same code to make the two separate modules is to keep each build as independent as possible.  To do that, we copy the source tree to %{py3dir} so that the python 2 sources are entirely independent from the python 3 sources.  Some things to watch out for:
+
+* Be sure to clean up the %{py3dir} before performing the copy.  It's easy to forget that since %setup does that automatically for the python2 module.
+* Make sure that you are copying the correct code.  The example is copying the code from within the top directory of the untarred source.  If the %prep has changed directory you will need to change back to the tarball location.
+* Patching the source code is done before copying to %{py3dir}.  Since you have both a python2 and a python3 directory you might be tempted to patch each one separately.  '''Resist!'''  Upstream for your package has chosen to distribute a single source tree that builds for both python2 and python3.  For your patches to [[Staying_close_to_upstream_projects| get into upstream]], you need to write patches that work with both as well.}}
+
+rpmbuild resets the directory at the end of each phase, so you don't need to restore the directory at the end of %prep.
+
+
+%build
+CFLAGS="$RPM_OPT_FLAGS" %{__python} setup.py build
+
+%if 0%{?with_python3}
+pushd %{py3dir}
+CFLAGS="$RPM_OPT_FLAGS" %{__python3} setup.py build
+popd
+%endif # with_python3
+
+%install
+rm -rf %{buildroot}
+
+# Must do the python3 install first because the scripts in /usr/bin are
+# overwritten with every setup.py install (and we want the python2 version
+# to be the default for now).
+%if 0%{?with_python3}
+pushd %{py3dir}
+%{__python3} setup.py install --skip-build --root $RPM_BUILD_ROOT
+
+rm -rf %{buildroot}%{python3_sitelib}/setuptools/tests
+
+find %{buildroot}%{python3_sitelib} -name '*.exe' | xargs rm -f
+chmod +x %{buildroot}%{python3_sitelib}/setuptools/command/easy_install.py
+popd
+%endif # with_python3
+
+%{__python} setup.py install --skip-build --root $RPM_BUILD_ROOT
+
+rm -rf ${buildroot}%{python_sitelib}/setuptools/tests
+
+find %{buildroot}%{python_sitelib} -name '*.exe' | xargs rm -f
+chmod +x %{buildroot}%{python_sitelib}/setuptools/command/easy_install.py
+
+%check
+%{__python} setup.py test
+
+%if 0%{?with_python3}
+pushd %{py3dir}
+%{__python3} setup.py test
+popd
+%endif # with_python3
+

+
+You'll notice that the %build, %install, and %check sections follow a common pattern.  They do the normal steps for building the python2 module but then they switch to %{py3dir} and run the same steps for python3.  Creating the new sections is generally pretty easy.  First copy the existing code.  Then wrap it with a pushd/popd to %{py3dir}.  The usage of pushd/popd commands will ensure that the directories are logged.  Finally, convert all macro references:
+
+* %{__python} becomes %{__python3}
+* %{python_sitelib} becomes %{python3_sitelib}
+* %{python_sitearch} becomes %{python3_sitearch}
+
+{{admon/warning|Order can be important|As you can see in the %install section, the order in which you do the python2 versus python3 install can sometimes matter.  You need to be aware of when the install is writing to the same file in both packages (in this example, a script in %{_bindir} and make sure that you're getting the version you expect.}}
+
+
+%clean
+rm -rf $RPM_BUILD_ROOT
+
+
+%files
+%defattr(-,root,root,-)
+%doc psfl.txt zpl.txt docs
+%{python_sitelib}/*
+%{_bindir}/easy_install
+%{_bindir}/easy_install-2.6
+
+%if 0%{?with_python3}
+%files -n python3-setuptools
+%defattr(-,root,root,-)
+%doc psfl.txt zpl.txt docs
+%{python3_sitelib}/*
+%{_bindir}/easy_install-3.1
+%endif # with_python3
+
+%changelog
+

+
+In this final section, you can see that we once again switch macros from %python_sitelib} to %{python3_sitelib}.  Since we chose to install the python2 version of %{_bindir}/easy_install earlier we need to include that file in the python2 package rather than the python3 subpackage.
+
+==== Running 2to3 from the spec file ====
+Sometimes, upstream hasn't integrated running 2to3 on the code into their build scripts but they support making a python3 module from it if you manually run 2to3 on the source.  This is the case when it's documented on the upstream's website, in a file in the tarball, or even when email with the module's author has instructions for building a python3 module from the python2 source and the authors are willing to support the result.  In these cases it's usually just a matter of the upstream not having written the build script that can turn the python2 source into python3.  When this happens you can run 2to3 from the spec file.  Once you have it working, you can also help upstream integrate it into their build scripts which will benefit everyone in the long term.
+
+You should usually follow upstream's directions on how to run 2to3 and build the python3 module in these cases but there's a few things you should check to make sure upstream is doing it correctly.
+
+* Since the code is being built from a unified source, you need to copy the code to a new directory before invoking 2to3 just like the [#Building_more_than_once "building more than once"] method.
+* If the 2to3 program is invoked instead of using the lib2to3 library functions, make sure it's invoked with --write --nobackups.  --write is needed to make 2to3 actually change the files.  --nobackups avoids leaving foo.py.bak files in the module directories that then make it into the final package payload.
+* Be sure to run 2to3 on the correct directory.  When you run 2to3 you need to run it on the whole tree.  A common mistake here for distutils packages has been to run it on the directory below setup.py, missing the setup.py file itself.  This leads to errors when python3 tries to execute setup.py
+* If you need to run 2to3 to fix code, use 2to3 or /usr/bin/2to3.  At the moment, this program is coming from the python-tools rpm.  Using 2to3 means that you'll be using a name that is supported upstream and across distros rather than /usr/bin/python3-2to3 which we have renamed in Fedora to avoid filesystem conflicts.  This also makes it easier for us to test and eventually change from using the python2 2to3 to the python3 2to3.  We just need to change the python3 package to provide the /usr/bin/2to3 program instead of python and all of our python packages will start using that version instead.
+* If 2to3 runs into a problem, please [https://bugzilla.redhat.com/enter_bug.cgi?component=python&product=Fedora file a Fedora bug].  Please try to isolate a minimal test case that reproduces the problem when doing so.
+
+== Avoiding collisions between the python 2 and python 3 stacks ==
+The python 2 and python 3 stacks are intended to be fully-installable in parallel. When generalizing the package for both python 2 and python 3, it is important to ensure that two different built packages do not attempt to place different payloads into the same path.
+
+=== Executables in /usr/bin ===
+==== The problem ====
+Many existing python packages install executables into /usr/bin. 
+
+For example if we have a console_scripts in a setup.py shared between
+python 2 and python 3 builds: these will spit out files in /usr/bin/,
+and these will collide.
+
+For example python-coverage has a setup.py that contains:
+
+    entry_points = {
+        'console_scripts': [
+            'coverage = coverage:main',
+            ]
+        },
+

+
+which thus generates a /usr/bin/coverage executable (this is a python
+script that runs another python script whilst generating code-coverage
+information on the latter).
+
+Similarly for the 'scripts' clause; see e.g. python-pygments:
+Pygments-1.1.1/setup.py has:
+
+    scripts = ['pygmentize'],
+

+which generates a /usr/bin/pygmentize (this is a python script that leverages the pygments syntax-highlighting module, giving a simple command-line interface for generating syntax-highlighted files)
+
+==== Guidelines ====
+If the executables provide the same functionality independent of whether they are run on top of Python 2 or Python 3, then only one version of the executable should be packaged.  Currently it will be the python 2 implementation, but once the Python 3 implementation is proven to work, the executable can be retired from the python 2 build and enabled in the python 3 package.  Be sure to test the new implementation.  Transitioning from python2 to python3 is left to individual package maintainers except for packages in Fedora's critical path.  For these, we want to port to python3 versions in the same Fedora release if possible.
+
+Examples of this:
+* /usr/bin/pygmentize ought to generate the same output regardless of whether it's implemented via Python 2 or Python 3, so only one version needs to be shipped.
+
+If the executables provide different functionality for Python 2 and Python 3, then both versions should be packaged. 
+
+Examples of this:
+* /usr/bin/coverage runs a python script, augmenting the interpreter with code-coverage information.  Given that the interpreter itself is the thing being worked with, it's reasonable to package both versions of the executable.
+* /usr/bin/bpython augments the interpreter with a "curses" interface.  Again, it's reasonable to package both versions of this.
+* /usr/bin/easy_install installs a module into one of the Python runtimes: we need a version for each runtime.
+  
+As an exception, for the rpms that are part of a python runtime itself, we plan to package both versions of the executables, so that e.g. both the python 2 and python 3 versions of 2to3 are packaged.
+
+==== Naming ====
+Many executables already contain a "-MAJOR.MINOR" suffix, for example /usr/bin/easy_install-3.1.  These obviously can be used as-is, as they won't conflict.
+
+For other executables, the general rule is:
+* if only one executable is to be shipped, then it owns its own slot
+* if executables are to be shipped for both python 2 and python 3, then the python 3 version of the executable gains a python3- prefix.  For example, the python 2 version of "coverage" remains /usr/bin/coverage and the python 3 version is /usr/bin/python3-coverage.
+See [http://lists.fedoraproject.org/pipermail/devel/2010-January/129217.html this thread] for a discussion of this.
+
+== Packaging eggs and setuptools concerns ==
+
+{{admon/note||To be moved from the [Packaging:Python/Eggs#What_are_eggs] page}}
+
+Eggs can mean several different things because they can be placed on disk in several formats:
+
+* A module and a file with a .egg-info extension that contains the metadata.  Created by distutils in Fedora 9 and above.
+* As a module and a directory with a .egg-info extension that contains the metadata.  Created using setuptools and also the invocation of setup.py in our examples below.
+* As a directory with a .egg extension that contains the module and egg metadata.  Created when we use easy_install -m to allow installing multiple versions of a module.
+* As a single zip file with a .egg extension that contains the module and the egg metadata.
+
+In Fedora packages, these will be installed to %{python_sitelib} or %{python_sitearch} directories.  We do not install the single zip file version of eggs in Fedora but the three other formats are used.
+
+=== How to package ===
+
+The following are a summary of the guidelines for reviewers to go over when a python module is packaged.  The [[Packaging/Python/Eggs|  complete policy]]  includes examples and rationale for the way we do things.
+
+* '''Must''': Python eggs must be built from source.  They cannot simply drop an egg from upstream into the proper directory. (See [[Packaging:Guidelines#No_inclusion_of_pre-built_binaries_or_libraries| prebuilt binaries Guidelines]] for details)
+* '''Must''': Python eggs must not download any dependencies during the build process.
+* '''Must''': If egg-info files are generated by the module's build scripts they must be included in the package.
+* '''Must''': When building a compat package, it must install using easy_install -m so it won't conflict with the main package.
+* '''Must''': When building multiple versions (for a compat package) one of the packages must contain a default version that is usable via "import MODULE" with no prior setup.
+* '''Should''': A package which is used by another package via an egg interface should provide egg info.
+
+== PyGTK2 and Numpy ==
+{{admon/note||This is a temporary workaround which may be resolved in the future. It will no longer be necessary when [[http://bugzilla.gnome.org/show_bug.cgi?id=591745 gnome bug #591745]] is fixed.}}
+
+If your package uses pygtk2, and calls the gtk.gdk.get_pixels_array() function, that package needs to explicitly Require: numpy. In the past, pygtk2 had a Requires on numpy, but since it is only used for that one function (and that function is not commonly used), the Requires has been removed to minimize the install footprint of pygtk2.
+
+[[Category:Packaging guidelines]] [[Category:Python]]

From 25ac1b3f92490dd9cf50b417b1908cd812300498 Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Feb 11 2010 18:11:11 +0000
Subject: [PATCH 428/3559] Remove note to remove from python eggs page


---

diff --git a/Packaging:Python.mw b/Packaging:Python.mw
index 09d5a87..20416c6 100644
--- a/Packaging:Python.mw
+++ b/Packaging:Python.mw
@@ -454,8 +454,6 @@ See [http://lists.fedoraproject.org/pipermail/devel/2010-January/129217.html thi
 
 == Packaging eggs and setuptools concerns ==
 
-{{admon/note||To be moved from the [Packaging:Python/Eggs#What_are_eggs] page}}
-
 Eggs can mean several different things because they can be placed on disk in several formats:
 
 * A module and a file with a .egg-info extension that contains the metadata.  Created by distutils in Fedora 9 and above.

From feb807ff86df1cd2d69a8aa0f642e0b50174e579 Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Feb 11 2010 18:14:19 +0000
Subject: [PATCH 429/3559] Update since more info has moved to  the main Python Guideline


---

diff --git a/Packaging:Python_Eggs.mw b/Packaging:Python_Eggs.mw
index 90162e2..81daf4f 100644
--- a/Packaging:Python_Eggs.mw
+++ b/Packaging:Python_Eggs.mw
@@ -1,8 +1,6 @@
 = Python Eggs =
 
-Python packages have started to use setuptools in their package build scripts.  Packages which do this provide extra metadata about the package in the form of eggs.  This document explains how to package eggs.
-
-
+Python packages provide extra metadata about the package in the form of eggs.  This document explains how to package eggs.
 
 == Why Eggs ==
 Eggs have several uses including:
@@ -12,14 +10,7 @@ Eggs have several uses including:
 
  • Giving us a way to support multiple versions of a python module for compat libraries.
 
 
-== What are Eggs ==
-Eggs can be placed on disk in several formats:
-* As a module and a file with a .egg-info extension that contains the metadata.  Created by distutils in Fedora 9's python2.5.
-* As a module and a directory with a .egg-info extension that contains the metadata.  Created using the most common invocation of setup.py in our examples below.
-* As a directory with a .egg extension that contains the module and egg metadata.  Created when we use easy_install -m to allow installing multiple versions of a module.
-* As a single zip file with a .egg extension that contains the module and the egg metadata.
-
-In Fedora Packages, these will be installed to %{python_sitelib} or %{python_sitearch} directories.
+The egg metatada can be used at runtime so it cannot be replaced with the rpm database which is only useful at installtime or by tools specifically for Fedora.
 
 {{Anchor|WhenEggs}}
 == When to Provide Eggs ==

From 00296a40d1644cfd451009fca0b34774050c5c50 Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Feb 11 2010 18:14:59 +0000
Subject: [PATCH 430/3559] Add categories


---

diff --git a/Packaging:Python_Eggs.mw b/Packaging:Python_Eggs.mw
index 81daf4f..b6a191a 100644
--- a/Packaging:Python_Eggs.mw
+++ b/Packaging:Python_Eggs.mw
@@ -127,3 +127,6 @@ Eggs provide some features that are to be avoided as part of the packaging proce
 * http://peak.telecommunity.com/DevCenter/setuptools
 * http://lists.debian.org/debian-python/2007/09/msg00004.html -- Discussion of eggs in Debian
 * http://mail.python.org/pipermail/distutils-sig/2007-September/008181.html -- Discussion of these guidelines on the distutils list
+
+[[Category:Packaging guidelines]]
+[[Category:Python]]

From f5a27f4ac9c4c5c050c9e8a599f86b4fbd5a2839 Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Feb 11 2010 18:16:42 +0000
Subject: [PATCH 432/3559] moved [[Packaging:Python/Eggs]] to [[Packaging:Python Eggs]]: Rename for mediawiki compliance


---

diff --git a/Packaging:Python%2FEggs.mw b/Packaging:Python%2FEggs.mw
new file mode 100644
index 0000000..8627453
--- /dev/null
+++ b/Packaging:Python%2FEggs.mw
@@ -0,0 +1 @@
+#REDIRECT [[Packaging:Python Eggs]]

From e29bb59943b896df10e96d81466f16cb6044d28c Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Feb 11 2010 18:17:25 +0000
Subject: [PATCH 433/3559] Python Eggs URL change


---

diff --git a/Packaging:Python.mw b/Packaging:Python.mw
index 20416c6..a0aff1a 100644
--- a/Packaging:Python.mw
+++ b/Packaging:Python.mw
@@ -465,7 +465,7 @@ In Fedora packages, these will be installed to %{python_sitelib} or %{python_sit
 
 === How to package ===
 
-The following are a summary of the guidelines for reviewers to go over when a python module is packaged.  The [[Packaging/Python/Eggs|  complete policy]]  includes examples and rationale for the way we do things.
+The following are a summary of the guidelines for reviewers to go over when a python module is packaged.  The [[Packaging:Python Eggs|  complete policy]]  includes examples and rationale for the way we do things.
 
 * '''Must''': Python eggs must be built from source.  They cannot simply drop an egg from upstream into the proper directory. (See [[Packaging:Guidelines#No_inclusion_of_pre-built_binaries_or_libraries| prebuilt binaries Guidelines]] for details)
 * '''Must''': Python eggs must not download any dependencies during the build process.

From 1b0855491b7dbf597462861f86d6efb4828050e3 Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Feb 11 2010 18:23:28 +0000
Subject: [PATCH 434/3559] Add Python3 naming section


---

diff --git a/Packaging:Naming.mw b/Packaging:Naming.mw
index 256f2b5..9fc3cb1 100644
--- a/Packaging:Naming.mw
+++ b/Packaging:Naming.mw
@@ -416,7 +416,34 @@ python-tpg (python module named tpg)
 
 There is an exception to this rule. If the upstream source has "py" (or "Py") in its name, you can use that name for the package. So, for example, pygtk is acceptable.
 
+{{Anchor|Python3}}
+== Addon Packages (python3 modules) ==
+
+An rpm with a python prefix or suffix means a python2 rpm so we need a different prefix to denote python3 packages.  For this, we use python3.  We have two constraints that the python2 packages don't operate under:
+
+
      
+
    1.  We need to be clear about these modules being for python3 so we don't have an exception for packages that already have "py" in their names like python2 modules.
      2. 
+
    2.  Consumers of the packages need to be able to find them even if they don't know whether they're using the python2 or python3 version.
      3. 
+
    
+
+So all python3 modules '''MUST''' have python3 in their name.  Other than that, the module must be in the same format as the python2 package.  Some examples:
+{|
+! Fedora python 2 package !! Upstream name !! Proposed python 3 package name
+|-
+| python-lxml             || lxml          || python3-lxml
+|-
+| pygtk2                  || pygtk         || python3-pygtk
+|-
+| gstreamer-python        || gst-python    || gstreamer-python3
+|-
+| gnome-python2           || gnome-python  || gnome-python3
+|-
+| rpm-python              || (part of rpm) || rpm-python3
+|}
+
+
 {{Anchor|AddonR}}
+
 == Addon Packages (R modules) ==
 Packages of R modules (thus they rely on R as a parent) have their own naming scheme. They should take into account the upstream name of the R module. This makes a package name format of R-$NAME. When in doubt, use the name of the module that you type to import it in R.
 

From 91531552e102ea66d88c35e7cd78b2820dbf7730 Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Feb 17 2010 17:36:19 +0000
Subject: [PATCH 435/3559] Add category


---

diff --git a/Packaging:Cmake.mw b/Packaging:Cmake.mw
index 645c813..ef0202b 100644
--- a/Packaging:Cmake.mw
+++ b/Packaging:Cmake.mw
@@ -58,3 +58,5 @@ Nevertheless, RPATH issues might arise when cmake was used improperly. E.g. inst
 '''NOTE''': cmake has good documentation in two places:
 * http://www.cmake.org/HTML/Documentation.html
 * http://www.cmake.org/Wiki/CMake
+
+[[Category:Packaging guidelines]]

From 25bb23cf1ba075cc6cd85e91dd9e85e239adf1a3 Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Feb 17 2010 17:37:11 +0000
Subject: [PATCH 436/3559] Add categories


---

diff --git a/Packaging:Debuginfo.mw b/Packaging:Debuginfo.mw
index 8824157..886f9d2 100644
--- a/Packaging:Debuginfo.mw
+++ b/Packaging:Debuginfo.mw
@@ -45,3 +45,5 @@ It is normal for noarch package builds to not produce a debuginfo package.  If i
 * http://mirrors.kernel.org/fedora/extras/development/i386/debug/?C=S;O=A
 * [[StackTraces]]
 * rpmlint >= 0.77
+
+[[Category:Packaging guidelines]]

From 543d6646682d7bc3393a18d12ca9d2dce138e778 Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Feb 17 2010 17:38:12 +0000
Subject: [PATCH 437/3559] Add category


---

diff --git a/Packaging:DistTag.mw b/Packaging:DistTag.mw
index 2f93fb2..411f812 100644
--- a/Packaging:DistTag.mw
+++ b/Packaging:DistTag.mw
@@ -164,5 +164,4 @@ A: RPMForge has a set of standard dist tags that they use. Specifically:
 
    • 
 RPMForge precedes the distribution value with a numeric value, designed to assist in upgrades between versions of Red Hat Linux, Red Hat Enterprise Linux, and Fedora. I really don't think that an upgrade path between RHEL and Fedora is viable, or something that we should attempt to promote. If Fedora used the same dist tags, we'd be implying that there was support for upgrading between drastically different distributions. It also adds an extra layer of complexity to the Release field, confusing users and new packagers.
 
-----
-[[Category:Extras]]
+[[Category:Packaging guidelines]]

From f9fd8facde8b7824bedfd81e961cab3f3e25a027 Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Feb 17 2010 17:42:18 +0000
Subject: [PATCH 438/3559] Add categories


---

diff --git a/Packaging:EclipsePlugins.mw b/Packaging:EclipsePlugins.mw
index 656da55..79e7253 100644
--- a/Packaging:EclipsePlugins.mw
+++ b/Packaging:EclipsePlugins.mw
@@ -246,3 +246,5 @@ OSGi bundles contain metadata just like RPMs do.  This metadata can be used to a
 
 === rpmstubby ===
 rpmstubby is a small project that is part of the [http://eclipse.org/linuxtools linuxdistros project]  at eclipse.org.  Its aim is to make packaging Eclipse plugins as RPMs extremely simple.  It is still in its infancy, but specfiles for packages like eclipse-mylyn were originally stubbed out using it.  It is hoped that it can soon be provided as a tool to Fedora packagers.  Help is always welcome on the project and it can be checked out of svn here:  svn://anonymous@dev.eclipse.org/svnroot/technology/org.eclipse.linuxtools/rpmstubby/trunk.
+
+[[Category:Packaging guidelines]]

From 1e2fab9bf648a704c174453bfae31f090d6f00f0 Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Feb 17 2010 17:48:59 +0000
Subject: [PATCH 439/3559] Add Category


---

diff --git a/Packaging:Emacs_Old.mw b/Packaging:Emacs_Old.mw
index dc2920f..a75fff9 100644
--- a/Packaging:Emacs_Old.mw
+++ b/Packaging:Emacs_Old.mw
@@ -415,3 +415,5 @@ rm -rf $RPM_BUILD_ROOT
 
 %changelog
 
    
+
+[[Category:Packaging guidelines]]

From 3ef6b13158f9ff17ed4e8cd01975c8d47f159cc0 Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Feb 17 2010 17:50:02 +0000
Subject: [PATCH 440/3559] Add Category


---

diff --git a/Packaging:FontsPolicy.mw b/Packaging:FontsPolicy.mw
index 26f91ee..ce5526b 100644
--- a/Packaging:FontsPolicy.mw
+++ b/Packaging:FontsPolicy.mw
@@ -199,3 +199,4 @@ The users of this legacy backend won't thank you for destabilizing it with new f
 
 {{:Fonts_SIG_signature}}
 [[Category:Fonts packaging|Packaging policy]]
+[[Category:Packaging guidelines]]

From 1de5f9e8b7388cb5750b0a21c2c933774e78e76d Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Feb 17 2010 18:08:25 +0000
Subject: [PATCH 441/3559] Add categories


---

diff --git a/Packaging:FullExceptionList.mw b/Packaging:FullExceptionList.mw
index 5d6f9f9..879b9c6 100644
--- a/Packaging:FullExceptionList.mw
+++ b/Packaging:FullExceptionList.mw
@@ -1,5 +1,5 @@
-
-This list is derived from [[Packaging/Guidelines#Exceptions]]  by resolving all deps. These are the packages you can safely assume will be present in a BuildRoot without being pulled in by a package's BuildRequires.
+This list is derived from [[Packaging:Guidelines#Exceptions]]  by resolving all deps. These are the packages you can safely assume will be present in a BuildRoot without being pulled in by a package's BuildRequires.
 
 List has been removed as it is variable across the collections.  If you need something that is '''A)''' not listed in the minimal list, and '''B)''' isn't brought in by something else you BuildRequire, you should list it as a BuildRequire just to be safe.
+
+[[Category:Packaging guidelines]]

From c72a10ca04e0efb604ba1062f419b6c2913d04f2 Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Feb 17 2010 18:31:28 +0000
Subject: [PATCH 442/3559] Add categories


---

diff --git a/Packaging:GCJGuidelines.mw b/Packaging:GCJGuidelines.mw
index b6a338b..64a9b18 100644
--- a/Packaging:GCJGuidelines.mw
+++ b/Packaging:GCJGuidelines.mw
@@ -55,3 +55,5 @@ BuildArch:      noarch
 %attr(-,root,root) %{_libdir}/gcj/%{name}/foo-x.y.z.jar.*
 %endif
 
      Note that the path has been stripped and .* has been appended.
+
+[[Category: Packaging guidelines]]

From ee44385ee2a4a238198734011e0b6ea7087f73e1 Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Feb 17 2010 18:35:53 +0000
Subject: [PATCH 443/3559] Add category


---

diff --git a/Packaging:GuidelinesTodo.mw b/Packaging:GuidelinesTodo.mw
index 4497c5b..bac4fe6 100644
--- a/Packaging:GuidelinesTodo.mw
+++ b/Packaging:GuidelinesTodo.mw
@@ -1,6 +1,3 @@
-
-
 == Action Items ==
 Status should be one of:
 * ratify -- Change needs be presented to FESCo for objections.
@@ -345,4 +342,4 @@ Emailed Jussi Lehtola about the required changes to packages listed which are st
 |Register VirtualProvides  ||PatriceDumas||failed vote||["PackagingDrafts/ProvidesList"]  idea is sound, but should be automatically generated.
 |}
 ----
-[[Category:Extras]]
+[[Category: Packaging guidelines]]

From 5b109f699caa952be80c65952c5d1add03aa2298 Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Feb 17 2010 18:36:43 +0000
Subject: [PATCH 444/3559] Add proper category


---

diff --git a/Packaging:GuidelinesTodo.mw b/Packaging:GuidelinesTodo.mw
index bac4fe6..34f86bb 100644
--- a/Packaging:GuidelinesTodo.mw
+++ b/Packaging:GuidelinesTodo.mw
@@ -342,4 +342,4 @@ Emailed Jussi Lehtola about the required changes to packages listed which are st
 |Register VirtualProvides  ||PatriceDumas||failed vote||["PackagingDrafts/ProvidesList"]  idea is sound, but should be automatically generated.
 |}
 ----
-[[Category: Packaging guidelines]]
+[[Category: Packaging committee]]

From 15919c527a60925b660a7ddc58fc2fa1d3f3235d Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Feb 17 2010 19:00:32 +0000
Subject: [PATCH 445/3559] Add category


---

diff --git a/Packaging:JPackagePolicy.mw b/Packaging:JPackagePolicy.mw
index 1e9cab6..a094268 100644
--- a/Packaging:JPackagePolicy.mw
+++ b/Packaging:JPackagePolicy.mw
@@ -92,3 +92,5 @@ With the subrelease scheme as documented above, it is very obvious from which JP
 * Fedora Java packages (which have a relationship to JPackage packages) must follow the subrelease versioning as defined in this document. 
 * No other packages fall under this policy (at this time).
 * Packagers of Fedora Java packages need to explicitly agree to this policy during package review.
+
+[[Category:Packaging guidelines]]

From 04529039f2a6bf199afe4252f9fef9c9f9bea6d9 Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Feb 17 2010 19:01:28 +0000
Subject: [PATCH 446/3559] Add categories


---

diff --git a/Packaging:Java.mw b/Packaging:Java.mw
index ad966c5..fa30f5a 100644
--- a/Packaging:Java.mw
+++ b/Packaging:Java.mw
@@ -392,3 +392,4 @@ sed -i '/class-path/I d' META-INF/MANIFEST.MF
 '''Will this preserve the line ending as the [http://java.sun.com/docs/books/tutorial/deployment/jar/downman.html this page]  says it must?'''
 
 [[Category:Packaging guidelines]]
+[[Category:Java]]

From 9030a415b0c2f1078a6f574e0ee8d92355c6f00e Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Feb 17 2010 19:02:51 +0000
Subject: [PATCH 447/3559] Add categories


---

diff --git a/Packaging:KernelModules.mw b/Packaging:KernelModules.mw
index 0fb2e21..da312ba 100644
--- a/Packaging:KernelModules.mw
+++ b/Packaging:KernelModules.mw
@@ -3,3 +3,7 @@ At one point (pre Fedora 8), packages containing "addon" kernel modules were per
 Existing kernel module packages must be removed (or merged into the main kernel package) before Fedora 9.
 
 The reference documentation on how to package kernel modules in the "kmod" style has been preserved [[Obsolete/KernelModules|  here]] .
+
+[[Category:Packaging guidelines]]
+[[Category:Policy]]
+[[Category:Guidelines hackfest]]

From 01e5013ff2b2f6027369ef02ce8420242ddf9891 Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Feb 17 2010 19:10:17 +0000
Subject: [PATCH 448/3559] Add categories


---

diff --git a/Packaging:LicensingGuidelines.mw b/Packaging:LicensingGuidelines.mw
index b9c323a..cfdf08a 100644
--- a/Packaging:LicensingGuidelines.mw
+++ b/Packaging:LicensingGuidelines.mw
@@ -128,3 +128,4 @@ License: Python and (BSD with advertising and QPL)
 
    
 
 {{:Licensing/SoftwareTypes}}
+[[Packaging:Licensing guidelines]]

From 9dbce58e9b4c22b35f50d4660692f5f18424cea1 Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Feb 17 2010 19:11:12 +0000
Subject: [PATCH 449/3559] Fix category


---

diff --git a/Packaging:LicensingGuidelines.mw b/Packaging:LicensingGuidelines.mw
index cfdf08a..e7b3a1a 100644
--- a/Packaging:LicensingGuidelines.mw
+++ b/Packaging:LicensingGuidelines.mw
@@ -128,4 +128,4 @@ License: Python and (BSD with advertising and QPL)
 
    
 
 {{:Licensing/SoftwareTypes}}
-[[Packaging:Licensing guidelines]]
+[[Category:Packaging guidelines]]

From 9cde2fd12ae367f60c2c09987a28be86382dbbbc Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Feb 17 2010 19:12:08 +0000
Subject: [PATCH 450/3559] Add categories


---

diff --git a/Packaging:Lisp.mw b/Packaging:Lisp.mw
index c303fd0..f97bafa 100644
--- a/Packaging:Lisp.mw
+++ b/Packaging:Lisp.mw
@@ -132,3 +132,5 @@ All implementations should be modified to load common-lisp-controller's %{_sysco
 = Further reading =
 
 See http://www.cliki.net/common-lisp-controller and http://common-lisp.net/project/asdf/  for more details on common-lisp-controller and asdf.
+
+[[Category:Packaging guidelines]]

From a02467714329b47d387bc50477ee7c3bff9ff6f1 Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Feb 17 2010 19:12:42 +0000
Subject: [PATCH 451/3559] Add categories


---

diff --git a/Packaging:MinGW_Future.mw b/Packaging:MinGW_Future.mw
index 2174afa..d5c749f 100644
--- a/Packaging:MinGW_Future.mw
+++ b/Packaging:MinGW_Future.mw
@@ -307,3 +307,5 @@ and automatically if the spec file includes these lines:
 
 (Note that if __strip and __objdump are not overridden in the specfile
 then this can sometimes cause Windows binaries to be corrupted).
+
+[[Category:Packaging guidelines]]

From b7d657a9c468105ace66e0771200ff6260a1da01 Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Feb 17 2010 19:13:44 +0000
Subject: [PATCH 452/3559] Add category, clean moin syntax


---

diff --git a/Packaging:Mono.mw b/Packaging:Mono.mw
index 4f174b8..6b87ffb 100644
--- a/Packaging:Mono.mw
+++ b/Packaging:Mono.mw
@@ -1,24 +1,3 @@
-
    #!html
-
-
    
-
-= Mono Packaging =
 '''Revision:''' 0.3
    
 '''Last Revised:''' Monday Aug 27, 2007
    
 
@@ -142,3 +121,5 @@ Packagers should avoid redefining _libdir in their spec file.  Redefinition of t
 === Defining target ===
 
 Was done for a brief period when we attempted to package mono apps as noarch.  It was not necessary then (the actual fix was to stop using AC_CANONICAL_* in the configure.ac file) and it is definitely not needed now that we are no longer building noarch mono packages.
+
+[[Category:Packaging guidelines]]

From d2468582fda6d309627085b387a5076e42a872b0 Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Feb 17 2010 19:14:51 +0000
Subject: [PATCH 453/3559] moved [[Packaging:NewMeetingTime]] to [[Archive:Packaging:NewMeetingTime]]: Not a guideline, no longer needed


---

diff --git a/Packaging:NewMeetingTime.mw b/Packaging:NewMeetingTime.mw
new file mode 100644
index 0000000..fa3a63f
--- /dev/null
+++ b/Packaging:NewMeetingTime.mw
@@ -0,0 +1 @@
+#REDIRECT [[Archive:Packaging:NewMeetingTime]]

From 6ad78559354abebded761bcb6bbe65daee21e616 Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Feb 17 2010 19:15:54 +0000
Subject: [PATCH 454/3559] Add category


---

diff --git a/Packaging:OCaml.mw b/Packaging:OCaml.mw
index d534e26..db377a7 100644
--- a/Packaging:OCaml.mw
+++ b/Packaging:OCaml.mw
@@ -1,7 +1,3 @@
-
-= OCaml Packaging Guidelines =
-
 This document seeks to document the conventions and customs surrounding the proper packaging of ocaml modules in Fedora.  It does not intend to cover all situations, but to codify those practices which have served the Fedora ocaml community well.
 
 
@@ -157,4 +153,6 @@ OCaml scripts do not need to be changed (unless resolving the security issue req
 
 = Footnotes =
 
-[[FootNote]
+[[FootNote]]
+
+[[Category:Packaging guidelines]]

From e6a3853be510bf9d2adaf9b33304ce5271a3276a Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Feb 17 2010 19:16:49 +0000
Subject: [PATCH 455/3559] moved [[Packaging:OldJPackagePolicy]] to [[Archive:Packaging:OldJPackagePolicy]]: Moved to archive


---

diff --git a/Packaging:OldJPackagePolicy.mw b/Packaging:OldJPackagePolicy.mw
new file mode 100644
index 0000000..e35adfa
--- /dev/null
+++ b/Packaging:OldJPackagePolicy.mw
@@ -0,0 +1 @@
+#REDIRECT [[Archive:Packaging:OldJPackagePolicy]]

From dc02efad869c63afa201d4fc4cb8e34ec891e118 Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Feb 17 2010 19:18:02 +0000
Subject: [PATCH 456/3559] Add categories


---

diff --git a/Packaging:OpenOffice.orgExtensions.mw b/Packaging:OpenOffice.orgExtensions.mw
index bda3eaa..66b41ba 100644
--- a/Packaging:OpenOffice.orgExtensions.mw
+++ b/Packaging:OpenOffice.orgExtensions.mw
@@ -39,3 +39,4 @@ fi
 %postun
 unopkg list --shared > /dev/null 2>&1 || :
 
    
+[[Category:Packaging guidelines]]

From b55a7eb991214ff6146e957ecc66884647805e7b Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Feb 17 2010 19:18:50 +0000
Subject: [PATCH 457/3559] Add categories


---

diff --git a/Packaging:PHP.mw b/Packaging:PHP.mw
index 81a6c4d..47ccb91 100644
--- a/Packaging:PHP.mw
+++ b/Packaging:PHP.mw
@@ -225,3 +225,6 @@ Or you can generate one; make sure you have the php-pear-PEAR-Command-Packaging 
 
     pear make-rpm-spec Foo.tgz
 
    
+
+[[Category:PHP]]
+[[Category:Packaging guidelines]]

From b4b9e98307955e359410bada2d4821e42ff1df5d Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Feb 17 2010 19:19:17 +0000
Subject: [PATCH 458/3559] Add Category


---

diff --git a/Packaging:PatchUpstreamStatus.mw b/Packaging:PatchUpstreamStatus.mw
index 8a8f48c..0e13465 100644
--- a/Packaging:PatchUpstreamStatus.mw
+++ b/Packaging:PatchUpstreamStatus.mw
@@ -42,3 +42,5 @@ Patch0: jna-jni-path.patch
 = Why upstream? =
 
 Refer [[PackageMaintainers/WhyUpstream|  Why Upstream?]]
+
+[[Category:Packaging guidelines]]

From f76e8e5e18cd432f3df80c6c7846fe145cb59717 Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Feb 17 2010 19:19:48 +0000
Subject: [PATCH 459/3559] Add categories


---

diff --git a/Packaging:Perl.mw b/Packaging:Perl.mw
index 181a365..6461c62 100644
--- a/Packaging:Perl.mw
+++ b/Packaging:Perl.mw
@@ -207,3 +207,4 @@ It's common practice to set the [https://www.redhat.com/mailman/listinfo/fedora-
 For more information, see: [[Perl/cpanspec]] 
 
 [[Category:Perl]]
+[[Category:Packaging guidelines]]

From 2d609caedc24283c9fafdd43f0f520046d2f9383 Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Feb 17 2010 19:21:18 +0000
Subject: [PATCH 460/3559] Add categories


---

diff --git a/Packaging:RPMMacros.mw b/Packaging:RPMMacros.mw
index 13f13d2..7b5ee86 100644
--- a/Packaging:RPMMacros.mw
+++ b/Packaging:RPMMacros.mw
@@ -1,5 +1,4 @@
-
+
 = Valid RPM Macros =
 
 Here are the definitions for some common specfile macros as they are defined on Fedora Core 11 (rpm-4.7.0-1.fc11). For definitions of more macros, examine the output of "rpm --showrc". To see the expanded definition of a macro use the command rpm --eval "%{macro}".  Note that neither command will take into account macros defined inside specfiles, but both will take into account macros defined in your ~/.rpmmacros file and macros defined on the command line.
@@ -60,3 +59,5 @@ Here are macros from other distributions to aid you in package conversion:
 * [[Extras/ReferencePLDRPMMacros| PLD RPM Macros]] 
 * [[Extras/ReferenceMandrakeRPMMacros| Mandrake RPM Macros]] 
 ----
+
+[[Categories:Packaging guidelines]]

From 41c51da301f5c28439153047fc8acc77e68a28c4 Mon Sep 17 00:00:00 2001
From: Tibbs 
Date: Feb 26 2010 19:53:54 +0000
Subject: [PATCH 461/3559] Clean up confusing language about just when sitelib/sitearch macros must be defined.


---

diff --git a/Packaging:Python.mw b/Packaging:Python.mw
index a0aff1a..d2f187a 100644
--- a/Packaging:Python.mw
+++ b/Packaging:Python.mw
@@ -32,7 +32,7 @@ BuildRequires: python3-devel
 A package that has both python2 and python3 files will need to BuildRequire both.
 
 == Macros ==
-In Fedora less than 12 and RHEL less than 5, python2 packages that install python modules need to define python_sitelib or python_sitearch macros that tell where to find the python directory that modules are installed in.  This is not needed in Fedora 13 or with python3 modules as the macros are defined by rpm and the python3-devel package.  To define those conditionally you can use this:
+In Fedora 12 and older and RHEL 5 and older, python2 packages that install python modules need to define python_sitelib or python_sitearch macros that tell where to find the python directory that modules are installed in.  This is not needed in Fedora 13 or with python3 modules as the macros are defined by rpm and the python3-devel package.  To define those conditionally you can use this:
 
 
     %if ! (0%{?fedora} > 12 || 0%{?rhel} > 5)

From a93c76906578d5ef74e9d9002730bcaa99e9a61b Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Mar 01 2010 20:21:57 +0000
Subject: [PATCH 462/3559] Correct BR to python-setuptools


---

diff --git a/Packaging:Python_Eggs.mw b/Packaging:Python_Eggs.mw
index b6a191a..3ed0d29 100644
--- a/Packaging:Python_Eggs.mw
+++ b/Packaging:Python_Eggs.mw
@@ -61,7 +61,7 @@ BuildRequires: python-setuptools-devel
 When we need to provide eggs in a non-setuptools package because another package requires that functionality we can modify our spec files to generate the egg-info:
 
 
    -BuildRequires: python-setuptools-devel
+BuildRequires: python-setuptools
 
 [...] 
 

From 4d089a7b734ff99394b8e6ce2d6b605a96bd5d63 Mon Sep 17 00:00:00 2001
From: Spot 
Date: Mar 03 2010 14:29:43 +0000
Subject: [PATCH 463/3559] Created page with '== Introduction ==  Message Passing Interface (MPI) is an API for parallelization of programs across multiple nodes and has been around since 1994 [http://en.wikipedia.org/wiki/M...'


---

diff --git a/Packaging:MPI.mw b/Packaging:MPI.mw
new file mode 100644
index 0000000..aefa522
--- /dev/null
+++ b/Packaging:MPI.mw
@@ -0,0 +1,236 @@
+== Introduction ==
+
+Message Passing Interface (MPI) is an API for parallelization of programs across multiple nodes and has been around since 1994 [http://en.wikipedia.org/wiki/Message_Passing_Interface]. MPI can also be used for parallelization on SMP machines and is considered very efficient in it too (close to 100% scaling on parallelizable code as compared to ~80% commonly obtained with threads due to unoptimal memory allocation on NUMA machines). Before MPI, about every manufacturer of supercomputers had their own programming language for writing programs; MPI made porting software easy.
+
+There are many MPI implementations available, such as [http://www.lam-mpi.org/ LAM-MPI] (in Fedora, obsoleted by Open MPI), [http://www.open-mpi.org/ Open MPI] (the default MPI compiler in Fedora and the MPI compiler used in RHEL), [http://www.mcs.anl.gov/research/projects/mpi/mpich1/ MPICH] (Not yet in Fedora), [http://www.mcs.anl.gov/research/projects/mpich2/ MPICH2] (in Fedora) and
+[http://mvapich.cse.ohio-state.edu/ MVAPICH1 and MVAPICH2] (are in RHEL but not yet in Fedora).
+
+As some MPI libraries work better on some hardware than others, and some software works best with some MPI library, the selection of the library used must be done in user level, on a session specific basis. Also, people doing high performance computing may want to use more efficient compilers than the default one in Fedora (gcc), so one must be able to have many versions of the MPI compiler each compiled with a different compiler installed at the same time. This must be taken into account when writing spec files.
+
+== Packaging of MPI compilers ==
+
+The MPI compiler RPMs MUST be possible to build with other compilers as well and support simultaneous installation of versions compiled with different compilers (e.g. in addition to a version compiled with {gcc,g++,gfortran} a version compiled with {gcc34,g++34,g77} must be possible to install and use simultaneously as gfortran does not fully support Fortran 77). To do this, the files of MPI compilers MUST be installed in the following directories:
+{|
+! File type !! Placement
+|-
+|Binaries||%{_libdir}/%{name}%{?_cc_name_suffix}/bin
+|-
+|Libraries||%{_libdir}/%{name}%{?_cc_name_suffix}/lib
+|-
+|[[PackagingDrafts/Fortran|Fortran modules]]||%{_fmoddir}/%{name}%{?_cc_name_suffix}/
+|-
+|Architecture specific [[Packaging/Python|Python modules]]||%{python_sitearch}/%{name}%{?_cc_name_suffix}/
+|-
+|Config files||%{_sysconfdir}/%{name}-%{_arch}%{?_cc_name_suffix}/
+|}
+Here %{?_cc_name_suffix} is null when compiled with the normal {gcc,g++,gfortran} combination, but would be e.g. -gcc34 for {gcc34,g++34,g77}.
+
+
+
+As include files and manual pages are bound to overlap between different MPI implementations, they MUST also placed outside normal directories. It is possible that some man pages or include files (either those of the MPI compiler itself or of some MPI software installed in the compiler's directory) are architecture specific (e.g. a definition on a 32-bit arch differs from that on a 64-bit arch), the directories that MUST be used are as follows:
+{|
+!File type !! Placement
+|-
+|Man pages||%{_mandir}/%{name}-%{_arch}%{?_cc_name_suffix}/
+|-
+|Include files||%{_includedir}/%{name}-%{_arch}%{?_cc_name_suffix}/
+|}
+
+
+Architecture and compiler (%{?_cc_name_suffix}) independent parts (except headers which go into -devel) MUST be placed in a -common subpackage that is BuildArch: noarch on >= Fedora 11.
+
+
+The MPI compiler's spec file MUST support the use of the following variables to compile with other compilers
+
    +# We only compile with gcc, but other people may want other compilers.
+# Set the compiler here.
+%global opt_cc gcc
+# Optional CFLAGS to use with the specific compiler...gcc doesn't need any,
+# so uncomment and define to use
+#global opt_cflags
+%global opt_cxx g++
+#global opt_cxxflags
+%global opt_f77 gfortran
+#global opt_fflags
+%global opt_fc gfortran
+#global opt_fcflags
+
+# Optional name suffix to use...we leave it off when compiling with gcc, but
+# for other compiled versions to install side by side, it will need a
+# suffix in order to keep the names from conflicting.
+#global cc_name_suffix -gcc
+
    
+
+The runtime of MPI compilers (mpirun, the libraries, the manuals etc) MUST be packaged into %{name}, and the development headers and libraries into %{name}-devel.
+
+As the compiler is installed outside PATH, one needs to load the relevant variables before being able to use the compiler or run MPI programs. This is done using [[PackagingDrafts/EnvironmentModules|environment modules]].
+
+The module file MUST prepend the MPI bindir %{_bindir}/%{name}-%{_arch}%{?_opt_cc_suffix} into the users PATH, set LD_LIBRARY_PATH to %{_libdir}/%{name}%{?_opt_cc_suffix}/ and PYTHONPATH to %{python_sitearch}/%{name}%{?_cc_name_suffix}/. The module file MUST also set some helper variables (primarily for use in spec files):
+{|
+! Variable !! Value !! Explanation
+|-
+|MPI_BIN||%{_libdir}/%{name}%{?_opt_cc_suffix}/bin||Binaries compiled against the MPI stack
+|-
+|MPI_SYSCONFIG||%{_sysconfdir}/%{name}-%{_arch}%{?opt_cc_suffix}/||MPI stack specific configuration files
+|-
+|MPI_FORTRAN_MOD_DIR||%{_fmoddir}/%{name}%{?_opt_cc_suffix}/||MPI stack specific Fortran module directory
+|-
+|MPI_INCLUDE||%{_includedir}/%{name}-%{_arch}%{?_opt_cc_suffix}/||MPI stack specific headers
+|-
+|MPI_LIB||%{_libdir}/%{name}%{?_opt_cc_suffix}/lib||Libraries compiled against the MPI stack
+|-
+|MPI_MAN||%{_mandir}/%{name}-%{_arch}%{?_opt_cc_suffix}/||MPI stack specific man pages
+|-
+|MPI_PYTHON_SITEARCH||%{python_sitearch}/%{name}%{?_cc_name_suffix}/||MPI stack specific Python modules
+|-
+|MPI_COMPILER||%{name}-%{_arch}%{?_cc_name_suffix}||Name of compiler package, for use in e.g. spec files
+|-
+|MPI_SUFFIX||%{?_cc_name_suffix}_%{name}||The suffix used for programs compiled against the MPI stack
+|}
+As these directories may be used by software using the MPI stack, the MPI runtime package MUST own all of them.
+
+MUST: By default, NO files are placed in /etc/ld.so.conf.d. If the packager wishes to provide alternatives support, it MUST be placed in a subpackage along with the ld.so.conf.d file so that alternatives support does not need to be installed if not wished for.
+
+The MPI compiler package MUST provide an RPM macro that makes loading and unloading the support easy in spec files, e.g. by placing the following in /etc/rpm/macros.openmpi
+
    +%_openmpi_load \
+ . /etc/profile.d/modules.sh; \
+ module load openmpi-%{_arch}; \
+ export CFLAGS="$CFLAGS %{optflags}";
+%_openmpi_unload \
+ . /etc/profile.d/modules.sh; \
+ module unload openmpi-%{_arch};
+
    
+loading and unloading the compiler in spec files is as easy as %{_openmpi_load} and %{_openmpi_unload}.
+
+If the environment module sets compiler flags such as CFLAGS (thus overriding the ones exported in %configure, the RPM macro MUST make them use the Fedora optimization flags %{optflags} once again (as in the example above in which the openmpi-%{_arch} module sets CFLAGS).
+
+== Packaging of MPI software ==
+
+Software that supports MPI MUST be packaged also in serial mode [i.e. no MPI], if it is supported by upstream. (for instance: foo).
+
+If possible, the packager MUST package versions for each MPI compiler in Fedora (e.g. if something can only be built with mpich2 and mvapich2, then lam and openmpi packages do not need to be made).
+
+MPI implementation specific files MUST be installed in the directories used by the used MPI compiler ($MPI_BIN, $MPI_LIB and so on). 
+
+The binaries MUST be suffixed with $MPI_SUFFIX (e.g. _openmpi for Open MPI, _mpich2 for MPICH2 and _lam for LAM/MPI). This is for two reasons: the serial version of the program can still be run when an MPI module is loaded and the user is always aware of the version s/he is running. This does not need to hurt the use of shell scripts:
+
    +# Which MPI implementation do we use?
+
+#module load lam-i386
+#module load openmpi-i386
+module load mpich2-i386
+
+# Run preprocessor
+foo -preprocess < foo.in
+# Run calculation
+mpirun -np 4 foo${MPI_SUFFIX}
+# Run some processing
+mpirun -np 4 bar${MPI_SUFFIX} -process
+# Collect results
+bar -collect
+
    
+
+The MPI enabled bits MUST be placed in a subpackage with the suffix denoting the MPI compiler used (for instance: foo-openmpi for Open MPI [the traditional MPI compiler in Fedora] or foo-mpich2 for MPICH2). For directory ownership and to guarantee the pickup of the correct MPI runtime, the MPI subpackages MUST require the correct MPI compiler's runtime package.
+
+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, library configuration (in /etc/ld.so.conf.d) MUST NOT be made.
+
+In case the headers are the same regardless of the compilation method and architecture (e.g. 32-bit serial, 64-bit Open MPI, MPICH2), they MUST be split into a separate -headers subpackage (e.g. 'foo-headers'). Fortran modules are architecture specific and as such are placed in the (MPI implementation specific) -devel package (foo-devel for the serial version and foo-openmpi-devel for the Open MPI version).
+
+Each MPI build MUST have a separate -devel subpackage (e.g. foo-mpich2-devel) that includes the development libraries and Requires: %{name}-headers if such a package exists. The goal is to be able to install and develop using e.g. 'foo-mpi-devel' without needing to install e.g. mpich2 and lam or the serial version of the package.
+
+Files must be shared between packages as much as possible. Compiler independent parts, such as data files in %{_datadir}/%{name} and man files MUST be put into a -common subpackage that is required by all of the binary packages (the serial package and all of the MPI packages).
+
+=== A sample spec file ===
+
    +# Define a macro for calling ../configure instead of ./configure
+%global dconfigure %(printf %%s '%configure' | sed 's!\./configure!../configure!g')
+
+Name: foo
+Requires: %{name}-common = %{version}-%{release}
+
+%package common
+
+%package lam
+BuildRequires: lam-devel
+# Require explicitly for dir ownership and to guarantee the pickup of the right runtime
+Requires: lam
+Requires: %{name}-common = %{version}-%{release}
+
+%package mpi
+BuildRequires: openmpi-devel
+# Require explicitly for dir ownership and to guarantee the pickup of the right runtime
+Requires: openmpi
+Requires: %{name}-common = %{version}-%{release}
+
+%package mpich2
+BuildRequires: mpich2-devel
+# Require explicitly for dir ownership and to guarantee the pickup of the right runtime
+Requires: mpich2
+Requires: %{name}-common = %{version}-%{release}
+
+%build
+# Have to do off-root builds to be able to build many versions at once
+
+# To avoid replicated code define a build macro
+%define dobuild() \
+mkdir $MPI_COMPILER; \
+cd $MPI_COMPILER; \
+%dconfigure --program-suffix=$MPI_SUFFIX ;\
+make %{?_smp_mflags} ; \
+cd ..
+
+# Build serial version, dummy arguments
+MPI_COMPILER=serial MPI_SUFFIX= %dobuild
+
+# Build parallel versions: set compiler variables to MPI wrappers
+export CC=mpicc
+export CXX=mpicxx
+export FC=mpif90
+export F77=mpif77
+
+# Build LAM version
+%{_lam_load}
+%dobuild
+%{_lam_unload}
+
+# Build OpenMPI version
+%{_openmpi_load}
+%dobuild
+%{_openmpi_unload}
+
+# Build mpich2 version
+%{_mpich2_load}
+%dobuild
+%{_mpich2_unload}
+
+%install
+# Install serial version
+make -C serial install DESTDIR=%{buildroot} INSTALL="install -p" CPPROG="cp -p"
+
+# Install LAM version
+%{_lam_load}
+make -C $MPI_COMPILER install DESTDIR=%{buildroot} INSTALL="install -p" CPPROG="cp -p"
+%{_lam_unload}
+
+# Install OpenMPI version
+%{_openmpi_load}
+make -C $MPI_COMPILER install DESTDIR=%{buildroot} INSTALL="install -p" CPPROG="cp -p"
+%{_openmpi_unload}
+
+# Install MPICH2 version
+%{_mpich2_load}
+make -C $MPI_COMPILER install DESTDIR=%{buildroot} INSTALL="install -p" CPPROG="cp -p"
+%{_mpich2_unload}
+
+
+%files # All the serial (normal) binaries
+
+%files common # All files shared between the serial and different MPI versions
+
+%files lam # All lam linked files
+
+%files openmpi # All openmpi linked files
+
+%files mpich2 # All mpich2 linked files
+
    

From 24699191a6cc7f8a6797a8ab017bbde4a191103c Mon Sep 17 00:00:00 2001
From: Spot 
Date: Mar 03 2010 14:30:41 +0000
Subject: [PATCH 464/3559] /* Application Specific Guidelines */


---

diff --git a/Packaging:Guidelines.mw b/Packaging:Guidelines.mw
index 6cf2999..81f77db 100644
--- a/Packaging:Guidelines.mw
+++ b/Packaging:Guidelines.mw
@@ -1071,6 +1071,10 @@ Guidelines for lisp packages: [[Packaging:Lisp]]
 === Mono ===
 Guidelines for Mono packages: [[Packaging:Mono]] 
 
+{{Anchor|MPIGuidelines}}
+== MPI ==
+Guidelines for MPI packages: [[Packaging:MPI]]
+
 {{Anchor|OCamlGuidelines}}
 === OCaml ===
 Guidelines for OCaml packages: [[Packaging:OCaml]] 

From 061fc2b24a8fd441b517be1f954ec406dfa4f082 Mon Sep 17 00:00:00 2001
From: Spot 
Date: Mar 03 2010 14:30:56 +0000
Subject: [PATCH 465/3559] *Empty MediaWiki Message*


---

diff --git a/Packaging:GuidelinesTodo.mw b/Packaging:GuidelinesTodo.mw
index 34f86bb..e4698b9 100644
--- a/Packaging:GuidelinesTodo.mw
+++ b/Packaging:GuidelinesTodo.mw
@@ -39,7 +39,7 @@ Status should be one of:
 |-
 |announce||Man pages|| FESCo, varekova|| ||[https://fedorahosted.org/fesco/ticket/291|FESCo ticket] [[Packaging:Guidelines#Man_pages Guideline]]
 |-
-|writeup||MPI packaging||[[User:jussilehtola|Jussi Lehtola]]||2009-08-12||[[PackagingDrafts/MPI]]
+|announce||MPI packaging||[[User:jussilehtola|Jussi Lehtola]]||2009-08-12||[[PackagingDrafts/MPI]]
 |-
 |writeup||Environment modules||[[User:jussilehtola|Jussi Lehtola]]||2009-08-12||[[PackagingDrafts/EnvironmentModules]]
 |-

From 287bc4395b44b9a3ee74278dfa1b6b2794cebe1f Mon Sep 17 00:00:00 2001
From: Spot 
Date: Mar 03 2010 14:32:30 +0000
Subject: [PATCH 466/3559] /* MPI */


---

diff --git a/Packaging:Guidelines.mw b/Packaging:Guidelines.mw
index 81f77db..5444c55 100644
--- a/Packaging:Guidelines.mw
+++ b/Packaging:Guidelines.mw
@@ -1072,7 +1072,7 @@ Guidelines for lisp packages: [[Packaging:Lisp]]
 Guidelines for Mono packages: [[Packaging:Mono]] 
 
 {{Anchor|MPIGuidelines}}
-== MPI ==
+=== MPI ===
 Guidelines for MPI packages: [[Packaging:MPI]]
 
 {{Anchor|OCamlGuidelines}}

From 5bca59e1c4746a110067879a5241170eb5a9f602 Mon Sep 17 00:00:00 2001
From: Spot 
Date: Mar 03 2010 14:40:21 +0000
Subject: [PATCH 467/3559] Created page with '== Introduction ==  When one has multiple programs serving the same purpose (for instance SMTP servers such as sendmail, exim and postfix; or print servers such as lprng and cups...'


---

diff --git a/Packaging:EnvironmentModules.mw b/Packaging:EnvironmentModules.mw
new file mode 100644
index 0000000..5931480
--- /dev/null
+++ b/Packaging:EnvironmentModules.mw
@@ -0,0 +1,44 @@
+== Introduction ==
+
+When one has multiple programs serving the same purpose (for instance SMTP servers such as sendmail, exim and postfix; or print servers such as lprng and cups), it is usual to wrap these using alternatives. Alternatives provides a clean way to have many types of software serving the same purpose installed at the same time and have the commands such as mail and lpr point to the wanted versions.
+
+
+However, when there are multiple variants that each serve the needs of some user and thus must be available simultaneously by users, the alternatives system simply isn't enough since it is system-wide. This has been reality on supercomputers and clusters for eons, and a solution has been developed: [http://modules.sourceforge.net/ environment modules].
+
+== Using environment modules ==
+
+To see what modules are available, run $ module avail.
+To load a module run e.g. $ module load openmpi-i386.
+To unload a module, run e.g. $module unload openmpi-i386.
+
+The upstream documentation for the module command is available [http://modules.sourceforge.net/man/module1.html here].
+
+== Creating environment modules ==
+
+{{admon/important|Packaging note|When creating RPMs containing module files, be sure to Requires: environment-modules for directory ownership and usability.}}
+
+To create an environment module, place a module file into /etc/modulefiles/. The directory /usr/share/Modules/modulefiles is to be used only for internal modules of environment-modules. Besides this, installing a module file into an arbitrary directory currently makes module unloading not working (see [https://bugzilla.redhat.com/show_bug.cgi?id=513583 BZ#513583])
+
+{{admon/warning|Multilib packages|Suffix the module file name with the architecture to prevent clashes from multilib/multiarch packages.}}
+
+The module files are plain text with a tcl syntax, for instance an environment module for 32-bit OpenMPI openmpi-i386:
+
+
    +#%Module 1.0
+# 
+# OpenMPI module for use with 'environment-modules' package:
+# 
+prepend-path            PATH            /usr/lib/openmpi/bin
+prepend-path            LD_LIBRARY_PATH /usr/lib/openmpi/lib
+setenv                  MPI_BIN         /usr/lib/openmpi/bin
+setenv                  MPI_LIB         /usr/lib/openmpi/lib
+
    
+
+The module file begins with the magic cookie #%Module , where  is the version of the module file used. The current version is 1.0.
+
+The above commands prepends the path with the bindir of the 32-bit OpenMPI (compiled with GCC) and adds the relevant library path. Then it sets five environment variables.
+
+It is also possible to set CFLAGS and LDFLAGS with the above manner, but in the case of MPI compilers it is not necessary since the compilers are invoked with the mpicc, mpicxx, mpif77 and mpif90 wrappers that already contain the necessary include and library paths. Also, in the case of development packages an override of CFLAGS and/or LDFLAGS is not sane, 
+as it may cause trouble in building RPMs as it overrides %{optflags}.
+
+The upstream documentation for module files is available [http://modules.sourceforge.net/man/modulefile4.html here].

From d209647da33348aefd259b04d9f19633a0c3366e Mon Sep 17 00:00:00 2001
From: Spot 
Date: Mar 03 2010 14:43:35 +0000
Subject: [PATCH 468/3559] Created page with '= Alternatives =  == What are alternatives == Alternatives provide means for parallel installation of packages which provide the same functionality by maintaining sets of symlink...'


---

diff --git a/Packaging:Alternatives.mw b/Packaging:Alternatives.mw
new file mode 100644
index 0000000..cecc266
--- /dev/null
+++ b/Packaging:Alternatives.mw
@@ -0,0 +1,124 @@
+= Alternatives =
+
+== What are alternatives ==
+Alternatives provide means for parallel installation of packages which provide the same functionality by maintaining sets of symlinks (one per package) pointing to alternativized files like this:
+/path/original-file -> /etc/alternatives/packagename-original-file -> /path/original-file.suffix
+For more information, see update-alternatives(8) manpage.
+
+== Recommended usage ==
+Alternatives can be used to allow parallel installation of software that can be used as a drop-in replacement and functions with sufficient similarity that users and other programs would, within reason, not need to know which variant is currently installed (for example: the various MTAs which all provide /usr/sbin/sendmail). Selection of which of the parallel-installed packages to use for a given alternativized file can only be done system-wide by a root-level user.
+Alternatives are not recommended to facilitate parallel installation of software whose selection should be done by users (for example: the various MPI environments).
+
+== How to use alternatives ==
+If a package is using alternatives, the files which would otherwise conflict must be installed with an appropriate suffix (for example: %{_sbindir}/sendmail.postfix instead of %{_sbindir}/sendmail), the original locations must be touched (for example: touch %{_sbindir}/sendmail), the links set up by alternatives must be listed as %ghost in the file list and proper Requires: must be added, like in the examples below.
+
+Putting the alternativized files in the file list ensures that they are owned by respective packages, which means that commands like:
+* rpm -qf /usr/bin/foo
+* yum install /usr/bin/foo
+* repoquery --whatprovides /usr/bin/foo
+all work properly. Using %ghost for this purpose allows using globs and generated file lists.
+
+== Examples ==
+
+Example from antlr.spec:
+
    +Requires(post): %{_sbindir}/update-alternatives
+Requires(postun): %{_sbindir}/update-alternatives
+...
+%install
+...
+touch %{buildroot}%{_bindir}/antlr
+
+%post
+%{_sbindir}/update-alternatives --install %{_bindir}/antlr \
+  %{name} %{_bindir}/antlr-java 10
+
+%postun
+if [ $1 -eq 0 ] ; then
+  %{_sbindir}/update-alternatives --remove %{name} %{_bindir}/antlr-java
+fi
+...
+%files
+...
+%ghost %{_bindir}/antlr
+%{_bindir}/antlr-java
+
    
+
+And a more complex example of alternatives invocation from sendmail.spec, slightly edited:
+
    +Requires(post): %{_sbindir}/update-alternatives
+Requires(postun): %{_sbindir}/update-alternatives
+Requires(preun): %{_sbindir}/update-alternatives
+...
+%install
+...
+# rename files for alternative usage
+mv %{buildroot}%{_sbindir}/sendmail %{buildroot}%{_sbindir}/sendmail.sendmail
+touch %{buildroot}%{_sbindir}/sendmail
+for i in mailq newaliases rmail; do
+	mv %{buildroot}%{_bindir}/$i %{buildroot}%{_bindir}/$i.sendmail
+	touch %{buildroot}%{_bindir}/$i
+done
+mv %{buildroot}%{_mandir}/man1/mailq.1 %{buildroot}%{_mandir}/man1/mailq.sendmail.1
+touch %{buildroot}%{_mandir}/man1/mailq.1
+mv %{buildroot}%{_mandir}/man1/newaliases.1 %{buildroot}%{_mandir}/man1/newaliases.sendmail.1
+touch %{buildroot}%{_mandir}/man1/newaliases.1
+mv %{buildroot}%{_mandir}/man5/aliases.5 %{buildroot}%{_mandir}/man5/aliases.sendmail.5
+touch %{buildroot}%{_mandir}/man5/aliases.5
+mv %{buildroot}%{_mandir}/man8/sendmail.8 %{buildroot}%{_mandir}/man8/sendmail.sendmail.8
+touch %{buildroot}%{_mandir}/man8/sendmail.8
+
+%postun
+if [ "$1" -ge "1" ]; then
+	if [ "`readlink %{_sysconfdir}/alternatives/mta`" == "%{_sbindir}/sendmail.sendmail" ]; then
+		%{_sbindir}/alternatives --set mta %{_sbindir}/sendmail.sendmail
+	fi
+fi
+
+%post
+# Set up the alternatives files for MTAs.
+%{_sbindir}/update-alternatives --install %{_sbindir}/sendmail mta %{_sbindir}/sendmail.sendmail 90 \
+	--slave %{_bindir}/mailq mta-mailq %{_bindir}/mailq.sendmail \
+	--slave %{_bindir}/newaliases mta-newaliases %{_bindir}/newaliases.sendmail \
+	--slave %{_bindir}/rmail mta-rmail %{_bindir}/rmail.sendmail \
+	--slave /usr/lib/sendmail mta-sendmail /usr/lib/sendmail.sendmail \
+	--slave %{_sysconfdir}/pam.d/smtp mta-pam %{_sysconfdir}/pam.d/smtp.sendmail \
+	--slave %{_mandir}/man8/sendmail.8.gz mta-sendmailman %{_mandir}/man8/sendmail.sendmail.8.gz \
+	--slave %{_mandir}/man1/mailq.1.gz mta-mailqman %{_mandir}/man1/mailq.sendmail.1.gz \
+	--slave %{_mandir}/man1/newaliases.1.gz mta-newaliasesman %{_mandir}/man1/newaliases.sendmail.1.gz \
+	--slave %{_mandir}/man5/aliases.5.gz mta-aliasesman %{_mandir}/man5/aliases.sendmail.5.gz \
+	--initscript sendmail
+...
+
+%preun
+if [ $1 = 0 ]; then
+	%{_sbindir}/update-alternatives --remove mta %{_sbindir}/sendmail.sendmail
+fi
+...
+
+%files
+...
+%ghost %{_sbindir}/sendmail
+%ghost %{_bindir}/mailq
+%ghost %{_bindir}/newaliases
+%ghost %{_bindir}/rmail
+%ghost /usr/lib/sendmail
+%ghost %{_sysconfdir}/pam.d/smtp
+%ghost %{_mandir}/man8/sendmail.8.gz
+%ghost %{_mandir}/man1/mailq.1.gz
+%ghost %{_mandir}/man1/newaliases.1.gz
+%ghost %{_mandir}/man5/aliases.5.gz
+
+%{_sbindir}/sendmail.sendmail
+%{_bindir}/mailq.sendmail
+%{_bindir}/newaliases.sendmail
+%{_bindir}/rmail.sendmail
+/usr/lib/sendmail.sendmail
+%config(noreplace) %{_sysconfdir}/pam.d/smtp.sendmail
+%{_mandir}/man8/sendmail.sendmail.8.gz
+%{_mandir}/man1/mailq.sendmail.1.gz
+%{_mandir}/man1/newaliases.sendmail.1.gz
+%{_mandir}/man5/aliases.sendmail.5.gz
+
+%attr(0755,root,root) %{_initrddir}/sendmail
+
    

From 79d2dc57618c329cdcf84534de701f6e3d643296 Mon Sep 17 00:00:00 2001
From: Spot 
Date: Mar 03 2010 14:44:05 +0000
Subject: [PATCH 469/3559] *Empty MediaWiki Message*


---

diff --git a/Packaging:EnvironmentModules.mw b/Packaging:EnvironmentModules.mw
index 5931480..490306e 100644
--- a/Packaging:EnvironmentModules.mw
+++ b/Packaging:EnvironmentModules.mw
@@ -1,3 +1,5 @@
+= Environment Modules =
+
 == Introduction ==
 
 When one has multiple programs serving the same purpose (for instance SMTP servers such as sendmail, exim and postfix; or print servers such as lprng and cups), it is usual to wrap these using alternatives. Alternatives provides a clean way to have many types of software serving the same purpose installed at the same time and have the commands such as mail and lpr point to the wanted versions.

From ed4afb44359f274636a916dcb7810e4d7673c862 Mon Sep 17 00:00:00 2001
From: Spot 
Date: Mar 03 2010 14:44:13 +0000
Subject: [PATCH 470/3559] *Empty MediaWiki Message*


---

diff --git a/Packaging:EnvironmentModules.mw b/Packaging:EnvironmentModules.mw
index 490306e..cc59380 100644
--- a/Packaging:EnvironmentModules.mw
+++ b/Packaging:EnvironmentModules.mw
@@ -4,7 +4,6 @@
 
 When one has multiple programs serving the same purpose (for instance SMTP servers such as sendmail, exim and postfix; or print servers such as lprng and cups), it is usual to wrap these using alternatives. Alternatives provides a clean way to have many types of software serving the same purpose installed at the same time and have the commands such as mail and lpr point to the wanted versions.
 
-
 However, when there are multiple variants that each serve the needs of some user and thus must be available simultaneously by users, the alternatives system simply isn't enough since it is system-wide. This has been reality on supercomputers and clusters for eons, and a solution has been developed: [http://modules.sourceforge.net/ environment modules].
 
 == Using environment modules ==

From 445ed940dd64a5eb074193bbd54051d895000e18 Mon Sep 17 00:00:00 2001
From: Spot 
Date: Mar 03 2010 14:44:44 +0000
Subject: [PATCH 471/3559] *Empty MediaWiki Message*


---

diff --git a/Packaging:GuidelinesTodo.mw b/Packaging:GuidelinesTodo.mw
index e4698b9..c42cf54 100644
--- a/Packaging:GuidelinesTodo.mw
+++ b/Packaging:GuidelinesTodo.mw
@@ -41,11 +41,11 @@ Status should be one of:
 |-
 |announce||MPI packaging||[[User:jussilehtola|Jussi Lehtola]]||2009-08-12||[[PackagingDrafts/MPI]]
 |-
-|writeup||Environment modules||[[User:jussilehtola|Jussi Lehtola]]||2009-08-12||[[PackagingDrafts/EnvironmentModules]]
+|announce||Environment modules||[[User:jussilehtola|Jussi Lehtola]]||2009-08-12||[[PackagingDrafts/EnvironmentModules]]
 |-
 |writeup||Filtering auto-provides||cweyl||2009-07-28||[[PackagingDrafts/AutoProvidesAndRequiresFiltering]]
 |-
-|writeup||Using Alternatives||[[User:Rathann|rathann]]||2009-04-14||[[PackagingDrafts/UsingAlternatives]]
+|announce||Using Alternatives||[[User:Rathann|rathann]]||2009-04-14||[[PackagingDrafts/UsingAlternatives]]
 |-
 |writeup||GConf scriptlets||abadger1999||2009-05-12||[[GConf Scriptlets (draft)]] Improve GConf scriplet handling.
 |-

From f2e2834951923ca425346e6be2f9a6d374de6911 Mon Sep 17 00:00:00 2001
From: Spot 
Date: Mar 03 2010 14:45:03 +0000
Subject: [PATCH 472/3559] *Empty MediaWiki Message*


---

diff --git a/Packaging:Guidelines.mw b/Packaging:Guidelines.mw
index 5444c55..290c149 100644
--- a/Packaging:Guidelines.mw
+++ b/Packaging:Guidelines.mw
@@ -916,6 +916,16 @@ Web applications packaged in Fedora should put their content into /usr/share/%{n
 
 Whenever possible, Fedora packages should avoid conflicting with each other. Unfortunately, this is not always possible. For full details on Fedora's Conflicts policy, see: [[Packaging:Conflicts]] .
 
+Tools such as Alternatives and Environment Modules can also help prevent package conflicts.
+
+=== Alternatives ===
+
+The "alternatives" tool provides a means for parallel installation of packages which provide the same functionality by maintaining sets of symlinks. For full details on how to properly use alternatives, see [[Packaging:Alternatives]].
+
+=== Environment Modules ===
+
+When there are multiple variants that each serve the needs of some user and thus must be available simultaneously by users, the alternatives system simply isn't enough since it is system-wide. In such situations, use of Environment Modules can avoid conflicts. For full details on how to properly use Environment Modules, see [[Packaging:Environment Modules]].
+
 == No External Kernel Modules ==
 {{:Packaging:KernelModules}}
 

From 8c13c1d7bf845fd393c6dcab8a7e7413269551bc Mon Sep 17 00:00:00 2001
From: Spot 
Date: Mar 03 2010 14:58:58 +0000
Subject: [PATCH 474/3559] *Empty MediaWiki Message*


---

diff --git a/Packaging:GuidelinesTodo.mw b/Packaging:GuidelinesTodo.mw
index c42cf54..977d072 100644
--- a/Packaging:GuidelinesTodo.mw
+++ b/Packaging:GuidelinesTodo.mw
@@ -43,7 +43,7 @@ Status should be one of:
 |-
 |announce||Environment modules||[[User:jussilehtola|Jussi Lehtola]]||2009-08-12||[[PackagingDrafts/EnvironmentModules]]
 |-
-|writeup||Filtering auto-provides||cweyl||2009-07-28||[[PackagingDrafts/AutoProvidesAndRequiresFiltering]]
+|announce||Filtering auto-provides||cweyl||2009-07-28||[[Packaging/AutoProvidesAndRequiresFiltering]]
 |-
 |announce||Using Alternatives||[[User:Rathann|rathann]]||2009-04-14||[[PackagingDrafts/UsingAlternatives]]
 |-

From 21ac07337e59b12fdfab2a596ae09fec88029097 Mon Sep 17 00:00:00 2001
From: Spot 
Date: Mar 03 2010 14:59:32 +0000
Subject: [PATCH 475/3559] *Empty MediaWiki Message*


---

diff --git a/Packaging:GuidelinesTodo.mw b/Packaging:GuidelinesTodo.mw
index 977d072..b8ac8e6 100644
--- a/Packaging:GuidelinesTodo.mw
+++ b/Packaging:GuidelinesTodo.mw
@@ -43,7 +43,7 @@ Status should be one of:
 |-
 |announce||Environment modules||[[User:jussilehtola|Jussi Lehtola]]||2009-08-12||[[PackagingDrafts/EnvironmentModules]]
 |-
-|announce||Filtering auto-provides||cweyl||2009-07-28||[[Packaging/AutoProvidesAndRequiresFiltering]]
+|announce||Filtering auto-provides||cweyl||2009-07-28||[[Packaging:AutoProvidesAndRequiresFiltering]]
 |-
 |announce||Using Alternatives||[[User:Rathann|rathann]]||2009-04-14||[[PackagingDrafts/UsingAlternatives]]
 |-

From 333f21a707d6b6fe2d2f1e502584450318bede04 Mon Sep 17 00:00:00 2001
From: Spot 
Date: Mar 03 2010 15:37:36 +0000
Subject: [PATCH 476/3559] /* GConf */


---

diff --git a/Packaging:Scriptlets.mw b/Packaging:Scriptlets.mw
index a2b5264..0375745 100644
--- a/Packaging:Scriptlets.mw
+++ b/Packaging:Scriptlets.mw
@@ -112,35 +112,62 @@ Requires(post): GConf2
 Requires(preun): GConf2
 ...
 %pre
-if [ "$1" -gt 1 ] ; then
-export GCONF_CONFIG_SOURCE=`gconftool-2 --get-default-source`
-gconftool-2 --makefile-uninstall-rule \
-%{_sysconfdir}/gconf/schemas/[NAME] .schemas >/dev/null || :
-fi
+%gconf_schema_prepare schema1 schema2
+%gconf_schema_obsolete schema3
+
    
+In this section we uninstall old schemas during upgrade using one of two macros.
+
+%gconf_schema_prepare is used for any current GConf schemas.  It
+takes care of uninstalling previous versions of schemas that this package
+currently installs.  It takes a space separated list of schema names without
+path or suffix that the package installs.  Note that behind the scenes, this
+macro works with the %post scriptlet to only process GConf schemas
+if changes have occurred.
+
+%gconf_schema_obsolete is used for schemas that this package
+previously provided but no longer does.  It will deregister the old schema if
+it is present on the system.  Nothing will happen if the old schema is not
+present.  This macro takes a space separated list of schemas to uninstall.  One
+example of using this might be if the package changed names.  If the old schema
+was named foo.schemas and the new schema is named
+foobar.schemas you'd use:
+
+
    +%gconf_schema_prepare foobar
+%gconf_schema_obsolete foo
 
    
-In this section we uninstall the old schemas when we upgrade.  The way we do this is first to get information about where gconf stores its values via the gconftool-2 --get-default-source line.  Then we uninstall the schema from that source.  If the package could be upgrading a package which had another name for the schema at one time, then we uncomment the lines to uninstall those as well.
 
-The next section is for installing the new schema:
+The next section does the processing of the newly installed schemas:
 
     %post
-export GCONF_CONFIG_SOURCE=`gconftool-2 --get-default-source`
-gconftool-2 --makefile-install-rule \
-%{_sysconfdir}/gconf/schemas/[NAME] .schemas > /dev/null || :
+%gconf_schema_upgrade schema1 schema2
 
    
-Here we do the same things as in the %pre section for upgrading except the gconftool-2 switch used is --makefile-install-rule to install the new schemas instead of the uninstall-rule to remove the old schemas.
 
-The last section deals with deleting the schemas on package removal:
+%gconf_schema_upgrade takes a space separated list of schemas that
+the package currently installs just like %gconf_schema_prepare.
+Behind the scenes, it does the actual work of registering the new version of
+the schema and deregistering the old version.
+
+The last section is for unregistering schemas when a package is removed:
 
     %preun
-if [ "$1" -eq 0 ] ; then
-export GCONF_CONFIG_SOURCE=`gconftool-2 --get-default-source`
-gconftool-2 --makefile-uninstall-rule \
-%{_sysconfdir}/gconf/schemas/[NAME] .schemas > /dev/null || :
-fi
+%gconf_schema_remove schema1 schema2
+
    
+When a package is upgraded rpm invokes the %pre scriptlet to register
+and deregister the schemas.  When a package is uninstalled, the
+%preun scriptlet is used.  %gconf_schema_remove takes
+the list of schemas that this package currently provides and removes them for us.
+
+=== Rebuilds for changes to macros ===
+When macros change, packages that make use of them have to be rebuilt to
+pick up the changes.  This repoquery command can be used to find the schema
+including packages to rebuild:
+
    +repoquery --whatprovides "/etc/gconf/schemas/*" |sort |uniq |wc -l
 
    
-This snippet is nearly the same as the one for upgrading.  Why can't we just combine this portion with the  %pre portion?  The answer is that we want to delete any old versions of the schema during an upgrade.  But this has to happen before we install the new version (in the %post script) otherwise we end up removing the schema that the upgrading package installs.  However, if it really is a removal that will leave no other instances of this package on the system, we have to clean up the schema before deleting it.
 
-'''Note:''' RHEL4 suffers from GConf [https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173869 Bug #173869] .  If you are building for EPEL-4, you need to add  killall -HUP gconfd-2 > /dev/null || :  after the gconftool-2 calls in all the scriptlets.
+=== EPEL Notes ===
+EPEL does not have macros.gconf2, so please follow the instructions found here: [[Packaging:EPEL#GConf2]]
 
 {{Anchor|info}}
 

From 19c822fe5786aad11f781610e8518b19619fca5c Mon Sep 17 00:00:00 2001
From: Spot 
Date: Mar 03 2010 15:39:11 +0000
Subject: [PATCH 477/3559] /* Requires */


---

diff --git a/Packaging:Guidelines.mw b/Packaging:Guidelines.mw
index 290c149..32b8acd 100644
--- a/Packaging:Guidelines.mw
+++ b/Packaging:Guidelines.mw
@@ -277,8 +277,11 @@ Exemplary rationale for a versioned explicit dependency:
 Packagers should revisit an explicit dependency as appropriate to avoid 
 it becoming inaccurate and superfluous.  For instance in the example above, when no current Fedora release shipped with libfubar < 1.2.3-7, it is no longer necessary to list the explicit, versioned requirement.
 
+=== Filtering Auto-Generated Requires ===
+RPM attempts to auto-generate Requires (and Provides) at build time, but in some situations, the auto-generated Requires/Provides are not correct or not wanted. For more details on how to filter out auto-generated Requires or Provides, please see: [[Packaging:AutoProvidesAndRequiresFiltering]]
 
 {{Anchor|BuildRequires}}
+
 == BuildRequires ==
 
 In package development and testing, please verify that your package is not missing any necessary build dependencies. Having proper build requirements saves the time of all developers and testers as well as autobuild systems because they will not need to search for missing build requirements manually. It is also a safety feature that prevents builds with that would not otherwise fail, but would be missing crucial features. For example, a graphical application may exclude PNG support after its '''configure''' script detects that libpng is not installed.

From 7316f2264d14487e44cc6f725703eea9223bf186 Mon Sep 17 00:00:00 2001
From: Spot 
Date: Mar 03 2010 15:39:34 +0000
Subject: [PATCH 478/3559] /* EPEL Notes */


---

diff --git a/Packaging:Scriptlets.mw b/Packaging:Scriptlets.mw
index 0375745..d81e318 100644
--- a/Packaging:Scriptlets.mw
+++ b/Packaging:Scriptlets.mw
@@ -167,7 +167,7 @@ repoquery --whatprovides "/etc/gconf/schemas/*" |sort |uniq |wc -l
 
    
 
 === EPEL Notes ===
-EPEL does not have macros.gconf2, so please follow the instructions found here: [[Packaging:EPEL#GConf2]]
+EPEL does not have macros.gconf2, so please follow the instructions found here: [[Packaging:EPEL#GConf]]
 
 {{Anchor|info}}
 

From 8b039f9c84ca497654e54527b0dea148e7e4a835 Mon Sep 17 00:00:00 2001
From: Spot 
Date: Mar 03 2010 20:13:40 +0000
Subject: [PATCH 479/3559] *Empty MediaWiki Message*


---

diff --git a/Packaging:GuidelinesTodo.mw b/Packaging:GuidelinesTodo.mw
index b8ac8e6..2cd4220 100644
--- a/Packaging:GuidelinesTodo.mw
+++ b/Packaging:GuidelinesTodo.mw
@@ -47,7 +47,7 @@ Status should be one of:
 |-
 |announce||Using Alternatives||[[User:Rathann|rathann]]||2009-04-14||[[PackagingDrafts/UsingAlternatives]]
 |-
-|writeup||GConf scriptlets||abadger1999||2009-05-12||[[GConf Scriptlets (draft)]] Improve GConf scriplet handling.
+|announce||GConf scriptlets||abadger1999||2009-05-12||[[GConf Scriptlets (draft)]] Improve GConf scriplet handling.
 |-
 |writeup||RPath Relaxation||abadger1999||2009-10-07|| [[RPath Packaging Draft]]
 |-

From 73fe07f5a7a56d0ab1a1595b053274d9cc64977f Mon Sep 17 00:00:00 2001
From: Spot 
Date: Mar 03 2010 20:16:27 +0000
Subject: [PATCH 480/3559] *Empty MediaWiki Message*


---

diff --git a/Packaging:Guidelines.mw b/Packaging:Guidelines.mw
index 32b8acd..8a8b319 100644
--- a/Packaging:Guidelines.mw
+++ b/Packaging:Guidelines.mw
@@ -510,10 +510,10 @@ Packages which explicitly need to link against the static version must Bui
 == Duplication of system libraries ==
 
 A package should not include or build against a local copy of a library that exists on a system. The package should be patched to use the system libraries.  This prevents old bugs and security holes from living on after the core system libraries have been fixed.  More rationale for this is on the [[Packaging:No Bundled Libraries|No Bundled Libraries]] page.
-{{Anchor|Rpath}}
 
+{{Anchor|Rpath}}
 == Beware of Rpath ==
-Sometimes, code will hardcode specific library paths when linking binaries (using the -rpath or -R flag). This is commonly referred to as an rpath, and in Fedora it is forbidden. Normally, the dynamic linker and loader (ld.so) resolve the executable's dependencies on shared libraries and load what is required. However, when -rpath or -R is used, the location information is then hardcoded into the binary and is examined by ld.so in the beginning of the execution. Since the Linux dynamic linker is usually smarter than a hardcoded path, we do not permit the use of rpath in Fedora.
+Sometimes, code will hardcode specific library paths when linking binaries (using the -rpath or -R flag). This is commonly referred to as an rpath. Normally, the dynamic linker and loader (ld.so) resolve the executable's dependencies on shared libraries and load what is required. However, when -rpath or -R is used, the location information is then hardcoded into the binary and is examined by ld.so in the beginning of the execution. Since the Linux dynamic linker is usually smarter than a hardcoded path, we usually do not permit the use of rpath in Fedora.
 
 There is a tool called ''check-rpaths'' which is included in the ''rpmdevtools'' package. It is a good idea to add it to the ''%__arch_install_post'' macro in your ''~/.rpmmacros'' config file:
 
    @@ -527,6 +527,29 @@ When ''check-rpaths'' is run, you might see output like this:
 ERROR   0001: file '/usr/bin/xapian-tcpsrv' contains a standard rpath '/usr/lib64' in [/usr/lib64] 
 
    
 
+Any rpath flagged by check-rpaths '''MUST''' be removed.
+
+{{Anchor|AcceptableRpath}}
+=== Rpath for Internal Libraries ===
+
+When a program installs internal libraries they are often not installed in the system path.  These internal libraries are only used for the programs that are present in the package (for example, to factor out code that's common to the executables).  These libraries are not intended for use outside of the package.  When this occurs, it is acceptable for the programs within the package to use an rpath to find these libraries.
+
+Example:
+
    +# Internal libraries for myapp are present in:
+%{_libdir}/myapp/
+%{_libdir}/myapp/libmyapp.so.0.3.4
+%{_libdir}/myapp/libmyapp.so
+
+# myapp has an rpath to %{_libdir}/myapp/
+readelf -d /usr/bin/myapp | grep RPATH
+ 0x0000000f (RPATH)                      Library rpath: [/usr/lib/myapp]
+
    
+
+{{admon/tip|Non-Internal Libraries|When programs outside of the package are supposed to link against the library, it is better to use the [[#AlternativeRpath| Alternative to Rpath]] or simply move the libraries into %{_libdir} instead.  That way the dynamic linker can find the libraries without having to link all the programs with an rpath.}}
+
+{{Anchor|AlternativeRpath}}
+=== Alternatives to Rpath ===
 Often, rpath is used because a binary is looking for libraries in a non-standard location (standard locations are /lib, /usr/lib, /lib64, /usr/lib64). If you are storing a library in a non-standard location (e.g. /usr/lib/foo/), you should include a custom config file in /etc/ld.so.conf.d/. For example, if I was putting 32 bit libraries of libfoo in /usr/lib/foo, I would want to make a file called "foo32.conf" in /etc/ld.so.conf.d/, which contained the following:
 
     /usr/lib/foo

From a52ba29edf0c73b3b906cb69923082d5b3411fc4 Mon Sep 17 00:00:00 2001
From: Spot 
Date: Mar 03 2010 20:16:41 +0000
Subject: [PATCH 481/3559] *Empty MediaWiki Message*


---

diff --git a/Packaging:GuidelinesTodo.mw b/Packaging:GuidelinesTodo.mw
index 2cd4220..1541682 100644
--- a/Packaging:GuidelinesTodo.mw
+++ b/Packaging:GuidelinesTodo.mw
@@ -49,7 +49,7 @@ Status should be one of:
 |-
 |announce||GConf scriptlets||abadger1999||2009-05-12||[[GConf Scriptlets (draft)]] Improve GConf scriplet handling.
 |-
-|writeup||RPath Relaxation||abadger1999||2009-10-07|| [[RPath Packaging Draft]]
+|announce||RPath Relaxation||abadger1999||2009-10-07|| [[RPath Packaging Draft]]
 |-
 |writeup||Directory ownership||notting||2009-10-07|| [[User:Notting/DirectoryDraft]]
 |- 

From 58366c8b8e560e7855f928739821cb67d91bcd34 Mon Sep 17 00:00:00 2001
From: Spot 
Date: Mar 03 2010 20:25:17 +0000
Subject: [PATCH 482/3559] /* File and Directory Ownership */


---

diff --git a/Packaging:Guidelines.mw b/Packaging:Guidelines.mw
index 8a8b319..34890fe 100644
--- a/Packaging:Guidelines.mw
+++ b/Packaging:Guidelines.mw
@@ -893,22 +893,64 @@ If you are unsure if something is considered approved content, ask on fedora-dev
 
 Your package should own all of the files that are installed as part of the %install process.  Packages must not own files already owned by other packages. The rule of thumb here is that the first package to be installed  should own the files that other packages may rely upon. This means, for example, that no package in Fedora should ever share ownership with any of the files owned by the filesystem or man package. If you feel that you have a good reason to own a file or that another package owns, then please present that at package review time.
 
-Directory ownership is a little more complex than file ownership.  Although the rule of thumb is the same: own all the directories you create but none of the directories of packages you depend on, there are several instances where it's desirable for multiple packages to own a directory.  Examples of this are:
+Directory ownership is a little more complex than file ownership.  Although the rule of thumb is the same: own all the directories you create but none of the directories of packages you depend on, there are several instances where it's desirable for multiple packages to own a directory. 
 
-1) The package you depend on to provide a directory may choose to own a different directory in a later version and your package will run unmodified with that later version.
+In all cases we are guarding against unowned directories being present on a system.  Please see [[Packaging:UnownedDirectories]] for the details.
 
-One common example of this is a Perl module.  Assume ''perl-A-B'' depends on ''perl-A'' and installs files into /usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi/A/B.  The base Perl package guarantees that it will own /usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi for as long as it remains compatible with version 5.8.8, but a future upgrade of the ''perl-A'' package may install into (and thus own) /usr/lib/perl5/vendor_perl/5.9.0/i386-linux-thread-multi/A.  So the ''perl-A-B'' package needs to own /usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi/A as well as /usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi/A/B in order to maintain proper ownership.
+{{admon/important|Note on multiple ownership| Note that when co-owning directories, you must ensure that the ownership and permissions on the directory match in all packages that own it.}}
+
+{{admon/important|Note on directories| If a directory is explicitly required by packages in Fedora (such as /usr/lib/mozilla/plugins), only one package should own it, so that dependency solving is deterministic.}}
+
+Here are examples that describe how to handle most cases of directory ownership.
 
-2) Multiple packages have files in a common directory but none of them requires others.
+=== The directory is wholly contained in your package, or involves core functionality of your package. ===
 
 An example:
 
    -Foo-Animal-Emu puts files into /usr/share/Foo/Animal/Emu
-Foo-Animal-Llama puts files into /usr/share/Foo/Animal/Llama
+gnucash places many files under the /usr/share/gnucash directory
 
    
-Neither package depends on the other one. Neither package depends on any other package which owns the /usr/share/Foo/Animal/ directory. In this case, each package must own the /usr/share/Foo/Animal/ directory.
 
-In all cases we are guarding against unowned directories being present on a system.  Please see [[Packaging:UnownedDirectories]] for the details.
+Solution: the gnucash package should own the /usr/share/gnucash directory
+
+=== The package places files in many directories that are part of a larger environment's infrastructure. ===
+
+An example:
+
    +kdeutils places files in (among other places)
+ /usr/share/applications/kde4
+ /usr/share/kde4/apps
+ /usr/share/kde4/services
+
    
+
+Solution: the infrastructure directories above should be placed in a kde-filesystem package, and kdeutils should Require: the kde-filesystem package.
+
+=== The directory is also owned by a package implementing required functionality of your package. ===
+
+An example:
+
+
    +pam owns the /etc/pam.d directory
+gdm places files into /etc/pam.d
+
    
+
+Solution: the pam package should own the /etc/pam.d directory, and gdm should Require: the pam package.
+
+=== Multiple packages own files in a common directory but none of them needs to require the others. ===
+
+An example:
+
+
    +bash-completion owns the /etc/bash_completion.d directory and uses the files placed there to configure itself.
+git places files into /etc/bash_completion.d
+bzr places files into /etc/bash_completion.d
+
    
+
+Solution: Both the git and bzr packages should own the /etc/bash_completion.d directory as bash-completion is optional functionality and the installation of git or bzr should not force the installation of bash-completion.
+{{admon/important|Rule of Thumb|When determining whether this exception applies, packagers and reviewers should ask this question: Do the files in this common directory enhance or add functionality to another package, where that other package is not necessary to be present for the primary functionality of this package?}}
+
+=== The package you depend on to provide a directory may choose to own a different directory in a later version and your package will run unmodified with that later version. ===
+
+One common example of this is a Perl module.  Assume ''perl-A-B'' depends on ''perl-A'' and installs files into /usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi/A/B.  The base Perl package guarantees that it will own /usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi for as long as it remains compatible with version 5.8.8, but a future upgrade of the ''perl-A'' package may install into (and thus own) /usr/lib/perl5/vendor_perl/5.9.0/i386-linux-thread-multi/A.  So the ''perl-A-B'' package needs to own /usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi/A as well as /usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi/A/B in order to maintain proper ownership.
 
 {{Anchor|DuplicateFiles}}
 === Duplicate Files ===
@@ -924,6 +966,7 @@ Permissions on files must be set properly. Executables should be set with execut
 Unless you have a very good reason to deviate from that, you should use %defattr(-,root,root,-) for all %files sections in your package.
 
 {{Anchor|UsersAndGroups}}
+
 == Users and Groups ==
 
 Some packages require or benefit from dedicated runtime user and/or group accounts.  Guidelines for handling these cases are in a separate [[Packaging:UsersAndGroups]]  document.

From 8c1ae6e0c33647e61b6d5ef2783364496632a4f6 Mon Sep 17 00:00:00 2001
From: Spot 
Date: Mar 03 2010 20:26:11 +0000
Subject: [PATCH 483/3559] *Empty MediaWiki Message*


---

diff --git a/Packaging:GuidelinesTodo.mw b/Packaging:GuidelinesTodo.mw
index 1541682..26dcf8a 100644
--- a/Packaging:GuidelinesTodo.mw
+++ b/Packaging:GuidelinesTodo.mw
@@ -51,7 +51,7 @@ Status should be one of:
 |-
 |announce||RPath Relaxation||abadger1999||2009-10-07|| [[RPath Packaging Draft]]
 |-
-|writeup||Directory ownership||notting||2009-10-07|| [[User:Notting/DirectoryDraft]]
+|announce||Directory ownership||notting||2009-10-07|| [[User:Notting/DirectoryDraft]]
 |- 
 |writeup||Revised Emacs add-on guidelines||[[User:jgu|jgu]]|| 2009-12-02 ||[[PackagingDrafts/EmacsPackagingRevised]]
 |-

From 3b1d6bd02586e4413df7dc4cfad86c429da76851 Mon Sep 17 00:00:00 2001
From: Spot 
Date: Mar 03 2010 20:27:29 +0000
Subject: [PATCH 485/3559] moved [[Packaging:Emacs]] to [[Packaging:Emacs Old]]


---

diff --git a/Packaging:Emacs.mw b/Packaging:Emacs.mw
new file mode 100644
index 0000000..1f2eb84
--- /dev/null
+++ b/Packaging:Emacs.mw
@@ -0,0 +1 @@
+#REDIRECT [[Packaging:Emacs Old]]

From bd6c5f1a880ab8acea4d40d7f3264609961f65e2 Mon Sep 17 00:00:00 2001
From: Spot 
Date: Mar 03 2010 20:29:07 +0000
Subject: [PATCH 486/3559] *Empty MediaWiki Message*


---

diff --git a/Packaging:Emacs.mw b/Packaging:Emacs.mw
index 1f2eb84..a310486 100644
--- a/Packaging:Emacs.mw
+++ b/Packaging:Emacs.mw
@@ -1 +1,357 @@
-#REDIRECT [[Packaging:Emacs Old]]
+= Packaging of add-ons for GNU Emacs and XEmacs =
+
+== Purpose ==
+
+The purpose of this document is to promote good practice in packaging add-ons for GNU Emacs and XEmacs, and to encourage the submission of more Emacs add-on packages to the package collection by providing easy to use spec file templates.
+
+This document refers to packaging for Fedora 12 onwards. If you are packaging for an older release of Fedora, please see: [[Packaging:Emacs_Old]]
+
+== Executive summary of Guidelines ==
+The following list contains the key points of the guidelines. More detail on each of these may be found in the subsequent sections. These guidelines make extensive use of the macros defined in /etc/rpm/macros.emacs and /etc/rpm/macros.xemacs which are installed with the emacs-common and xemacs-common packages.
+
+=== Package naming and sub-package organization ===
+1. Where an add-on package foo is for both GNU Emacs and XEmacs, the main package should be called emacs-common-foo. This main package should contain files common to both GNU Emacs and XEmacs such as documentation etc. Files specific to each of GNU Emacs and XEmacs should be placed in sub-packages as detailed in points 4 and 5 below.
+
+2. Where a package is specific only to one flavour of (X)Emacs, the main package should be called emacs-foo or xemacs-foo. In both cases, elisp source should be packaged in separate sub-packages as detailed below.
+
+3. Where a package which is not primarily an (X)Emacs add-on package but contains auxillary (X)Emacs components, these should be placed in sub-packages following the guidelines below.
+
+4. Files specific to GNU Emacs should be placed in two sub-packages:
+* emacs-foo: this sub-package should contain compiled elisp and other files needed to use the add-on package with GNU Emacs only. It should not contain any source elisp files which are not required to run the package.
+* emacs-foo-el: this sub-package contains the source elisp files used to build the add-on package for GNU Emacs. Files in this package should not be required to use the add-on package.
+
+5. Files specific to XEmacs should be placed in two sub-packages:
+* xemacs-foo: this sub-package should contain compiled elisp and other files needed to use the add-on package with XEmacs only. It should not contain any source elisp files which are not required to run the package.
+* xemacs-foo-el: this sub-package contains the source elisp files used to build the add-on package for XEmacs. Files in this package should not be required to use the add-on package.
+
+=== File locations ===
+1. File locations for GNU Emacs add-on packages:
+* All elisp and related files for the add-on package should be installed in the directory %{_emacs_sitelispdir}/foo.
+* If the package requires a startup file this should be called foo-init.el and be placed in %{_emacs_sitestartdir}.
+
+2. File locations for XEmacs add-on packages:
+* All elisp files for the add-on package should be installed in the directory %{_xemacs_sitelispdir}/foo (%{_xemacs_sitelispdir} translates to /usr/share/xemacs/site-packages/lisp/)
+* All other files for the add-on package should be installed under the relevant sub-directories  in %{_xemacs_sitepkgdir} eg. %{_xemacs_sitepkgdir}/etc/foo (%{_xemacs_sitepkgdir} translates to /usr/share/xemacs/site-packages).
+* If the package requires a startup file this should be called foo-init.el and be placed in %{_xemacs_sitestartdir}.
+
+=== Directory ownership ===
+1. Directory ownerships for GNU Emacs add-on packages:
+* %{_emacs_sitelispdir}/foo should be owned by the package emacs-foo.
+
+2. Directory ownerships for XEmacs add-on packages: 
+* %{_xemacs_sitelispdir}/foo should be owned by xemacs-foo.
+* Any %{_xemacs_sitepkgdir}/*/foo directories should be owned by xemacs-foo.
+
+=== Package Requires and BuildRequires ===
+1. Package Requires for GNU Emacs add-on packages
+* emacs-foo-el must have Requires: emacs-foo = %{version}-%{release}.
+* Where relevant emacs-foo must have Requires: emacs-common-foo = %{version}-%{release}
+* emacs-foo must have Requires: emacs(bin) >= %{_emacs_version}
+
+2. Package Requires for XEmacs add-on packages
+* xemacs-foo-el must have Requires: xemacs-foo = %{version}-%{release}.
+* Where relevant xemacs-foo must have Requires: emacs-common-foo = %{version}-%{release}
+* xemacs-foo must have Requires: xemacs(bin) >= %{_xemacs_version}
+
+3. Package BuildRequires for GNU Emacs add-on packages
+* In general it should suffice to have BuildRequires: emacs
+
+4 Package BuildRequires for XEmacs add-on packages
+* In general it should suffice to have BuildRequires: xemacs
+* It may be necessary to also add BuildRequires: xemacs-devel in rare circumstances
+
+=== Manual byte compilation ===
+Usually package elisp compilation is handled via a make file shipped with the package, but on some occasions it may be necessary to add commands to the %build section of the spec file to byte compile files. The following macros are provided to help with this
+
+1. For GNU Emacs byte compilation, use %{_emacs_bytecompile} file.el
+
+2. For XEmacs byte compilation, use %{_xemacs_bytecompile} file.el
+
+=== Use of BuildArch: noarch ===
+If an add-on package requires only byte compilation of elisp then BuildArch: noarch should be used.
+
+== Templates for Emacsen add-on package spec files ==
+
+=== Template for a package for both GNU Emacs and XEmacs ===
+This spec-file template for the add-on package "foo" creates 5 packages:
+
+1. emacs-common-foo is the main package. This should contain files which are common to both the emacs-foo and xemacs-foo subpackages below. Examples of what this file would contain are the package documentation, the COPYING file, the CHANGELOG file etc.
+
+2. emacs-foo. This sub-package Requires emacs-common-foo and contains the files needed to run foo with Emacs only. This package owns the director /usr/share/emacs/site-lisp/foo.
+
+3. emacs-foo-el. This sub-package contains the elisp source files corresponding to the compiled elisp files in package emacs-foo. This sub-package Requires: emacs-foo, as the directory in which the elisp source files are installed to is owned by emacs-foo.
+
+4. xemacs-foo. This sub-package Requires emacs-common-foo and contains the files needed to run foo with Emacs only. This package owns the director /usr/share/emacs/site-packages/lisp/foo.
+
+5. xemacs-foo-el. This sub-package contains the elisp source files corresponding to the compiled elisp files in package xemacs-foo. This sub-package Requires: xemacs-foo, as the directory in which the elisp source files are installed to is owned by xemacs-foo.
+
+For the Requires mentioned in 1-5 above, the exact %{version}-%{release} should be matched.
+
+For convenience, there are two macros at the top of the file which you should customise to your package. You do not have to use the macros placed at the top of the file, but they help readability and make writing a spec file for a new package much quicker.
+
+
    +%global pkg foo
+%global pkgname Foo
+
+Name:           emacs-common-%{pkg}
+Version:
+Release:        1%{?dist}
+Summary:
+
+Group:
+License:
+URL:
+Source0:
+
+BuildArch:	noarch
+BuildRequires:  emacs
+BuildRequires:  xemacs
+Requires:
+
+%description
+%{pkgname} is an add-on package for GNU Emacs and XEmacs. It does wonderful things...
+
+This package contains the files common to both the GNU Emacs and XEmacs %{pkgname}
+packages.
+
+%package -n emacs-%{pkg}
+Summary:	Compiled elisp files to run %{pkgname} under GNU Emacs
+Group:
+Requires:	emacs(bin) >= %{_emacs_version}
+Requires:       emacs-common-%{pkg} = %{version}-%{release}
+
+%description -n emacs-%{pkg}
+This package contains the byte compiled elisp packages to run %{pkgname} with GNU
+Emacs.
+
+
+%package -n emacs-%{pkg}-el
+Summary:	Elisp source files for %{pkgname} under GNU Emacs
+Group:
+Requires:	emacs-%{pkg} = %{version}-%{release}
+
+%description -n emacs-%{pkg}-el
+This package contains the elisp source files for %{pkgname} under GNU Emacs. You
+do not need to install this package to run %{pkgname}. Install the emacs-%{pkg}
+package to use %{pkgname} with GNU Emacs.
+
+
+%package -n xemacs-%{pkg}
+Summary:	Compiled elisp files to run %{pkgname} under XEmacs
+Group:
+Requires:	xemacs(bin) >= %{_xemacs_version}
+Requires:       emacs-common-%{pkg} = %{version}-%{release}
+
+%description -n xemacs-%{pkg}
+This package contains the byte compiled elisp packages to use %{pkgname} with
+XEmacs.
+
+
+%package -n xemacs-%{pkg}-el
+Summary:	Elisp source files for %{pkgname} under XEmacs
+Group:
+Requires:	xemacs-%{pkg} = %{version}-%{release}
+
+%description -n xemacs-%{pkg}-el
+This package contains the elisp source files for %{pkgname} under XEmacs. You do
+not need to install this package to run %{pkgname}. Install the xemacs-%{pkg}
+package to use %{pkgname} with XEmacs.
+
+
+%prep
+%setup -q -n %{pkg}-%{version}
+
+%build
+
+
+%install
+
+
+%clean
+rm -rf $RPM_BUILD_ROOT
+
+
+%post
+
+
+%preun
+
+
+%files
+%defattr(-,root,root,-)
+%doc
+
+
+%files -n emacs-%{pkg}
+%defattr(-,root,root,-)
+%{_emacs_sitelispdir}/%{pkg}/*.elc
+%{_emacs_sitestartdir/*.el
+%dir %{_emacs_sitelispdir}/%{pkg}
+
+
+%files -n emacs-%{pkg}-el
+%defattr(-,root,root,-)
+%{_emacs_sitelispdir}/%{pkg}/*.el
+
+
+%files -n xemacs-%{pkg}
+%defattr(-,root,root,-)
+%{_xemacs_sitelispdir}/%{pkg}/*.elc
+%{_xemacs_sitestartdir}/*.el
+%dir %{_xemacs_sitelispdir}/%{pkg}
+
+
+%files -n xemacs-%{pkg}-el
+%defattr(-,root,root,-)
+%{_xemacs_sitelispdir}/%{pkg}/*.el
+
+
+%changelog
+
    
+
+=== Template for a add-on package for GNU Emacs only ===
+This is a template for a package for GNU Emacs only. The main package is called emacs-foo and contains all files needed to run package foo with GNU Emacs. There is a subpackage called emacs-foo-el which installs the elisp source files. emacs-foo owns the directory into which it is installed (/usr/share/emacs/site-lisp/foo), and so emacs-foo-el Requires emacs-foo with the matching version and release tag.
+
+
    +%global pkg foo
+%global pkgname Foo
+
+Name:           emacs-%{pkg}
+Version:
+Release:        1%{?dist}
+Summary:
+
+Group:
+License:
+URL:
+Source0:
+
+BuildArch:      noarch
+BuildRequires:  emacs
+Requires:       emacs(bin) >= %{_emacs_version}
+
+%description
+%{pkgname} is an add-on package for GNU Emacs. It does wonderful things...
+
+%package -n %{name}-el
+Summary:        Elisp source files for %{pkgname} under GNU Emacs
+Group:
+Requires:       %{name} = %{version}-%{release}
+
+%description -n %{name}-el
+This package contains the elisp source files for %{pkgname} under GNU Emacs. You
+do not need to install this package to run %{pkgname}. Install the %{name}
+package to use %{pkgname} with GNU Emacs.
+
+%prep
+%setup -q -n %{pkg}-%{version}
+
+%build
+
+
+%install
+
+
+%clean
+rm -rf $RPM_BUILD_ROOT
+
+
+%post
+
+
+%preun
+
+
+%files
+%defattr(-,root,root,-)
+%doc
+%{_emacs_sitelispdir}/%{pkg}/*.elc
+%{_emacs_sitestartdir}/*.el
+%dir %{_emacs_sitelispdir}/%{pkg}
+
+%files -n %{name}-el
+%defattr(-,root,root,-)
+%{_emacs_sitelispdir}/%{pkg}/*.el
+
+%changelog
+
    
+
+== Principles behind the guidelines ==
+The existence of the GNU Emacs and XEmacs variants makes packaging Emacs add-on packaging slightly complex. GNU Emacs and XEmacs have different philosophies regarding add-on packages.
+
+XEmacs has its own packaging system and maintains and distributes its own library of third party add-on modules. These are distributed in Fedora in the xemacs-packages-base and xemacs-packages-extra packages. GNU Emacs doesn't have any equivalent system, and third party add-ons are left for the user or distribution to install.
+
+The packaging naming guidelines state that:
+
+''Packages of emacs add-on components (code that adds additional functionality to emacs compatible editors) have their own naming scheme. It is often the case that a component will add functionality to several different compatible editors, such as GNU Emacs and XEmacs (and possibly development versions of these editors). The package name should take into account the upstream name of the emacs component.''
+
+''Where a component adds functionality to more than one emacs compatible editor, the package name should be of the form emacs-common-$NAME. In this case, the main package should contain only files common to all emacs compatible editors, and the code specific to each should be placed in a subpackage reflecting the specific editor $EDITOR-$NAME eg. xemacs-$NAME, emacs-$NAME (the latter being the package specific to GNU Emacs). An example of this scheme can be found in the package emacs-common-muse.''
+
+''Where a component is designed to add functionality to only a single emacs compatible editor, the main package name should reflect this by being called $EDITOR-$NAME. An example of this situation can be found in the package emacs-auctex, which is built only for GNU Emacs.''
+
+Wherever possible, we encourage making an add-on package available for both GNU Emacs and XEmacs. One common case where that is not desireable is when an add-on package is already available for XEmacs in either xemacs-packages-base or xemacs-packages-extra. For example VM (a mail reader for Emacs) is provided for XEmacs in the xemacs-packages-extra package, but is not included in the emacs or emacs-common packages. Therefore it is sensible to create a package called emacs-vm which is the VM package for GNU Emacs only. Another such example is AUCTeX.
+
+=== Location of installed files ===
+==== GNU Emacs ====
+For GNU Emacs, files for add-on package foo should be placed in %{_emacs_sitelispdir}/foo which evaluates to /usr/share/emacs/site-lisp/foo. 
+
+Usually an add-on package will require a startup file, and this should be called foo-init.el and be placed in %{_emacs_sitestartdir} which evaluates to /usr/share/emacs/site-lisp/site-start.d/.
+
+==== XEmacs ====
+XEmacs expects add-on packages to be installed under %{_xemacs_sitepkgdir} which evaluates to /usr/share/xemacs/site-packages.
+
+Lisp files for add-on package foo should be placed in %{_xemacs_sitelispdir}/foo which evaluates to %{_xemacs_sitepkgdir}/lisp/foo.
+
+Other files for the add-on which are not elisp files should be placed in package specific sub-directories under %{_xemacs_sitepkgdir} eg. %{_xemacs_sitepkgdir}/etc/foo.
+
+Usually an add-on package will require a startup file, and this should be called foo-init.el and be placed in %{_xemacs_sitestartdir} which evaluates to /usr/share/xemacs/site-packages/lisp/site-start.d/.
+
+=== Packaging of source elisp files ===
+Typically, an Emacs add-on package will be compiled from source elisp files. The resulting compiled elisp files will then be included in the relevant emacs-foo and xemacs-foo packages. However, these packages SHOULD NOT contain uncompiled elisp source files which are not required for the program to run. Rather, following the precedent set by GNU Emacs packaging, the elisp source files should be placed in their own sub-packages, named emacs-foo-el and xemacs-foo-el.
+
+The (x)emacs-foo-el packages are similar in many ways to the -devel subpackages for system libraries. It is often the case that byte compiling the elisp source for one add-on will require the presence of the elisp source for another add-on package at build time for example.
+
+=== BuildArch for (X)Emacs add-on packages ===
+You should set BuildArch: noarch for add-on packages which only compile elisp files during building.
+
+If the package building process also compiles programs in other languages, you may need to not set BuildArch.
+
+=== Requires for GNU Emacs and XEmacs ===
+Add-on packages should have appropriate Requires entries for the flavour of (X)Emacs they are targeted at. Both GNU Emacs and XEmacs are available in two different packages - some details of these packages follow.
+
+1. GNU Emacs is packaged as two variants. The emacs package is built with Xorg support to allow the user to run Emacs in a windowed environment. The emacs-nox package is built without Xorg support and hence allows Emacs to be run only in a console. Note:
+* Both the emacs and emacs-nox packages have Requires: emacs-common.
+* Both emacs and emacs-nox have a virtual Provides: emacs(bin)
+
+2. XEmacs is packaged as two variants. The xemacs package is built with Xorg support to allow the user to run Emacs in a windowed environment. The xemacs-nox package is built without Xorg support and hence allows Emacs to be run only in a console. Note:
+* Both the xemacs and xemacs-nox packages have Requires: xemacs-common.
+* Both xemacs and xemacs-nox have a virtual Provides: xemacs(bin)
+
+Assuming your add-on package will work in both a windowed and a console (X)Emacs session, it is wrong to have Requires: emacs or Requires: xemacs as that would pull in a dependency on Xorg even if the console variants of (X)Emacs was installed. Rather you should use Requires: xemacs(bin) for XEmacs add-on packages, and Requires: emacs(bin) for GNU Emacs add-on packages.
+
+If the package ONLY works with Xorg support built into (X)Emacs, then the packages should have Requires: emacs or Requires: xemacs. This is very uncommon.
+
+==== Why we need versioned Requires ====
+Many elisp packages aim for backwards source level compatibility by checking whether some features exist in the (X)Emacs in use when the package is being run or byte-compiled.  If yes, they use what's available.  If no, they provide their own versions of missing functions, macros etc.  This propagates into *.elc during byte compilation, and quite a few functions do get added between upstream (X)Emacs releases.
+
+So let's say I byte-compile a package into *.elc with XEmacs 21.5.28.  Elisp package quux checks if the foo-bar function is available in the XEmacs being used to byte-compile it.  Yes, it is, so the internal backwards compat version of foo-bar included in quux does not end up in the *.elc.  Now, let's assume foo-bar was added in XEmacs 21.5.28 and didn't exist in 21.5.27 and we're trying to run the *.elc with 21.5.27 -> boom, foo-bar is not available. Note: this wouldn't happen if only *.el were shipped - *.elc are the potential and likely problem.  Requiring >= version of the (X)Emacs used to byte-compile the *.elc is not the only solution (nor enough for all corner cases), but is the best one we currently have available.
+
+The main package and subpackages will need to have appropriately version Requires to ensure that a recent enough version of (X)Emacs is installed. (X)Emacs byte compiled lisp is usually forward compatible with later (X)Emacs versions, but is frequently not compatible with earlier versions of (X)Emacs.
+
+==== Determining the Required (X)Emacs version at package build time ====
+It is recommended to derive greater-than-or-equal-to valued versioned dependencies from the version of (X)Emacs used to byte-compile the package at package build time. The emacs-common and xemacs-common packages both place files in /etc/rpm which define macros containing the version of (X)Emacs installed. The relevant macros are:
+
+
    +%{_emacs_version}
+%{_xemacs_version}
+
    
+
+=== Other packages containing Emacsen add-ons ===
+It is often the case that a software package, while not being primarily an Emacs add-on package, will contain components for (X)Emacs. For example, the Gnuplot program contains some elisp files for editing Gnuplot input files in GNU Emacs and running Gnuplot from GNU Emacs.
+
+{| border="1"
+|-
+| {{Template:Tip}} Where a package contains add-on components for (X)Emacs, in general these components should be packaged in a sub-package consistent with the guidelines here for main (X)Emacs packages.
+|}
+
+In other words, if a package foo contains components for (X)Emacs, the subpackages containing the files  to run the (X)Emmacs components should be called emacs-foo and emacs-foo-el, which own the directories /usr/share/emacs/site-lisp/foo and /usr/share/xemacs/site-packages/lisp/foo respectively. Elisp source files not needed for running the add-ons should be packaged in separate sub-packages emacs-foo-el and xemacs-foo-el, which should Require emacs-foo and xemacs-foo respectively.

From 18727988170561ab034e94caaeddc0e3070eb0a1 Mon Sep 17 00:00:00 2001
From: Spot 
Date: Mar 03 2010 20:29:40 +0000
Subject: [PATCH 487/3559] *Empty MediaWiki Message*


---

diff --git a/Packaging:GuidelinesTodo.mw b/Packaging:GuidelinesTodo.mw
index 26dcf8a..8a9db34 100644
--- a/Packaging:GuidelinesTodo.mw
+++ b/Packaging:GuidelinesTodo.mw
@@ -53,7 +53,7 @@ Status should be one of:
 |-
 |announce||Directory ownership||notting||2009-10-07|| [[User:Notting/DirectoryDraft]]
 |- 
-|writeup||Revised Emacs add-on guidelines||[[User:jgu|jgu]]|| 2009-12-02 ||[[PackagingDrafts/EmacsPackagingRevised]]
+|announce||Revised Emacs add-on guidelines||[[User:jgu|jgu]]|| 2009-12-02 ||[[PackagingDrafts/EmacsPackagingRevised]]
 |-
 |writeup||PHP guidelines||[[User:Remi|Remi]]|| 2009-12-02 ||[[PackagingDrafts/PHP]]
 |-

From b1b8e14ab13a06900dcb9a8f6595c479d4b978e9 Mon Sep 17 00:00:00 2001
From: Spot 
Date: Mar 03 2010 20:48:54 +0000
Subject: [PATCH 488/3559] *Empty MediaWiki Message*


---

diff --git a/Packaging:PHP.mw b/Packaging:PHP.mw
index 47ccb91..fa83f34 100644
--- a/Packaging:PHP.mw
+++ b/Packaging:PHP.mw
@@ -38,7 +38,7 @@ Note that web applications that happen to be written in PHP do not belong under 
 
 == File Placement ==
 
-Non-PEAR PHP extensions should put their Class files in /usr/share/php.
+Non-PEAR PHP software which provides shared libraries should put its PHP source files for such shared libraries in a subfolder of /usr/share/php, named according to the name of the software. For example, a library called "Whizz_Bang" (with a RPM called php-something-Whizz-Bang) would put the PHP source files for its shared libraries in /usr/share/php/Whizz_Bang. 
 
 == Requires and Provides ==
 
@@ -78,22 +78,29 @@ Requires: php-channel(channelname)
 Provides:     php-pear(channelname/foo) = %{version}
 
    
 
+=== C extensions (PECL and others) ===
+
+To be certain that a binary extension will run correctly with a particular version of PHP, it is necessary to check that a particular package has both API and ABIs matching the installed version of PHP. The mechanism for doing this has evolved over time and is as follows:
+
+For '''Fedora''' (all current versions):
+
    +BuildRequires: php-devel
+Requires:      php(zend-abi) = %{php_zend_api}
+Requires:      php(api) = %{php_core_api}
+
    
+{{admon/important|Packaging note|Details on what to do for EPEL branches EL-4 and EL-5 can be found here: [[Packaging:EPEL#PHP_ABI_Check_Handling]]}}
+
 === PECL Packages ===
 
-A PECL package '''MUST''' have:
+PECL extension '''MUST''' have ABI check (see previous)
+
+A PECL package '''MUST''' also have:
 
 
    -BuildRequires: php-devel, php-pear
+BuildRequires: php-pear
 Requires(post): %{__pecl}
 Requires(postun): %{__pecl}
 
-%if %{?php_zend_api}0
-Requires:     php(zend-abi) = %{php_zend_api}
-Requires:     php(api) = %{php_core_api}
-%else
-Requires:     php-api = %{php_apiver}
-%endif
-
 Provides:     php-pecl(foo) = %{version}
 
    
 
@@ -193,6 +200,8 @@ fi
 %endif
 
    
 
+{{admon/important|Packaging note|These scriptlets are not correct on EPEL, please see: [[Packaging:EPEL#PHP_PECL_Module_Scriptlets]]}}
+
 === Other Modules ===
 
 If your module includes compiled code, you may need to define some macros to extract some information from PHP.  It is recommended that you user the following:

From b2e17baa5d57c26fdf9889c15738e117f308a874 Mon Sep 17 00:00:00 2001
From: Spot 
Date: Mar 03 2010 20:49:35 +0000
Subject: [PATCH 489/3559] /* PECL Modules */


---

diff --git a/Packaging:PHP.mw b/Packaging:PHP.mw
index fa83f34..c394a16 100644
--- a/Packaging:PHP.mw
+++ b/Packaging:PHP.mw
@@ -186,18 +186,14 @@ You may need to define a few additional macros to extract some information from 
 
 And here are some recommended scriptlets for properly registering and unregistering the module:
 
    -%if 0%{?pecl_install:1}
 %post
 %{pecl_install} %{pecl_xmldir}/%{name}.xml >/dev/null || :
-%endif
 
 
-%if 0%{?pecl_uninstall:1}
 %postun
 if [ $1 -eq 0 ]  ; then
 %{pecl_uninstall} %{pecl_name} >/dev/null || :
 fi
-%endif
 
    
 
 {{admon/important|Packaging note|These scriptlets are not correct on EPEL, please see: [[Packaging:EPEL#PHP_PECL_Module_Scriptlets]]}}

From ac6001bb39c8a248758a34b57712b71cc7fb14d4 Mon Sep 17 00:00:00 2001
From: Spot 
Date: Mar 03 2010 20:49:58 +0000
Subject: [PATCH 490/3559] *Empty MediaWiki Message*


---

diff --git a/Packaging:GuidelinesTodo.mw b/Packaging:GuidelinesTodo.mw
index 8a9db34..dd745ab 100644
--- a/Packaging:GuidelinesTodo.mw
+++ b/Packaging:GuidelinesTodo.mw
@@ -55,7 +55,7 @@ Status should be one of:
 |- 
 |announce||Revised Emacs add-on guidelines||[[User:jgu|jgu]]|| 2009-12-02 ||[[PackagingDrafts/EmacsPackagingRevised]]
 |-
-|writeup||PHP guidelines||[[User:Remi|Remi]]|| 2009-12-02 ||[[PackagingDrafts/PHP]]
+|announce||PHP guidelines||[[User:Remi|Remi]]|| 2009-12-02 ||[[PackagingDrafts/PHP]]
 |-
 |ratify||SRPM Buildtime macros||abadger1999||2010-02-03||[[SRPM_Buildtime_macros]]
 |-

From 8deed888cff083bda46720d26b61ac2b82bf6b01 Mon Sep 17 00:00:00 2001
From: Spot 
Date: Mar 03 2010 21:01:19 +0000
Subject: [PATCH 491/3559] *Empty MediaWiki Message*


---

diff --git a/Packaging:GuidelinesTodo.mw b/Packaging:GuidelinesTodo.mw
index dd745ab..949499a 100644
--- a/Packaging:GuidelinesTodo.mw
+++ b/Packaging:GuidelinesTodo.mw
@@ -57,11 +57,11 @@ Status should be one of:
 |-
 |announce||PHP guidelines||[[User:Remi|Remi]]|| 2009-12-02 ||[[PackagingDrafts/PHP]]
 |-
-|ratify||SRPM Buildtime macros||abadger1999||2010-02-03||[[SRPM_Buildtime_macros]]
+|writeup||SRPM Buildtime macros||abadger1999||2010-02-03||[[SRPM_Buildtime_macros]]
 |-
-|ratify||Emphasize correct SF.net SourceURL||[[User:till]]||2010-02-03||[[PackagingDrafts/SourceURL_sourceforge_downloads_admonition]]
+|writeup||Emphasize correct SF.net SourceURL||[[User:till]]||2010-02-03||[[PackagingDrafts/SourceURL_sourceforge_downloads_admonition]]
 |-
-|ratify||Python guideline update||abadger1999||2010-02-03 (vote taken on mailing list)|| https://fedoraproject.org/wiki/PackagingDrafts/Python3
+|writeup||Python guideline update||abadger1999||2010-02-03 (vote taken on mailing list)|| https://fedoraproject.org/wiki/PackagingDrafts/Python3
 |}
 
 == Other TODO ==

From 9ad5a3a700290637e34ee5ae9436eddd9c47f75c Mon Sep 17 00:00:00 2001
From: Spot 
Date: Mar 03 2010 21:02:45 +0000
Subject: [PATCH 492/3559] /* Macros */


---

diff --git a/Packaging:Guidelines.mw b/Packaging:Guidelines.mw
index 34890fe..c0bfc72 100644
--- a/Packaging:Guidelines.mw
+++ b/Packaging:Guidelines.mw
@@ -686,6 +686,20 @@ Fedora's RPM includes a %makeinstall macro but it must '''NOT''' be
 
 Instead, Fedora packages should use: make DESTDIR=%{buildroot} install or make DESTDIR=$RPM_BUILD_ROOT install
 
+=== Source RPM Buildtime Macros ===
+All macros in Summary: and %description need to be expandable at srpm buildtime.  Because SRPMs are built without the package's BuildRequires installed, depending on macros defined outside of the spec file can easily lead to the unexpanded macros showing up in the built SRPM.  One way to check is to create a minimal chroot and build the srpm:
+
+
    +mock --init
+mock --copyin [SRPM] /
+mock --shell bash
+rpm -ivh [SRPM]
+cd /builddir/build/SPECS
+rpmbuild -bs --nodeps [SRPM]
+rpm -qpiv /builddir/build/SRPMS/[SRPM]
+
    
+Check the rpm output for unexpanded macros (%{foo}) or missing information (when%{?foo} is expanded to the empty string).  Even easier is to simply avoid macros in Summary: and %description unless they are defined in the current spec file.
+
 == %global preferred over %define ==
 
 Use %global instead of %define, unless you really need only locally defined submacros within other macro definitions (a very rare case).

From 13efc91f8c4f7d4f5a648ff2fb8b26efde06fbb5 Mon Sep 17 00:00:00 2001
From: Spot 
Date: Mar 03 2010 21:03:12 +0000
Subject: [PATCH 493/3559] *Empty MediaWiki Message*


---

diff --git a/Packaging:GuidelinesTodo.mw b/Packaging:GuidelinesTodo.mw
index 949499a..03d6e20 100644
--- a/Packaging:GuidelinesTodo.mw
+++ b/Packaging:GuidelinesTodo.mw
@@ -57,7 +57,7 @@ Status should be one of:
 |-
 |announce||PHP guidelines||[[User:Remi|Remi]]|| 2009-12-02 ||[[PackagingDrafts/PHP]]
 |-
-|writeup||SRPM Buildtime macros||abadger1999||2010-02-03||[[SRPM_Buildtime_macros]]
+|announce||SRPM Buildtime macros||abadger1999||2010-02-03||[[SRPM_Buildtime_macros]]
 |-
 |writeup||Emphasize correct SF.net SourceURL||[[User:till]]||2010-02-03||[[PackagingDrafts/SourceURL_sourceforge_downloads_admonition]]
 |-

From d0c47a4d63ac07b8573b8ab5ebc8dc7fd9447c55 Mon Sep 17 00:00:00 2001
From: Spot 
Date: Mar 03 2010 21:06:15 +0000
Subject: [PATCH 494/3559] /* Sourceforge.net */


---

diff --git a/Packaging:SourceURL.mw b/Packaging:SourceURL.mw
index 0d8f7b2..49a38c1 100644
--- a/Packaging:SourceURL.mw
+++ b/Packaging:SourceURL.mw
@@ -75,7 +75,9 @@ Source0: http://downloads.sourceforge.net/%{name}/%{name}-%{version}.tar.gz
 
    
 changing ".tar.gz" to whatever matches the upstream distribution.  Note that we are using downloads.sourceforge.net instead of an arbitrarily chosen mirror. You may use the package name/package version instead of the %{name} and %{version} macros, of course.
 
+Please note that the correct url is downloads.sourceforge.net, and '''NOT''' download.sourceforge.net.
 {{Anchor|VersionMacro}}
+
 == Using %{version} ==
 
 Using %{version} in the SourceX: makes it easier for you to bump the version of a package, because most of the time you do not need to edit SourceX: when editing the specfile for the new package.

From 53f57cf20ca3dff7c8f6e845fff04ca21682a8ca Mon Sep 17 00:00:00 2001
From: Spot 
Date: Mar 03 2010 21:07:30 +0000
Subject: [PATCH 495/3559] /* Addon Packages (python3 modules) */


---

diff --git a/Packaging:Naming.mw b/Packaging:Naming.mw
index 9fc3cb1..f1f4db6 100644
--- a/Packaging:Naming.mw
+++ b/Packaging:Naming.mw
@@ -428,7 +428,7 @@ An rpm with a python prefix or suffix means a python2 rpm so we nee
 
 So all python3 modules '''MUST''' have python3 in their name.  Other than that, the module must be in the same format as the python2 package.  Some examples:
 {|
-! Fedora python 2 package !! Upstream name !! Proposed python 3 package name
+! Fedora python 2 package !! Upstream name !! Fedora Python 3 package name
 |-
 | python-lxml             || lxml          || python3-lxml
 |-

From 1d20a534cf78c13e3739682d973921290f2d2eae Mon Sep 17 00:00:00 2001
From: Spot 
Date: Mar 03 2010 21:08:48 +0000
Subject: [PATCH 496/3559] *Empty MediaWiki Message*


---

diff --git a/Packaging:GuidelinesTodo.mw b/Packaging:GuidelinesTodo.mw
index 03d6e20..1424353 100644
--- a/Packaging:GuidelinesTodo.mw
+++ b/Packaging:GuidelinesTodo.mw
@@ -59,9 +59,9 @@ Status should be one of:
 |-
 |announce||SRPM Buildtime macros||abadger1999||2010-02-03||[[SRPM_Buildtime_macros]]
 |-
-|writeup||Emphasize correct SF.net SourceURL||[[User:till]]||2010-02-03||[[PackagingDrafts/SourceURL_sourceforge_downloads_admonition]]
+|announce||Emphasize correct SF.net SourceURL||[[User:till]]||2010-02-03||[[PackagingDrafts/SourceURL_sourceforge_downloads_admonition]]
 |-
-|writeup||Python guideline update||abadger1999||2010-02-03 (vote taken on mailing list)|| https://fedoraproject.org/wiki/PackagingDrafts/Python3
+|announce||Python guideline update||abadger1999||2010-02-03 (vote taken on mailing list)|| https://fedoraproject.org/wiki/PackagingDrafts/Python3
 |}
 
 == Other TODO ==

From a1fd5820fb61fb4917436ed1bb6d3db8fc7017ad Mon Sep 17 00:00:00 2001
From: Spot 
Date: Mar 03 2010 21:50:19 +0000
Subject: [PATCH 499/3559] *Empty MediaWiki Message*


---

diff --git a/Packaging:GuidelinesTodo.mw b/Packaging:GuidelinesTodo.mw
index 1424353..39035a8 100644
--- a/Packaging:GuidelinesTodo.mw
+++ b/Packaging:GuidelinesTodo.mw
@@ -9,72 +9,73 @@ Status should be one of:
 |- style="color: white; background-color: #3074c2; font-weight: bold" 
 |Status||Task Name||Owner||Meeting Date||Notes
 |-
-|announce||Use the better source||mether||2009-09-09|| Draft available at https://fedoraproject.org/wiki/PackagingDrafts/Use_Better_Source 
+|}
+
+== Other TODO ==
+Emailed Jussi Lehtola about the required changes to packages listed which are still listed here: [[PackagingDrafts/Fortran]]
+
+
+
+{{:PackagingDrafts/DraftsTodo}}
+
+== Resolved items ==
+{| border="1"
+|- style="color: white; background-color: #3074c2; font-weight: bold" 
+|Task Name||Owner||Resolution Date||Notes
+|-
+|Use the better source||mether||2009-09-09|| Draft available at https://fedoraproject.org/wiki/PackagingDrafts/Use_Better_Source 
 |-
-|announce||Fortran||[[User:jussilehtola|Jussi Lehtola]]||2009-08-19||[[PackagingDrafts/Fortran]]
+|Fortran||[[User:jussilehtola|Jussi Lehtola]]||2009-08-19||[[PackagingDrafts/Fortran]]
 |-
-|announce||Correct ant sample spec||[[User:jussilehtola|Jussi Lehtola]]||2009-08-12||[[PackagingDrafts/JavaAntSampleSpec]]
+|Correct ant sample spec||[[User:jussilehtola|Jussi Lehtola]]||2009-08-12||[[PackagingDrafts/JavaAntSampleSpec]]
 |-
-|announce||Update R guidelines||[[User:pingou|pingou]]||2009-08-12|| [[ProposalUpdateRGuidelines]]
+|Update R guidelines||[[User:pingou|pingou]]||2009-08-12|| [[ProposalUpdateRGuidelines]]
 |-
-|announce||Drop Scrollkeeper Scriptlets||[[User:spot|spot]]||2009-08-12|| [[PackagingDrafts/DropScrollkeeperUpdate]]
+|Drop Scrollkeeper Scriptlets||[[User:spot|spot]]||2009-08-12|| [[PackagingDrafts/DropScrollkeeperUpdate]]
 |-
-|announce||Numpy and pygtk2||[[User:spot|spot]]||2009-08-12|| [[PackagingDrafts/PythonNumpy]]
+|Numpy and pygtk2||[[User:spot|spot]]||2009-08-12|| [[PackagingDrafts/PythonNumpy]]
 |-
-|announce||dos2unix||atorkhov|| 2009-07-28||[[PackagingDrafts/Dos2unix]]
+|dos2unix||atorkhov|| 2009-07-28||[[PackagingDrafts/Dos2unix]]
 |-
-|announce||Explanation of no bundled libraries||abadger1999||2009-07-28||[[No_Bundled_Libraries]]
+|Explanation of no bundled libraries||abadger1999||2009-07-28||[[No_Bundled_Libraries]]
 |-
-|announce||pre-built binaries||oget||2009-07-28||[[PackagingDrafts/Removal_of_pre-built_binaries]]
+|pre-built binaries||oget||2009-07-28||[[PackagingDrafts/Removal_of_pre-built_binaries]]
 |-
-|announce||Phase out Buildroot||abadger1999||2009-06-02||https://fedoraproject.org/wiki/Phase_out_buildroot_tag_%28draft%29
+|Phase out Buildroot||abadger1999||2009-06-02||https://fedoraproject.org/wiki/Phase_out_buildroot_tag_%28draft%29
 |-
-|announce||Common Package Names||abadger1999||2009-04-14||[[Common package names packaging guideline draft]]
+|Common Package Names||abadger1999||2009-04-14||[[Common package names packaging guideline draft]]
 |-
-|announce||WordPress plugins||[[User:Ianweller|Ian Weller]]||2009-04-14||[[User:Ianweller/WordPress plugin packaging guidelines (draft)]]
+|WordPress plugins||[[User:Ianweller|Ian Weller]]||2009-04-14||[[User:Ianweller/WordPress plugin packaging guidelines (draft)]]
 |-
-|announce||Globus||ellert||2009-05-12||[[PackagingDrafts/Globus]] Draft packaging guidelines for packages from the Globus Toolkit.
+|Globus||ellert||2009-05-12||[[PackagingDrafts/Globus]] Draft packaging guidelines for packages from the Globus Toolkit.
 |-
-|announce||RPM handling of pkgconfig requires|| ajax, abadger1999 || 2009-12-02 || [[PackagingDrafts/PkgconfigAutoRequires|pkgconfig autorequires]] 
+|RPM handling of pkgconfig requires|| ajax, abadger1999 || 2009-12-02 || [[PackagingDrafts/PkgconfigAutoRequires|pkgconfig autorequires]] 
 |-
-|announce||Man pages|| FESCo, varekova|| ||[https://fedorahosted.org/fesco/ticket/291|FESCo ticket] [[Packaging:Guidelines#Man_pages Guideline]]
+|Man pages|| FESCo, varekova|| ||[https://fedorahosted.org/fesco/ticket/291|FESCo ticket] [[Packaging:Guidelines#Man_pages Guideline]]
 |-
-|announce||MPI packaging||[[User:jussilehtola|Jussi Lehtola]]||2009-08-12||[[PackagingDrafts/MPI]]
+|MPI packaging||[[User:jussilehtola|Jussi Lehtola]]||2009-08-12||[[PackagingDrafts/MPI]]
 |-
-|announce||Environment modules||[[User:jussilehtola|Jussi Lehtola]]||2009-08-12||[[PackagingDrafts/EnvironmentModules]]
+|Environment modules||[[User:jussilehtola|Jussi Lehtola]]||2009-08-12||[[PackagingDrafts/EnvironmentModules]]
 |-
-|announce||Filtering auto-provides||cweyl||2009-07-28||[[Packaging:AutoProvidesAndRequiresFiltering]]
+|Filtering auto-provides||cweyl||2009-07-28||[[Packaging:AutoProvidesAndRequiresFiltering]]
 |-
-|announce||Using Alternatives||[[User:Rathann|rathann]]||2009-04-14||[[PackagingDrafts/UsingAlternatives]]
+|Using Alternatives||[[User:Rathann|rathann]]||2009-04-14||[[PackagingDrafts/UsingAlternatives]]
 |-
-|announce||GConf scriptlets||abadger1999||2009-05-12||[[GConf Scriptlets (draft)]] Improve GConf scriplet handling.
+|GConf scriptlets||abadger1999||2009-05-12||[[GConf Scriptlets (draft)]] Improve GConf scriplet handling.
 |-
-|announce||RPath Relaxation||abadger1999||2009-10-07|| [[RPath Packaging Draft]]
+|RPath Relaxation||abadger1999||2009-10-07|| [[RPath Packaging Draft]]
 |-
-|announce||Directory ownership||notting||2009-10-07|| [[User:Notting/DirectoryDraft]]
+|Directory ownership||notting||2009-10-07|| [[User:Notting/DirectoryDraft]]
 |- 
-|announce||Revised Emacs add-on guidelines||[[User:jgu|jgu]]|| 2009-12-02 ||[[PackagingDrafts/EmacsPackagingRevised]]
+|Revised Emacs add-on guidelines||[[User:jgu|jgu]]|| 2009-12-02 ||[[PackagingDrafts/EmacsPackagingRevised]]
 |-
-|announce||PHP guidelines||[[User:Remi|Remi]]|| 2009-12-02 ||[[PackagingDrafts/PHP]]
+|PHP guidelines||[[User:Remi|Remi]]|| 2009-12-02 ||[[PackagingDrafts/PHP]]
 |-
-|announce||SRPM Buildtime macros||abadger1999||2010-02-03||[[SRPM_Buildtime_macros]]
+|SRPM Buildtime macros||abadger1999||2010-02-03||[[SRPM_Buildtime_macros]]
 |-
-|announce||Emphasize correct SF.net SourceURL||[[User:till]]||2010-02-03||[[PackagingDrafts/SourceURL_sourceforge_downloads_admonition]]
+|Emphasize correct SF.net SourceURL||[[User:till]]||2010-02-03||[[PackagingDrafts/SourceURL_sourceforge_downloads_admonition]]
 |-
-|announce||Python guideline update||abadger1999||2010-02-03 (vote taken on mailing list)|| https://fedoraproject.org/wiki/PackagingDrafts/Python3
-|}
-
-== Other TODO ==
-Emailed Jussi Lehtola about the required changes to packages listed which are still listed here: [[PackagingDrafts/Fortran]]
-
-
-
-{{:PackagingDrafts/DraftsTodo}}
-
-== Resolved items ==
-{| border="1"
-|- style="color: white; background-color: #3074c2; font-weight: bold" 
-|Task Name||Owner||Resolution Date||Notes
+|Python guideline update||abadger1999||2010-02-03 (vote taken on mailing list)|| https://fedoraproject.org/wiki/PackagingDrafts/Python3
 |-
 |Drop special provision for when Red Hat is upstream||mether||2009-08-20|| https://fedoraproject.org/wiki/No_more_exception_where_we_are_upstream%28draft%29 FESCo decided to drop this requirement.
 |-

From e309ecb1177ec6be04e830951a1dc7d867fa990e Mon Sep 17 00:00:00 2001
From: Spot 
Date: Mar 03 2010 21:54:38 +0000
Subject: [PATCH 500/3559] *Empty MediaWiki Message*


---

diff --git a/Packaging:GuidelinesTodo.mw b/Packaging:GuidelinesTodo.mw
index 39035a8..64a44c1 100644
--- a/Packaging:GuidelinesTodo.mw
+++ b/Packaging:GuidelinesTodo.mw
@@ -9,6 +9,9 @@ Status should be one of:
 |- style="color: white; background-color: #3074c2; font-weight: bold" 
 |Status||Task Name||Owner||Meeting Date||Notes
 |-
+|ratify||Complex Font Template fix||abadger1999||2010-02-24||[[Fix_Complex_Font_Template(draft)]]
+|-
+|ratify|| Which files to include in python modules ||abadger1999||2010-02-24||[[No_py_removal%28draft%29]]
 |}
 
 == Other TODO ==

From e1cdf85d1269d4d9407d7a1618f43e26e4d1c859 Mon Sep 17 00:00:00 2001
From: Tibbs 
Date: Mar 05 2010 17:15:41 +0000
Subject: [PATCH 501/3559] Remove link to now-pointless FullExceptionList page.


---

diff --git a/Packaging:Guidelines.mw b/Packaging:Guidelines.mw
index c0bfc72..ebe85c1 100644
--- a/Packaging:Guidelines.mw
+++ b/Packaging:Guidelines.mw
@@ -366,7 +366,7 @@ An example of this are the gettext and libgcj packages. gettext is usually a dev
 {{Anchor|Exceptions}}
 === Exceptions ===
 
-There is no need to include the following packages or their dependencies as BuildRequires because they would occur too often. These packages are considered the minimum build environment.  The derived list of all deps pulled in by this list is on [[Packaging:FullExceptionList]] .
+There is no need to include the following packages or their dependencies as BuildRequires because they would occur too often. These packages are considered the minimum build environment.
 
 
     bash
@@ -395,6 +395,7 @@ which
 
    
 
 {{Anchor|summary}}
+
 == Summary and description ==
 The summary should be a short and concise description of the package. The description expands upon this. Do not include installation instructions in the description; it is not a manual. If the package requires some manual configuration or there are other important instructions to the user, refer the user to the documentation in the package. Add a ''README.Fedora'', or similar, if you feel this is necessary. Also, please make sure that there are no lines in the description longer than 80 characters.
 

From 1a4290db345fd6f064130066918295e1872048ab Mon Sep 17 00:00:00 2001
From: Tibbs 
Date: Mar 05 2010 17:16:09 +0000
Subject: [PATCH 502/3559] Since there are two "Exceptions" sections in the guidelines, the link needs updating.


---

diff --git a/Packaging:FullExceptionList.mw b/Packaging:FullExceptionList.mw
index 879b9c6..a213d86 100644
--- a/Packaging:FullExceptionList.mw
+++ b/Packaging:FullExceptionList.mw
@@ -1,4 +1,4 @@
-This list is derived from [[Packaging:Guidelines#Exceptions]]  by resolving all deps. These are the packages you can safely assume will be present in a BuildRoot without being pulled in by a package's BuildRequires.
+This list is derived from [[Packaging:Guidelines#Exceptions_2]]  by resolving all deps. These are the packages you can safely assume will be present in a BuildRoot without being pulled in by a package's BuildRequires.
 
 List has been removed as it is variable across the collections.  If you need something that is '''A)''' not listed in the minimal list, and '''B)''' isn't brought in by something else you BuildRequire, you should list it as a BuildRequire just to be safe.
 

From b09907772c4642fbfbf17cfdf5c0f1188221b573 Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Mar 11 2010 14:59:31 +0000
Subject: [PATCH 503/3559] /* Collection of past random notes */


---

diff --git a/Packaging:UsersAndGroups.mw b/Packaging:UsersAndGroups.mw
index bd4c32a..459da00 100644
--- a/Packaging:UsersAndGroups.mw
+++ b/Packaging:UsersAndGroups.mw
@@ -38,3 +38,5 @@ Note that the practice of not creating users/groups if they exist has a drawback
 === Collection of past random notes ===
 
 Moved to PackagingDrafts/UsersAndGroupsThoughts (note that these are not part of this guideline).
+
+[[Category:Packaging guidelines]]

From f89361ba35310854f3b9f6848758e80361e4c983 Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Mar 19 2010 15:02:16 +0000
Subject: [PATCH 504/3559] Fix for py_byte_compile; temporary fix for modifying __os_install_post


---

diff --git a/Packaging:Python.mw b/Packaging:Python.mw
index d2f187a..a8da3bc 100644
--- a/Packaging:Python.mw
+++ b/Packaging:Python.mw
@@ -141,7 +141,7 @@ These settings are enough to properly byte compile any package that builds pytho
 
 
     # Turn off the brp-python-bytecompile script
-%global __os_install_post %(echo '%{__os_install_post}' | sed -e 's!/usr/lib[^[:space:]]*/brp-python-bytecompile!!g')
+%global __os_install_post %(echo '%{__os_install_post}' | sed -e 's!/usr/lib[^[:space:]]*/brp-python-bytecompile!/bin/true!g')
 # Buildrequire both python2 and python3
 BuildRequires: python2-devel python3-devel
 [...]
@@ -153,11 +153,13 @@ make install DESTDIR=%{buildroot}
 
 # Manually invoke the python byte compile macro for each path that needs byte
 # compilation.
-%{py_byte_compile} %{__python} %{buildroot}%{_datadir}/mypackage/foo
-%{py_byte_compile} %{__python3} %{buildroot}%{_datadir}/mypackage/bar
+%py_byte_compile %{__python} %{buildroot}%{_datadir}/mypackage/foo
+%py_byte_compile %{__python3} %{buildroot}%{_datadir}/mypackage/bar
 
    
 
-The %{py_byte_compile macro takes two arguments.  The first is the python interpreter to use for byte compiling.  The second is a file or directory to byte compile.  If the second argument is a directory, the macro will recursively byte compile any *.py file in the directory.
+The %py_byte_compile macro takes two arguments.  The first is the python interpreter to use for byte compiling.  The second is a file or directory to byte compile.  If the second argument is a directory, the macro will recursively byte compile any *.py file in the directory.
+
+{{admon/warning|No %{} for py_byte_compile|RPM macros can only take arguments when they do not have curly braces around them.  Therefore, py_byte_compile won't work correctly if you write: %{py_byte_compile} %{__python}}}
 
 === Including pyos ===
 In the past it was common practice to %ghost .pyo files in order to save a small amount of space on the users filesystem.  However, this has two issues:

From adf6ea65547d144374fce1fd90888aefae9a3ba7 Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Mar 19 2010 15:17:47 +0000
Subject: [PATCH 505/3559] Permanent fix for __os_install_post


---

diff --git a/Packaging:Python.mw b/Packaging:Python.mw
index a8da3bc..1bca842 100644
--- a/Packaging:Python.mw
+++ b/Packaging:Python.mw
@@ -141,7 +141,7 @@ These settings are enough to properly byte compile any package that builds pytho
 
 
     # Turn off the brp-python-bytecompile script
-%global __os_install_post %(echo '%{__os_install_post}' | sed -e 's!/usr/lib[^[:space:]]*/brp-python-bytecompile!/bin/true!g')
+%global __os_install_post %(echo '%{__os_install_post}' | sed -e 's!/usr/lib[^[:space:]]*/brp-python-bytecompile[[:space:]].*$!!g')
 # Buildrequire both python2 and python3
 BuildRequires: python2-devel python3-devel
 [...]

From 0252c67f1340f297011928f27dbdb03912a5ea51 Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Mar 19 2010 22:16:34 +0000
Subject: [PATCH 506/3559] Change pkgconfig check since we no longer need to Require: pkgconfig


---

diff --git a/Packaging:ReviewGuidelines.mw b/Packaging:ReviewGuidelines.mw
index 14d2945..36ff42e 100644
--- a/Packaging:ReviewGuidelines.mw
+++ b/Packaging:ReviewGuidelines.mw
@@ -46,7 +46,7 @@ There are many many things to check for a review. This list is provided to assis
 * '''MUST''': If a package includes something as %doc, it must not affect the runtime of the application. To summarize: If it is in %doc, the program must run properly if it is not present. [[Packaging/Guidelines#PackageDocumentation|Packaging Guidelines: Package Documentation]]
    
 * '''MUST''': Header files must be in a -devel package. [[Packaging/Guidelines#DevelPackages|Packaging Guidelines: Devel Packages]]
    
 * '''MUST''': Static libraries must be in a -static package. [[Packaging/Guidelines#StaticLibraries|Packaging Guidelines: Packaging Static Libraries]]
    
-* '''MUST''': Packages containing pkgconfig(.pc) files must 'Requires: pkgconfig' (for directory ownership and usability). [[Packaging/Guidelines#PkgconfigFiles|Packaging Guidelines: Pkgconfig Files]]
    
+* '''MUST''': pkgconfig(.pc) files belong in a -devel subpackage unless the package itself is for development.  [[Packaging/Guidelines#PkgconfigFiles|Packaging Guidelines: Pkgconfig Files]]
    
 * '''MUST''': If a package contains library files with a suffix (e.g. libfoo.so.1.1), then library files that end in .so (without suffix) must go in a -devel package. [[Packaging/Guidelines#DevelPackages|Packaging Guidelines: Devel Packages]]
    
 * '''MUST''': In the vast majority of cases, devel packages must require the base package using a fully versioned dependency: Requires: %{name} = %{version}-%{release}  [[Packaging/Guidelines#RequiringBasePackage|Packaging Guidelines: Requiring Base Package]]
    
 * '''MUST''': Packages must NOT contain any .la libtool archives, these must be removed in the spec if they are built.[[Packaging/Guidelines#StaticLibraries|Packaging Guidelines: Packaging Static Libraries]]
    

From ed0f90ce07afcf973127aa364c5cf5398bc9f5cd Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Mar 19 2010 22:21:55 +0000
Subject: [PATCH 507/3559] pkgconfig in -devel is already addressed i nthe should section


---

diff --git a/Packaging:ReviewGuidelines.mw b/Packaging:ReviewGuidelines.mw
index 36ff42e..75bc504 100644
--- a/Packaging:ReviewGuidelines.mw
+++ b/Packaging:ReviewGuidelines.mw
@@ -46,7 +46,6 @@ There are many many things to check for a review. This list is provided to assis
 * '''MUST''': If a package includes something as %doc, it must not affect the runtime of the application. To summarize: If it is in %doc, the program must run properly if it is not present. [[Packaging/Guidelines#PackageDocumentation|Packaging Guidelines: Package Documentation]]
    
 * '''MUST''': Header files must be in a -devel package. [[Packaging/Guidelines#DevelPackages|Packaging Guidelines: Devel Packages]]
    
 * '''MUST''': Static libraries must be in a -static package. [[Packaging/Guidelines#StaticLibraries|Packaging Guidelines: Packaging Static Libraries]]
    
-* '''MUST''': pkgconfig(.pc) files belong in a -devel subpackage unless the package itself is for development.  [[Packaging/Guidelines#PkgconfigFiles|Packaging Guidelines: Pkgconfig Files]]
    
 * '''MUST''': If a package contains library files with a suffix (e.g. libfoo.so.1.1), then library files that end in .so (without suffix) must go in a -devel package. [[Packaging/Guidelines#DevelPackages|Packaging Guidelines: Devel Packages]]
    
 * '''MUST''': In the vast majority of cases, devel packages must require the base package using a fully versioned dependency: Requires: %{name} = %{version}-%{release}  [[Packaging/Guidelines#RequiringBasePackage|Packaging Guidelines: Requiring Base Package]]
    
 * '''MUST''': Packages must NOT contain any .la libtool archives, these must be removed in the spec if they are built.[[Packaging/Guidelines#StaticLibraries|Packaging Guidelines: Packaging Static Libraries]]
    

From 266207c3bd6c596ddd24d890a4e02f4749df9128 Mon Sep 17 00:00:00 2001
From: Spot 
Date: Mar 23 2010 17:17:46 +0000
Subject: [PATCH 508/3559] /* GConf */


---

diff --git a/Packaging:Scriptlets.mw b/Packaging:Scriptlets.mw
index d81e318..3bec004 100644
--- a/Packaging:Scriptlets.mw
+++ b/Packaging:Scriptlets.mw
@@ -107,6 +107,7 @@ Unfortunately, this configure switch only works if the upstream packager has ada
 
 Here's the second part:
 
    +BuildRequires: GConf2
 Requires(pre): GConf2
 Requires(post): GConf2
 Requires(preun): GConf2

From c0108e069a004cb26160745dcd59b193e29d5d72 Mon Sep 17 00:00:00 2001
From: Tibbs 
Date: Apr 01 2010 18:17:10 +0000
Subject: [PATCH 509/3559] Clean up BuildRoot section and move the pre-F10 sections to the EPEL guidelines.


---

diff --git a/Packaging:Guidelines.mw b/Packaging:Guidelines.mw
index ebe85c1..4143f65 100644
--- a/Packaging:Guidelines.mw
+++ b/Packaging:Guidelines.mw
@@ -173,40 +173,13 @@ You must use one of the following formats:
 {{Anchor|BuildRoot}}
 
 == BuildRoot tag ==
-{{admon/note|The RPM in Fedora 10 defines a default buildroot so in Fedora 10 and above it is no longer necessary to define a buildroot tag. Fedora releases older than 10 and EPEL releases older than or equal to 5 still need to have the tag.}}
 
-The ''BuildRoot'' value MUST be below %{_tmppath}/ and MUST contain at least %{name}, %{version} and %{release}. It may invoke mktemp since this is guaranteed to exist on every system. From there, packagers are expected to use a sane ''BuildRoot''.
+Fedora (as of F-10) does not require the presence of the BuildRoot tag in the spec and if one is defined it will be ignored.  The provided buildroot will automatically be cleaned before commands in %install are called.
 
-The ''recommended'' values for the ''BuildRoot'' tag are (in descending order of preference) :
-
    -%(mktemp -ud %{_tmppath}/%{name}-%{version}-%{release}-XXXXXX)
-%{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
-%{_tmppath}/%{name}-%{version}-%{release}-root
-
    
-
-At one point, the second was a mandatory value, but it is now left to the packager to decide. If unsure, simply pick the first.
-
-{{Anchor|PreppingBuildRootForInstall}}
-=== Prepping BuildRoot For %install ===
-{{admon/note|The current redhat-rpm-config package in Fedora 10 and newer automatically deletes and creates the buildroot at %install, so in Fedora 10 and newer, it is not necessary for packages to manually Prepare the BuildRoot for install as described below. Fedora releases older than 10 and EPEL releases older than or equal to 5 still need to follow the below guidelines.}}
-
-It is important to properly prepare the ''BuildRoot'' in the %install section of your package before it is used. Every Fedora package MUST have an %install section that begins with either:
-
-
    -%install
-rm -rf %{buildroot}
-
    
-
-or
-
-
    -%install
-rm -rf $RPM_BUILD_ROOT
-
    
-
-This is to ensure that the ''BuildRoot'' will be created fresh during the %install section.
+{{admon/note|EPEL difference|rpm in EPEL5 and below require the BuildRoot tag and it must be manually cleaned in %install; follow the [[EPEL/GuidelinesAndPolicies#Distribution_specific_guidelines|EPEL Guidelines]].}}
 
 {{Anchor|Clean}}
+
 == %clean ==
 Each package must have a %clean section, which contains rm -rf %{buildroot} ([[Packaging:Guidelines#UsingBuildRootOptFlags|or $RPM_BUILD_ROOT]]).
    
 
    

From 8d928a50f652b50f3b9764606653b714a8d51271 Mon Sep 17 00:00:00 2001
From: Tibbs 
Date: Apr 01 2010 18:21:24 +0000
Subject: [PATCH 510/3559] Note that %clean is optional in F-13 and later.


---

diff --git a/Packaging:Guidelines.mw b/Packaging:Guidelines.mw
index 4143f65..cce5f0b 100644
--- a/Packaging:Guidelines.mw
+++ b/Packaging:Guidelines.mw
@@ -181,13 +181,10 @@ Fedora (as of F-10) does not require the presence of the BuildRoot tag in the sp
 {{Anchor|Clean}}
 
 == %clean ==
-Each package must have a %clean section, which contains rm -rf %{buildroot} ([[Packaging:Guidelines#UsingBuildRootOptFlags|or $RPM_BUILD_ROOT]]).
    
-
    
-In the past, some packages checked that %{buildroot} was not / before deleting it. This is not necessary in Fedora, for several reasons:
-* All Fedora packages are required to have a sane ''BuildRoot'', see: [[Packaging:Guidelines#BuildRoot]]
-* In Fedora 10 (and newer), rpm sets a sane ''BuildRoot'' by default (and ignores any spec defined ''BuildRoot'')
+The %clean section is not required for F-13 and above.  Each package for F-12 and below (or EPEL) MUST have a %clean section, which contains rm -rf %{buildroot} ([[Packaging:Guidelines#UsingBuildRootOptFlags|or $RPM_BUILD_ROOT]]).
    
 
 {{Anchor|Requires}}
+
 == Requires ==
 RPM has very good capabilities of automatically finding dependencies for libraries and eg. Perl modules. In short, don't reinvent the wheel, but just let rpm do its job. There is usually no need to explicitly list eg. Requires: libX11 when the dependency has already been picked up by rpm in the form of depending on libraries in the libX11 package.
 

From b52c80f91347fe9bd83d3f7a7054166dbc4f5449 Mon Sep 17 00:00:00 2001
From: Tibbs 
Date: Apr 01 2010 18:25:23 +0000
Subject: [PATCH 511/3559] Since the %clean section is optional in F-13 and there seems to be no provision for version-specific review, it shouldn't be listed as a MUST here.


---

diff --git a/Packaging:ReviewGuidelines.mw b/Packaging:ReviewGuidelines.mw
index 75bc504..f1b05c4 100644
--- a/Packaging:ReviewGuidelines.mw
+++ b/Packaging:ReviewGuidelines.mw
@@ -39,7 +39,6 @@ There are many many things to check for a review. This list is provided to assis
 * '''MUST''': A package must own all directories that it creates. If it does not create a directory that it uses, then it should require a package which does create that directory.  [[Packaging/Guidelines#FileAndDirectoryOwnership|Packaging Guidelines: File And Directory Ownership]]
    
 * '''MUST''': A Fedora package must not list a file more than once in the spec file's %files listings. [[Packaging/Guidelines#DuplicateFiles|Packaging Guidelines: Duplicate Files]]
    
 * '''MUST''': Permissions on files must be set properly. Executables should be set with executable permissions, for example. Every %files section must include a %defattr(...) line. [[Packaging/Guidelines#FilePermissions|Packaging Guidelines: File Permissions]]
    
-* '''MUST''': Each package must have a %clean section, which contains rm -rf %{buildroot} ([[Packaging/Guidelines#UsingBuildRootOptFlags|or $RPM_BUILD_ROOT]]). [[Packaging/Guidelines#clean|Packaging Guidelines: %clean]]
    
 * '''MUST''': Each package must consistently use macros. [[Packaging/Guidelines#macros|Packaging Guidelines: Macros]]
    
 * '''MUST''': The package must contain code, or permissable content. [[Packaging/Guidelines#CodeVsContent|Packaging Guidelines: Code Vs. Content]]
    
 * '''MUST''': Large documentation files must go in a -doc subpackage. (The definition of large is left up to the packager's best judgement, but is not restricted to size. Large can refer to either size or quantity). [[Packaging/Guidelines#PackageDocumentation|Packaging Guidelines: Package Documentation]]
    

From 2b95d5a4d8eec591cfb7cb319052455d153ef40b Mon Sep 17 00:00:00 2001
From: Rdieter 
Date: Apr 10 2010 22:57:57 +0000
Subject: [PATCH 512/3559] /* Architecture Build Failures */


---

diff --git a/Packaging:Guidelines.mw b/Packaging:Guidelines.mw
index cce5f0b..82d4674 100644
--- a/Packaging:Guidelines.mw
+++ b/Packaging:Guidelines.mw
@@ -100,7 +100,8 @@ If a Fedora package does not successfully compile, build or work on an architect
 * [https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=FE-ExcludeArch-x86 FE-ExcludeArch-x86]
 * [https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=FE-ExcludeArch-x64 FE-ExcludeArch-x64]
 * [https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=FE-ExcludeArch-ppc FE-ExcludeArch-ppc]
-* [https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=FE-ExcludeArch-ppc64 FE-ExcludeArch-ppc64]   
+* [https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=FE-ExcludeArch-ppc64 FE-ExcludeArch-ppc64]
+* [https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=F-ExcludeArch-sparc F-ExcludeArch-sparc]
 
 {{Anchor|layout}}
 

From a1ddc24627df49d5a913e3b386c6acc992d25152 Mon Sep 17 00:00:00 2001
From: Rdieter 
Date: Apr 10 2010 23:17:23 +0000
Subject: [PATCH 513/3559] /* Architecture Build Failures */


---

diff --git a/Packaging:Guidelines.mw b/Packaging:Guidelines.mw
index 82d4674..a7c914f 100644
--- a/Packaging:Guidelines.mw
+++ b/Packaging:Guidelines.mw
@@ -101,6 +101,8 @@ If a Fedora package does not successfully compile, build or work on an architect
 * [https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=FE-ExcludeArch-x64 FE-ExcludeArch-x64]
 * [https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=FE-ExcludeArch-ppc FE-ExcludeArch-ppc]
 * [https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=FE-ExcludeArch-ppc64 FE-ExcludeArch-ppc64]
+* [https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=F-ExcludeArch-arm F-ExcludeArch-arm]
+* [https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=F-ExcludeArch-s390x F-ExcludeArch-s390x]
 * [https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=F-ExcludeArch-sparc F-ExcludeArch-sparc]
 
 {{Anchor|layout}}

From 106ba4a7947d13316875ff4a4a31e6154529ffa6 Mon Sep 17 00:00:00 2001
From: Spot 
Date: Apr 15 2010 14:06:30 +0000
Subject: [PATCH 514/3559] /* Filesystem Layout */


---

diff --git a/Packaging:Guidelines.mw b/Packaging:Guidelines.mw
index a7c914f..4d3fa58 100644
--- a/Packaging:Guidelines.mw
+++ b/Packaging:Guidelines.mw
@@ -111,7 +111,7 @@ If a Fedora package does not successfully compile, build or work on an architect
 
 Fedora follows the [http://www.pathname.com/fhs/ Filesystem Hierarchy Standard]  with regards to filesystem layout. The FHS defines where files should be placed on the system. Fedora packages must follow the FHS. Any deviation from the FHS should be rationalized when the package is reviewed.
 
-There are notable exceptions to this guideline for libexecdir (as specified in the [[http://www.gnu.org/prep/standards/standards.html#Directory-Variables|GNU Coding Standards]]) and /usr/target for cross-compilers.
+There are notable exceptions to this guideline for libexecdir (as specified in the [http://www.gnu.org/prep/standards/standards.html#index-libexecdir-139|GNU Coding Standards]) and /usr/target for cross-compilers.
 
 {{Anchor|libexecdir}}
 === Libexecdir ===
@@ -120,6 +120,7 @@ The [http://www.pathname.com/fhs/ Filesystem Hierarchy Standard]  does not inclu
 Fedora's rpm includes a macro for libexecdir, %{_libexecdir}. Packagers are highly encouraged to store libexecdir files in a package-specific subdirectory of %{_libexecdir}, such as %{_libexecdir}/%{name}.
 
 {{Anchor|rpmlint}}
+
 == Use rpmlint ==
 Run rpmlint on the rpms to examine them for common errors, and fix them (unless rpmlint is wrong, which can happen, too). If you find rpmlint's output cryptic, the -i switch to it can be used to get more verbose descriptions of most errors and warnings. The rpmlint package is available in the Fedora repositories.
 

From 28154703ec5237158f513cd40cc16f2cd093ec5e Mon Sep 17 00:00:00 2001
From: Spot 
Date: Apr 15 2010 14:07:59 +0000
Subject: [PATCH 515/3559] /* Filesystem Layout */


---

diff --git a/Packaging:Guidelines.mw b/Packaging:Guidelines.mw
index 4d3fa58..ce19ba1 100644
--- a/Packaging:Guidelines.mw
+++ b/Packaging:Guidelines.mw
@@ -111,7 +111,7 @@ If a Fedora package does not successfully compile, build or work on an architect
 
 Fedora follows the [http://www.pathname.com/fhs/ Filesystem Hierarchy Standard]  with regards to filesystem layout. The FHS defines where files should be placed on the system. Fedora packages must follow the FHS. Any deviation from the FHS should be rationalized when the package is reviewed.
 
-There are notable exceptions to this guideline for libexecdir (as specified in the [http://www.gnu.org/prep/standards/standards.html#index-libexecdir-139|GNU Coding Standards]) and /usr/target for cross-compilers.
+There are notable exceptions to this guideline for libexecdir (as specified in the [http://www.gnu.org/prep/standards/standards.html#index-libexecdir-139 GNU Coding Standards]) and /usr/target for cross-compilers.
 
 {{Anchor|libexecdir}}
 === Libexecdir ===

From 947bdd7a7036bee1e114a09f8fe42723d586604f Mon Sep 17 00:00:00 2001
From: Spot 
Date: Apr 15 2010 14:21:13 +0000
Subject: [PATCH 516/3559] *Empty MediaWiki Message*


---

diff --git a/Packaging:Python.mw b/Packaging:Python.mw
index 1bca842..32cabfa 100644
--- a/Packaging:Python.mw
+++ b/Packaging:Python.mw
@@ -16,7 +16,7 @@ python modules using these runtimes should have a corresponding "Requires" line 
 
 {{admon/warning|Test your work| Remember to test the built RPMs and verify that they actually work!  For instance, when you're packaging a python module that builds for both python2 and python3, don't test the python2 module but ship the python3 module without testing that it does what it's supposed to.  If you are requesting that an application '''switch''' from Python 2 to Python 3 for its Python implementation, please provide supporting material (e.g. a list of tests performed, and their outcome).  Simply getting a package to build against Python 3 is no guarantee that the package's functionality still works.}}
 
-{{admon/note|For packagers of the python interpreter|Unlike the Requires lines, the "Provides" for each runtime are manually entered into the specfile for each runtime.  In theory /usr/lib/rpm/pythondeps.sh would also automatically generate "Provides" lines for the runtime, but in practice rpmbuild only invokes it for files in the rpm payload identified as "python" by the file utility, and the runtime is an ELF binary, not a python script, hence it isn't passed.  It's simplest to manually supply the Provides line, rather than change these innards of rpmbuild.  See [[https://bugzilla.redhat.com/show_bug.cgi?id=532118 bug 532118]].}}
+{{admon/note|For packagers of the python interpreter|Unlike the Requires lines, the "Provides" for each runtime are manually entered into the specfile for each runtime.  In theory /usr/lib/rpm/pythondeps.sh would also automatically generate "Provides" lines for the runtime, but in practice rpmbuild only invokes it for files in the rpm payload identified as "python" by the file utility, and the runtime is an ELF binary, not a python script, hence it isn't passed.  It's simplest to manually supply the Provides line, rather than change these innards of rpmbuild.  See [[rhbug:532118|Red Hat Bug 532118]].}}
 
 == BuildRequires ==
 To build a package containing python2 files, you need to have
@@ -116,7 +116,7 @@ Or even:
 
 {{admon/warning|Avoid INSTALLED_FILES|python's distutils has an INSTALLED_FILES feature that lists which files are installed when you run python setup.py install.  Do not use it for packaging as that will not list the directories which need to be specified in the %files section as well. Using globs in the %files section is simpler and safer.}}
 
-{{admon/warning|Including egg info|When you run %{__python} setup.py install in any current Fedora, distutils generates a .egg-info file with metadata about the python module that is installed.  These files need to be included as well. (See [#Packaging_eggs_and_setuptools_concerns])}}
+{{admon/warning|Including egg info|When you run %{__python} setup.py install in any current Fedora, distutils generates a .egg-info file with metadata about the python module that is installed.  These files need to be included as well. (See [https://fedoraproject.org/wiki/Packaging:Python#Packaging_eggs_and_setuptools_concerns Packaging eggs and setuptools concerns] )}}
 
 === Bytecompiling with the correct python version ===
 
@@ -174,7 +174,7 @@ The current method of dealing with pyo files is to '''include them as is; no %gh
 
 Many times when you package a python module you will want to create a module for python2 and a module for python3.  There are two ways of doing this: either from a single SRPM or from multiple.  The rule to choose which method is simple: if the python2 and python3 modules are distributed as a single tarball (many times as a single directory of source where the /usr/bin/2to3 program is used to transform the code at buildtime) then you must package them as subpackages built from a single SRPM.  If they come in multiple tarballs then package them from multiple SRPMs.
 
-{{admon/note|Python Bindings|python bindings are sometimes built as part of the C library's build.  The ideal for these is to patch the code so it will build against both python2 and python3.  Then take a copy of the sources during the %prep phase, and configure one subdirectory to build against python 2, another to build against python 3.  These changes should be upstreamed.  Example: the build of rpm itself emits an rpm-python subpackage (see [[https://bugzilla.redhat.com/show_bug.cgi?id=531543  bug 531543]])}}
+{{admon/note|Python Bindings|python bindings are sometimes built as part of the C library's build.  The ideal for these is to patch the code so it will build against both python2 and python3.  Then take a copy of the sources during the %prep phase, and configure one subdirectory to build against python 2, another to build against python 3.  These changes should be upstreamed.  Example: the build of rpm itself emits an rpm-python subpackage (see [[rhbug:531543|Red Hat Bug 531543]].)}}
 
 === Multiple SRPMS ===
 

From 35a5ed8f0842ed137b8f8d1fb68218ce95f4861a Mon Sep 17 00:00:00 2001
From: Tibbs 
Date: Apr 18 2010 15:09:59 +0000
Subject: [PATCH 517/3559] Remove requirement to clean the buildroot; I missed that when I made my last edit.


---

diff --git a/Packaging:ReviewGuidelines.mw b/Packaging:ReviewGuidelines.mw
index f1b05c4..c06d21b 100644
--- a/Packaging:ReviewGuidelines.mw
+++ b/Packaging:ReviewGuidelines.mw
@@ -50,7 +50,6 @@ There are many many things to check for a review. This list is provided to assis
 * '''MUST''': Packages must NOT contain any .la libtool archives, these must be removed in the spec if they are built.[[Packaging/Guidelines#StaticLibraries|Packaging Guidelines: Packaging Static Libraries]]
    
 * '''MUST''': Packages containing GUI applications must include a %{name}.desktop file, and that file must be properly installed with desktop-file-install in the %install section. If you feel that your packaged GUI application does not need a .desktop file, you must put a comment in the spec file with your explanation. [[Packaging/Guidelines#desktop|Packaging Guidelines: Desktop files]]
    
 * '''MUST''': Packages must not own files or directories already owned by other packages. The rule of thumb here is that the first package to be installed should own the files or directories that other packages may rely upon. This means, for example, that no package in Fedora should ever share ownership with any of the files or directories owned by the filesystem or man package. If you feel that you have a good reason to own a file or directory that another package owns, then please present that at package review time. [[Packaging/Guidelines#FileAndDirectoryOwnership|Packaging Guidelines: File And Directory Ownership]]
    
-* '''MUST''': At the beginning of %install, each package MUST run rm -rf %{buildroot} ([[Packaging/Guidelines#UsingBuildRootOptFlags|or $RPM_BUILD_ROOT]]). [[Packaging/Guidelines#PreppingBuildRootForInstall|Packaging Guidelines: Prepping BuildRoot For %install]]
    
 * '''MUST''': All filenames in rpm packages must be valid UTF-8. [[Packaging/Guidelines#FilenameEncoding|Packaging Guidelines: Filename Encoding]]
    
 
 
    

From d0cf0f807c9366043bc19dcfe41103848e1c0348 Mon Sep 17 00:00:00 2001
From: Spot 
Date: Apr 22 2010 15:18:47 +0000
Subject: [PATCH 518/3559] /* Handling Locale Files */


---

diff --git a/Packaging:Guidelines.mw b/Packaging:Guidelines.mw
index ce19ba1..7a7f540 100644
--- a/Packaging:Guidelines.mw
+++ b/Packaging:Guidelines.mw
@@ -718,13 +718,14 @@ Here is an example of proper usage of %find_lang, in foo.spec
 
 %build
 %configure --with-cheese
+make %{?_smp_mflags}
 
 %install
-make DESTDIR=$RPM_BUILD_ROOT install
+make DESTDIR=%{buildroot} install
 %find_lang %{name}
 
 %clean
-rm -rf $RPM_BUILD_ROOT
+rm -rf %{buildroot}
 
 %files -f %{name}.lang
 %defattr(-,root,root,-)
@@ -757,6 +758,7 @@ Using %find_lang helps keep the spec file simple, and helps avoid s
 Keep in mind that usage of %find_lang in packages containing locales is a MUST.
 
 {{Anchor|Timestamps}}
+
 == Timestamps ==
 When adding file copying commands in the spec file, consider using a command that preserves the files' timestamps, eg. cp -p or install -p.
 

From 47fa3b5212a4bde1187f4f572920eb4bad07f92d Mon Sep 17 00:00:00 2001
From: Toshio 
Date: May 07 2010 13:17:36 +0000
Subject: [PATCH 519/3559] Fix typo


---

diff --git a/Packaging:Python.mw b/Packaging:Python.mw
index 32cabfa..ce334eb 100644
--- a/Packaging:Python.mw
+++ b/Packaging:Python.mw
@@ -120,7 +120,7 @@ Or even:
 
 === Bytecompiling with the correct python version ===
 
-When byte compiling a .py file, python embeds a magic number in the byte compiled files that correspond to the runtime.  Files in {%python_sitelib} and %{python_sitearch} must correspond to the runtime for which they were built.  For instance, a pure python module compiled for the 3.1 runtime needs to be below %{_usr}/lib/python3.1/site-packages
+When byte compiling a .py file, python embeds a magic number in the byte compiled files that correspond to the runtime.  Files in %{python_sitelib} and %{python_sitearch} must correspond to the runtime for which they were built.  For instance, a pure python module compiled for the 3.1 runtime needs to be below %{_usr}/lib/python3.1/site-packages
 
 The brp-python-bytecompile script tries to figure this out for you.  The script determines which interpreter to use when byte compiling the module by following these steps:
 

From 0876ccc4a109856cc466e34979aae3ba96690fc2 Mon Sep 17 00:00:00 2001
From: Toshio 
Date: May 07 2010 13:21:27 +0000
Subject: [PATCH 520/3559] Fix another typo -- missing {


---

diff --git a/Packaging:Python.mw b/Packaging:Python.mw
index ce334eb..1889897 100644
--- a/Packaging:Python.mw
+++ b/Packaging:Python.mw
@@ -387,7 +387,7 @@ rm -rf $RPM_BUILD_ROOT
 %changelog
 
    
 
-In this final section, you can see that we once again switch macros from %python_sitelib} to %{python3_sitelib}.  Since we chose to install the python2 version of %{_bindir}/easy_install earlier we need to include that file in the python2 package rather than the python3 subpackage.
+In this final section, you can see that we once again switch macros from %{python_sitelib} to %{python3_sitelib}.  Since we chose to install the python2 version of %{_bindir}/easy_install earlier we need to include that file in the python2 package rather than the python3 subpackage.
 
 ==== Running 2to3 from the spec file ====
 Sometimes, upstream hasn't integrated running 2to3 on the code into their build scripts but they support making a python3 module from it if you manually run 2to3 on the source.  This is the case when it's documented on the upstream's website, in a file in the tarball, or even when email with the module's author has instructions for building a python3 module from the python2 source and the authors are willing to support the result.  In these cases it's usually just a matter of the upstream not having written the build script that can turn the python2 source into python3.  When this happens you can run 2to3 from the spec file.  Once you have it working, you can also help upstream integrate it into their build scripts which will benefit everyone in the long term.

From 984762cb35076035f57960c3bf4986edd43f29e3 Mon Sep 17 00:00:00 2001
From: Spot 
Date: May 11 2010 13:15:55 +0000
Subject: [PATCH 521/3559] remove pointless post,postun Requires


---

diff --git a/Packaging:R.mw b/Packaging:R.mw
index c78313f..f585209 100644
--- a/Packaging:R.mw
+++ b/Packaging:R.mw
@@ -38,8 +38,7 @@ Group:            Applications/Engineering
 Summary:          Adds foo functionality for R
 BuildRequires:    R-devel, tex(latex)
 BuildRoot:        %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
-Requires(post):   R-core
-Requires(postun): R-core
+Requires:         R-core
 
 %description
 R Interface to foo, enables bar!
@@ -98,8 +97,6 @@ Summary:          Adds foo functionality for R
 BuildRequires:    R-devel, tex(latex)
 BuildRoot:        %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
 BuildArch:        noarch
-Requires(post):   R-core
-Requires(postun): R-core
 Requires:         R-core
 
 %description

From 40c9c4926f21e234fdc5549bac969c948b7713bc Mon Sep 17 00:00:00 2001
From: Spot 
Date: May 13 2010 14:27:32 +0000
Subject: [PATCH 522/3559] /* Action Items */


---

diff --git a/Packaging:GuidelinesTodo.mw b/Packaging:GuidelinesTodo.mw
index 64a44c1..93ab827 100644
--- a/Packaging:GuidelinesTodo.mw
+++ b/Packaging:GuidelinesTodo.mw
@@ -9,9 +9,11 @@ Status should be one of:
 |- style="color: white; background-color: #3074c2; font-weight: bold" 
 |Status||Task Name||Owner||Meeting Date||Notes
 |-
-|ratify||Complex Font Template fix||abadger1999||2010-02-24||[[Fix_Complex_Font_Template(draft)]]
+|writeup||Complex Font Template fix||abadger1999||2010-02-24||[[Fix_Complex_Font_Template(draft)]]
 |-
-|ratify|| Which files to include in python modules ||abadger1999||2010-02-24||[[No_py_removal%28draft%29]]
+|writeup|| Which files to include in python modules ||abadger1999||2010-02-24||[[No_py_removal%28draft%29]]
+|-
+|ratify|| RPMMacros improvements || [[User:till]]||2010-05-12|| [[PackagingDrafts/RPMMacros_sharedstatedir_optflags_and_admonitions]]
 |}
 
 == Other TODO ==

From e379fd4621b1eb840b8a3327763bb7dce859bf26 Mon Sep 17 00:00:00 2001
From: Toshio 
Date: May 17 2010 15:39:51 +0000
Subject: [PATCH 523/3559] System runtime updated


---

diff --git a/Packaging:Python.mw b/Packaging:Python.mw
index 1889897..59e8595 100644
--- a/Packaging:Python.mw
+++ b/Packaging:Python.mw
@@ -4,9 +4,7 @@ In Fedora we have multiple python runtimes, one for each supported major release
 
 Each runtime corresponds to a binary of the form /usr/bin/python$MAJOR.$MINOR
 
-One of these python runtimes is the "system runtime".  It can be identified by the destination of the symlink /usr/bin/python.  Currently this is /usr/bin/python-2.6
-
-{{admon/note||Currently /usr/bin/python is actually a duplicate copy of the ELF file, rather than a symlink.  This shouldn't cause any problems for packagers of python modules but we see this as [[https://bugzilla.redhat.com/show_bug.cgi?id=556970 a bug]] that needs fixing.}}
+One of these python runtimes is the "system runtime" which is what we run when invoking /usr/bin/python.  On Fedora 13 this is /usr/bin/python-2.6
 
 All python runtimes have a virtual provide for python(abi) = $MAJOR-$MINOR.  For example, the python-3.1 runtime rpm has:
   $ rpm -q --provides python3 |grep -i abi

From 36c0cc873c634045d7f72beb0e72323668f8023d Mon Sep 17 00:00:00 2001
From: Spot 
Date: May 18 2010 18:11:39 +0000
Subject: [PATCH 524/3559] *Empty MediaWiki Message*


---

diff --git a/Packaging:GuidelinesTodo.mw b/Packaging:GuidelinesTodo.mw
index 93ab827..ec0dca9 100644
--- a/Packaging:GuidelinesTodo.mw
+++ b/Packaging:GuidelinesTodo.mw
@@ -13,7 +13,7 @@ Status should be one of:
 |-
 |writeup|| Which files to include in python modules ||abadger1999||2010-02-24||[[No_py_removal%28draft%29]]
 |-
-|ratify|| RPMMacros improvements || [[User:till]]||2010-05-12|| [[PackagingDrafts/RPMMacros_sharedstatedir_optflags_and_admonitions]]
+|writeup|| RPMMacros improvements || [[User:till]]||2010-05-12|| [[PackagingDrafts/RPMMacros_sharedstatedir_optflags_and_admonitions]]
 |}
 
 == Other TODO ==

From 4c476f48aa50a4325bc78079990cd6cc83f27ef9 Mon Sep 17 00:00:00 2001
From: Tibbs 
Date: May 19 2010 03:51:45 +0000
Subject: [PATCH 525/3559] Add el6 and fc13.


---

diff --git a/Packaging:DistTag.mw b/Packaging:DistTag.mw
index 411f812..a991048 100644
--- a/Packaging:DistTag.mw
+++ b/Packaging:DistTag.mw
@@ -44,6 +44,7 @@ Red Hat Enterprise Linux:
 3 (all variants): .el3
 4 (all variants): .el4
 5 (all variants): .el5
+6 (all variants): .el6
 
 Fedora, Fedora Core:
 1: .fc1
@@ -58,6 +59,7 @@ Fedora, Fedora Core:
 10: .fc10
 11: .fc11
 12: .fc12
+13: .fc13
 
 Development:
 

From 0382fb3b768fe4ee633bd5bf8c86518cee0ed4dc Mon Sep 17 00:00:00 2001
From: Tibbs 
Date: May 19 2010 03:52:32 +0000
Subject: [PATCH 526/3559] Remove incorrect "not currently used" note.


---

diff --git a/Packaging:DistTag.mw b/Packaging:DistTag.mw
index a991048..7d45a9f 100644
--- a/Packaging:DistTag.mw
+++ b/Packaging:DistTag.mw
@@ -96,7 +96,7 @@ Keep in mind that %{dist} should '''never''' be used in the Name or
 
 Along with %{dist}, there are several "helper" variables defined by the buildsystem. These variables are:
 
-%{rhel}: This variable is only defined on Red Hat Enterprise Linux builds. If defined, it is set to the release number of Red Hat Enterprise Linux present at build time. (Not currently used.)
+%{rhel}: This variable is only defined on Red Hat Enterprise Linux builds. If defined, it is set to the release number of Red Hat Enterprise Linux present at build time.
 
 %{fedora}: This variable is only defined on Fedora builds. If defined, it is set to the release number of Fedora present at build time.
 

From db8594e9b93a8e8d746ed918484d12bb9ab55cf0 Mon Sep 17 00:00:00 2001
From: Toshio 
Date: May 19 2010 17:15:50 +0000
Subject: [PATCH 527/3559] Update from draft


---

diff --git a/Packaging:RPMMacros.mw b/Packaging:RPMMacros.mw
index 7b5ee86..1a01cf7 100644
--- a/Packaging:RPMMacros.mw
+++ b/Packaging:RPMMacros.mw
@@ -1,7 +1,6 @@
+== Valid RPM Macros ==
 
-= Valid RPM Macros =
-
-Here are the definitions for some common specfile macros as they are defined on Fedora Core 11 (rpm-4.7.0-1.fc11). For definitions of more macros, examine the output of "rpm --showrc". To see the expanded definition of a macro use the command rpm --eval "%{macro}".  Note that neither command will take into account macros defined inside specfiles, but both will take into account macros defined in your ~/.rpmmacros file and macros defined on the command line.
+Here are the definitions for some common specfile macros as they are defined on Fedora 13 (rpm-4.8.0-14.fc13). For definitions of more macros, examine the output of "rpm --showrc". To see the expanded definition of a macro use the command rpm --eval "%{macro}".  Note that neither command will take into account macros defined inside specfiles, but both will take into account macros defined in your ~/.rpmmacros file and macros defined on the command line.
 
 Keep in mind that some of these macros may evaluate differently on older Fedora or EPEL releases. 
 
@@ -11,22 +10,48 @@ Keep in mind that some of these macros may evaluate differently on older Fedora 
 %{_prefix}            /usr
 %{_exec_prefix}       %{_prefix}
 %{_bindir}            %{_exec_prefix}/bin
-%{_lib}               lib (lib64 on 64bit systems)
 %{_libdir}            %{_exec_prefix}/%{_lib}
 %{_libexecdir}        %{_exec_prefix}/libexec
 %{_sbindir}           %{_exec_prefix}/sbin
 %{_sharedstatedir}    /var/lib
-%{_datadir}           %{_prefix}/share
+%{_datarootdir}       %{_prefix}/share
+%{_datadir}           %{_datarootdir}
 %{_includedir}        %{_prefix}/include
-%{_oldincludedir}     /usr/include
 %{_infodir}           /usr/share/info
 %{_mandir}            /usr/share/man
 %{_localstatedir}     /var
 %{_initddir}          %{_sysconfdir}/rc.d/init.d
 
    
-Note: On releases older than Fedora 10 (and EPEL), %{_initddir} does not exist. Instead, you should use the deprecated %{_initrddir} macro.
+{{admon/important|Differences in EPEL 4 & 5|
+* %{_initddir} does not exist in EPEL 4 & 5, use the deprecated %{_initrddir} macro instead
+* %{_sharedstatedir} expands to %{_prefix}/com in EPEL 4 & 5
+}}
+
+=== Other macros and variables for paths ===
+These macros should be used for paths that are not covered by the macros mimicking autoconf variables. The %{_buildroot} macro or the $RPM_BUILD_ROOT variable is the directory that should be assumed to be the root file system when installing files. Is is used as the value for the DESTDIR variable.
+
    +%{_var}               /var
+%{_tmppath}           %{_var}/tmp
+%{_usr}               /usr
+%{_usrsrc}            %{_usr}/src
+%{_lib}               lib (lib64 on 64bit multilib systems)
+%{_docdir}            %{_datadir}/doc
+%{buildroot}          %{_buildrootdir}/%{name}-%{version}-%{release}.%{_arch}
+$RPM_BUILD_ROOT       %{buildroot}
+
    
+
+=== Build flags macros and variables ===
+These macros should be used as flags for the compiler or linker. Note that the values for the macros below reflect the settings on Fedora 13 (i686) with redhat-rpm-config installed.
+
+
    +%{__global_cflags}   -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4
+%{optflags}          %{__global_cflags} -m32 -march=i686 -mtune=atom -fasynchronous-unwind-tables
+$RPM_OPT_FLAGS       %{optflags}
+
    
+
 
 === RPM directory macros ===
+The macros are usually used with rpmbuild --define to specify which directories rpmbuild should use, it is unusual to use them within SPEC files.
 
     %{_topdir}            %{getenv:HOME}/rpmbuild
 %{_builddir}          %{_topdir}/BUILD
@@ -36,28 +61,8 @@ Note: On releases older than Fedora 10 (and EPEL), %{_initddir} doe
 %{_srcrpmdir}         %{_topdir}/SRPMS
 %{_buildrootdir}      %{_topdir}/BUILDROOT
 
    
-Note: On releases older than Fedora 10 (and EPEL), %{_buildrootdir} does not exist.
-
-=== Build flags macros ===
-
    -%{_global_cflags}     -O2 -g -pipe
-%{_optflags}          %{__global_cflags} -m32 -march=i386 -mtune=pentium4 # if redhat-rpm-config is installed
-
    
-
-=== Other macros ===
-
    -%{_var}               /var
-%{_tmppath}           %{_var}/tmp
-%{_usr}               /usr
-%{_usrsrc}            %{_usr}/src
-%{_docdir}            %{_datadir}/doc
-
    
-
-== Reference ==
-Here are macros from other distributions to aid you in package conversion:
-
-* [[Extras/ReferencePLDRPMMacros| PLD RPM Macros]] 
-* [[Extras/ReferenceMandrakeRPMMacros| Mandrake RPM Macros]] 
-----
+{{admon/important|Differences in EPEL 4 & 5|
+* %{_buildrootdir} does not exist in EPEL 4 & 5
+}}
 
 [[Categories:Packaging guidelines]]

From 6258252290e06d85461f54acda1ad5dd5dfbbb13 Mon Sep 17 00:00:00 2001
From: Toshio 
Date: May 19 2010 17:18:52 +0000
Subject: [PATCH 528/3559] Correct category


---

diff --git a/Packaging:RPMMacros.mw b/Packaging:RPMMacros.mw
index 1a01cf7..29f5457 100644
--- a/Packaging:RPMMacros.mw
+++ b/Packaging:RPMMacros.mw
@@ -65,4 +65,4 @@ The macros are usually used with rpmbuild --define to specify which
 * %{_buildrootdir} does not exist in EPEL 4 & 5
 }}
 
-[[Categories:Packaging guidelines]]
+[[Category:Packaging guidelines]]

From 6b3315d2c37770fe4430b1ca14d9e9f96e946094 Mon Sep 17 00:00:00 2001
From: Toshio 
Date: May 19 2010 17:22:21 +0000
Subject: [PATCH 529/3559] /* Action Items */


---

diff --git a/Packaging:GuidelinesTodo.mw b/Packaging:GuidelinesTodo.mw
index ec0dca9..15d1637 100644
--- a/Packaging:GuidelinesTodo.mw
+++ b/Packaging:GuidelinesTodo.mw
@@ -13,7 +13,7 @@ Status should be one of:
 |-
 |writeup|| Which files to include in python modules ||abadger1999||2010-02-24||[[No_py_removal%28draft%29]]
 |-
-|writeup|| RPMMacros improvements || [[User:till]]||2010-05-12|| [[PackagingDrafts/RPMMacros_sharedstatedir_optflags_and_admonitions]]
+|announce|| RPMMacros improvements || [[User:till]]||2010-05-12|| [[PackagingDrafts/RPMMacros_sharedstatedir_optflags_and_admonitions]]
 |}
 
 == Other TODO ==

From f9db6571935a5fd76f1a64f35155081760fcb654 Mon Sep 17 00:00:00 2001
From: Toshio 
Date: May 19 2010 17:24:15 +0000
Subject: [PATCH 530/3559] /* Byte compiling */


---

diff --git a/Packaging:Python.mw b/Packaging:Python.mw
index 59e8595..543a6d8 100644
--- a/Packaging:Python.mw
+++ b/Packaging:Python.mw
@@ -83,6 +83,22 @@ Using the macros has several benefits.
 
  • Using these macros instead of hardcoding the directory in the specfile ensures your spec remains compatible with the installed python version even if the directory structure changes radically (for instance, if python_sitelib moves into %{_datadir})
    • 
 
 
+== Files to include ==
+When installing python modules we include several different types of files.
+
      
+
    • *.py source files because they are used when generating tracebacks
      • 
+
    • *.pyc and *.pyo byte compiled files
+
      • python will try to create them at runtime if they don't exist which leads to spurious SELinux AVC denials in the logs
        • 
+
      • If the system administrator invokes python with -OO, .pyos will be created with no docstrings.  This can break some programs.
        • 
+
      
+
    • *.egg-info files or directories.  If these are generated by the module's build scripts they must be included in the package because they might be needed by other applications and modules at runtime.
      •  
+
    
+
+== Source files == 
+
+Source files (*.py) must be included in the same packages as the byte-compiled
+versions of them.
+
 == Byte compiling ==
 
 Python will automatically try to byte compile files when it runs in order to speed up startup the next time it is run.  These files are saved in files with the extension of .pyc (compiled python) or .pyo (optimized compiled python).  These files are a byte code that is portable across OSes.  If you do not include them in your packages, python will try to create them when the user runs the program.  If the system administrator uses them, then the files will be successfully written.  Later, when the package is removed, the .pyc and .pyo files will be left behind on the filesystem.  To prevent that the byte compiled files need to be compiled and included in the %files section.  Normally, byte compilation is done for you by the brp-python-bytecompile script. This script runs after the %install section of the spec file has been processed and byte compiles any .py files that it finds (this recompilation puts the proper filesystem paths into the modules otherwise tracebacks would include the %{buildroot} in them).  All that you need to do is include the files in the %files section.  The following are all acceptable ways to accomplish this:

From 347a746db7ce1b55b0dea9006d622a1616bd6e05 Mon Sep 17 00:00:00 2001
From: Toshio 
Date: May 19 2010 17:25:31 +0000
Subject: [PATCH 531/3559] Egginfo inclusion moved to a different section


---

diff --git a/Packaging:Python.mw b/Packaging:Python.mw
index 543a6d8..a20c934 100644
--- a/Packaging:Python.mw
+++ b/Packaging:Python.mw
@@ -485,7 +485,6 @@ The following are a summary of the guidelines for reviewers to go over when a py
 
 * '''Must''': Python eggs must be built from source.  They cannot simply drop an egg from upstream into the proper directory. (See [[Packaging:Guidelines#No_inclusion_of_pre-built_binaries_or_libraries| prebuilt binaries Guidelines]] for details)
 * '''Must''': Python eggs must not download any dependencies during the build process.
-* '''Must''': If egg-info files are generated by the module's build scripts they must be included in the package.
 * '''Must''': When building a compat package, it must install using easy_install -m so it won't conflict with the main package.
 * '''Must''': When building multiple versions (for a compat package) one of the packages must contain a default version that is usable via "import MODULE" with no prior setup.
 * '''Should''': A package which is used by another package via an egg interface should provide egg info.

From 71785f7352f93234c100f2681193b6ab4399b2d1 Mon Sep 17 00:00:00 2001
From: Toshio 
Date: May 19 2010 17:26:35 +0000
Subject: [PATCH 532/3559] Moved to files to include section


---

diff --git a/Packaging:Python.mw b/Packaging:Python.mw
index a20c934..384cf2c 100644
--- a/Packaging:Python.mw
+++ b/Packaging:Python.mw
@@ -175,14 +175,7 @@ The %py_byte_compile macro takes two arguments.  The first is the p
 
 {{admon/warning|No %{} for py_byte_compile|RPM macros can only take arguments when they do not have curly braces around them.  Therefore, py_byte_compile won't work correctly if you write: %{py_byte_compile} %{__python}}}
 
-=== Including pyos ===
-In the past it was common practice to %ghost .pyo files in order to save a small amount of space on the users filesystem.  However, this has two issues:
-
      
-
    1. With SELinux, if a user is running python -O [APP]  it will try to write the .pyos when they don't exist.  This leads to AVC denial records in the logs.
      2. 
-
    2. If the system administrator runs python -OO [APP]  the .pyos will get created with no docstrings.  Some programs require docstrings in order to function.  On subsequent runs with python -O [APP]  python will use the cached .pyos even though a different optimization level has been requested.  The only way to fix this is to find out where the .pyos are and delete them.
      3. 
-
    
 
-The current method of dealing with pyo files is to '''include them as is; no %ghosting'''.
 
 == Common SRPM vs split SRPMs ==
 

From ba57b74212760059a3baaf212ba12b3f267c1dbd Mon Sep 17 00:00:00 2001
From: Toshio 
Date: May 19 2010 17:36:15 +0000
Subject: [PATCH 533/3559] All action items written up


---

diff --git a/Packaging:GuidelinesTodo.mw b/Packaging:GuidelinesTodo.mw
index 15d1637..1f8536b 100644
--- a/Packaging:GuidelinesTodo.mw
+++ b/Packaging:GuidelinesTodo.mw
@@ -9,9 +9,9 @@ Status should be one of:
 |- style="color: white; background-color: #3074c2; font-weight: bold" 
 |Status||Task Name||Owner||Meeting Date||Notes
 |-
-|writeup||Complex Font Template fix||abadger1999||2010-02-24||[[Fix_Complex_Font_Template(draft)]]
+|announce||Complex Font Template fix||abadger1999||2010-02-24||[[Fix_Complex_Font_Template(draft)]]
 |-
-|writeup|| Which files to include in python modules ||abadger1999||2010-02-24||[[No_py_removal%28draft%29]]
+|announce|| Which files to include in python modules ||abadger1999||2010-02-24||[[No_py_removal%28draft%29]]
 |-
 |announce|| RPMMacros improvements || [[User:till]]||2010-05-12|| [[PackagingDrafts/RPMMacros_sharedstatedir_optflags_and_admonitions]]
 |}

From 5aec31a5b781f0559cf06ce3708e898b1868a6b8 Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Jun 09 2010 15:01:30 +0000
Subject: [PATCH 534/3559] add yaboot static lib exception


---

diff --git a/Packaging:Guidelines.mw b/Packaging:Guidelines.mw
index 7a7f540..f3f15d5 100644
--- a/Packaging:Guidelines.mw
+++ b/Packaging:Guidelines.mw
@@ -481,7 +481,11 @@ Packages which explicitly need to link against the static version must Bui
 
 * If a library you depend on '''only''' provides a static version your package can link against it provided that you BuildRequire the ''*-static'' subpackage. Packagers in such a situation should be aware that if a shared library becomes available, that you should adjust your package to use the shared library.
 
+==== Programs which have been granted exceptions ====
+* yaboot has permission to link statically since it's a boot loader that uses e2fsprogs-libs to read the filesystem
+
 {{Anchor|SystemLibraryDuplication}}
+
 == Duplication of system libraries ==
 
 A package should not include or build against a local copy of a library that exists on a system. The package should be patched to use the system libraries.  This prevents old bugs and security holes from living on after the core system libraries have been fixed.  More rationale for this is on the [[Packaging:No Bundled Libraries|No Bundled Libraries]] page.

From 5ba8fbac1112344468f52890be9783973d07303f Mon Sep 17 00:00:00 2001
From: Spot 
Date: Jul 07 2010 19:11:42 +0000
Subject: [PATCH 535/3559] *Empty MediaWiki Message*


---

diff --git a/Packaging:LicensingGuidelines.mw b/Packaging:LicensingGuidelines.mw
index e7b3a1a..73077d2 100644
--- a/Packaging:LicensingGuidelines.mw
+++ b/Packaging:LicensingGuidelines.mw
@@ -1,9 +1,9 @@
 = Licensing Guidelines =
 
 '''Author:''' [[TomCallaway|  Tom 'spot' Callaway]]  
    
-'''Revision:''' 0.06
    
+'''Revision:''' 0.07
    
 '''Initial Draft:''' Thursday August 2, 2007
    
-'''Last Revised:''' Monday October 19, 2008
    
+'''Last Revised:''' Wednesday July 7, 2010
    
 
 
 
@@ -14,10 +14,23 @@ All software in Fedora must be under licenses in the [http://fedoraproject.org/w
 
 If code is multiple licensed, and at least one of the licenses is approved for Fedora, that code can be included in Fedora under the approved license(s) (but only under the terms of the approved license(s)).
 
-{{Anchor|LicenseText}}
+{{Anchor|License Text}}
+== License Text ==
+If (and only if) the source package includes the text of the license(s) in its own file, then that file, containing the text of the license(s) for the package must be included in %doc. If the source package does not include the text of the license(s), the packager should contact upstream and encourage them to correct this mistake.
 
-{{Anchor|LicenseField}}
+{{Anchor|Subpackage Licensing}}
+=== Subpackage Licensing ===
+If a subpackage is dependent (either implicitly or explicitly) upon a base package (where a base package is defined as a resulting binary package from the
+same source RPM which contains the appropriate license texts as %doc), it is not necessary for that subpackage to also include those license texts as %doc.
+
+However, if a subpackage is independent of any base package (it does not require it, either implicitly or explicitly), it must include copies of any license texts
+(as present in the source) which are applicable to the files contained within the subpackage.
+
+{{Anchor|Clarification}}
+=== License Clarification ===
+In cases where the licensing is unclear, it may be necessary to contact the copyright holders to confirm the licensing of code or content. In those situations, it is _always_ preferred to ask upstream to resolve the licensing confusion by documenting the licensing and releasing an updated tarball. However, this is not always possible to achieve. In such cases, it is acceptable to receive confirmation of licensing via email. A copy of the email, containing full headers, must be included as a source file (marked as %doc) in the package. This file is considered part of the license text.
 
+{{Anchor|LicenseField}}
 == License: field ==
 Every Fedora package must contain a License: entry. Maintainers should be aware that the contents of the License: field are understood to not be legally binding (only the source code itself is), but maintainers must make every possible effort to be accurate when filling the License: field.
 
@@ -29,14 +42,6 @@ If a source package generates multiple binary packages, the License: field may d
 === Valid License Short Names ===
 The License: field must be filled with the appropriate license Short License identifier(s) from the "Good License" tables on the [[Licensing|  Fedora Licensing]]  page. If your license does not appear in the tables, it needs to be sent to fedora-legal-list@redhat.com (note that this list is moderated, only members may directly post). If the license is approved, it will be added to the appropriate table.
 
-{{Anchor|License Text}}
-=== License Text ===
-If (and only if) the source package includes the text of the license(s) in its own file, then that file, containing the text of the license(s) for the package must be included in %doc. If the source package does not include the text of the license(s), the packager should contact upstream and encourage them to correct this mistake.
-
-{{Anchor|Clarification}}
-=== License Clarification ===
-In cases where the licensing is unclear, it may be necessary to contact the copyright holders to confirm the licensing of code or content. In those situations, it is _always_ preferred to ask upstream to resolve the licensing confusion by documenting the licensing and releasing an updated tarball. However, this is not always possible to achieve. In such cases, it is acceptable to receive confirmation of licensing via email. A copy of the email, containing full headers, must be included as a source file (marked as %doc) in the package. This file is considered part of the license text.
-
 {{Anchor|Distributable}}
 === "Distributable" ===
 In the past, Fedora (and Red Hat Linux) packages have used "Distributable" in the License: field. In virtually all of these cases, this was not correct. Fedora no longer permits packages to use "Distributable" as a valid License. If your package contains content which is freely redistributable without restrictions, but does not contain any license other than explicit permission from the content owner/creator, then that package can use "Freely redistributable without restriction" as its License: identifier.

From 7dce8343c6df85aca59f871d5e89d4175f9d6bec Mon Sep 17 00:00:00 2001
From: Spot 
Date: Jul 08 2010 18:18:12 +0000
Subject: [PATCH 536/3559] /* Duplicate Files */


---

diff --git a/Packaging:Guidelines.mw b/Packaging:Guidelines.mw
index f3f15d5..d311baf 100644
--- a/Packaging:Guidelines.mw
+++ b/Packaging:Guidelines.mw
@@ -951,7 +951,9 @@ One common example of this is a Perl module.  Assume ''perl-A-B'' depends on ''p
 === Duplicate Files ===
 A Fedora package must not list a file more than once in the spec file's %files listings.  If you think your package is a valid exception to this, please bring it to the attention of the Packaging Committee so they can improve on this Guideline.
 
+One notable exception to this rule is around license texts. There are certain situations where it is required to duplicate the license text across multiple %files section within a package. For more details, please refer to [[Packaging:LicensingGuidelines#Subpackage_Licensing]].
 {{Anchor|FilePermissions}}
+
 === File Permissions ===
 Permissions on files must be set properly. Executables should be set with executable permissions, for example. Every %files section must include a %defattr(...) line. Here is a good default:
 
    
From ecac40da20c9691116f0ac2dd4dfa0be04c9856e Mon Sep 17 00:00:00 2001
From: Spot 
Date: Jul 08 2010 18:19:30 +0000
Subject: [PATCH 537/3559] *Empty MediaWiki Message*


---

diff --git a/Packaging:ReviewGuidelines.mw b/Packaging:ReviewGuidelines.mw
index c06d21b..07f22d3 100644
--- a/Packaging:ReviewGuidelines.mw
+++ b/Packaging:ReviewGuidelines.mw
@@ -4,9 +4,9 @@
 This is a set of guidelines for Package Reviews. Note that a complete list of things to check for would be impossible, but every attempt has been made to make this document as comprehensive as possible. Reviewers and contributors (packagers) should use their best judgement whenever items are unclear, and if in doubt, ask on the [https://www.redhat.com/mailman/listinfo/fedora-packaging fedora-packaging list] .
 
 '''Author:''' [[TomCallaway|  Tom 'spot' Callaway]] 
    
-'''Revision:''' 0.29
    
+'''Revision:''' 0.30
    
 '''Initial Draft:''' Monday Jun 27, 2005
    
-'''Last Revised:''' Friday Jan 9, 2009
    
+'''Last Revised:''' Thursday, Jul 8, 2010
    
 
 == Package Review Process ==
 Contributors and reviewers should follow the [[Package Review Process]].
@@ -37,7 +37,7 @@ There are many many things to check for a review. This list is provided to assis
 * '''MUST''': Packages must NOT bundle copies of system libraries.[[Packaging:Guidelines#Duplication_of_system_libraries|Packaging Guidelines: Duplication of System Libraries]]
    
 * '''MUST''': If the package is designed to be relocatable, the packager must state this fact in the request for review, along with the rationalization for relocation of that specific package. Without this, use of Prefix: /usr is considered a blocker. [[Packaging/Guidelines#RelocatablePackages|Packaging Guidelines: Relocatable Packages]]
    
 * '''MUST''': A package must own all directories that it creates. If it does not create a directory that it uses, then it should require a package which does create that directory.  [[Packaging/Guidelines#FileAndDirectoryOwnership|Packaging Guidelines: File And Directory Ownership]]
    
-* '''MUST''': A Fedora package must not list a file more than once in the spec file's %files listings. [[Packaging/Guidelines#DuplicateFiles|Packaging Guidelines: Duplicate Files]]
    
+* '''MUST''': A Fedora package must not list a file more than once in the spec file's %files listings. (Notable exception: license texts in specific situations)[[Packaging/Guidelines#DuplicateFiles|Packaging Guidelines: Duplicate Files]]
    
 * '''MUST''': Permissions on files must be set properly. Executables should be set with executable permissions, for example. Every %files section must include a %defattr(...) line. [[Packaging/Guidelines#FilePermissions|Packaging Guidelines: File Permissions]]
    
 * '''MUST''': Each package must consistently use macros. [[Packaging/Guidelines#macros|Packaging Guidelines: Macros]]
    
 * '''MUST''': The package must contain code, or permissable content. [[Packaging/Guidelines#CodeVsContent|Packaging Guidelines: Code Vs. Content]]
    

From 73914c638c035c8b86c6db83ccabf03cd33f967a Mon Sep 17 00:00:00 2001
From: Spot 
Date: Jul 26 2010 20:08:27 +0000
Subject: [PATCH 538/3559] /* In %prep (preferred) */


---

diff --git a/Packaging:Perl.mw b/Packaging:Perl.mw
index 6461c62..2929699 100644
--- a/Packaging:Perl.mw
+++ b/Packaging:Perl.mw
@@ -66,6 +66,9 @@ RPM's dependency generator can often throw in additional dependencies and will o
 Filtering can be done entirely in the SPEC file, in the %prep section:
 
 
    +%prep
+%setup -q -n Foo-%{version}
+
 cat << \EOF > %{name}-prov
 #!/bin/sh
 %{__perl_provides} $* |\

From 3c901be752bbaf68c193b60359c7c9e154b4842d Mon Sep 17 00:00:00 2001
From: Bioinfornatics 
Date: Jul 28 2010 00:53:43 +0000
Subject: [PATCH 539/3559] Created page with ''''Revision:''' 0.1
     '''Last Revised:''' Wednesday Jul 28, 2010
      == Packaging Tips ==  === File Locations ===  ==== Libraries ==== D packages should install assemblies to ...'


---

diff --git a/Packaging:D.mw b/Packaging:D.mw
new file mode 100644
index 0000000..5689b38
--- /dev/null
+++ b/Packaging:D.mw
@@ -0,0 +1,43 @@
+'''Revision:''' 0.1
    
+'''Last Revised:''' Wednesday Jul 28, 2010
    
+
+== Packaging Tips ==
+
+=== File Locations ===
+
+==== Libraries ====
+D packages should install assemblies to %{_libdir} rather than /usr/lib or %{_datadir}.
+
+===== Header =====
+D package should install header file like .d or .di to %{_d_includedir}/%{name}
+
+=== Libraries ===
+At this time in D programming only OS X support shared lirbraries. So wait this feature or help ldc project. Feel free.
    
+For build static librarie in D you need use ar and ranlib tools. ldc compiler support GNU strip.
    
+short example from makefile:
    
+
    +DC=ldc
+HD=-Hd $(IMPORT_DEST)
+DFLAGS_REQ=-c -I ../DerelictUtil
+AL_SRC= \
+    derelict/openal/al.d \
+    derelict/openal/alfuncs.d \
+    derelict/openal/altypes.d   
+    
+PACKAGE_PATH=derelict/openal
+
+all : DerelictAL
+
+$(LIB_PRE)DerelictAL.$(LIB_EXT) :
+	$(DC) $(DFLAGS) $(DFLAGS_REQ) $(AL_SRC) $(HD)/$(PACKAGE_PATH)
+	$(AR) rcs $@ $^
+	$(RANLIB) $@
+	$(CP) $@ $(LIB_DEST)
+	$(RM) $@
+
    
+
+=== Macros ===
+%{_d_includedir} need be used for devel file
    
+%{_d_optflags} need be used for ldc options
    
+
+[[Category:Packaging guidelines]]

From 40091710f7951597392bc6e3e65bf3a88e622e45 Mon Sep 17 00:00:00 2001
From: Bioinfornatics 
Date: Jul 28 2010 13:36:03 +0000
Subject: [PATCH 540/3559] /* Libraries */


---

diff --git a/Packaging:D.mw b/Packaging:D.mw
index 5689b38..6b425f8 100644
--- a/Packaging:D.mw
+++ b/Packaging:D.mw
@@ -6,10 +6,10 @@
 === File Locations ===
 
 ==== Libraries ====
-D packages should install assemblies to %{_libdir} rather than /usr/lib or %{_datadir}.
+D packages must install assemblies to %{_libdir} rather than /usr/lib or %{_datadir}.
 
 ===== Header =====
-D package should install header file like .d or .di to %{_d_includedir}/%{name}
+D package must install header file like .d or .di to %{_d_includedir}/%{name}
 
 === Libraries ===
 At this time in D programming only OS X support shared lirbraries. So wait this feature or help ldc project. Feel free.
    

From d46f2f9ba76d655758c9b99c64500b9164b0e9e4 Mon Sep 17 00:00:00 2001
From: Bioinfornatics 
Date: Jul 28 2010 13:42:43 +0000
Subject: [PATCH 541/3559] /* Macros */


---

diff --git a/Packaging:D.mw b/Packaging:D.mw
index 6b425f8..82f0127 100644
--- a/Packaging:D.mw
+++ b/Packaging:D.mw
@@ -37,7 +37,17 @@ $(LIB_PRE)DerelictAL.$(LIB_EXT) :
 
    
 
 === Macros ===
+All D package need ldc for build and macro file is in ldc package, every package must have ldc in BuildRequire
+
+==== Include directories ====
 %{_d_includedir} need be used for devel file
    
+%{_d_includedir} define /usr/include/d/ directory
+
+==== Compiler options ====
 %{_d_optflags} need be used for ldc options
    
+%{_d_optflags} define options -release -w -g
    
+-release disables asserts, invariants, contracts and boundscheck
    
+-w enable warnings
    
+-g generate debug information
    
 
 [[Category:Packaging guidelines]]

From b968ee0a372da4f4e69c738ac8854828749d321f Mon Sep 17 00:00:00 2001
From: Bioinfornatics 
Date: Jul 28 2010 13:43:17 +0000
Subject: [PATCH 542/3559] /* Include directories */


---

diff --git a/Packaging:D.mw b/Packaging:D.mw
index 82f0127..416e121 100644
--- a/Packaging:D.mw
+++ b/Packaging:D.mw
@@ -40,8 +40,8 @@ $(LIB_PRE)DerelictAL.$(LIB_EXT) :
 All D package need ldc for build and macro file is in ldc package, every package must have ldc in BuildRequire
 
 ==== Include directories ====
-%{_d_includedir} need be used for devel file
    
-%{_d_includedir} define /usr/include/d/ directory
+'''%{_d_includedir}''' need be used for devel file
    
+'''%{_d_includedir}''' define ''/usr/include/d/'' directory
 
 ==== Compiler options ====
 %{_d_optflags} need be used for ldc options
    

From 1751cd9c69bc8016b19efe0eb164afc5ceb1aae2 Mon Sep 17 00:00:00 2001
From: Bioinfornatics 
Date: Jul 28 2010 13:43:46 +0000
Subject: [PATCH 543/3559] /* Include directories */


---

diff --git a/Packaging:D.mw b/Packaging:D.mw
index 416e121..4922004 100644
--- a/Packaging:D.mw
+++ b/Packaging:D.mw
@@ -40,8 +40,8 @@ $(LIB_PRE)DerelictAL.$(LIB_EXT) :
 All D package need ldc for build and macro file is in ldc package, every package must have ldc in BuildRequire
 
 ==== Include directories ====
-'''%{_d_includedir}''' need be used for devel file
    
-'''%{_d_includedir}''' define ''/usr/include/d/'' directory
+%{_d_includedir} need be used for devel file
    
+%{_d_includedir} define ''/usr/include/d/'' directory
 
 ==== Compiler options ====
 %{_d_optflags} need be used for ldc options
    

From 7db584bf0f5ec5890d29a91bb478ff6072b5391e Mon Sep 17 00:00:00 2001
From: Bioinfornatics 
Date: Jul 28 2010 13:44:29 +0000
Subject: [PATCH 544/3559] /* Compiler options */


---

diff --git a/Packaging:D.mw b/Packaging:D.mw
index 4922004..c139f9e 100644
--- a/Packaging:D.mw
+++ b/Packaging:D.mw
@@ -45,9 +45,9 @@ All D package need ldc for build and macro file is in ldc package, every package
 
 ==== Compiler options ====
 %{_d_optflags} need be used for ldc options
    
-%{_d_optflags} define options -release -w -g
    
--release disables asserts, invariants, contracts and boundscheck
    
--w enable warnings
    
--g generate debug information
    
+%{_d_optflags} define options ''-release -w -g''
    
+-release ''disables asserts, invariants, contracts and boundscheck''
    
+-w ''enable warnings''
    
+-g ''generate debug information''
    
 
 [[Category:Packaging guidelines]]

From 1e47f167ee70ba5dc3f1735e295ddc1d4ffdbe99 Mon Sep 17 00:00:00 2001
From: Bioinfornatics 
Date: Jul 28 2010 13:54:43 +0000
Subject: [PATCH 545/3559] *Empty MediaWiki Message*


---

diff --git a/Packaging:D.mw b/Packaging:D.mw
index c139f9e..0b75188 100644
--- a/Packaging:D.mw
+++ b/Packaging:D.mw
@@ -50,4 +50,56 @@ All D package need ldc for build and macro file is in ldc package, every package
 -w ''enable warnings''
    
 -g ''generate debug information''
    
 
+== SPEC template ==
+here an template for D package with static libraries
+
    +Name:
+Version:
+Release:        1%{?dist}
+Summary:        Development/Libraries
+
+
+Group:
+License:
+URL:
+Source0:
+BuildRoot:      %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
+
+BuildRequires: ldc
+Requires:      tango
+
+%description
+
+%package devel
+Provides:       %{name}-static =  %{version}-%{release}
+Summary:        Support for developing D application
+Group:          Development/Libraries
+
+%prep
+%setup -q
+
+
+%build
+%configure
+make %{?_smp_mflags}
+
+
+%install
+rm -rf %{buildroot}
+make install DESTDIR=%{buildroot}
+
+
+%clean
+rm -rf %{buildroot}
+
+
+%files devel
+%defattr(-,root,root,-)
+%doc README.txt LICENSE.txt
+%{_d_includedir}/%{name}
+%{_libdir}/%{name}/
+%changelog
+
+
    
+
 [[Category:Packaging guidelines]]

From 303d50b56b951452dcc4e51f326afad520ef1b4f Mon Sep 17 00:00:00 2001
From: Bioinfornatics 
Date: Jul 28 2010 13:55:12 +0000
Subject: [PATCH 546/3559] /* SPEC template */


---

diff --git a/Packaging:D.mw b/Packaging:D.mw
index 0b75188..3d41e04 100644
--- a/Packaging:D.mw
+++ b/Packaging:D.mw
@@ -98,6 +98,7 @@ rm -rf %{buildroot}
 %doc README.txt LICENSE.txt
 %{_d_includedir}/%{name}
 %{_libdir}/%{name}/
+
 %changelog
 
 
    

From 17d8383e195a26738ea35b8e020359eb2625c5f1 Mon Sep 17 00:00:00 2001
From: Bioinfornatics 
Date: Jul 29 2010 13:36:22 +0000
Subject: [PATCH 547/3559] /* Macros */


---

diff --git a/Packaging:D.mw b/Packaging:D.mw
index 3d41e04..ad9c549 100644
--- a/Packaging:D.mw
+++ b/Packaging:D.mw
@@ -39,10 +39,6 @@ $(LIB_PRE)DerelictAL.$(LIB_EXT) :
 === Macros ===
 All D package need ldc for build and macro file is in ldc package, every package must have ldc in BuildRequire
 
-==== Include directories ====
-%{_d_includedir} need be used for devel file
    
-%{_d_includedir} define ''/usr/include/d/'' directory
-
 ==== Compiler options ====
 %{_d_optflags} need be used for ldc options
    
 %{_d_optflags} define options ''-release -w -g''
    
@@ -50,6 +46,14 @@ All D package need ldc for build and macro file is in ldc package, every package
 -w ''enable warnings''
    
 -g ''generate debug information''
    
 
+==== Include directories ====
+%{_d_includedir} need be used for devel file
    
+%{_d_includedir} define ''/usr/include/d/'' directory
+
+==== Lib directories ====
+%{_d_libdir} lib directory path used for static library (and later i hope shared library)
+%{_d_libdir} define ''/usr/lib64/d'' directory
+
 == SPEC template ==
 here an template for D package with static libraries
 
    
From 7f6dd111a9961abe8f83f6a6c95c4ff5eec578ee Mon Sep 17 00:00:00 2001
From: Bioinfornatics 
Date: Jul 29 2010 13:36:54 +0000
Subject: [PATCH 548/3559] /* Macros */


---

diff --git a/Packaging:D.mw b/Packaging:D.mw
index ad9c549..38d46f9 100644
--- a/Packaging:D.mw
+++ b/Packaging:D.mw
@@ -52,7 +52,7 @@ All D package need ldc for build and macro file is in ldc package, every package
 
 ==== Lib directories ====
 %{_d_libdir} lib directory path used for static library (and later i hope shared library)
-%{_d_libdir} define ''/usr/lib64/d'' directory
+%{_d_libdir} define ''/usr/lib64/d'' or ''/usr/lib/d'' directory
 
 == SPEC template ==
 here an template for D package with static libraries

From 250150005af529b217d1d598fa2b54be6b009048 Mon Sep 17 00:00:00 2001
From: Bioinfornatics 
Date: Jul 29 2010 23:57:39 +0000
Subject: [PATCH 549/3559] /* Packaging Tips */


---

diff --git a/Packaging:D.mw b/Packaging:D.mw
index 38d46f9..79d06be 100644
--- a/Packaging:D.mw
+++ b/Packaging:D.mw
@@ -6,7 +6,7 @@
 === File Locations ===
 
 ==== Libraries ====
-D packages must install assemblies to %{_libdir} rather than /usr/lib or %{_datadir}.
+D packages must install assemblies to %{_d_libdir} rather than /usr/lib or %{_datadir}.
 
 ===== Header =====
 D package must install header file like .d or .di to %{_d_includedir}/%{name}

From 87614ecfd6449dc81d4f21c3990c81ab5b0fa399 Mon Sep 17 00:00:00 2001
From: Bioinfornatics 
Date: Aug 02 2010 16:16:40 +0000
Subject: [PATCH 550/3559] /* Compiler options */


---

diff --git a/Packaging:D.mw b/Packaging:D.mw
index 79d06be..de7c764 100644
--- a/Packaging:D.mw
+++ b/Packaging:D.mw
@@ -41,10 +41,11 @@ All D package need ldc for build and macro file is in ldc package, every package
 
 ==== Compiler options ====
 %{_d_optflags} need be used for ldc options
    
-%{_d_optflags} define options ''-release -w -g''
    
+%{_d_optflags} define options ''-release -w -g -O2''
    
 -release ''disables asserts, invariants, contracts and boundscheck''
    
 -w ''enable warnings''
    
 -g ''generate debug information''
    
+-O2 ''for make a good optimisation''
 
 ==== Include directories ====
 %{_d_includedir} need be used for devel file
    

From 7e2356d36d5ebb13fb1d8e3bd8aa18e5ff145207 Mon Sep 17 00:00:00 2001
From: Bioinfornatics 
Date: Aug 05 2010 10:03:21 +0000
Subject: [PATCH 551/3559] *Empty MediaWiki Message*


---

diff --git a/Packaging:D.mw b/Packaging:D.mw
index de7c764..54934a0 100644
--- a/Packaging:D.mw
+++ b/Packaging:D.mw
@@ -55,9 +55,18 @@ All D package need ldc for build and macro file is in ldc package, every package
 %{_d_libdir} lib directory path used for static library (and later i hope shared library)
 %{_d_libdir} define ''/usr/lib64/d'' or ''/usr/lib/d'' directory
 
-== SPEC template ==
+== SPEC ==
+=== Tips ===
+If you package do not contain a shared library but only static library you shoul write at top of spec file:
+ %global debug_package %{nil}
+
+Because GNU strip can't extract debug symbols from static lib achieves.
+
+=== Template ===
 here an template for D package with static libraries
 
    +%global debug_package %{nil}
+
 Name:
 Version:
 Release:        1%{?dist}

From 2969b9d1652e3bf3240c192f0b40bd9ec5f49114 Mon Sep 17 00:00:00 2001
From: Bioinfornatics 
Date: Aug 05 2010 10:04:18 +0000
Subject: [PATCH 552/3559] /* SPEC */


---

diff --git a/Packaging:D.mw b/Packaging:D.mw
index 54934a0..8669f3b 100644
--- a/Packaging:D.mw
+++ b/Packaging:D.mw
@@ -57,11 +57,14 @@ All D package need ldc for build and macro file is in ldc package, every package
 
 == SPEC ==
 === Tips ===
+==== If only static library ===
 If you package do not contain a shared library but only static library you shoul write at top of spec file:
  %global debug_package %{nil}
 
 Because GNU strip can't extract debug symbols from static lib achieves.
 
+
+
 === Template ===
 here an template for D package with static libraries
 
    
From 96d3cfb7446cf52623ef5a85f4d765b464274101 Mon Sep 17 00:00:00 2001
From: Bioinfornatics 
Date: Aug 05 2010 10:09:41 +0000
Subject: [PATCH 553/3559] /* SPEC */


---

diff --git a/Packaging:D.mw b/Packaging:D.mw
index 8669f3b..2f00e83 100644
--- a/Packaging:D.mw
+++ b/Packaging:D.mw
@@ -57,20 +57,23 @@ All D package need ldc for build and macro file is in ldc package, every package
 
 == SPEC ==
 === Tips ===
-==== If only static library ===
+==== If only static library ====
+===== Define gmacro =====
 If you package do not contain a shared library but only static library you shoul write at top of spec file:
  %global debug_package %{nil}
 
 Because GNU strip can't extract debug symbols from static lib achieves.
 
-
+===== Provides static libraries =====
+When a package only provides static libraries you can place all the static library files in the *-devel subpackage. When doing this you also must have a virtual Provide for the *-static package.
+Then  the root package could be empty, in the template for example they are no %file foo and foo-devel package contain static librarie.
 
 === Template ===
 here an template for D package with static libraries
 
     %global debug_package %{nil}
 
-Name:
+Name:           foo
 Version:
 Release:        1%{?dist}
 Summary:        Development/Libraries

From 87c48340829de777dbd97388f0da62f651576f09 Mon Sep 17 00:00:00 2001
From: Bioinfornatics 
Date: Aug 05 2010 10:09:59 +0000
Subject: [PATCH 554/3559] /* Define gmacro */


---

diff --git a/Packaging:D.mw b/Packaging:D.mw
index 2f00e83..f77a912 100644
--- a/Packaging:D.mw
+++ b/Packaging:D.mw
@@ -58,7 +58,7 @@ All D package need ldc for build and macro file is in ldc package, every package
 == SPEC ==
 === Tips ===
 ==== If only static library ====
-===== Define gmacro =====
+===== Define global macro =====
 If you package do not contain a shared library but only static library you shoul write at top of spec file:
  %global debug_package %{nil}
 

From b9ed0d2aa2d123c161f54c282879a8d2688e6352 Mon Sep 17 00:00:00 2001
From: Bioinfornatics 
Date: Aug 09 2010 16:36:23 +0000
Subject: [PATCH 555/3559] /* Define global macro */


---

diff --git a/Packaging:D.mw b/Packaging:D.mw
index f77a912..f58f842 100644
--- a/Packaging:D.mw
+++ b/Packaging:D.mw
@@ -59,7 +59,7 @@ All D package need ldc for build and macro file is in ldc package, every package
 === Tips ===
 ==== If only static library ====
 ===== Define global macro =====
-If you package do not contain a shared library but only static library you shoul write at top of spec file:
+If your package do not contain a shared library but only static library you shoul write at top of spec file:
  %global debug_package %{nil}
 
 Because GNU strip can't extract debug symbols from static lib achieves.

From e73bd45c18cd299e7518c81862fe3754a99bcb6f Mon Sep 17 00:00:00 2001
From: Bioinfornatics 
Date: Aug 23 2010 13:42:49 +0000
Subject: [PATCH 556/3559] /* Template */


---

diff --git a/Packaging:D.mw b/Packaging:D.mw
index f58f842..e3e4a3d 100644
--- a/Packaging:D.mw
+++ b/Packaging:D.mw
@@ -117,7 +117,7 @@ rm -rf %{buildroot}
 %defattr(-,root,root,-)
 %doc README.txt LICENSE.txt
 %{_d_includedir}/%{name}
-%{_libdir}/%{name}/
+%{_d_libdir}/%{name}/
 
 %changelog
 

From 4866051f58005d07728da6cd924713326b9521c9 Mon Sep 17 00:00:00 2001
From: Spot 
Date: Aug 25 2010 15:51:11 +0000
Subject: [PATCH 557/3559] *Empty MediaWiki Message*


---

diff --git a/Packaging:D.mw b/Packaging:D.mw
index e3e4a3d..7b43c11 100644
--- a/Packaging:D.mw
+++ b/Packaging:D.mw
@@ -1,94 +1,64 @@
 '''Revision:''' 0.1
    
 '''Last Revised:''' Wednesday Jul 28, 2010
    
 
-== Packaging Tips ==
+== ldc ==
+All D packages depend on ldc to build, so every package must have ldc as BuildRequires. In addition, the ldc package includes some useful macros for D packages. 
 
-=== File Locations ===
+=== Compiler options ===
+%{_d_optflags} must be used with ldc (normal %{optflags} do not apply to ldc, only to gcc).
 
-==== Libraries ====
-D packages must install assemblies to %{_d_libdir} rather than /usr/lib or %{_datadir}.
-
-===== Header =====
-D package must install header file like .d or .di to %{_d_includedir}/%{name}
-
-=== Libraries ===
-At this time in D programming only OS X support shared lirbraries. So wait this feature or help ldc project. Feel free.
    
-For build static librarie in D you need use ar and ranlib tools. ldc compiler support GNU strip.
    
-short example from makefile:
    
+%{_d_optflags} is defined as:
 
    -DC=ldc
-HD=-Hd $(IMPORT_DEST)
-DFLAGS_REQ=-c -I ../DerelictUtil
-AL_SRC= \
-    derelict/openal/al.d \
-    derelict/openal/alfuncs.d \
-    derelict/openal/altypes.d   
-    
-PACKAGE_PATH=derelict/openal
-
-all : DerelictAL
-
-$(LIB_PRE)DerelictAL.$(LIB_EXT) :
-	$(DC) $(DFLAGS) $(DFLAGS_REQ) $(AL_SRC) $(HD)/$(PACKAGE_PATH)
-	$(AR) rcs $@ $^
-	$(RANLIB) $@
-	$(CP) $@ $(LIB_DEST)
-	$(RM) $@
+-release -w -g -O2
 
    
 
-=== Macros ===
-All D package need ldc for build and macro file is in ldc package, every package must have ldc in BuildRequire
-
-==== Compiler options ====
-%{_d_optflags} need be used for ldc options
    
-%{_d_optflags} define options ''-release -w -g -O2''
    
 -release ''disables asserts, invariants, contracts and boundscheck''
    
--w ''enable warnings''
    
--g ''generate debug information''
    
--O2 ''for make a good optimisation''
+-w ''enables warnings''
    
+-g ''generates debug information''
    
+-O2 ''is the optimisation level''
 
-==== Include directories ====
-%{_d_includedir} need be used for devel file
    
-%{_d_includedir} define ''/usr/include/d/'' directory
+=== Header Files ===
+D packages contain header files, which end with .d or .di. These header files must be installed into %{_d_includedir}/%{name}.
 
-==== Lib directories ====
-%{_d_libdir} lib directory path used for static library (and later i hope shared library)
-%{_d_libdir} define ''/usr/lib64/d'' or ''/usr/lib/d'' directory
-
-== SPEC ==
-=== Tips ===
-==== If only static library ====
-===== Define global macro =====
-If your package do not contain a shared library but only static library you shoul write at top of spec file:
- %global debug_package %{nil}
+%{_d_includedir} is defined as:
+
    +/usr/include/d/
+
    
 
-Because GNU strip can't extract debug symbols from static lib achieves.
+== Libraries ==
+At this time, Linux does not support shared libraries for D code (only OSX does). 
+As a result, D packages are explicitly excluded from the restrictions against packaging static libraries.
 
-===== Provides static libraries =====
-When a package only provides static libraries you can place all the static library files in the *-devel subpackage. When doing this you also must have a virtual Provide for the *-static package.
-Then  the root package could be empty, in the template for example they are no %file foo and foo-devel package contain static librarie.
+To build static libraries in D, you use the same tools that you would for C, specifically, ar, ranlib, and strip.
 
-=== Template ===
-here an template for D package with static libraries
+If your D package contains static libraries, you must disable debuginfo generation, by adding this line to the top of your spec file:
 
     %global debug_package %{nil}
+
    
+Otherwise, it would generate an empty debuginfo package.
 
-Name:           foo
-Version:
-Release:        1%{?dist}
-Summary:        Development/Libraries
+All static libraries must be placed in the *-devel subpackage. When doing this, you must also have 
+Provides: %{name}-static = %{version}-%{release} in the devel package definition.
 
+It is possible that this will leave the root package empty, if this is the case, do not list a %files section for the root package, only for the -devel package. This is illustrated in the example template below.
 
-Group:
-License:
-URL:
-Source0:
-BuildRoot:      %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
+== Template ==
+
    +%global debug_package %{nil}
 
-BuildRequires: ldc
-Requires:      tango
+Name:           foo
+Version:        1.2.3
+Release:        1%{?dist}
+Summary:        Does foo in D
+Group:          Development/Libraries
+License:        LGPLv2+
+URL:            http://anywhere.com/
+Source0:        http://anywhere.com/%{name}-%{version}.tar.bz2
+BuildRequires:  ldc
+Requires:       tango
 
 %description
+Foo and bar.
 
 %package devel
 Provides:       %{name}-static =  %{version}-%{release}
@@ -105,22 +75,18 @@ make %{?_smp_mflags}
 
 
 %install
-rm -rf %{buildroot}
 make install DESTDIR=%{buildroot}
 
-
 %clean
 rm -rf %{buildroot}
 
-
 %files devel
 %defattr(-,root,root,-)
 %doc README.txt LICENSE.txt
-%{_d_includedir}/%{name}
-%{_d_libdir}/%{name}/
+%{_d_includedir}/%{name}/
+%{_libdir}/*.a
 
 %changelog
-
+* Wed Aug 25 2010 John Doe  1.2.3-1
+- initial package
 
    
-
-[[Category:Packaging guidelines]]

From d6cfa30bf98713e16da2189a7634e4d5582a9f97 Mon Sep 17 00:00:00 2001
From: Spot 
Date: Aug 25 2010 16:02:00 +0000
Subject: [PATCH 558/3559] *Empty MediaWiki Message*


---

diff --git a/Packaging:D.mw b/Packaging:D.mw
index 7b43c11..2da5423 100644
--- a/Packaging:D.mw
+++ b/Packaging:D.mw
@@ -1,6 +1,3 @@
-'''Revision:''' 0.1
    
-'''Last Revised:''' Wednesday Jul 28, 2010
    
-
 == ldc ==
 All D packages depend on ldc to build, so every package must have ldc as BuildRequires. In addition, the ldc package includes some useful macros for D packages. 
 

From e4bcdc0c8f79b33fdd3b5baa4bd3bc9b2165bd34 Mon Sep 17 00:00:00 2001
From: Bioinfornatics 
Date: Aug 27 2010 09:53:04 +0000
Subject: [PATCH 559/3559] /* Template */


---

diff --git a/Packaging:D.mw b/Packaging:D.mw
index 2da5423..8cd42de 100644
--- a/Packaging:D.mw
+++ b/Packaging:D.mw
@@ -73,6 +73,7 @@ make %{?_smp_mflags}
 
 %install
 make install DESTDIR=%{buildroot}
+install -m 0644 lib/* %{_libdir}
 
 %clean
 rm -rf %{buildroot}

From e3f491b7dd87bd96fa1f2930edd47565d71e0035 Mon Sep 17 00:00:00 2001
From: Bioinfornatics 
Date: Aug 27 2010 09:55:23 +0000
Subject: [PATCH 560/3559] /* Template */


---

diff --git a/Packaging:D.mw b/Packaging:D.mw
index 8cd42de..7659b7f 100644
--- a/Packaging:D.mw
+++ b/Packaging:D.mw
@@ -72,8 +72,13 @@ make %{?_smp_mflags}
 
 
 %install
+mkdir -p %{_libdir}
+mkdir -p %{_d_includedir}/%{name}/
+
 make install DESTDIR=%{buildroot}
-install -m 0644 lib/* %{_libdir}
+
+install -m 0644 lib/*     %{_libdir}
+install -m 0644 include/* %{_d_includedir}/%{name}/
 
 %clean
 rm -rf %{buildroot}

From f69751bad9d11b6f702e5a5881c16ea3b48d0c8e Mon Sep 17 00:00:00 2001
From: Spot 
Date: Sep 01 2010 16:04:14 +0000
Subject: [PATCH 561/3559] /* Template */


---

diff --git a/Packaging:D.mw b/Packaging:D.mw
index 7659b7f..e04c9f0 100644
--- a/Packaging:D.mw
+++ b/Packaging:D.mw
@@ -72,13 +72,13 @@ make %{?_smp_mflags}
 
 
 %install
-mkdir -p %{_libdir}
-mkdir -p %{_d_includedir}/%{name}/
+mkdir -p %{buildroot}%{_libdir}
+mkdir -p %{buildroot}%{_d_includedir}/%{name}/
 
 make install DESTDIR=%{buildroot}
 
-install -m 0644 lib/*     %{_libdir}
-install -m 0644 include/* %{_d_includedir}/%{name}/
+install -m 0644 lib/*     %{buildroot}%{_libdir}
+install -m 0644 include/* %{buildroot}%{_d_includedir}/%{name}/
 
 %clean
 rm -rf %{buildroot}

From abc0ef1dfd61b7ffc8b882680817a82827511daf Mon Sep 17 00:00:00 2001
From: Spot 
Date: Sep 07 2010 13:48:50 +0000
Subject: [PATCH 562/3559] Created page with '== $RPM_SOURCE_DIR or %{_sourcedir} ==  Packages which use files itemized as Source# files, must refer to those files by their Source# macro name, and must not use $RPM_SOURCE_DI...'


---

diff --git a/Packaging:RPM_Source_Dir.mw b/Packaging:RPM_Source_Dir.mw
new file mode 100644
index 0000000..15561ae
--- /dev/null
+++ b/Packaging:RPM_Source_Dir.mw
@@ -0,0 +1,31 @@
+== $RPM_SOURCE_DIR or %{_sourcedir} ==
+
+Packages which use files itemized as Source# files, must refer to those files by their Source# macro name, and must not use $RPM_SOURCE_DIR or %{sourcedir} to refer to those files.
+
+This is done to ensure that Fedora SRPMS are properly generated. If a Source# item is renamed, a spec which refers to its old name may succeed locally (because the file is still in %{_sourcedir} along with the new file), but the proper file will not be included in the SRPM. 
+
+'''Incorrect Use:'''
+
    +Source1: php.conf
+Source2: php.ini
+Source3: macros.php
+
+...
+
+install -m 644 $RPM_SOURCE_DIR/php.conf $RPM_BUILD_ROOT/etc/httpd/conf.d
+sed -e "s/@PHP_APIVER@/%{apiver}/;s/@PHP_ZENDVER@/%{zendver}/;s/@PHP_PDOVER@/%{pdover}/" \
+    < $RPM_SOURCE_DIR/macros.php > macros.php
+
    
+
+'''Correct Use:'''
+
    +Source1: php.conf
+Source2: php.ini
+Source3: macros.php
+
+...
+
+install -m 644 %{SOURCE1} $RPM_BUILD_ROOT/etc/httpd/conf.d
+sed -e "s/@PHP_APIVER@/%{apiver}/;s/@PHP_ZENDVER@/%{zendver}/;s/@PHP_PDOVER@/%{pdover}/" \
+    < %{SOURCE3} > macros.php
+
    

From f9cf129c16d82b90bbb8c07219279a03dbe0419a Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Sep 14 2010 19:45:14 +0000
Subject: [PATCH 563/3559] Define explicit requires


---

diff --git a/Packaging:Guidelines.mw b/Packaging:Guidelines.mw
index d311baf..15b1fac 100644
--- a/Packaging:Guidelines.mw
+++ b/Packaging:Guidelines.mw
@@ -227,7 +227,7 @@ Rpm gives you the ability to depend on files instead of packages.  Whenever poss
 
 {{Anchor|ExplicitRequires}}
 === Explicit Requires ===
-Packages must not contain explicit ''Requires'' on libraries except when absolutely 
+Explicit Requires are Requires added manually by the packager in the spec file.  Packages must not contain explicit ''Requires'' on libraries except when absolutely 
 necessary. When explicit library ''Requires'' are necessary, there should be a spec file comment justifying it.
 
 We generally rely on rpmbuild to automatically add dependencies on library SONAMEs. 

From bf026ea81fb9083e354b214225b98d9960cec906 Mon Sep 17 00:00:00 2001
From: Tibbs 
Date: Sep 22 2010 21:18:17 +0000
Subject: [PATCH 564/3559] Remove ancient mention of "Fedora Core 3 and earlier".


---

diff --git a/Packaging:Ruby.mw b/Packaging:Ruby.mw
index 9de1369..dc4a9b2 100644
--- a/Packaging:Ruby.mw
+++ b/Packaging:Ruby.mw
@@ -28,8 +28,6 @@ The Ruby library files in a pure Ruby package '''must''' be placed into Co
 %{!?ruby_sitelib: %global ruby_sitelib %(ruby -rrbconfig -e 'puts Config::CONFIG["sitelibdir"] ')}
 
    
 
-{{Template:Note}} For Fedora Core 3 and earlier releases, it is not possible to build noarch packages; for those releases, all Ruby packages '''must''' be architecture-specific, even if they only contain Ruby files. (See [https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=184199 bug 184199]  for details)
-
 {{Anchor|ruby_sitearch}}
 
 === Ruby packages with binary content/shared libraries ===

From b1c2e8641ff3b809c868181ddb5c97226868f9e9 Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Sep 28 2010 15:46:16 +0000
Subject: [PATCH 565/3559] Add the MUST NOT with the other MUSTs


---

diff --git a/Packaging:AutoProvidesAndRequiresFiltering.mw b/Packaging:AutoProvidesAndRequiresFiltering.mw
index 6d97185..8601b04 100644
--- a/Packaging:AutoProvidesAndRequiresFiltering.mw
+++ b/Packaging:AutoProvidesAndRequiresFiltering.mw
@@ -6,6 +6,7 @@ RPM has no general or standard mechanism to enable filtering of auto-generated r
 
 * '''MUST:''' Packages must not provide RPM dependency information when that information is not global in nature, or are otherwise handled (e.g. through a virtual provides system).  e.g. a plugin package containing a binary shared library must not "provide" that library unless it is accessible through the system library paths.
 * '''MUST:''' When filtering automatically generated RPM dependency information, the filtering system implemented by Fedora must be used, except where there is a compelling reason to deviate from it.
+* '''MUST NOT:''' If the package does not fall into one of the categories specified in the [[#Usage| Usage Section below]] then it must not filter the provides at this time.  The reason for this is explained in the [[#Usage| Usage Section]].
 
 == Rationale ==
 

From 2aeb84cbc76efc59ac5d46ceec63fec397af3cd0 Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Sep 28 2010 15:48:43 +0000
Subject: [PATCH 566/3559] Add python example


---

diff --git a/Packaging:AutoProvidesAndRequiresFiltering.mw b/Packaging:AutoProvidesAndRequiresFiltering.mw
index 8601b04..a9d43d1 100644
--- a/Packaging:AutoProvidesAndRequiresFiltering.mw
+++ b/Packaging:AutoProvidesAndRequiresFiltering.mw
@@ -98,7 +98,7 @@ To filter this out, we could use:
 %filter_setup
 
    
 
-=== Arch-specific perl-* package ===
+=== Arch-specific extensions to scripting languages ===
 
 e.g. to ensure an arch-specific perl-* package won't provide or require things that it shouldn't, we could use an invocation as such:
 
@@ -111,6 +111,15 @@ e.g. to ensure an arch-specific perl-* package won't provide or require things t
 %filter_setup
 
    
 
+The recipe for python-* is very similar:
+
    +# we don't want to provide private python extension libs
+%filter_provides_in %{python_sitearch}/.*\.so$ 
+
+# actually set up the filtering
+%filter_setup
+
    
+
 === %_docdir filtering ===
 
 By policy, nothing under %_docdir is allowed to either "provide" or "require" anything.  We can prevent this from happening by preventing anything under %_docdir from being scanned:

From 687ca6912071ef215af5d504bfce7e7598acc5bb Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Sep 28 2010 17:24:26 +0000
Subject: [PATCH 567/3559] Add link to filtering Provides and Requires


---

diff --git a/Packaging:Python.mw b/Packaging:Python.mw
index 384cf2c..3d25190 100644
--- a/Packaging:Python.mw
+++ b/Packaging:Python.mw
@@ -482,6 +482,9 @@ The following are a summary of the guidelines for reviewers to go over when a py
 * '''Must''': When building multiple versions (for a compat package) one of the packages must contain a default version that is usable via "import MODULE" with no prior setup.
 * '''Should''': A package which is used by another package via an egg interface should provide egg info.
 
+== Filtering Requires: and Provides: ==
+RPM's dependency generator can often throw in additional dependencies and will often think packages provide functionality contrary to reality. To fix this, the dependency generator needs to be overriden so that the additional dependencies can be filtered out.  See [[Packaging:AutoProvidesAndRequiresFiltering]] for details.
+
 == PyGTK2 and Numpy ==
 {{admon/note||This is a temporary workaround which may be resolved in the future. It will no longer be necessary when [[http://bugzilla.gnome.org/show_bug.cgi?id=591745 gnome bug #591745]] is fixed.}}
 

From 4d1f8ecfb48a0348c51441660c7b4802972ca0d2 Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Sep 29 2010 17:37:20 +0000
Subject: [PATCH 568/3559] Conditionalize use of the macros


---

diff --git a/Packaging:AutoProvidesAndRequiresFiltering.mw b/Packaging:AutoProvidesAndRequiresFiltering.mw
index a9d43d1..d1a5469 100644
--- a/Packaging:AutoProvidesAndRequiresFiltering.mw
+++ b/Packaging:AutoProvidesAndRequiresFiltering.mw
@@ -84,6 +84,15 @@ The '''%filter_setup''' macro must be invoked after defining any specific overri
 %filter_setup
 
    
 
+These macros were not defined in EPEL5.  People wanting to share one spec file with Fedora and EPEL need to conditionalize use of the macros.  That can be done like this:
+
+
    +%{?filter_setup:
+%filter_provides_in %{python_sitearch}.*\.so$
+%filter_setup
+}
+
    
+
 == Examples ==
 
 
@@ -94,8 +103,10 @@ On a x86_64 machine, the pidgin-libnotify provides pidgin-libnotify.so()(64bit),
 To filter this out, we could use:
 
 
    +%{?filter_setup:
 %filter_provides_in %{_libdir}/purple-2/.*\.so$
 %filter_setup
+}
 
    
 
 === Arch-specific extensions to scripting languages ===
@@ -104,20 +115,20 @@ e.g. to ensure an arch-specific perl-* package won't provide or require things t
 
 
     # we don't want to provide private Perl extension libs
+%{?filter_setup:
 %filter_provides_in %{perl_vendorarch}/.*\.so$ 
 %filter_provides_in -P %{perl_archlib}/(?!CORE/libperl).*\.so$ 
-
-# actually set up the filtering
 %filter_setup
+}
 
    
 
 The recipe for python-* is very similar:
 
     # we don't want to provide private python extension libs
+%{?filter_setup:
 %filter_provides_in %{python_sitearch}/.*\.so$ 
-
-# actually set up the filtering
 %filter_setup
+}
 
    
 
 === %_docdir filtering ===
@@ -126,9 +137,9 @@ By policy, nothing under %_docdir is allowed to either "provide" or "require" an
 
 
     # we don't want to either provide or require anything from _docdir, per policy
+%{?filter_setup:
 %filter_provides_in %{_docdir} 
 %filter_requires_in %{_docdir}
-
-# actually set up the filtering
 %filter_setup
+}
 
    

From 14050771bdbc66a30662524b339b48b6f7418096 Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Oct 04 2010 19:03:42 +0000
Subject: [PATCH 569/3559] Update No Bundled Library guidelines


---

diff --git a/Packaging:Guidelines.mw b/Packaging:Guidelines.mw
index 15b1fac..1ad6e51 100644
--- a/Packaging:Guidelines.mw
+++ b/Packaging:Guidelines.mw
@@ -488,9 +488,9 @@ Packages which explicitly need to link against the static version must Bui
 
 == Duplication of system libraries ==
 
-A package should not include or build against a local copy of a library that exists on a system. The package should be patched to use the system libraries.  This prevents old bugs and security holes from living on after the core system libraries have been fixed.  More rationale for this is on the [[Packaging:No Bundled Libraries|No Bundled Libraries]] page.
-
+A package should not include or build against a local copy of a library that exists on a system. The package should be patched to use the system libraries. This prevents old bugs and security holes from living on after the core system libraries have been fixed. Some packages may be granted an exception to this. Please see the [[Packaging:No Bundled Libraries|No Bundled Libraries]] page for rationale, the process for being granted an exception, and the requirements if your package is bundling. 
 {{Anchor|Rpath}}
+
 == Beware of Rpath ==
 Sometimes, code will hardcode specific library paths when linking binaries (using the -rpath or -R flag). This is commonly referred to as an rpath. Normally, the dynamic linker and loader (ld.so) resolve the executable's dependencies on shared libraries and load what is required. However, when -rpath or -R is used, the location information is then hardcoded into the binary and is examined by ld.so in the beginning of the execution. Since the Linux dynamic linker is usually smarter than a hardcoded path, we usually do not permit the use of rpath in Fedora.
 

From 7f7325289890c7119a16a68014c905941e87ea9d Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Oct 06 2010 17:28:01 +0000
Subject: [PATCH 570/3559] Add rationale


---

diff --git a/Packaging:Conflicts.mw b/Packaging:Conflicts.mw
index 04b67ac..a800b70 100644
--- a/Packaging:Conflicts.mw
+++ b/Packaging:Conflicts.mw
@@ -11,9 +11,12 @@
 
 {{Anchor|Conflicts}}
 == Conflicts ==
-Whenever possible, Fedora packages should avoid conflicting with each other. Unfortunately, this is not always possible. These guidelines illustrate how conflicts should be handled in Fedora, specifically concerning when and when not to use the Conflicts: field.
+Whenever possible, Fedora packages should avoid conflicting with each other. Conflicts result in a transaction set where the user has to decipher the error message and make some sort of decision. The transaction set doesn't provide information to the user about why two packages conflict to help them make an informed decision.
+
+As Fedora packagers, we try to make it so both packages will install and run. Unfortunately, this is not always possible but we can usually make it so that both packages can install and the user can decide which package to enable when they configure the new package.. In the few remaining cases, we have to use Conflicts: tags. These guidelines illustrate how conflicts should be handled in Fedora, specifically concerning when and when not to use the Conflicts: field. 
 
 {{Anchor|AcceptableUsesOfConflicts}}
+
 == Acceptable Uses of Conflicts: ==
 As a general rule, Fedora packages must NOT contain any usage of the Conflicts: field. This field is commonly misused, when a Requires: would usually be more appropriate. It confuses depsolvers and end-users for no good reason. However, there are some cases in which using the Conflicts: field is appropriate and acceptable.
 

From 82bc5fcaad22a3bc49c2587060940651e1b32e33 Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Oct 06 2010 17:32:22 +0000
Subject: [PATCH 571/3559] Add guidance for content of an rpm changelog


---

diff --git a/Packaging:Guidelines.mw b/Packaging:Guidelines.mw
index 1ad6e51..dcbb5d8 100644
--- a/Packaging:Guidelines.mw
+++ b/Packaging:Guidelines.mw
@@ -164,8 +164,10 @@ You must use one of the following formats:
 - And fix the link syntax.
 
    
 
+Changelog entries should provide a brief summary of the changes done to the package between releases, including noting updating to a new version, adding a patch, fixing other spec sections, note bugs fixed, and CVE's if any. They must never simply contain an entire copy of the source CHANGELOG entries.  The intent is to give the user a hint as to what changed in a package update without overwhelming them with the technical details. Links to upstream changelogs can be entered for those who want additional information.
 
 {{Anchor|tags}}
+
 == Tags ==
 *The ''Packager'' tag should not be used in spec files. The identities of the packagers are evident from the changelog entries. By not using the ''Packager'' tag, you also avoid seeing bad binaries rebuilt by someone else with your name in the header.  See also the '''Maximum RPM definition of the Packager tag''' at [http://www.rpm.org/max-rpm/s1-rpm-inside-tags.html#S3-RPM-INSIDE-PACKAGER-TAG www.rpm.org] .  If you need to include information about the packager in the rpms ''you'' built, use %packager in your ~/.rpmmacros instead.
 *The ''Vendor'' tag should not be used. It is set automatically by the build system.

From f2cdbcc314f148d6b378ec243ea55d2e9bf23a16 Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Oct 06 2010 17:38:11 +0000
Subject: [PATCH 572/3559] Make filtering section just point to the Filtering page


---

diff --git a/Packaging:Perl.mw b/Packaging:Perl.mw
index 2929699..86a24d8 100644
--- a/Packaging:Perl.mw
+++ b/Packaging:Perl.mw
@@ -58,62 +58,12 @@ Some packages link to libperl.so, usually to provide embedded perl functionality
 {{Anchor|depfiltering}}
 
 == Filtering Requires: and Provides ==
+RPM's dependency generator can often throw in additional dependencies and will often think packages provide functionality contrary to reality. To fix this, the dependency generator needs to be overriden so that the additional dependencies can be filtered out. Please see [[Packaging:AutoProvidesAndRequiresFiltering]] for information.
 
-RPM's dependency generator can often throw in additional dependencies and will often think packages provide functionality contrary to reality.  To fix this, the dependency generator needs to be overriden so that the additional dependencies can be filtered out.  There are two main ways to do this:
-
-=== In %prep (preferred) ===
-
-Filtering can be done entirely in the SPEC file, in the %prep section:
-
-
    -%prep
-%setup -q -n Foo-%{version}
-
-cat << \EOF > %{name}-prov
-#!/bin/sh
-%{__perl_provides} $* |\
-sed -e '/perl(unwanted_provide)/d'
-EOF
-
-%global __perl_provides %{_builddir}/%{name}-%{version}/%{name}-prov
-chmod +x %{__perl_provides}
-
-
-cat << \EOF > %{name}-req
-#!/bin/sh
-%{__perl_requires} $* |\
-sed -e '/perl(unwanted_require)/d'
-EOF
-
-%global __perl_requires %{_builddir}/%{name}-%{version}/%{name}-req
-chmod +x %{__perl_requires}
-
    
-
-=== External filtering ===
-
-Or the script can be placed in an external file and referenced from the specfile.  This is worse than the above because the full path of the to-be-overridden script needs to be hardcoded into the file, ignoring the system rpmbuild config.  It is, however, the method used by a significant number of existing packages.
-
-
    -Source98: filter-provides.sh
-Source99: filter-requires.sh
-
-%global __perl_provides %{SOURCE98}
-%global __perl_requires %{SOURCE99}
-
    
-where filter-provides.sh contains:
-
    -#!/bin/sh
-/usr/lib/rpm/perl.prov $* |
-sed -e '/perl(unwanted_provide)/d'
-
    
-and filter-requires.sh contains:
-
    -#!/bin/sh
-/usr/lib/rpm/perl.req $* |
-sed -e '/perl(unwanted_require)/d'
-
    
+{{admon/note| In the past, several other methods were given for doing this filtering. Those should be considered deprecated and packages should be updated to use the macros on [[Packaging:AutoProvidesAndRequiresFiltering]] as time and the natural rebuild cycle permits.}}
 
 {{Anchor|manualdeps}}
+
 == Manual Requires and Provides ==
 
 Under some circumstances, RPM's automatic dependency generator can miss dependencies that should be added.

From ad0df47088a98c62b4f7bc7d8e5d715c58c66a68 Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Oct 06 2010 17:39:30 +0000
Subject: [PATCH 573/3559] Add title to admon box so the whole thing isn't bold


---

diff --git a/Packaging:Perl.mw b/Packaging:Perl.mw
index 86a24d8..a2e994a 100644
--- a/Packaging:Perl.mw
+++ b/Packaging:Perl.mw
@@ -60,7 +60,7 @@ Some packages link to libperl.so, usually to provide embedded perl functionality
 == Filtering Requires: and Provides ==
 RPM's dependency generator can often throw in additional dependencies and will often think packages provide functionality contrary to reality. To fix this, the dependency generator needs to be overriden so that the additional dependencies can be filtered out. Please see [[Packaging:AutoProvidesAndRequiresFiltering]] for information.
 
-{{admon/note| In the past, several other methods were given for doing this filtering. Those should be considered deprecated and packages should be updated to use the macros on [[Packaging:AutoProvidesAndRequiresFiltering]] as time and the natural rebuild cycle permits.}}
+{{admon/note| Updating deprecated methods|In the past, several other methods were given for doing this filtering. Those should be considered deprecated and packages should be updated to use the macros on [[Packaging:AutoProvidesAndRequiresFiltering]] as time and the natural rebuild cycle permits.}}
 
 {{Anchor|manualdeps}}
 

From 5aae446b86d3fd231c42844261e28759129a6f75 Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Oct 06 2010 17:48:27 +0000
Subject: [PATCH 574/3559] merge in perl_default_filter


---

diff --git a/Packaging:AutoProvidesAndRequiresFiltering.mw b/Packaging:AutoProvidesAndRequiresFiltering.mw
index d1a5469..16dd70b 100644
--- a/Packaging:AutoProvidesAndRequiresFiltering.mw
+++ b/Packaging:AutoProvidesAndRequiresFiltering.mw
@@ -93,6 +93,28 @@ These macros were not defined in EPEL5.  People wanting to share one spec file w
 }
    +=== Simplified macros for common cases === + +In some cases, the filtering of extraneous Provides: is fairly generic to all packages which provide similar things. There are simple macros that setup filters correctly for those cases so that you can do the filtering with one line. If you need to filter a bit more than the simple macro provides, you still have the option to use the macros listed above. + +==== Perl ==== +Perl extension modules can be filtered using this macro: + +
    +%{?perl_default_filter}
+
    + +This is equivalent to: + +
    +%filter_provides_in %{perl_vendorarch}/.*\\.so$ 
+%filter_provides_in -P %{perl_archlib}/(?!CORE/libperl).*\\.so$ 
+%filter_from_provides /perl(UNIVERSAL)/d; /perl(DB)/d 
+%filter_provides_in %{_docdir} 
+%filter_requires_in %{_docdir} 
+%filter_setup 
+
    + == Examples == @@ -115,14 +137,11 @@ e.g. to ensure an arch-specific perl-* package won't provide or require things t 
     # we don't want to provide private Perl extension libs
-%{?filter_setup:
-%filter_provides_in %{perl_vendorarch}/.*\.so$ 
-%filter_provides_in -P %{perl_archlib}/(?!CORE/libperl).*\.so$ 
-%filter_setup
+%{?perl_default_filter}
 }
    -The recipe for python-* is very similar: +A recipe for python: 
     # we don't want to provide private python extension libs
 %{?filter_setup:

From b26a99c652cd03f60f0d10a149f2ca7f9d37db9e Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Oct 06 2010 17:51:21 +0000
Subject: [PATCH 575/3559] Fix category


---

diff --git a/Packaging:AutoProvidesAndRequiresFiltering.mw b/Packaging:AutoProvidesAndRequiresFiltering.mw
index 16dd70b..40b51df 100644
--- a/Packaging:AutoProvidesAndRequiresFiltering.mw
+++ b/Packaging:AutoProvidesAndRequiresFiltering.mw
@@ -1,5 +1,3 @@
-[[Category:Packaging_guidelines_drafts]]
-
 == Summary ==
 
 RPM has no general or standard mechanism to enable filtering of auto-generated requires and provides; this guideline describes how Fedora has implemented such a system.
@@ -10,8 +8,6 @@ RPM has no general or standard mechanism to enable filtering of auto-generated r
 
 == Rationale ==
 
-RPM has no general mechanism to enable filtering of auto-generated requires and provides; this feature aims to implement one. 
-
 The auto requires and provides system contained in RPM is quite useful; however, it often picks up "private" package capabilities that shouldn't be advertised as global, things that are "just wrong", or things prohibited by policy (e.g. deps from inside %{_docdir}).
 
 For example:
@@ -162,3 +158,5 @@ By policy, nothing under %_docdir is allowed to either "provide" or "require" an
 %filter_setup
 }
    + +[[Category:Packaging_guidelines]] From 04b9fb3f207eb526da3963e41b2fc775401ed7db Mon Sep 17 00:00:00 2001 From: Toshio Date: Oct 06 2010 17:52:40 +0000 Subject: [PATCH 576/3559] Link directly to the perl section --- diff --git a/Packaging:Perl.mw b/Packaging:Perl.mw index a2e994a..fc73285 100644 --- a/Packaging:Perl.mw +++ b/Packaging:Perl.mw @@ -58,9 +58,9 @@ Some packages link to libperl.so, usually to provide embedded perl functionality {{Anchor|depfiltering}} == Filtering Requires: and Provides == -RPM's dependency generator can often throw in additional dependencies and will often think packages provide functionality contrary to reality. To fix this, the dependency generator needs to be overriden so that the additional dependencies can be filtered out. Please see [[Packaging:AutoProvidesAndRequiresFiltering]] for information. +RPM's dependency generator can often throw in additional dependencies and will often think packages provide functionality contrary to reality. To fix this, the dependency generator needs to be overriden so that the additional dependencies can be filtered out. Please see [[https://fedoraproject.org/wiki/Packaging:AutoProvidesAndRequiresFiltering#Perl]] for information. -{{admon/note| Updating deprecated methods|In the past, several other methods were given for doing this filtering. Those should be considered deprecated and packages should be updated to use the macros on [[Packaging:AutoProvidesAndRequiresFiltering]] as time and the natural rebuild cycle permits.}} +{{admon/note| Updating deprecated methods|In the past, several other methods were given for doing this filtering. Those should be considered deprecated and packages should be updated to use the macros on [[https://fedoraproject.org/wiki/Packaging:AutoProvidesAndRequiresFiltering#Perl]] as time and the natural rebuild cycle permits.}} {{Anchor|manualdeps}} From 513fd75b8e53a5dc7c3183971173491368f47776 Mon Sep 17 00:00:00 2001 From: Toshio Date: Oct 06 2010 17:59:18 +0000 Subject: [PATCH 577/3559] Remove external macros link and just point out that they're available in all Fedora and RHEL6+. --- diff --git a/Packaging:AutoProvidesAndRequiresFiltering.mw b/Packaging:AutoProvidesAndRequiresFiltering.mw index 40b51df..a47554b 100644 --- a/Packaging:AutoProvidesAndRequiresFiltering.mw +++ b/Packaging:AutoProvidesAndRequiresFiltering.mw @@ -22,7 +22,7 @@ As it stands, filtering these auto-generated requires and provides is difficult * removing items from the requires stream (post-scan filtering) * removing items from the provides stream (post-scan filtering) -'''Macros defining the filtering system: [http://fedorapeople.org/~cweyl/macros.filtering macros.filtering]''' +These macros are available in all non-EOL Fedora and RHEL6 or higher. == Usage == From 2b31adbff7816f08e6d6c72d93465f79ef4d4795 Mon Sep 17 00:00:00 2001 From: Spot Date: Oct 06 2010 18:40:30 +0000 Subject: [PATCH 578/3559] /* Template */ --- diff --git a/Packaging:D.mw b/Packaging:D.mw index e04c9f0..35e2770 100644 --- a/Packaging:D.mw +++ b/Packaging:D.mw @@ -68,7 +68,7 @@ Group: Development/Libraries %build %configure -make %{?_smp_mflags} +make %{?_smp_mflags} INCLUDEDIR=%{d_includedir} %install From 68d5984cc7fb288b38092e9ebd884c4930f8af29 Mon Sep 17 00:00:00 2001 From: Toshio Date: Oct 06 2010 18:41:21 +0000 Subject: [PATCH 579/3559] Update to account for gtk-doc-like cases --- diff --git a/Packaging:Guidelines.mw b/Packaging:Guidelines.mw index dcbb5d8..d239dc8 100644 --- a/Packaging:Guidelines.mw +++ b/Packaging:Guidelines.mw @@ -888,16 +888,18 @@ If you are unsure if something is considered approved content, ask on fedora-dev {{Anchor|FileAndDirectoryOwnership}} == File and Directory Ownership == -Your package should own all of the files that are installed as part of the %install process. Packages must not own files already owned by other packages. The rule of thumb here is that the first package to be installed should own the files that other packages may rely upon. This means, for example, that no package in Fedora should ever share ownership with any of the files owned by the filesystem or man package. If you feel that you have a good reason to own a file or that another package owns, then please present that at package review time. +Your package should own all of the files that are installed as part of the %install process. Packages must not own files already owned by other packages. The rule of thumb here is that the first package to be installed should own the files that other packages may rely upon. This means, for example, that no package in Fedora should ever share ownership with any of the files owned by the filesystem or man package. If you feel that you have a good reason to own a file or that another package owns, then please present that at package review time. -Directory ownership is a little more complex than file ownership. Although the rule of thumb is the same: own all the directories you create but none of the directories of packages you depend on, there are several instances where it's desirable for multiple packages to own a directory. +Directory ownership is a little more complex than file ownership. Packages must own all directories they put files in, except for: +* any directories owned by the filesystem, man, or other explicitly created -filesystem packages +* any directories owned by other packages in your package's natural dependency chain + +In this context, a package's "natural dependency chain" is defined as the set of packages necessary for that package to function normally. To be specific, you do not need to require a package for the sole fact that it happens to own a directory that your package places files in. If your package already requires that package for other reasons, then your package should not also own that directory. In all cases we are guarding against unowned directories being present on a system. Please see [[Packaging:UnownedDirectories]] for the details. {{admon/important|Note on multiple ownership| Note that when co-owning directories, you must ensure that the ownership and permissions on the directory match in all packages that own it.}} -{{admon/important|Note on directories| If a directory is explicitly required by packages in Fedora (such as /usr/lib/mozilla/plugins), only one package should own it, so that dependency solving is deterministic.}} - Here are examples that describe how to handle most cases of directory ownership. === The directory is wholly contained in your package, or involves core functionality of your package. === @@ -909,32 +911,36 @@ gnucash places many files under the /usr/share/gnucash directory Solution: the gnucash package should own the /usr/share/gnucash directory -=== The package places files in many directories that are part of a larger environment's infrastructure. === +=== The directory is also owned by a package implementing required functionality of your package. === An example: + 
    -kdeutils places files in (among other places)
- /usr/share/applications/kde4
- /usr/share/kde4/apps
- /usr/share/kde4/services
+pam owns the /etc/pam.d directory
+gdm places files into /etc/pam.d
+gdm depends on pam to function normally, and would Require: pam (either implicitly or explicitly) separate from the directory ownership.
    -Solution: the infrastructure directories above should be placed in a kde-filesystem package, and kdeutils should Require: the kde-filesystem package. +Solution: the pam package should own the /etc/pam.d directory, and gdm should Require: the pam package. -=== The directory is also owned by a package implementing required functionality of your package. === +=== The directory is owned by a package which is not required for your package to function. === + +Some packages create and own directories with the intention of permitting other packages to store appropriate files, but those other packages do not need that original package to be present to function properly. An example: 
    -pam owns the /etc/pam.d directory
-gdm places files into /etc/pam.d
+gtk-doc owns the /usr/share/gtk-doc/ directory
+evolution puts files into /usr/share/gtk-doc/
+evolution does not need gtk-doc in order to function properly.
+Nothing in evolution's dependency chain owns /usr/share/gtk-doc/
    -Solution: the pam package should own the /etc/pam.d directory, and gdm should Require: the pam package. +Solution: the evolution package should own the /usr/share/gtk-doc directory. There is no need to add an explicit Requires on gtk-doc solely for the directory ownership. -=== Multiple packages own files in a common directory but none of them needs to require the others. === +{{admon/important|An exception|Sometimes, it may be preferable for such directories to be owned by an "artificial filesystem" package, such as mozilla-filesystem. These packages are designed to be explicitly required when other packages store files in their directories, thus, in such situations, these packages should explicitly Require the artificial filesystem package and not multiply own those directories. Packagers should consider the number of affected directories and packages when determining whether to create artificial filesystem packages, and use their own best judgement to determine if this is necessary or not.}} -An example: +Another example: 
     bash-completion owns the /etc/bash_completion.d directory and uses the files placed there to configure itself.
@@ -947,24 +953,10 @@ Solution: Both the git and bzr packages should own the /etc/bash_completion.d di
 
 === The package you depend on to provide a directory may choose to own a different directory in a later version and your package will run unmodified with that later version. ===
 
-One common example of this is a Perl module.  Assume ''perl-A-B'' depends on ''perl-A'' and installs files into /usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi/A/B.  The base Perl package guarantees that it will own /usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi for as long as it remains compatible with version 5.8.8, but a future upgrade of the ''perl-A'' package may install into (and thus own) /usr/lib/perl5/vendor_perl/5.9.0/i386-linux-thread-multi/A.  So the ''perl-A-B'' package needs to own /usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi/A as well as /usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi/A/B in order to maintain proper ownership.
-
-{{Anchor|DuplicateFiles}}
-=== Duplicate Files ===
-A Fedora package must not list a file more than once in the spec file's %files listings.  If you think your package is a valid exception to this, please bring it to the attention of the Packaging Committee so they can improve on this Guideline.
-
-One notable exception to this rule is around license texts. There are certain situations where it is required to duplicate the license text across multiple %files section within a package. For more details, please refer to [[Packaging:LicensingGuidelines#Subpackage_Licensing]].
-{{Anchor|FilePermissions}}
-
-=== File Permissions ===
-Permissions on files must be set properly. Executables should be set with executable permissions, for example. Every %files section must include a %defattr(...) line. Here is a good default:
-
    -%files
-%defattr(-,root,root,-)
-
    
-Unless you have a very good reason to deviate from that, you should use %defattr(-,root,root,-) for all %files sections in your package.
+An example involving Perl modules:
 
-{{Anchor|UsersAndGroups}}
+Assume perl-A-B depends on perl-A and installs files into /usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi/A/B.  
+The base Perl package guarantees that it will own /usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi for as long as it remains compatible with version 5.8.8, but a future upgrade of the perl-A package may install into (and thus own) /usr/lib/perl5/vendor_perl/5.9.0/i386-linux-thread-multi/A.  So the perl-A-B package needs to own /usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi/A as well as /usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi/A/B in order to maintain proper ownership.
 
 == Users and Groups ==
 

From cdc098a05902923d47c6131f04fea3001af93c73 Mon Sep 17 00:00:00 2001
From: Spot 
Date: Oct 06 2010 18:42:30 +0000
Subject: [PATCH 580/3559] /* Template */


---

diff --git a/Packaging:D.mw b/Packaging:D.mw
index 35e2770..d3b8963 100644
--- a/Packaging:D.mw
+++ b/Packaging:D.mw
@@ -68,8 +68,7 @@ Group:          Development/Libraries
 
 %build
 %configure
-make %{?_smp_mflags} INCLUDEDIR=%{d_includedir}
-
+make %{?_smp_mflags}
 
 %install
 mkdir -p %{buildroot}%{_libdir}

From 94b43e15e0d26bf22c1116cd87dd96a1e0eab5e6 Mon Sep 17 00:00:00 2001
From: Spot 
Date: Oct 06 2010 18:45:31 +0000
Subject: [PATCH 581/3559] /* Template */


---

diff --git a/Packaging:D.mw b/Packaging:D.mw
index d3b8963..04816a3 100644
--- a/Packaging:D.mw
+++ b/Packaging:D.mw
@@ -67,6 +67,7 @@ Group:          Development/Libraries
 
 
 %build
+export DFLAGS="%{_d_optflags}"
 %configure
 make %{?_smp_mflags}
 

From bcbb119ee05af0acffeff779689aa0724447a46f Mon Sep 17 00:00:00 2001
From: Spot 
Date: Oct 06 2010 18:47:34 +0000
Subject: [PATCH 582/3559] /* Compiler options */


---

diff --git a/Packaging:D.mw b/Packaging:D.mw
index 04816a3..0c23f6e 100644
--- a/Packaging:D.mw
+++ b/Packaging:D.mw
@@ -14,6 +14,8 @@ All D packages depend on ldc to build, so every package must have ldc as BuildRe
 -g ''generates debug information''
    
 -O2 ''is the optimisation level''
 
+Some D packages use Makefiles, which usually use the $DFLAGS variable in the same way that C packages with Makefiles use $CFLAGS. In this case, export DFLAGS="%{_d_optflags}" is usually appropriate. In other cases, the build script in the D package has an option to pass in %{_d_optflags}. It is the responsibility of the packager to ensure that %{_d_optflags} are used with ldc when the package is built.
+
 === Header Files ===
 D packages contain header files, which end with .d or .di. These header files must be installed into %{_d_includedir}/%{name}.
 

From b9a4adf8ac6ad54a67fb7adfa335b4a6ac4d52a1 Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Oct 06 2010 20:35:08 +0000
Subject: [PATCH 584/3559] Add category


---

diff --git a/Packaging:RPM_Source_Dir.mw b/Packaging:RPM_Source_Dir.mw
index 15561ae..25eedf6 100644
--- a/Packaging:RPM_Source_Dir.mw
+++ b/Packaging:RPM_Source_Dir.mw
@@ -29,3 +29,5 @@ install -m 644 %{SOURCE1} $RPM_BUILD_ROOT/etc/httpd/conf.d
 sed -e "s/@PHP_APIVER@/%{apiver}/;s/@PHP_ZENDVER@/%{zendver}/;s/@PHP_PDOVER@/%{pdover}/" \
     < %{SOURCE3} > macros.php
    + +[[Category:Packaging guidelines]] From b150fceca69a521491dd001c04e25599d0ccb7c9 Mon Sep 17 00:00:00 2001 From: Toshio Date: Oct 06 2010 20:39:35 +0000 Subject: [PATCH 585/3559] Add section for improper use of _sourcedir --- diff --git a/Packaging:Guidelines.mw b/Packaging:Guidelines.mw index d239dc8..dcfdf2d 100644 --- a/Packaging:Guidelines.mw +++ b/Packaging:Guidelines.mw @@ -681,6 +681,9 @@ rpm -qpiv /builddir/build/SRPMS/[SRPM] Check the rpm output for unexpanded macros (%{foo}) or missing information (when%{?foo} is expanded to the empty string). Even easier is to simply avoid macros in Summary: and %description unless they are defined in the current spec file. +=== Improper use of %_sourcedir === +Packages which use files itemized as Source# files, must refer to those files by their Source# macro name, and must not use $RPM_SOURCE_DIR or %{sourcedir} to refer to those files. See [[Packaging:RPM_Source_Dir]] for full details. + == %global preferred over %define == Use %global instead of %define, unless you really need only locally defined submacros within other macro definitions (a very rare case). From 8343514863f908b824cce83f6831f824742249d9 Mon Sep 17 00:00:00 2001 From: Tibbs Date: Oct 06 2010 20:55:22 +0000 Subject: [PATCH 586/3559] Remove extraneous dot. --- diff --git a/Packaging:Guidelines.mw b/Packaging:Guidelines.mw index dcfdf2d..4402241 100644 --- a/Packaging:Guidelines.mw +++ b/Packaging:Guidelines.mw @@ -905,7 +905,7 @@ In all cases we are guarding against unowned directories being present on a syst Here are examples that describe how to handle most cases of directory ownership. -=== The directory is wholly contained in your package, or involves core functionality of your package. === +=== The directory is wholly contained in your package, or involves core functionality of your package === An example: 
    
From 25efdf0142073b0b242432bd568c3542c266d3cb Mon Sep 17 00:00:00 2001
From: Tibbs 
Date: Oct 06 2010 20:56:13 +0000
Subject: [PATCH 587/3559] Remove extraneous dots from section titles.


---

diff --git a/Packaging:Guidelines.mw b/Packaging:Guidelines.mw
index 4402241..ba8e899 100644
--- a/Packaging:Guidelines.mw
+++ b/Packaging:Guidelines.mw
@@ -914,7 +914,7 @@ gnucash places many files under the /usr/share/gnucash directory
 
 Solution: the gnucash package should own the /usr/share/gnucash directory
 
-=== The directory is also owned by a package implementing required functionality of your package. ===
+=== The directory is also owned by a package implementing required functionality of your package ===
 
 An example:
 
@@ -926,7 +926,7 @@ gdm depends on pam to function normally, and would Require: pam (either implicit
 
 Solution: the pam package should own the /etc/pam.d directory, and gdm should Require: the pam package.
 
-=== The directory is owned by a package which is not required for your package to function. ===
+=== The directory is owned by a package which is not required for your package to function ===
 
 Some packages create and own directories with the intention of permitting other packages to store appropriate files, but those other packages do not need that original package to be present to function properly.
 
@@ -954,7 +954,7 @@ bzr places files into /etc/bash_completion.d
 Solution: Both the git and bzr packages should own the /etc/bash_completion.d directory as bash-completion is optional functionality and the installation of git or bzr should not force the installation of bash-completion.
 {{admon/important|Rule of Thumb|When determining whether this exception applies, packagers and reviewers should ask this question: Do the files in this common directory enhance or add functionality to another package, where that other package is not necessary to be present for the primary functionality of this package?}}
 
-=== The package you depend on to provide a directory may choose to own a different directory in a later version and your package will run unmodified with that later version. ===
+=== The package you depend on to provide a directory may choose to own a different directory in a later version and your package will run unmodified with that later version ===
 
 An example involving Perl modules:
 

From e0817f1e99c1c2018dadf5e94a20ef01e8aad1dd Mon Sep 17 00:00:00 2001
From: Spot 
Date: Oct 13 2010 16:51:56 +0000
Subject: [PATCH 588/3559] Created page with '== Packages with Bundled Libraries ==  Packages which contain bundled libraries (bundled libraries being defined as libraries which exist and are mantained independently, whether...'


---

diff --git a/Packaging:Treatment_Of_Bundled_Libraries.mw b/Packaging:Treatment_Of_Bundled_Libraries.mw
new file mode 100644
index 0000000..826fb67
--- /dev/null
+++ b/Packaging:Treatment_Of_Bundled_Libraries.mw
@@ -0,0 +1,16 @@
+== Packages with Bundled Libraries ==
+
+Packages which contain bundled libraries (bundled libraries being defined as libraries which exist and are mantained independently, whether or not they are packaged separately for Fedora) must be handled in the following manner:
+
+* Bundled libraries (and/or their source code) must be explicitly deleted during %prep. Build scripts may need to be patched to deal with this situation. Whenever possible, the patching should be done in a way to conditionalize use of the bundled libraries, so that it can be sent upstream for consideration.
+* It is not necessary to remove bundled libraries from the source tarball unless there is a legal reason to do so
+* Bundled libraries must NEVER end up in a package, even if they are not used.
+
+== Exceptions ==
+There are some notable exceptions:
+
+=== Bootstrapping ===
+Packages which depend upon bundled libraries in order to bootstrap a build may retain them for use when the package is built in bootstrapping mode. When the package is built in a normal mode, the normal guidelines apply.
+
+=== Conditionalized functionality ===
+Packages which bundle specific subsets of third-party source code with the sole purpose of providing functionality that is not available in the system copy, and explicitly conditionalize that use in such a way that if the system copy provides that functionality, the bundled source code is not used, are exempt from the requirement to remove the bundled source code.

From a0737841c3eebda396d0bd591b40969447d5747a Mon Sep 17 00:00:00 2001
From: Spot 
Date: Oct 13 2010 16:53:47 +0000
Subject: [PATCH 589/3559] *Empty MediaWiki Message*


---

diff --git a/Packaging:Treatment_Of_Bundled_Libraries.mw b/Packaging:Treatment_Of_Bundled_Libraries.mw
index 826fb67..138b28d 100644
--- a/Packaging:Treatment_Of_Bundled_Libraries.mw
+++ b/Packaging:Treatment_Of_Bundled_Libraries.mw
@@ -14,3 +14,6 @@ Packages which depend upon bundled libraries in order to bootstrap a build may r
 
 === Conditionalized functionality ===
 Packages which bundle specific subsets of third-party source code with the sole purpose of providing functionality that is not available in the system copy, and explicitly conditionalize that use in such a way that if the system copy provides that functionality, the bundled source code is not used, are exempt from the requirement to remove the bundled source code.
+
+=== Explicit Exceptions ===
+Packages which have been given an explicit exception by FESCo are exempt from these guidelines.

From 03532f55754dd975b754712e355cf2d51c3188e1 Mon Sep 17 00:00:00 2001
From: Spot 
Date: Oct 13 2010 16:54:48 +0000
Subject: [PATCH 590/3559] *Empty MediaWiki Message*


---

diff --git a/Packaging:Treatment_Of_Bundled_Libraries.mw b/Packaging:Treatment_Of_Bundled_Libraries.mw
index 138b28d..b8c4b13 100644
--- a/Packaging:Treatment_Of_Bundled_Libraries.mw
+++ b/Packaging:Treatment_Of_Bundled_Libraries.mw
@@ -13,7 +13,7 @@ There are some notable exceptions:
 Packages which depend upon bundled libraries in order to bootstrap a build may retain them for use when the package is built in bootstrapping mode. When the package is built in a normal mode, the normal guidelines apply.
 
 === Conditionalized functionality ===
-Packages which bundle specific subsets of third-party source code with the sole purpose of providing functionality that is not available in the system copy, and explicitly conditionalize that use in such a way that if the system copy provides that functionality, the bundled source code is not used, are exempt from the requirement to remove the bundled source code.
+Packages which bundle specific subsets of third-party source code with the sole purpose of providing functionality that is not available in the system copy, and explicitly conditionalize that use in such a way that if the system copy provides that functionality, the bundled source code is not used, are exempt from the requirement to remove the bundled source code. Packages in this exception case MUST document this situation in a specfile comment, and verify that the functionality is properly conditionalized with each update.
 
 === Explicit Exceptions ===
 Packages which have been given an explicit exception by FESCo are exempt from these guidelines.

From f3dda8d55b8aebc1a0c137adcd05dc516d8dfa47 Mon Sep 17 00:00:00 2001
From: Spot 
Date: Oct 13 2010 16:56:42 +0000
Subject: [PATCH 591/3559] *Empty MediaWiki Message*


---

diff --git a/Packaging:Treatment_Of_Bundled_Libraries.mw b/Packaging:Treatment_Of_Bundled_Libraries.mw
index b8c4b13..46322cd 100644
--- a/Packaging:Treatment_Of_Bundled_Libraries.mw
+++ b/Packaging:Treatment_Of_Bundled_Libraries.mw
@@ -13,7 +13,7 @@ There are some notable exceptions:
 Packages which depend upon bundled libraries in order to bootstrap a build may retain them for use when the package is built in bootstrapping mode. When the package is built in a normal mode, the normal guidelines apply.
 
 === Conditionalized functionality ===
-Packages which bundle specific subsets of third-party source code with the sole purpose of providing functionality that is not available in the system copy, and explicitly conditionalize that use in such a way that if the system copy provides that functionality, the bundled source code is not used, are exempt from the requirement to remove the bundled source code. Packages in this exception case MUST document this situation in a specfile comment, and verify that the functionality is properly conditionalized with each update.
+Packages which bundle specific subsets of third-party source code with the sole purpose of providing functionality that is not available in the system copy, and explicitly conditionalize that use in such a way that if the system copy provides that functionality, the bundled source code is not used, are exempt from the requirement to delete the bundled source code during %prep. Packages in this exception case MUST document this situation in a specfile comment, and verify that the functionality is properly conditionalized with each update.
 
 === Explicit Exceptions ===
 Packages which have been given an explicit exception by FESCo are exempt from these guidelines.

From 38e7438d14cd659d6d7523a4f8efa56395738145 Mon Sep 17 00:00:00 2001
From: Spot 
Date: Oct 13 2010 16:58:44 +0000
Subject: [PATCH 592/3559] *Empty MediaWiki Message*


---

diff --git a/Packaging:Treatment_Of_Bundled_Libraries.mw b/Packaging:Treatment_Of_Bundled_Libraries.mw
index 46322cd..d1d72a5 100644
--- a/Packaging:Treatment_Of_Bundled_Libraries.mw
+++ b/Packaging:Treatment_Of_Bundled_Libraries.mw
@@ -16,4 +16,4 @@ Packages which depend upon bundled libraries in order to bootstrap a build may r
 Packages which bundle specific subsets of third-party source code with the sole purpose of providing functionality that is not available in the system copy, and explicitly conditionalize that use in such a way that if the system copy provides that functionality, the bundled source code is not used, are exempt from the requirement to delete the bundled source code during %prep. Packages in this exception case MUST document this situation in a specfile comment, and verify that the functionality is properly conditionalized with each update.
 
 === Explicit Exceptions ===
-Packages which have been given an explicit exception by FESCo are exempt from these guidelines.
+Packages which have been given an explicit exception by FESCo are exempt from these guidelines. See: [[Packaging:No_Bundled_Libraries]]

From 053496badc9eb29ecf092c7e3ce8ecf5d61136d3 Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Oct 21 2010 03:36:24 +0000
Subject: [PATCH 593/3559] /* Arch-specific extensions to scripting languages */


---

diff --git a/Packaging:AutoProvidesAndRequiresFiltering.mw b/Packaging:AutoProvidesAndRequiresFiltering.mw
index a47554b..c9015b6 100644
--- a/Packaging:AutoProvidesAndRequiresFiltering.mw
+++ b/Packaging:AutoProvidesAndRequiresFiltering.mw
@@ -134,7 +134,6 @@ e.g. to ensure an arch-specific perl-* package won't provide or require things t
 
     # we don't want to provide private Perl extension libs
 %{?perl_default_filter}
-}
 
    
 
 A recipe for python:

From 90162b0f4c793dbc7a863d4b9e724ec93abe6895 Mon Sep 17 00:00:00 2001
From: Tibbs 
Date: Nov 10 2010 14:52:07 +0000
Subject: [PATCH 594/3559] Note that rpmlint should be run on both binary and source rpms.


---

diff --git a/Packaging:Guidelines.mw b/Packaging:Guidelines.mw
index ba8e899..4daa171 100644
--- a/Packaging:Guidelines.mw
+++ b/Packaging:Guidelines.mw
@@ -122,7 +122,7 @@ Fedora's rpm includes a macro for libexecdir, %{_libexecdir}. Packa
 {{Anchor|rpmlint}}
 
 == Use rpmlint ==
-Run rpmlint on the rpms to examine them for common errors, and fix them (unless rpmlint is wrong, which can happen, too). If you find rpmlint's output cryptic, the -i switch to it can be used to get more verbose descriptions of most errors and warnings. The rpmlint package is available in the Fedora repositories.
+Run rpmlint on binary and source rpms to examine them for common errors, and fix them (unless rpmlint is wrong, which can happen, too). If you find rpmlint's output cryptic, the -i switch to it can be used to get more verbose descriptions of most errors and warnings. The rpmlint package is available in the Fedora repositories.
 
 === Rpmlint Errors ===
 

From 1df509c6d5bf353304b1498ec8ca5b6716ac8d85 Mon Sep 17 00:00:00 2001
From: Tibbs 
Date: Nov 10 2010 14:54:29 +0000
Subject: [PATCH 595/3559] Note that rpmlint should be run on both binary and source rpms.


---

diff --git a/Packaging:ReviewGuidelines.mw b/Packaging:ReviewGuidelines.mw
index 07f22d3..1833409 100644
--- a/Packaging:ReviewGuidelines.mw
+++ b/Packaging:ReviewGuidelines.mw
@@ -19,7 +19,7 @@ There are many many things to check for a review. This list is provided to assis
 
 {{admon/warning|MUST Items|Items marked as '''MUST''' are things that the package (or reviewer) '''MUST''' do. If a package fails a '''MUST''' item, that is considered a blocker. No package with blockers can be approved on a review. Those items must be fixed before approval can be given. }}
 
-* '''MUST''': rpmlint must be run on every package. The output should be posted in the review.[[Packaging/Guidelines#rpmlint|Packaging Guidelines: Use rpmlint]] 
    
+* '''MUST''': rpmlint must be run on the source rpm and all binary rpms the build produces. The output should be posted in the review.[[Packaging/Guidelines#rpmlint|Packaging Guidelines: Use rpmlint]] 
    
 * '''MUST''': The package must be named according to the [[Packaging/NamingGuidelines| Package Naming Guidelines]] .
    
 * '''MUST''': The spec file name must match the base package %{name}, in the format %{name}.spec unless your package has an exemption. [[Packaging/NamingGuidelines#Spec_file_name| Naming Guidelines: Spec File Naming]] . 
    
 * '''MUST''': The package must meet the [[Packaging/Guidelines|  Packaging Guidelines]] .
    

From d0d611c7d2b1ae8ec6e71a1ce4615c5785b5cdd8 Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Nov 10 2010 17:40:28 +0000
Subject: [PATCH 596/3559] Clarified requiring base package section


---

diff --git a/Packaging:Guidelines.mw b/Packaging:Guidelines.mw
index 4daa171..31d0543 100644
--- a/Packaging:Guidelines.mw
+++ b/Packaging:Guidelines.mw
@@ -431,10 +431,12 @@ A reasonable exception is when the main package itself is a development tool not
 {{Anchor|RequiringBasePackage}}
 
 == Requiring Base Package ==
-Devel packages must require the base package using a fully versioned dependency: Requires: %{name} = %{version}-%{release}.
-Usually, subpackages other than -devel should also require the base package using a fully versioned dependency.
+Subpackages are often extensions for their base package and in that case they should require their base package. It is almost always better to over specify the version, so it's best practice to just use a fully versioned dependency: Requires: %{name} = %{version}-%{release}. Devel packages are an example of a package that must require their base packages using a fully versioned dependency.  -libs subpackages which only contain shared libraries do not normally need to explicitly depend on %{name} = %{version}-%{release} as they normally aren't needed by the base package at runtime.
+
+If you end up in a situation where the main package depends on the subpackage and the subpackage on the main package you should think carefully about why you don't have everything in the main package.
 
 {{Anchor|SharedLibraries}}
+
 == Shared Libraries ==
 Whenever possible (and feasible), Fedora Packages containing libraries should build them as shared libraries. In addition, every binary RPM package which contains shared library files (not just symlinks) in any of the dynamic linker's default paths, must call ldconfig in %post and %postun. If the package has multiple subpackages with libraries, each subpackage should also have a %post/%postun section that calls /sbin/ldconfig. An example of the correct syntax for this is:
 
    
From 8397a665740e22f92c71d20f76bbe6709eba14c2 Mon Sep 17 00:00:00 2001
From: Spot 
Date: Nov 10 2010 18:34:31 +0000
Subject: [PATCH 598/3559] *Empty MediaWiki Message*


---

diff --git a/Packaging:Java.mw b/Packaging:Java.mw
index fa30f5a..87a84d4 100644
--- a/Packaging:Java.mw
+++ b/Packaging:Java.mw
@@ -2,49 +2,51 @@ These guidelines are laid out in order of relevance to packaging.
 
 == Introduction ==
 
-=== Background ===
-Traditionally, Java implementations have been available under a non-free license.  Free software clean room implementations of the class library largely centred around GNU Classpath.  GCJ, a Java frontend for GCC, allowed for native compilation of Java software.  In 2007, Sun released its reference implementation of Java under the GPL+Classpath exception as OpenJDK.  This included the bytecode interpreter, just-in-time (JIT) compiler (Hotspot), and the majority of its class library.  Due to the remaining small proprietary encumbrances, a project known as IcedTea was formed to build OpenJDK with entirely free tools, and provides Free software plugs for the encumbered pieces of the class libraries.  Recent (early 2008) developments have enabled Fedora to ship a package under the OpenJDK name.
-
 === The Basics ===
-The term Java means many things to many people:  a class library, a bytecode interpreter, a JIT compiler, a language specification, etc.  For the vast majority of users and developers, Java is a programming language and runtime environment that is architecture- and OS-agnostic.  The normal flow of code is .java (source file) ’ .class (Java bytecode) ’ .jar (a zip archive).  In the majority of cases, a user executes a Java program by specifying a class name containing a main method (just like C and C++).  Often, this is done by invoking the java binary with a list of JAR files specifying the classpath like so:
+The term Java means many things to many people:  a class library, a bytecode interpreter, a JIT compiler, a language specification, etc.  For the vast majority of users and developers, Java is a programming language and runtime environment that is architecture- and OS-agnostic.  The normal flow of code is .java (source file) .class (Java bytecode) .jar (a zip archive).  In the majority of cases, a user executes a Java program by specifying a class name containing a main method (just like C and C++).  Often, this is done by invoking the java binary with a list of JAR files specifying the classpath like so:
 
 java [-cp ]   [] 
 
 == Java Packaging ==
 The [http://www.jpackage.org JPackage Project]  has defined standard file system locations and conventions for use in Java packages.  Many distributions have inherited these conventions and in the vast majority of cases, Fedora follows them verbatim.  We include relevant sections of the JPackage guidelines here but caution that the canonical document will always reside upstream:  [http://www.jpackage.org/cgi-bin/viewvc.cgi/src/jpackage-utils/doc/jpackage-1.5-policy.xhtml?revision=HEAD&root=jpackage JPackage Guidelines]  .  Over time, we would like to remove any divergences in these documents, but where they are different, these Fedora guidelines will take precedence for Fedora packages.
 
+TODO: Find the proper jpackage link and fix it.
+
 === Package naming ===
 
-Packages '''MUST''' follow the standard Fedora [[Packaging/NamingGuidelines]]  .  Java API documentation '''MUST''' be placed into a sub-package called %{name}-javadoc.
+Packages '''MUST''' follow the standard Fedora [[Packaging/NamingGuidelines]].
 
-==== Release tags ====
-For now, refer to the [[Packaging/JPackagePolicy]]  for release tags.  That document should eventually be folded into this one.
+Java API documentation '''MUST''' be placed into a sub-package called %{name}-javadoc.
 
-=== Jar file naming ===
+==== Release tags ====
+Packages '''MUST''' follow the standard Fedora [[Packaging/NamingGuidelines#Package_Version | Package versioning guidelines]] .
 
-# If a package provides a single JAR file it must have the same name as the package itself.
+=== JAR file installation ===
 
-ex. jaf.jar
+The following applies to all JAR files except [[#JNI|JNI-using JAR files]], [[#GCJ|GCJ files]] and application-specific JAR files (ie. JAR files that can only reasonably be used as part of an application and therefore constitute application-private data).
 
-# If the project name and the commonly used JAR filename differ, a symbolic link with the usual name must also be provided.
+==== Split JAR files ====
 
-ex. Single JAR complete naming.  Project name is jaf, common name is activation.
+If a project offers the choice of packaging it as a single monolithic jar or several ones, the split packaging '''should''' be preferred.
 
-activation.jar ’ jaf.jar
+==== Filenames ====
 
-# If the package provides several JAR files, the filenames assigned by the build must be used.  Above symlinking rules apply.
+* If the package provides a '''single''' JAR and the filename provided by the build is %{name}.jar or %{name}-%{version}.jar then filename %{name}.jar '''MUST''' be used.
+* If the package provides a '''single''' JAR and the filename provided by the build is neither %{name}-%{version}.jar nor %{name}.jar then this file '''MUST''' be installed as %{name}.jar and a symbolic link with the usual name must be provided.
+* If the package provides more than '''one''' JAR file, the filenames assigned by the build '''MUST''' be used (without versions).
+* If the project usually provides alternative JAR file names by installing symbolic links then such symlinks '''MAY''' be installed in the same directory as the JAR files.
 
-ex.   
    ant-1.5.3.jar
-ant-optional-1.5.3.jar
    
+==== Installation directory ====
 
-# If the number of provided JAR files exceeds '''two''', you must place them into a sub-directory.
+* All JAR files '''MUST''' go into %{_javadir} or a Java-version specific directory %{_javadir}-* as appropriate[http://lists.fedoraproject.org/pipermail/packaging/2010-January/006792.html].
 
-# If a project offers the choice of packaging it as a single monolithic jar or several ones, the split packaging should be preferred.
+* If the number of provided JAR files exceeds '''two''', you '''MUST''' place them into a sub-directory named %{name}.
 
-=== Directory structure ===
-All JAR files '''MUST''' go into %{_javadir}.  Exceptions include [[JNI|  JNI-using JAR files]] , and application-specific JAR files (ie. JAR files that can only reasonably be used as part of an application and therefore constitute application-private data).
+=== Javadoc installation ===
 
-Java API documentation uses a system known as javadoc.  All javadocs '''MUST''' be installed into %{_javadocdir}.
+* Java API documentation uses a system known as javadoc.  All javadocs '''MUST''' be created and installed into a directory of %{_javadocdir}/%{name}. 
+* Directory or symlink %{_javadocdir}/%{name}-%{version} '''SHOULD NOT''' exist.
+* The javadoc subpackage '''MUST''' be declared noarch even if main package is architecture specific.
 
 === BuildRequires and Requires ===
 At a minimum, Java packages '''MUST''':
@@ -63,8 +65,9 @@ For historical reasons, when specifying versions 1.6.0 or greater, an epoch of 1
 === build-classpath ===
 build-classpath is a script that can be used to generate classpaths from generic names of JAR files.  Example:
 
-
    export CLASSPATH=$(build-classpath commons-logging commons-net)
+
    export CLASSPATH=$(build-classpath commons-logging commons-net xbean/xbean-reflect)
 
    
+{{admon/note|Additional information|You can use either package names (all jar files will be included) or jar filenames with path prefix to select only some jar files from whole package.}}
 
 === build-jar-repository ===
 build-jar-repository is similar to build-classpath but instead of producing a classpath entry, it creates symlinks in a given directory.  Example:
@@ -106,9 +109,11 @@ install javadoc:javadoc
 %install
 rm -rf $RPM_BUILD_ROOT
 install -d -m 755 $RPM_BUILD_ROOT%{_javadir}
-install -d -m 755 $RPM_BUILD_ROOT%{_datadir}/maven2/poms
-install -pm 644 pom.xml $RPM_BUILD_ROOT/%{_datadir}/maven2/poms/JPP-maven-archiver.pom
-%add_to_maven_depmap org.apache.maven maven-archiver %{version} JPP maven-archiver
+install -d -m 755 $RPM_BUILD_ROOT%{_mavenpomdir}
+install -pm 644 pom.xml $RPM_BUILD_ROOT/%{_mavenpomdir}/JPP-%{name}.pom
+# artifactId and jarName are usually %{name} for single module projects
+%add_to_maven_depmap [groupId] [artifactId] %{version} JPP[/optional_subDir] [jarName]
+
 ...
 %post
 %update_maven_depmap
@@ -118,38 +123,90 @@ install -pm 644 pom.xml $RPM_BUILD_ROOT/%{_datadir}/maven2/poms/JPP-maven-archiv
 ...
 
    
 
-=== Wrapper Scripts ===
-Applications wishing to provide a convenient method of execution '''SHOULD''' provide a wrapper script in %{_bindir}.  These can be as simple as this example:
+{{admon/note|Note:|Multimodule Maven projects should use javadoc:aggregate instead of javadoc:javadoc.}}
 
-
    #!/bin/bash
-. /usr/share/java-utils/java-functions
+{{admon/important|Important|Please read [[Java/JPPMavenReadme]] for details about mvn-jpp and %add_to_maven_depmap usage. }}
 
+=== Wrapper Scripts ===
+Applications wishing to provide a convenient method of execution '''SHOULD''' provide a wrapper script in %{_bindir}.  These can be as simple as this example:
+
+
    #!/bin/sh
+if [ -f /usr/share/java-utils/java-functions ] ;
+then 
+  . /usr/share/java-utils/java-functions
+else
+  echo "Can't find functions library, aborting"
+  exit 1
+fi
+
+# Configuration
 MAIN_CLASS=MyCoolApp
 
+# Set parameters
 set_classpath "mycoolapp"
 
+# Let's start
 run "$@"
 
    
 
+Specify your script as additional source
+
+
    +...
+Source1:          %{name}.jtidy.script
+...
+
    
+
+and install it into %{_bindir}
+
+
    +%install
+...
+# shell script
+mkdir -p %{buildroot}%{_bindir}
+cp -ap %{SOURCE1} %{buildroot}%{_bindir}/%{name}
+...
+
    
+
+Don't forget set file permissions correctly:
+
+
    +%files
+...
+%attr(755, root, root) %{_bindir}/*
+...
+
    
+
 === GCJ ===
+Building GCJ AOT bits is discouraged unless you have a very strong reason to include them in the packages.
+Even when AOT bits are built and included in packages it is recommended to not require java-1.5.0-gcj because this will force every single user to install it even if one wants to use another JVM.
+
 Please refer to [[Packaging/GCJGuidelines]]  for GCJ-specific guidelines.
 
 === -devel packages ===
 -devel packages don't really make sense for Java packages.  Header files do not exist for Java packages.
 
+
+=== Maven pom.xml files and depmaps ===
+If upstream project is shipping Maven pom.xml files, these '''MUST''' be installed with the corresponding %add_to_maven_depmaps calls.
+
+If upstream project does not ship pom.xml file [[http://repo1.maven.org/maven2/ official maven repo]] should be checked and if there are pom.xml files they '''SHOULD''' be installed.
+
+{{admon/tip|Tip|[[http://mvnrepository.com/ Mvnrepository site]] can be used to ease}}
+
 == Specfile Template ==
 === ant ===
 
     Name:           # see normal package guidelines
 Version:        # see normal package guidelines
 Release:        1%{?dist}
-Summary:        # see normal package guidelines (SNPG)
+Summary:        # see normal package guidelines
 
-Group:          # SNPG
-License:        # SNPG
-URL:            # SNPG
-Source0:        # SNPG
-BuildRoot:      %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
+Group:          # see normal package guidelines
+License:        # see normal package guidelines
+URL:            # see normal package guidelines
+Source0:        # see normal package guidelines
+BuildArch:      noarch
 
 BuildRequires:  jpackage-utils
 
@@ -165,48 +222,28 @@ Requires:       java
 
 %package javadoc
 Summary:        Javadocs for %{name}
-Group:          Development Documentation
-Requires:       %{name} = %{version}-%{release}
+Group:          Documentation
 Requires:       jpackage-utils
 
 %description javadoc
 This package contains the API documentation for %{name}.
 
-%package manual
-Summary:        Manual for %{name}
-Group:          Development Documentation
-Requires:       jpackage-utils
-Requires:       %{name} = %{version}-%{release}
-
-%description manual
-The manual for %{name}.
-
 %prep
 %setup -q
 
-
 find -name '*.class' -exec rm -f '{}' \;
 find -name '*.jar' -exec rm -f '{}' \;
 
-
-
 %build
 ant
 
 %install
-rm -rf $RPM_BUILD_ROOT
 
 mkdir -p $RPM_BUILD_ROOT%{_javadir}
-cp -p [build path to jar]   \
-$RPM_BUILD_ROOT%{_javadir}/%{name}-%{version}.jar
-
+cp -p [build path to jar] $RPM_BUILD_ROOT%{_javadir}/%{name}.jar
 
 mkdir -p $RPM_BUILD_ROOT%{_javadocdir}/%{name}
-cp -rp [javadoc directory]  \
-$RPM_BUILD_ROOT%{_javadocdir}/%{name}
-
-%clean
-rm -rf $RPM_BUILD_ROOT
+cp -rp [javadoc directory] $RPM_BUILD_ROOT%{_javadocdir}/%{name}
 
 %files
 %defattr(-,root,root,-)
@@ -217,9 +254,6 @@ rm -rf $RPM_BUILD_ROOT
 %defattr(-,root,root,-)
 %{_javadocdir}/%{name}
 
-%files manual
-%defattr(-,root,root,-)
-%doc [manual directory] /*
 
 %changelog
 
    
@@ -229,13 +263,14 @@ rm -rf $RPM_BUILD_ROOT
 Name:           # see normal package guidelines
 Version:        # see normal package guidelines
 Release:        1%{?dist}
-Summary:        # see normal package guidelines (SNPG)
+Summary:        # see normal package guidelines
 
-Group:          # SNPG
-License:        # SNPG
-URL:            # SNPG
-Source0:        # SNPG
-BuildRoot:      %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
+Group:          # see normal package guidelines
+License:        # see normal package guidelines
+URL:            # see normal package guidelines
+Source0:        # see normal package guidelines
+
+BuildArch:      noarch
 
 BuildRequires:  jpackage-utils
 
@@ -243,13 +278,13 @@ BuildRequires:  java-devel
 
 BuildRequires:  maven2
 
-BuildRequires:    maven2-plugin-compiler
-BuildRequires:    maven2-plugin-install
-BuildRequires:    maven2-plugin-jar
-BuildRequires:    maven2-plugin-javadoc
-BuildRequires:    maven2-plugin-release
-BuildRequires:    maven2-plugin-resources
-BuildRequires:    maven2-plugin-surefire
+BuildRequires:    maven-compiler-plugin
+BuildRequires:    maven-install-plugin
+BuildRequires:    maven-jar-plugin
+BuildRequires:    maven-javadoc-plugin
+BuildRequires:    maven-release-plugin
+BuildRequires:    maven-resources-plugin
+BuildRequires:    maven-surefire-plugin
 
 Requires:       jpackage-utils
 
@@ -262,22 +297,12 @@ Requires:       java
 
 %package javadoc
 Summary:        Javadocs for %{name}
-Group:          Development/Documentation
-Requires:       %{name}-%{version}-%{release}
+Group:          Documentation
 Requires:       jpackage-utils
 
 %description javadoc
 This package contains the API documentation for %{name}.
 
-%package manual
-Summary:        Manual for %{name}
-Group:          Development/Documentation
-Requires:       jpackage-utils
-Requires:       %{name}-%{version}-%{release}
-
-%description manual
-The manual for %{name}.
-
 %prep
 %setup -q
 
@@ -286,30 +311,23 @@ The manual for %{name}.
 export MAVEN_REPO_LOCAL=$(pwd)/.m2/repository
 mkdir -p $MAVEN_REPO_LOCAL
 
-mvn-jpp \
--Dmaven.repo.local=$MAVEN_REPO_LOCAL \
-install javadoc:javadoc
+mvn-jpp -Dmaven.repo.local=$MAVEN_REPO_LOCAL \
+        install javadoc:javadoc # or javadoc:aggregate
 
 %install
-rm -rf $RPM_BUILD_ROOT
 
 mkdir -p $RPM_BUILD_ROOT%{_javadir}
-cp -p [build path to jar]   \
-$RPM_BUILD_ROOT%{_javadir}/%{name}-%{version}.jar
-
+cp -p [build path to jar] $RPM_BUILD_ROOT%{_javadir}/%{name}.jar
 
 mkdir -p $RPM_BUILD_ROOT%{_javadocdir}/%{name}
-cp -rp [javadoc directory]  \
-$RPM_BUILD_ROOT%{_javadocdir}/%{name}
+cp -rp [javadoc directory] $RPM_BUILD_ROOT%{_javadocdir}/%{name}
 
-install -d -m 755 $RPM_BUILD_ROOT%{_datadir}/maven2/poms
+install -d -m 755 $RPM_BUILD_ROOT%{_mavenpomdir}
 install -pm 644 [path to pom]  \
-$RPM_BUILD_ROOT%{_datadir}/maven2/poms/JPP-%{name}.pom
+        $RPM_BUILD_ROOT%{_mavenpomdir}/JPP-%{name}.pom
 
-%add_to_maven_depmap org.apache.maven %{name} %{version} JPP %{name}
+%add_to_maven_depmap project_group_id project_artifact_id %{version} JPP %{name}
 
-%clean
-rm -rf $RPM_BUILD_ROOT
 
 %post
 %update_maven_depmap
@@ -319,8 +337,8 @@ rm -rf $RPM_BUILD_ROOT
 
 %files
 %defattr(-,root,root,-)
-%{_datadir}/maven2/poms
-%{_mavendepmapfragdir}
+%{_mavenpomdir}/*
+%{_mavendepmapfragdir}/*
 %{_javadir}/*
 %doc
 
@@ -328,38 +346,37 @@ rm -rf $RPM_BUILD_ROOT
 %defattr(-,root,root,-)
 %{_javadocdir}/%{name}
 
-%files manual
-%defattr(-,root,root,-)
-%doc [manual directory] /*
-
 %changelog
 
 
    
 
+{{admon/important|Depmap information|Last two arguments to %add_to_maven_depmap macro represent location of installed jar file. Using ".. jpp/foo bar" as last two arguments will mean that groupId/artifactId of package will resolve to jar file %{_javadir}/foo/bar.jar.}}
+
 For detailed instructions on the JPackage/Fedora maven, see the JPackage Maven rpm readme located [http://fedoraproject.org/wiki/Java/JPPMavenReadme here] .
 
 {{Anchor|JNI}}
+
 == Packaging JAR files that use JNI ==
 
 === Applicability ===
 
 Java programs that wish to make calls into native libraries do so via the Java Native Interface (JNI).  A Java package uses JNI if it contains a .so
 
-{{Template:Warning}} Note that GCJ packages contain .sos in %{_libdir}/gcj/%{name} but they are not JNI .sos.
+{{Template:Warning}} Note that GCJ packages contain .sos in %{_libdir}/gcj/%{name} but they are not JNI .sos.
 
 === Guideline ===
 
-JAR files that require JNI shared objects '''MUST''' be installed in %{_libdir}/%{name}.  The JNI shared objects themselves must also be installed in %{_libdir}/%{name}.  If the JNI-using code calls System.loadLibrary you'll have to patch it to use System.load, passing it the full path to the dynamic shared object.  If the package installs a wrapper script you'll need to manually add %{_libdir}/%{name}/ to CLASSPATH.  If you are depending on a JNI-using JAR file, you'll need to add it manually -- build-classpath will not find it.
+JAR files that require JNI shared objects '''MUST''' be installed in %{_libdir}/%{name}.  The JNI shared objects themselves must also be installed in %{_libdir}/%{name}.  If the JNI-using code calls System.loadLibrary you'll have to patch it to use System.load, passing it the full path to the dynamic shared object.  If the package installs a wrapper script you'll need to manually add %{_libdir}/%{name}/ to CLASSPATH.  If you are depending on a JNI-using JAR file, you'll need to add it manually -- build-classpath will not find it.
 
 === Rationale ===
 
-This is less convenient, but cleaner from a packaging point-of-view, than putting the JAR file in %{_javadir}, and putting the JNI shared object in  %{_libdir} to be loaded from the default library path.  First, JNI shared objects are dlopen'd, and dlopen'd shared objects should not be placed directly in %{_libdir} since they are application-private data, and not libraries meant to be linked to directly -- that is, not meant to be shared. Second, placing the JAR file in %{_javadir} causes the build-classpath script to always load it, even when running on a runtime environment of the wrong arch, meaning that the System.loadLibrary line would fail.
+This is less convenient, but cleaner from a packaging point-of-view, than putting the JAR file in %{_javadir}, and putting the JNI shared object in  %{_libdir} to be loaded from the default library path.  First, JNI shared objects are dlopen'd, and dlopen'd shared objects should not be placed directly in %{_libdir} since they are application-private data, and not libraries meant to be linked to directly -- that is, not meant to be shared. Second, placing the JAR file in %{_javadir} causes the build-classpath script to always load it, even when running on a runtime environment of the wrong arch, meaning that the System.loadLibrary line would fail.
 
 The plan is to eventually eliminate patching of the System.loadLibrary line and wrapper script by making jpackage-utils multilib aware.  This involves the following changes:  creating %{_libdir}/java and %{_libdir}/jni directories; giving JNI-containing packages the ability to require an architecture-specific runtime environment; adding support for specifying the required runtime architecture in a wrapper script; modifying jpackage-utils's runtime scripts to search %{_libdir}/java; modifying IcedTea to look for JNI shared objects in %{_libdir}/jni.
 
-The %{_jnidir} rpm macro defines the main JNI jar repository. Like %{_javadir} it is declined in -ext and -x.y.z variants. It follows exactly the same rules as the %{_javadir}-derived tree structure, except that it hosts JAR files that use JNI.
+The %{_jnidir} rpm macro defines the main JNI jar repository. Like %{_javadir} it is declined in -ext and -x.y.z variants. It follows exactly the same rules as the %{_javadir}-derived tree structure, except that it hosts JAR files that use JNI.
 
-%{_jnidir} usually expands into /usr/lib/java.
+%{_jnidir} usually expands into /usr/lib/java.
 
 == Things to avoid ==
 === Pre-built JAR files / Other bundled software ===
@@ -389,7 +406,6 @@ Use sed to remove class-path elements in MANIFES
 
     sed -i '/class-path/I d' META-INF/MANIFEST.MF
 
    
-'''Will this preserve the line ending as the [http://java.sun.com/docs/books/tutorial/deployment/jar/downman.html this page]  says it must?'''
 
 [[Category:Packaging guidelines]]
 [[Category:Java]]

From 82acbacbac1a062b3a87d73436d9d661f091838f Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Nov 16 2010 14:35:50 +0000
Subject: [PATCH 599/3559] update


---

diff --git a/Packaging:Perl.mw b/Packaging:Perl.mw
index fc73285..e7550a7 100644
--- a/Packaging:Perl.mw
+++ b/Packaging:Perl.mw
@@ -1,59 +1,75 @@
-= Perl Packaging =
-
 This document seeks to document the conventions and customs surrounding the proper packaging of perl modules in Fedora.  It does not intend to cover all situations, but to codify those practices which have served the Fedora perl community well.
 
+= Perl SIG =
+People around Perl, who are packaging, maintaining & reviewing packages. If you are interested in Perl, join [https://lists.fedoraproject.org/mailman/listinfo/Perl-devel mailing list], where are discussed latest issues.
 
+New Perl packages should set the [https://lists.fedoraproject.org/mailman/listinfo/Perl-devel Fedora perl SIG mailing list]  as a member of the initial-cc list for bugzilla.  This can be done by adding the user perl-sig to the initial CC list when creating the [[Package_SCM_admin_requests#New_Packages|New Package SCM Request]].
 
 {{Anchor|licensetag}}
+
 = License tag =
 
 Perl itself is dual licensed, under both the GPL and Artistic licenses.  Many perl modules follow this practice; when they do, the license tag should be filled out as "GPL+ or Artistic", not the other way around.
 
-Note also that under the new [[Licensing|  license tag guidelines]] , it's important to specify "GPL+" not just "GPL" for those packages "licensed under the same terms as perl itself."
+Note also that under the new [[Licensing|  license tag guidelines]], it's important to specify "GPL+" not just "GPL" for those packages "licensed under the same terms as perl itself."
 
 
     License:  GPL+ or Artistic
 
    
 
 {{Anchor|DirectoryOwnership}}
+
 = Directory Ownership =
-As specified in the [[Guidelines#FileAndDirectoryOwnership|  general Packaging Guidelines]] , perl packages are permitted to share ownership of directories.
 
-As an example, assume that perl-A-B depends on perl-A and installs files into /usr/lib/perl5/vendor_perl/5.10.0/i386-linux-thread-multi/A/B. The base Perl package guarantees that it will own /usr/lib/perl5/vendor_perl/5.10.0/i386-linux-thread-multi for as long as it remains compatible with version 5.10.0, but a future upgrade of the perl-A package may install into (and thus own) /usr/lib/perl5/vendor_perl/5.11.0/i386-linux-thread-multi/A. So the perl-A-B package needs to own /usr/lib/perl5/vendor_perl/5.10.0/i386-linux-thread-multi/A as well as /usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi/A/B in order to maintain proper ownership.
+As specified in the [[Packaging:Guidelines#File_and_Directory_Ownership | general Packaging Guidelines]], perl packages are expected to share ownership of certain directories.
+
+In general, a noarch Perl package must own:
+
+
    +# For noarch packages: vendorlib
+%{perl_vendorlib}/*
+
    
+
+...and a arch-specific Perl package must own:
+
+
    +# For arch-specific packages: vendorarch
+%{perl_vendorarch}/*
+%exclude %dir %{perl_vendorarch}/auto/
+
    
 
 {{Anchor|requiresandprovides}}
-= Perl Requires and Provides =
 
-Perl packages use the virtual perl(Foo) naming to indicate a given perl module.  Packages should use this methodology, and not require the package name directly.  E.g. a package requires the perl module Readonly, a package should not explicitly require the package perl-Readonly, but rather perl(Readonly), which the perl-Readonly package provides.
+= Perl Requires and Provides =
 
-{{Template:Warning}} NOTE: Explicitly requiring perl-devel, even when wrapped in a conditional construct, is strongly discouraged, and is generally considered a blocker at review and a packaging bug.  Instead, see the next section on requiring core modules -- making sure that these core modules are BR'ed when used will pull in the correct development perl packages.
+Perl packages use the virtual perl(Foo) naming to indicate a given perl module.  Packages should use this methodology, and not require the package name directly.  For example, a package requiring the perl module Readonly should not explicitly require perl-Readonly, but rather perl(Readonly), which the perl-Readonly package provides.
 
+It is recommended to buildrequire core modules '''explicitly''', because they can move between sub-packages or disappear from core perl.
 
-{{Anchor|corebrs}}
-== Core modules as buildrequires ==
+{{admon/caution|Do not explicitly buildrequire "perl-devel"|Explicitly requiring perl-devel, even when wrapped in a conditional construct, is strongly discouraged, and is generally considered a blocker at review and a packaging bug.  Instead, see the next section on requiring core modules -- making sure that these core modules are BR'ed when used will pull in the correct development perl packages.}}
 
-Historically, buildrequiring a core module (that is, one provided by the perl package itself) has been frowned upon.  However, with the perl/perl-devel split, a number of core modules are now packages seperately from the perl package, and now need to be explicitly buildrequired:
 
-* perl(CPAN)
-* perl(ExtUtils::Embed)
-* perl(ExtUtils::MakeMaker)
-* perl(Test::Harness)
-* perl(Test::More)
-* perl(Test::Simple)
+{{Anchor|corebrs}}
 
-{{Anchor|module_compat}}
 == Versioned MODULE_COMPAT_ Requires ==
+
 All perl modules must include the versioned MODULE_COMPAT Requires:
 
 
     Requires:  perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo $version))
 
    
 
-This is to ensure that perl packages have a dependency on a perl which provides the appropriate versioned directory structure (otherwise, the modules won't be found).
+This is to ensure that perl packages have a dependency on the particular version of Perl it was built against, or on a newer version of Perl that provides backward compatibility with it.
+
+For example, perl-5.8.8 provided not only perl(:MODULE_COMPAT_5.8.8), but also perl(:MODULE_COMPAT_5.8.7), etc., because backward compatibility was guaranteed for Fedora Perl 5.8.x.
+
+On the other hand, perl-5.10.1 implements some incompatible changes to module tree layout and libperl.so build options.  Once the compatibility aids are removed, perl-5.10.1 and above will no longer provide perl(:MODULE_COMPAT_5.10.0).
+
+In the future, it is possible that perl-5.12.2 will provide not only perl(:MODULE_COMPAT_5.12.[012]), but also perl(:MODULE_COMPAT_5.10.[123]), if the backward compatibility with all versions >= 5.10.1 is maintained.
 
 {{Anchor|libperl}}
 === Packages that link to libperl ===
-Some packages link to libperl.so, usually to provide embedded perl functionality. All of these packages must also use the versioned MODULE_COMPAT Requires.
+Some packages link to libperl.so, usually to provide embedded perl functionality. All of these packages must also use the versioned MODULE_COMPAT Requires, because the automaticaly generated dependency on libperl.so does not include any interface version number.
 
 {{Anchor|depfiltering}}
 
@@ -119,8 +135,9 @@ There are a couple caveats here:
 * Optional tests do not need to be enabled if they will cause circular build deps
 * Tests which require network or display access should be disabled for the buildsystem, but with a method provided for local builds
 * Tests which do not test package functionality should still be invoked, but their exclusion not be considered a blocker (e.g. Test::Pod::Coverage, Test::Kwalitee and the like)
+* Author, "release candidate", or smoke tests do not need to be enabled e.g. tests using Perl::Critic
 
-Additionally, for "meta" packages that provide a common interface to a number of similar modules, it is not necessary to package all of the modules that the package supports so long as at least one module exists to allow the meta package to provide functionality.  For instance, the package perl-JSON-Any (JSON::Any) provides a common interface to JSON, JSON::XS, JSON::PC, JSON::Syck and JSON::DWIM; JSON::PC and JSON::DWIM are not currently in Fedora and do not need to be packaged.
+Additionally, for "meta" packages that provide a common interface to a number of similar modules, it is not necessary to package all of the modules that the package supports so long as at least one module exists to allow the meta package to provide functionality.  For instance, the package perl-JSON-Any (JSON::Any) provides a common interface to JSON, JSON::XS, JSON::PC, JSON::Syck and JSON::DWIM; JSON::PC and JSON::DWIM are not currently in Fedora and do not need to be packaged as, e.g. JSON::XS enables JSON::Any.
 
 == Conditionally enabling/disabling tests ==
 
@@ -149,15 +166,25 @@ See also [[PackagingTips/Perl#Makefile.PL_vs_Build.PL]] .
 
 It is not uncommon for binary module packages to include .h files, see e.g. perl-DBI, perl-Glib, perl-Gtk2.  For a variety of reasons these should not be split off into a -devel package.
 
-= Set inital-cc to 'perl-sig' =
 
-It's common practice to set the [https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list Fedora perl SIG mailing list]  as a member of the initial-cc list for bugzilla.  This can be done by adding the user perl-sig to the initial CC list.
 
 = cpanspec =
 
 cpanspec is an excellent little tool to assist in creating Fedora-compliant packages from CPAN-based modules.  Its use as a starting point is recommended (but certainly not mandated).
 
-For more information, see: [[Perl/cpanspec]] 
+For more information, see: [[Perl/cpanspec]]
+
+= Updates of packages =
+Summary of tools used for updates and helpful comments can be found here [[Perl/updates]].
+
+= Useful tips =
+Some modules try to pull in modules from cpan. Instead of patching makefile, you can easily add
+PERL5_CPANPLUS_IS_RUNNING=1 to avoid CPAN entirely.
+
+
    +%build
+PERL5_CPANPLUS_IS_RUNNING=1 %{__perl} Makefile.PL INSTALLDIRS=vendor
+make %{?_smp_mflags}
+
    
 
 [[Category:Perl]]
-[[Category:Packaging guidelines]]

From 700c36b604179bd1b13521daa4f9be0611e91cb9 Mon Sep 17 00:00:00 2001
From: Toshio 
Date: Nov 16 2010 14:43:19 +0000
Subject: [PATCH 600/3559] heading format and category addition


---

diff --git a/Packaging:Perl.mw b/Packaging:Perl.mw
index e7550a7..c9d7d37 100644
--- a/Packaging:Perl.mw
+++ b/Packaging:Perl.mw
@@ -1,13 +1,13 @@
 This document seeks to document the conventions and customs surrounding the proper packaging of perl modules in Fedora.  It does not intend to cover all situations, but to codify those practices which have served the Fedora perl community well.
 
-= Perl SIG =
+== Perl SIG ==
 People around Perl, who are packaging, maintaining & reviewing packages. If you are interested in Perl, join [https://lists.fedoraproject.org/mailman/listinfo/Perl-devel mailing list], where are discussed latest issues.
 
 New Perl packages should set the [https://lists.fedoraproject.org/mailman/listinfo/Perl-devel Fedora perl SIG mailing list]  as a member of the initial-cc list for bugzilla.  This can be done by adding the user perl-sig to the initial CC list when creating the [[Package_SCM_admin_requests#New_Packages|New Package SCM Request]].
 
 {{Anchor|licensetag}}
 
-= License tag =
+== License tag ==
 
 Perl itself is dual licensed, under both the GPL and Artistic licenses.  Many perl modules follow this practice; when they do, the license tag should be filled out as "GPL+ or Artistic", not the other way around.
 
@@ -19,7 +19,7 @@ License:  GPL+ or Artistic
 
 {{Anchor|DirectoryOwnership}}
 
-= Directory Ownership =
+== Directory Ownership ==
 
 As specified in the [[Packaging:Guidelines#File_and_Directory_Ownership | general Packaging Guidelines]], perl packages are expected to share ownership of certain directories.
 
@@ -40,7 +40,7 @@ In general, a noarch Perl package must own:
 
 {{Anchor|requiresandprovides}}
 
-= Perl Requires and Provides =
+== Perl Requires and Provides ==
 
 Perl packages use the virtual perl(Foo) naming to indicate a given perl module.  Packages should use this methodology, and not require the package name directly.  For example, a package requiring the perl module Readonly should not explicitly require perl-Readonly, but rather perl(Readonly), which the perl-Readonly package provides.
 
@@ -51,7 +51,7 @@ It is recommended to buildrequire core modules '''explicitly''', because they ca
 
 {{Anchor|corebrs}}
 
-== Versioned MODULE_COMPAT_ Requires ==
+=== Versioned MODULE_COMPAT_ Requires ===
 
 All perl modules must include the versioned MODULE_COMPAT Requires:
 
@@ -68,19 +68,19 @@ On the other hand, perl-5.10.1 implements some incompatible changes to module tr
 In the future, it is possible that perl-5.12.2 will provide not only perl(:MODULE_COMPAT_5.12.[012]), but also perl(:MODULE_COMPAT_5.10.[123]), if the backward compatibility with all versions >= 5.10.1 is maintained.
 
 {{Anchor|libperl}}
-=== Packages that link to libperl ===
+==== Packages that link to libperl ====
 Some packages link to libperl.so, usually to provide embedded perl functionality. All of these packages must also use the versioned MODULE_COMPAT Requires, because the automaticaly generated dependency on libperl.so does not include any interface version number.
 
 {{Anchor|depfiltering}}
 
-== Filtering Requires: and Provides ==
+=== Filtering Requires: and Provides ===
 RPM's dependency generator can often throw in additional dependencies and will often think packages provide functionality contrary to reality. To fix this, the dependency generator needs to be overriden so that the additional dependencies can be filtered out. Please see [[https://fedoraproject.org/wiki/Packaging:AutoProvidesAndRequiresFiltering#Perl]] for information.
 
 {{admon/note| Updating deprecated methods|In the past, several other methods were given for doing this filtering. Those should be considered deprecated and packages should be updated to use the macros on [[https://fedoraproject.org/wiki/Packaging:AutoProvidesAndRequiresFiltering#Perl]] as time and the natural rebuild cycle permits.}}
 
 {{Anchor|manualdeps}}
 
-== Manual Requires and Provides ==
+=== Manual Requires and Provides ===
 
 Under some circumstances, RPM's automatic dependency generator can miss dependencies that should be added.
 This is usually as a result of using language constructs that the dependency script wasn't expecting.
@@ -112,7 +112,7 @@ package DBD::Pg;
    
 So it's wise to examine the Provides: of your packages to check that they are sane and complete.
 If something is missing, it can be fixed either by using manual Provides: entries, or by patching the source to use a format that RPM can parse correctly.
 
-= URL tag =
+== URL tag ==
 
 For CPAN-based packages the URL tag should use a non-versioned search.cpan.org URL.  E.g., if one were packaging the module Net::XMPP, the URL would be:
 
@@ -120,7 +120,7 @@ For CPAN-based packages the URL tag should use a non-versioned search.cpan.org U
 URL:            http://search.cpan.org/dist/Net-XMPP/
    -= Testing and Test Suites = +== Testing and Test Suites == Perl packages typically have a large, healthy test suite. It is policy to run as much of the test suite as possible, subject to the technical limitations of the buildsystem. This means, at the least: @@ -128,7 +128,7 @@ Perl packages typically have a large, healthy test suite. It is policy to run a * Any "optional" tests should be enabled * Any modules needed for the tests but not yet in Fedora that could be included in Fedora should also be submitted for review -== When to *not* test == +=== When to *not* test === There are a couple caveats here: @@ -139,7 +139,7 @@ There are a couple caveats here: Additionally, for "meta" packages that provide a common interface to a number of similar modules, it is not necessary to package all of the modules that the package supports so long as at least one module exists to allow the meta package to provide functionality. For instance, the package perl-JSON-Any (JSON::Any) provides a common interface to JSON, JSON::XS, JSON::PC, JSON::Syck and JSON::DWIM; JSON::PC and JSON::DWIM are not currently in Fedora and do not need to be packaged as, e.g. JSON::XS enables JSON::Any. -== Conditionally enabling/disabling tests == +== Conditionally enabling/=disabling tests === One common way to disable a test for mock but enable it locally is to use a _with_foo macro test. e.g.: @@ -151,7 +151,7 @@ One common way to disable a test for mock but enable it locally is to use a rpmbuild or %_with_network_tests is defined somewhere, e.g. in a user's $HOME/.rpmmacros. This approach preserves the test suite for local builds while working within the technical limitations of the buildsystem. -= Makefile.PL vs Build.PL = +== Makefile.PL vs Build.PL == Perl modules typically utilize one of two different buildsystems: @@ -162,22 +162,22 @@ The two different styles are easily recognizable: ExtUtils::Makeperl-DBI    , perl-Glib, perl-Gtk2. For a variety of reasons these should not be split off into a -devel package. -= cpanspec = +== cpanspec == cpanspec is an excellent little tool to assist in creating Fedora-compliant packages from CPAN-based modules. Its use as a starting point is recommended (but certainly not mandated). For more information, see: [[Perl/cpanspec]] -= Updates of packages = +== Updates of packages == Summary of tools used for updates and helpful comments can be found here [[Perl/updates]]. -= Useful tips = +== Useful tips == Some modules try to pull in modules from cpan. Instead of patching makefile, you can easily add PERL5_CPANPLUS_IS_RUNNING=1 to avoid CPAN entirely. @@ -188,3 +188,4 @@ make %{?_smp_mflags} [[Category:Perl]] +[[Category:Packaging guidelines]] From f09e81277a2bb8ee8f944a8675c0583b61c101a6 Mon Sep 17 00:00:00 2001 From: Tibbs Date: Nov 16 2010 21:51:23 +0000 Subject: [PATCH 601/3559] Add subsection on %pretrans. --- diff --git a/Packaging:Guidelines.mw b/Packaging:Guidelines.mw index 31d0543..0e4f28f 100644 --- a/Packaging:Guidelines.mw +++ b/Packaging:Guidelines.mw @@ -842,6 +842,11 @@ Build scripts of packages (%prep, %build, %install, %check and %clean) may only Further clarification: That should hold true irrespective of the builder's uid. +=== The %pretrans scriptlet === + +Note that the %pretrans scriptlet will, in the particular case of system installation, run before anything at all has been installed. This implies that it cannot have any dependencies at all. For this reason, %pretrans is best avoided, but if you must use it, the script must be written in Lua. See http://www.rpm.org/wiki/PackagerDocs/RpmLua for more information. + + {{Anchor|ConditionalDependencies}} == Conditional dependencies == If the spec file contains conditional dependencies selected based on presence of optional --with(out) foo arguments to rpmbuild, build the source RPM to be submitted with the default options, ie. so that none of these arguments are present in the rpmbuild command line. The reason is that those requirements get "serialized" into the resulting source RPM, ie. the conditionals no longer apply. From bd6a57693d4b004c9f7e01c40382f8bca154ce82 Mon Sep 17 00:00:00 2001 From: Tibbs Date: Nov 16 2010 22:13:25 +0000 Subject: [PATCH 602/3559] Add note about running rpmlint on installed packages. --- diff --git a/Packaging:Guidelines.mw b/Packaging:Guidelines.mw index 0e4f28f..18050f1 100644 --- a/Packaging:Guidelines.mw +++ b/Packaging:Guidelines.mw @@ -122,7 +122,7 @@ Fedora's rpm includes a macro for libexecdir, %{_libexecdir}. Packa {{Anchor|rpmlint}} == Use rpmlint == -Run rpmlint on binary and source rpms to examine them for common errors, and fix them (unless rpmlint is wrong, which can happen, too). If you find rpmlint's output cryptic, the -i switch to it can be used to get more verbose descriptions of most errors and warnings. The rpmlint package is available in the Fedora repositories. +Run rpmlint on binary and source rpms to examine them for common errors, and fix them (unless rpmlint is wrong, which can happen, too). If you find rpmlint's output cryptic, the -i switch to it can be used to get more verbose descriptions of most errors and warnings. Note that rpmlint will perform additional checks if given the name of an installed package. For example, yum install foo-1.0-1.f20.x86_64.rpm; rpmlint foo will perform a set of tests on the foo package that rpmlint foo-1.0-1.f20.x86_64.rpm cannot. The rpmlint package is available in the Fedora repositories. === Rpmlint Errors === From 12bdea4bf908b4b5696ce9f21404fead87cadcbb Mon Sep 17 00:00:00 2001 From: Spot Date: Nov 17 2010 19:14:46 +0000 Subject: [PATCH 603/3559] *Empty MediaWiki Message* --- diff --git a/Packaging:RPM_Source_Dir.mw b/Packaging:RPM_Source_Dir.mw index 25eedf6..940aaab 100644 --- a/Packaging:RPM_Source_Dir.mw +++ b/Packaging:RPM_Source_Dir.mw @@ -30,4 +30,17 @@ sed -e "s/@PHP_APIVER@/%{apiver}/;s/@PHP_ZENDVER@/%{zendver}/;s/@PHP_PDOVER@/%{p < %{SOURCE3} > macros.php +=== Exceptions === +When there is an available list of supplementary source files, it is permissible to use this list in conjunction with %{sourcedir} to simplify operations on those supplementary source files. + +An example of this from the kde-l10n package: + +
    +for i in $(cat %{SOURCE1000}) ; do
+  echo $i | grep -v '^#' && \
+  bzip2 -dc %{_sourcedir}/%{name}-$i-%{version}.tar.bz2 | tar -xf -
+done
+
    + +where Source1000: subdirs-kde-l10n is a list provided by upstream of all the languages supported, and there are ~50 SourceN: tags, which can vary from version from version, but match the languages listed in Source1000, for the tarballs provided by upstream. [[Category:Packaging guidelines]] From d010274ee4a2b281b99329e550830278d436e05d Mon Sep 17 00:00:00 2001 From: Toshio Date: Nov 17 2010 19:29:09 +0000 Subject: [PATCH 604/3559] Add gdk-pixbuf loaders --- diff --git a/Packaging:Scriptlets.mw b/Packaging:Scriptlets.mw index 3bec004..152667b 100644 --- a/Packaging:Scriptlets.mw +++ b/Packaging:Scriptlets.mw @@ -170,6 +170,26 @@ repoquery --whatprovides "/etc/gconf/schemas/*" |sort |uniq |wc -l === EPEL Notes === EPEL does not have macros.gconf2, so please follow the instructions found here: [[Packaging:EPEL#GConf]] +== gdk-pixbuf loaders == + +gdk-pixbuf is a library that is part of the gdk-pixbuf2 package. It is for loading images in various formats in GNOME. gdk-pixbuf can be extended by implementing loaders for image formats in loadable modules. These loadable modules have to be installed in %{_libdir}/gdk-pixbuf-2.0/2.10.0/loaders. To avoid opening all modules in that directory +unnecessarily, gdk-pixbuf maintains a cache with information about the available modules in the text file %{_libdir}/gdk-pixbuf-2.0/2.10.0/loaders.cache. This cache file needs to be updated when the set of installed modules changes, by calling the gdk-pixbuf-query-loaders binary. Multilib considerations force us to install the binary in -32 and -64 variants. + +The scriptlets to maintain the cache file are: +
    +%postun
+gdk-pixbuf-query-loaders-%{__isa_bits} --update-cache &> /dev/null || :
+
+%post
+if [ $1 -eq 1 ] ; then
+    # For upgrades, the cache will be regenerated by the new package's %postun
+    gdk-pixbuf-query-loaders-%{__isa_bits} --update-cache &> /dev/null || :
+fi
+
    + +Note the use of %{__isa_bits}, which is an rpm macro that expands to either 32 or 64, +depending on the architecture of the package. + {{Anchor|info}} == Texinfo == From 34e34076467020a30c76e0403759047355237e54 Mon Sep 17 00:00:00 2001 From: Toshio Date: Nov 17 2010 19:34:29 +0000 Subject: [PATCH 605/3559] gsettings, gtk3 modules, and gio-modules scriptlets --- diff --git a/Packaging:Scriptlets.mw b/Packaging:Scriptlets.mw index 152667b..4ee016d 100644 --- a/Packaging:Scriptlets.mw +++ b/Packaging:Scriptlets.mw @@ -170,6 +170,23 @@ repoquery --whatprovides "/etc/gconf/schemas/*" |sort |uniq |wc -l === EPEL Notes === EPEL does not have macros.gconf2, so please follow the instructions found here: [[Packaging:EPEL#GConf]] +== GSettings Schema == + +GSettings is the configuration system used by the GNOME 3 desktop. It replaces the older GConf +system, which was used in GNOME 2. GSettings has pluggable backends, the 'native' one for GNOME is using DConf to store settings. The GSettings API and utilities are part of the glib2 package. + +Programs which use GSettings install schema information including default values in the directory %{_datadir}/glib-2.0/schemas. Schema files are xml files with the extension .gschema.xml. At runtime, GSettings uses the schemas in a compiled binary (but arch-neutral) form, which is created by running the glib-compile-schemas utility. glib-compile-schemas must be run whenever the set of installed schemas changes. + +
    +%postun
+glib-compile-schemas %{_datadir}/glib-2.0/schemas &> /dev/null || :
+
+%post
+if [ $1 -eq 1 ] ; then
+    glib-compile-schemas %{_datadir}/glib-2.0/schemas &> /dev/null || :
+fi
+
    + == gdk-pixbuf loaders == gdk-pixbuf is a library that is part of the gdk-pixbuf2 package. It is for loading images in various formats in GNOME. gdk-pixbuf can be extended by implementing loaders for image formats in loadable modules. These loadable modules have to be installed in %{_libdir}/gdk-pixbuf-2.0/2.10.0/loaders. To avoid opening all modules in that directory @@ -190,6 +207,44 @@ fi Note the use of %{__isa_bits}, which is an rpm macro that expands to either 32 or 64, depending on the architecture of the package. +== GTK+ modules == + +The GTK+ toolkit (in the gtk3 package) can be extended by loadable modules which can provide theme engines, input methods, print backends or other functionality. These modules have to be installed in subdirectories of %{_libdir}/gtk-3.0 or %{_libdir}/gtk-3.0/3.0.0. For the input methods, GTK+ maintains a cache in the text file %{_libdir}/gtk-3.0/3.0.0/immodules.cache. This cache file needs to be updated when the set of installed input methods changes, by calling the gtk-query-immodules-3.0 binary. Multilib considerations force us to install the binary in -32 and -64 variants. + +The scriptlets to maintain the cache file are: +
    +%postun
+gtk-query-immodules-3.0-%{__isa_bits} --update-cache &> /dev/null || :
+
+%post
+if [ $1 -eq 1 ] ; then
+    # For upgrades, the cache will be regenerated by the new package's %postun
+    gio-query-immodules-3.0-%{__isa_bits} --update-cache &> /dev/null || :
+fi
+
    + +The 3.0 in the binary name is there because gtk2 has its own utility for the same purpose, called gtk-query-immodules-2.0. Note the use of %{__isa_bits}, which is an rpm macro that expands to either 32 or 64, depending on the architecture of the package. + +== GIO modules == +GIO is a library that is part of the glib2 package. It is a low-level part of the GNOME stack. GIO can be extended by implementing [http://library.gnome.org/devel/gio/2.26/extending-gio.html extension points] in loadable modules. These loadable modules have to be installed in %{_libdir}/gio/modules. To avoid opening all modules in that directory +unnecessarily, GIO maintains a cache with information about the available modules in the +text file giomodule.cache in the same directory. This cache file needs to be updated when the set of installed modules changes, by calling the gio-querymodules binary. Multilib considerations force us to install the binary in -32 and -64 variants. + +The scriptlets to maintain the cache file are: +
    +%postun
+gio-querymodules-%{__isa_bits} %{_libdir}/gio/modules &> /dev/null || :
+
+%post
+if [ $1 -eq 1 ] ; then
+    # For upgrades, the cache will be regenerated by the new package's %postun
+    gio-querymodules-%{__isa_bits} %{_libdir}/gio/modules || :
+fi
+
    + +Note the use of %{__isa_bits}, which is an rpm macro that expands to either 32 or 64, +depending on the architecture of the package. + {{Anchor|info}} == Texinfo == From a47fcc2e07d7e704e364a77c3e1615e18d0eb2c2 Mon Sep 17 00:00:00 2001 From: Toshio Date: Nov 17 2010 19:46:35 +0000 Subject: [PATCH 606/3559] Add category --- diff --git a/Packaging:Scriptlets.mw b/Packaging:Scriptlets.mw index 4ee016d..971b847 100644 --- a/Packaging:Scriptlets.mw +++ b/Packaging:Scriptlets.mw @@ -319,3 +319,4 @@ fi %posttrans gtk-update-icon-cache %{_datadir}/icons/hicolor &>/dev/null || : +[[Category:Packaging guidelines]] From 4de6fc3f8c313f9379072a64c3eb7351ba25e24b Mon Sep 17 00:00:00 2001 From: Toshio Date: Nov 19 2010 16:14:08 +0000 Subject: [PATCH 607/3559] fix typo in gtk3 scriptlet --- diff --git a/Packaging:Scriptlets.mw b/Packaging:Scriptlets.mw index 971b847..4bb6894 100644 --- a/Packaging:Scriptlets.mw +++ b/Packaging:Scriptlets.mw @@ -219,7 +219,7 @@ gtk-query-immodules-3.0-%{__isa_bits} --update-cache &> /dev/null || : %post if [ $1 -eq 1 ] ; then # For upgrades, the cache will be regenerated by the new package's %postun - gio-query-immodules-3.0-%{__isa_bits} --update-cache &> /dev/null || : + gtk-query-immodules-3.0-%{__isa_bits} --update-cache &> /dev/null || : fi From 1df9a906827bb53654c7f0527180ece1ef603b85 Mon Sep 17 00:00:00 2001 From: Tibbs Date: Nov 23 2010 02:31:42 +0000 Subject: [PATCH 608/3559] Reformat 
     section to repair damage from old wiki conversion.


---

diff --git a/Packaging:UsersAndGroups.mw b/Packaging:UsersAndGroups.mw
index 459da00..f5c0509 100644
--- a/Packaging:UsersAndGroups.mw
+++ b/Packaging:UsersAndGroups.mw
@@ -12,8 +12,8 @@ Requires(pre): shadow-utils
 %pre
 getent group GROUPNAME >/dev/null || groupadd -r GROUPNAME
 getent passwd USERNAME >/dev/null || \
-useradd -r -g GROUPNAME -d HOMEDIR -s /sbin/nologin \
--c "Useful comment about the purpose of this account" USERNAME
+    useradd -r -g GROUPNAME -d HOMEDIR -s /sbin/nologin \
+    -c "Useful comment about the purpose of this account" USERNAME
 exit 0
    From d8a97ed413b5a7c1fbea03a1e8ef293c3a8faafa Mon Sep 17 00:00:00 2001 From: Spot Date: Nov 24 2010 22:14:44 +0000 Subject: [PATCH 609/3559] Created page with '= NOTE = Work in progress, not even close to useful or complete. == Fedora systemd Services == This document describes the guidelines for systemd services, for use and inclusion...' --- diff --git a/Packaging:Systemd.mw b/Packaging:Systemd.mw new file mode 100644 index 0000000..44f1182 --- /dev/null +++ b/Packaging:Systemd.mw @@ -0,0 +1,593 @@ += NOTE = +Work in progress, not even close to useful or complete. + +== Fedora systemd Services == +This document describes the guidelines for systemd services, for use and inclusion in Fedora packages. + +== Unit Files == +The systemd equivalent for an SysV initscript is called a Unit file. + +=== Naming === +Unit files have a naming scheme of foobar.service. When considering what basename to use, keep the following advice in mind: + +* Unit files should be named after the software implementation that they support, as opposed to the generic type of software. So, a good name would be "apache-httpd.service", and a bad name would be "httpd.service", as there are multiple httpd implementations, but only one Apache httpd. +* Unit files should have the same base name as the SysV initscript, so if the SysV initscript is /etc/rc.d/init.d/foobar, then the unit file must be /lib/systemd/system/foobar.service. This will enable automatic fallback in systemd: if a native unit file doesn't exist by a specific name it will fall back to the SysV file of the same service. If the SysV initscript was named poorly (e.g. httpd), then you should provide a compatibility symlink for the old SysV basename (apache-httpd.service -> httpd.service). + +It is our intention to unify service names of well-known software across distributions, so that we can eventually ship the service files in the upstream packages. Hence it is a good idea to discuss service names with maintainers of the same packages in other distributions and agree on a common name. + +=== Format === +Every .service file must begin with a [Unit] section: + +
    +[Unit]
+Description=A brief human readable string describing the service (not the service file!)
+After=syslog.target
+
    + +The Description= line must not exceed 80 characters, and must describe the service, and not the service file. For example, "Apache Web Server" is a good description, but "Starts and Stops the Apache Web Server" is a bad one. + +The After= line is only necessary if the service can log to syslog (most can, so if in doubt, include it). + +Next, the .service file must have a [Service] section: + +
    +[Service]
+Type=...
+BusName=...
+ExecStart=...
+ExecReload=...
+
    + +The Type= setting is very important. For D-Bus services this should be "dbus", for traditional services "forking" is usually a good idea, for services not offering any interfaces to other services "simple" is best. For "one-short" scripts "oneshot" is ideal, often combined with RemainAfterExit=. See http://0pointer.de/public/systemd-man/systemd.service.html for further discussion on the topic. Since "simple" is the default type, .service files which would normally set Type=simple may simply omit the Type line altogether. + +BusName= should be set for all services connecting to D-Bus. (i.e. it is a must for those where Type=dbus, but might make sense otherwise, too) Omit this option if your service does not take a name on the bus. + +ExecStart= is necessary for all services. This line defines the string that you would run to start the service daemon, along with any necessary options. + +ExecReload= should be specified for all services supporting reload. It is highly recommended to add code here that synchronously reloads the configuration file here (i.e. /bin/kill -HUP $MAINPID is usually a poor choice, due to its asynchronous nature). Omit this option if your service does not support reloading. + +Finally, the .service file must have an [Install] section: + +
    +[Install]
+WantedBy=...
+
    + +The recommended parameters for WantedBy are either multi-user.target (for most system services) or graphical.target (for services related to the UI). + +For more information regarding these options see http://0pointer.de/public/systemd-man/systemd.unit.html and http://0pointer.de/public/systemd-man/systemd.service.html + +Strictly speaking ExecStart= (in the [Service] section) is the only option really necessary for a .service file. However, in Fedora you must add the other options mentioned here (as applicable). + +=== Support for /etc/sysconfig files === +If your service supports /etc/sysconfig files, then you must use + +Use EnvironmentFile= to support /etc/sysconfig files. You may then refer to variables set in sysconfig files with ${FOOBAR} and $FOOBAR, in the ExecStart= lines (and related lines). (${FOOBAR} expands the variable into one word, $FOOBAR splits up the variable value at whitespace into multiple words) /etc/rc.d/init.d. A rpm macro exists for this directory, %_initddir. Note: The %_initddir macro does not exist on Fedora 9 or older releases, or on RHEL 5 or older. For those releases, you should use the deprecated %_initrddir macro. + + + +=== Filesystem locations == +Packages with Systemd unit files '''must''' put them into %{_unitdir}. %{_unitdir} evaluates to /lib/systemd/system/ on all Fedora systems. Unit files are architecture independent (hence, not %{_lib}) and needed early in the boot process. + + + +Use EnvironmentFile= to support /etc/sysconfig files. You may then refer to variables set in sysconfig files with ${FOOBAR} and $FOOBAR, in the ExecStart= lines (and related lines). (${FOOBAR} expands the variable into one word, $FOOBAR splits up the variable value at whitespace into multiple words) /etc/rc.d/init.d. A rpm macro exists for this directory, %_initddir. Note: The %_initddir macro does not exist on Fedora 9 or older releases, or on RHEL 5 or older. For those releases, you should use the deprecated %_initrddir macro. + + +== Initscript packaging == +Initscripts must not be marked as %config files. + +Although init files live in /etc, they are scripts to be executed, not configured. Any configuration should be made available through /etc/sysconfig/ rather than in the init script itself. A valid exception to this rule would be existing packages where configuration is still done via the init file. In this case, the init file could be marked as %config following the rules from the [[Packaging/Guidelines#Config| Configuration files]] section to preserve a users configuration upon upgrade, hopefully so that the user can migrate said configuration to a new /etc/sysconfig/ config file. + +Init scripts should also have 0755 permissions. + +{{Anchor|InitscriptScriptlets}} +=== Initscripts in spec file scriptlets === + +
    +Requires(post): chkconfig
+Requires(preun): chkconfig
+# This is for /sbin/service
+Requires(preun): initscripts
+...
+%post
+# This adds the proper /etc/rc*.d links for the script
+/sbin/chkconfig --add 
+   
+   
+   
+   
+
+
diff --git a/_topic_map.yml b/_topic_map.yml
new file mode 100644
index 0000000..345f6b8
--- /dev/null
+++ b/_topic_map.yml
@@ -0,0 +1,316 @@
+# This configuration file dictates the organization of the topic groups and
+# topics on the main page of the doc site for this branch. Each record
+# consists of the following:
+#
+# ---                                  <= Record delimiter
+# Name: Origin of the Species          <= Display name of topic group
+# Dir:  origin_of_the_species          <= Directory name of topic group
+# Topics:
+#   - Name: The Majestic Marmoset      <= Topic name
+#     File: the_majestic_marmoset      <= Topic file under group dir +/- .adoc
+#   - Name: The Curious Crocodile      <= Topic 2 name
+#     File: the_curious_crocodile      <= Topic 2 file
+#   - Name: The Numerous Nematodes     <= Sub-topic group name
+#     Dir: the_numerous_nematodes      <= Sub-topic group dir
+#     Topics:
+#       - Name: The Wily Worm          <= Sub-topic name
+#         File: the_wily_worm          <= Sub-topic file under /
+#       - Name: The Acrobatic Ascarid  <= Sub-topic 2 name
+#         File: the_acrobatic_ascarid  <= Sub-topic 2 file under /
+#
+# The ordering of the records in this document determines the ordering of the
+# topic groups and topics on the main page.
+---
+Name: Fedora Packaging Guidelines
+Dir: packaging
+Topics:
+  - Name: Ada
+    File: Ada.adoc
+
+  - Name: Guidelines
+    File: Guidelines.adoc
+
+  - Name: Ada
+    File: Ada.adoc
+
+  - Name: Alternatives
+    File: Alternatives.adoc
+
+  - Name: AppData
+    File: AppData.adoc
+
+  - Name: AutoProvidesAndRequiresFiltering
+    File: AutoProvidesAndRequiresFiltering.adoc
+
+  - Name: Bundled_Libraries
+    File: Bundled_Libraries.adoc
+
+  - Name: Bundled_Libraries_Virtual_Provides
+    File: Bundled_Libraries_Virtual_Provides.adoc
+
+  - Name: C_and_C++
+    File: C_and_C++.adoc
+
+  - Name: Cmake
+    File: Cmake.adoc
+
+  - Name: Committee
+    File: Committee.adoc
+
+  - Name: Conflicts
+    File: Conflicts.adoc
+
+  - Name: CronFiles
+    File: CronFiles.adoc
+
+  - Name: CryptoPolicies
+    File: CryptoPolicies.adoc
+
+  - Name: D
+    File: D.adoc
+
+  - Name: Debuginfo
+    File: Debuginfo.adoc
+
+  - Name: DefaultServices
+    File: DefaultServices.adoc
+
+  - Name: DevAssistant
+    File: DevAssistant.adoc
+
+  - Name: Directory_Replacement
+    File: Directory_Replacement.adoc
+
+  - Name: DistTag
+    File: DistTag.adoc
+
+  - Name: Drupal7
+    File: Drupal7.adoc
+
+  - Name: EclipsePlugins
+    File: EclipsePlugins.adoc
+
+  - Name: Emacs
+    File: Emacs.adoc
+
+  - Name: Emacs_Old
+    File: Emacs_Old.adoc
+
+  - Name: EnvironmentModules
+    File: EnvironmentModules.adoc
+
+  - Name: EPEL
+    File: EPEL.adoc
+
+  - Name: FontsPolicy
+    File: FontsPolicy.adoc
+
+  - Name: FontsSpecTemplate
+    File: FontsSpecTemplate.adoc
+
+  - Name: Fortran
+    File: Fortran.adoc
+
+  - Name: FrequentlyMadeMistakes
+    File: FrequentlyMadeMistakes.adoc
+
+  - Name: FullExceptionList
+    File: FullExceptionList.adoc
+
+  - Name: GAP
+    File: GAP.adoc
+
+  - Name: GCJGuidelines
+    File: GCJGuidelines.adoc
+
+  - Name: Globus
+    File: Globus.adoc
+
+  - Name: Guidelines:Systemd
+    File: Guidelines:Systemd.adoc
+
+  - Name: GuidelinesTodo
+    File: GuidelinesTodo.adoc
+
+  - Name: Haskell
+    File: Haskell.adoc
+
+  - Name: Initial_Service_Setup
+    File: Initial_Service_Setup.adoc
+
+  - Name: Java
+    File: Java.adoc
+
+  - Name: JavaScript
+    File: JavaScript.adoc
+
+  - Name: JPackagePolicy
+    File: JPackagePolicy.adoc
+
+  - Name: KernelModules
+    File: KernelModules.adoc
+
+  - Name: Langpacks
+    File: Langpacks.adoc
+
+  - Name: LibreOfficeExtensions
+    File: LibreOfficeExtensions.adoc
+
+  - Name: LibreOfficeExtentions
+    File: LibreOfficeExtentions.adoc
+
+  - Name: LicensingGuidelines
+    File: LicensingGuidelines.adoc
+
+  - Name: Lisp
+    File: Lisp.adoc
+
+  - Name: Meson
+    File: Meson.adoc
+
+  - Name: MinGW
+    File: MinGW.adoc
+
+  - Name: MinGW_Future
+    File: MinGW_Future.adoc
+
+  - Name: Mono
+    File: Mono.adoc
+
+  - Name: MPI
+    File: MPI.adoc
+
+  - Name: Naming
+    File: Naming.adoc
+
+  - Name: NamingGuidelines
+    File: NamingGuidelines.adoc
+
+  - Name: NewMeetingTime
+    File: NewMeetingTime.adoc
+
+  - Name: No_Bundled_Libraries
+    File: No_Bundled_Libraries.adoc
+
+  - Name: Node.js
+    File: Node.js.adoc
+
+  - Name: OCaml
+    File: OCaml.adoc
+
+  - Name: Octave
+    File: Octave.adoc
+
+  - Name: OldJPackagePolicy
+    File: OldJPackagePolicy.adoc
+
+  - Name: Old_Ruby
+    File: Old_Ruby.adoc
+
+  - Name: OpenOffice.orgExtensions
+    File: OpenOffice.orgExtensions.adoc
+
+  - Name: PatchUpstreamStatus
+    File: PatchUpstreamStatus.adoc
+
+  - Name: Perl
+    File: Perl.adoc
+
+  - Name: Per-Product_Configuration
+    File: Per-Product_Configuration.adoc
+
+  - Name: PHP
+    File: PHP.adoc
+
+  - Name: PkgConfigBuildRequires
+    File: PkgConfigBuildRequires.adoc
+
+  - Name: PreupgradeAssistant
+    File: PreupgradeAssistant.adoc
+
+  - Name: Python Eggs
+    File: Python%2FEggs.adoc
+
+  - Name: Python
+    File: Python.adoc
+
+  - Name: Python_Appendix
+    File: Python_Appendix.adoc
+
+  - Name: PythonAppendix
+    File: PythonAppendix.adoc
+
+  - Name: Python_Eggs
+    File: Python_Eggs.adoc
+
+  - Name: Python_F21
+    File: Python_F21.adoc
+
+  - Name: Python_Old
+    File: Python_Old.adoc
+
+  - Name: R
+    File: R.adoc
+
+  - Name: ReviewGuidelines
+    File: ReviewGuidelines.adoc
+
+  - Name: RPMMacros
+    File: RPMMacros.adoc
+
+  - Name: RPM_Source_Dir
+    File: RPM_Source_Dir.adoc
+
+  - Name: Ruby
+    File: Ruby.adoc
+
+  - Name: Rust
+    File: Rust.adoc
+
+  - Name: Scriptlets
+    File: Scriptlets.adoc
+
+  - Name: ScriptletSnippets
+    File: ScriptletSnippets.adoc
+
+  - Name: SourceURL
+    File: SourceURL.adoc
+
+  - Name: SSLCertificateHandling
+    File: SSLCertificateHandling.adoc
+
+  - Name: SugarActivityGuidelines
+    File: SugarActivityGuidelines.adoc
+
+  - Name: Systemd
+    File: Systemd.adoc
+
+  - Name: SysVInitScript
+    File: SysVInitScript.adoc
+
+  - Name: Tcl
+    File: Tcl.adoc
+
+  - Name: Tmpfiles.d
+    File: Tmpfiles.d.adoc
+
+  - Name: Treatment_Of_Bundled_Libraries
+    File: Treatment_Of_Bundled_Libraries.adoc
+
+  - Name: UnownedDirectories
+    File: UnownedDirectories.adoc
+
+  - Name: UsersAndGroups
+    File: UsersAndGroups.adoc
+
+  - Name: Versioning
+    File: Versioning.adoc
+
+  - Name: WeakDependencies
+    File: WeakDependencies.adoc
+
+  - Name: Web_Assets
+    File: Web_Assets.adoc
+
+  - Name: WordPress_plugin_packaging_guidelines
+    File: WordPress_plugin_packaging_guidelines.adoc
diff --git a/index-main.html b/index-main.html
new file mode 100644
index 0000000..482a1ce
--- /dev/null
+++ b/index-main.html
@@ -0,0 +1,89 @@
+
+
+  
+    
+    
+    
+    
+
+    AsciiBinder Site Template
+
+    
+    
+    
+
+    
+    
+    
+  
+  
+    
    
+      
    
+        
    
+          
+        
    
+      
    
+      
    
+        
    
+          
    What is AsciiBinder?
    
+          
    AsciiBinder is a documentation system for people who have a lot of docs to maintain and republish on a regular basis. AsciiBinder was specifically developed to solve two problems at once:
    
+          
      
+            
    • Make it easier for developers and community members to contribute documentation.
      • 
+            
    • Make it easier for content managers to build and publish several variants of the same documentation.
      • 
+          
    
+          
     
    
+          
    AsciiBinder isn't for blogging.
    
+          
    If you are looking for a great tool for blogging where your articles are sourced in AsciiDoc, this isn't it. Seriously, go check out Awestruct, which is awesome for that.
    
+          
     
    
+          
    AsciiBinder is for documenting versioned, interrelated projects.
    
+          
    On the other hand, if you are looking for a way to:
    
+          
      
+            
    • Source your docs in AsciiDoc
      • 
+            
    • Manage doc changes and doc versions with git
      • 
+            
    • Have the ability to conditionalize topics and produce different distributions of the docs based on those conditions
      • 
+          
    
+          
    ...then by jove, you've come to the right place.
    
+          
     
    
+        
    
+        
    
+          
    Installation
    
+          
      
+            
    1. Install Ruby
      2. 
+            
    2. gem install ascii_binder
      3. 
+          
    
+          
     
    
+          
    Reference
    
+          
    
+            
+              
+              GitHub
+               AsciiBinder on GitHub
+            
+            
+              
+              Pencil
+               Latest Documentation
+            
+            
+              
+              Gear
+               AsciiBinder User's Guide
+            
+            
+              
+              Wrench
+               AsciiBinder Maintainer's Guide
+            
+          
    
+        
    
+      
    
+    
    
+    
+    
+    
+    
+  
+
diff --git a/welcome/index.adoc b/welcome/index.adoc
new file mode 100644
index 0000000..e06a091
--- /dev/null
+++ b/welcome/index.adoc
@@ -0,0 +1,14 @@
+= {product-title} {product-version} Documentation
+{product-author}
+{product-version}
+:data-uri:
+:icons:
+
+Welcome to the AsciiBinder Docs Management System. This welcome page is provided as a template for the topic pages that you will create for your software project.
+
+== Need Help?
+* Check out the http://www.asciibinder.org/latest/welcome/[AsciiBinder documentation]
+* Join our http://groups.google.com/group/asciibinder[mailing list]
+* Find us on IRC at FreeNode, http://webchat.freenode.net/?randomnick=1&channels=asciibinder&uio=d4[#asciibinder] channel
+* Open an https://github.com/redhataccess/ascii_binder/issues[issue on GitHub]
+

From b0c61584813d52ff8122fecbb328bc5c78f02211 Mon Sep 17 00:00:00 2001
From: Zbigniew Jędrzejewski-Szmek 
Date: Apr 15 2018 10:50:46 +0000
Subject: [PATCH 3551/3559] python: formatting fixes


---

diff --git a/packaging/AutoProvidesAndRequiresFiltering.adoc b/packaging/AutoProvidesAndRequiresFiltering.adoc
index 23235f1..376a98a 100644
--- a/packaging/AutoProvidesAndRequiresFiltering.adoc
+++ b/packaging/AutoProvidesAndRequiresFiltering.adoc
@@ -1,3 +1,5 @@
+= Auto Provides and Requires Filtering
+
 [[summary]]
 Summary
 ~~~~~~~
@@ -28,7 +30,7 @@ It's strongly recommended that these filtering macros be invoked before %descrip
 Regular Expression Variant
 ^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-These filters use regular expressions. The regular expression variant used for these filters follow the POSIX.2 regular expression standard (see man regex(7) ). In this variant, the literal characters `^.[$()|*+?{` need to be backslash escaped. Because rpm interprets backslashes as part of its parsing of spec files, you will need to use a *double backslash* for any escapes. A literal backslash ("`\`") is represented by four backslashes.
+These filters use regular expressions. The regular expression variant used for these filters follow the POSIX.2 regular expression standard (see man regex(7) ). In this variant, the literal characters `^.[$()|\*+?{` need to be backslash escaped. Because rpm interprets backslashes as part of its parsing of spec files, you will need to use a *double backslash* for any escapes. A literal backslash ("`\`") is represented by four backslashes.
 
 The regex engine is only passed the final string, after rpm macro expansion. So you can't use unescaped data via rpm macros. For instance, if you generate a list of files to match in a macro and that list contains `libfoo.so` you'll have to use `libfoo\\.so` to escape the ("`.`"). Example:
 
@@ -186,5 +188,3 @@ Additional Information
 ~~~~~~~~~~~~~~~~~~~~~~
 
 Additional information about RPM's dependency generator can be found here: http://rpm.org/user_doc/dependency_generators.html
-
-Category:Packaging_guidelines
diff --git a/packaging/Python.adoc b/packaging/Python.adoc
index 65007a1..a9a8a22 100644
--- a/packaging/Python.adoc
+++ b/packaging/Python.adoc
@@ -1,4 +1,4 @@
-__TOC__
+:source-highlighter: pygments
 
 [[python-version-support]]
 Python Version Support
@@ -16,8 +16,11 @@ However, packages in Fedora MUST NOT depend on where `/usr/bin/python` happens t
 
 All python runtimes have a virtual provide for `python(abi) = $MAJOR-$MINOR`. For example, the python-3.4 runtime package has:
 
-` $ rpm -q --provides python3 |grep -i abi` +
-` python(abi) = 3.4`
+[source,console]
+----
+$ rpm -q --provides python3 |grep -i abi
+python(abi) = 3.4
+----
 
 python modules using these runtimes should have a corresponding "Requires" line on the python runtime that they are used with. This is done automatically for files below `/usr/lib[^/]*/python${PYVER}`
 
@@ -42,8 +45,8 @@ Using a fictional module named "example", the subpackage containing the python2 
 The python3 subpackage *must* provide `python3-example`. However, as the naming guidelines mandate that the python3 subpackage be named `python3-example`, this will happen automatically.
 
 [[the-python_provide-macro]]
-The %python_provide macro
-^^^^^^^^^^^^^^^^^^^^^^^^^
+The `%python_provide` macro
+^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 In addition, the subpackage corresponding to the current system runtime *must* provide `Provides: python-example`. However, the system version of python in Fedora will almost certainly change at some point in the future.
 
@@ -59,6 +62,7 @@ Automatic Provides with a standardized name
 
 When building a Python package, RPM looks for `.dist-info` and `.egg-info` files or directories in the `%files` sections of all packages. If one or more are found, RPM parses them to find the *standardized name* (i.e. dist name, name on PyPI) of the packaged software, and then automatically creates two `Provides:` tags in the following format:
 
+[source,spec]
 ....
 Provides: pythonX.Ydist(CANONICAL_STANDARDIZED_NAME)
 Provides: pythonXdist(CANONICAL_STANDARDIZED_NAME)
@@ -76,6 +80,7 @@ In addition, you can use the %\{py_dist_name} macro that simply transforms any _
 
 For example:
 
+[source,spec]
 ....
 BuildRequires: %{py2_dist PyMySQL} >= 0.7.5
 # => BuildRequires: python2dist(pymysql) >= 0.7.5
@@ -99,23 +104,24 @@ The following macros are defined for you in all supported Fedora and EPEL releas
 |__python |`%{__python2}` |Prohibited (see note below)
 |__python2 |/usr/bin/python2 |Python 2 interpreter.
 |__python3 |/usr/bin/python3 |Python 3 interpreter
-|python_provide |(Lua script) |Given a package name, evaluates to either `Provides: python-example` or nothing at all depending on the version of the system runtime. See Packaging:Python#The_.25python_provide_macro[here] for an example.
-|py2_dist |(Lua script) |Given a standardized name (i.e. dist name, name on PyPI) of Python software, it will convert it to a canonical format, and evaluates to `python2dist(CANONICAL_NAME)`, which is useful when listing dependencies. See Packaging:Python#Automatic_Provides_with_a_standardized_name[above] for more information.
+|python_provide |(Lua script) |Given a package name, evaluates to either `Provides: python-example` or nothing at all depending on the version of the system runtime. See <> for an example.
+|py2_dist |(Lua script) |Given a standardized name (i.e. dist name, name on PyPI) of Python software, it will convert it to a canonical format, and evaluates to `python2dist(CANONICAL_NAME)`, which is useful when listing dependencies. See <> for more information.
 |python2_sitelib |/usr/lib/python2.X/site-packages |Where pure python2 modules are installed
 |python2_sitearch |/usr/lib64/python2.X/site-packages on x86_64 +
 /usr/lib/python2.X/site-packages on x86 |Where python2 extension modules that are compiled C are installed
 |python3_sitelib |/usr/lib/python3.X/site-packages |Where pure python3 modules are installed
 |python3_sitearch |/usr/lib64/python3.X/site-packages on x86_64 +
 /usr/lib/python3.X/site-packages on x86 |Where python3 extension modules that are compiled C are installed
-|py3_dist |(Lua script) |Given a standardized name (i.e. dist name, name on PyPI) of Python software, it will convert it to a canonical format, and evaluates to `python3dist(CANONICAL_NAME)`, which is useful when listing dependencies. See Packaging:Python#Automatic_Provides_with_a_standardized_name[above] for more information.
+|py3_dist |(Lua script) |Given a standardized name (i.e. dist name, name on PyPI) of Python software, it will convert it to a canonical format, and evaluates to `python3dist(CANONICAL_NAME)`, which is useful when listing dependencies. See <> for more information.
 |py_byte_compile |(script) |Defined in python3-devel. See the Packaging:Python_Appendix#Manual_byte_compilation[byte compiling] section for usage
 |python3_version |3.X |Defined in python3-devel. Useful when running programs with Python version in filename, such as nosetest-%\{python3_version}
 |python3_version_nodots |3X |Defined in python3-devel. Useful when listing files explicitly in %files section , such as %\{python3_sitelib}/foo/*.cpython-%\{python3_version_nodots}.pyo
-|py_dist_name |(Lua script) |Given a standardized name (i.e. dist name, name on PyPI) of Python software, it will convert it to a canonical format. See Packaging:Python#Automatic_Provides_with_a_standardized_name[above] for more information.
+|py_dist_name |(Lua script) |Given a standardized name (i.e. dist name, name on PyPI) of Python software, it will convert it to a canonical format. See <> for more information.
 |=======================================================================================================================================================================================================================================================================================================================================
 
 During `%install` or when listing `%files` you can use the `python2_sitearch` and `python2_sitelib` macros to specify where the installed modules are to be found. For instance:
 
+[source,spec]
 ....
 %files
 # A pure python2 module
@@ -157,6 +163,7 @@ You must include in your package the .pyc and .pyo files. If the build process c
 
 All that you need to do is include the files in the `%files` section (replacing %\{python3_sitelib} with the appropriate macro for your package):
 
+[source,spec]
 ....
 %files
 %{python3_sitelib}/foo/
@@ -164,6 +171,7 @@ All that you need to do is include the files in the `%files` section (replacing 
 
 or, if the python code installs directly into %\{python3_sitelib}:
 
+[source,spec]
 ....
 %files
 %{python3_sitelib}/foo.py
@@ -209,7 +217,8 @@ aware of when the install is writing to the same file in both packages (in this
 example, a script in `%{_bindir}` and make sure that you're getting
 the version you expect.
 
-....
+[source,spec]
+----
 %global srcname example
 %global sum An example python module
 
@@ -277,7 +286,7 @@ An python module which provides a convenient example.
 %{_bindir}/sample-exec
 
 %changelog
-....
+----
 
 [[avoiding-collisions-between-the-python-2-and-python-3-stacks]]
 Avoiding collisions between the python 2 and python 3 stacks
@@ -297,13 +306,14 @@ and these will collide.
 
 For example `python-coverage` has a `setup.py` that contains:
 
-....
-    entry_points = {
-        'console_scripts': [
-            'coverage = coverage:main',
-            ]
-        },
-....
+[source,python]
+----
+entry_points = {
+    'console_scripts': [
+        'coverage = coverage:main',
+        ]
+    },
+----
 
 which thus generates a `/usr/bin/coverage` executable (this is a python
 script that runs another python script whilst generating code-coverage
@@ -312,8 +322,9 @@ information on the latter).
 Similarly for the 'scripts' clause; see e.g. `python-pygments`:
 `Pygments-1.1.1/setup.py` has:
 
+[source,python]
 ....
-    scripts = ['pygmentize'],
+scripts = ['pygmentize'],
 ....
 
 which generates a `/usr/bin/pygmentize` (this is a python script that leverages the pygments syntax-highlighting module, giving a simple command-line interface for generating syntax-highlighted files)
@@ -353,7 +364,7 @@ See http://lists.fedoraproject.org/pipermail/devel/2010-January/129217.html[this
 Packaging eggs
 ~~~~~~~~~~~~~~
 
-Please see the Python eggs Packaging:Python_Eggs[guidelines] for information specific to Python eggs.
+Please see the link:Python_Eggs.html[Python Eggs] information specific to Python eggs.
 
 [[reviewer-checklist]]
 Reviewer checklist
@@ -373,6 +384,4 @@ The following briefly summarizes the guidelines for reviewers to go over:
 Filtering Requires: and Provides:
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-RPM's dependency generator can often throw in additional dependencies and will often think packages provide functionality contrary to reality. To fix this, the dependency generator needs to be overriden so that the additional dependencies can be filtered out. See Packaging:AutoProvidesAndRequiresFiltering for details.
-
-Category:Packaging_guidelines[Category:Packaging guidelines] Category:Python
+RPM's dependency generator can often throw in additional dependencies and will often think packages provide functionality contrary to reality. To fix this, the dependency generator needs to be overriden so that the additional dependencies can be filtered out. See link:AutoProvidesAndRequiresFiltering.html[Auto Provides And Requires Filtering] for details.
diff --git a/packaging/Python_Eggs.adoc b/packaging/Python_Eggs.adoc
index cd7d79b..3310c38 100644
--- a/packaging/Python_Eggs.adoc
+++ b/packaging/Python_Eggs.adoc
@@ -1,5 +1,3 @@
-__TOC__
-
 Python packages provide extra metadata about the package in the form of egg metadata. This document explains how to package those metadata.
 
 [[why-eggs]]
@@ -18,7 +16,7 @@ The egg metadata can be used at runtime so they cannot be replaced with the rpm 
 When to Provide Egg Metadata
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-When upstream uses setuptools to provide egg metadata it will be automatically built and installed when you use the %py\{2,3}_build and %py\{2,3}_install macros.
+When upstream uses setuptools to provide egg metadata it will be automatically built and installed when you use the `%py{2,3}_build` and `%py{2,3}_install` macros.
 
 [[upstream-egg-packages]]
 Upstream Egg Packages
@@ -30,7 +28,7 @@ contains compiled bytecode and may, if it contains a C extension, contain
 compiled binary extensions as well. These are opaque structures with no
 guarantee that they were even built from the source distributed with the egg.
 If you must use an egg package from upstream because they do not provide tarballs, you
-need to include it as a source in your spec, unzip it in %setup, and rebuild
+need to include it as a source in your spec, unzip it in `%setup`, and rebuild
 from the source files contained within it.
 
 [[providing-egg-metadata-using-setuptools]]
@@ -39,6 +37,7 @@ Providing Egg Metadata Using Setuptools
 
 When upstream uses setuptools to provide egg metadata it is very simple to include them in your package. Your spec file will look something like this:
 
+[source,spec]
 ....
 # Must have setuptools to build the package
 BuildRequires: python2-setuptools
@@ -67,6 +66,7 @@ Sometimes we want to keep an old version of a module around for compatibility. W
 
 When upstream doesn't include the version in the name, we have to find another way to parallel install two versions of the package. Egg metadata give us this ability. The latest version of a package must be installed as the python-MODULENAME and is built using the normal guidelines. The compatibility versions of the module should be named python-$MODULENAME$DISTINGUISHINGVER and be enabled by making these spec file changes:
 
+[source,spec]
 ....
 # Require setuptools as the consumer will need pkg_resources to use this module
 Requires: python2-setuptools
@@ -80,24 +80,25 @@ Requires: python2-setuptools
 %py2_install_egg
 ....
 
-This creates the python egg under the %\{python2_sitelib}/*.egg directory. This module is not directly usable via the import statement. Instead, the consuming package must setup the PYTHONPATH to reference the compat version before it imports the module. This can be done in a variety of ways.
+This creates the python egg under the `%{python2_sitelib}/*.egg` directory. This module is not directly usable via the `import` statement. Instead, the consuming package must setup the `PYTHONPATH` to reference the compat version before it imports the module. This can be done in a variety of ways.
 
-* Manually modifying sys.path is quick if the user just wants to try out some code with the old version:
+* Manually modifying `sys.path` is quick if the user just wants to try out some code with the old version:
 
+[source,pycon]
 ....
 >>> import sys
 >>> sys.path.insert(0, '/usr/lib/python2.7/site-packages/CherryPy-2.2.1-py2.7.egg/')
 >>> import cherrypy
 ....
 
-* Using setuptools and easy_install to create "script wrappers" to invoke the programs. Setuptools has you define an entrypoint in the program's module (basically, a main() function) and then writes a script to access that via an option in setup.py.
+* Using setuptools and easy_install to create "script wrappers" to invoke the programs. Setuptools has you define an entrypoint in the program's module (basically, a `main()` function) and then writes a script to access that via an option in setup.py.
 
 It is highly recommended that any such compatibility packages install a README.fedora file explaining how to use this module. The file should contain the above examples of how to call the module from code and explain that this is a compat package and that a newer version exists.
 
 There are several other methods of invoking scripts so that they might take the right version but they suffer from various problems. They are listed here because a program you're packaging may use them and you need to know about them if they break. If you mention them in README.fedora, please also add why they are dangerous to use.
 
-* `pkg_resources.requires('MODULE[VERSIONINFO] ')`: Does not work with a default version (able to be imported via import MODULE). The setuptools author refuses to remove this limitation and refuses to document that it is a limitation. Therefore you may run across scripts that use this method and need to patch them to use one of the above, supported methods instead.
-* `__requires__='MODULE[VERSIONINFO] '`: This works but the setuptools author feels that it is only a workaround and will not support it. It works presently but could stop in a future version of setuptools. Some upstreams use this method and may need to be fixed if the setuptools author ever changes the interface.
+* `pkg_resources.requires('MODULE[VERSIONINFO]')`: Does not work with a default version (able to be imported via import MODULE). The setuptools author refuses to remove this limitation and refuses to document that it is a limitation. Therefore you may run across scripts that use this method and need to patch them to use one of the above, supported methods instead.
+* `__requires__='MODULE[VERSIONINFO]'`: This works but the setuptools author feels that it is only a workaround and will not support it. It works presently but could stop in a future version of setuptools. Some upstreams use this method and may need to be fixed if the setuptools author ever changes the interface.
 
 [[egg-features-to-avoid]]
 Egg "Features" to avoid
@@ -115,5 +116,3 @@ Links
 * http://peak.telecommunity.com/DevCenter/setuptools
 * http://lists.debian.org/debian-python/2007/09/msg00004.html -- Discussion of eggs in Debian
 * http://mail.python.org/pipermail/distutils-sig/2007-September/008181.html -- Discussion of these guidelines on the distutils list
-
-Category:Packaging_guidelines[Category:Packaging guidelines] Category:Python

From 80fe3193ddca279ddb69ff926b8558455b411e2d Mon Sep 17 00:00:00 2001
From: Zbigniew Jędrzejewski-Szmek 
Date: Apr 15 2018 10:50:48 +0000
Subject: [PATCH 3552/3559] Drop [Category] links


git grep -e '[[]Category'  -l|xargs sed -i -r '/[[]Category/d'

---

diff --git a/packaging/Ada.adoc b/packaging/Ada.adoc
index 000695e..4f44603 100644
--- a/packaging/Ada.adoc
+++ b/packaging/Ada.adoc
@@ -79,4 +79,3 @@ Rpmlint and Ada packages
 
 Rpmlint is a program that checks packages for common problems. For Ada packages, some of the rpmlint messages, such as "executable-stack", can be disregarded, because GNAT uses trampolines for pointers to nested functions. (See for example http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24355[this entry in the GCC Bugzilla].)
 
-Category:_Packaging_guidelines[Category: Packaging guidelines]
diff --git a/packaging/Alternatives.adoc b/packaging/Alternatives.adoc
index 630a568..b814ca3 100644
--- a/packaging/Alternatives.adoc
+++ b/packaging/Alternatives.adoc
@@ -156,4 +156,3 @@ fi
 %attr(0755,root,root) %{_initrddir}/sendmail
 ....
 
-Category:Packaging_guidelines[Category:Packaging guidelines]
diff --git a/packaging/AppData.adoc b/packaging/AppData.adoc
index 6782968..109c346 100644
--- a/packaging/AppData.adoc
+++ b/packaging/AppData.adoc
@@ -87,4 +87,3 @@ Although you can just include the .appdata.xml or .metainfo.xml files in the pac
 appstream-util validate-relax --nonet %{buildroot}%{_datadir}/metainfo/*.appdata.xml
 ....
 
-Category:Packaging_guidelines[Category:Packaging guidelines]
diff --git a/packaging/C_and_C++.adoc b/packaging/C_and_C++.adoc
index a9e3a16..038e36f 100644
--- a/packaging/C_and_C++.adoc
+++ b/packaging/C_and_C++.adoc
@@ -48,4 +48,3 @@ Applications
 
 No additional suggestions are provided for applications at this time.
 
-Category:Packaging_guidelines[Category:Packaging guidelines]
diff --git a/packaging/Cmake.adoc b/packaging/Cmake.adoc
index 117371a..79d811d 100644
--- a/packaging/Cmake.adoc
+++ b/packaging/Cmake.adoc
@@ -42,4 +42,3 @@ Nevertheless, RPATH issues might arise when cmake was used improperly. E.g. inst
 * http://www.cmake.org/documentation/
 * http://www.cmake.org/Wiki/CMake
 
-Category:Packaging_guidelines[Category:Packaging guidelines]
diff --git a/packaging/Conflicts.adoc b/packaging/Conflicts.adoc
index deb21a9..1f5c431 100644
--- a/packaging/Conflicts.adoc
+++ b/packaging/Conflicts.adoc
@@ -174,4 +174,3 @@ Other Uses of Conflicts:
 
 If you find yourself in a situation where you feel that your package has to conflict with another package (either explicitly or implicitly), but does not fit the documented accepted cases above, then you need to make your case to the link:Packaging/Committee[Fedora Packaging Committee]. If they agree, then, and only then can you use `Conflicts:` in a Fedora package. Remember, whenever you use `Conflicts:`, you are also required to include the reasoning in a comment next to the `Conflicts:` entry, so that it will be abundantly clear why it needed to exist.
 
-Category:_Packaging_guidelines[Category: Packaging guidelines]
diff --git a/packaging/CronFiles.adoc b/packaging/CronFiles.adoc
index 593ebe7..c716e37 100644
--- a/packaging/CronFiles.adoc
+++ b/packaging/CronFiles.adoc
@@ -86,4 +86,3 @@ mkdir -p $RPM_BUILD_ROOT%{_sysconfdir}/cron.monthly
 %config(noreplace) %{_sysconfdir}/cron.monthly/%{name}
 ....
 
-Category:Packaging_guidelines[Category:Packaging guidelines]
diff --git a/packaging/CryptoPolicies.adoc b/packaging/CryptoPolicies.adoc
index 9ad8ded..364a14d 100644
--- a/packaging/CryptoPolicies.adoc
+++ b/packaging/CryptoPolicies.adoc
@@ -32,4 +32,3 @@ Perl applications
 * *LWP::UserAgent Perl applications*:
 ** Check the source code for passing *SSL_cipher_list* argument to *ssl_opts()* method call on a *LWP::UserAgent* object. If such a call presents, follow instructions described in the OpenSSL section.
 
-Category:Packaging_guidelines[Category:Packaging guidelines]
diff --git a/packaging/D.adoc b/packaging/D.adoc
index 791e4fa..4a824e5 100644
--- a/packaging/D.adoc
+++ b/packaging/D.adoc
@@ -115,4 +115,3 @@ rm -rf %{buildroot}
 - initial package
 ....
 
-Category:Packaging_guidelines[Category:Packaging guidelines]
diff --git a/packaging/Debuginfo.adoc b/packaging/Debuginfo.adoc
index e10aa6e..1800ed3 100644
--- a/packaging/Debuginfo.adoc
+++ b/packaging/Debuginfo.adoc
@@ -54,4 +54,3 @@ Resources
 * StackTraces
 * rpmlint >= 0.77
 
-Category:Packaging_guidelines[Category:Packaging guidelines]
diff --git a/packaging/DevAssistant.adoc b/packaging/DevAssistant.adoc
index 7662e5d..6511c56 100644
--- a/packaging/DevAssistant.adoc
+++ b/packaging/DevAssistant.adoc
@@ -169,4 +169,3 @@ Sample %files section when specified manually
 %{assistant_path}/meta/%{shortname}.yaml
 ....
 
-Category:Packaging_guidelines[Category:Packaging guidelines]
diff --git a/packaging/Directory_Replacement.adoc b/packaging/Directory_Replacement.adoc
index df07206..dc5ba58 100644
--- a/packaging/Directory_Replacement.adoc
+++ b/packaging/Directory_Replacement.adoc
@@ -63,4 +63,3 @@ if st and st.type == "link" then
 end
 ....
 
-Category:Packaging_guidelines[Category:Packaging guidelines]
diff --git a/packaging/DistTag.adoc b/packaging/DistTag.adoc
index 197a54d..d69a125 100644
--- a/packaging/DistTag.adoc
+++ b/packaging/DistTag.adoc
@@ -162,4 +162,3 @@ A: Actually, we do. The Fedora buildsystem defines the values for dist when you 
 Q: Why is use of %\{?dist} mandatory?
 A: There are very few packages which didn't use it, the primary very old reason for not using it (sharing large data packages across Fedora releases) is no longer relevant because all Fedora releases are signed with a different key, and having consistent Release: tags simplifies the automated tools which may need to increment them.
 
-Category:Packaging_guidelines[Category:Packaging guidelines]
diff --git a/packaging/Drupal7.adoc b/packaging/Drupal7.adoc
index 7e84235..5d4b83e 100644
--- a/packaging/Drupal7.adoc
+++ b/packaging/Drupal7.adoc
@@ -271,4 +271,3 @@ cp -pr * %{buildroot}%{drupal7_themes}/%{theme}/
 - Initial package
 ....
 
-Category:Packaging_guidelines[Category:Packaging guidelines]
diff --git a/packaging/EclipsePlugins.adoc b/packaging/EclipsePlugins.adoc
index e48118b..30e00cc 100644
--- a/packaging/EclipsePlugins.adoc
+++ b/packaging/EclipsePlugins.adoc
@@ -245,4 +245,3 @@ rpmstubby
 
 `rpmstubby` is a small project that is part of the http://eclipse.org/linuxtools[linuxdistros project] at eclipse.org. Its aim is to make packaging Eclipse plugins as RPMs extremely simple. Specfiles for packages like `eclipse-mylyn` were originally stubbed out using it. Available as eclipse-rpmstubby package.
 
-Category:Packaging_guidelines[Category:Packaging guidelines]
diff --git a/packaging/Emacs.adoc b/packaging/Emacs.adoc
index c054a76..986636a 100644
--- a/packaging/Emacs.adoc
+++ b/packaging/Emacs.adoc
@@ -421,4 +421,3 @@ Other packages containing Emacsen add-ons (Case II)
 
 It is often the case that a software package, while not being primarily an Emacs add-on package, will contain components for (X)Emacs. For example, the Gnuplot program contains some elisp files for editing Gnuplot input files in GNU Emacs and running Gnuplot from GNU Emacs. In this case, we want to enable the (X)Emacs support IF (X)Emacs is installed, but we don't want to mandate the installation of (X)Emacs on installation of this package since (X)Emacs is not required for providing the core functionality of the package. To enable this, the emacs-filesystem and xemacs-filesystem sub-packages were created which own the /usr/share/emacs/site-lisp and /usr/share/xmeacs/site-packages directories respectively. A package can then Require these (x)emacsfilesystem packages in order to install their Elisp files without pulling in (X)Emacs and their dependency chain.
 
-Category:Packaging_guidelines[Category:Packaging guidelines]
diff --git a/packaging/Emacs_Old.adoc b/packaging/Emacs_Old.adoc
index 45416ca..c4908e6 100644
--- a/packaging/Emacs_Old.adoc
+++ b/packaging/Emacs_Old.adoc
@@ -464,4 +464,3 @@ rm -rf $RPM_BUILD_ROOT
 %changelog
 ....
 
-Category:Packaging_guidelines_obsolete[Category:Packaging guidelines obsolete]
diff --git a/packaging/EnvironmentModules.adoc b/packaging/EnvironmentModules.adoc
index 27eb0cb..33bbcb6 100644
--- a/packaging/EnvironmentModules.adoc
+++ b/packaging/EnvironmentModules.adoc
@@ -68,4 +68,3 @@ Lmod
 
 https://www.tacc.utexas.edu/tacc-projects/lmod[Lmod] is an environment modules implementation written in Lua, and can make use of module files written in Lua as well as Tcl. Such files have a ".lua" extensions. However, such files *must not* be installed /usr/share/modulefiles so as to not cause issues when the environment-modules package is in use. Instead install into %\{_datadir}/lmod/lmod/modulefiles/Core.
 
-Category:Packaging_guidelines[Category:Packaging guidelines]
diff --git a/packaging/FontsPolicy.adoc b/packaging/FontsPolicy.adoc
index 24fe2bb..9798427 100644
--- a/packaging/FontsPolicy.adoc
+++ b/packaging/FontsPolicy.adoc
@@ -185,4 +185,3 @@ The users of this legacy backend won't thank you for destabilizing it with new f
 Notes
 ~~~~~
 
-Category:Fonts_packaging[Packaging policy] Category:Packaging_guidelines[Category:Packaging guidelines]
diff --git a/packaging/Fortran.adoc b/packaging/Fortran.adoc
index 826257a..1c6f9f7 100644
--- a/packaging/Fortran.adoc
+++ b/packaging/Fortran.adoc
@@ -20,4 +20,3 @@ As Fortran modules are architecture and GCC version specific, they MUST be place
 
 To use the modules in the Fortran module directory, one needs to add `-I%{_fmoddir}` to the compiler flags (this is already included in `FFLAGS` used by `%configure`).
 
-Category:Packaging_guidelines[Category:Packaging guidelines]
diff --git a/packaging/FullExceptionList.adoc b/packaging/FullExceptionList.adoc
index 7dc30e6..b1ee6f3 100644
--- a/packaging/FullExceptionList.adoc
+++ b/packaging/FullExceptionList.adoc
@@ -2,4 +2,3 @@ This list is derived from Packaging:Guidelines#Exceptions_2 by resolving all dep
 
 List has been removed as it is variable across the collections. If you need something that is *A)* not listed in the minimal list, and *B)* isn't brought in by something else you BuildRequire, you should list it as a BuildRequire just to be safe.
 
-Category:Packaging_guidelines[Category:Packaging guidelines]
diff --git a/packaging/GAP.adoc b/packaging/GAP.adoc
index 6b8ac1e..d761db3 100644
--- a/packaging/GAP.adoc
+++ b/packaging/GAP.adoc
@@ -85,4 +85,3 @@ Testing
 
 Some add-ons have not yet updated their test suites for GAP 4.8. If a GAP add-on's test suite invokes `ReadTest(foo)`, modify it to invoke `Test(foo, rec( compareFunction := "uptowhitespace" ) )` instead for Fedora 24 and later.
 
-Category:Packaging_guidelines[Category:Packaging guidelines]
diff --git a/packaging/GCJGuidelines.adoc b/packaging/GCJGuidelines.adoc
index 68795ad..603d89e 100644
--- a/packaging/GCJGuidelines.adoc
+++ b/packaging/GCJGuidelines.adoc
@@ -78,4 +78,3 @@ BuildArch:      noarch
 
 Note that the path has been stripped and `.*` has been appended.
 
-Category:_Packaging_guidelines[Category: Packaging guidelines]
diff --git a/packaging/Globus.adoc b/packaging/Globus.adoc
index c57147b..dc74228 100644
--- a/packaging/Globus.adoc
+++ b/packaging/Globus.adoc
@@ -855,4 +855,3 @@ rm -rf $RPM_BUILD_ROOT
 - Autogenerated
 ....
 
-Category:Packaging_guidelines[Category:Packaging guidelines]
diff --git a/packaging/Guidelines.adoc b/packaging/Guidelines.adoc
index a905648..6e195b4 100644
--- a/packaging/Guidelines.adoc
+++ b/packaging/Guidelines.adoc
@@ -1963,4 +1963,3 @@ Some applications, languages and build systems have specific guidelines written 
 * Packaging:Web_Assets[Shared web assets]
 * Packaging:WordPress_plugin_packaging_guidelines[Wordpress extensions]
 
-Category:Packaging_guidelines[Category:Packaging guidelines]
diff --git a/packaging/Haskell.adoc b/packaging/Haskell.adoc
index 6d13449..0b445bd 100644
--- a/packaging/Haskell.adoc
+++ b/packaging/Haskell.adoc
@@ -409,4 +409,3 @@ References
 * link:Packaging/OCaml[Fedora OCaml Packaging Guidelines]
 * link:SIGs/Haskell[Fedora Haskell SIG]
 
-Category:Packaging_guidelines[Category:Packaging guidelines]
diff --git a/packaging/Initial_Service_Setup.adoc b/packaging/Initial_Service_Setup.adoc
index 3447d1a..fba8b95 100644
--- a/packaging/Initial_Service_Setup.adoc
+++ b/packaging/Initial_Service_Setup.adoc
@@ -118,4 +118,3 @@ PIDFile=/var/run/tog-pegasus/cimserver.pid
 WantedBy=multi-user.target
 ....
 
-Category:Packaging_guidelines[Category:Packaging guidelines]
diff --git a/packaging/Java.adoc b/packaging/Java.adoc
index bb6ccd8..dbd9243 100644
--- a/packaging/Java.adoc
+++ b/packaging/Java.adoc
@@ -140,4 +140,3 @@ Guideline
 * JAR files using JNI or containing JNI shared objects themselves MUST be placed in `%{_jnidir}` and MAY be symlinked to `%{_libdir}/%{name}`.
 * JNI shared objects MUST be placed in `%{_libdir}/%{name}`
 
-Category:Java Category:Packaging_guidelines[Category:Packaging guidelines]
diff --git a/packaging/JavaScript.adoc b/packaging/JavaScript.adoc
index 3067511..4e8140d 100644
--- a/packaging/JavaScript.adoc
+++ b/packaging/JavaScript.adoc
@@ -132,4 +132,3 @@ Some Node.js modules include parts that can be used in the browser or by other s
 
 * One `nodejs-foo` package that contains the Node.js module portion, following the Packaging:Node.js[Node.js guidelines]. This may symlink to the necessary files or directories of the `js-foo` package.
 
-Category:Packaging_guidelines[Category:Packaging guidelines]
diff --git a/packaging/LibreOfficeExtensions.adoc b/packaging/LibreOfficeExtensions.adoc
index c260379..454b036 100644
--- a/packaging/LibreOfficeExtensions.adoc
+++ b/packaging/LibreOfficeExtensions.adoc
@@ -22,4 +22,3 @@ install -d -m 755 $RPM_BUILD_ROOT%{_libdir}/libreoffice/share/extensions/%{extna
 unzip -q target/lib/%{extname}.oxt -d $RPM_BUILD_ROOT%{_libdir}/libreoffice/share/extensions/%{extname}
 ....
 
-Category:Packaging_guidelines[Category:Packaging guidelines]
diff --git a/packaging/LicensingGuidelines.adoc b/packaging/LicensingGuidelines.adoc
index a2432aa..594e46c 100644
--- a/packaging/LicensingGuidelines.adoc
+++ b/packaging/LicensingGuidelines.adoc
@@ -182,4 +182,3 @@ Public Domain
 
 Works which are clearly marked as being in the Public Domain, and for which no evidence is known to contradict this statement, are treated in Fedora as being in the Public Domain, on the grounds that the intentions of the original creator are reflected by such a use, even if due to regional issues, it may not have been possible for the original creator to fully abandon all of their their copyrights on the work and place it fully into the Public Domain. If you believe that a work in Fedora which is marked as being in the Public Domain is actually available under a copyright license, please inform us of this fact with details, and we will immediately investigate the claim.
 
-Category:Packaging_guidelines[Category:Packaging guidelines]
diff --git a/packaging/Lisp.adoc b/packaging/Lisp.adoc
index 6d2a43b..1da87a6 100644
--- a/packaging/Lisp.adoc
+++ b/packaging/Lisp.adoc
@@ -160,4 +160,3 @@ Further reading
 
 See http://www.cliki.net/common-lisp-controller and http://common-lisp.net/project/asdf/ for more details on common-lisp-controller and asdf.
 
-Category:Packaging_guidelines[Category:Packaging guidelines]
diff --git a/packaging/Meson.adoc b/packaging/Meson.adoc
index 1a0050b..43b96a8 100644
--- a/packaging/Meson.adoc
+++ b/packaging/Meson.adoc
@@ -86,4 +86,3 @@ Requires:       %{name}%{?_isa} = %{?epoch:%{epoch}:}%{version}-%{release}
 %{_includedir}/%{name}.h
 ....
 
-Category:Packaging_guidelines[Category:Packaging guidelines]
diff --git a/packaging/MinGW.adoc b/packaging/MinGW.adoc
index ad288ac..8eb91e8 100644
--- a/packaging/MinGW.adoc
+++ b/packaging/MinGW.adoc
@@ -611,4 +611,3 @@ find $RPM_BUILD_ROOT -name "*.la" -delete
 - Initial release
 ....
 
-Category:Packaging_guidelines[Category:Packaging guidelines]
diff --git a/packaging/Mono.adoc b/packaging/Mono.adoc
index fda329e..943d2cf 100644
--- a/packaging/Mono.adoc
+++ b/packaging/Mono.adoc
@@ -150,4 +150,3 @@ Glossary
 * *GAC*: GAC stands for Global Assembly Cache. It is a machine-wide .NET assemblies cache.
 * *Glue Libraries*: Libraries which bridge a system library written in C or C++ with Mono. These wrappers are separate different than AOTs.
 
-Category:Packaging_guidelines[Category:Packaging guidelines]
diff --git a/packaging/Node.js.adoc b/packaging/Node.js.adoc
index be6d5b3..6960d33 100644
--- a/packaging/Node.js.adoc
+++ b/packaging/Node.js.adoc
@@ -259,4 +259,3 @@ One of the packages must additionally provide a symlink from the usual location 
 
 Finally, any packages that depend on a version that *does not* provide the aforementioned symlink from the base name to the versioned directory must be rebuilt in order to work properly. To obtain a list of potentially affected packages, run `reqoquery --whatrequires 'npm(module_name)'` or `npm view module_name dependencies`. Please coordinate with the Node.js SIG if any rebuilds are necessary.
 
-Category:Packaging_guidelines[Category:Packaging guidelines]
diff --git a/packaging/OCaml.adoc b/packaging/OCaml.adoc
index c1ef223..a45d050 100644
--- a/packaging/OCaml.adoc
+++ b/packaging/OCaml.adoc
@@ -178,4 +178,3 @@ Further reading
 * https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01280.html - Proposal to include MD5 sums in RPM deps.
 * https://bugzilla.redhat.com/show_bug.cgi?id=433783 - Common rpmlint errors and warnings in OCaml packages.
 
-Category:Packaging_guidelines[Category:Packaging guidelines]
diff --git a/packaging/Octave.adoc b/packaging/Octave.adoc
index ba1db1d..c207d92 100644
--- a/packaging/Octave.adoc
+++ b/packaging/Octave.adoc
@@ -233,4 +233,3 @@ Obsoletes notes
 
 Packages that used to be in the octave-forge package need to have the Obsoletes line above. Packages that were not do not.
 
-Category:Packaging_guidelines_drafts[Category:Packaging guidelines drafts]
diff --git a/packaging/OpenOffice.orgExtensions.adoc b/packaging/OpenOffice.orgExtensions.adoc
index f3ea835..dd555e8 100644
--- a/packaging/OpenOffice.orgExtensions.adoc
+++ b/packaging/OpenOffice.orgExtensions.adoc
@@ -42,4 +42,3 @@ fi
 unopkg list --shared > /dev/null 2>&1 || :
 ....
 
-Category:Packaging_guidelines[Category:Packaging guidelines]
diff --git a/packaging/PHP.adoc b/packaging/PHP.adoc
index fb2331c..d9d9c23 100644
--- a/packaging/PHP.adoc
+++ b/packaging/PHP.adoc
@@ -424,4 +424,3 @@ pear make-rpm-spec Foo.tgz
 References to the Fedora PHP Packaging Guidelines
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-Category:PHP Category:Packaging_guidelines[Category:Packaging guidelines]
diff --git a/packaging/PatchUpstreamStatus.adoc b/packaging/PatchUpstreamStatus.adoc
index 6509238..95ee03e 100644
--- a/packaging/PatchUpstreamStatus.adoc
+++ b/packaging/PatchUpstreamStatus.adoc
@@ -52,4 +52,3 @@ Why upstream?
 
 Refer link:PackageMaintainers/WhyUpstream[ Why Upstream?]
 
-Category:Packaging_guidelines[Category:Packaging guidelines]
diff --git a/packaging/Per-Product_Configuration.adoc b/packaging/Per-Product_Configuration.adoc
index 55d16e3..34c388a 100644
--- a/packaging/Per-Product_Configuration.adoc
+++ b/packaging/Per-Product_Configuration.adoc
@@ -128,4 +128,3 @@ fi
 %{_datadir}/polkit-1/actions/org.fedoraproject.FirewallD1.server.policy
 ....
 
-Category:Packaging_guidelines[Category:Packaging guidelines]
diff --git a/packaging/Perl.adoc b/packaging/Perl.adoc
index 6461775..d720772 100644
--- a/packaging/Perl.adoc
+++ b/packaging/Perl.adoc
@@ -223,4 +223,3 @@ People around Perl, who are packaging, maintaining & reviewing packages. If you 
 
 New Perl packages should set the https://lists.fedoraproject.org/mailman/listinfo/Perl-devel[Fedora Perl SIG mailing list] as a member of the initial-cc list for bugzilla. This can be done by adding the user `perl-sig` to the initial CC list when creating the link:Package_SCM_admin_requests#New_Packages[New Package SCM Request].
 
-Category:Perl Category:Packaging_guidelines[Category:Packaging guidelines]
diff --git a/packaging/PreupgradeAssistant.adoc b/packaging/PreupgradeAssistant.adoc
index 99ddc69..8380e68 100644
--- a/packaging/PreupgradeAssistant.adoc
+++ b/packaging/PreupgradeAssistant.adoc
@@ -269,4 +269,3 @@ install -p -m 644 %{preupgrade_name}-%{preupg_results}/%{name}/group.xml %{build
 %{preupgrade_dir}/%{name}/*.xml
 ....
 
-Category:Packaging_guidelines[Category:Packaging guidelines]
diff --git a/packaging/Python_Appendix.adoc b/packaging/Python_Appendix.adoc
index eef0e22..378d891 100644
--- a/packaging/Python_Appendix.adoc
+++ b/packaging/Python_Appendix.adoc
@@ -127,4 +127,3 @@ make install DESTDIR=%{buildroot}
 
 The `%py_byte_compile` macro takes two arguments. The first is the python interpreter to use for byte compiling. The second is a file or directory to byte compile. If the second argument is a directory, the macro will recursively byte compile any *.py file in the directory.
 
-Category:Packaging_guidelines[Category:Packaging guidelines] Category:Python
diff --git a/packaging/Python_Old.adoc b/packaging/Python_Old.adoc
index c606dea..3c371f3 100644
--- a/packaging/Python_Old.adoc
+++ b/packaging/Python_Old.adoc
@@ -548,4 +548,3 @@ Filtering Requires: and Provides:
 
 RPM's dependency generator can often throw in additional dependencies and will often think packages provide functionality contrary to reality. To fix this, the dependency generator needs to be overriden so that the additional dependencies can be filtered out. See Packaging:AutoProvidesAndRequiresFiltering for details.
 
-Category:Packaging_guidelines[Category:Packaging guidelines] Category:Python
diff --git a/packaging/R.adoc b/packaging/R.adoc
index b7ed062..e695dfa 100644
--- a/packaging/R.adoc
+++ b/packaging/R.adoc
@@ -265,4 +265,3 @@ R packages usually expect to find their header files in %\{_libdir}/R/library/*/
 
 You should still separate these header files into a -devel subpackage.
 
-Category:Packaging_guidelines[Category:Packaging guidelines]
diff --git a/packaging/RPMMacros.adoc b/packaging/RPMMacros.adoc
index 38fcc8c..829cae5 100644
--- a/packaging/RPMMacros.adoc
+++ b/packaging/RPMMacros.adoc
@@ -73,4 +73,3 @@ The macros are usually used with `rpmbuild --define` to specify which directorie
 %{_buildrootdir}      %{_topdir}/BUILDROOT
 ....
 
-Category:Packaging_guidelines[Category:Packaging guidelines]
diff --git a/packaging/RPM_Source_Dir.adoc b/packaging/RPM_Source_Dir.adoc
index a04afb7..a44ba0a 100644
--- a/packaging/RPM_Source_Dir.adoc
+++ b/packaging/RPM_Source_Dir.adoc
@@ -51,4 +51,3 @@ done
 
 where Source1000: subdirs-kde-l10n is a list provided by upstream of all the languages supported, and there are ~50 SourceN: tags, which can vary from version from version, but match the languages listed in Source1000, for the tarballs provided by upstream.
 
-Category:Packaging_guidelines[Category:Packaging guidelines]
diff --git a/packaging/Ruby.adoc b/packaging/Ruby.adoc
index d494cc0..07c99a7 100644
--- a/packaging/Ruby.adoc
+++ b/packaging/Ruby.adoc
@@ -438,4 +438,3 @@ popd
 * Add the commands you used to get the tests into the specfile as comments. This will make it a lot easier the next time you will need to get them.
 * Run the tests as you normally would.
 
-Category:Packaging_guidelines[Category:Packaging guidelines]
diff --git a/packaging/Rust.adoc b/packaging/Rust.adoc
index 0b78505..88eaa39 100644
--- a/packaging/Rust.adoc
+++ b/packaging/Rust.adoc
@@ -357,4 +357,3 @@ which use %{crate} from crates.io.
 %{cargo_registry}/%{crate}-%{version}/
 ....
 
-Category:Packaging_guidelines[Category:Packaging guidelines]
diff --git a/packaging/SSLCertificateHandling.adoc b/packaging/SSLCertificateHandling.adoc
index ef93a25..95c99ef 100644
--- a/packaging/SSLCertificateHandling.adoc
+++ b/packaging/SSLCertificateHandling.adoc
@@ -152,4 +152,3 @@ Your application should Do The Right Thing for certificates in PKCS#11, without 
 
 There is a wiki page at https://fedoraproject.org/wiki/PackageMaintainers/PKCS11 which help you test whether your packages meet these guidelines. If in doubt, file a bug as blocking the https://bugzilla.redhat.com/show_bug.cgi?id=PKCS11[PKCS#11 tracker bug] and ask for assistance.
 
-Category:Packaging_guidelines[Category:Packaging guidelines]
diff --git a/packaging/Scriptlets.adoc b/packaging/Scriptlets.adoc
index 25f5886..3a3c0fa 100644
--- a/packaging/Scriptlets.adoc
+++ b/packaging/Scriptlets.adoc
@@ -393,4 +393,3 @@ if [ "$1" = 0 ] && [ -f %{_sysconfdir}/shells ] ; then
 fi
 ....
 
-Category:Packaging_guidelines[Category:Packaging guidelines] Category:Packaging_guidelines[Category:Packaging guidelines]
diff --git a/packaging/SourceURL.adoc b/packaging/SourceURL.adoc
index a35583e..479836e 100644
--- a/packaging/SourceURL.adoc
+++ b/packaging/SourceURL.adoc
@@ -220,4 +220,3 @@ Sometimes this does not work because the upstream cgi tries to parse the fragmen
 
 '''''
 
-Category:Packaging_guidelines[Category:Packaging guidelines]
diff --git a/packaging/UsersAndGroups.adoc b/packaging/UsersAndGroups.adoc
index 0bf0492..20416c8 100644
--- a/packaging/UsersAndGroups.adoc
+++ b/packaging/UsersAndGroups.adoc
@@ -96,4 +96,3 @@ Rationale for some of the implementation choices
 * We run the `groupadd`/`useradd` always -- both on initial installs and upgrades -- in `%pre`. This is made possible by the `getent` checks above, and should fix things up if the user/group has disappeared after the package to be upgraded was initially installed (just like file permissions get reset on upgrades etc).
 * The `exit 0` at the end will result in the `%pre` scriptlet passing through even if the user/group creation fails for some reason. This is suboptimal but has less potential for system wide breakage than allowing it to fail. If the user/group aren't available at the time the package's payload is unpacked, rpm will fall back to setting those files owned by root.
 
-Category:Packaging_guidelines[Category:Packaging guidelines]
diff --git a/packaging/Versioning.adoc b/packaging/Versioning.adoc
index 337ac2f..62dd5c0 100644
--- a/packaging/Versioning.adoc
+++ b/packaging/Versioning.adoc
@@ -146,4 +146,3 @@ Rawhide is allowed to lag temporarily
 
 A package MAY temporarily have a lower EVR in Rawhide when compared to a release branch of Fedora ONLY in the case where the package fails to build in Rawhide. This permits important updates to be pushed to existing Fedora releases regardless of the current state of Rawhide.
 
-Category:Packaging_guidelines[Category:Packaging guidelines]
diff --git a/packaging/WeakDependencies.adoc b/packaging/WeakDependencies.adoc
index 446a11d..bc513c7 100644
--- a/packaging/WeakDependencies.adoc
+++ b/packaging/WeakDependencies.adoc
@@ -123,4 +123,3 @@ the targeted package.
 Note, that EPEL or other third party repositories may have (and are encouraged
 to have) a different policy.
 
-Category:Packaging_guidelines[Category:Packaging guidelines]
diff --git a/packaging/Web_Assets.adoc b/packaging/Web_Assets.adoc
index 4c80f58..47c18eb 100644
--- a/packaging/Web_Assets.adoc
+++ b/packaging/Web_Assets.adoc
@@ -114,4 +114,3 @@ All system fonts (available in `%{_datadir}/fonts`) are automatically made avail
 
 Please note that those guidelines prohibit packaging fonts elsewhere. There is no compelling reason to support other font formats, as most browsers that support web fonts support the TTF or OTF formats used by system fonts, therefore alternative web font formats like WOFF are prohibited.
 
-Category:Packaging_guidelines[Category:Packaging guidelines]
diff --git a/packaging/WordPress_plugin_packaging_guidelines.adoc b/packaging/WordPress_plugin_packaging_guidelines.adoc
index d4a24e9..3e7a3bd 100644
--- a/packaging/WordPress_plugin_packaging_guidelines.adoc
+++ b/packaging/WordPress_plugin_packaging_guidelines.adoc
@@ -112,4 +112,3 @@ rm -rf %{buildroot}
 %changelog
 ....
 
-Category:Packaging_guidelines[Category:Packaging guidelines]

From c5a1a568590ebb6c7aec87f9fca712c596801d60 Mon Sep 17 00:00:00 2001
From: Zbigniew Jędrzejewski-Szmek 
Date: Apr 15 2018 10:50:48 +0000
Subject: [PATCH 3553/3559] ada: formatting fixes


---

diff --git a/packaging/Ada.adoc b/packaging/Ada.adoc
index 4f44603..d2156d9 100644
--- a/packaging/Ada.adoc
+++ b/packaging/Ada.adoc
@@ -1,14 +1,12 @@
-[[packaging-ada-programs-and-libraries]]
-Packaging Ada programs and libraries
-------------------------------------
+= Packaging Ada programs and libraries
 
-This document describes the current policies for packaging Ada programs and libraries for Fedora. These are Ada-specific amendments to the generic Packaging Guidelines. Ada packages must also conform to the Packaging:Guidelines[Packaging Guidelines] and the Packaging:ReviewGuidelines[Review Guidelines].
+This document describes the current policies for packaging Ada programs and libraries for Fedora. These are Ada-specific amendments to the generic Packaging Guidelines. Ada packages must also conform to the link:Guidelines.html[Packaging Guidelines] and the link:ReviewGuidelines.html[Review Guidelines].
 
 [[compilation]]
 Compilation
 ~~~~~~~~~~~
 
-* Ada code in Fedora *MUST* be compiled using GNAT, the default Ada compiler in Fedora. All packages that contain Ada code *MUST* have "`BuildRequires: gcc-gnat`" to ensure that the compiler is available.
+* Ada code in Fedora *MUST* be compiled using GNAT, the default Ada compiler in Fedora. All packages that contain Ada code *MUST* have `BuildRequires: gcc-gnat` to ensure that the compiler is available.
 * There are a number of RPM macros that contain Fedora's standard compiler and linker flags adapted for GNAT. The appropriate macro *MUST* be used in the build stage. The right macro to use depends on what build tools the package uses.
 ** For packages that are built with `Gnatmake` or `GPRbuild` but without `Comfignat` there are the macros `%Gnatmake_optflags` and `%GPRbuild_optflags`, which contain builder, compiler and linker flags.
 ** In case a package's build system invokes the underlying GNAT tools without using `Gnatmake` or `GPRbuild`, then the appropriate macro for each tool *MUST* be used. If for example Gnatlink is invoked directly, then the expansion of Gnatlink_flags shall be passed to it.
@@ -69,9 +67,9 @@ end Example;
 File placement
 ~~~~~~~~~~~~~~
 
-* Ada source files in -devel packages (*.ads and *.adb) *MUST* be placed in the `%{_includedir}` directory or a subdirectory thereof. Placing them directly in `%{_includedir}` may be appropriate if there are very few of them in the package and their names include the name of the library. Otherwise they should usually be placed in a subdirectory, for example `%{_includedir}/%{name}`.
-* Ada library information files (*.ali) *MUST* be placed in a subdirectory of `%{_libdir}`, for example `%{_libdir}/%{name}`.
-* GNAT projects files (*.gpr) *MUST* be placed in the `%{_GNAT_project_dir}` directory or a subdirectory thereof. A subdirectory, for example `%{_GNAT_project_dir}/%{name}`, may be a good idea if there are lots of project files in the same package or if they have generic names. Otherwise they should usually be placed directly in `%{_GNAT_project_dir}`. The name of the library *MUST* be included either in the name of each project file or in the name of the subdirectory where the project files are placed.
+* Ada source files in -devel packages (`\*.ads` and `*.adb`) *MUST* be placed in the `%{_includedir}` directory or a subdirectory thereof. Placing them directly in `%{_includedir}` may be appropriate if there are very few of them in the package and their names include the name of the library. Otherwise they should usually be placed in a subdirectory, for example `%{_includedir}/%{name}`.
+* Ada library information files (`\*.ali`) *MUST* be placed in a subdirectory of `%{_libdir}`, for example `%{_libdir}/%{name}`.
+* GNAT projects files (`\*.gpr`) *MUST* be placed in the `%{_GNAT_project_dir}` directory or a subdirectory thereof. A subdirectory, for example `%{_GNAT_project_dir}/%{name}`, may be a good idea if there are lots of project files in the same package or if they have generic names. Otherwise they should usually be placed directly in `%{_GNAT_project_dir}`. The name of the library *MUST* be included either in the name of each project file or in the name of the subdirectory where the project files are placed.
 
 [[rpmlint-and-ada-packages]]
 Rpmlint and Ada packages

From 73774a6c5ba1d894781bb6c587340fdd9bc41eb4 Mon Sep 17 00:00:00 2001
From: Zbigniew Jędrzejewski-Szmek 
Date: Apr 15 2018 10:50:48 +0000
Subject: [PATCH 3554/3559] guidelines: formatting fixes


---

diff --git a/packaging/Guidelines.adoc b/packaging/Guidelines.adoc
index 6e195b4..40e95ff 100644
--- a/packaging/Guidelines.adoc
+++ b/packaging/Guidelines.adoc
@@ -1,15 +1,11 @@
-Last revised -- by .
+The Packaging Guidelines are a collection of common issues and the severity that should be placed on them. While these guidelines should not be ignored, they should also not be blindly followed. If you think that your package should be exempt from part of the Guidelines, please bring the issue to the https://pagure.io/packaging-committee/[Fedora Packaging Committee].
 
-The Packaging Guidelines are a collection of common issues and the severity that should be placed on them. While these guidelines should not be ignored, they should also not be blindly followed. If you think that your package should be exempt from part of the Guidelines, please bring the issue to the link:Packaging_Committee[Fedora Packaging Committee].
-
-It is the package reviewer's responsibility to point out specific problems with a package and a packager's responsibility to deal with those issues. The reviewer and packager work together to determine the severity of the issues (whether they block a package or can be worked on after the package is in the repository.) Please remember that any package that you submit must also conform to the Packaging:ReviewGuidelines[Review Guidelines] .
+It is the package reviewer's responsibility to point out specific problems with a package and a packager's responsibility to deal with those issues. The reviewer and packager work together to determine the severity of the issues (whether they block a package or can be worked on after the package is in the repository.) Please remember that any package that you submit must also conform to the link:ReviewGuidelines.html[Review Guidelines].
 
 The original author of these documents is link:TomCallaway[ Tom 'spot' Callaway], though they were originally based on many other documents. They have been significantly modified over the years by many members of the Packaging Committee.
 
 Report issues with these guidelines, including typos, https://pagure.io/packaging-committee[here]. The wiki discussion pages are not read by the Committee.
 
-__TOC__
-
 [[applicability]]
 Applicability
 ~~~~~~~~~~~~~
@@ -32,13 +28,14 @@ Where the language "must", "is required to" or "needs to" is used, the packager 
 Naming
 ~~~~~~
 
-You should go through the Packaging:NamingGuidelines to ensure that your package is named appropriately.
+You should go through the link:NamingGuidelines.html[Naming Guidelines] to ensure that your package is named appropriately.
 
 [[version-and-release]]
 Version and Release
 ~~~~~~~~~~~~~~~~~~~
 
-Documentation covering the proper way to use the Version and Release fields can be found here: Packaging:Versioning
+Documentation covering the proper way to use the Version and Release fields can be found here: link:Versioning
+.html[Versioning].
 
 [[legal]]
 Legal
@@ -50,7 +47,7 @@ There are various legal concerns to consider when packaging for Fedora.
 Licensing
 ^^^^^^^^^
 
-You should review Licensing:Main and the Packaging:LicensingGuidelines to ensure that your package is licensed appropriately.
+You should review Licensing:Main and the link:LicensingGuidelines.html[Licensing Guidelines] to ensure that your package is licensed appropriately.
 
 [[code-vs-content]]
 Code Vs Content
@@ -132,9 +129,9 @@ When you encounter prebuilt binaries in a package you *MUST*:
 Exceptions
 ^^^^^^^^^^
 
-* Some software (usually related to compilers or cross-compiler environments) cannot be built without the use of a previous toolchain or development environment (open source). If you have a package which meets this criteria, contact the Fedora Packaging Committee for approval. Please note that this exception, if granted, is limited to only the initial build of the package. You may bootstrap this build with a "bootstrap" pre-built binary, but after this is complete, you must immediately increment Release, drop the "bootstrap" pre-built binary, and build completely from source. Bootstrapped packages containing pre-built "bootstrap" binaries must not be pushed as release packages or updates under any circumstances. These packages should contain the necessary logic to be built once bootstrapping is completed and the prebuilt programs are no longer needed. Information about how you should break circular dependencies by bootstrapping can be found here: Packaging:Guidelines#Bootstrapping
+* Some software (usually related to compilers or cross-compiler environments) cannot be built without the use of a previous toolchain or development environment (open source). If you have a package which meets this criteria, contact the Fedora Packaging Committee for approval. Please note that this exception, if granted, is limited to only the initial build of the package. You may bootstrap this build with a "bootstrap" pre-built binary, but after this is complete, you must immediately increment Release, drop the "bootstrap" pre-built binary, and build completely from source. Bootstrapped packages containing pre-built "bootstrap" binaries must not be pushed as release packages or updates under any circumstances. These packages should contain the necessary logic to be built once bootstrapping is completed and the prebuilt programs are no longer needed. Information about how you should break circular dependencies by bootstrapping can be found here: <>.
 * An exception is made for binary firmware, as long as it meets the requirements documented here: Licensing:Main#Binary_Firmware
-* Some pre-packaged program binaries or program libraries may be under terms which do not permit redistribution, or be affected by legal scenarios such as patents. In such situations, simply deleting these files in %prep is not sufficient, the maintainer will need to make a modified source that does not contain these files. See: Packaging:SourceURL#When_Upstream_uses_Prohibited_Code
+* Some pre-packaged program binaries or program libraries may be under terms which do not permit redistribution, or be affected by legal scenarios such as patents. In such situations, simply deleting these files in %prep is not sufficient, the maintainer will need to make a modified source that does not contain these files. See: link:SourceURL#when-upstream-uses-prohibited-code[Source URL].
 
 [[use-of-pregenerated-code]]
 Use of pregenerated code
@@ -437,7 +434,7 @@ Tags and Sections
 * The `BuildRoot:` tag, `Group:` tag, and `%clean` section SHOULD NOT be used.
 * The contents of the buildroot SHOULD NOT be removed in the first line of `%install`.
 * The `Summary:` tag value SHOULD NOT end in a period.
-* The `Source:` tags document where to find the upstream sources for the package. In most cases this SHOULD be a complete URL to the upstream tarball. For special cases, please see the Packaging:SourceURL[SourceURL Guidelines].
+* The `Source:` tags document where to find the upstream sources for the package. In most cases this SHOULD be a complete URL to the upstream tarball. For special cases, please see the link:SourceURL.html[SourceURL Guidelines].
 
 [[package-dependencies]]
 Package Dependencies
@@ -447,7 +444,7 @@ All package dependencies (build-time or runtime, regular, weak or otherwise) MUS
 
 RPM can automatically determine dependencies for most compiled libraries and for some scripting languages such as Perl. Automatically determined dependencies MUST NOT be duplicated by manual dependencies.
 
-Build dependencies, however, cannot be automatically determined and MUST be explicitly listed. Refer to the link:#BuildRequires[ BuildRequires section].
+Build dependencies, however, cannot be automatically determined and MUST be explicitly listed. Refer to the <> section.
 
 Versioned dependencies (build-time or runtime) SHOULD ONLY be used when actually necessary to guarantee that the proper version of a package is present. If a versioned dependency would be satisfied by a version present in three previous Fedora releases then the then a versioned dependency is not needed and a regular unversioned dependency SHOULD be used instead.
 
@@ -486,7 +483,7 @@ This means that gtk+-devel should contain
 Weak dependencies
 ^^^^^^^^^^^^^^^^^
 
-Weak dependencies (`Recommends:`, `Suggests:`, `Supplements:` and `Enhances:`) MAY be used to specify relationships between packages which are less strict than mandatory requirements. Please see Packaging:WeakDependencies for guidelines on using these tags.
+Weak dependencies (`Recommends:`, `Suggests:`, `Supplements:` and `Enhances:`) MAY be used to specify relationships between packages which are less strict than mandatory requirements. Please see link:WeakDependencies.html[Weak Dependencies] for guidelines on using these tags.
 
 [[richboolean-dependencies]]
 Rich/Boolean dependencies
@@ -526,7 +523,7 @@ Packagers should revisit an explicit dependency as appropriate to avoid it becom
 Filtering Auto-Generated Requires
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-RPM attempts to auto-generate Requires (and Provides) at build time, but in some situations, the auto-generated Requires/Provides are not correct or not wanted. For more details on how to filter out auto-generated Requires or Provides, please see: Packaging:AutoProvidesAndRequiresFiltering
+RPM attempts to auto-generate Requires (and Provides) at build time, but in some situations, the auto-generated Requires/Provides are not correct or not wanted. For more details on how to filter out auto-generated Requires or Provides, please see: link:AutoProvidesAndRequiresFiltering[Auto Provides and Requires Filtering].
 
 [[build-time-dependencies-buildrequires]]
 Build-Time Dependencies (BuildRequires)
@@ -559,7 +556,7 @@ This would prevent yum-builddep or similar tools that use the SRPM's requirement
 BuildRequires based on pkg-config
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-Fedora packages which use `pkg-config` to build against a library (e.g. 'foo') on which they depend, *SHOULD* express their build dependency correctly as `pkgconfig(foo)`. For more information, see Packaging:PkgConfigBuildRequires.
+Fedora packages which use `pkg-config` to build against a library (e.g. 'foo') on which they depend, *SHOULD* express their build dependency correctly as `pkgconfig(foo)`. For more information, see link:PkgConfigBuildRequires.html[PkgConfig BuildRequires].
 
 [[conditional-build-time-dependencies]]
 Conditional build-time dependencies
@@ -604,7 +601,7 @@ Files marked as documentation must not cause the package to pull in more depende
 
 Files located in `%_pkgdocdir` must not affect the runtime of the packaged software. The software must function properly and with unchanged functionality if those files are modified, removed or not installed at all.
 
-Although license files are documentation, they are treated specially (including using a different tag. Please see Packaging:LicensingGuidelines for how to handle them.
+Although license files are documentation, they are treated specially (including using a different tag. Please see link:LicensingGuidelines.html[Licensing Guidelines] for how to handle them.
 
 [[changelogs]]
 Changelogs
@@ -667,7 +664,7 @@ The next day, you make additional changes to the spec, and need to add a new cha
 
 Please remember that this is only acceptable if 1.0-1 has not yet been built.
 
-You can do this any number of times, until you actually build 1.0-1 in the buildsystem. Once you've done that, you must change the E-V-R and any new entries should be added as described in Packaging:Guidelines#Changelogs[Changelogs].
+You can do this any number of times, until you actually build 1.0-1 in the buildsystem. Once you've done that, you must change the E-V-R and any new entries should be added as described in <>.
 
 [[repeat-the-old-version-release-with-a-new-entry]]
 Repeat the old version release with a new entry
@@ -692,7 +689,7 @@ The next day, you make additional changes to the spec, and need to add a new cha
 
 Please remember that this is only acceptable if 1.0-1 has not yet been built.
 
-You can do this any number of times, until you actually build 1.0-1 in the buildsystem. Once you've done that, you must change the E-V-R and any new entries should be added as described in Packaging:Guidelines#Changelogs[Changelogs].
+You can do this any number of times, until you actually build 1.0-1 in the buildsystem. Once you've done that, you must change the E-V-R and any new entries should be added as described in <>.
 
 [[manpages]]
 Manpages
@@ -717,7 +714,7 @@ Compiler flags
 
 Compilers used to build packages must honor the applicable compiler flags set in the system rpm configuration. Honoring means that the contents of that variable is used as the basis of the flags actually used by the compiler during the package build.
 
-For C, C++, and Fortran code, the Packaging:RPMMacros#Build_flags_macros_and_variables[ %\{optflags} macro] contains these flags.
+For C, C++, and Fortran code, the link:RPMMacros.html#build-flags-macros-and-variables[`%\{optflags}` macro] contains these flags.
 Overriding these flags for performance optimizations (for instance, -O3 instead of -O2) is generally discouraged. If you can present benchmarks that show a
 significant speedup for this particular code, this could be revisited on a case-by-case basis. Adding to and overriding or filtering parts of
 these flags is permitted if there's a good reason to do so; the rationale for doing so must be documented in the specfile.
@@ -762,7 +759,7 @@ There are some notable disadvantages to enabling PIE that should be considered i
 Debuginfo packages
 ~~~~~~~~~~~~~~~~~~
 
-Packages should produce useful `-debuginfo` packages, or explicitly disable them when it is not possible to generate a useful one but rpmbuild would do it anyway. Whenever a `-debuginfo` package is explicitly disabled, an explanation why it was done is required in the specfile. Debuginfo packages are discussed in more detail in a separate document, Packaging:Debuginfo .
+Packages should produce useful `-debuginfo` packages, or explicitly disable them when it is not possible to generate a useful one but rpmbuild would do it anyway. Whenever a `-debuginfo` package is explicitly disabled, an explanation why it was done is required in the specfile. Debuginfo packages are discussed in more detail in a separate document, link:Debuginfo.html[Debuginfo].
 
 [[devel-packages]]
 Devel Packages
@@ -771,7 +768,7 @@ Devel Packages
 Fedora packages must be designed with a logical separation of files. Specifically, -devel packages must be used to contain files which are intended solely for development or needed only at build-time. This is done to minimize the install footprint for users. There are some types of files which almost always belong in a -devel package:
 
 * Header files (foo.h), usually found in /usr/include
-* Static library files when the package does not provide any matching shared library files. See Packaging:Guidelines#Packaging_Static_Libraries for more information about this scenario.
+* Static library files when the package does not provide any matching shared library files. See <> for more information about this scenario.
 * Unversioned shared system library files, when a matching versioned shared system library file is also present. For example, if your package contains:
 
 ....
@@ -817,7 +814,7 @@ Requires: %{name}%{?_isa} = %{version}-%{release}
 Shared Libraries
 ~~~~~~~~~~~~~~~~
 
-Whenever possible (and feasible), Fedora packages containing libraries SHOULD build them as shared libraries. See Packaging:Scriptlets#Shared_Libraries for information about whether scriptlets are required.
+Whenever possible (and feasible), Fedora packages containing libraries SHOULD build them as shared libraries. See link:Scriptlets.html#Shared_Libraries[Shared Libraries] for information about whether scriptlets are required.
 
 [[downstream-.so-name-versioning]]
 Downstream .so name versioning
@@ -935,9 +932,9 @@ All packages whose upstreams have no mechanism to build against system libraries
 
 To indicate an instance of bundling, first determine the name and version of the bundled library:
 
-* If the bundled package also exists separately in the distribution, use the name of that package. Otherwise consult the Packaging:Naming[naming guidelines] to determine an appropriate name for the library as if it were entering the distribution as a separate package.
+* If the bundled package also exists separately in the distribution, use the name of that package. Otherwise consult the link:Naming.html[Naming Guidelines] to determine an appropriate name for the library as if it were entering the distribution as a separate package.
 
-* Use the Packaging:Versioning[versioning guidelines] to determine an appropriate version for the library, if possible. If the library has been forked from an upstream, use the upstream version that was most recently merged in or rebased onto, or the version the original library carried at the time of the fork.
+* Use the link:Versioning.html[Versioning Guidelines] to determine an appropriate version for the library, if possible. If the library has been forked from an upstream, use the upstream version that was most recently merged in or rebased onto, or the version the original library carried at the time of the fork.
 
 Then at an appropriate place in your spec, add `Provides: bundled(``) = ` where and are the name and version you determined above. If it was not possible to determine a version, use `Provides: bundled(``)` instead.
 
@@ -947,8 +944,8 @@ In addition to indicating bundling in this manner, packages whose upstreams have
 Avoid bundling of fonts in other packages
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-Fonts in general-purpose formats such as Type1, OpenType TT (TTF) or OpenType CFF (OTF) are subject to specific packaging guidelines (Packaging:FontsPolicy[1]), and should always be packaged in the system-wide font repositories instead of private application directories.
-For more information, see: Packaging:FontsPolicy#Package_layout_for_fonts.
+Fonts in general-purpose formats such as Type1, OpenType TT (TTF) or OpenType CFF (OTF) are subject to specific packaging guidelines (link:FontsPolicy.html[1]), and should always be packaged in the system-wide font repositories instead of private application directories.
+For more information, see: link:FontsPolicy.html#package-layout-for-fonts[Package Layout for Fonts].
 
 [[beware-of-rpath]]
 Beware of Rpath
@@ -956,10 +953,10 @@ Beware of Rpath
 
 Sometimes, code will hardcode specific library paths when linking binaries (using the -rpath or -R flag). This is commonly referred to as an rpath. Normally, the dynamic linker and loader (ld.so) resolve the executable's dependencies on shared libraries and load what is required. However, when -rpath or -R is used, the location information is then hardcoded into the binary and is examined by ld.so in the beginning of the execution. Since the Linux dynamic linker is usually smarter than a hardcoded path, we usually do not permit the use of rpath in Fedora.
 
-There is a tool called _check-rpaths_ which is included in the _rpmdevtools_ package. It is a good idea to add it to the _`%__arch_install_post`_ macro in your _`~/.rpmmacros`_ config file:
+There is a tool called _check-rpaths_ which is included in the _rpmdevtools_ package. It is a good idea to add it to the `%__arch_install_post` macro in your `~/.rpmmacros` config file:
 
 ....
-%__arch_install_post            \
+%__arch_install_post          \
 /usr/lib/rpm/check-rpaths     \
 /usr/lib/rpm/check-buildroot
 ....
@@ -1047,7 +1044,7 @@ Packages MUST NOT install repository configuration files which violate the https
 Per-product Configuration
 ~~~~~~~~~~~~~~~~~~~~~~~~~
 
-In the Fedora.next world, we will have a set of curated Fedora Products as well as the availability of classic Fedora. Historically, we have maintained a single set of configuration defaults for all Fedora installs but different target use-cases have different needs. Please see the Packaging:Per-Product_Configuration[ Per-Product Configuration Guidelines] for instructions on how to create packages that need to behave differently between Fedora.next Products.
+In the Fedora.next world, we will have a set of curated Fedora Products as well as the availability of classic Fedora. Historically, we have maintained a single set of configuration defaults for all Fedora installs but different target use-cases have different needs. Please see the link:Per-Product_Configuration.html[Per-Product Configuration Guidelines] for instructions on how to create packages that need to behave differently between Fedora.next Products.
 
 [[initscripts]]
 Initscripts
@@ -1059,7 +1056,7 @@ SystemV-style initscripts are forbidden in Fedora. Systemd units must be used in
 Systemd units
 ~~~~~~~~~~~~~
 
-Detailed guidelines for packaging systemd units and systemd-managed services are Packaging:Systemd[here].
+Detailed guidelines for packaging systemd units and systemd-managed services are link:Systemd.html[here].
 
 [[desktop-files]]
 Desktop files
@@ -1134,13 +1131,13 @@ Do *not* apply a vendor tag to .desktop files (using --vendor).
 AppData files
 ~~~~~~~~~~~~~
 
-Packages containing graphical applications should include AppData files. See Packaging:AppData for the relevant guidelines.
+Packages containing graphical applications should include AppData files. See link:AppData.html[AppData] for the relevant guidelines.
 
 [[macros]]
 Macros
 ~~~~~~
 
-Packagers are strongly encouraged to use macros instead of hard-coded directory names (see Packaging:RPMMacros ). However, in situations where the macro is longer than the path it represents, or situations where the packager feels it is cleaner to use the actual path, the packager is permitted to use the actual path instead of the macro. There are several caveats to this approach:
+Packagers are strongly encouraged to use macros instead of hard-coded directory names (see link:RPMMacros.html[RPM Macros]). However, in situations where the macro is longer than the path it represents, or situations where the packager feels it is cleaner to use the actual path, the packager is permitted to use the actual path instead of the macro. There are several caveats to this approach:
 
 * The package must be consistent. For any given path, within the same spec, use either a hard-coded path or a macro, not a combination of the two.
 * %\{_libdir} must always be used for binary libraries due to multi-lib, you may not substitute a hard-coded path.
@@ -1213,7 +1210,7 @@ Check the `rpm` output for unexpanded macros (`%{foo}`) or missing information (
 Improper use of %_sourcedir
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-Packages which use files itemized as Source# files, must refer to those files by their `Source#` macro name, and must not use `$RPM_SOURCE_DIR` or `%{sourcedir}` to refer to those files. See Packaging:RPM_Source_Dir for full details.
+Packages which use files itemized as Source# files, must refer to those files by their `Source#` macro name, and must not use `$RPM_SOURCE_DIR` or `%{sourcedir}` to refer to those files. See link:RPM_Source_Dir.html[RPM Source Dir] for full details.
 
 [[software-collection-macros]]
 Software Collection Macros

From b3c84927c3eb293008f75555243a68662b4d079f Mon Sep 17 00:00:00 2001
From: Zbigniew Jędrzejewski-Szmek 
Date: Apr 15 2018 10:50:48 +0000
Subject: [PATCH 3555/3559] ada: formatting fixes


---

diff --git a/packaging/Ada.adoc b/packaging/Ada.adoc
index d2156d9..35063be 100644
--- a/packaging/Ada.adoc
+++ b/packaging/Ada.adoc
@@ -1,3 +1,5 @@
+:source-highlighter: pygments
+
 = Packaging Ada programs and libraries
 
 This document describes the current policies for packaging Ada programs and libraries for Fedora. These are Ada-specific amendments to the generic Packaging Guidelines. Ada packages must also conform to the link:Guidelines.html[Packaging Guidelines] and the link:ReviewGuidelines.html[Review Guidelines].
@@ -12,6 +14,7 @@ Compilation
 ** In case a package's build system invokes the underlying GNAT tools without using `Gnatmake` or `GPRbuild`, then the appropriate macro for each tool *MUST* be used. If for example Gnatlink is invoked directly, then the expansion of Gnatlink_flags shall be passed to it.
 ** For packages whose build systems use `Comfignat` there is the macro `%Comfignat_make`. It expands to a Make command with appropriate values for `Comfignat`'s configuration variables, including builder, compiler and linker flags, directory variables and the directories project. Use it alone to build the default target:
 +
+[source,spec]
 ....
 %build
 %{Comfignat_make}

From 641c5db13e3c1a7ccdd2b94570e760b68edf0699 Mon Sep 17 00:00:00 2001
From: Zbigniew Jędrzejewski-Szmek 
Date: Apr 15 2018 10:51:57 +0000
Subject: [PATCH 3556/3559] python: formatting fixes


---

diff --git a/packaging/Python.adoc b/packaging/Python.adoc
index a9a8a22..95ca68b 100644
--- a/packaging/Python.adoc
+++ b/packaging/Python.adoc
@@ -1,5 +1,8 @@
 :source-highlighter: pygments
 
+[[python]]
+= Python
+
 [[python-version-support]]
 Python Version Support
 ~~~~~~~~~~~~~~~~~~~~~~
@@ -113,7 +116,7 @@ The following macros are defined for you in all supported Fedora and EPEL releas
 |python3_sitearch |/usr/lib64/python3.X/site-packages on x86_64 +
 /usr/lib/python3.X/site-packages on x86 |Where python3 extension modules that are compiled C are installed
 |py3_dist |(Lua script) |Given a standardized name (i.e. dist name, name on PyPI) of Python software, it will convert it to a canonical format, and evaluates to `python3dist(CANONICAL_NAME)`, which is useful when listing dependencies. See <> for more information.
-|py_byte_compile |(script) |Defined in python3-devel. See the Packaging:Python_Appendix#Manual_byte_compilation[byte compiling] section for usage
+|py_byte_compile |(script) |Defined in python3-devel. See the <> section for usage
 |python3_version |3.X |Defined in python3-devel. Useful when running programs with Python version in filename, such as nosetest-%\{python3_version}
 |python3_version_nodots |3X |Defined in python3-devel. Useful when listing files explicitly in %files section , such as %\{python3_sitelib}/foo/*.cpython-%\{python3_version_nodots}.pyo
 |py_dist_name |(Lua script) |Given a standardized name (i.e. dist name, name on PyPI) of Python software, it will convert it to a canonical format. See <> for more information.
@@ -190,7 +193,7 @@ Similarly, any `.pyo` shipped in a Fedora package for python < 3.5 *must not* ha
 Manual byte compilation
 ^^^^^^^^^^^^^^^^^^^^^^^
 
-For more details on the internals of byte compilation, please see Packaging:Python_Appendix#Manual_byte_compilation[the appendix].
+For more details on the internals of byte compilation, please see <>.
 
 [[common-srpm-vs-split-srpms]]
 Common SRPM vs split SRPMs
@@ -209,7 +212,7 @@ because the build products for different versions of Python usually do not confl
 There are cases where it is not possible to build in a single directory. Most
 commonly this happens when the sources are modified during the build process to
 convert them from python2 to python3 using the the `2to3` tool. In
-that case, please see Packaging:Python_Appendix#Using_separate_build_directories[the appendix].
+that case, please see <>.
 
 As you can see in the `%install` section below, the order in which
 you do the python2 versus python3 install can sometimes matter. You need to be
@@ -364,7 +367,8 @@ See http://lists.fedoraproject.org/pipermail/devel/2010-January/129217.html[this
 Packaging eggs
 ~~~~~~~~~~~~~~
 
-Please see the link:Python_Eggs.html[Python Eggs] information specific to Python eggs.
+Please see the <> information specific to Python eggs.
+<>
 
 [[reviewer-checklist]]
 Reviewer checklist
@@ -374,7 +378,7 @@ The following briefly summarizes the guidelines for reviewers to go over:
 
 * *Must*: If you build for more than one python runtime you must use the `%python_provide` macro.
 * *Must*: If you build for a single python runtime you must add `%python_provide python-$module` so that the current default python is provided from the unversioned python package.
-* *Must*: Python modules must be built from source. They cannot simply drop an egg from upstream into the proper directory. (See Packaging:Guidelines#No_inclusion_of_pre-built_binaries_or_libraries[ prebuilt binaries Guidelines] for details)
+* *Must*: Python modules must be built from source. They cannot simply drop an egg from upstream into the proper directory. (See <> for details)
 * *Must*: Python modules must not download any dependencies during the build process.
 * *Must*: When building a compat package, it must install using easy_install -m so it won't conflict with the main package.
 * *Must*: When building multiple versions (for a compat package) one of the packages must contain a default version that is usable via "import MODULE" with no prior setup.
diff --git a/packaging/Python_Eggs.adoc b/packaging/Python_Eggs.adoc
index 3310c38..953e55c 100644
--- a/packaging/Python_Eggs.adoc
+++ b/packaging/Python_Eggs.adoc
@@ -1,3 +1,6 @@
+[[python-eggs]]
+= Python Eggs
+
 Python packages provide extra metadata about the package in the form of egg metadata. This document explains how to package those metadata.
 
 [[why-eggs]]

From 919521d2ef27c91e80453745acfaefb62a844fc3 Mon Sep 17 00:00:00 2001
From: Zbigniew Jędrzejewski-Szmek 
Date: Apr 15 2018 10:51:58 +0000
Subject: [PATCH 3557/3559] Remove all REDIRECT pages


$ git rm $(git grep -e REDIRECT -l)

---

diff --git a/_topic_map.yml b/_topic_map.yml
index 345f6b8..bc865fa 100644
--- a/_topic_map.yml
+++ b/_topic_map.yml
@@ -42,21 +42,12 @@ Topics:
   - Name: AutoProvidesAndRequiresFiltering
     File: AutoProvidesAndRequiresFiltering.adoc
 
-  - Name: Bundled_Libraries
-    File: Bundled_Libraries.adoc
-
-  - Name: Bundled_Libraries_Virtual_Provides
-    File: Bundled_Libraries_Virtual_Provides.adoc
-
   - Name: C_and_C++
     File: C_and_C++.adoc
 
   - Name: Cmake
     File: Cmake.adoc
 
-  - Name: Committee
-    File: Committee.adoc
-
   - Name: Conflicts
     File: Conflicts.adoc
 
@@ -99,9 +90,6 @@ Topics:
   - Name: EnvironmentModules
     File: EnvironmentModules.adoc
 
-  - Name: EPEL
-    File: EPEL.adoc
-
   - Name: FontsPolicy
     File: FontsPolicy.adoc
 
@@ -111,9 +99,6 @@ Topics:
   - Name: Fortran
     File: Fortran.adoc
 
-  - Name: FrequentlyMadeMistakes
-    File: FrequentlyMadeMistakes.adoc
-
   - Name: FullExceptionList
     File: FullExceptionList.adoc
 
@@ -126,9 +111,6 @@ Topics:
   - Name: Globus
     File: Globus.adoc
 
-  - Name: Guidelines:Systemd
-    File: Guidelines:Systemd.adoc
-
   - Name: GuidelinesTodo
     File: GuidelinesTodo.adoc
 
@@ -156,9 +138,6 @@ Topics:
   - Name: LibreOfficeExtensions
     File: LibreOfficeExtensions.adoc
 
-  - Name: LibreOfficeExtentions
-    File: LibreOfficeExtentions.adoc
-
   - Name: LicensingGuidelines
     File: LicensingGuidelines.adoc
 
@@ -171,9 +150,6 @@ Topics:
   - Name: MinGW
     File: MinGW.adoc
 
-  - Name: MinGW_Future
-    File: MinGW_Future.adoc
-
   - Name: Mono
     File: Mono.adoc
 
@@ -183,15 +159,6 @@ Topics:
   - Name: Naming
     File: Naming.adoc
 
-  - Name: NamingGuidelines
-    File: NamingGuidelines.adoc
-
-  - Name: NewMeetingTime
-    File: NewMeetingTime.adoc
-
-  - Name: No_Bundled_Libraries
-    File: No_Bundled_Libraries.adoc
-
   - Name: Node.js
     File: Node.js.adoc
 
@@ -201,9 +168,6 @@ Topics:
   - Name: Octave
     File: Octave.adoc
 
-  - Name: OldJPackagePolicy
-    File: OldJPackagePolicy.adoc
-
   - Name: Old_Ruby
     File: Old_Ruby.adoc
 
@@ -228,24 +192,15 @@ Topics:
   - Name: PreupgradeAssistant
     File: PreupgradeAssistant.adoc
 
-  - Name: Python Eggs
-    File: Python%2FEggs.adoc
-
   - Name: Python
     File: Python.adoc
 
   - Name: Python_Appendix
     File: Python_Appendix.adoc
 
-  - Name: PythonAppendix
-    File: PythonAppendix.adoc
-
   - Name: Python_Eggs
     File: Python_Eggs.adoc
 
-  - Name: Python_F21
-    File: Python_F21.adoc
-
   - Name: Python_Old
     File: Python_Old.adoc
 
@@ -270,9 +225,6 @@ Topics:
   - Name: Scriptlets
     File: Scriptlets.adoc
 
-  - Name: ScriptletSnippets
-    File: ScriptletSnippets.adoc
-
   - Name: SourceURL
     File: SourceURL.adoc
 
@@ -285,9 +237,6 @@ Topics:
   - Name: Systemd
     File: Systemd.adoc
 
-  - Name: SysVInitScript
-    File: SysVInitScript.adoc
-
   - Name: Tcl
     File: Tcl.adoc
 
diff --git a/packaging/Bundled_Libraries.adoc b/packaging/Bundled_Libraries.adoc
deleted file mode 100644
index 6087270..0000000
--- a/packaging/Bundled_Libraries.adoc
+++ /dev/null
@@ -1 +0,0 @@
-1.  REDIRECT link:Bundled_Libraries[Bundled Libraries]
diff --git a/packaging/Bundled_Libraries_Virtual_Provides.adoc b/packaging/Bundled_Libraries_Virtual_Provides.adoc
deleted file mode 100644
index f6db1c4..0000000
--- a/packaging/Bundled_Libraries_Virtual_Provides.adoc
+++ /dev/null
@@ -1 +0,0 @@
-1.  REDIRECT link:Bundled_Libraries_Virtual_Provides[Bundled Libraries Virtual Provides]
diff --git a/packaging/Committee.adoc b/packaging/Committee.adoc
deleted file mode 100644
index 6d568f6..0000000
--- a/packaging/Committee.adoc
+++ /dev/null
@@ -1 +0,0 @@
-1.  REDIRECT link:Packaging_Committee[Packaging Committee]
diff --git a/packaging/EPEL.adoc b/packaging/EPEL.adoc
deleted file mode 100644
index e0cfe66..0000000
--- a/packaging/EPEL.adoc
+++ /dev/null
@@ -1 +0,0 @@
-1.  REDIRECT EPEL:Packaging
diff --git a/packaging/FrequentlyMadeMistakes.adoc b/packaging/FrequentlyMadeMistakes.adoc
deleted file mode 100644
index b86c253..0000000
--- a/packaging/FrequentlyMadeMistakes.adoc
+++ /dev/null
@@ -1 +0,0 @@
-1.  REDIRECT FrequentlyMadePackagingMistakes
diff --git a/packaging/Guidelines:Systemd.adoc b/packaging/Guidelines:Systemd.adoc
deleted file mode 100644
index 60b71c5..0000000
--- a/packaging/Guidelines:Systemd.adoc
+++ /dev/null
@@ -1 +0,0 @@
-1.  REDIRECT Packaging:Systemd
diff --git a/packaging/LibreOfficeExtentions.adoc b/packaging/LibreOfficeExtentions.adoc
deleted file mode 100644
index 6f9670a..0000000
--- a/packaging/LibreOfficeExtentions.adoc
+++ /dev/null
@@ -1 +0,0 @@
-1.  REDIRECT Packaging:LibreOfficeExtensions
diff --git a/packaging/MinGW_Future.adoc b/packaging/MinGW_Future.adoc
deleted file mode 100644
index 319c00f..0000000
--- a/packaging/MinGW_Future.adoc
+++ /dev/null
@@ -1 +0,0 @@
-1.  REDIRECT Packaging:MinGW
diff --git a/packaging/NamingGuidelines.adoc b/packaging/NamingGuidelines.adoc
deleted file mode 100644
index c7c1962..0000000
--- a/packaging/NamingGuidelines.adoc
+++ /dev/null
@@ -1 +0,0 @@
-1.  REDIRECT Packaging:Naming
diff --git a/packaging/NewMeetingTime.adoc b/packaging/NewMeetingTime.adoc
deleted file mode 100644
index 556ea64..0000000
--- a/packaging/NewMeetingTime.adoc
+++ /dev/null
@@ -1 +0,0 @@
-1.  REDIRECT Archive:Packaging:NewMeetingTime
diff --git a/packaging/No_Bundled_Libraries.adoc b/packaging/No_Bundled_Libraries.adoc
deleted file mode 100644
index f4f2f5a..0000000
--- a/packaging/No_Bundled_Libraries.adoc
+++ /dev/null
@@ -1 +0,0 @@
-1.  REDIRECT Packaging:Bundled_Libraries[Packaging:Bundled Libraries]
diff --git a/packaging/OldJPackagePolicy.adoc b/packaging/OldJPackagePolicy.adoc
deleted file mode 100644
index e5ff4ea..0000000
--- a/packaging/OldJPackagePolicy.adoc
+++ /dev/null
@@ -1 +0,0 @@
-1.  REDIRECT Archive:Packaging:OldJPackagePolicy
diff --git a/packaging/Python%2FEggs.adoc b/packaging/Python%2FEggs.adoc
deleted file mode 100644
index 52be02f..0000000
--- a/packaging/Python%2FEggs.adoc
+++ /dev/null
@@ -1 +0,0 @@
-1.  REDIRECT Packaging:Python_Eggs[Packaging:Python Eggs]
diff --git a/packaging/PythonAppendix.adoc b/packaging/PythonAppendix.adoc
deleted file mode 100644
index 9f1fc1b..0000000
--- a/packaging/PythonAppendix.adoc
+++ /dev/null
@@ -1 +0,0 @@
-1.  REDIRECT Packaging:Python_Appendix[Packaging:Python Appendix]
diff --git a/packaging/Python_F21.adoc b/packaging/Python_F21.adoc
deleted file mode 100644
index 69b9997..0000000
--- a/packaging/Python_F21.adoc
+++ /dev/null
@@ -1 +0,0 @@
-1.  REDIRECT Packaging:Python_Old[Packaging:Python Old]
diff --git a/packaging/ScriptletSnippets.adoc b/packaging/ScriptletSnippets.adoc
deleted file mode 100644
index b55b4a5..0000000
--- a/packaging/ScriptletSnippets.adoc
+++ /dev/null
@@ -1 +0,0 @@
-1.  REDIRECT Packaging:Scriptlets
diff --git a/packaging/SysVInitScript.adoc b/packaging/SysVInitScript.adoc
deleted file mode 100644
index 9b68260..0000000
--- a/packaging/SysVInitScript.adoc
+++ /dev/null
@@ -1 +0,0 @@
-1.  REDIRECT EPEL:SysVInitScripts

From 2bff80c15bb13d8a1552f5ab3ab297a7ab8ef917 Mon Sep 17 00:00:00 2001
From: Zbigniew Jędrzejewski-Szmek 
Date: Apr 15 2018 10:51:58 +0000
Subject: [PATCH 3558/3559] guidelines: formatting fixes


---

diff --git a/packaging/Guidelines.adoc b/packaging/Guidelines.adoc
index 40e95ff..3c712ba 100644
--- a/packaging/Guidelines.adoc
+++ b/packaging/Guidelines.adoc
@@ -1,8 +1,10 @@
+= Fedora Packaging Guidelines
+
 The Packaging Guidelines are a collection of common issues and the severity that should be placed on them. While these guidelines should not be ignored, they should also not be blindly followed. If you think that your package should be exempt from part of the Guidelines, please bring the issue to the https://pagure.io/packaging-committee/[Fedora Packaging Committee].
 
 It is the package reviewer's responsibility to point out specific problems with a package and a packager's responsibility to deal with those issues. The reviewer and packager work together to determine the severity of the issues (whether they block a package or can be worked on after the package is in the repository.) Please remember that any package that you submit must also conform to the link:ReviewGuidelines.html[Review Guidelines].
 
-The original author of these documents is link:TomCallaway[ Tom 'spot' Callaway], though they were originally based on many other documents. They have been significantly modified over the years by many members of the Packaging Committee.
+The original author of these documents is https://fedoraproject.org/wiki/User:Spot[Tom 'spot' Callaway], though they were originally based on many other documents. They have been significantly modified over the years by many members of the Packaging Committee.
 
 Report issues with these guidelines, including typos, https://pagure.io/packaging-committee[here]. The wiki discussion pages are not read by the Committee.
 
@@ -22,13 +24,13 @@ As these guidelines can never cover all possible contingencies, there will alway
 
 If, in a guideline, the language "should" or "is suggested" is used and it is not feasible for the package to conform to that guideline, the packager may deviate from the it. The nature of the deviation and the reasoning behind it MUST be documented in the specfile.
 
-Where the language "must", "is required to" or "needs to" is used, the packager may deviate from the guideline only with approval from the packaging committee. Please follow the procedure at ​the link:Packaging_Committee#Bringing_Issues_to_the_Committee[Packaging Committee] page for making these requests.
+Where the language "must", "is required to" or "needs to" is used, the packager may deviate from the guideline only with approval from the packaging committee. Please follow the procedure at the link:https://fedoraproject.org/wiki/Packaging_Committee#Bringing_Issues_to_the_Committee[Packaging Committee] page for making these requests.
 
 [[naming]]
 Naming
 ~~~~~~
 
-You should go through the link:NamingGuidelines.html[Naming Guidelines] to ensure that your package is named appropriately.
+You should go through the link:Naming.html[Naming Guidelines] to ensure that your package is named appropriately.
 
 [[version-and-release]]
 Version and Release
@@ -47,7 +49,7 @@ There are various legal concerns to consider when packaging for Fedora.
 Licensing
 ^^^^^^^^^
 
-You should review Licensing:Main and the link:LicensingGuidelines.html[Licensing Guidelines] to ensure that your package is licensed appropriately.
+You should review link:https://fedoraproject.org/wiki/Licensing:Main and the link:LicensingGuidelines.html[Licensing Guidelines] to ensure that your package is licensed appropriately.
 
 [[code-vs-content]]
 Code Vs Content
@@ -99,7 +101,7 @@ No External Kernel Modules
 
 At one point (pre Fedora 8), packages containing "addon" kernel modules were permitted. This is no longer the case. Fedora strongly encourages kernel module packagers to submit their code into the upstream kernel tree.
 
-The reference documentation on how to package kernel modules in the "kmod" style has been preserved link:Obsolete/KernelModules[here] .
+The reference documentation on how to package kernel modules in the "kmod" style has been preserved link:https://fedoraproject.org/wiki/Obsolete/KernelModules[here].
 
 [[no-inclusion-of-pre-built-binaries-or-libraries]]
 No inclusion of pre-built binaries or libraries
@@ -110,19 +112,19 @@ All program binaries and program libraries included in Fedora packages must be b
 * Security: Pre-packaged program binaries and program libraries not built from the source code could contain parts that are malicious, dangerous, or just broken. Also, these are functionally impossible to patch.
 * Compiler Flags: Pre-packaged program binaries and program libraries not built from the source code were probably not compiled with standard Fedora compiler flags for security and optimization.
 
-Content binaries (such as .pdf, .png, .ps files) are _not_ required to be rebuilt from the source code.
+Content binaries (such as `.pdf`, `.png`, `.ps` files) are _not_ required to be rebuilt from the source code.
 
 If you are in doubt as to whether something is considered a program binary or a program library, here is some helpful criteria:
 
 * Is it executable? If so, it is probably a program binary.
-* Does it contain a .so, ,so.#, or .so.#.#.# extension? If so, it is probably a program library.
+* Does it contain a `+.so+`, `+so.#+`, or `+.so.#.#.#+` extension? If so, it is probably a program library.
 * If in doubt, ask your reviewer. If the reviewer is not sure, they should ask the Fedora Packaging Committee.
 
 Packages which require non-open source components to build are also not permitted (e.g. proprietary compiler required).
 
 When you encounter prebuilt binaries in a package you *MUST*:
 
-* Remove all pre-built program binaries and program libraries in %prep prior to the building of the package. Examples include, but are not limited to, *.class, *.dll, *.DS_Store, *.exe, *.jar, *.o, *.pyc, *.pyo, *.egg, *.so, *.swf files.
+* Remove all pre-built program binaries and program libraries in `%prep` prior to the building of the package. Examples include, but are not limited to, `+*.class+`, `+*.dll+`, `+*.DS_Store+`, `+*.exe+`, `+*.jar+`, `+*.o+`, `+*.pyc+`, `+*.pyo+`, `+*.egg+`, `+*.so+`, `+*.swf+` files.
 * Ask upstream to remove the binaries in their next release.
 
 [[exceptions]]
@@ -130,8 +132,8 @@ Exceptions
 ^^^^^^^^^^
 
 * Some software (usually related to compilers or cross-compiler environments) cannot be built without the use of a previous toolchain or development environment (open source). If you have a package which meets this criteria, contact the Fedora Packaging Committee for approval. Please note that this exception, if granted, is limited to only the initial build of the package. You may bootstrap this build with a "bootstrap" pre-built binary, but after this is complete, you must immediately increment Release, drop the "bootstrap" pre-built binary, and build completely from source. Bootstrapped packages containing pre-built "bootstrap" binaries must not be pushed as release packages or updates under any circumstances. These packages should contain the necessary logic to be built once bootstrapping is completed and the prebuilt programs are no longer needed. Information about how you should break circular dependencies by bootstrapping can be found here: <>.
-* An exception is made for binary firmware, as long as it meets the requirements documented here: Licensing:Main#Binary_Firmware
-* Some pre-packaged program binaries or program libraries may be under terms which do not permit redistribution, or be affected by legal scenarios such as patents. In such situations, simply deleting these files in %prep is not sufficient, the maintainer will need to make a modified source that does not contain these files. See: link:SourceURL#when-upstream-uses-prohibited-code[Source URL].
+* An exception is made for binary firmware, as long as it meets the requirements documented here: link:https://fedoraproject.org/wiki/Licensing:Main#Binary_Firmware[Binary Firmware]
+* Some pre-packaged program binaries or program libraries may be under terms which do not permit redistribution, or be affected by legal scenarios such as patents. In such situations, simply deleting these files in %prep is not sufficient, the maintainer will need to make a modified source that does not contain these files. See: link:SourceURL.html#when-upstream-uses-prohibited-code.html[Source URL].
 
 [[use-of-pregenerated-code]]
 Use of pregenerated code
@@ -159,8 +161,8 @@ may include applications, so the distinction is not always clear.
 Library or Application?
 ^^^^^^^^^^^^^^^^^^^^^^^
 
-* If the primary purpose of a package is to provide executables to be run by users, it SHOULD be packaged as an application. If it also includes libraries which may be imported or linked to by other code, see link:#Mixed_Use_Packages[#Mixed Use Packages] below.
-* If the primary purpose of a package is to provide libraries intended to be imported or loaded into other code, it is considered a library and MUST be packaged as such. If it contains utility programs that can be run by users as well, see link:#Mixed_Use_Packages[#Mixed Use Packages] below.
+* If the primary purpose of a package is to provide executables to be run by users, it SHOULD be packaged as an application. If it also includes libraries which may be imported or linked to by other code, see link:#mixed-use-packages[Mixed Use Packages] below.
+* If the primary purpose of a package is to provide libraries intended to be imported or loaded into other code, it is considered a library and MUST be packaged as such. If it contains utility programs that can be run by users as well, see link:#mixed-use-packages[Mixed Use Packages] below.
 
 It is left to the packager to determine the primary purpose of a
 package. Often times upstream will already have done this with their
@@ -206,13 +208,13 @@ To help facilitate legibility, only macros and conditionals for Fedora and EPEL 
 Spec file Encoding
 ^^^^^^^^^^^^^^^^^^
 
-Unless you need to use characters outside the http://commons.wikimedia.org/wiki/Image:Ascii_full.png[ASCII repertoire] , you will not need to be concerned about the encoding of the spec file. If you do need non-ASCII characters, save your spec files as UTF-8. If you're in doubt as to what characters are ASCII, please refer to http://commons.wikimedia.org/wiki/Image:Ascii_full.png[this chart] .
+Unless you need to use characters outside the http://commons.wikimedia.org/wiki/Image:Ascii_full.png[ASCII repertoire], you will not need to be concerned about the encoding of the spec file. If you do need non-ASCII characters, save your spec files as UTF-8. If you're in doubt as to what characters are ASCII, please refer to http://commons.wikimedia.org/wiki/Image:Ascii_full.png[this chart].
 
 [[non-ascii-filenames]]
 Non-ASCII Filenames
 +++++++++++++++++++
 
-Similarly, filenames that contain non-ASCII characters must be encoded as UTF-8. Since there's no way to note which encoding the filename is in, using the same encoding for all filenames is the best way to ensure users can read the filenames properly. If upstream ships filenames that are not encoded in UTF-8 you can use a utility like convmv (from the convmv package) to convert the filename in your %install section.
+Similarly, filenames that contain non-ASCII characters must be encoded as UTF-8. Since there's no way to note which encoding the filename is in, using the same encoding for all filenames is the best way to ensure users can read the filenames properly. If upstream ships filenames that are not encoded in UTF-8 you can use a utility like `convmv` (from the convmv package) to convert the filename in your `%install` section.
 
 [[spec-maintenance-and-canonicity]]
 Spec Maintenance and Canonicity
@@ -224,7 +226,7 @@ Fedora's git repository is the canonical location for Fedora spec files. Maintai
 Architecture Support
 ~~~~~~~~~~~~~~~~~~~~
 
-All Fedora packages must successfully compile and build into binary rpms on at least one supported primary architecture, except where the package is useful only on a secondary architecture (such as an architecture-specific boot utility, microcode loader, or hardware configuration tool). Fedora packagers should make every effort to support all link:Architectures#Primary_Architectures[primary architectures].
+All Fedora packages must successfully compile and build into binary rpms on at least one supported primary architecture, except where the package is useful only on a secondary architecture (such as an architecture-specific boot utility, microcode loader, or hardware configuration tool). Fedora packagers should make every effort to support all link:https://fedoraproject.org/wiki/Architectures#Primary_Architectures[primary architectures].
 
 Content, code which does not need to compile or build, and architecture independent code (noarch) are notable exceptions.
 
@@ -369,7 +371,7 @@ Limited usage of /opt, /etc/opt, and /var/opt
 
 `/opt` and its related directories (`/etc/opt` and `/var/opt`) is reserved for the use of vendors in the FHS. We have reserved the `fedora` name with http://www.lanana.org/lsbreg/providers/providers.txt[LANANA] for our use. If a package installs files into `/opt` it may only use directories in the `/opt/fedora` hierarchy. Fedora attempts to organize this directory by allocating a subdirectory of our `/opt/fedora` directory for specific subsystems. If you think you need to use `/opt/fedora` please file an FPC ticket to decide whether it's a valid use of `/opt` and what subdirectory should be allocated for your use.
 
-Currently, we have allocated `/opt/fedora/scls`, `/etc/opt/fedora/scls`, and `/var/opt/fedora/scls` for use by User:Toshio/SCL_Guidelines_(draft)[ Software Collections].
+Currently, we have allocated `/opt/fedora/scls`, `/etc/opt/fedora/scls`, and `/var/opt/fedora/scls` for use by link:https://fedoraproject.org/wiki/User:Toshio/SCL_Guidelines_(draft)[Software Collections].
 
 [[effect-of-the-usrmove-fedora-feature]]
 Effect of the UsrMove Fedora Feature
@@ -377,21 +379,13 @@ Effect of the UsrMove Fedora Feature
 
 Fedora has merged several directories in `/` with their counterparts in `/usr/`.
 
-/bin
-
-/usr/bin aka %\{_bindir}
-
-/sbin
-
-/usr/sbin aka %\{_sbindir}
-
-/lib64 or /lib
-
-/usr/lib64 or /usr/lib aka %\{_libdir}
-
-/lib
-
-/usr/lib aka %\{_prefix}/lib
+|===============================================================
+|`/bin`             | `/usr/bin` aka `%{_bindir}`
+|`/sbin`            | `/usr/sbin` aka `%{_sbindir}`
+|`/lib64` or `/lib/usr/lib64` or `/usr/lib` aka `%{_libdir}`
+|`/lib` or `/usr/lib` aka `%{_prefix}/lib`
+|===============================================================
+XXX: I know this table makes no sense. It just doesn't.
 
 For example, end users will find that `/bin/sh` is the same file as `/usr/bin/sh`.
 
@@ -444,7 +438,7 @@ All package dependencies (build-time or runtime, regular, weak or otherwise) MUS
 
 RPM can automatically determine dependencies for most compiled libraries and for some scripting languages such as Perl. Automatically determined dependencies MUST NOT be duplicated by manual dependencies.
 
-Build dependencies, however, cannot be automatically determined and MUST be explicitly listed. Refer to the <> section.
+Build dependencies, however, cannot be automatically determined and MUST be explicitly listed. Refer to the <> section.
 
 Versioned dependencies (build-time or runtime) SHOULD ONLY be used when actually necessary to guarantee that the proper version of a package is present. If a versioned dependency would be satisfied by a version present in three previous Fedora releases then the then a versioned dependency is not needed and a regular unversioned dependency SHOULD be used instead.
 
@@ -454,7 +448,7 @@ A versioned dependency on a package with a defined Epoch MUST be included in tha
 Architecture-specific Dependencies
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-A dependency is made arch-specific by appending the macro %\{?_isa} to the package name. For example:
+A dependency is made arch-specific by appending the macro `%{?_isa}` to the package name. For example:
 
 ....
 Requires: foo
@@ -466,7 +460,7 @@ becomes:
 Requires: foo%{?_isa}
 ....
 
-If the foo-devel package has a foo-config script, you can try doing a foo-config --libs and foo-config --cflags to get strong hints what packages should be marked as foo's requirements. For example:
+If the foo-devel package has a `foo-config` script, you can try doing a `foo-config --libs` and `foo-config --cflags` to get strong hints what packages should be marked as foo's requirements. For example:
 
 ....
 $ gtk-config --cflags
@@ -477,7 +471,9 @@ $ gtk-config --libs
 
 This means that gtk+-devel should contain
 
-`Requires: glib-devel%{?_isa} libXi-devel%{?_isa} libXext-devel%{?_isa} libX11-devel%{?_isa}`
+....
+Requires: glib-devel%{?_isa} libXi-devel%{?_isa} libXext-devel%{?_isa} libX11-devel%{?_isa}
+....
 
 [[weak-dependencies]]
 Weak dependencies
@@ -523,17 +519,17 @@ Packagers should revisit an explicit dependency as appropriate to avoid it becom
 Filtering Auto-Generated Requires
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-RPM attempts to auto-generate Requires (and Provides) at build time, but in some situations, the auto-generated Requires/Provides are not correct or not wanted. For more details on how to filter out auto-generated Requires or Provides, please see: link:AutoProvidesAndRequiresFiltering[Auto Provides and Requires Filtering].
+RPM attempts to auto-generate Requires (and Provides) at build time, but in some situations, the auto-generated Requires/Provides are not correct or not wanted. For more details on how to filter out auto-generated Requires or Provides, please see: link:AutoProvidesAndRequiresFiltering.html[Auto Provides and Requires Filtering].
 
-[[build-time-dependencies-buildrequires]]
+[[buildrequires]]
 Build-Time Dependencies (BuildRequires)
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 It is important that your package list all necessary build dependencies using the `BuildRequires:` tag. You MAY assume that enough of an environment exists for RPM to function, to build packages and execute basic shell scripts, but you SHOULD NOT assume any other packages are present as RPM dependencies and anything brought into the buildroot by the build system can change over time.
 
 [[buildrequires-and-_isa]]
-BuildRequires and %\{_isa}
-^^^^^^^^^^^^^^^^^^^^^^^^^^
+BuildRequires and `%{_isa}`
+^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 You MUST NOT use arched BuildRequires. The arch ends up in the built SRPM but SRPMs need to be architecture independent. For instance, if you did this:
 
@@ -568,7 +564,7 @@ If the spec file contains conditional dependencies selected based on presence of
 Summary and description
 ~~~~~~~~~~~~~~~~~~~~~~~
 
-The summary should be a short and concise description of the package. The description expands upon this. Do not include installation instructions in the description; it is not a manual. If the package requires some manual configuration or there are other important instructions to the user, refer the user to the documentation in the package. Add a _README.Fedora_, or similar, if you feel this is necessary. Also, please make sure that there are no lines in the description longer than 80 characters.
+The summary should be a short and concise description of the package. The description expands upon this. Do not include installation instructions in the description; it is not a manual. If the package requires some manual configuration or there are other important instructions to the user, refer the user to the documentation in the package. Add a `README.Fedora`, or similar, if you feel this is necessary. Also, please make sure that there are no lines in the description longer than 80 characters.
 
 Please put personal preferences aside and use American English spelling in the summary and description. Packages can contain additional translated summary/description for supported Non-English languages, if available.
 
@@ -593,15 +589,15 @@ If you're not sure, ask yourself, is there any chance someone may get confused a
 Documentation
 ~~~~~~~~~~~~~
 
-Any relevant documentation included in the source distribution should be included in the package in the proper documentation directory. Irrelevant documentation includes build instructions, the omnipresent _INSTALL_ file containing generic build instructions, for example, and documentation for non-Linux systems, e.g. _README.MSDOS_. Also pay attention about which subpackage you include documentation in. For example API documentation belongs in the `-devel` subpackage, not the main one. Or if there's a lot of documentation, consider putting it into a subpackage. In this case, it is recommended to use `*-doc` as the subpackage name.
+Any relevant documentation included in the source distribution should be included in the package in the proper documentation directory. Irrelevant documentation includes build instructions, the omnipresent `INSTALL` file containing generic build instructions, for example, and documentation for non-Linux systems, e.g. `README.MSDOS`. Also pay attention about which subpackage you include documentation in. For example API documentation belongs in the `-devel` subpackage, not the main one. Or if there's a lot of documentation, consider putting it into a subpackage. In this case, it is recommended to use `*-doc` as the subpackage name.
 
-Marking a _relative_ path with `%doc` in the `%files` section will cause RPM to copy the referenced file or directory from `%_builddir` to the proper location for documentation. Files can also be placed in `%_pkgdocdir`, and the build scripts of the software being packaged may do this automatically when called in `%install`. However, mixing these methods is problematic and may result in duplicated or conflicting files, so use of `%doc` with _relative_ paths and installation of files directly into `%_pkgdocdir` in the same source package is forbidden.
+Marking a _relative_ path with `%doc` in the `%files` section will cause RPM to copy the referenced file or directory from `+%_builddir+` to the proper location for documentation. Files can also be placed in `+%_pkgdocdir+`, and the build scripts of the software being packaged may do this automatically when called in `%install`. However, mixing these methods is problematic and may result in duplicated or conflicting files, so use of `%doc` with _relative_ paths and installation of files directly into `+%_pkgdocdir+` in the same source package is forbidden.
 
 Files marked as documentation must not cause the package to pull in more dependencies than it would without the documentation. One simple way to ensure this in most cases is to remove all executable permissions from files in `%_pkgdocdir`.
 
 Files located in `%_pkgdocdir` must not affect the runtime of the packaged software. The software must function properly and with unchanged functionality if those files are modified, removed or not installed at all.
 
-Although license files are documentation, they are treated specially (including using a different tag. Please see link:LicensingGuidelines.html[Licensing Guidelines] for how to handle them.
+Although license files are documentation, they are treated specially (including using a different tag). Please see link:LicensingGuidelines.html[Licensing Guidelines] for how to handle them.
 
 [[changelogs]]
 Changelogs
@@ -695,7 +691,7 @@ You can do this any number of times, until you actually build 1.0-1 in the build
 Manpages
 ~~~~~~~~
 
-As man pages are the traditional method of getting help on a Unix system, packages SHOULD contain them for all executables. If some man pages are absent, packagers SHOULD work with upstream to add them. It is also occasionally possible to find pages created by other distributions, or to use the output of the help2man program; those are often useful as a starting point. When installing man pages, note that they should be installed uncompressed as the build system will compress them as needed. The compression method may change, so it is important to reference the pages in the %files section with a pattern that takes this into account:
+As man pages are the traditional method of getting help on a Unix system, packages SHOULD contain them for all executables. If some man pages are absent, packagers SHOULD work with upstream to add them. It is also occasionally possible to find pages created by other distributions, or to use the output of the `help2man` program; those are often useful as a starting point. When installing man pages, note that they should be installed uncompressed as the build system will compress them as needed. The compression method may change, so it is important to reference the pages in the `%files` section with a pattern that takes this into account:
 
 ....
 %files
@@ -800,7 +796,7 @@ The placement of pkgconfig(.pc) files depends on their usecase. Since they are a
 Requiring Base Package
 ~~~~~~~~~~~~~~~~~~~~~~
 
-Subpackages are often extensions for their base package and in that case they should require their base package. It is almost always better to over specify the version, so it is best practice to just use a fully versioned dependency: Requires: %\{name}%\{?_isa} = %\{version}-%\{release}. Devel packages are an example of a package that must require their base packages using a fully versioned dependency. -libs subpackages which only contain shared libraries do not normally need to explicitly depend on %\{name}%\{?_isa} = %\{version}-%\{release}, as they usually do not need the base package to be functional libraries.
+Subpackages are often extensions for their base package and in that case they should require their base package. It is almost always better to over specify the version, so it is best practice to just use a fully versioned dependency: `+Requires: %{name}%{?_isa} = %{version}-%{release}+`. Devel packages are an example of a package that must require their base packages using a fully versioned dependency. `-libs` subpackages which only contain shared libraries do not normally need to explicitly depend on `+%{name}%{?_isa} = %{version}-%{release}+`, as they usually do not need the base package to be functional libraries.
 
 If you end up in a situation where the main package depends on the subpackage and the subpackage on the main package you should think carefully about why you don't have everything in the main package.
 
@@ -833,7 +829,7 @@ libfoobar.so.0.n
 The _n_ should initially be a small integer (for instance, "1"). we use two digits here ("0.n") because the common practice with upstreams is to use only a single digit here. Using multiple digits helps us avoid potential future conflicts. Do not forget to add the SONAME field (see below) to the library.
 
 When new versions of the library are released, you should use an
-link:How_to_check_for_ABI_changes_in_a_package[ABI comparison tool] to check for ABI differences in the built shared
+link:https://fedoraproject.org/wiki/How_to_check_for_ABI_changes_in_a_package[ABI comparison tool] to check for ABI differences in the built shared
 libraries. If it detects any incompatibilities, bump the _n_ number by one.
 
 [[soname-handling]]
@@ -846,7 +842,7 @@ object with which it should link. This allows developers to simply link against 
 unversioned library symlink and the dynamic linker will link against the
 correct object.
 
-Keep in mind that although the filename is usually the library's SONAME plus an incrementing minor version there's nothing that intrinsically links these. ldconfig uses the SONAME as the value for a symlink to the actual filename. The dynamic linker then uses that symlink to find the library, disregarding the actual filename. The dynamic linker merely does a simple equality check on the field and does not check for ABI incompatibilities or similar problems. This is the main reason for using an link:How_to_check_for_ABI_changes_in_a_package[ABI comparison tool] and incrementing the the SONAME.
+Keep in mind that although the filename is usually the library's SONAME plus an incrementing minor version there's nothing that intrinsically links these. ldconfig uses the SONAME as the value for a symlink to the actual filename. The dynamic linker then uses that symlink to find the library, disregarding the actual filename. The dynamic linker merely does a simple equality check on the field and does not check for ABI incompatibilities or similar problems. This is the main reason for using an link:https://fedoraproject.org/wiki/How_to_check_for_ABI_changes_in_a_package[ABI comparison tool] and incrementing the the SONAME.
 
 The SONAME field is written to the shared object by linker, using (at least in
 case of `ld`) the `-soname SONAME` flags. This can be
@@ -867,9 +863,9 @@ $ objdump -p /path/to/libfoo.so.0.n | grep 'SONAME'
 Packaging Static Libraries
 ~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-Packages including libraries SHOULD exclude static libs as far as possible (eg by configuring with _--disable-static_). Applications linking against libraries SHOULD link against shared libraries not static versions.
+Packages including libraries SHOULD exclude static libs as far as possible (eg by configuring with `--disable-static`). Applications linking against libraries SHOULD link against shared libraries not static versions.
 
-Libtool archives, _foo.la_ files, SHOULD NOT be included. Packages using libtool will install these by default even if you configure with _--disable-static_, so they may need to be removed before packaging. Due to bugs in older versions of libtool or bugs in programs that use it, there are times when it is not always possible to remove *.la files without modifying the program. In most cases it is fairly easy to work with upstream to fix these issues. Note that if you are updating a library in a stable release (not devel) and the package already contains *.la files, removing the *.la files SHOULD be treated as an API/ABI change -- ie: Removing them changes the interface that the library gives to the rest of the world thus MUST follow Fedora policies for potentially destabilizing updates.
+Libtool archives, `foo.la` files, SHOULD NOT be included. Packages using libtool will install these by default even if you configure with `--disable-static`, so they may need to be removed before packaging. Due to bugs in older versions of libtool or bugs in programs that use it, there are times when it is not always possible to remove `+*.la+` files without modifying the program. In most cases it is fairly easy to work with upstream to fix these issues. Note that if you are updating a library in a stable release (not devel) and the package already contains `+*.la+` files, removing the `+*.la+` files SHOULD be treated as an API/ABI change — ie: Removing them changes the interface that the library gives to the rest of the world thus MUST follow Fedora policies for potentially destabilizing updates.
 
 [[packaging-static-libraries-1]]
 Packaging Static Libraries
@@ -881,7 +877,6 @@ Packaging Static Libraries
 
 1.  *Static libraries and shared libraries.* In this case, the static libraries MUST be placed in a _*-static_ subpackage. Separating the static libraries from the other development files in _*-devel_ allow us to track this usage by checking which packages `BuildRequire` the _*-static_ package. The intent is that whenever possible, packages will move away from using these static libraries, to the shared libraries. If the _*-static_ subpackage requires headers or other files from _*-devel_ in order to be useful it MUST require the _*-devel_ subpackage.
 2.  *Static libraries only.* When a package only provides static libraries you MAY place all the static library files in the _*-devel_ subpackage. When doing this you also MUST have a virtual Provide for the _*-static_ package:
-
 ....
 %package devel
 Provides: foo-static = %{version}-%{release}
@@ -936,9 +931,9 @@ To indicate an instance of bundling, first determine the name and version of the
 
 * Use the link:Versioning.html[Versioning Guidelines] to determine an appropriate version for the library, if possible. If the library has been forked from an upstream, use the upstream version that was most recently merged in or rebased onto, or the version the original library carried at the time of the fork.
 
-Then at an appropriate place in your spec, add `Provides: bundled(``) = ` where and are the name and version you determined above. If it was not possible to determine a version, use `Provides: bundled(``)` instead.
+Then at an appropriate place in your spec, add `+Provides: bundled() = +` where `++` and `++` are the name and version you determined above. If it was not possible to determine a version, use `+Provides: bundled()+` instead.
 
-In addition to indicating bundling in this manner, packages whose upstreams have no mechanism to build against system libraries must be contacted publicly about a path to supporting system libraries. If upstream refuses, this must be recorded in the spec file, either in comments placed adjacent to the Provides: above, or in an additional file checked into the SCM and referenced by a comment placed adjacent to the `Provides:` above.
+In addition to indicating bundling in this manner, packages whose upstreams have no mechanism to build against system libraries must be contacted publicly about a path to supporting system libraries. If upstream refuses, this must be recorded in the spec file, either in comments placed adjacent to the `Provides:` above, or in an additional file checked into the SCM and referenced by a comment placed adjacent to the `Provides:` above.
 
 [[avoid-bundling-of-fonts-in-other-packages]]
 Avoid bundling of fonts in other packages
@@ -1016,13 +1011,13 @@ sed -i 's|^runpath_var=LD_RUN_PATH|runpath_var=DIE_RPATH_DIE|g' libtool
 ....
 
 * Sometimes, the code/Makefiles can be patched to remove the _-rpath_ or _-R_ flag from being called. This is not always easy or sane to do, however.
-* As a last resort, Fedora has a package called _chrpath_. When this package is installed, you can run `chrpath --delete` on the files which contain rpaths. So, in our earlier example, we'd run:
+* As a last resort, Fedora has a package called `chrpath`. When this package is installed, you can run `chrpath --delete` on the files which contain rpaths. So, in our earlier example, we'd run:
 
 ....
 chrpath --delete $RPM_BUILD_ROOT%{_bindir}/xapian-tcpsrv
 ....
 
-Make sure that you remember to add a *BuildRequires: chrpath* if you end up using this method.
+Make sure that you remember to add a `BuildRequires: chrpath` if you end up using this method.
 
 [[configuration-files]]
 Configuration files
@@ -1030,9 +1025,9 @@ Configuration files
 
 Configuration files must be marked as such in packages.
 
-As a rule of thumb, use `%config(noreplace)` instead of plain `%config` unless your best, educated guess is that doing so will break things. In other words, think hard before overwriting local changes in configuration files on package upgrades. An example case when /not/ to use `noreplace` is when a package's configuration file changes so that the new package revision wouldn't work with the config file from the previous package revision. Whenever plain `%config` is used, add a brief comment to the specfile explaining why.
+As a rule of thumb, use `%config(noreplace)` instead of plain `%config` unless your best, educated guess is that doing so will break things. In other words, think hard before overwriting local changes in configuration files on package upgrades. An example case when *not* to use `noreplace` is when a package's configuration file changes so that the new package revision wouldn't work with the config file from the previous package revision. Whenever plain `%config` is used, add a brief comment to the specfile explaining why.
 
-Don't use %config or %config(noreplace) under /usr. /usr is deemed to not contain configuration files in Fedora.
+Don't use `%config` or `%config(noreplace)` under `/usr`. `/usr` is deemed to not contain configuration files in Fedora.
 
 [[configuration-of-package-managers]]
 Configuration of Package Managers
@@ -1062,8 +1057,8 @@ Detailed guidelines for packaging systemd units and systemd-managed services are
 Desktop files
 ~~~~~~~~~~~~~
 
-If a package contains a GUI application, then it needs to also include a properly installed .desktop file. For the purposes of these guidelines, a GUI application is defined as any application which draws an X window and runs from within that window. Installed .desktop files MUST follow the http://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html[desktop-entry-spec] , paying particular attention to validating correct usage of Name, GenericName, http://standards.freedesktop.org/menu-spec/latest/apa.html[Categories] ,
-http://www.freedesktop.org/Standards/startup-notification-spec[StartupNotify]
+If a package contains a GUI application, then it needs to also include a properly installed .desktop file. For the purposes of these guidelines, a GUI application is defined as any application which draws an X window and runs from within that window. Installed .desktop files MUST follow the https://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html[desktop-entry-spec], paying particular attention to validating correct usage of Name, GenericName, https://standards.freedesktop.org/menu-spec/latest/apa.html[Categories],
+https://www.freedesktop.org/Standards/startup-notification-spec[StartupNotify]
 entries.
 
 [[icon-tag-in-desktop-files]]
@@ -1083,8 +1078,8 @@ The icon tag can be specified in two ways:
 The short name without file extension is preferred, because it allows for icon theming (it assumes .png by default, then tries .svg and finally .xpm), but either method is acceptable.
 
 [[desktop-file-creation]]
-.desktop file creation
-^^^^^^^^^^^^^^^^^^^^^^
++.desktop+ file creation
+^^^^^^^^^^^^^^^^^^^^^^^^
 
 If the package doesn't already include and install its own .desktop file, you need to make your own. You can do this by including a .desktop file you create as a Source: (e.g. Source3: %\{name}.desktop) or generating it in the spec file. Here are the contents of a sample .desktop file (comical.desktop):
 
@@ -1142,7 +1137,7 @@ Packagers are strongly encouraged to use macros instead of hard-coded directory 
 * The package must be consistent. For any given path, within the same spec, use either a hard-coded path or a macro, not a combination of the two.
 * %\{_libdir} must always be used for binary libraries due to multi-lib, you may not substitute a hard-coded path.
 
-Macro forms of system executables SHOULD NOT be used except when there is a need to allow the location of those executables to be configurable. For example, `rm` should be used in preference to `%{__rm}`, but `%{__python}` is acceptable.
+Macro forms of system executables SHOULD NOT be used except when there is a need to allow the location of those executables to be configurable. For example, `rm` should be used in preference to `+%{__rm}+`, but `+%{__python}+` is acceptable.
 
 Having macros in a Source: or Patch: line is a matter of style. Some people enjoy the ready readability of a source line without macros. Others prefer the ease of updating for new versions when macros are used. In all cases, remember to be consistent in your spec file and verify that the URLs you list are valid. spectool (from the rpmdevtools package) can aid you in checking that whether the URL contains macros or not.
 
@@ -1156,37 +1151,37 @@ rpm -q --specfile foo.spec --qf "$(grep -i ^Source foo.spec)\n"
 `%autosetup`
 ^^^^^^^^^^^^
 
-As an alternative to the usual `%setup` macro, the `%autosetup` can be used. In addition to the normal %setup tasks, it will apply all defined Patch# items in the spec automatically. It is also capable of handling VCS formatted patch files, but this will require additional BuildRequires, and assumes that _all_ patch files in the spec are formatted for that single VCS type. For this reason, it is not recommended that you specify a VCS with `%autosetup`. For more details on proper use of `%autosetup`, refer to the ​http://rpm.org/user_doc/autosetup.html[RPM documentation].
+As an alternative to the usual `%setup` macro, the `%autosetup` can be used. In addition to the normal `%setup` tasks, it will apply all defined `Patch#` items in the spec automatically. It is also capable of handling VCS formatted patch files, but this will require additional BuildRequires, and assumes that _all_ patch files in the spec are formatted for that single VCS type. For this reason, it is not recommended that you specify a VCS with `%autosetup`. For more details on proper use of `%autosetup`, refer to the http://rpm.org/user_doc/autosetup.html[RPM documentation].
 
 [[using-buildroot-and-optflags-vs-rpm_build_root-and-rpm_opt_flags]]
-Using %\{buildroot} and %\{optflags} vs $RPM_BUILD_ROOT and $RPM_OPT_FLAGS
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Using `%{buildroot}` and `%{optflags}` vs `$RPM_BUILD_ROOT` and `$RPM_OPT_FLAGS`
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 There are two styles of defining the rpm Build Root and Optimization Flags in a spec file:
 
 [cols=",,",]
-|==========================================
+|=============================================
 | |macro style |variable style
-|Build Root |%\{buildroot} |$RPM_BUILD_ROOT
-|Opt. Flags |%\{optflags} |$RPM_OPT_FLAGS
-|==========================================
+|Build Root |`%{buildroot}` |`$RPM_BUILD_ROOT`
+|Opt. Flags |`%{optflags}` |`$RPM_OPT_FLAGS`
+|=============================================
 
 There is very little value in choosing one style over the other, since they will resolve to the same values in all scenarios. You should pick a style and use it consistently throughout your packaging.
 
 Mixing the two styles, while valid, is bad from a QA and usability point of view, and should not be done in Fedora packages.
 
 [[why-the-makeinstall-macro-should-not-be-used]]
-Why the %makeinstall macro should not be used
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Why the `%makeinstall` macro should not be used
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-Fedora's RPM includes a `%makeinstall` macro but it must *NOT* be used when make install DESTDIR=%\{buildroot} works. %makeinstall is a kludge that can work with Makefiles that don't make use of the DESTDIR variable but it has the following potential issues:
+Fedora's RPM includes a `%makeinstall` macro but it must *NOT* be used when `make install DESTDIR=%{buildroot}` works. `%makeinstall` is a kludge that can work with Makefiles that don't make use of the DESTDIR variable but it has the following potential issues:
 
-* `%makeinstall` overrides a set of Make variables during "make install" and prepends the %\{buildroot} path. I.e. it performs make prefix="%\{buildroot}%\{_prefix}" libdir="%\{buildroot}%\{_libdir} ...".
+* `%makeinstall` overrides a set of Make variables during "make install" and prepends the `%{buildroot}` path. I.e. it performs `+make prefix="%{buildroot}%{_prefix}" libdir="%{buildroot}%{_libdir}" ...+`.
 * It is error-prone and can have unexpected effects when run against less than perfect Makefiles, e.g. the buildroot path may be included in installed files where variables are substituted at install-time.
-* It can trigger unnecessary and wrong rebuilds when executing "make install", since the Make variables have different values compared with the %build section.
-* If a package contains libtool archives, it can cause broken *.la files to be installed.
+* It can trigger unnecessary and wrong rebuilds when executing `make install`, since the Make variables have different values compared with the `%build` section.
+* If a package contains libtool archives, it can cause broken `+*.la+` files to be installed.
 
-Instead, Fedora packages should use: `%make_install` (Note the "_" !), `make DESTDIR=%{buildroot} install` or `make DESTDIR=$RPM_BUILD_ROOT install`. Those all do the same thing.
+Instead, Fedora packages should use: `%make_install` (Note the "+_+" !), `make DESTDIR=%{buildroot} install` or `make DESTDIR=$RPM_BUILD_ROOT install`. Those all do the same thing.
 
 [[source-rpm-buildtime-macros]]
 Source RPM Buildtime Macros
@@ -1204,7 +1199,7 @@ rpmbuild -bs --nodeps [SRPM]
 rpm -qpiv /builddir/build/SRPMS/[SRPM]
 ....
 
-Check the `rpm` output for unexpanded macros (`%{foo}`) or missing information (when`%{?foo}` is expanded to the empty string). Even easier is to simply avoid macros in `Summary:` and `%description` unless they are defined in the current spec file.
+Check the `rpm` output for unexpanded macros (`%{foo}`) or missing information (when `%{?foo}` is expanded to the empty string). Even easier is to simply avoid macros in `Summary:` and `%description` unless they are defined in the current spec file.
 
 [[improper-use-of-_sourcedir]]
 Improper use of %_sourcedir
@@ -1216,7 +1211,7 @@ Packages which use files itemized as Source# files, must refer to those files by
 Software Collection Macros
 ^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-User:Toshio/SCL_Guidelines_(draft)[ Software Collections] are to be kept to separate packages from mainstream packages similar to how Packaging:MinGW[ MingW packages] are managed.
+link:https://fedoraproject.org/wiki/User:Toshio/SCL_Guidelines_(draft)[ Software Collections] are to be kept to separate packages from mainstream packages similar to how link:MinGW.html[MingW packages] are managed.
 
 In the past, SCL macros were allowed to be present inside of mainstream packages if they were not used. Since we're now building SCLs, we are now enforcing a strict separation. Packages *MUST* be updated to restrict SCL macros to only those packages particularly approved as part of an SCL.
 
@@ -1249,18 +1244,18 @@ Scripting inside of spec files
 
 Sometimes it is necessary to write a short script (perhaps a one-liner) that is executed in the %prep, %build, or %install sections of a spec file to get some information about the build environment. In order to simplify the dependency graph, spec files should only use the following languages for this purpose:
 
-`   1. Python` +
-`   2. Perl` +
-`   3. Standard programs used in shell programing, for instance gawk or sed` +
-`   4. Lua (as supported by the native lua interpreter in rpm)`
+1. Python
+2. Perl
+3. Standard programs used in shell programing, for instance `gawk` or `sed`
+4. Lua (as supported by the native lua interpreter in `rpm`)
 
 Additionally, if your package cannot build without a specific scripting language (such as Ruby, or Tcl), and therefore already has a BuildRequires on that language, it may also be called from the spec file.
 
 Note: If you call perl or python in your spec file (and it is not already a BuildRequires for the package), you need to explicitly add a BuildRequires for perl or python.
 
 [[global-preferred-over-define]]
-%global preferred over %define
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+`%global` preferred over `%define`
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Use `%global` instead of `%define`, unless you really need only locally defined submacros within other macro definitions (a very rare case).
 
@@ -1268,7 +1263,7 @@ Rationale: The two macro defining statements behave the same when they are a the
 
 But when they are used in nested macro expansions (like in `%{!?foo: ... }` constructs, `%define` theoretically only lasts until the end brace (local scope), while `%global` definitions have global scope.
 
-Note that %define and %global differ in more ways than just scope: the body of a %define'd macro is lazily expanded (ie when used), but the body of %global is expanded at definition time. It's possible to use %%-escaping to force lazy expansion of %global.
+Note that `%define` and `%global` differ in more ways than just scope: the body of a ``%define``'d macro is lazily expanded (ie when used), but the body of `%global` is expanded at definition time. It's possible to use %%-escaping to force lazy expansion of `%global`.
 
 [[handling-locale-files]]
 Handling Locale Files
@@ -1288,7 +1283,7 @@ For Qt-based packages that use the Linguist tool chain, for the localization uti
 BuildRequires: qt-devel
 ....
 
-If you have few enough locale files that they can all go into one package, you can use the `%find_lang` macro. (If you need to split your package into separate language packs, please see Packaging:Langpacks[the langpack guidelines].) This macro will locate all of the them belonging to your package (by name), and put this list in a file. You can then use that file to include all of the locales. `%find_lang` should be run in the %install section of your spec file, after all of the files have been installed into the buildroot. The correct syntax for `%find_lang` is usually:
+If you have few enough locale files that they can all go into one package, you can use the `%find_lang` macro. (If you need to split your package into separate language packs, please see link:Langpacks.html[the langpack guidelines].) This macro will locate all of the them belonging to your package (by name), and put this list in a file. You can then use that file to include all of the locales. `%find_lang` should be run in the %install section of your spec file, after all of the files have been installed into the buildroot. The correct syntax for `%find_lang` is usually:
 
 ....
 %find_lang %{name}
@@ -1384,7 +1379,7 @@ Using `%find_lang` helps keep the spec file simple, and helps avoid several othe
 
 * As new locale files appear in later package revisions, `%find_lang` will automatically include them when it is run, preventing you from having to update the spec any more than is necessary.
 
-Keep in mind that usage of `%find_lang` in packages containing locales is a MUST unless the locale files are broken out into langpacks. In which case, you should follow Packaging:Langpacks[the langpack guidelines].
+Keep in mind that usage of `%find_lang` in packages containing locales is a MUST unless the locale files are broken out into langpacks. In which case, you should follow link:Langpacks.html[the langpack guidelines].
 
 [[log-files]]
 Log Files
@@ -1445,7 +1440,7 @@ to your `~/.rpmmacros` file -- even on UP machines -- as this will expose most o
 Scriptlets
 ~~~~~~~~~~
 
-Great care should be taken when using scriptlets in Fedora packages. If scriptlets are used, those scriptlets must be sane. Some common scriptlets are documented here: Packaging:Scriptlets.
+Great care should be taken when using scriptlets in Fedora packages. If scriptlets are used, those scriptlets must be sane. Some common scriptlets are documented here: link:Scriptlets.html[Scriptlets].
 
 [[scriplets-are-only-allowed-to-write-in-certain-directories]]
 Scriplets are only allowed to write in certain directories
@@ -1502,7 +1497,7 @@ Directory ownership is a little more complex than file ownership. Packages must 
 
 In this context, a package's "natural dependency chain" is defined as the set of packages necessary for that package to function normally. To be specific, you do not need to require a package for the sole fact that it happens to own a directory that your package places files in. If your package already requires that package for other reasons, then your package should not also own that directory.
 
-In all cases we are guarding against unowned directories being present on a system. Please see Packaging:UnownedDirectories for the details.
+In all cases we are guarding against unowned directories being present on a system. Please see link:UnownedDirectories.html[Unowned Directories] for the details.
 
 Here are examples that describe how to handle most cases of directory ownership.
 
@@ -1566,7 +1561,7 @@ Duplicate Files
 
 A Fedora package must not list a file more than once in the spec file's %files listings. If you think your package is a valid exception to this, please bring it to the attention of the Packaging Committee so they can improve on this Guideline.
 
-One notable exception to this rule is around license texts. There are certain situations where it is required to duplicate the license text across multiple %files section within a package. For more details, please refer to Packaging:LicensingGuidelines#Subpackage_Licensing.
+One notable exception to this rule is around license texts. There are certain situations where it is required to duplicate the license text across multiple %files section within a package. For more details, please refer to link:LicensingGuidelines.html#subpackage-licensing[Subpackage Licensing].
 
 [[file-permissions]]
 File Permissions
@@ -1582,7 +1577,7 @@ The %defattr directive in the %files list SHOULD ONLY be used when setting a non
 Users and Groups
 ~~~~~~~~~~~~~~~~
 
-Some packages require or benefit from dedicated runtime user and/or group accounts. Guidelines for handling these cases are in a separate Packaging:UsersAndGroups document.
+Some packages require or benefit from dedicated runtime user and/or group accounts. Guidelines for handling these cases are in a separate link:UsersAndGroups.html[User and Groups] document.
 
 Note that system services packaged for Fedora MUST NOT run as the `nobody` user, but MUST instead allocate their own system user.
 
@@ -1600,7 +1595,7 @@ Web applications packaged in Fedora should put their content into /usr/share/%\{
 Conflicts
 ~~~~~~~~~
 
-Whenever possible, Fedora packages should avoid conflicting with each other. Unfortunately, this is not always possible. For full details on Fedora's Conflicts policy, see: Packaging:Conflicts .
+Whenever possible, Fedora packages should avoid conflicting with each other. Unfortunately, this is not always possible. For full details on Fedora's Conflicts policy, see: link:Conflicts.html[Conflicts].
 
 Tools such as Alternatives and Environment Modules can also help prevent package conflicts.
 
@@ -1608,13 +1603,13 @@ Tools such as Alternatives and Environment Modules can also help prevent package
 Alternatives
 ^^^^^^^^^^^^
 
-The "alternatives" tool provides a means for parallel installation of packages which provide the same functionality by maintaining sets of symlinks. For full details on how to properly use alternatives, see Packaging:Alternatives.
+The "alternatives" tool provides a means for parallel installation of packages which provide the same functionality by maintaining sets of symlinks. For full details on how to properly use alternatives, see link:Alternatives.html[Alternatives].
 
 [[environment-modules]]
 Environment Modules
 ^^^^^^^^^^^^^^^^^^^
 
-When there are multiple variants that each serve the needs of some user and thus must be available simultaneously by users, the alternatives system simply isn't enough since it is system-wide. In such situations, use of Environment Modules can avoid conflicts. For full details on how to properly use Environment Modules, see Packaging:EnvironmentModules.
+When there are multiple variants that each serve the needs of some user and thus must be available simultaneously by users, the alternatives system simply isn't enough since it is system-wide. In such situations, use of Environment Modules can avoid conflicts. For full details on how to properly use Environment Modules, see link:EnvironmentModules.html[Environment Modules].
 
 [[patch-guidelines]]
 Patch Guidelines
@@ -1639,7 +1634,7 @@ The above is perfectly acceptable; but if you prefer, a brief comment about what
 Patch0: gnome-panel-fix-frobnicator.patch
 ....
 
-Sending patches upstream and adding this comment will help ensure that Fedora is acting as a good FLOSS citizen (see link:PackageMaintainers/WhyUpstream[ Why Upstream?] ). It will help others (and even you) down the line in package maintenance by knowing what patches are likely to appear in a new upstream release.
+Sending patches upstream and adding this comment will help ensure that Fedora is acting as a good FLOSS citizen (see link:https://fedoraproject.org/wiki/PackageMaintainers/WhyUpstream[Why Upstream?]). It will help others (and even you) down the line in package maintenance by knowing what patches are likely to appear in a new upstream release.
 
 [[if-upstream-doesnt-have-a-bug-tracker]]
 If upstream doesn't have a bug tracker
@@ -1674,7 +1669,7 @@ Applying patches
 
 Normally, patches to a package SHOULD be listed in `PatchN:` tags in the RPM spec file and applied using the %patch or %autosetup macros. The files MUST then be checked into the Fedora Package revision control system (currently the git repos on pkgs.fedoraproject.org and commonly accessed via fedpkg). Storing the files in this way allows people to use standard tools to visualize the changes between revisions of the files and track additions and removals without a layer of indirection (as putting them into lookaside would do).
 
-Applying patches directly from RPM_SOURCE_DIR IS NOT ALLOWED. Please see Packaging:RPM_Source_Dir for the complete rationale.
+Applying patches directly from RPM_SOURCE_DIR IS NOT ALLOWED. Please see link:RPM_Source_Dir[RPM Source Dir] for the complete rationale.
 
 The maintainer MAY deviate from this rule when the upstream of the package provides an extremely large patch or a tarball of patches against a base release. In this case the tarball of patches MAY be listed as a `SourceN:` line and the patches would be applied by untarring the archive and then applying the distributed patch(es) using the regular /usr/bin/patch command. Additional patches to the package (for instance, generated by the Fedora maintainer to fix bugs) MUST still be listed in `PatchN:` lines and be applied by %patch macros after the patches from the tarball were applied. Maintainers and reviewers should be cautious when exercising this exception as shipping an update as a patchset may be a sign that the patchset is not from the actual upstream or that the patches should be reviewed for correctness rather than simply accepted as the upstream code base.
 
@@ -1759,7 +1754,7 @@ Replacing a symlink to a directory or a directory to any type file
 
 In some cases replacing a symlink to a directory requires special handling. Replacing a directory with any type of file always requires special handling.
 
-See Packaging:Directory_Replacement for information about doing this.
+See link:Directory_Replacement.html[Directory Replacement] for information about doing this.
 
 [[test-suites]]
 Test Suites
@@ -1785,7 +1780,7 @@ If you install a binfmt configuration snippet waldo.conf into %\{_binfmtdir} (/u
 
 These have the effect of making the appropriate changes immediately upon package installation instead of requiring a reboot or manual activation.
 
-There are specific guidelines for handling tmpfiles.d configurations and directories (in /run and /run/lock): Packaging:Tmpfiles.d
+There are specific guidelines for handling tmpfiles.d configurations and directories (in /run and /run/lock): link:Tmpfiles.d.html[Tmpfiles.d]
 
 [[renamingreplacing-existing-packages]]
 Renaming/Replacing Existing Packages
@@ -1806,7 +1801,7 @@ If a package supersedes/replaces an existing package without being a sufficientl
 
 If retired packages need to be removed from end user machines because they cause dependency issues which interfere with upgrades or are otherwise harmful, a packager MAY request that `Obsoletes:` be added to `fedora-obsolete-packages`. Simply file a bugzilla ticket https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&version=rawhide&component=fedora-obsolete-packages[here]. Please include information on which packages need to be obsoleted, the exact versions which need to be obsoleted, and the reasons why they cannot be allowed to remain installed.
 
-If the obsoleted package had an Epoch set, it must be preserved in both the `Provides:` and `Obsoletes:`. For example, assume foo being renamed to bar, bar is compatible with foo, and the last foo package release being foo-1.0-3%\{?dist} with Epoch: 2. The following should be added to bar (and similarly for all subpackages as applicable):
+If the obsoleted package had an Epoch set, it must be preserved in both the `Provides:` and `Obsoletes:`. For example, assume foo being renamed to bar, bar is compatible with foo, and the last foo package release being +foo-1.0-3%{?dist}+ with Epoch: 2. The following should be added to bar (and similarly for all subpackages as applicable):
 
 ....
 Provides: foo = 2:%{version}-%{release}
@@ -1831,7 +1826,7 @@ If an application contains native and stable support for both IPv4 and IPv6, and
 Cron Files
 ~~~~~~~~~~
 
-For details on how to package cron files, refer to: Packaging:CronFiles
+For details on how to package cron files, refer to: link:CronFiles.html[Cron Files].
 
 [[security-updates-to-resolve-known-cve-issues]]
 Security Updates To Resolve Known CVE Issues
@@ -1878,13 +1873,13 @@ Provides: bar(some_functionality)
 %endif
 ....
 
-Please note that usage of pre-built binaries in bootstrap still needs an exception from the Packaging Committee as stated in Packaging:Guidelines#Exceptions
+Please note that usage of pre-built binaries in bootstrap still needs an exception from the Packaging Committee as stated in <>.
 
 [[system-cryptographic-policies]]
 System cryptographic policies
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-Applications which make use the SSL or TLS cryptographic protocols MUST follow Packaging:CryptoPolicies.
+Applications which make use the SSL or TLS cryptographic protocols MUST follow link:CryptoPolicies.html[Crypt Policies].
 
 [[shebang-lines]]
 Shebang lines

From a068a75b2ec7c605a5ff4f476edfa40565a6274c Mon Sep 17 00:00:00 2001
From: Gene Hightower 
Date: Sep 13 2018 19:51:12 +0000
Subject: [PATCH 3559/3559] Don't discourage packaging static libraries.


---

diff --git a/packaging/Guidelines.adoc b/packaging/Guidelines.adoc
index 3c712ba..eb8522a 100644
--- a/packaging/Guidelines.adoc
+++ b/packaging/Guidelines.adoc
@@ -863,7 +863,7 @@ $ objdump -p /path/to/libfoo.so.0.n | grep 'SONAME'
 Packaging Static Libraries
 ~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-Packages including libraries SHOULD exclude static libs as far as possible (eg by configuring with `--disable-static`). Applications linking against libraries SHOULD link against shared libraries not static versions.
+Applications linking against libraries SHOULD link against shared libraries not static versions.
 
 Libtool archives, `foo.la` files, SHOULD NOT be included. Packages using libtool will install these by default even if you configure with `--disable-static`, so they may need to be removed before packaging. Due to bugs in older versions of libtool or bugs in programs that use it, there are times when it is not always possible to remove `+*.la+` files without modifying the program. In most cases it is fairly easy to work with upstream to fix these issues. Note that if you are updating a library in a stable release (not devel) and the package already contains `+*.la+` files, removing the `+*.la+` files SHOULD be treated as an API/ABI change — ie: Removing them changes the interface that the library gives to the rest of the world thus MUST follow Fedora policies for potentially destabilizing updates.
 
@@ -871,8 +871,6 @@ Libtool archives, `foo.la` files, SHOULD NOT be included. Packages using libtool
 Packaging Static Libraries
 ^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-* In general, packagers SHOULD NOT ship static libraries.
-
 * We want to be able to track which packages are using static libraries (so we can find which packages need to be rebuilt if a security flaw in a static library is fixed, for instance). There are two scenarios in which static libraries are packaged:
 
 1.  *Static libraries and shared libraries.* In this case, the static libraries MUST be placed in a _*-static_ subpackage. Separating the static libraries from the other development files in _*-devel_ allow us to track this usage by checking which packages `BuildRequire` the _*-static_ package. The intent is that whenever possible, packages will move away from using these static libraries, to the shared libraries. If the _*-static_ subpackage requires headers or other files from _*-devel_ in order to be useful it MUST require the _*-devel_ subpackage.