Conflicts Draft Proposal
by Tom Callaway
I drafted a proposal for when it is ok to use Conflicts: (almost never):
http://fedoraproject.org/wiki/PackagingDrafts/Conflicts
Keep in mind that while it is not stated in the Draft, the kernel is
considered a special case, and I feel strongly that most (if not all) of
its existing Conflicts: will be approved.
Fedora Packaging Committee Members should vote via email on this issue,
as we did not have quorum in the IRC meeting to vote.
~spot
16 years, 5 months
Request to drop %(%{__id_u} -n) in preferred buildroot
by Axel Thimm
Hi,
I think the `preferred buildroot' is not really making sense. The
above has developed historically out of a misunderstanding in ancient
buildroot times.
When people were building as root and BuildRoots were defined as
%{_tmppath}/%{name}-%{version}-root, some considered "root" to mean
the uid of the builder. Later %release was added and some replaced
root with `id -un`. Even later some realized that root was referring
to the BuildRoot and in order to play safe added both.
I'm using %{_tmppath}/%{name}-%{version}-%{release}-root in my
packages and someone is now nitpicking on why not using the preferred
BuildRoot as given in the guidelines. Instead of locally fighting a
BuildRoot battle, I'd better get the guidelines fixed ;)
Also consider what this really is about: Deambiguifying the BuildRoot
per package makes sense as there may be several build processes
sharing the same filesystem (either locally or through NFS), but
deambiguifying the build user, too, means that we assume that the same
EVR package will be possibly built on the same filesystem by
different users? And even simultaneously?
It makes more sense to include a conditional epoch or target/arch in
the buildroot that the builder. In fact the best thing for a
buildsystem is to override the buildroot adding a build-id to it
anyway.
--
Axel.Thimm at ATrpms.net
16 years, 5 months
iconcache, v0.5
by Rex Dieter
FYI, updated iconcache proposal v0.5:
* nixed xdg-utils.
* Updated motivations/justifications,
* gtk2 implementation suggestions/links,
http://fedoraproject.org/wiki/PackagingDrafts/ScriptletSnippets/iconcache
Looks like Core folks won't settle for anything in between status-quo
and 100% fix (no in-between-compromising like using xdg-utils), so let's
give it a shot.
This time round, I'll try to put all relavent suggestions, comments,
dialog on the wiki. Hopefully, that will help keep those not following
the intimate details of the ml threads informed.
-- Rex
16 years, 5 months
Packaging/PHP : add channels packaging proposal.
by Remi Collet
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Here is another update proposal for the PHP Guidelines.
Context : some packages are provided on other channels than the default
one (pear.php.net)
The channel definition must be installed (in the pear registry) to allow
the build, so this require an RPM of channel definition available in the
repository :
- - to build the package in mock.
- - to install the package
Note : i don't keep Requires php, as php-pear already require php and
php-cli.
Regards.
- ---------------------------------------------------------
==Naming scheme==
* CHANNEL definition packages should be named
php-channel-channelname-%{version}-%{release}.noarch.rpm
==Requires and Provides==
CHANNEL definition Packages
* Requires: php-pear(PEAR)
* Provides: php-channel(channelname)
PEAR Packages
* Requires: php-pear(PEAR)
* Requires: php-channel(channelname) if needed
* Provides: php-pear(foo) or php-pear(channelname/foo)
==Macros and scriptlets==
CHANNEL definition
%post
if [ $1 -eq 1 ] ; then
%{__pear} channel-add %{pear_xmldir}/%{channel_name}.xml > /dev/null || :
else
%{__pear} channel-update %{pear_xmldir}/%{channel_name}.xml >
/dev/null ||:
fi
%postun
if [ $1 -eq 0 ] ; then
%{__pear} channel-delete %{channel_name} > /dev/null || :
fi
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFFlVpJYUppBSnxahgRArDEAJ4jSt5d9UNxgnCldXdApC9fyg8L2wCg3H/z
yojj8Exk1QfwtjqBtkJ4GKg=
=Qb6D
-----END PGP SIGNATURE-----
16 years, 5 months
(Un)packaging partly patented software
by Axel Thimm
Hi,
I think I had read somehwere, or we just discussed it (?), that for
tarballs carrying potential patent infringing bits it is not enough to
build/package the other parts, but that also the src.rpm needs to be
kept clean.
E.g. the upstream tarball needs to be unpacked, the patent encumbered
bits removed/patched out and the result repackaged into a new tarball
(for example into foo-1.2-patentfree.tar.gz)
Am I remembering correctly? Do we have something like a procedure in
the wiki on creating these modified tarballs and commenting the
specfile approriately (I couldn't find anything when searching for
"patents", but there were perhaps too many hits ...).
If not shouldn't we come up with one? The procedure needs to be
documented and be reproducable for reviewers to be able to confirm
that the tarball "matches" upstream indeed, since they won't have any
nice md5sum method to compare.
--
Axel.Thimm at ATrpms.net
16 years, 5 months
Packaging/PHP : some update proposal
by Remi Collet
Here is some updates proposal for the
Guidelines for packaging PHP addon modules
1 ------ No file in BUILD directory
PEAR & PECL Packages
The source archive contains a package.xml outside any directory, so you
should/must use
%setup -q -c
2 ----- Initial spec.
PEAR Packages
To create your specfile, you could use the default template provided by
rpmdevtools or generate one with the command "pear make-rpm-spec
Sources.tgz" (install php-pear-PEAR-Command-Packaging)
3 ---- API version check
PECL Packages
With php-5.1.6-3.3 on FC6 and php-5.2.0-8 on rawhide php-common now
provide php-zend-api.
This exact version must be require by pecl extension.
The php-common in Fedora Core 7 and above (version 5.2.0-8) provides
several useful macros:
%{php_core_api}
%{php_zend_api}
%{php_pdo_api}
Solution 1 (using the macros, only available on rawhide)
%if %{?php_zend_api}0
Requires: php_zend_api = %{php_zend_api}
%endif
Solution 2 (not using the /etc/rpm/macros.php)
%global php_zendapi %((echo 0; php -i 2>/dev/null | sed -n 's/^PHP
Extension => //p') | tail -1)
%if %{fedora} >= 6
Requires: php_zend_api = %{php_zendapi}
%endif
We can also post a RFE on php to also provide the macros on FC6
---
Some comments.
A load time, PHP check that each extension is compatible.
php_dl.c compare ZEND_MODULE_API_NO value at php build time and at
extension build time.
If this values doesn't match, the extension is not loaded and an error
is displayed :
> PHP Warning: PHP Startup: mailparse: Unable to initialize module
> Module compiled with module API=20060613, debug=0, thread-safety=0
> PHP compiled with module API=20050922, debug=0, thread-safety=0
> These options need to match
>
php-abi (PHP_API_VERSION) is 20041225 for a very long time.
php-zend-abi (ZEND_MODULE_API_NO) is the true API version need to check
extension compatibility
Ex : php-5.1.4, 5.1.5, 5.1.6
PHP Api Version: 20041225
Zend Module Api No: 20050922
php-5.2.0
PHP Api Version: 20041225
Zend Module Api No: 20060613
See Bugzilla #212804
Requires: php-api could be keep, but is not very useful
Thanks for your comments,
I could edit the wiki if this is approved and if you want me to do it.
Remi.
P.S. i hope this is clear ?
16 years, 5 months
Proposal to limit file deps
by Toshio Kuratomi
Hey all, I've just added a draft proposal for limiting file dependencies
in packages. It's a "should" recommendation at this point.
http://www.fedoraproject.org/wiki/PackagingDrafts/FileDeps
= File Deps Guideline =
== Problem ==
Resolving file dependencies can be a bottleneck when running yum. With
our current repodata format, information on which package owns files
in /etc and the bin directories (/bin /sbin /usr/bin /usr/sbin) are kept
in primary.xml. All other file deps are kept in filelist.xml. This
means that anytime yum has to resolve a file dep in /etc or a bin
directory it can just download primary.xml to resolve it. If the file
dep is outside of those directories, yum has to download and parse a
second xml file, filelist.xml, which is much larger than primary.xml.
Fedora 6 repodata compressed and uncompressed:
|| ||primary.xml||filelist.xml||
||Core ||1M/7.6M ||3.1M/39.2M||
||Extras ||4.7M/11.7M ||4M/50.8M||
||Updates||0.4M/4.2M ||2.1M/27.5M||
The compressed size has direct bearing on the additional time it will
take to download the additional filelist.xml. The uncompressed size is
one indicator of how much additional time is needed to parse for the
file that satisfies the dependency. If yum does not need to refresh its
primary.xml and filelist.xml (because it downloaded a copy previously
and the repository has not been updated since), yum won't have to parse
a new file and the filelist info will be quicker to find (as the file
will have been parsed into an sqlite database), however this is the
exception rather than the rule.
If we can avoid having to download and parse filelist.xml, we can
greatly speed up yum's dependency resolution times.
== Proposed Guideline ==
'''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.
Using file dependencies outside of /etc, /bin, /sbin, /usr/bin,
or /usr/sbin requires yum (and other depsolvers using the repomd format)
to download and parse a large xml file looking for the dependency.
Helping the depsolvers avoid this processing by depending on the package
instead of the file saves our end users a lot of time.
-Toshio
16 years, 5 months
printing textual messages in %post etc.?
by Ralf Corsepius
Hi,
Do the GuideLines/Does the FPC have an opinion on rpms intentionally
printing out textual messages during installs?
At least, I could not find a corresponding paragraph in the GuideLines.
Background: tripwire's spec (Currently under review) contains this:
%post
...
# Print getting started help message
if [ $1 -eq 1 ]; then
echo To configure tripwire, read: %_docdir/%{name}-%{version}/README.Fedora
fi
I don't have a strong opinion on this and actually am ambivalent.
On one hand, such messages can be helpful to users.
On the other hand, in general, rpm-installs should be silent as much as
possible.
Furthermore, I am not sure if printing such messages is safe. How does
rpm handle such messages/ to which file descriptor will they be piped
(stdout, stderr ...)? Will they desturb installers (yum, apt, shell
scripts, pirut, yumex, synaptic, ...) and what happens with such
messages during unsupervised installs?
Ralf
[1] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=203864
16 years, 5 months
Re: icon cache scriplet guideline update
by Rex Dieter
Rex Dieter wrote:
> Callum Lerwick wrote:
>> On Wed, 2006-12-20 at 07:43 -0600, Rex Dieter wrote:
>>> Because, frankly, poo-pooing the current proposal/guidelines in favor
>>> of some handy-wavy theoretical lacking-actual-implementation
>>> solution, is no solution.
>>
>> Well, the point is, the current proposal does not address the "multiple
>> packages needlessly updating caches multiple times" problem at all.
>
> Fair enough, I'll investigate hooking into rpm's %posttrans hooks. My
> findings so far are promising.
I formally withdraw the iconcache proposal as-is, pending investigation
of the previously unaddressed "needlessly updating cache multiple times"
issue.
-- Rex
16 years, 5 months
Java (jpackage) naming scheme rehash.
by Jesse Keating
A while ago we had a long discussion about the naming of jpackage packages
within Fedora. Currently the naming convention that is used by Fedora for
jpackage packages does not mesh with the Fedora Packaging Guidelines.
See http://fedoraproject.org/wiki/PackagingDrafts/JavaPackageNaming
There are a number of proposals on that page, but the one I'd like to focus on
is http://fedoraproject.org/wiki/PackagingDrafts/JavaPackageNaming#Proposal_1
This changes how we number the Fedora spins of the jpackage packages, but
doesn't introduce any extra chars into the version/release.
Please, jpackage folks who are now on this list, review the page and the
proposal and comment / suggest / flame / whatever. Please note that part of
the core/extras merge, every package will be reviewed, and currently the
jpackage packages (of which there are many, and some 90~ new ones pending for
maven2) will not pass the review. Resolution on this matter is urgent.
Thanks!
--
Jesse Keating
Release Engineer: Fedora
16 years, 5 months
