packaging August 2006

packaging@lists.fedoraproject.org

35 participants
40 discussions

Request to drop %(%{__id_u} -n) in preferred buildroot
by Axel Thimm 04 Jan '07

04 Jan '07

Hi, I think the `preferred buildroot' is not really making sense. The above has developed historically out of a misunderstanding in ancient buildroot times. When people were building as root and BuildRoots were defined as %{_tmppath}/%{name}-%{version}-root, some considered "root" to mean the uid of the builder. Later %release was added and some replaced root with `id -un`. Even later some realized that root was referring to the BuildRoot and in order to play safe added both. I'm using %{_tmppath}/%{name}-%{version}-%{release}-root in my packages and someone is now nitpicking on why not using the preferred BuildRoot as given in the guidelines. Instead of locally fighting a BuildRoot battle, I'd better get the guidelines fixed ;) Also consider what this really is about: Deambiguifying the BuildRoot per package makes sense as there may be several build processes sharing the same filesystem (either locally or through NFS), but deambiguifying the build user, too, means that we assume that the same EVR package will be possibly built on the same filesystem by different users? And even simultaneously? It makes more sense to include a conditional epoch or target/arch in the buildroot that the builder. In fact the best thing for a buildsystem is to override the buildroot adding a build-id to it anyway. -- Axel.Thimm at ATrpms.net

10 23

--vendor fedora, rationale/motivation?
by Rex Dieter 29 Nov '06

29 Nov '06

Per http://fedoraproject.org/wiki/Extras/FedoraDesktopEntryGuidelines: The vendor prefix (desktop-file-install --vendor=...) must be set to fedora". I don't understand the rationale/motivation behind requiring '--vendor fedora' I can, however, see that desktop-file-install's current implementation(*) of prepending %{vendor}- to the .desktop file name has some problems/issues: 1. .desktop filename now varies from upstream 2. --vendor may change when/if Extras bits are pulled into Core and/or RHEL. 3. *In particular*: when users start employing menu editors, since most(all?) of them base their customizations on the .desktop file name. -- Rex (*) If desktop-file-install's implementation instead followed something like kde's practice of using a vendor directory (e.g. /usr/share/applications/kde), then (1) and (3) would no longer be an issue.

4 6

Importance of debuginfo packages
by Jason L Tibbitts III 11 Sep '06

11 Sep '06

Often when doing package reviews I find a package that needs some hack in order to get rpmbuild to build a complete debuginfo package. Some of this relates to passing the proper compiler flags and making sure the package doesn't strip its own binaries, which I think is necessary, but occasionally rpmbuild needs the source to be moved around in the build tree, or it needs symlinks flattened or somesuch. These are just hacks to work around rpmbuild deficiencies, and I can understand if packagers are reticent to clutter up their packages for something of unknown value. So, how important is it to have a proper debuginfo package? How much hacking is permissible or necessary in order to achieve that goal? Is an incomplete debuginfo package (that contains, say, the striped debug information but is missing some or all of the source code) still useful, or would it be better to have none at all? - J<

7 10

%makeinstall - must not or should not use it?
by Till Maas 10 Sep '06

10 Sep '06

Hiyas, the Packaging Guidelines contradict itself about the usage of %makeinstall http://fedoraproject.org/wiki/Packaging/Guidelines#head-fcaf3e6fcbd51194a5d… The headline says "Why the %makeinstall macro should not be used" and the first sentence says "RPM, as included in Fedora, includes a %makeinstall macro, but you must NOT use this macro in Fedora packages." It seems to be used by a lot of maintainers, so is this just a should not or is this another candidate for a major specfile-cleanup project? Regards, Till

11 17

cmake best practices
by Orion Poplawski 05 Sep '06

05 Sep '06

It appears that more and more projects are moving to cmake, especially with KDE4 making the jump. Two packages of mine (plplot and kdesvn) are also making the switch. I also happen to be the current packager for cmake itself (because I package paraview which uses it), though I expect it will have to get moved to core relatively soon. It seems like it is time to start collecting cmake best practices for generating Fedora RPMS using cmake, and perhaps even creating a %cmake rpm macro that is analagous to the %configure macro. Here's what I have so far (note that cmake generally does out of tree builds): %build mkdir fedora cd fedora export CFLAGS="$RPM_OPT_FLAGS" export CXXFLAGS="$RPM_OPT_FLAGS" cmake .. \ -DCMAKE_INSTALL_PREFIX:PATH=%{_prefix} \ -DBUILD_SHARED_LIBS:BOOL=ON \ -DCMAKE_SKIP_RPATH:BOOL=ON make VERBOSE=1 %{?_smp_mflags} %install rm -rf $RPM_BUILD_ROOT cd fedora make install DESTDIR=$RPM_BUILD_ROOT I'm also running into trouble getting kdesvn to install into /usr/lib64 on x86_64. This might just be a matter of educating upstream users on the proper cmake commands for this (once I figure that out myself...). Currently there is lots of hard coding of "lib" into install paths. Now, where to put this in the wiki? -- Orion Poplawski System Administrator 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

2 2

New meeting time
by Axel Thimm 05 Sep '06

05 Sep '06

Hi, all 7 participants of today's IRC session would agree to Tue, 17:00 UTC + DST fixes. http://www.fedoraproject.org/wiki/Packaging/NewMeetingTime It's two days before fesco which will make some easier information passing and evaluation. The remaining three are Ralf, Jose and David. Is it OK with you? -- Axel.Thimm at ATrpms.net

5 5

Re: RFC: Creating meta group packages via comps
by Jeremy Katz 30 Aug '06

30 Aug '06

On Tue, 2006-08-29 at 11:09 -0700, Christopher Stone wrote: > It should be really easy to make a script that builds metagroup > packages from comps, no? > > This will allow someone to install a group such as kde/gnome as an rpm > package and when packages are removed/added/changed in the comps > groups, the meta group package also changes, and the user gets the > appropriate changes. > > I don't think this is possible now with the groupinstall feature in > yum which IMO is a bad feature since it should be done with meta group > packages as I describe. > > Comments? The entire point here is that there don't have to be packages to keep track of this metadata -- so if you change comps, you don't have to go change lots of packages. This is also really helpful for doing site-specific customizations of what the various groups are. The argument about a "noob" is pretty much moot as they're far more likely to be using the graphical interface as opposed to yum on the command line. And at that point, the comps file becomes even _more_ important as it's used for the entirety of the display. Jeremy

4 4

RFC: Creating meta group packages via comps
by Christopher Stone 30 Aug '06

30 Aug '06

Hi, It should be really easy to make a script that builds metagroup packages from comps, no? This will allow someone to install a group such as kde/gnome as an rpm package and when packages are removed/added/changed in the comps groups, the meta group package also changes, and the user gets the appropriate changes. I don't think this is possible now with the groupinstall feature in yum which IMO is a bad feature since it should be done with meta group packages as I describe. Comments?

7 16

New Meeting Time
by Toshio Kuratomi 29 Aug '06

29 Aug '06

Hi guys, as discussed in the meetings for the past couple of weeks, we're trying to change the meeting time. I've started a wiki page with a simple calendar to fill in days and times that work for you. You can also block off a section of time that doesn't work (as I've done for the West Coast sleep & commute period). http://www.fedoraproject.org/wiki/Packaging/NewMeetingTime -Toshio

2 1

Best practise license checking?
by Till Maas 25 Aug '06

25 Aug '06

Hiyas, do you have any recommendations on how to check which license a package uses? Is it enough to look at the upstream homepage or README which license it uses or need a reviewer perform a code inspection? In the latter case is it enough to check the headers of each file for licensing? And has each file have a header with an allowed license? And after review, has the maintainer to check on each new file on each release whether or not the file has an allowed license? Regards, Till

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

packaging August 2006