Building the freemedforms suite
by Ankur Sinha
Hello,
Freemedforms[1] a suite of medical software. It contains a few
applications:
freemedforms-emr
freediams
freeaccounts
others are still under development
...
At the time I packaged the freemedforms-emr (and when my review for
freediams was approved), upstream released separate tars for each of
these. They were therefore straight forward packages (I hadn't gotten
down to building freediams for Fedora yet. I've now built it, but it's
segfaulting. I'm waiting on upstream for a fix)
I recently updated the freemedforms package for fedora. I also went
ahead and split the package into meaningful subpackages based on their
functions. Spec[2]
I've found that upstream now releases a single tar[3] for all these
applications which has made the packaging incredibly messy. These
applications also share private libraries that are required for each of
them during both build and runtime (I've placed these in a
freemedforms-common-libs package in the spec).
Upstream maintains the package for debian. This is the "rules" file[4].
You'll notice upstream uses a single "spec" file to build all the
applications. I was wondering if I should follow this? It will involve
multiple invocations of qmake in the spec. Is that permitted? There
doesn't seem to be a single command to build the entire suite at the
moment.
It'll also increase the number of subpackages, but I think I can handle
the complexity.
Another issue is that upstream is still working on other applications
which are part of the suite. If I use a single spec, when these
applications are ready, how does a packager include them? I'd like each
of them reviewed before inclusion. We can't just modify an existing spec
(another packager may not have access to the spec either)
How should I proceed? Should I keep the applications as different
packages as I currently plan to? Should I look to use a single spec and
generate the entire suite?
I've tried to fix as many issues as I could in the spec. If you do
observe any, please let me know. I've only built at the moment, and not
pushed any updates.
[1] http://www.freemedforms.com/en/
[2]
http://pkgs.fedoraproject.org/gitweb/?p=freemedforms.git;a=blob;f=freemed...
[3] http://code.google.com/p/freemedforms/downloads/list
[4] http://code.google.com/p/freemedforms/downloads/list
--
Thanks,
Warm regards,
Ankur: "FranciscoD"
Please only print if necessary.
Looking to contribute to Fedora? Look here: https://fedoraproject.org/wiki/Fedora_Join_SIG
http://fedoraproject.org/wiki/User:Ankursinha
http://dodoincfedora.wordpress.com/
10 years, 11 months
Where Can I Find Previous Versions?
by Joseph D. Wagner
I've noticed that mirrors no longer appear to contain previous versions
of packages. For example, when kernel-3.4.3 was released, kernel-3.4.2
disappeared from all the mirrors.
I recently had regression troubles, and I wanted to downgrade to a
previous version to resolve the issue. However, I was surprised to find
the previous version was gone. My only option was to downgrade to the
original version that came with the distribution. I was very
disappointed with that.
Is there some place I can find the previous version? If not, is it
possible to change this so at least 1 previous version is left in the
mirrors?
Joseph D. Wagner
10 years, 11 months
Python compiled files without .py in a name
by Martin Krizek
Hi,
a project I am packaging contains a few python scripts that do not
have .py in a name. I gather only files containing .py are bytecompiled
during RPM building. And so if there is a file called "script" in the
site-packages, it is bytecompiled once the file is used and "scriptc" is
created. Then after uninstalling the package, "scriptc" is left on the
filesystem.
What is the correct/proper way to handle such files? Or even, am I missing
something?
Thanks,
Martin
10 years, 11 months
Questions about feature "Systemd unit cleanup and enhancement"
by Simone Caronni
Hello,
I have a couple of questions regarding the new feature just approved,
in particular regarding the "scope" section:
https://fedoraproject.org/wiki/Features/Systemd-unit-cleanup#Scope
1) Change PIDFile=/var/run/foo fields to point to PIDFile=/run/foo instead
Is there a rpm macro for the "/run" directory? I was using
"--with-pid-dir=%{_localstatedir}/run" in a SPEC file for %configure.
Maybe there's something similar already declared into the expansion of
%configure for Fedora 18?
What should I do if the pid directory is specified into the
configuration file of the daemon I'm mantaining?
Can the user still run with its own config upon successful upgrade to Fedora 18?
2) Remove various entries in units which are no longer necessary since
they are systemd defaults for unit simplification
Where can I get such list? (Git, wiki pages, man pages)
Thanks & regards,
--Simone
--
You cannot discover new oceans unless you have the courage to lose
sight of the shore (R. W. Emerson).
10 years, 11 months
Re: [Fedora-packaging] PHP library must not requires Apache
by Remi Collet
Le 11/06/2012 20:20, Tom Callaway a écrit :
> On 06/11/2012 01:51 PM, Remi Collet wrote:
>> Le 11/06/2012 19:04, Tom Callaway a écrit :
>>>
>>> Why? Is there something that requires explicitly Apache httpd that
>>> merits this removal?
>>
>> php requires httpd
>>
>> From : repoquery --whatrequires php (quickly filtered)
>>
>> mlt-php-0:0.7.8-1.fc17.x86_64
>> php-IDNA_Convert-0:0.6.3-5.fc17.noarch
>> php-Kohana-0:2.4-1.rc2.fc17.1.noarch
>> php-LightweightPicasaAPI-0:3.3-4.fc17.noarch
>> php-Smarty-0:2.6.26-3.fc17.noarch
>> php-ZendFramework-0:1.11.11-2.fc17.noarch
>> php-doctrine-Doctrine-0:1.2.4-2.fc17.noarch
>> php-email-address-validation-0:0-0.5.20090910svn.fc17.noarch
>> php-feedcreator-0:1.7.2-6.fc17.noarch
>> php-geshi-0:1.0.8.10-2.fc17.noarch
>> php-getid3-0:2.0.0b5-4.fc17.noarch
>> php-hkit-0:0.5-6.fc17.noarch
>> php-laconica-0:0.5.0-7.fc17.noarch
>> php-libguestfs-1:1.18.0-1.fc17.x86_64
>> php-markdown-0:1.0.1n-3.fc17.noarch
>> php-oauth-0:1.0-0.10.svn1262.fc17.noarch
>> php-pdb-0:1.3.4-6.fc17.noarch
>> php-pear-Payment-Process-0:0.6.6-7.fc16.noarch
>> php-pecl-selinux-0:0.3.1-8.fc17.x86_64
>> php-phpSmug-0:2.1-3.fc17.noarch
>> php-swift-Swift-0:4.1.7-1.fc17.noarch
>> php-symfony-symfony-0:1.4.8-4.fc17.noarch
>> php-voms-admin-0:0.6-2.fc17.noarch
>> php-xmpphp-0:0.1-0.9.rc2_r77.fc17.noarch
>> rrdtool-php-0:1.4.7-5.fc17.x86_64
>>
>> So installing one of this library will pull httpd.
>
> Yes, but do they need _Apache_ httpd, or will any webserver suffice?
No, a library don't need any webserver.
>
> ~tom
>
> ==
> Fedora Project
>
10 years, 11 months
[Guidelines Change] Changes to the Packaging Guidelines
by Tom Callaway
Here is the latest set of changes to the Fedora Packaging Guidelines:
---
In Fedora, you can assume that the default shell (/bin/sh) is bash.
Thus, all scriptlets can safely assume that if they are running in shell
code, they are running within bash.
https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Default_Shell
---
A bundling exception was granted for calibre to bundle their forked
version of pyPdf.
https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Packages_gr...
---
A new set of MinGW guidelines are in place for Fedora 17+. These
guidelines reflect the existence of mingw32 and mingw64.
https://fedoraproject.org/wiki/Packaging:MinGW
Older guidelines remain in place for older versions of Fedora (and RHEL
6 or older):
https://fedoraproject.org/wiki/Packaging:MinGW_Old
---
A section of the Ruby Guidelines concerning the appropriate place to
copy C extensions in the spec file template has been clarified and enhanced:
https://fedoraproject.org/wiki/Packaging:Ruby#Building_gems
---
Guidelines for usage of tmpfiles.d have been updated to better reflect
the current stage of Fedora and other Fedora guidelines. In summary:
* Dropped the irrelevant talk of "both systemd and upstart"
* Prefer talking of /run everywhere instead of /var/run
* Ship the packaged files in %{_prefix}/lib/tmpfiles.d/, not
%{_sysconfdir}/tmpfiles.d/.
* Do not mark the files as %config and add an explanation why.
* Use the more usual 'd' specifier instead of 'D'.
* Nudge packagers into thinking about the permission mode of their
directories, rather than copying the "0710" dogmatically.
https://fedoraproject.org/wiki/Packaging:Tmpfiles.d
---
The systemd guidelines have been update to reflect the fact that unit
files should avoid using StandardOutput= or StandardError=. The default
is the right choice for almost all cases, and using the default allows
users to change global defaults in /etc/systemd/system.conf.
Also, all references to "After=syslog.target" have been dropped, as that
is no longer correct or relevant in current versions of Fedora.
https://fedoraproject.org/wiki/Packaging:Systemd
---
The packaging guidelines now mention that the %make_install macro (*not*
to be confused with %makeinstall) may be used instead of "make
DESTDIR=%{buildroot}".
http://fedoraproject.org/wiki/Packaging:Guidelines#Why_the_.25makeinstall...
---
A new section was added to the guidelines to indicate that Fedora uses
gcc as the compiler (for all languages that gcc supports). Packages may
only build with an alternative compiler to gcc if upstream does not
support gcc.
https://fedoraproject.org/wiki/Packaging:Guidelines#Compiler
---
These guidelines (and changes) were approved by the Fedora Packaging
Committee (FPC).
Many thanks to Kevin Fenzi, Hans de Goede, Vít Ondruch, Erik van
Pienbroek, Petr Pisar, Lennart Poettering, Michal Schmidt, Rahul
Sundaram, 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
10 years, 11 months
