I sent this proposal to f-m-l about a week ago to gather comments, and
there were no serious disagreements with the proposal which have not yet
been addressed (thanks to Tibbs and Toshio for their feedback).
Basically, I want to establish a set of guidelines for packaging Tcl
extensions, as we already have guidelines for other popular scripting
languages. In addition to making Tcl packages more consistent with each
other, it will also help work toward fixing my pet-peeve bug (bz #226893)
Please let me know if I need to do anything to help get these draft
I'd like to package up Maia Mailguard, and the license appears to be
original BSD (advertising clause included) with a branding extension
I'm currently trying to create Fedora-compliant packages of the
Internet Communications Engine (Ice) -- object-oriented middleware,
see http://www.zeroc.com/ for details. They used to provide a yum
repository for Fedora, but with the new version they've stopped. I'm
now working on adapt their SRPMS to Fedora packaging standards. (If
anyone else has done / is doing this, let me know!)
I've managed to create a few packages, in the process learning a lot
more about RPM tricks and so on. One issue I'm having -- and I'm
pretty sure it's unavoidable -- is that many of the packages have
build-time requirements on other packages. For example, the tool to
translate ice interfaces into Java code is called "slice2java" and is
part of the ice-java-devel package; this tool is then needed to build
the ice-java runtime package.
What's the accepted way of building something with this type of
constraints in mock? Should I just build temporary versions of the
necessary tools as needed (e.g., let ice-java compile its own version
of "slice2java" just for use in the build process)? I'd rather not do
that, but if it's necessary I can do things that way.
Thanks for any suggestions!
Mary Ellen Foster
sorry for the duplicate post, but I am afraid fedora-extras-list was
not the best place for this...
---------- Forwarded message ----------
From: Gianluca Sforna <giallu(a)gmail.com>
Date: Mar 30, 2007 10:41 AM
Subject: Licensing issue in mantis
To: Discussion related to Fedora Extras <fedora-extras-list(a)redhat.com>
Mantis (php) codebase includes a module which comes from a 3rd party
project and is licensed with a "free for non commercial use" style
clause which is, AFAICT, incompatible with the GPL.
Is removing the offending file from the rpm package during %install enough?
Is upstream compelled to remove it as well?
I figure it's worth writing this up.
FESCO approves, but Warren would like a comment added to the effect
that packagers should document in the specfile any weird upstream
versioning conventions which they're trying to massage into a
sortable RPM EVR.
I indicated that I did not believe that the PC would have any issue
with adding such a comment.
FESCO is onboard here, but the issue is down to implementation. And
of course there's an ongoing thread in fedora-devel.
I searched for a fuse solution for ftp/gmail today and noticed that we
have four fuse files systems with fuse- prefix in Fedora:
$ yum list fuse-*
And at least two without:
$ yum list ntfs-3g curlftpfs
Do we care about that mismatch? Should we rename the two latter in the
long term just to be consistent? I tend to say "yes", so users that
search like I did (yum list fuse-*) don't get taken into the wrong
Yes, it's just a small detail, but having some package with prefix and
some without is IMHO just confusing.