Does anyone know whether OCaml library main packages (non-devel
packages) should be packaged as no-arch, since they only contain
bytecode files, which should be architecture independent? It seems
that convention (by looking at the list of available OCaml libraries)
is to make them architecture dependent (that is, just have a version
for each architecture even though there shouldn't be architecture
dependent contents), though rpmlint complains. It seems that Debian's
from which one might've been tempted to draw suggestions, is to
include the native code files in the main library package, which is
not done for Fedora. (This also doesn't seem to be addressed in the
Fedora OCaml packaging guidelines either.) Is this something that just
should be done but often isn't, or did I miss something else?
fedora-usermgmt has a period of about a year to appear in discussions,
I think the FPC needs to consider it and make a final decision with
wich to live with for the next N years.
The recent example is that OLPC developers scan the wiki and find
fedora-usermgmt promising a lot (which it cannot really devliver) and
are lured into using it.
Non hard core Fedorians do not know that the authoritative bits are
under /Packaging/, and not under for example /PackageUserCreation/ or
/PackageUserCreation/ (which are named much too generic for being
really fedora-usermgmt pages), and are fooled into thinking that this
is Fedora's canonical way to go. Also the few (two?) fedora-usermgmt
supporters are pointing people to this direction.
Whatever the quality of fedora-usermgmt's approach, we can all agree
or disagree or agree on disagreeing, but I think two points are clear:
a) it is the FPC's job to dictate how a package should manage its
b) the FPC needs to have a uniform method of dealing with it. This
means either to ban fedora-usermgmt or to officially embrace it and
make it part of the uid/gid assignment process.
fedora-usermgmt was grandfathered from fedora.us days and needs to be
reviewed just like any other technology we use.
Ville and friends did a nice official FPC proposal that passed that
catered for all cases where fedora-usermgmt could be used and more
(even considering prepopulated uid/gid system resources). It was now
in effect since a year os so and we know it does its job. IMHO the
next step is to declare fedora-usermgmt as deprecated and request
packages to move to a non-fedora-usermgmt uid/gid handling for F11.
Most probably all members of the FPC are aware of the recuring
fedora-usermgmt discussions - this should not be another one. If you
all think you know where you stand, and have read about
fedora-usermgmt pros and cons make a quick decision on this to get
this over with.
Axel.Thimm at ATrpms.net
I am wondering if the following video processing libs could be included
in Fedora itself ?
These "perform NTSC video signal processing on an image, giving a result
similar to that of the game console connected to a TV and unlike that of
a simple palette-based image". To do this it would appear to need to
understand the hardware chips used in such consoles, but I find no
mention of patented or so techniques.
For eg: nes_ntsc, in it's current incarnation, require or BR only Fedora
packages. An out of Fedora game console emulator could use this library
to add 80's realizm to the Emu.
The author has released under the LGPL v2.1 or later. Would it be
acceptable to be in Fedora ?
I noticed a few links on
are broken due to the wiki migration. Look out for strings like
"[wiki:Self:Packaging/" to find them.
I might have fixed those myself, but if you guys protect that area with
ACLs then you need to fix things like this yourself.