Help needed handling package move
by Orion Poplawski
I package the eclipse-photran feature. Currently this is at version
5.0.0. The Photran project has merged with the PTP project which I
currently am in the process of packaging.
I'm still splitting out the photran compenents with the package names
"eclipse-photran*" , but because PTP is at version 3.0.1, their versions
are now lower. The photran component is still considered to be at 5.0.0
(or 5.0.1).
Any suggestions on how to handle this would be appreciated.
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA Division FAX: 303-415-9702
3380 Mitchell Lane orion(a)cora.nwra.com
Boulder, CO 80301 http://www.cora.nwra.com
14 years, 3 months
Naming packages from apache.org
by Orion Poplawski
crossposting to java and packaging -
Seems like we need an accepted standard for naming packages from
apache.org, particularly commons.apache.org. We already have lots of
"jakarta-commons-*" packages, but now "commons" is an ex-jakarta project
and jakarta.apache.org/commons redirects to commons.apache.org. Same
with jakarta taglibs (although that moved to tomcat).
As of now, the only apache-* package I know of is apache-ivy, which I
would have named simply "ivy". I've got a package request in for
"commons-jexl"[1], but it has been suggested that it be named
apache-commons-jexl. If it were named that I would want a Provides:
commons-jexl much like most jakarta-commons-* packages, so it doesn't
really clean up the namespace any (just adds to it in fact).
commons-* is a lousy name though too, be very generic.
So, I'm fine with either (although I think it's quite possible that
"apache commons" could get renamed again), but at this juncture before a
bunch more packages come in from apache commons, I think we should make
a decision and stick with it.
1 - https://bugzilla.redhat.com/show_bug.cgi?id=531379
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA Division FAX: 303-415-9702
3380 Mitchell Lane orion(a)cora.nwra.com
Boulder, CO 80301 http://www.cora.nwra.com
14 years, 3 months
Let me introduce myself
by Morpheusv
Hello.
Since early 2008 I have used Fedora as my personal system, since late 2008
came the concern to actively contribute to Fedora, and that's how I took my
first step by becoming Fedora ambassador for my country.
But the issue of collaborating in the development of free software, is
something that has a couple of months of hanging around in my head.
This is how the project started packing clamsmtp software, which is an SMTP
filter that allows the antivirus scan for viruses with ClamAV.
Since becoming a pre-packaged feel that Fedora is an excellent opportunity
to contribute and expand my knowledge and experience.
This is my first package, and I am looking to sponsor.
See https: / / bugzilla.redhat.com / show_bug.cgi? Id = 555,059
Greatly appreciated your comments and suggestions.
--
--
Andres Pascasio
http://www.pascasio.org
http://fedoraproject.org/wiki/User:Morpheusv
14 years, 3 months
from atalk to netatalk
by HAT
Hi,
Netatalk team is preparing netatalk 2.1beta now.
We consult Fedora packagers.
We will change initscript's name from "atalk" to "netatalk".
from:
/etc/rc.d/init.d/atalk
to:
/etc/rc.d/init.d/netatalk
Do you have the objection in this?
A keyword "atalk" is an abbreviation for "AppleTalk".
AppleTalk will be disable by default in netatalk 2.1beta.
A description has already been updated.
Old:
# description: This package enables Linux to talk to Macintosh
# computers via the AppleTalk networking protocol and
# provides printer, file sharing, and AppleTalk routing
# services.
New:
# description: This package is an implementation of "AFP over TCP"
# and provides printer, file sharing, and routing
# services via legacy AppleTalk networking protocol.
See also,
http://marc.info/?l=netatalk-devel&m=126019960613004
--
HAT
14 years, 3 months
Where should server state go?
by Bruno Wolff III
I am looking at adding a subpackage to colossus for a public facing game
server that maintains some state in files. It isn't clear to me where this
should go (other than being under /var). Packages don't seem to be consistent
about this as far as I can see.
Some possibilities might be:
/var/colossus
/var/lib/colossus
/var/games/colossus
/var/lib/games/colossus
On a related note, is it Ok to keep a config file in /var so there are
less places to go looking for information related to the server, or should
that be kept in /etc?
14 years, 3 months
Request for Guideline Clarification
by Rich Mattes
Hi all,
I've been gathering bits and pieces of information regarding the
packaging of shared libraries for a while now. As I understand it:
- Normal .so libraries with versioned filenames go into the base package
for a program when they exist
- Unversioned .so libraries go into the -devel package
-- If there are no versioned libraries for a program, should a
versioned library be added or should the unversioned .so file be
included in the base package?
- Libraries which are used by other programs at runtime should be
versioned, and in %{_libdir}
-- Are there exceptions to this? When is it appropriate to leverage
subdirectories and /etc/ld.so.conf.d/?
- Libraries which are plugins to one specific program, and are dlopened
by that program, do not need a versioned filename. They should go in
their own subdierctory in %{_libdir} (e.g. /usr/lib/gstreamer-0.10)
-- If packaged as seperate plugins, they should be in packages called
packagename-plugins-pluginname, or something similar
- All shared library filenames should begin with lib
A lot of this isn't in the packaging guidelines, I think if these points
could be clarified and included in the guidelines it would help to
answer a lot of questions.
Thanks,
Rich
14 years, 3 months
Clarification of Static Libraries packaging guidelines
by Michael Schwendt
$ yum list \*-static | wc -l
115
$ yum list \*-devel-static | wc -l
8
$ yum list \*-static | grep -v devel | wc -l
108
Perhaps I only have a nit-picky day, but
https://fedoraproject.org/wiki/Packaging:Guidelines#Packaging_Static_Libr...
clearly mentions *-static as in foo-static - and not foo-devel-static.
Could this part of the guidelines be clarified, please?
Related to this ambiguity in the naming guidelines, it's kind of pointless
if some packages start creating -static subpackages, which provide a
virtual -devel *and* a virtual -devel-static package in addition to a
shared library base package. Effectively, it implies that another
package could "BuildRequires: libfoo-devel" for _static_ linking even
if a shared library is available. This is exactly what the old guidelines
wanted to avoid (by separating -devel and -static subpackages).
14 years, 3 months
