#862 fix broken links and minor build warnings
Merged 4 months ago by ignatenkobrain. Opened 5 months ago by tmz.
tmz/packaging-committee master  into  master

@@ -0,0 +1,83 @@ 

+ %global opt %(test -x %{_bindir}/ocamlopt && echo 1 || echo 0)

+ %global debug_package %{nil}

+ 

+ Name:           ocaml-foolib

+ Version:        1.2.3

+ Release:        1%{?dist}

+ Summary:        OCaml library for fooing bars

+ 

+ License:        LGPL+

+ URL:            http://www.example.com/foolib

+ Source0:        http://www.example.com/foolib-1.2.3.tar.gz

+ BuildRoot:      %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)

+ 

+ BuildRequires:  ocaml, ocaml-findlib-devel

+ 

+ %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

+ 

+ %description

+ OCaml library for fooing bars.  This library can also foo bazes.

+ 

+ 

+ %package        devel

+ Summary:        Development files for %{name}

+ Requires:       %{name} = %{version}-%{release}

+ 

+ 

+ %description    devel

+ The %{name}-devel package contains libraries and signature files for

+ developing applications that use %{name}.

+ 

+ 

+ %prep

+ %setup -q -n foolib-%{version}

+ # You may need a ./configure step here.

+ 

+ 

+ %build

+ make byte

+ %if %opt

+ make opt

+ %endif

+ 

+ 

+ %install

+ # These rules work if the library uses 'ocamlfind install' to install itself.

+ export DESTDIR=$RPM_BUILD_ROOT

+ export OCAMLFIND_DESTDIR=$RPM_BUILD_ROOT%{_libdir}/ocaml

+ mkdir -p $OCAMLFIND_DESTDIR $OCAMLFIND_DESTDIR/stublibs

+ make install

+ 

+ 

+ %clean

+ rm -rf $RPM_BUILD_ROOT

+ 

+ 

+ %files

+ %doc README

+ %{_libdir}/ocaml/foolib

+ %if %opt

+ %exclude %{_libdir}/ocaml/foolib/*.a

+ %exclude %{_libdir}/ocaml/foolib/*.cmxa

+ %exclude %{_libdir}/ocaml/foolib/*.cmx

+ %endif

+ %exclude %{_libdir}/ocaml/foolib/*.mli

+ %{_libdir}/ocaml/stublibs/*.so

+ %{_libdir}/ocaml/stublibs/*.so.owner

+ 

+ 

+ %files devel

+ %doc README

+ %if %opt

+ %{_libdir}/ocaml/foolib/*.a

+ %{_libdir}/ocaml/foolib/*.cmxa

+ %{_libdir}/ocaml/foolib/*.cmx

+ %endif

+ %{_libdir}/ocaml/foolib/*.mli

+ 

+ 

+ %changelog

+ * Sat May 26 2007 Your Name <you@example.com> - 1.2.3-1

+ - Initial RPM release.

@@ -1,6 +1,6 @@ 

  = Conflicts Guidelines

  

- *Author:* link:TomCallaway[ Tom 'spot' Callaway] +

+ *Author:* https://fedoraproject.org/wiki/TomCallaway[ Tom 'spot' Callaway] +

  *Revision:* 0.07 +

  *Initial Draft:* Tuesday Dec 5, 2006 +

  *Last Revised:* Wednesday Oct 31, 2012 +

@@ -136,4 +136,4 @@ 

  

  == 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.

+ 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 https://pagure.io/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.

@@ -38,6 +38,6 @@ 

  

  * debuginfo package listings for Fedora, 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.

  ** Note that due to the split repository, each directory must be examined separately.

- ** http://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/x86_64/debug/a/?C=S;O=A

+ ** https://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/Everything/x86_64/debug/tree/Packages/a/?C=S;O=A

  * StackTraces

  * rpmlint >= 0.77

@@ -41,7 +41,7 @@ 

  

  == Approved Exceptions

  

- Some services which are permitted to be enabled by default as specific exceptions. Services that should be enabled by default throughout all of Fedora must be approved by https://fedorahosted.org/fesco/newticket[FESCo]. Services that should be enabled or disabled by default only on one or more of the Fedora Editions must be approved by those Editions' https://fedoraproject.org/wiki/Fedora.next#Working_groups[Working Groups].

+ Some services which are permitted to be enabled by default as specific exceptions. Services that should be enabled by default throughout all of Fedora must be approved by https://pagure.io/fesco[FESCo]. Services that should be enabled or disabled by default only on one or more of the Fedora Editions must be approved by those Editions' https://fedoraproject.org/wiki/Fedora.next#Working_groups[Working Groups].

  

  Example:

  

@@ -50,9 +50,9 @@ 

  

  == Current list of enabled/disabled services

  

- * https://pagure.io/fedora-release/blob/master/f/90-default.preset[Fedora general]

- * https://pagure.io/fedora-release/blob/master/f/80-server.preset[Fedora Server]

- * https://pagure.io/fedora-release/blob/master/f/80-workstation.preset[Fedora Workstation]

+ * https://src.fedoraproject.org/rpms/fedora-release/blob/master/f/90-default.preset[Fedora general]

+ * https://src.fedoraproject.org/rpms/fedora-release/blob/master/f/80-server.preset[Fedora Server]

+ * https://src.fedoraproject.org/rpms/fedora-release/blob/master/f/80-workstation.preset[Fedora Workstation]

  

  == How to enable a service by default

  

@@ -1,6 +1,6 @@ 

  = DAP Packaging guidelines

  

- DevAssistant provides an easy extendability through Assistants. These assistants are normally distributed via the https://dapi.devassistant.org[DevAssistant Package Index] in the form of DAP (DevAssistant Package) files. If you want to include a DAP into the main Fedora repositories, you can do so. This document outlines the rules involved.

+ DevAssistant provides an easy extendability through Assistants. These assistants are normally distributed via the https://devassistant.github.io[DevAssistant Package Index] in the form of DAP (DevAssistant Package) files. If you want to include a DAP into the main Fedora repositories, you can do so. This document outlines the rules involved.

  

  *Note:* Packaged DAPs only work with DevAssistant 0.10.0 and newer. They can not be used with DevAssistant versions 0.9.* packaged in Fedora 21 and earlier.

  

@@ -48,7 +48,7 @@ 

  replacing `+/path/to/dir+`

  with the path to the directory that is being converted.

  

- ==== Scriptlet to replace a directory

+ === Scriptlet to replace a directory

  

  RPM cannot simply remove a directory

  when it is replaced by a file or symlink,

@@ -59,11 +59,11 @@ 

  

  === Other Packages

  

- See Packaging:PHP#Other_Packages[PHP packaging guidelines].

+ See xref:PHP.adoc#Other_Packages[PHP packaging guidelines].

  

  === PHP Extensions

  

- See Packaging:PHP#Extensions_Requires[PHP packaging guidelines].

+ See xref:PHP.adoc#Extensions_Requires[PHP packaging guidelines].

  

  To get a list of required PHP extensions, use http://php5.laurent-laville.org/compatinfo/[PHP_CompatInfo (phpcompatinfo)]:

  

@@ -75,7 +75,7 @@ 

  

  === Requiring a Minimum PHP Version

  

- See Packaging:PHP#Requiring_a_Minimum_PHP_version[PHP packaging guidelines] but note that this should not normally be required by most packages (see http://drupal.org/node/542202#php[1]).

+ See xref:PHP.adoc#Requiring_a_Minimum_PHP_version[PHP packaging guidelines] but note that this should not normally be required by most packages (see https://drupal.org/node/542202#php[1]).

  

  === Common Issues

  

@@ -21,7 +21,7 @@ 

  

  == 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] .

+ 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 https://src.fedoraproject.org/rpms/eclipse-cdt/blob/master/f/eclipse-cdt.spec[eclipse-cdt] or be put into a https://src.fedoraproject.org/rpms/eclipse-rpm-editor/blob/f10/f/fetch-specfile-editor.sh[separate shell script] as in https://src.fedoraproject.org/rpms/eclipse-rpm-editor/blob/f10/f/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.

  

@@ -199,7 +199,7 @@ 

  $ <do symlinking here>

  ....

  

- 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 https://src.fedoraproject.org/rpms/eclipse-mylyn/[eclipse-mylyn] (specifically the patches related to `+org.eclipse.mylyn.webcore+`).

  

  === rpmstubby

  

@@ -1,6 +1,6 @@ 

  === 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 link:Legal_considerations_for_fonts[ 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 https://fedoraproject.org/wiki/Legal_considerations_for_fonts[legal page].

  

   +

   +

@@ -15,13 +15,13 @@ 

  .  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 link:Fonts_SIG_mailing_lists[fonts list], so the font family split can be eventually hidden from users.

+ * such cases should be notified to the fontconfig maintainer and the Fedora https://fedoraproject.org/wiki/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 link: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.

+ As noted in the xref:index.adoc#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.

  

  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.

  

@@ -46,7 +46,7 @@ 

  7.  If any element of the naming contains spaces, they should be replaced by “-”.

  8.  The use of the _-fonts_ suffix is not dependant on the actual number of font files in the package.

  

- When in doubt, ask the link:Fonts_SIG_mailing_lists[mailing list] for clarification.

+ When in doubt, ask the https://fedoraproject.org/wiki/Fonts_SIG_mailing_lists[mailing list] for clarification.

  

  ==== Examples

  

@@ -98,20 +98,20 @@ 

  

  === Building from sources

  

- Fonts *SHOULD* be built from source whenever upstream provides them in a source formatfootnote:[As documented in our general link: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.

+ Fonts *SHOULD* be built from source whenever upstream provides them in a source format footnote:[As documented in our general xref:what-can-be-packaged.adoc#prebuilt-binaries-or-libraries[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_ packagefootnote:[Built from the pkgdb:fontpackages[fontpackages] srpm.]. Its sources are published on http://pagure.io/[Pagure] in https://pagure.io/fontpackages[archive] and git (https://pagure.io/fontpackages.git) formats.

+ Creating font packages or subpackages in Fedora is done using the _fontpackages-devel_ package footnote:[Built from the https://apps.fedoraproject.org/packages/fontpackages[fontpackages] srpm.]. Its sources are published on https://pagure.io/[Pagure] in https://pagure.io/fontpackages[archive] and git (https://pagure.io/fontpackages.git) formats.

  

  It contains a set of commented fontconfig templates, and the two official Fedora fonts spec templates:

  

- * a link:Simple_fonts_spec_template[simple template] for font source packages containing a single font family,

- * a link:Fonts_spec_template_for_multiple_fonts[complex template] for font source packages containing several different font families.

+ * a https://fedoraproject.org/wiki/Simple_fonts_spec_template[simple template] for font source packages containing a single font family,

+ * a https://fedoraproject.org/wiki/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 link:Fonts_SIG_mailing_lists[mailing list].

+ _fontpackages_ evolutions can be discussed on the Fonts SIG https://fedoraproject.org/wiki/Fonts_SIG_mailing_lists[mailing list].

  

  === Install-time dependencies

  

@@ -125,7 +125,7 @@ 

  

  === Licensing Information in Metadata

  

- The "copyright notice" field (tag #0) of the "name" table of TTF and OTF files *MUST* be populated and contain accurate information. Additionally, if information is provided in the "license description" (#13) or "license info URL" (#14) fields are populated, the information contained therein must also be accurate. You can use User:Patches/ttname[`+ttname+`] to review the metadata included with the font to check it for accuracy.

+ The "copyright notice" field (tag #0) of the "name" table of TTF and OTF files *MUST* be populated and contain accurate information. Additionally, if information is provided in the "license description" (#13) or "license info URL" (#14) fields are populated, the information contained therein must also be accurate. You can use https://fedoraproject.org/wiki/User:Patches/ttname[`+ttname+`] to review the metadata included with the font to check it for accuracy.

  

  If the metadata is incorrect, packagers should work with upstream to ensure the metadata is properly populated there, so all users of the font can benefit from the corrections. If upstream is non-responsive or you are waiting on a new release for the corrections, you can also use `+ttname+` in `+%prep+` to correct the metadata for the Fedora package.

  

@@ -149,7 +149,7 @@ 

  

  === Core fonts

  

- Once upon a time every Linux GUI application used the so-called _Core fonts_ server-side X11 backendfootnote:[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 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.

  

  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.

  

@@ -253,7 +253,7 @@ 

  

  == RPM Macros

  

- The templates all have buildrequires for ghc-rpm-macros, which provides http://pkgs.fedoraproject.org/cgit/ghc-rpm-macros.git/tree/ghc-rpm-macros.ghc[macros.ghc] to assist with packaging Haskell Cabal packages.

+ The templates all have buildrequires for ghc-rpm-macros, which provides https://src.fedoraproject.org/rpms/ghc-rpm-macros/blob/master/f/macros.ghc[macros.ghc] to assist with packaging Haskell Cabal packages.

  

  ....

  BuildRequires:  ghc-rpm-macros

@@ -369,8 +369,8 @@ 

  

  == References

  

- * http://fedorahosted.org/cabal2spec

- * http://pkgs.fedoraproject.org/gitweb/?p=ghc-rpm-macros.git

- * http://pkg-haskell.alioth.debian.org/haskell-policy/ - Debian Haskell packaging policy

- * link:Packaging/OCaml[Fedora OCaml Packaging Guidelines]

- * link:SIGs/Haskell[Fedora Haskell SIG]

+ * https://hackage.haskell.org/package/cabal-rpm

+ * https://src.fedoraproject.org/rpms/ghc-rpm-macros

+ * https://wiki.debian.org/Haskell[Debian Haskell Group]

+ * xref:OCaml.adoc[Fedora OCaml Packaging Guidelines]

+ * https://fedoraproject.org/wiki/Haskell_SIG[Fedora Haskell SIG]

@@ -27,7 +27,7 @@ 

  

  === 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/ .

+ 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 https://common-lisp.net/project/asdf/asdf.html[here].

  

  === Install location and hooking into the common-lisp-controller

  

@@ -35,7 +35,7 @@ 

  

  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 link:Packaging/EnvironmentModules[environment modules].

+ 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 xref:EnvironmentModules.adoc[environment modules].

  

  The module file MUST be installed under `+%{_sysconfdir}/modulefiles/mpi+`. This allows as user with only one mpi implementation installed to load the module with:

  

@@ -93,7 +93,7 @@ 

  

  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.

+ 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:

  

@@ -110,7 +110,7 @@ 

  

  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 link:Packaging/Guidelines[ Packaging Guidelines] .

+ 1. Identify which directories the files should install into according to the xref:index.adoc[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.

@@ -472,7 +472,7 @@ 

  == Authorship

  

  The original author of these guidelines was

- link:TomCallaway[Tom 'spot' Callaway].

+ https://fedoraproject.org/wiki/TomCallaway[Tom 'spot' Callaway].

  They are now maintained by the

- link:Packaging_Committee[Packaging Committee]

+ https://fedoraproject.org/wiki/Packaging_Committee[Packaging Committee]

  with input from the Fedora community.

@@ -114,7 +114,7 @@ 

  %nodejs_fixdep foomodule '>2.0'

  ....

  

- The second argument to `+%nodejs_fixdep+` must be a valid _package.json_ version specifier as explained in https://npmjs.org/doc/json.html[`+\+`man npm json\`++`].

+ The second argument to `+%nodejs_fixdep+` must be a valid _package.json_ version specifier as explained in https://docs.npmjs.com/files/package.json#version[`+\+`man npm json\`++`].

  

  You can also remove a dependency:

  

@@ -14,7 +14,13 @@ 

  

  == Packaging libraries

  

- image:Packaging_OCaml_ocaml-foolib.spec[Packaging_OCaml_ocaml-foolib.spec,title="fig:Packaging_OCaml_ocaml-foolib.spec"] - An example specfile for an imaginary OCaml library called _foolib_.

+ The following is an example specfile for an imaginary OCaml library called _foolib_.

+ 

+ .ocaml-example.spec

+ [source]

+ ----

+ include::{examplesdir}/ocaml-example.spec[]

+ ----

  

  === Main package

  

@@ -33,7 +39,7 @@ 

  

  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.

+ 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).

  

@@ -145,8 +151,6 @@ 

  

  == 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.

@@ -15,7 +15,7 @@ 

  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 https://fedoraproject.org/wiki/Staying_close_to_upstream_projects[Staying close to upstream projects]). 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

  

@@ -42,4 +42,4 @@ 

  

  == Why upstream?

  

- Refer link:PackageMaintainers/WhyUpstream[ Why Upstream?]

+ Refer https://fedoraproject.org/wiki/Staying_close_to_upstream_projects[Staying close to upstream projects]

@@ -5,7 +5,7 @@ 

  

  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 link: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 https://fedoraproject.org/wiki/Licensing:Main[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

@@ -13,7 +13,7 @@ 

  

  == 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.

+ As specified in the xref:index.adoc#_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:

  

@@ -186,6 +186,6 @@ 

  

  == 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[the mailing list], where are discussed latest issues.

+ People around Perl, who are packaging, maintaining & reviewing packages. If you are interested in Perl, join https://lists.fedoraproject.org/admin/lists/perl-devel.lists.fedoraproject.org/[the 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 link:Package_SCM_admin_requests#New_Packages[New Package SCM Request].

+ New Perl packages should set the https://lists.fedoraproject.org/admin/lists/perl-devel.lists.fedoraproject.org/[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].

@@ -119,7 +119,7 @@ 

  Some things to watch out for:

  

  * 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 `+python3+`. 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 link:Staying_close_to_upstream_projects[ get into upstream], you need to write patches that work with both as well.

+ * Patching the source code is done before copying to `+python3+`. 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 https://fedoraproject.org/wiki/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+`.

  

@@ -100,5 +100,5 @@ 

  

  * 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

+ * 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]

@@ -4,61 +4,59 @@ 

  

  == Package Review Process

  

- Contributors and reviewers MUST follow the link:Package_Review_Process[Package Review Process], with the following exceptions:

+ Contributors and reviewers MUST follow the https://fedoraproject.org/wiki/Package_Review_Process[Package Review Process], with the following exceptions:

  

- * FPC grants an explicit exemption from the process, as indicated link:Packaging_Committee#Review_Process_Exception_Procedure[here].

- * The package is being created so that multiple versions of the same package can coexist in the distribution. The package MUST be properly named according to the Packaging:Naming#Multiple_packages_with_the_same_base_name[naming guidelines] and MUST NOT conflict with all other versions of the same package. If these requirements are not met, an exemption is required as above.

+ * FPC grants an explicit exemption from the process, as indicated https://fedoraproject.org/wiki/Packaging_Committee#Review_Process_Exemption_Procedure[here].

+ * The package is being created so that multiple versions of the same package can coexist in the distribution. The package MUST be properly named according to the xref:Naming.adoc#_multiple_packages_with_the_same_base_name[naming guidelines] and MUST NOT conflict with all other versions of the same package. If these requirements are not met, an exemption is required as above.

  

  == 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*.

  

- * *MUST*: rpmlint must be run on the source rpm and all binary rpms the build produces. The output should be posted in the review.footnote:[link:Packaging/Guidelines#rpmlint[Packaging Guidelines: Use rpmlint]] +

- * *MUST*: The package must be named according to the link: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. footnote:[link:Packaging/NamingGuidelines#Spec_file_name[ Naming Guidelines: Spec File Naming]] . +

- * *MUST*: The package must meet the link:Packaging/Guidelines[ Packaging Guidelines] . +

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

- * *MUST*: The License field in the package spec file must match the actual license. footnote:[link: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 `+%license+`.footnote:[link:Packaging/LicensingGuidelines#License_Text[Licensing Guidelines: License Text]] +

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

- * *MUST*: The spec file for the package *MUST* be legible. footnote:[link: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 sha256sum for this task as it is used by the `+sources+` file once imported into git. If no upstream URL can be specified for this package, please see the link: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. footnote:[link: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. footnote:[link: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 link: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.footnote:[link:Packaging/Guidelines#Handling_Locale_Files[Packaging Guidelines: Handling Locale Files]] +

- * *MUST*: Packages must NOT bundle copies of system libraries.footnote:[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. footnote:[link: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. footnote:[link: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. (Notable exception: license texts in specific situations)footnote:[link:Packaging/Guidelines#DuplicateFiles[Packaging Guidelines: Duplicate Files]] +

- * *MUST*: Permissions on files must be set properly. Executables should be set with executable permissions, for example. footnote:[link:Packaging/Guidelines#FilePermissions[Packaging Guidelines: File Permissions]] +

- * *MUST*: Each package must consistently use macros. footnote:[link:Packaging/Guidelines#macros[Packaging Guidelines: Macros]] +

- * *MUST*: The package must contain code, or permissible content. footnote:[link: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). footnote:[link: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. footnote:[link:Packaging/Guidelines#PackageDocumentation[Packaging Guidelines: Package Documentation]] +

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

- * *MUST*: Development files must be in a -devel package. footnote:[link: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}%{?_isa} = %{version}-%{release}+` footnote:[link: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.footnote:[link: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. footnote:[link: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. footnote:[link:Packaging/Guidelines#FileAndDirectoryOwnership[Packaging Guidelines: File And Directory Ownership]] +

- * *MUST*: All filenames in rpm packages must be valid UTF-8. footnote:[link:Packaging/Guidelines#FilenameEncoding[Packaging Guidelines: Filename Encoding]] +

- * *MUST*: Packages being added to the distribution MUST NOT depend on any packages which have been marked as being deprecated. footnote:[Packaging:Deprecating_Packages] +

+ * *MUST*: rpmlint must be run on the source rpm and all binary rpms the build produces. The output should be posted in the review.footnote:[xref:index.adoc#_use_rpmlint[Packaging Guidelines: Use rpmlint\]] +

+ * *MUST*: The package must be named according to the xref:Naming.adoc[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. footnote:[xref:index.adoc#_spec_file_naming[Packaging Guidelines: Spec File Naming\]] . +

+ * *MUST*: The package must meet the xref:index.adoc[Packaging Guidelines] . +

+ * *MUST*: The package must be licensed with a Fedora approved license and meet the xref:LicensingGuidelines.adoc[Licensing Guidelines] . +

+ * *MUST*: The License field in the package spec file must match the actual license. footnote:[xref:LicensingGuidelines.adoc#_valid_license_short_names[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 `+%license+`.footnote:[xref:LicensingGuidelines.adoc#_license_text[Licensing Guidelines: License Text\]] +

+ * *MUST*: The spec file must be written in American English. footnote:[xref:index.adoc#_summary_and_description[Packaging Guidelines: Summary and description\]] +

+ * *MUST*: The spec file for the package *MUST* be legible. footnote:[xref:index.adoc#_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 sha256sum for this task as it is used by the `+sources+` file once imported into git. If no upstream URL can be specified for this package, please see the xref:SourceURL.adoc[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. footnote:[xref:index.adoc#_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. footnote:[xref:index.adoc#_architecture_build_failures[Packaging Guidelines: Architecture Build Failures\]] +

+ * *MUST*: All build dependencies must be listed in `+BuildRequires+`. footnote:[xref:index.adoc#buildrequires[Packaging Guidelines: Build-Time Dependencies (BuildRequires)\]] +

+ * *MUST*: The spec file MUST handle locales properly. This is done by using the `+%find_lang+` macro. Using `+%{_datadir}/locale/*+` is strictly forbidden.footnote:[xref:index.adoc#_handling_locale_files[Packaging Guidelines: Handling Locale Files\]] +

+ * *MUST*: Packages must NOT bundle copies of system libraries.footnote:[xref:index.adoc#bundling[Packaging Guidelines: Bundling and 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. footnote:[xref:index.adoc#_relocatable_packages[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. footnote:[xref:index.adoc#_file_and_directory_ownership[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. (Notable exception: license texts in specific situations)footnote:[xref:index.adoc#_duplicate_files[Packaging Guidelines: Duplicate Files\]] +

+ * *MUST*: Permissions on files must be set properly. Executables should be set with executable permissions, for example. footnote:[xref:index.adoc#_file_permissions[Packaging Guidelines: File Permissions\]] +

+ * *MUST*: Each package must consistently use macros. footnote:[xref:index.adoc#_macros[Packaging Guidelines: Macros\]] +

+ * *MUST*: The package must contain code, or permissible content. footnote:[xref:what-can-be-packaged.adoc[What Can Be Packaged\]] +

+ * *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). footnote:[xref:index.adoc#_documentation[Packaging Guidelines: 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. footnote:[xref:index.adoc#_documentation[Packaging Guidelines: Documentation\]] +

+ * *MUST*: Static libraries must be in a -static package. footnote:[xref:index.adoc#packaging-static-libraries[Packaging Guidelines: Packaging Static Libraries\]] +

+ * *MUST*: Development files must be in a -devel package. footnote:[xref:index.adoc#_devel_packages[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}%{?_isa} = %{version}-%{release}+` footnote:[xref:index.adoc#_requiring_base_package[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.footnote:[xref:index.adoc#packaging-static-libraries[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. footnote:[xref:index.adoc#_desktop_files[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. footnote:[xref:index.adoc#_file_and_directory_ownership[Packaging Guidelines: File and Directory Ownership\]] +

+ * *MUST*: All filenames in rpm packages must be valid UTF-8. footnote:[xref:index.adoc#_non_ascii_filenames[Packaging Guidelines: Non-ASCII Filenames\]] +

+ * *MUST*: Packages being added to the distribution MUST NOT depend on any packages which have been marked as being deprecated. footnote:[xref:deprecating-packages.adoc[Deprecating Packages\]] +

  

-  +

+ '''

  

-  +

- 

- * *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. footnote:[link: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. footnote:[link:Packaging/Guidelines#summary[Packaging Guidelines: Summary and description]] +

- * *SHOULD*: The reviewer should test that the package builds in mock. footnote:[link:PackageMaintainers/MockTricks[Mock Tricks]] +

- * *SHOULD*: The package should compile and build into binary rpms on all supported architectures. footnote:[link:Packaging/Guidelines#ArchitectureSupport[Packaging Guidelines: Architecture Support]] +

+ * *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. footnote:[xref:LicensingGuidelines.adoc#_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. footnote:[xref:index.adoc#_summary_and_description[Packaging Guidelines: Summary and description\]] +

+ * *SHOULD*: The reviewer should test that the package builds in mock. footnote:[https://fedoraproject.org/wiki/Using_Mock_to_test_package_builds[Using Mock to test package builds\]] +

+ * *SHOULD*: The package should compile and build into binary rpms on all supported architectures. footnote:xref:index.adoc#_architecture_support[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. footnote:[link:Packaging/Guidelines#Scriptlets[Packaging Guidelines: Scriptlets]] +

- * *SHOULD*: Usually, subpackages other than devel should require the base package using a fully versioned dependency. footnote:[link: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. footnote:[link: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. footnote:[link: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.footnote:[Packaging:Guidelines#Manpages[Packaging Guidelines: Manpages]] +

+ * *SHOULD*: If scriptlets are used, those scriptlets must be sane. This is vague, and left up to the reviewers judgement to determine sanity. footnote:[xref:index.adoc#_scriptlets[Packaging Guidelines: Scriptlets\]] +

+ * *SHOULD*: Usually, subpackages other than devel should require the base package using a fully versioned dependency. footnote:[xref:index.adoc#_requiring_base_package[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. footnote:[xref:index.adoc#_pkgconfig_files_foo_pc[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. footnote:[xref:index.adoc#_file_and_directory_dependencies[Packaging Guidelines: File and Directory 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.footnote:[xref:index.adoc#_manpages[Packaging Guidelines: Manpages\]] +

  

  == A note on dependencies

  

@@ -13,7 +13,7 @@ 

  

  The version of RPM in Fedora also has functionality

  to automatically run scripts when files are placed in certain locations.

- (See http://www.rpm.org/wiki/FileTriggers[1].)

+ (See http://rpm.org/user_doc/file_triggers.html[1].)

  This potentially obviates the need for most of the scriptlets on this page,

  but is not currently implemented in all cases where it could be.

  

@@ -188,7 +188,7 @@ 

  

  === Users and groups

  

- These are discussed on a link:Packaging/UsersAndGroups[ separate page]

+ These are discussed on a xref:UsersAndGroups.adoc[separate page]

  

  === GConf

  

@@ -1,13 +1,13 @@ 

  = Deprecating Packages

  :toc:

  

- Sometimes a package is intended to be link:How_to_remove_a_package_at_end_of_life[removed from Fedora], but it is kept in Fedora for some additional (often indeterminate) time for various reasons including maintaining backwards compatibility. In order to prevent new packages from depending on such a package, it can be marked as *deprecated*.

+ Sometimes a package is intended to be https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life[removed from Fedora], but it is kept in Fedora for some additional (often indeterminate) time for various reasons including maintaining backwards compatibility. In order to prevent new packages from depending on such a package, it can be marked as *deprecated*.

  

  == Prerequisites for deprecation

  

  If nothing in Fedora depends on a package, a maintainer may deprecate it at their leisure. A maintainer (or collection of maintainers) may also deprecate a set of packages together if no package in that set is a dependency of any package outside of that set.

  

- If a package is a dependency of other packages in the distribution (which are not to be deprecated) then deprecation requires a link:Changes/Policy[FESCo approved Fedora change]. A packager SHOULD communicate package deprecation to other maintainers, preferably via the https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/[devel] or https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org/[devel-announce] mailing lists.

+ If a package is a dependency of other packages in the distribution (which are not to be deprecated) then deprecation requires a https://fedoraproject.org/wiki/Changes/Policy[FESCo approved Fedora change]. A packager SHOULD communicate package deprecation to other maintainers, preferably via the https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/[devel] or https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org/[devel-announce] mailing lists.

  

  == Marking a package deprecated

  

@@ -41,7 +41,7 @@ 

  

  `+Provides:  deprecated() == YYYYMMDD+`

  

- The special `+deprecated()+` provide MUST NOT be added in any released branch of Fedora. It is acceptable to deprecate packages in rawhide (the master branch), the branch for an upcoming Fedora release (if one exists) up until the time of the link:Schedule[Final Freeze], and to EPEL branches (at any time). Also note that because packages may exist in a deprecated state for some time, those packages can eventually enter release branches. The restriction is on the initial addition of the `+deprecated()+` tag.

+ The special `+deprecated()+` provide MUST NOT be added in any released branch of Fedora. It is acceptable to deprecate packages in rawhide (the master branch), the branch for an upcoming Fedora release (if one exists) up until the time of the https://fedoraproject.org/wiki/Schedule[Final Freeze], and to EPEL branches (at any time). Also note that because packages may exist in a deprecated state for some time, those packages can eventually enter release branches. The restriction is on the initial addition of the `+deprecated()+` tag.

  

  == Consequences of a package being deprecated

  

@@ -1400,7 +1400,7 @@ 

  

  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 xref:RPM_Source_dir.adoc[Packaging:RPM_Source_Dir] for the complete rationale.

+ Applying patches directly from RPM_SOURCE_DIR IS NOT ALLOWED. Please see xref:RPM_Source_Dir.adoc[Packaging: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.

  

I noticed a broken link in the guidelines index page, pointing to RPM_Source_dir.adoc. While fixing this I ran across the minor warning when building the via antora. After I was a little familiar with the process, I used the linkchecker command to locate other broken links. There were a good number of them, which I've attempted to correct in 3d0c608 ("fix broken links", 2019-02-24).

Let me know if this should be broken up into smaller chunks or needs further work.

I pushed the built pages here to make it easier to check the results.

rebased onto 63177e5

4 months ago

Pull-Request has been merged by ignatenkobrain

4 months ago
Metadata
Changes Summary 24
+83
file added
guidelines/modules/ROOT/examples/ocaml-example.spec
+2 -2
file changed
guidelines/modules/ROOT/pages/Conflicts.adoc
+1 -1
file changed
guidelines/modules/ROOT/pages/Debuginfo.adoc
+4 -4
file changed
guidelines/modules/ROOT/pages/DefaultServices.adoc
+1 -1
file changed
guidelines/modules/ROOT/pages/DevAssistant.adoc
+1 -1
file changed
guidelines/modules/ROOT/pages/Directory_Replacement.adoc
+3 -3
file changed
guidelines/modules/ROOT/pages/Drupal7.adoc
+2 -2
file changed
guidelines/modules/ROOT/pages/EclipsePlugins.adoc
+11 -11
file changed
guidelines/modules/ROOT/pages/FontsPolicy.adoc
+6 -6
file changed
guidelines/modules/ROOT/pages/Haskell.adoc
+1 -1
file changed
guidelines/modules/ROOT/pages/Lisp.adoc
+1 -1
file changed
guidelines/modules/ROOT/pages/MPI.adoc
+2 -2
file changed
guidelines/modules/ROOT/pages/Mono.adoc
+2 -2
file changed
guidelines/modules/ROOT/pages/Naming.adoc
+1 -1
file changed
guidelines/modules/ROOT/pages/Node.js.adoc
+8 -4
file changed
guidelines/modules/ROOT/pages/OCaml.adoc
+2 -2
file changed
guidelines/modules/ROOT/pages/PatchUpstreamStatus.adoc
+4 -4
file changed
guidelines/modules/ROOT/pages/Perl.adoc
+1 -1
file changed
guidelines/modules/ROOT/pages/Python_Appendix.adoc
+2 -2
file changed
guidelines/modules/ROOT/pages/Python_Eggs.adoc
+44 -46
file changed
guidelines/modules/ROOT/pages/ReviewGuidelines.adoc
+2 -2
file changed
guidelines/modules/ROOT/pages/Scriptlets.adoc
+3 -3
file changed
guidelines/modules/ROOT/pages/deprecating-packages.adoc
+1 -1
file changed
guidelines/modules/ROOT/pages/index.adoc