June 2009 - packaging - Fedora mailing-lists

"Explicit requires" and "requiring base package"
by Ville Skyttä 09 Sep '09

09 Sep '09

https://fedoraproject.org/wiki/Packaging/Guidelines#Explicit_Requires Packages must not contain explicit Requires on libraries except when absolutely necessary. [...] https://fedoraproject.org/wiki/Packaging/Guidelines#Requiring_Base_Package Devel packages must require the base package using a fully versioned dependency: Requires: %{name} = %{version}-%{release}. Usually, subpackages other than -devel should also require the base package using a fully versioned dependency. I think these two guidelines or their wording are more or less in conflict these days. Most -devel packages do not "absolutely necessarily" need an explicit dependency on the base package because rpm automatically adds soname dependencies from symlinks in -devel to the corresponding shared lib in the main/lib package. Ditto, many cases of other non-devel subpackages get automatic lib soname dependencies to the main/lib package. If the intent is to still require explicit deps like in "requiring base package" even though there are automatic ones that would usually work, just to be sure or for other reasons (possibility of compilation options, patchwork that affects some internal subpackages but not other -devel/lib package consumers), I think "requiring base packages" and "explicit requires" should be cross referenced noting that this is an exception and those explicit deps are indeed wanted. If not, IMO "requiring base package" should be softened so that it requires adding those explicit deps if no automatic ones are present, or just removed because that'd be redundant with "explicit requires" and the rest of the general dependency guidelines.

2 5

F-11 to F-12 transition
by Federico Hernandez 01 Sep '09

01 Sep '09

Now this might really be a newbie question but since I haven't maintained a package that long yet I wonder how the transition now from F-11 to the future F-12 works. At what point can/must I check out a new CVS branch for F-12 of my package? Will it be created automatically and all the packages in rawhide will move by magic into F-12? Or do I need to request one via bugzilla? Just wondering as I have never been around for this transition. Greetings, /Federico

3 5

next FPC meeting
by Toshio Kuratomi 01 Jul '09

01 Jul '09

Hey guys, looks like with all the vacations and conferences that people have been attending, we've lost track of the weeks that we want to be doing meetings again. Spot has another commitment on July 7th. How does July 14th sound for the next one? If there's quorum for a July 7th meeting we can meet then as well/instead.... I'll stick my hand up and say I'm available on both days. -Toshio

5 4

openmpi
by Orion Poplawski 30 Jun '09

30 Jun '09

It seems to me that the removal of the -devel (and possibly -libs) sub-packages from openmpi is a violation of the packaging guidelines. See: https://bugzilla.redhat.com/show_bug.cgi?id=499851 Perhaps the packaging committee could comment? What to do next? No response so far from the packager (1 1/2 months). -- 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

4 3

Generic filtering macros...
by Chris Weyl 30 Jun '09

30 Jun '09

So, I have a number of macros that taken together create a generic filtering system for our autoprov/dep system. http://fedorapeople.org/~cweyl/macros.perl.local http://fedorapeople.org/~cweyl/macros.perl (suitable for ~/.rpmmacros inclusion) As this has a not insignificant amount to do with packaging, I'm looking for some feedback both on the macros themselves as well as on the best approach to get these included by default. (File a feature and get it approved? File a bug against rpm? A small ritual sacrifice? :)) Thanks! -Chris -- Chris Weyl Ex astris, scientia

4 14

auto req/prov filtering, redux
by Chris Weyl 30 Jun '09

30 Jun '09

So, while checking if there was going to be a FPC meeting today, a couple points came up that seem as if they could use a bit of clarification: * The internal dependency generator is not golbaly turned off; it is only turned off when the filtering macros are actually invoked. * Disabling the internal dependency generator is currently the only way to enable the filtering of errant solib dependency information. * File coloring only impacts us via multilib in the case of elf32/64 executable binaries (w.r.t. disabling the internal dependency generator). [1] * Clean, consistent autoreq/prov overriding is clearly needed: there are hundreds of packages disabling the internal dep generator, hundreds more with some form of req/prov filtering, and recent questions on fedora-devel-list as to overriding this sort of dep. In other words, to make these macros available globally will have no impact on any package not explicitly using them. (Note the %expand macro being used in %setup_filter[2]) solib-provoked "provides" can be filtered from packages not providing elf32/64 executable binaries without messing up multilib. (That is, all arch-specific perl packages, pidgin/mysql/etc plugin packages, etc.) Is any of the above wrong? Are there any specific objections that would prevent the adoption of this proposal, beyond bikeshedding? -Chris [1] http://article.gmane.org/gmane.linux.redhat.fedora.extras.packaging/5889 [2] http://fedorapeople.org/~cweyl/macros.filtering -- Chris Weyl Ex astris, scientia

1 0

Java packaging questions about rpmlint messages
by Bruno Wolff III 29 Jun '09

29 Jun '09

I am working on packaging a java game and have a couple of rpmlint messages that I am not sure if I can ignore. One is an error for having no binaries. I thought the java stuff was somewhat arch dependent, so I thought my resulting jar file should be arch dependent and that overriding the buildarch would be a bad idea? The second is a warning for including a classpath in the manifest. The original package is setup to have a class path point to a library with a few included jar files. Only one of these jars is needed and is already packaged for Fedora. For the build process I override the property saying where the libs are to point to the Fedora jar directory. But this gets left in the manifest. To run the program I have a shell script that includes the two jar files and gives the class name to run. So while not being able to give a usable classpath on the java command line is annoying, it isn't a big deal in this case. Is this out and out broken? Is there a way to do it better without having to do too much customization of the original projects build.xml file? (ant is used to do the build.)

3 4

[Draft]Policy for creating filesystem subpackages
by Jochen Schmitt 28 Jun '09

28 Jun '09

Hallo, I have create a draft for a guildlines, which described under which condiition a so-called filsystem subpackages has to been created. The draft you may find at: https://fedoraproject.org/wiki/PackagingDrafts/CreatingFilesystemSubpackages Best Regards: Jochen Schmitt

3 2

libspotify
by Paul F. Johnson 28 Jun '09

28 Jun '09

Hi, I'm considering packaging libspotify (it's a library for accessing the spotify music service), but it has a couple of problems. The licence is MIT, which is fine. However, for a user to be able connect to spotify, they have to email spotify to obtain a file which registers them. It also requires a .la file which is against the packaging rules. Spotify have very little interest in their library, so there would probably be little that they would do to remove this .la file and without it, the package won't install locally. Any comments or advice on this? TTFN Paul -- Sie können mich aufreizen und wirklich heiß machen!

4 4

removal of pre-built files
by Orcan Ogetbil 28 Jun '09

28 Jun '09

Hi, Toshio asked me to write up a proposal for clarification of the removal of pre-built binaries. I came up with two proposals. I'd like to have them considered and voted separately. https://fedoraproject.org/wiki/PackagingDrafts/Removal_of_pre-built_binaries Any comments, suggestions welcome. Orcan

9 20

Directory ownerships again
by Panu Matilainen 26 Jun '09

26 Jun '09

I've been playing around with making rpm use runtime-calculated directory dependencies for additional transaction ordering hints - it gives a nice, natural and consistent order when directory ownerships are clear. However things can go very wrong if several unrelated packages own a directory, for example: multiprovided dir /usr/share/man/man1 -> filesystem-2.4.21-1.fc11.x86_64 -> gnome-power-manager-2.26.1-3.fc11.x86_64 -> policycoreutils-2.0.62-12.6.fc11.x86_64 Depending on input order, this could end up pulling gnome-power-manager and a huge pile of gnome dependencies very early into the order where they really cant be. So the result is a big mess, unless such multiply provided directories are ignored in the ordering - easy enough to do, just a lost opportunity to do something useful with existing data. Using F11 x86_64 DVD as test material, here's the full output with the owner packages included (lots of duplicates in there): http://laiskiainen.org/tmp/f11-multiple-dirowners.txt ...and just the directories which have more than one owner: http://laiskiainen.org/tmp/f11-multiply-owned-dirs.txt Translations, language pack packages and such are by far the biggest single offender group, these have multiple direcotry ownerships all over the place. The rest are mostly random individual cases of couple of packages disagreeing with ownership of something or several sub-packages owning more than they perhaps should. The "couple of packages disagreeing" cases need to be looked at case-by-case, but I think for the translations and such a clearer policy would be good. Having the filesystem package and nothing else own most of them seems fairly obvious but what should be done when a package introduces a new translation that filesystem doesn't yet have? Require filesystem to be updated every time (dunno how often this happens in reality) or ...? - Panu -

5 7

Digging up an old dead thread ...
by steve 25 Jun '09

25 Jun '09

Hi, First off apologies for the cross-post to fedora-legal-list, this message has some licensing questions, but I also wanted to keep context without having to send two separate mails. First off some background, earlier this year, i expressed a desire to package some creative commons licensed content ... https://www.redhat.com/archives/fedora-packaging/2009-February/msg00054.html After a bit of interest in this topic, including a general consensus that it might be a good idea, the thread died out since i could not follow up on this due to lack of time. Now, however, I do have some time and so I decided to submit a few of packages as an example of the idea: https://bugzilla.redhat.com/show_bug.cgi?id=507912 https://bugzilla.redhat.com/show_bug.cgi?id=507915 https://bugzilla.redhat.com/show_bug.cgi?id=507916 (Note that all these submissions are technical books in the same vein as diveintopython which already exists for Fedora.) Now, I have 2 questions for fedora-legal: a. Specific to the last two packages (ldd_pdf and javanotes) -- The upstream license for both of those specify the license version number (CC-BY-SA version 2 and 2.5), however, the page that lists acceptable licenses for Fedora[1] does not provide any version numbers. So, should I modify the License tag or should the wiki page be updated ? b. About other CC licensed content -- A lot of the available content is licensed with the Non-Commercial restriction, which is considered as a Bad License according to the wiki page on licensing. Why is non-commercial only restriction considered bad ? ...and is there an alternative to including this in the official Fedora repository -- for instance the rpm fusion repository ? Now, coming to the original question i raised, would it make sense for me to submit additional such packages possibly even the non-tech related ? Can we have an 'alpha', 'beta' or 'rawhide' of a creative commons repository to see if the idea gains popularity and to create some policies regarding this ? In any case, for people who'd already are sold on the idea, i've set up a repository which for now has only 7 rpms (all of them books/tutorials) but I intend on adding more. I've made them as Fedora Packaging Policy compliant as possible. Feel free to try it out and suggest/contribute similar content that you would like to be packaged. Note however, that these packages also include the CC content under the Non-Commercial restriction which Fedora considers Bad. You may use the repository by creating the file '/etc/yum.repos.d/lonetwin.repo' with the following lines: [lonetwin.net] name=lonetwin's creative commons repo baseurl=http://lonetwin.net/yum/ enabled=1 gpgcheck=0 ..and just in case you are wondering why should you trust my repo ? Well, you shouldn't. That said, none of the available packages are modified from the original source, they are just packaged as rpms. Comments/suggestions are welcome. I hope that this thread does not die out like the last one. cheers, - steve [1] http://fedoraproject.org/wiki/Licensing#Content_Licenses

6 8

Qt 4.5.2 for FC10
by L Pierre 25 Jun '09

25 Jun '09

Any chase to get Qt 4.5.2 rpm for FC10?

2 1

OSGi Packaging Changes
by Toshio Kuratomi 24 Jun '09

24 Jun '09

Hi Alphonse, I don't know if anyone from the Packaging Committee emailed you about changing https://fedoraproject.org/wiki/Features/OSGiAutoDeps into a Packaging Draft so I'm making sure you're in the loop :-) What we need is for the changes to the packaging guidelines to be written up and presented in draft form. An overview of this process is here: http://fedoraproject.org/wiki/Packaging/Committee The draft can be a coy of the new draft based off the existing guidelines or it can be just the sections that you are adding/modifying. It should also include any explanation of why the changes are justified written so someone unfamiliar with the problem space can understand. We may request more information from you in order to polish the draft. -Toshio

3 4

Renaming of upstream project/rpm/binary
by Federico Hernandez 21 Jun '09

21 Jun '09

Hi! This is not yet happening, but the upstream project wants to do a rename and release several "binaries" under the new project name. The current binary and package is one of them: Now: project name: foo --> rpm: foo --> binary: foo Soon: project name: FOOBAR --> rpm FOOBAR --> binary foo --> binary bar --> binary ernie --> binary bert foo 1.8 --> foobar 2.0 What are the procedures for this? Formal and technical ones? In particular regarding the "updates". How can I make the old package be superseeded by the new package. THX /Federico

3 4

Re: [Fedora-packaging] Help needed on AutoProvReqs subject was (OSGi Packaging Changes)
by Alphonse Van Assche 20 Jun '09

20 Jun '09

Hi *, My first idea was to just update the OSGi section of the Eclipse plugin packaging guidline but things are more complicated if we will a complete OSGi deps solving support. IMO, we need to activate the osgideps.pl script on the whole system (like the perl one) for the follow reasons: - Ability to spit package "correctly", I think that the current eclipse-rcp sub package cannot work without other sub packages[1] at the same time without the script I don't kow a way to sort that out. - No need to add defines to each OSGi aware packages. - Not need to rebuild [1]

1 1

problem with scratch build or mock
by Philippe Makowski 20 Jun '09

20 Jun '09

Hi, I made the src.rpm under F11 then koji build --scratch dist-5E-epel /home/philippe/rpmbuild/SRPMS/firebird-2.1.3.18156.0-0.fc11.src.rpm can someone explain me why I get this : DEBUG util.py:256: error: unpacking of archive failed on file /builddir/build/SOURCES/Firebird-2.1.3.18156-0.tar.bz2;4a3bf995: cpio: MD5 sum mismatch and even using mock -r epel-5-i386 rebuild ./SRPMS/firebird-2.1.3.18156.0-0.fc11.src.rpm on my box I get into the same trouble

2 1

Use of /usr/share/php in RPM
by Remi Collet 20 Jun '09

20 Jun '09

Hi, /usr/share/php is provided by PHP and included in include_dir defaut value. So this seems a good place to store "class" file. But I think we need a Guidelines 1/ to not allow direct use of /usr/share/php => use a sub-folder Ex : - php-oauth use /usr/share/php/oauth => ok - php-xmpphp use /usr/share/php/xmpphp => ok See reviews : - php-hkit Review https://bugzilla.redhat.com/show_bug.cgi?id=505358 approved but use /usr/share/php - php-PHPMailer Review pending https://bugzilla.redhat.com/show_bug.cgi?id=505356 - php-captchaphp Review pending https://bugzilla.redhat.com/show_bug.cgi?id=505354 2/ to not allow install for Web application A web application must install under /usr/share/<appname> php-laconica seems to be a web-app installed under /usr/share/php Comments before I propose a draft ? Regards

3 3

Proposal to move rubygem expansion stage
by Mamoru Tasaka 18 Jun '09

18 Jun '09

Hello, all: There has been some discussin about whether the stage to expand RubyGems should be moved from %install or not: https://www.redhat.com/archives/fedora-packaging/2009-March/msg00000.html I would like to propose to move the stage to expand RubyGems from %install to %prep completely: https://fedoraproject.org/wiki/PackagingDrafts/Gem_expand_stage_change Any comments would be appreciated. Regards, Mamoru

1 0

Makefile questions
by Chess Griffin 15 Jun '09

15 Jun '09

Hello- I am familiar with packaging for other *nixes but this is my first RPM attempt and I have a couple of questions. I have read the various packaging docs on the Fedora Project site, but have been unable to find a precise answer. If there is another document to read or another list where I should be directing these questions, please let me know. 1. The Makefile sets PREFIX to /usr/local. In %install, is it ok to use: make install PREFIX=/usr DESTDIR=$RPM_BUILD_ROOT 2. The Makefile also attempts to install and set user/group ownership and permissions, i.e. it does 'INSTALLBIN= install -g bin -o root -m 555'. Is it ok to address this by patching the line so it reads 'INSTALLBIN= install' seeing as how ownership and permissions are later set in %files? 3. Similarly, the Makefile also hardcodes the manpage directory, i.e. in install, it has: '$(INSTALLDIR) $(DESTDIR)$(PREFIX)/man/man1. Again, is it ok to patch this line so it reads '$(INSTALLDIR) $(DESTDIR)$PREFIX/share/man/man1'? This package has no ./configure stage and just uses make and make install, and does not appear to respect MANDIR. I have done all these in my draft spec file and the package clears rpmlint and builds fine with mock, but I wanted to know if what I did followed convention. Thanks! -- Chess Griffin

3 4

Putting the new GConf Schema Guidelines into effect
by Toshio Kuratomi 14 Jun '09

14 Jun '09

Hi guys, The new GConf Schema Guidelines ( https://fedoraproject.org/wiki/GConf_Scriptlets_%28draft%29 ) have been approved by FPC and ratified by FESCo. In order to put them into effect we need to get two files installed by some package. * The /etc/rpm/macros.gconf file holds the rpm macros that hide the implementation details of installing GConf schema. These need to be present when the rpm's of GConf using packages are built. * The /var/lib/rpm-state/gconf directory holds temporary files that keep state for GConf schema between the %pre and %post stages of the rpm transaction. This needs to be available at package install time. To handle the macros file I think we should add them to redhat-rpm-config. Jon, is that fine with you? To handle the state directory, I think GConf2 should own: %dir %{_localstatedir}/lib/rpm-state/gconf Since nothing currently owns /var/lib/rpm-state, we probably want it (and anything else that uses the directory in the future) to own: %dir %{_localstatedir}/lib/rpm-state as well. Does this seem like a good plan to everyone? I can submit bugzilla reports to track the changes going into packages and update the Guidelines for the Fedora Releases where this feature becomes available if this is good. Also, FESCo asked if there was a plan to mass update all the packages. Do you guys want to have that happen? I told FESCo that the old way of writing GConf install scripts was fine. Just a bit slower and with more text to write into every spec file. -Toshio

5 10

Review Guidelines missing entry
by Toshio Kuratomi 13 Jun '09

13 Jun '09

I just noticed that although checking for static libraries is listed on: https://fedoraproject.org/wiki/Packaging:ReviewGuidelines Checking for Bundled libraries isn't: https://fedoraproject.org/wiki/Packaging/Guidelines#Duplication_of_system_l… I'm going to add that as it's just a clarification rather than a change in Guidelines. If someone objects, holler and I can revert until the next FPC meeting. -Toshio

4 6

KDE 4.2.4 for FC10 rpm?
by L Pierre 12 Jun '09

12 Jun '09

KDE 4.2.4 for FC10 rpm? Regards,

2 1

Which library wins if two different libraries are named same?
by Robert Scheck 12 Jun '09

12 Jun '09

Good morning everybody, yesterday night, I noticed that there's an overlap of the libmapi.so library in the future. There are two packages which would provide a same named but different library called "libmapi.so". One is provided by the openchange package, the other will be provided by the zarafa package (https://bugzilla.redhat.com/show_bug.cgi?id=498194) Which one will win, which one has to be renamed? The openchange library already is in Fedora, but is very much newer from the history compared with the zarafa one. The openchange libmapi.so exists since ~ April 2007, the zarafa libmapi.so exists since about 5 years now. When looking to the point of producitivity, I would say that zarafa libmapi.so would win as well, as it is in productive use at their customers since they're existing as well. Or should maybe both libraries get renamed to mark which upstream they're from? This is, what I personally would prefer, especially as we're now very early in the circle and could do such a library renaming without hurting too much and too many things. Greetings, Robert

2 1

initscripts in spec file scriptlets
by Chuck Anderson 11 Jun '09

11 Jun '09

http://fedoraproject.org/wiki/Packaging/SysVInitScript has an example of how to write %post/%preun scriptlets that install init scripts. The problem is, the %post one will overwrite the /etc/rc?.d/[KS] symlinks upon every package upgrade: %post # This adds the proper /etc/rc*.d links for the script /sbin/chkconfig --add <script> shouldn't this rather be: %post # This adds the proper /etc/rc*.d links for the script # only during the initial package install, not upgrades if [ $1 -eq 1 ]; then /sbin/chkconfig --add <script> fi so it only does the --add on initial installs, not upgrades? If you re-do the chkconfig --add on upgrades, won't that overwrite the runlevel on/off settings that the sysadmin may have customized?

2 1

Re: The better way to use %install section
by David A. Wheeler 10 Jun '09

10 Jun '09

Murilo Opsfelder Ara?jo mopsfelder at gmail dot com asked: > I'm packing a third party software and this third party software is a > tarball with a install.sh and other binaries. ... > $ ls ... > install.sh > > To install this software I just need to run (as root) install.sh and > myprogram runs fine. > > After finishing installation I have all the files installed as the > following example: > /usr/bin/bin1 > /usr/bin/bin2 > Or do I need to copy all install.sh commands inside %install section? Tom Callaway graciously replied: > Well, this is a bit off topic for this list, but I'm in a > good mood, so I'll try to answer your questions. ... > The problem with the install.sh is that it almost certainly has the > install directories for those binaries hardcoded to /usr/bin. When > you're installing files during %install in an rpm, you want to install > those files into %{buildroot}%{_bindir}. I agree. Ideally, program authors would support the "DESTDIR" environment variable, so that you could easily install programs to an intermediate (DESTDIR) directory for later execution in the "real" directory (e.g., /usr/bin/). In my experience, almost nobody supports DESTDIR :-(. This lack of DESTDIR support causes trouble for rpm-based packagers (Fedora, RHEL, etc.) _and_ deb-based packagers (Debian, Ubuntu, etc.). For now, you have to re-implement the installation by hand. Ideally, DESTDIR support would be automated instead of requiring the modification of every makefile in the universe. That's not as easy as it seems; I've documented some options for doing that: http://www.dwheeler.com/essays/automating-destdir.html I intend to release some code relatively soon that should automate DESTDIR for most installations, as noted there. But for now, you'll need to do what Tom Callaway explained above. --- David A. Wheeler

1 0

Install apache moudle will restart apache automatical?
by georgexsh 10 Jun '09

10 Jun '09

Hi guys: I'm building a apache module that write by myself. Something I don't understand is, httpd will be restarted after I install the mould package, even while I didn't put anything in the %post and %postun/%preun section, I simply add a require directive: Requires: httpd. I wander is rpm that smart to know my module need restart httpd to be activated. httpd on my box is a customed version of apache 2.0.63, and configured to be able to be managed by /sbin/service. Thanks in advance. -- georgexsh

1 0

The better way to use %install section
by Murilo Opsfelder Araujo 08 Jun '09

08 Jun '09

Hi guys, I'm packing a third party software and this third party software is a tarball with a install.sh and other binaries. For example: $ tar xvzf myprogram.tar.gz $ cd myprogram $ ls bin1 bin2 install.sh To install this software I just need to run (as root) install.sh and myprogram runs fine. After finishing installation I have all the files installed as the following example: /usr/bin/bin1 /usr/bin/bin2 What's the better way to install these files? Do I need to run install.sh on the %install section inside myprogram.spec? Something like this: %install sh install.sh Or do I need to copy all install.sh commands inside %install section? Something like this: %install install -o root -w root -m 0755 bin1 %{_installdir}/bin1 install -o root -w root -m 0755 bin2 %{_installdir}/bin2 And one question just to confirm: do I need to list all bin* files inside %files in both case, right? Thanks in advance. -- Murilo Opsfelder Araújo mopsfelder(a)gmail.com {murilo,panda}(a)bsd.com.br

2 1

Python packaging guideline has incorrect BR
by Susi Lehtola 08 Jun '09

08 Jun '09

Hi, https://fedoraproject.org/wiki/Packaging:Python still has BuildRequires: python while it should read BuildRequires: python-devel could somebody fix this? -- Jussi Lehtola Fedora Project Contributor jussilehtola(a)fedoraproject.org

2 1

No Bundled Libraries Explanation
by Toshio Kuratomi 07 Jun '09

07 Jun '09

There's been quite a few requests to bundle libraries recently. Some of these from web applications, one from C applications, one in the kernel itself. Cassmodiah has been good enough to create a tracker bug for these here:: https://bugzilla.redhat.com/show_bug.cgi?id=504493 We probably should add applications that bundle JavaScript components here as well, although we're are letting those continue to bundle until we have JavaScript Guidelines finalized. With several of these problems, I've been asked to explain/argue/discuss why we have a No bundle rule and have also argued against the exception that was requested for one of them. Because I don't want to keep repeating myself, I've started a page with the reasons that bundling is a bad idea here:: https://fedoraproject.org/wiki/No_Bundled_Libraries I've put this on the agenda for the Packaging Committee but would like some discussion with additions, clarifications, etc. -Toshio

1 0

java-devel pulls in gcj, not openjdk-devel
by Susi Lehtola 06 Jun '09

06 Jun '09

Hi, isn't nowadays openjdk-1.6.0-java-devel supposed to be the Java compiler we use always? I just noticed that the java-devel that is supposed to be used in spec files pulls in java-1.5.0-gcj-devel-1.5.0.0-28.fc11.x86_64 which made my jaxodraw compilation fail (gcj isn't supported). Shouldn't the provides: java-devel be removed from java-1.5.0-gcj-devel since this causes problems? -- Jussi Lehtola Fedora Project Contributor jussilehtola(a)fedoraproject.org

3 3

Proposal to explicitly allow dos2unix
by Alexey Torkhov 05 Jun '09

05 Jun '09

Hi. In guidelines in common errors section https://fedoraproject.org/wiki/Packaging/Guidelines#Rpmlint_Errors there is the following phrase: --- This error occurs because of DOS line breaks in a file. Fix it with sed in the %prep section: %{__sed} -i 's/\r//' src/somefile -- DONT use dos2unix, that can cause build fail on FC3. --- Because FC3 is not supported for long time, I'm proposing to change it to: --- This error occurs because of DOS line breaks in a file. Fix it with in the %prep section with sed: <code>%{__sed} -i 's/\r//' src/somefile</code> or dos2unix. --- Packaging draft is created at https://fedoraproject.org/wiki/PackagingDrafts/Dos2unix and added to DraftsTodo page. Waiting for comments. Alexey

3 4

Packaging:SysVInitScript questions
by Todd Zullinger 01 Jun '09

01 Jun '09

I was reading over Packaging:SysVInitScript to bring some packages into line with the current guidelines. The template and the text differ a bit on the reload function, or at least aren't very clear. The template includes: reload() { restart } [...] case "$1" in [...] reload) rh_status_q || exit 7 $1 ;; Later, in the 'Required Actions' section, reload is described: reload: reload the configuration of the service without actually stopping and restarting the service (if the service does not support this, do nothing) So, which is preferred? If I have a daemon that doesn't have any way to reload its configuration short of restarting, should we do as the template shows and call restart or should reload() be a no-op? In many current packages, reload() does a restart if there's no other way to reload the config. For the puppet init scripts I was looking at updating, I think keeping reload() as restart would cause the least amount of surprise, as that's what it does currently. But I'm curious what the prevailing wisdom is. On another subject, the 'Initialization of Environment Variables' section mentions that init scripts may be run by admins with non-standard environment variables, like PATH, and that the init script should set these to known/default values if needed. Would it be worth noting that PATH is explicitly set and exported in /etc/init.d/functions, so init scripts which source that don't need to worry about PATH, unless they need to extend the default PATH set in the function library (which is "/sbin:/usr/sbin:/bin:/usr/bin")? Lastly, does anyone know what tools use (or used) the processname: and config: tags? The current puppet init script contains these, just under description: and I'm wondering whether they are so old that we don't have to bother keeping them any longer. They've been listed as optional tags in /usr/share/doc/initscripts-*/sysvinitfiles for ages. I just don't know of anything that uses them. -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ There is no sweeter sound than the crumbling of your fellow man. -- Groucho Marx

2 1

ISC license link need to be updated.
by paragn 01 Jun '09

01 Jun '09

Hi, I see that ISC license is not exist at link https://www.isc.org/index.pl?/sw/dhcp/dhcp-copyright.php but its now available at https://www.isc.org/software/license. Can someone update new link to https://fedoraproject.org/wiki/Licensing? Regards, Parag.

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

packaging June 2009