packaging June 2006

packaging@lists.fedoraproject.org

31 participants
26 discussions

--vendor fedora, rationale/motivation?
by Rex Dieter 29 Nov '06

29 Nov '06

Per http://fedoraproject.org/wiki/Extras/FedoraDesktopEntryGuidelines: The vendor prefix (desktop-file-install --vendor=...) must be set to fedora". I don't understand the rationale/motivation behind requiring '--vendor fedora' I can, however, see that desktop-file-install's current implementation(*) of prepending %{vendor}- to the .desktop file name has some problems/issues: 1. .desktop filename now varies from upstream 2. --vendor may change when/if Extras bits are pulled into Core and/or RHEL. 3. *In particular*: when users start employing menu editors, since most(all?) of them base their customizations on the .desktop file name. -- Rex (*) If desktop-file-install's implementation instead followed something like kde's practice of using a vendor directory (e.g. /usr/share/applications/kde), then (1) and (3) would no longer be an issue.

4 6

PHP packaging policy notes
by Joe Orton 13 Jul '06

13 Jul '06

cc'ing Tim since we had lots of discussion about much of this stuff already and I'm not sure if he's on fedora-packaging (I didn't even know that list existed...) I was planning to add a "php-abi = <PHP_API_VERSION>" definition for C ABI versioning rather than php(ABI). Versioning language features in PHP a la MODULE_COMPAT_* is just not going to be feasible; the language is not well-defined enough nor stable enough for us to try and enforce versioning; plus stuff like "zend.ze1_compatibility_mode" means the exposed language is dependent on config options anyway. I don't see why it's necessary for a PEAR package to require php-pear(PEAR); that is somewhat equivalent to an RPM having "Requires: rpm"; it should be sufficient and correct for PEAR packages to simply "Requires: php-pear" AFAICS. Why should a PEAR package for foo provide php-foo? Not sure that's a good idea. On "Other Packages": an application written in PHP or such like should not have a php- prefix at all. A Smarty package should be called "smarty" (following the "upper-case is evil" rule of packaging). joe

13 94

New Mono Page for new guidelines
by Toshio Kuratomi 04 Jul '06

04 Jul '06

I've reworked the Mono page to reflect the new Guidelines we confirmed yesterday. If people want to take a look, it's here: http://fedoraproject.org/wiki/PackagingDrafts/Mono Changes are color coded: Red removes, green adds, blue is a justification for people who didn't attend the meeting and will be removed from the final copy. (I probably should have done this before the meeting rather than after, sorry.) If no one objects, I'll replace the current Packaging/Mono page this weekend. This is also an example of how the PackagingDrafts area could be used to work on new or revised Drafts. DavidLutterkort's RubyGems is another: http://fedoraproject.org/wiki/PackagingDrafts/RubyGems -Toshio

2 4

Re: rpms/haddock/devel haddock.spec,1.2,1.3
by Ralf Corsepius 30 Jun '06

30 Jun '06

On Thu, 2006-06-29 at 20:11 -0700, Jens Petersen wrote: > Author: petersen > > Update of /cvs/extras/rpms/haddock/devel > In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv16242 > > Modified Files: > haddock.spec > Log Message: > - set selinux unconfined_execmem_exec_t context to allow running under > targeted policy (#195821) > > > > Index: haddock.spec > =================================================================== > RCS file: /cvs/extras/rpms/haddock/devel/haddock.spec,v > retrieving revision 1.2 > retrieving revision 1.3 > diff -u -r1.2 -r1.3 > --- haddock.spec 29 Jun 2006 12:23:45 -0000 1.2 > +++ haddock.spec 30 Jun 2006 03:11:26 -0000 1.3 > @@ -10,6 +10,8 @@ > BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) > > BuildRequires: ghc libxslt docbook-style-xsl > +# need chcon > +PreReq: coreutils > > %description > Haddock is a tool for automatically generating hyperlinked documentation from > @@ -53,6 +55,11 @@ > %clean > rm -rf ${RPM_BUILD_ROOT} > > + > +%post > +/usr/bin/chcon -t unconfined_execmem_exec_t %{_libexecdir}/haddock.bin >/dev/null 2>&1 || : I think, we should implement a policy to make * Requires(pre|post) mandatory instead of PreReq * To make file deps on tools being used in %pre|post scripts mandatory. Ralf

4 5

Open issues with the PHP guidelines
by Jason L Tibbitts III 30 Jun '06

30 Jun '06

Here are some open issues I see with the PHP guidelines. I don't pretend that this is exhaustive: 1) The php(ABI) symbol. The current PHP package (in FC5) provides php-api = 20041225; is that sufficient? 2) Somethig equivalent to perl(:MODULE_COMPAT_version). The base PHP package eventually provides a whole bunch of these indicating what releases a module could have been written against and still work. So php v6 can drop compatibility for anything before v4.2 and the package can drop the corresponding :MODULE_COMPAT symbols. 3) It seems there are plenty of extensions which are neither PEAR nor PECL. We need to figure out conventions for those. 4) Scriptlets for registering PEAR packages. 5) There is some functionality in php-pear which only made it in as of some specific version, I think 1.4.9, which needs to be there in order for something work work. I don't know the exact details, but we need to document them. (As a bonus, it seems that package has a nonzero epoch as well.) 6) We need to work up specfile templates for all three situations if appropriate and get them into fedora-rpmdevtools. - J<

4 11

Re: License tag in packages
by Christopher Stone 30 Jun '06

30 Jun '06

This has been brought up in discussions before: https://www.redhat.com/archives/fedora-packaging/2006-March/msg00004.html Let's please not get into what the License Tag should hold. I really do not want to have packages that look like this: License: (GPL v2.0 or GPL v2.5) and ((MPL <= 1 or MPL =3) and (...)) and so on and so on... I think it should be clear to people that the Header fields are not meant to be used for this type of thing. A License tag should be something like: License: GPL or Artistic And actual license files should be placed in %doc. If we are to make any kind of standard on this, this is what it should be. Complicating the header tags is only going to complicate a lot of other things and confuse new packagers. The bottom line is that Header tags SHOULD not be used to determine the license. We want to encourage people to read the ACTUAL license itself, not our header tags. All licenses header tags should be as generalized as possible with just "GPL" for this very purpose. We do not want new packagers creating new header tags with all kinds of add ons.. License: GPL (except for clause 4 paragraph 2) and Artistic (with this added on....) etc... Once we go down the road of getting specific on the License tags then we will be adding all kinds of crap to the tag. Please let's not go there.

6 11

Namespace for cross-compilation tools?
by Jason L Tibbitts III 29 Jun '06

29 Jun '06

I was looking through the old review tickets and saw Ralf's submission of i386-rtems4.7-binutils. I don't believe that's a good name, but I can't really think of what it should be named. binutils-i386-rtems4.7 is one possibility, but then the gcc package would end up as gcc-newlib-i386-rtems4.7 which isn't logically connected to the binutils package. How about a "cross" namespace: cross-target-utility would give us cross-i386-rtems4.7-binutils and cross-i386-rtems4.7-gcc-newlib. - J<

8 29

Including License doc in packages
by Tim Jackson 29 Jun '06

29 Jun '06

There seems to be some confusion about including the license file in a package. I have been told two more-or-less contradictory things in two very similar packages. Unfortunately I can't find the wiki citation about this right now, but... php-pear-DB (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176733) "You do not have to bring in the license from an external source." php-pear-PEAR-Command-Packaging (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=185423) "SHOULD FIX: Include actual license in %doc" OK, so they're not actually contradictory. But we really ought to have some consistency here. If the license file isn't distributed with the package, we should have a clear policy: either we pull it in from an external source (maybe if that's "reasonably" possible, i.e. it's distributed on a public URL as a standalone file), or we don't. Otherwise we just lengthen package reviews and cause the precious time of packagers to be wasted with repeated pointless discussions and re-spins of packages. I really don't care what the policy is - I don't mind whether or not I have to pull external license files into my packages, I just think there should be an unambiguous policy so that I don't have to have this debate every time I do a package. Plus we have at least some consistency for users. Tim

3 5

Re: soname change policy proposal
by Axel Thimm 29 Jun '06

29 Jun '06

Hi, On Tue, Jun 27, 2006 at 09:42:03AM +0200, Hans de Goede wrote: > I've been thinking about this for a while and I think its time for a > brain dump, so here is a first shot at a soname change policy: I agree with Ville to prepend this with the (soft) requirement to try to remain ABI compatible within a distribution. > 1) When a package update would cause an soname change then a compat > package with the old libraries must be provided for all release repos, > that is for all repos except devel. > 1a) This compat package must be successfully build before a build of > the update causing the change may be requested. > 1b) If an update causing a soname change will only be build for devel > a compat package is not mandatory. In this case however other packagers > must be warned, with the warning containing a way for them to get the > new version. After the warning one must wait 7 days minimum before the > new version may be build. I had a similar suggestion some time back on this list, where I tried to persuade to use compat-like packages from the beginning, so that there is no need to rebuild new old-packages and rereview them, and also no need to sync compat vs new packages, coordinate rebuilds of all dependent packages and the like. It is also both backward and forward compatible: Simply subpackage the library components in libfoo<somajor> packages like Debian/Mandriva/ATrpms are doing. The libfoo<somajor>s are already your compat packages, when a new bump happens libfoo<somajor+1> simply appears in the repo next to the to be outphased libfoo<somajor>. Applications can be rebuilt against the new foo at their own pace. No review of the compat-becoming libfoo<somajor> is neccessary, since it hasn't changed, not only in theory, but it is still the same well-known binary with the same rpm metadata. No subtle rpm meta-obsoletes due to Provides: of some common resource (see Rex' comment). The only drawback: Your system doesn't cater for old and unused libfoo<soname-N>s. But that's fixable by tagging the packages. For example ATrpms uses Provides: shared-library-package, so all such compat packages can be found with a simple rpm -q --whatprovides shared-library-package, for example: # rpm -q --whatprovides shared-library-package libsrs_alt1-1.0-2_rc1.rhfc5.at libbeecrypt6-4.1.2-9.2_11.rhfc5.at libgcrypt11-1.2.2-11.rhfc5.at libspf2_2-1.2.5-4.rhfc5.at libgcrypt11-1.2.2-11.rhfc5.at libdirect-0.9_24-0.9.24-8.rhfc5.at libfusion-0.9_24-0.9.24-8.rhfc5.at Therefore one could easily implement a "package garbage collector". The poor man's implementation would look like rpm -q --qf '%{name}-%{version}-%{release}.%{arch}\n' --whatprovides shared-library-package | xargs -l1 rpm -e 2> /dev/null [As a side-effect you get multi-repo combinations working better, since repos are using different libfoo<soname+N>. This isn't an argument for Fedora Core/Extras, but it was the motivation for ATrpms to use that method. Still given the size of Fedora Extras having larger time windows for libfoo transitions of dependent packages is a good thing and comparable to the not-synced upgrading of libfoo<soname> in different repos, e.g. in Fedora Core/Extras semantics: no need for alarms at fedora-maintainers etc.] This scheme works very nice. The question I still have is whether to only apply it to a very selected set of packages known from the past to aggressively bump sonames, or whether it makes sense to have this as a general guideline to avoid ever getting into such a trap again. I guess in order to find out how well this scheme works the first model could be tried out on the problematic packages and depending on success/failure it could be extended to further packages. -- Axel.Thimm at ATrpms.net

1 0

License tag in packages
by Tim Jackson 28 Jun '06

28 Jun '06

Hi, There seems to be some disagreement about the use of "License" in packages. Over in : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=185423 we are getting into a bit of discussion which is not specific to that package. Basically, the question is: License: Foo License or License: Foo License vX.Y I'm in favour of the latter. Here's why: - legally, "Foo License v1" is wholly and entirely unrelated to "Foo License v2", unless there is a GPL-style "you may use any future version" clause. - despite the fact that License is for informational purposes and is not binding, we shouldn't confuse users. Importantly, we may imply that a package is licensed in a way that it's not which, whilst it may not have any legal consequences, is needlessly confusing. Licensing is already a mysterious enough area as far as most users are concerned without further confusing the issue. - Because of the above, I am essentially saying that we should treat "Foo License v1" and "Foo License v2" in the same way as "Foo License" and "Bar License", i.e. as entirely separate licenses. - we should respect the authors if they specify a specific license version. To address some obvious objections: Q: the License tag is not legally binding anyway A: true, but we are using it, so we should use it accurately. If "Foo License" doesn't accurately describe the license of a package then we might as well "cat /dev/urandom" to it since we're not enlightening users - they'll have to go and read the docs in either case Q: including specific version number has potential for bitrot A: in the sense that the maintainer has to keep an eye on it, true, but that's true in any case since packages can and do change licenses over time. Q: rpmlint moans A: rpmlint needs to be fixed, not the package Q: we're going to have to change loads of existing packages A: I'm not suggesting that; there's clearly no pressing need to change existing packages but for new ones we should have a clear policy Regardless of the above, I think some consistency and a policy is required, including across Core and Extras. For example, the Core php package recently switched *to* a versioned license field. So it seems silly for me to be being asked to take a version *out* of a package in Extras. Frankly I don't really care what the outcome is and I think it's largely an academic argument but I think someone with some authority (FESco) should make a call on it and document the policy and reasoning. Tim

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

packaging June 2006