trivial: drop Category: links
Signed-off-by: Igor Gnatenko <ignatenkobrain@fedoraproject.org>
This commit is contained in:
Igor Gnatenko
parent
1d0bff1b20
commit
60f9e22189
67 changed files with 0 additions and 140 deletions
|
|
@ -64,5 +64,3 @@ end Example;
|
|||
== 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]
|
||||
|
|
|
|||
|
|
@ -149,5 +149,3 @@ fi
|
|||
|
||||
%attr(0755,root,root) %{_initrddir}/sendmail
|
||||
....
|
||||
|
||||
Category:Packaging_guidelines[Category:Packaging guidelines]
|
||||
|
|
|
|||
|
|
@ -80,5 +80,3 @@ Although you can just include the .appdata.xml or .metainfo.xml files in the pac
|
|||
....
|
||||
appstream-util validate-relax --nonet %{buildroot}%{_metainfodir}/*.appdata.xml
|
||||
....
|
||||
|
||||
Category:Packaging_guidelines[Category:Packaging guidelines]
|
||||
|
|
|
|||
|
|
@ -151,5 +151,3 @@ By policy, nothing under `+%_docdir+` is allowed to either "provide" or "require
|
|||
== Additional Information
|
||||
|
||||
Additional information about RPM's dependency generator can be found here: http://rpm.org/user_doc/dependency_generators.html
|
||||
|
||||
Category:Packaging_guidelines
|
||||
|
|
|
|||
|
|
@ -35,5 +35,3 @@ Libraries should version all of their symbols using a version script. Versioning
|
|||
== Applications
|
||||
|
||||
No additional suggestions are provided for applications at this time.
|
||||
|
||||
Category:Packaging_guidelines[Category:Packaging guidelines]
|
||||
|
|
|
|||
|
|
@ -33,5 +33,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]
|
||||
|
|
|
|||
|
|
@ -137,5 +137,3 @@ Renaming packages and replacing them with others can be difficult if it has to o
|
|||
== 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]
|
||||
|
|
|
|||
|
|
@ -73,5 +73,3 @@ mkdir -p $RPM_BUILD_ROOT%{_sysconfdir}/cron.monthly
|
|||
%files
|
||||
%config(noreplace) %{_sysconfdir}/cron.monthly/%{name}
|
||||
....
|
||||
|
||||
Category:Packaging_guidelines[Category:Packaging guidelines]
|
||||
|
|
|
|||
|
|
@ -28,5 +28,3 @@ Applications utilizing other cryptographic libraries do not adhere to the system
|
|||
|
||||
* *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]
|
||||
|
|
|
|||
|
|
@ -104,5 +104,3 @@ rm -rf %{buildroot}
|
|||
* Wed Aug 25 2010 John Doe <jdoe@anywhere.com> 1.2.3-1
|
||||
- initial package
|
||||
....
|
||||
|
||||
Category:Packaging_guidelines[Category:Packaging guidelines]
|
||||
|
|
|
|||
|
|
@ -41,5 +41,3 @@ It is normal for noarch package builds to not produce a debuginfo package. If it
|
|||
** http://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/x86_64/debug/a/?C=S;O=A
|
||||
* StackTraces
|
||||
* rpmlint >= 0.77
|
||||
|
||||
Category:Packaging_guidelines[Category:Packaging guidelines]
|
||||
|
|
|
|||
|
|
@ -62,5 +62,3 @@ If the service should be enabled by default, it must be added to one of the dist
|
|||
|
||||
For services which meet one of the conditions listed above, a ticket should be filed in
|
||||
https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&format=fedora-systemd-request[bugzilla]. If the preset should be changed for versions other than rawhide, indicate that in the ticket.
|
||||
|
||||
Category:Packaging_guidelines[Category:Packaging guidelines]
|
||||
|
|
|
|||
|
|
@ -45,5 +45,3 @@ The special `+deprecated()+` provide MUST NOT be added in any released branch of
|
|||
== Consequences of a package being deprecated
|
||||
|
||||
Technically, nothing changes; a deprecated package works and behaves as before. However, other packages in Fedora MUST NOT add a dependency on a deprecated package (that includes Requires, BuildRequires, Recommends, Suggests, etc.). This applies both for updates of existing packages and new packages added to Fedora. Those submitting new packages, along with package reviewers, MUST check to see if any dependencies of the package they are submitting or reviewing have been deprecated. (It is, however, acceptable for a deprecated package to be renamed.)
|
||||
|
||||
Category:Packaging_guidelines[Category:Packaging guidelines]
|
||||
|
|
|
|||
|
|
@ -140,5 +140,3 @@ Observe the generated `+Makefile+` to see all available options.
|
|||
%{assistant_path}/icons/crt/%{shortname}*
|
||||
%{assistant_path}/meta/%{shortname}.yaml
|
||||
....
|
||||
|
||||
Category:Packaging_guidelines[Category:Packaging guidelines]
|
||||
|
|
|
|||
|
|
@ -52,5 +52,3 @@ if st and st.type == "link" then
|
|||
os.remove(path)
|
||||
end
|
||||
....
|
||||
|
||||
Category:Packaging_guidelines[Category:Packaging guidelines]
|
||||
|
|
|
|||
|
|
@ -143,5 +143,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]
|
||||
|
|
|
|||
|
|
@ -242,5 +242,3 @@ cp -pr * %{buildroot}%{drupal7_themes}/%{theme}/
|
|||
* ddd MMM DD YYYY __NAME__ <__EMAIL__> __VERSION__-1
|
||||
- Initial package
|
||||
....
|
||||
|
||||
Category:Packaging_guidelines[Category:Packaging guidelines]
|
||||
|
|
|
|||
|
|
@ -204,5 +204,3 @@ However, we end up with the plugin classes themselves being expanded in the `+or
|
|||
=== 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]
|
||||
|
|
|
|||
|
|
@ -360,5 +360,3 @@ It is recommended to derive greater-than-or-equal-to valued versioned dependenci
|
|||
=== 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]
|
||||
|
|
|
|||
|
|
@ -429,5 +429,3 @@ rm -rf $RPM_BUILD_ROOT
|
|||
|
||||
%changelog
|
||||
....
|
||||
|
||||
Category:Packaging_guidelines_obsolete[Category:Packaging guidelines obsolete]
|
||||
|
|
|
|||
|
|
@ -57,5 +57,3 @@ Switching between the environment-modules and Lmod implementations is done via a
|
|||
== 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]
|
||||
|
|
|
|||
|
|
@ -154,7 +154,3 @@ Once upon a time every Linux GUI application used the so-called _Core fonts_ ser
|
|||
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.
|
||||
|
||||
=== Notes
|
||||
|
||||
Category:Fonts_packaging[Packaging policy] Category:Packaging_guidelines[Category:Packaging guidelines]
|
||||
|
|
|
|||
|
|
@ -15,5 +15,3 @@ Fortran include files MUST be placed in the standard include directory: either d
|
|||
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+`).
|
||||
|
||||
Category:Packaging_guidelines[Category:Packaging guidelines]
|
||||
|
|
|
|||
|
|
@ -1,5 +1,3 @@
|
|||
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.
|
||||
|
||||
Category:Packaging_guidelines[Category:Packaging guidelines]
|
||||
|
|
|
|||
|
|
@ -64,5 +64,3 @@ Since GAP documentation must be installed under `+%{_gap_dir}/pkg+` for the buil
|
|||
== 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]
|
||||
|
|
|
|||
|
|
@ -73,5 +73,3 @@ BuildArch: noarch
|
|||
....
|
||||
|
||||
Note that the path has been stripped and `+.*+` has been appended.
|
||||
|
||||
Category:_Packaging_guidelines[Category: Packaging guidelines]
|
||||
|
|
|
|||
|
|
@ -818,5 +818,3 @@ rm -rf $RPM_BUILD_ROOT
|
|||
* Tue May 5 2009 Mattias Ellert <mattias.ellert@fysast.uu.se> - 10.2-3
|
||||
- Autogenerated
|
||||
....
|
||||
|
||||
Category:Packaging_guidelines[Category:Packaging guidelines]
|
||||
|
|
|
|||
|
|
@ -374,5 +374,3 @@ Packages compiling Haskell code without Cabal, ie directly with `+ghc+` or `+ghc
|
|||
* 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]
|
||||
|
||||
Category:Packaging_guidelines[Category:Packaging guidelines]
|
||||
|
|
|
|||
|
|
@ -107,5 +107,3 @@ PIDFile=/var/run/tog-pegasus/cimserver.pid
|
|||
[Install]
|
||||
WantedBy=multi-user.target
|
||||
....
|
||||
|
||||
Category:Packaging_guidelines[Category:Packaging guidelines]
|
||||
|
|
|
|||
|
|
@ -105,5 +105,3 @@ Note that GCJ packages contain `+.so+`s in `+%{_libdir}/gcj/%{name}+` but they a
|
|||
* JNI packages MUST follow guidelines of ordinary Java packages with exceptions listed here
|
||||
* 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]
|
||||
|
|
|
|||
|
|
@ -103,5 +103,3 @@ Some Node.js modules include parts that can be used in the browser or by other s
|
|||
* One `+js-foo+` package that contains the pure JavaScript portion, following these guidelines.
|
||||
|
||||
* 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]
|
||||
|
|
|
|||
|
|
@ -19,5 +19,3 @@ Requires: libreoffice-core
|
|||
install -d -m 755 $RPM_BUILD_ROOT%{_libdir}/libreoffice/share/extensions/%{extname}
|
||||
unzip -q target/lib/%{extname}.oxt -d $RPM_BUILD_ROOT%{_libdir}/libreoffice/share/extensions/%{extname}
|
||||
....
|
||||
|
||||
Category:Packaging_guidelines[Category:Packaging guidelines]
|
||||
|
|
|
|||
|
|
@ -147,5 +147,3 @@ License: Python and (BSD with advertising and QPL)
|
|||
== 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]
|
||||
|
|
|
|||
|
|
@ -131,5 +131,3 @@ All implementations should be modified to load common-lisp-controller's %\{_sysc
|
|||
== 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]
|
||||
|
|
|
|||
|
|
@ -79,5 +79,3 @@ Requires: %{name}%{?_isa} = %{?epoch:%{epoch}:}%{version}-%{release}
|
|||
%{_libdir}/lib%{name}.so
|
||||
%{_includedir}/%{name}.h
|
||||
....
|
||||
|
||||
Category:Packaging_guidelines[Category:Packaging guidelines]
|
||||
|
|
|
|||
|
|
@ -568,5 +568,3 @@ find $RPM_BUILD_ROOT -name "*.la" -delete
|
|||
* Sun Apr 15 2012 Erik van Pienbroek <epienbro@fedoraproject.org> - 1.0.0-1
|
||||
- Initial release
|
||||
....
|
||||
|
||||
Category:Packaging_guidelines[Category:Packaging guidelines]
|
||||
|
|
|
|||
|
|
@ -125,5 +125,3 @@ Was done for a brief period when we attempted to package mono apps as noarch. It
|
|||
* *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.
|
||||
* *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]
|
||||
|
|
|
|||
|
|
@ -304,5 +304,3 @@ carry the prefix "tex-".
|
|||
== Authorship
|
||||
|
||||
The original author of these guidelines was link:TomCallaway[Tom 'spot' Callaway]. They are now maintained by the link:Packaging_Committee[Packaging Committee] with input from the Fedora community.
|
||||
|
||||
Category:Packaging_guidelines
|
||||
|
|
|
|||
|
|
@ -218,5 +218,3 @@ Then, in both the original package and the compatibility package, change the `+%
|
|||
One of the packages must additionally provide a symlink from the usual location to the versioned location described above. For instance, `+%{nodejs_sitelib}/uglify-js+` would point to `+%{nodejs_sitelib}/uglify-js@2+` in the previous example. Typically the newest package should provide this symlink, but it might be prudent for the older version to provide it instead when introducing such a package into an existing Fedora release, so as not to break dependent packages. The symlink can then be migrated to the newest version in the next Fedora release.
|
||||
|
||||
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]
|
||||
|
|
|
|||
|
|
@ -149,5 +149,3 @@ OCaml scripts do not need to be changed (unless resolving the security issue req
|
|||
* 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.
|
||||
|
||||
Category:Packaging_guidelines[Category:Packaging guidelines]
|
||||
|
|
|
|||
|
|
@ -208,5 +208,3 @@ Actuarial functions for Casualty and Property lines.
|
|||
=== 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]
|
||||
|
|
|
|||
|
|
@ -39,5 +39,3 @@ fi
|
|||
%postun
|
||||
unopkg list --shared > /dev/null 2>&1 || :
|
||||
....
|
||||
|
||||
Category:Packaging_guidelines[Category:Packaging guidelines]
|
||||
|
|
|
|||
|
|
@ -369,7 +369,3 @@ Or you can generate one; make sure you have the php-pear-PEAR-Command-Packaging
|
|||
....
|
||||
pear make-rpm-spec Foo.tgz
|
||||
....
|
||||
|
||||
== References to the Fedora PHP Packaging Guidelines
|
||||
|
||||
Category:PHP Category:Packaging_guidelines[Category:Packaging guidelines]
|
||||
|
|
|
|||
|
|
@ -43,5 +43,3 @@ Patch0: jna-jni-path.patch
|
|||
== Why upstream?
|
||||
|
||||
Refer link:PackageMaintainers/WhyUpstream[ Why Upstream?]
|
||||
|
||||
Category:Packaging_guidelines[Category:Packaging guidelines]
|
||||
|
|
|
|||
|
|
@ -115,5 +115,3 @@ fi
|
|||
%{_datadir}/polkit-1/actions/org.fedoraproject.FirewallD1.desktop.policy
|
||||
%{_datadir}/polkit-1/actions/org.fedoraproject.FirewallD1.server.policy
|
||||
....
|
||||
|
||||
Category:Packaging_guidelines[Category:Packaging guidelines]
|
||||
|
|
|
|||
|
|
@ -188,5 +188,3 @@ PERL5_CPANPLUS_IS_RUNNING=1 to avoid CPAN entirely.
|
|||
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.
|
||||
|
||||
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]
|
||||
|
|
|
|||
|
|
@ -238,5 +238,3 @@ install -p -m 644 %{preupgrade_name}-%{preupg_results}/%{name}/group.xml %{build
|
|||
%{preupgrade_dir}/%{name}/*.{py,sh}
|
||||
%{preupgrade_dir}/%{name}/*.xml
|
||||
....
|
||||
|
||||
Category:Packaging_guidelines[Category:Packaging guidelines]
|
||||
|
|
|
|||
|
|
@ -293,5 +293,3 @@ The following briefly summarizes the guidelines for reviewers to go over:
|
|||
* *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*: If you build a python module you should use the `+%python_provide+` macro.
|
||||
* *Should*: A package which is used by another package via an egg interface should provide egg info.
|
||||
|
||||
Category:Packaging_guidelines[Category:Packaging guidelines] Category:Python
|
||||
|
|
|
|||
|
|
@ -312,5 +312,3 @@ Note that this *does disable* the compilation of files in `+/usr/lib(64)?/python
|
|||
|
||||
In Fedora 27 or earlier, use `+%global __os_install_post %(echo '%{__os_install_post}' | sed -e 's!/usr/lib[^[:space:]]*/brp-python-bytecompile+`:space:[`+:space:+`]`+.*$!!g')+`
|
||||
instead of the `+%undefine+` line above.
|
||||
|
||||
Category:Packaging_guidelines[Category:Packaging guidelines] Category:Python
|
||||
|
|
|
|||
|
|
@ -102,5 +102,3 @@ Egg metadata provide some features that are to be avoided as part of the packagi
|
|||
* 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
|
||||
|
|
|
|||
|
|
@ -497,5 +497,3 @@ The following are a summary of the guidelines for reviewers to go over when a py
|
|||
== 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
|
||||
|
|
|
|||
|
|
@ -218,5 +218,3 @@ 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[Category:Packaging guidelines]
|
||||
|
|
|
|||
|
|
@ -62,5 +62,3 @@ The macros are usually used with `+rpmbuild --define+` to specify which director
|
|||
%{_srcrpmdir} %{_topdir}/SRPMS
|
||||
%{_buildrootdir} %{_topdir}/BUILDROOT
|
||||
....
|
||||
|
||||
Category:Packaging_guidelines[Category:Packaging guidelines]
|
||||
|
|
|
|||
|
|
@ -46,5 +46,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]
|
||||
|
|
|
|||
|
|
@ -369,5 +369,3 @@ popd
|
|||
* Make sure to include the version of the tests in the source name, so that when updating to new version, rpmbuild will fail because it won't find the proper `+%{SOURCE1}+` (and this will remind you to update the tests, too).
|
||||
* 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]
|
||||
|
|
|
|||
|
|
@ -332,5 +332,3 @@ which use %{crate} from crates.io.
|
|||
%license LICENSE-APACHE LICENSE-MIT
|
||||
%{cargo_registry}/%{crate}-%{version}/
|
||||
....
|
||||
|
||||
Category:Packaging_guidelines[Category:Packaging guidelines]
|
||||
|
|
|
|||
|
|
@ -117,5 +117,3 @@ There's a lot of confusing terminology here, but really what we're asking for is
|
|||
Your application should Do The Right Thing for certificates in PKCS#11, without the user having to explicitly specify which PKCS#11 provider to use and without the user having to learn some weird non-standard way of asking for it.
|
||||
|
||||
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]
|
||||
|
|
|
|||
|
|
@ -354,5 +354,3 @@ if [ "$1" = 0 ] && [ -f %{_sysconfdir}/shells ] ; then
|
|||
sed -i '\!^/bin/foo$!d' %{_sysconfdir}/shells
|
||||
fi
|
||||
....
|
||||
|
||||
Category:Packaging_guidelines[Category:Packaging guidelines] Category:Packaging_guidelines[Category:Packaging guidelines]
|
||||
|
|
|
|||
|
|
@ -168,7 +168,3 @@ Sometimes this does not work because the upstream cgi tries to parse the fragmen
|
|||
# http://dev.mysql.com/downloads/mysql/5.1.html
|
||||
Source0: mysql-5.1.31.tar.gz
|
||||
....
|
||||
|
||||
'''''
|
||||
|
||||
Category:Packaging_guidelines[Category:Packaging guidelines]
|
||||
|
|
|
|||
|
|
@ -82,5 +82,3 @@ Since the init script is run by root, before the daemon drops privileges, why no
|
|||
* This code would need to be implemented in every init script packaged. Using tmpfiles.d we can cut down on the number of places we have to put code like this.
|
||||
* Having to add the mkdir to the systemd unit files when tmpfiles.d is already in place introduces the need to run shell code for that init script. Systemd is no longer able to handle starting the daemon by itself which slows things down. The shell code also introduces imperative constructs into the otherwise declarative structure which is nice to avoid.
|
||||
* Properly labelling the created directories is done automatically by the tmpfiles.d mechanism but would have to be manually done by the init script.
|
||||
|
||||
Category:Packaging_guidelines[Category:Packaging guidelines]
|
||||
|
|
|
|||
|
|
@ -79,5 +79,3 @@ exit 0
|
|||
* 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.
|
||||
* 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]
|
||||
|
|
|
|||
|
|
@ -119,5 +119,3 @@ In this case, you MAY set to an in integer beginning with '1' and increasing by
|
|||
== 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]
|
||||
|
|
|
|||
|
|
@ -108,5 +108,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]
|
||||
|
|
|
|||
|
|
@ -87,5 +87,3 @@ Web Asset packages that consist solely of images, such as a set of icons, may be
|
|||
All system fonts (available in `+%{_datadir}/fonts+`) are automatically made available in `+%{_webassetdir}/fonts/+` via a symlink. For more information on packaging system fonts, see the Packaging:FontsPolicy[font guidelines]. Please note that [Web_Assets/Fonts|only fonts available in the Fedora package collection are made available on HTTP servers by default].
|
||||
|
||||
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]
|
||||
|
|
|
|||
|
|
@ -97,5 +97,3 @@ It is required that the original source files from which the code was generated
|
|||
It is preferred, but not required, that the tools used to generate such code be free software and included in Fedora.
|
||||
|
||||
It is suggested, but not required, that such code be regenerated as part of the build process. The means for doing this are entirely specific to the individual package being built, but it may happen automatically if the necessary dependencies are present at build time.
|
||||
|
||||
Category:Packaging_guidelines[Category:Packaging guidelines]
|
||||
|
|
|
|||
|
|
@ -103,5 +103,3 @@ rm -rf %{buildroot}
|
|||
|
||||
%changelog
|
||||
....
|
||||
|
||||
Category:Packaging_guidelines[Category:Packaging guidelines]
|
||||
|
|
|
|||
|
|
@ -1575,5 +1575,3 @@ Some applications, languages and build systems have specific guidelines written
|
|||
* Packaging:Tcl[Tcl/Tk extensions]
|
||||
* Packaging:Web_Assets[Shared web assets]
|
||||
* Packaging:WordPress_plugin_packaging_guidelines[Wordpress extensions]
|
||||
|
||||
Category:Packaging_guidelines[Category:Packaging guidelines]
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue