--vendor fedora, rationale/motivation?
by Rex Dieter
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.
17 years
PHP packaging policy notes
by Joe Orton
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
17 years, 5 months
New Mono Page for new guidelines
by Toshio Kuratomi
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
17 years, 5 months
Re: rpms/haddock/devel haddock.spec,1.2,1.3
by Ralf Corsepius
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
17 years, 5 months
Open issues with the PHP guidelines
by Jason L Tibbitts III
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<
17 years, 5 months
Re: License tag in packages
by Christopher Stone
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.
17 years, 5 months
Namespace for cross-compilation tools?
by Jason L Tibbitts III
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<
17 years, 5 months
Including License doc in packages
by Tim Jackson
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
17 years, 5 months
Re: soname change policy proposal
by Axel Thimm
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
17 years, 5 months
License tag in packages
by Tim Jackson
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
17 years, 5 months
