Re: [Fedora-packaging] Architectures supported by LSB, fedora, ubuntu and kvm
by xning
Hello,
I adjusted the volumn names to reduce the line length. Now
the line length is less than 80. So it's suit to browse in
terminal. And also add two architecures: s390 and s390x.
----- Original Message -----
From: "Xibo Ning" <xning(a)redhat.com>
To: "fedora-devel" <devel(a)lists.fedoraproject.org>
Sent: Tuesday, February 14, 2012 10:13:43 AM
Subject: Architectures supported by LSB, fedora, ubuntu and kvm
Hello,
Just as the subject, I made a text table. It's simple. The column name
explains itself. I think it is usefull for somebody.
The table also contains two columns:
'is_fedora_kvm_support?' and 'is_ubuntu_kvm_support?'. The two columns
tell us whether fedora/ubuntn kvm could virtualize
the architecture.
I got the information from LSB, fedora and ubuntu offical site. kvm
information comes from KVM packages of fedora 16 and ubuntu 10.04 LTS.
I am not familar with most of these architectures. So, I would like to
receive feedback and advice.
The table in attach file.
Best regards,
xning
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
12 years, 2 months
Introducing a directory for installed test programs
by Julio Merino
Hello,
The purpose of this long email is to justify the need for a /usr/tests
directory and to ask for approval for its creation, with the final goal
of packaging ATF, its tests and the tests provided by arbitrary
applications (e.g. the just-approved lutok package[1]). This email is
long because I feel the need to provide tons of background to explain
why this directory is required. I hope the text is clear and that it
makes enough sense to convince you of its approval. Here we go!
I am the author of the Automated Testing Framework[2] (ATF for short).
ATF is the testing framework currently used in the NetBSD operating
system, although the ATF project itself is OS-agnostic. In other words,
ATF builds and runs fine on multiple Linux distributions, BSD systems
and OS X. (ATF is being replaced by a new project called Kyua[3]; this
will come into play later in the text.)
I am now interested in creating an RPM package of ATF (and Kyua) for
Fedora and there is a "little detail" in ATF that will surely be
controversial. This is why I am reaching the FPC before sending any
spec file for review, as this particular point will need discussion and
approval.
ATF is made up of two parts: 1) a collection of libraries (C, C++ and
shell) that enable developers to write test programs for their
applications and libraries; and 2) a collection of tools (atf-run,
atf-report) that allow the developers and *end users* to execute these
tests.
To re-emphasize the point above, note that I said "end users". One of
the major features that differentiate ATF from other testing frameworks
is that *the tests written using ATF are supposed to be installed in the
system* as part of the regular application or library. ATF then
provides standalone tools to execute these tests and to generate reports
of their results, all without the need of the original program sources
nor any development tools (read: no gcc, and specially no make). These
tests can be run by any user as they don't require write access to the
directory in which the tests live.
To put this in the context of a Linux distribution, let's consider a
fictitious example: imagine that glib and gtk came with ATF-based tests.
These tests would get installed into testsdir/glib/... and
testsdir/gtk/... The user would then do "cd testsdir/gtk/ && atf-run"
to execute the tests on his machine, without the need for any -devel
packages. The key point of this idea is that this allows end users to
gain confidence in their systems, because they can validate that a
particular piece of software runs fine on their OS / hardware
combination. What is more, suppose that glib got upgraded to a new
version but not gtk. If there were any incompatibilities between the
two, the installed gtk tests would highlight it because they'd start
failing. The packager may never have noticed that fact himself if he
always kept his build environment up-to-date (as is commonly the case).
(Also, consider creating a cron job to run all these tests nightly!)
Well, imagine no more. We already do something like this in NetBSD.
NetBSD defines the testsdir above as "/usr/tests". This tree[4]
contains a subdirectory for each package that provides ATF-based tests,
and there is a top-level Atffile file that allows atf-run to recurse
into all the package subdirectories. (I.e. executing atf-run within
/usr/tests runs *all* the tests available in the system for all
packages.) You can see in [5] a more detailed description as to how
this comes into practice.
There are two important things to consider about /usr/tests:
1) The first is that there is a single directory acting as the "root"
for the tests of arbitrary packages because this is what allows all
these tests to be run at once. In other words, instead of having
/usr/pkg1/tests /usr/pkg2/tests, we have /usr/tests/pkg1 and
/usr/tests/pkg2.
2) The second is that ATF is not encoded anywhere in the path. I.e. the
directories are /usr/tests/pkg*, not /usr/atf/pkg* nor
/usr/tests/atf/pkg*. The reason for this is that the package-specific
tests needn't be implemented using the ATF libraries. In fact, Kyua,
the replacement for ATF, is able to execute these same unmodified tests
and can also execute tests written other frameworks. In a future world,
packages would install arbitrary tests into /usr/tests written using
their preferred libraries (e.g. pyunit, autotest, etc.) and a single
tool (Kyua) would run them all. Encoding the tool name in the directory
introduces a dependency on the tool that does not necessarily exist.
So, to sum it up: the whole point of this email is to discuss what the
"testsdir" above should be in Fedora. I think it makes a lot of sense
to keep the default of /usr/tests.
However, of course, this does not complain with any the LSB policies.
The problem is that no other already-existing directory seems to suit
the goals of /usr/tests. For example: /usr/share/tests is unsuitable
because the tests are obviously executables and thus not shareable.
/usr/libexec/tests also appears unsuitable because these programs are
not helper binaries internally used by other programs: they are supposed
to be exposed to the end user, who may choose to run them by hand.
/usr/lib/tests is even worse because these are not libraries and also
has the same problem of libexec in the sense that the files are hidden
from end users. End users need to be encouraged to "cd /usr/tests" and
to run stuff from there, just as they do with /usr/bin or /usr/sbon.
Therefore, I believe that introducing a new directory is sensible
enough, particularly because it is potentially optional (e.g. could be
made part of a -filesystem package). Actually, the way I envision the
packaging to work is the following. Let's consider lutok again, as its
distribution file contains ATF-based tests. lutok would come in these
packages: lutok, lutok-devel, lutok-tests. The latter package would
place files in /usr/tests/lutok only and it would depend on libatf-c++
(because lutok's tests are implemented in C++) and maybe some
"tests-filesystem" package. lutok-tests needn't depend on the atf
tools. Then, the user could just install the 'atf' package providing
atf-run and atf-report to execute these tests from within /usr/tests or
/usr/tests/lutok. Similarly, other tools could place their installable
tests in /usr/tests/<pkg>.
So, what packages would make use of /usr/tests if it were introduced
now? As far as I can tell, these would be atf, lutok and kyua
(including all of its subpackages for the libraries, etc.). Bind 9
recently adopted ATF too, although I'm not sure if they install the
tests.
This should be all for now. Is it OK to introduce this optional
/usr/tests directory?
Please let me know if you have any questions or concerns.
Thank you,
Julio Merino
1: https://bugzilla.redhat.com/show_bug.cgi?id=785619
2: http://www.NetBSD.org/~jmmv/atf/
3: http://code.google.com/p/kyua/
4: http://cvsweb.netbsd.org/bsdweb.cgi/src/tests/?only_with_tag=MAIN
5: http://blog.netbsd.org/tnf/entry/testing_netbsd_easy_does_it
12 years, 2 months
Additional sources / bundled?
by Brendan Jones
Hi
I have a couple of packages that I'm porting from the CCRMA repo. A
couple of them list some additional sources that contain only content
(ie a PDF or audio presets / no binaries). Do I still have to create
separate SPECS for these files? Some are also unversioned.
regards,
Brendan
12 years, 2 months
section: binaries in /bin and /sbin
by Kay Sievers
This in no longer a problem in Fedora and can be removed:
"Binaries placed into /bin and /sbin must not depend upon libraries
stored in /usr/lib (or /usr/lib64). Binaries which depend on libraries
in /usr/lib* must live in either /usr/bin or /usr/sbin."
Thanks,
Kay
12 years, 2 months
broken recommendation for libexecdir
by Kay Sievers
Heya,
recommending %{_libdir}/%{name} will result in /usr/lib64/foo/ which is
very broken.
"Application private directories' are for binaries not for libraries and
are not architecture dependent; they must live in /usr/lib, regardless
of the architecture. It is also defined that way by LSB.
In general, we recommend, and all new tools use already, the LSB
defined /usr/lib/<pkgname>/ dir, because libexec/ is entirely forbidden
to use on all other Linux distributions, and we want to share more with
them.
There would be no rush to get rid of libexec in Fedora, it's nothing
wrong with it in general; but recommending it in the packaging
guidelines seems very wrong to me, and against all common sense in
upstream Linux development.
It's a pretty useless Fedora'ism that serves no real purpose and is just
different from everything else. It solves no problem that isn't already
solved since many years.
Thanks,
Kay
12 years, 2 months
Request for confirmation: Which form is required for a review
by Matthias Runge
Hi,
lately, I stumbled upon a review, which I thought, wouldn't suffice.
It looks like the following
name: ok
summary: ok
license: ok
handling locale files: ok
rpmlint output: only spelling warning
Not needed BuildRequires: (names), please remove them in git.
APPROVED.
My question is: is this review sufficient, if not, where is it written
down, that it isn't? I'm especially aiming to the form of this review.
I wasn't able to spot a requirement to write something like approved (or
something else) on
http://fedoraproject.org/wiki/Packaging:ReviewGuidelines
Further more, there isn't anything said about how the reviewer should
document his work. If we deny the requirement of documenting reviewer's
operation, then just setting the approved flag conforms with the
guidelines; This also claims, everything has been checked and is well done.
Am I missing something? Is there any need to clarify our review
guidelines? Do we need something more documented? Do we trust our
reviewers, so there's no need of bureaucracy? Why should/must I do more
than just setting the flag or writing 7 catchwords?
Thanks
--
Matthias Runge <mrunge(a)matthias-runge.de>
<mrunge(a)fedoraproject.org>
12 years, 2 months
[Guidelines Change] Changes to the Packaging Guidelines
by Tom Callaway
There have been quite a few approved changes to the Fedora Packaging
Guidelines since the previous announcement, but this is mostly because I
have not had time to actually apply the approved updates to the wiki
until recently. These updates actually were approved over a period of
several months. I will try harder to get updates written up and
announced in a more timely fashion going forward.
---
The Eclipse Plugin Packaging Guidelines were updated. The most major
change is the addition of a section discussing how to run the
reconciler. For the full updated guidelines see:
https://fedoraproject.org/wiki/Packaging:EclipsePlugins
---
t4k_common contains a forked copy of an older version of liblinebreak. A
temporary bundling exception has been granted until the t4k_common
upstream is able to port their code to use the newer system copy of
liblinebreak. The t4k_common package must include Provides:
bundled(liblinebreak) until the issue is resolved.
This exception has been added to the list here:
https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Packages_gr...
---
Spring RTS includes a forked and bundled copy of Lua which has Spring
RTS specific patches applied, must link to streflop, and is configured
differently from stock Lua (most importantly it needs lua_Number to be a
float and not a double). Lua is particularly important because parts of
the game code may be written in it, which must yield exactly identical
results (also floating point operations!) on all platforms.
As a result, it has been granted a bundling exception for lua. The
Spring RTS package must include Provides: bundled(lua) = X.Y.Z (where
X.Y.Z is the base lua version), until the bundling issue is resolved (if
ever).
This exception has been added to the list here:
https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Packages_gr...
---
A section has been added to the Guidelines that limits which package
manager repositories are allowed to be configured in Fedora. Additional
repository configuration files are allowed as documentation provided
that they are legally allowable by Fedora.
https://fedoraproject.org/wiki/Packaging:Guidelines#Configuration_of_Pack...
---
The MPI Guidelines have been clarified by adding this additional statement:
If the maintainer wishes for the environment module to load
automatically by use of a scriptlet in /etc/profile.d or by some other
mechanism, this MUST be done in a subpackage.
https://fedoraproject.org/wiki/Packaging:MPI
---
The Devel Packages section of the Packaging Guidelines has been
rewritten to be more comprehensive and clear:
https://fedoraproject.org/wiki/Packaging:Guidelines#Devel_Packages
In addition, the ReviewGuidelines have been simplified to state simply
that Development files must be in a -devel package.
---
An exception was granted which permits the bundling of binutils
libraries, (most notably, libbfd, libcpu, libopcodes, and libdecnumber)
but only to packages which share the same upstream as binutils
(sourceware.org). This is because the libraries are developed by the
application authors as common functionality shared between several
applications. Being developers of both, they'll be intimately aware of
both issues that arise in the libraries and know how to port to newer
versions of the library as needed. Note that, at the moment, all of
these applications and libraries come from sourceware.org but not all of
them are used in binutils.
Packages leveraging this exception must add: Provides: bundled(binutils)
= %{snap}, where %{snap} is defined in the package as the date that the
binutils checkout was made, until the bundling issue is resolved (if ever).
This exception has been added to the list here:
https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Packages_gr...
---
The Packaging Guidelines section on Architecture Support has been
amended to clarify that all Fedora packages must successfully compile
and build into binary rpms on at least one supported primary
architecture, except where the package is useful only on a secondary
architecture (such as an architecture-specific boot utility, microcode
loader, or hardware configuration tool).
https://fedoraproject.org/wiki/Packaging:Guidelines#Architecture_Support
---
The "okjson" software has reluctantly been granted a bundling exception.
Packages which bundle okjson.rb must add: Provides: bundled(okjson),
until the bundling issue is resolved (if ever).
https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Packages_gr...
---
The section of the Packaging Guidelines covering /srv was amended to
include /opt and /usr/local. Specifically, the following sentence was added:
In addition, no Fedora package can have any files or directories
under /opt or /usr/local, as these directories are not permitted to
be used by Distributions in the FHS.
https://fedoraproject.org/wiki/Packaging:Guidelines#No_Files_or_Directori...
---
A new section has been added to the Fedora Packaging Guidelines
regarding Network Support. Specifically, if an application contains
native and stable support for both IPv4 and IPv6, and support for IPv6
does not negatively affect IPv4 then both must be enabled in the Fedora
package.
https://fedoraproject.org/wiki/Packaging:Guidelines#Networking_Support
---
As part of the /usrmove feature in Fedora 17, Fedora packages MUST NOT
place files or directories in the /bin, /sbin, /lib or /lib64
directories. Instead, the /usr/bin, /usr/sbin, /usr/lib, and /usr/lib64
directories must be used. Packages must assume that /bin, /sbin, /lib,
and /lib64 are symbolic links to the /usr/bin, /usr/sbin, /usr/lib, and
/usr/lib64 directories, respectively.
This is effective immediately for new packages, however, packagers are
not required to implement this change for distributions older than
Fedora 17.
https://fedoraproject.org/wiki/Packaging:Guidelines#Filesystem_Layout
---
A temporary bundling exception has been granted for libtdb_compat and
libccan, but only for samba4 packages. This exception will last until
F18 GA, or libtdb 2.x releases, whichever comes first.
Samba4 packages which bundle libtdb_compat or libccan must include
Provides: bundled(libtdb_compat) or Provides: bundled(libccan), until
the bundling issue(s) are resolved.
https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Packages_gr...
---
A bundling exception has been granted for libreplace, but only if the
package in question shares the same upstream as samba. This is because
the libreplace library is developed by the application authors as common
functionality shared between several applications. Being developers of
both, they'll be intimately aware of both issues that arise in the
libraries and know how to port to newer versions of the library as needed.
Samba packages which bundle libreplace must include Provides:
bundled(libreplace), until the bundling issue is resolved (if ever).
https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Packages_gr...
---
The Pre-Release packages section was improved significantly, with the
intent of making it more clear through the use of specific examples in
tables.
https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Pre-Release_pac...
---
The Icon Tag in Desktop Files section in the Packaging Guidelines has
been amended to include a link to the scriptlets to refresh the icon cache.
https://fedoraproject.org/wiki/Packaging:Guidelines#Icon_tag_in_Desktop_F...
---
The Emacs Packaging Guidelines have been clarified and simplified, with
much unnecessary duplication removed.
https://fedoraproject.org/wiki/Packaging:Emacs
---
A new section containing tips and best practices for writing scriptlets
for Fedora packages has been added.
https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Writing_script...
---
The Guidelines section on Handling Locale Files has been updated to
reflect the additional functionality in %find_lang.
https://fedoraproject.org/wiki/Packaging:Guidelines#Handling_Locale_Files
---
Ulrich Drepper's MD5 implementation, as found originally in gcc, was
added to the list of MD5 exception cases permitted for bundling exceptions.
https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Packages_gr...
---
A link to the No Bundling Libraries page, which contains the steps
necessary to request a Bundling exception, has been added to the
"Bundling of multiple projects" section in the main Guidelines.
https://fedoraproject.org/wiki/Packaging:Guidelines#Bundling_of_multiple_...
---
The section on File and Directory Ownership has been updated to reflect
the fact that while in most cases, it should not be necessary for
multiple packages to contain identical copies of the same file, if it is
necessary, multiple packages may contain identical copies of the same
file, as long as the following requirements are met:
* The packages sharing ownership of the identical files are built from a
single SRPM.
OR
* The packages sharing ownership of the identical files are not in a
dependency chain (e.g. if package A requires package B, they should not
both contain identical files, either A or B must own the common files,
but not both.)
In addition, identical files are defined as files which are always
identical in content, checksum, permissions, and location on the
filesystem in each package.
https://fedoraproject.org/wiki/Packaging:Guidelines#File_and_Directory_Ow...
---
Announce Text:
A new section has been added to the PHP Guidelines, documenting the PHP
ZTS extension.
https://fedoraproject.org/wiki/Packaging:PHP#PHP_ZTS_extension
---
These guidelines (and changes) were approved by the Fedora Packaging
Committee (FPC).
Many thanks to Nick Clifton, Remi Collet, Frank R Dana Jr., Gilboa
Davara, Kevin Fenzi, Stephen Gallagher, Harald Hoyer, Jan Kratochvil,
Jussi Lehtola, Marcela Mašláňová, Panu Matilai, Vít Ondruch, Petr Pisar,
Michael Schwendt, Kay Sievers, Chris Tyler, Jonathan Underwood, Karel
Volný, Sami Wagiaalla, Christoph Wickert, 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,
~tom
12 years, 2 months
Re: [Fedora-packaging] Time for Lua packaging guidelines?
by Michel Alexandre Salim
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Tim,
On 02/03/2012 07:32 PM, Tim Niemueller wrote:
> Hi Michel.
>
> Yes, it might be time to come up with Lua packaging guidelines
> (though I like to keep it at a minimal bureaucratic level.
Certainly. I'm envisaging a rather stripped down version of the Python
guidelines.
>
> Are you (or anyone else interested in this) at Fosdem by any
> chance? I will be so it might give an opportunity to meet face to
> face and get things started. We could also discuss Lua 5.2.
>
Sadly I'm not going to be there. But I'm normally on IRC or Jabber.
Best,
- --
Michel Alexandre Salim
Fedora Project Contributor: http://fedoraproject.org/
Email: salimma(a)fedoraproject.org | GPG key ID: A36A937A
Jabber: hircus(a)jabber.ccc.de | IRC: hircus(a)irc.freenode.net
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk8sPZ8ACgkQNd069XiIR3jntQCfXjVIpFylBqiWU4FehvcJfJhQ
GyIAn0B5unC3KX0RiQMqfnImaSlzTfiE
=azjm
-----END PGP SIGNATURE-----
12 years, 2 months
