Changes to the Packaging Guidelines
 

On 12/15/2010 03:25 PM, Ville Skyttä wrote:
> In my opinion the guideline should be something like this instead of blindly
> banning executable %doc files:
>
> "Files marked as documentation must not cause additional dependencies that
> aren't satisfied by the package itself or its dependency chain as it would be
> if none of its files marked as documentation were included in the package."

I would be okay with that. Might be slightly harder to enforce though.

~tom

==
Fedora Project
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging

Changes to the Packaging Guidelines
 

Tom Callaway wrote, at 02/05/2011 02:18 AM +9:00:
>
> In some situations, this is not a problem, but there are some situations
> where it does matter:
>
> * A library that is explicitly Required (example a dlopen'd library)
> * The dependency from one -devel packages that is not noarch to
> another -devel package.
> * A non-noarch subpackage's dependency on its main package or another
> subpackage (e.g., libfoo-devel depends on libfoo, or fooapp-plugins
> depends on foo-app).
>
> The Packaging Guidelines (and Naming Guidelines) have been amended to
> reflect that %{?_isa} must be used for Explicit Requires and Provides
> that match those situations.
>
> http://fedoraproject.org/wiki/Packaging:Guidelines#Requires
> http://fedoraproject.org/wiki/Packaging:Guidelines#Explicit_Requires
> http://fedoraproject.org/wiki/Packaging:Guidelines#Requiring_Base_Package
> https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Renaming.2Freplacing_ex isting_packages
>

So
- Does this mean that mass packaging change will occur?
- Currently rpmbuild detects pkgconfig .pc dependencies, so for -devel
packages containing pkgconfig .pc file now we usually don't have write
dependency for another -devel subpackage like "Requires: foo-devel"
explicitly (as rpmbuild automatically adds "Requires: pkgconfig(foo)")
(and I guess we shouldn't write such explicit requires when possible
and let rpmbuild handle such dependencies automatically)

If dependencies between (non-arch) -devel packages must be changed to
explicit arch-specific, it means that rpmbuild should also be changed
to add arch-specific pkgconfig Provides / Requires (e.g.
pkgconfig(x11)(x86-64) instead of current pkgconfig(x11)) ?

- And as far as I am correct this also applies to other virtual Provdes/Requires
rpmbuild will automatically add.
- For example perl(BDB) devendency on perl-Coro.x86_64 will be satisfied by
perl-BDB.i686? Then this type of all virtual provides / requires rpmbuild
will handle must be changed??

Unless I am wrong to make things consistent such changes on rpmbuild must
be required. However is this actually we want?

Regards,
Mamoru
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging

Changes to the Packaging Guidelines
 

When writing explicit BuildRequires and Requires in specs (particularly that could be used by other distros), is there a specific reason not to use (for example)*pkgconfig(libcurl), where the package in question could be libcurl-devel or curl-devel or ambiguous-devel that provides it? Same for mono(nunit.core). Is there a use case in which it isn't beneficial, other than older RPM systems that don't do it internally?



Isaac Fischer
+1 (210) 775-2890
xwaver@gmail.com



IM: xwaver@gmail.com xwaver118 xwaver118

Signature powered by WiseStamp*


On Fri, Feb 4, 2011 at 4:34 PM, Tom Callaway <tcallawa@redhat.com> wrote:

On 02/04/2011 02:24 PM, Mamoru Tasaka wrote:

> - Does this mean that mass packaging change will occur?

> - Currently rpmbuild detects pkgconfig .pc dependencies, so for -devel

> * *packages containing pkgconfig .pc file now we usually don't have write

> * *dependency for another -devel subpackage like "Requires: foo-devel"

> * *explicitly (as rpmbuild automatically adds "Requires: pkgconfig(foo)")

> * * *(and I guess we shouldn't write such explicit requires when possible

> * * * and let rpmbuild handle such dependencies automatically)

>

> * *If dependencies between (non-arch) -devel packages must be changed to

> * *explicit arch-specific, it means that rpmbuild should also be changed

> * *to add arch-specific pkgconfig Provides / Requires (e.g.

> * *pkgconfig(x11)(x86-64) instead of current pkgconfig(x11)) ?

>

> - And as far as I am correct this also applies to other virtual Provdes/Requires

> * *rpmbuild will automatically add.

> * *- For example perl(BDB) devendency on perl-Coro.x86_64 will be satisfied by

> * * *perl-BDB.i686? Then this type of all virtual provides / requires rpmbuild

> * * *will handle must be changed??

>

> * *Unless I am wrong to make things consistent such changes on rpmbuild must

> * *be required. However is this actually we want?





The Guidelines currently only cover Explicit Requires and Provides, the

examples you point out are all implicit (Virtual). That isn't to say

that perhaps these items should also be arch specific, where applicable,

just that they are not yet addressed in the guidelines.



~tom



==

Fedora Project

--

packaging mailing list

packaging@lists.fedoraproject.org

https://admin.fedoraproject.org/mailman/listinfo/packaging



--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging

Changes to the Packaging Guidelines
 

Here are the latest set of changes to the Fedora Packaging Guidelines:

---

The Emacs packaging guidelines were updated to handle cases where a
package's principal functionality does not require (X)Emacs, but the
package also includes some auxiliary Elisp files to provide support for
the package in (X)Emacs.

https://fedoraproject.org/wiki/Packaging:Emacs

---

The Scriptlet Snippets section dealing with the order that scriptlets
are invoked has been updated to include %trigger scripts.

https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Scriptlet_Ordering

---

A subsection was added to the Packaging Guidelines section on Filesystem
Layout in which it is made explicit that binaries in /bin or /sbin must
NOT depend on any libraries in /usr/lib or /usr/lib64.

https://fedoraproject.org/wiki/Packaging:Guidelines#Binaries_in_.2Fbin_and_.2Fsbi n


---

The section on Epochs was improved, and clarifying language about Epoch
use in Requires was added to the Packaging Guidelines.

https://fedoraproject.org/wiki/Packaging:Guidelines#Use_of_Epochs
https://fedoraproject.org/wiki/Packaging:Guidelines#Requires

---

New guidelines were added covering the packaging of Ada programs.

https://fedoraproject.org/wiki/Packaging:Ada

---

The section on Boostrapping in the Treatment of Bundled Libraries page
in the Packaging Guidelines has been amended to add the following:

Packages which are built in such a bootstrapping mode must not be tagged
for a final release (or pushed as an update for any stable release). FPC
will track the progress of approved bootstrapping exceptions via the
ticket requesting the bootstrap bundling exception.

https://fedoraproject.org/wiki/Packaging:Treatment_Of_Bundled_Libraries#Bootstrap ping

---

Macro forms of system executables (such as %{__rm}) should not be used
except when there is a need to allow the location of those executables
to be configurable.

https://fedoraproject.org/wiki/Packaging:Guidelines#Macros

---

These guidelines (and changes) were approved by the Fedora Packaging
Committee (FPC).

Many thanks to Hans Niedermann, Jonathan Underwood, Pavel Zhukov, and
all of the members of the FPC, for assisting in drafting, refining, and
passing these guidelines.

As a reminder: The Fedora Packaging Guidelines are living documents! If
you find something missing, incorrect, or in need of revision, you can
suggest a draft change. The procedure for this is documented here:
https://fedoraproject.org/wiki/Packaging/Committee#GuidelineChangeProcedure

Thanks,

~spot
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging

Changes to the Packaging Guidelines
 

Here are the changes to the Fedora Packaging Guidelines for this week:

---

The Packaging:PHP guidelines have been updated to reflect that PEAR
documentation provided by upstream are installed in %{pear_docdir},
should stay there, and must be marked as %doc.

Additionally, the definition of pear_docdir has been defined as
%{_docdir}/pear.

https://fedoraproject.org/wiki/Packaging:PHP

---

The Java guidelines have been updated to add information and sample
template for Maven 3 (Fedora 15+).

https://fedoraproject.org/wiki/Packaging:Java

---

These guidelines (and changes) were approved by the Fedora Packaging
Committee (FPC).

Many thanks to Remi Collet, Stanislav Ochotnicky, and all of the members
of the FPC, for assisting in drafting, refining, and passing these
guidelines.

As a reminder: The Fedora Packaging Guidelines are living documents! If
you find something missing, incorrect, or in need of revision, you can
suggest a draft change. The procedure for this is documented here:
https://fedoraproject.org/wiki/Packaging/Committee#GuidelineChangeProcedure

Thanks,

~spot
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging

Changes to the Packaging Guidelines
 

Here are the latest changes to the Fedora Packaging Guidelines:

---

A new set of guidelines have been written for handling systemd in packages:

https://fedoraproject.org/wiki/Packaging:Guidelines:Systemd
https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Systemd

---

A new set of guidelines have been written for packaging Octave packages:
https://fedoraproject.org/wiki/Packaging:Octave

---

Some clarification was added to the Guidelines section on Macros.
Previously, it said:

"Use macros instead of hard-coded directory names (see
Packaging:RPMMacros )."

Now, that line has been replaced with:

"Packagers are strongly encouraged to use macros instead of hard-coded
directory names (see Packaging:RPMMacros ). However, in situations where
the macro is longer than the path it represents, or situations where the
packager feels it is cleaner to use the actual path, the packager is
permitted to use the actual path instead of the macro. There are several
caveats to this approach:

* The package must be consistent. For any given path, within the same
spec, use either a hard-coded path or a macro, not a combination of the two.
* %{_libdir} must always be used for binary libraries due to multi-lib,
you may not substitute a hard-coded path. "

https://fedoraproject.org/wiki/Packaging:Guidelines#Macros

---

The Guidelines covering MinGW packaging have been updated for Fedora 16.
The previous guidelines still apply for older Fedora releases (Fedora 15
and older) and all RHEL releases.

https://fedoraproject.org/wiki/Packaging:MinGW
https://fedoraproject.org/wiki/Packaging:MinGW_Old

---

The Packaging Guidelines have been updated to allow the use of /run and
to clarify that directory hierarchies not listed in the FHS are not
allowed unless listed in the Packaging Guidelines.

https://fedoraproject.org/wiki/Packaging:Guidelines#Filesystem_Layout

---

In the past (pre rpm 4.4), it was necessary to have a %defattr section
at the beginning of each %files section, but this is now the default and
no longer necessary to explicitly include.

The guidelines have been updated in numerous places to remove references
to hard-coded %defattr sections.

https://fedoraproject.org/wiki/Packaging/Guidelines#File_Permissions

---

The Scriptlets for GSettings have been updated to:

%postun
if [ $1 -eq 0 ] ; then
glib-compile-schemas %{_datadir}/glib-2.0/schemas &> /dev/null || :
fi

%posttrans
glib-compile-schemas %{_datadir}/glib-2.0/schemas &> /dev/null || :

https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#GSettings_Schema

---

These guidelines (and changes) were approved by the Fedora Packaging
Committee (FPC).

Many thanks to Christopher Aillon, Richard W. M. Jones, Erik van
Pienbroek, Lennart Poettering, Orion Poplawski, Julian Sikorski, and all
of the members of the FPC, for assisting in drafting, refining, and
passing these guidelines.

As a reminder: The Fedora Packaging Guidelines are living documents! If
you find something missing, incorrect, or in need of revision, you can
suggest a draft change. The procedure for this is documented here:
https://fedoraproject.org/wiki/Packaging/Committee#GuidelineChangeProcedure

Thanks,

~spot
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging

Changes to the Packaging Guidelines
 

Tom Callaway wrote:
> The Packaging Guidelines have been updated to allow the use of /run and
> to clarify that directory hierarchies not listed in the FHS are not
> allowed unless listed in the Packaging Guidelines.
>
> https://fedoraproject.org/wiki/Packaging:Guidelines#Filesystem_Layout

Something went wrong with the link to the FHS ticket for /run. The URL
contains a vertical bar that makes it invalid. I don't know the wiki syntax
well enough to say how it should be.

Björn Persson
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging

Changes to the Packaging Guidelines
 

>>>>> "BP" == Björn Persson <bjorn@rombobjörn.se> writes:

BP> Something went wrong with the link to the FHS ticket for /run.

Fixed, thanks. (A space was missing at the end of the URL.)

- J<
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging

Changes to the Packaging Guidelines
 

Here are the latest changes to the Fedora Packaging Guidelines:

---

A section has been added to the SysVInitScript guidelines covering the
optional situation where a package that uses systemd unit files as the
default also includes sysv initscripts in a subpackage:

https://fedoraproject.org/wiki/Packaging:SysVInitScript#Initscripts_in_addition_t o_systemd_unit_files

---

The GIO scriptlets have been changed to not conditionalize the %post
invocation. This works around a multilib issue.

https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#GIO_modules

---

The guideline that prohibits Fedora packages from using /srv has been
updated to better represent what the FHS has to say about /srv and to
clarify the expectations for Fedora packages which may be configured to
use /srv.

https://fedoraproject.org/wiki/Packaging:Guidelines#No_Files_or_Directories_under _.2Fsrv

---

It was brought to the FPC's attention that while the new Guidelines
covering MinGW packaging were technically correct, Fedora 16 did not yet
contain the necessary toolchain to support the new Guidelines, nor was
it clear that it would arrive in rawhide anytime soon.

Accordingly, the "old" MinGW guidelines were put back in place at:
https://fedoraproject.org/wiki/Packaging:MinGW

The "new" MinGW guidelines remain approved, but are not active and
packagers should not use them at this time. If/when the necessary
toolchain components are packaged in Fedora, these guidelines will be
re-enabled.

In addition, the current MinGW guidelines were improved slightly to
support the "new" SRPM naming standard. This is intended to prevent new
MinGW packages from having to be re-reviewed when the "new" MinGW
guidelines take effect.

---

These guidelines (and changes) were approved by the Fedora Packaging
Committee (FPC).

Many thanks to Kalev Lember, Matthew Miller, Michael Schwendt, and all
of the members of the FPC, for assisting in drafting, refining, and
passing these guidelines.

As a reminder: The Fedora Packaging Guidelines are living documents! If
you find something missing, incorrect, or in need of revision, you can
suggest a draft change. The procedure for this is documented here:
https://fedoraproject.org/wiki/Packaging/Committee#GuidelineChangeProcedure

Thanks,

~spot
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging

Changes to the Packaging Guidelines
 

Here is this week's change to the Fedora Packaging Guidelines:

---

The systemd guidelines on naming unit files have been amended to tell
packagers how to make compatibility symlinks for alternate service names
should their service have had a different name in the past.

http://fedoraproject.org/wiki/Packaging:Systemd#Naming

---

These guidelines (and changes) were approved by the Fedora Packaging
Committee (FPC).

Many thanks to the Fedora Community, and all of the members of the FPC,
for assisting in drafting, refining, and passing these guidelines.

As a reminder: The Fedora Packaging Guidelines are living documents! If
you find something missing, incorrect, or in need of revision, you can
suggest a draft change. The procedure for this is documented here:
https://fedoraproject.org/wiki/Packaging/Committee#GuidelineChangeProcedure

Thanks,

~spot
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging