packaging March 2007

packaging@lists.fedoraproject.org

38 participants
30 discussions

[DRAFT] ExtraDistTagConditionalMacros
by Tom Callaway 23 Mar '07

23 Mar '07

I have added a draft for Extra DistTag Conditional Macros. Dag Wieers pointed out on the epel-devel mailing list that there were some useful macros that we could add to the existing helper macros to ease conditionals in spec files. http://fedoraproject.org/wiki/PackagingDrafts/ExtraDistTagConditionalMacros Comments are always welcomed. ~spot

3 2

Post-release tags
by Fernando Nasser 23 Mar '07

23 Mar '07

Hi all, We have for quite some time figured out what to do with pre-release tags: 0.#.<tag>.#%{?dist} But what to do with _post_-release tags? Here is an example: These upstream software releases its software from pre-release to final like that: 1_1_0_BETA 1_1_0_BETA1 1_1_0_BETA2 1_1_0_CR1 1_1_0_CR2 1_1_0_GA So far so good, we use pre-release tags for all but the last, which we call just '1.1.0'. After the final release (GA- General Availability), the process goes on. After some fixes are added, they release: 1_1_0_CP1 1_1_0_CP2 1_1_0_CP3 So I thought we could just add one decimal point: .1, .2 and .3 for the above. Eventually, they have a wider distribution one with a different naming: 1_1_0_SP1 (SP = Service Pack) And there goes my extra decimal point scheme. I think CPs after that would go like: 1_1_0_SP1_CP1 as I've also seen then use 1_1_0_GA_CP1 instead of just 1_1_0_CP1 I've also seem ugly things like 1_1_0_PATCH1 What should we do in these cases? Add non-numerics in the version field and have: 1.1.0.GA 1.1.0.GA.CP1 or 1.1.0.GA_CP1 Or should we create a "post-release" convention, with a numeric field (non-zero, to distinguish from pre-release tags) followed by the alphanumeric from upstream, like "GA", "GA_CP1" etc? Please, think a little bit about this, they have quite a few packages. Regards to all, Fernando P.S.: We don't need the leading '0.' in this case as there won't be a following pure digit version, like it happens for pre-release tags.

4 6

[review: xorg-x11-server-Xgl] How you prefer start Xgl?
by alcapcom 21 Mar '07

21 Mar '07

Hi list, Few months ago I have add a review for Xgl, without success at this time. Considering that fglrx driver still not support AIGLX, this package is useful for most of the fedora Desktop users. The specfile follow the packaging guide line, and seem to be clean. The only blocker that stay is "howto start Xgl". The goal of this mail, is to know which of the two solutions you preferred and why. Have try to sum the (+/-) of each solution, if there is other coolstuff/limitation/problem of one of them, it should be useful to know too. In advance, Thanks. Alphonse Start Xgl from GDM (session menu) --------------------------------- (+) The login time is shorter (last Xorg improvement) (+) Can choice a X type before login (-) Traditionally X is started on the display :0, but that is not possible if we start Xgl from GDM (dislay :0 should already used by GDM) (-) There are 3 log files for X (Xorg.0.log, Xorg.1.log and Xorg.93.log) that should appear strange for the end user. (-) For each WM available available on fedora, we needs a .desktop file (GDM session menu can quickly look too long) (-) two X are loaded at boot time + 1 if rgbd is used (graphical boot). Try it : http://files.damaestro.us/xgl/Xgl-settings-0.1-3.fc6.noarch.rpm Start GDM with Xgl ------------------ (+) do not have any of (-) thing of the first solution. (-) The only thing that I see is that the login take more time between the username input and the password input. Try it: http://download.tuxfamily.org/fedoraxgl/6/i386/system-config-xselector-0.1-… --- REVIEW BZ: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=192436 SPEC: http://download.tuxfamily.org/fedoraxgl/SPECS/xorg-x11-server-Xgl.spec SRPM: http://download.tuxfamily.org/fedoraxgl/SRPMS/xorg-x11-server-Xgl-0-0.4.200…

1 0

cmake rpm macro(s):
by Rex Dieter 20 Mar '07

20 Mar '07

Appended is a first try at rpm macro'izing the the call to cmake per: http://fedoraproject.org/wiki/PackagingDrafts/cmake I chose not to implement the out-of-tree style of build in the PackagingDraft to keep things simple(r). Made each cmake option a separate macro to make in easier to override. Comments? -- Rex ################################# ## /etc/rpm/macros.cmake: %_cmake_install_prefix -DCMAKE_INSTALL_PREFIX:PATH=%{_prefix} %_cmake_build_shared_libs -DBUILD_SHARED_LIBS:BOOL=ON %_cmake_lib_suffix64 -DLIB_SUFFIX=64 %cmake \ CFLAGS="${CFLAGS:-%optflags}" ; export CFLAGS ; \ CXXFLAGS="${CXXFLAGS:-%optflags}" ; export CXXFLAGS ; \ FFLAGS="${FFLAGS:-%optflags}" ; export FFLAGS ; \ %{_bindir}/cmake \\\ %{?_cmake_install_prefix} \\\ %{?_cmake_build_shared_libs} \\\ %if "%{?_lib}" == "lib64" \ %{?_cmake_lib_suffix64} \\\ %endif \ ###############################3#

6 20

Repotag in EPEL
by Thorsten Leemhuis 20 Mar '07

20 Mar '07

Hi, I'd like to ask the Packaging Committee (which afaics is responsible for the Packaging standards used in Fedora projects, which includes EPEL) for advice and a formal decision about using a repotag in EPEL. There are a lot of people strongly urging to use one -- see attached mails or the threads in the online archive at https://www.redhat.com/archives/epel-devel-list/2007-March/msg00224.html https://www.redhat.com/archives/epel-devel-list/2007-March/msg00258.html I (and some other EPEL SIG members afaics) don't care much about using one or not. But afaics the use of a repotag is unwanted in Fedora-land up to now afaics. If the answer from the PC is "yes, EPEL is free to use a repotag" then please decide how to actually use it -- Add a "repotag" macro defined by the buildsys or overload %{dist}, ... We need a decision soon. Thanks for your support. CU thl

6 7

How to deal with folders that need the user to change permissions on?
by Axel Thimm 15 Mar '07

15 Mar '07

Hi, the default mediawiki install does not allow image uploads (on puprose) and requires the user to adjust permissions (#231542). Perhaps there is a better way to deal with this in mediawiki, but the general issue came up: Suppose a package requires the user/admin to change permissions on a folder to enable some functionality. How do we deal with that? A package upgrade resets the permissions and there is no way to tell rpm that this folder is "%configdir". A workaround would be to not own this folder which is very ugly, violates guidelines, leaves orphaned folders behind, and is just not The Right Solution. Which is The Right Solution? (again in the context of "folder permission change really required by a package", I hope mediawiki's issue may be worked around, so don't stick to this example) -- Axel.Thimm at ATrpms.net

2 3

buildroot race condition
by Till Maas 14 Mar '07

14 Mar '07

Hello, an OpenSUSE packager made me aware of a race condition problem with a lot of fedora specs: http://lists.opensuse.org/opensuse-packaging/2007-02/msg00005.html A lot of specs and the template specs from rpmdev-newspec use following: %install rm -rf $RPM_BUILD_ROOT # racing time mkdir -p $RPM_BUILD_ROOT/bla/foo The solution is to make the following mandatory: %install rm -rf $RPM_BUILD_ROOT mkdir $RPM_BUILD_ROOT # this fails when $RPM_BUILD_ROOT already exists Regards, Till

9 21

legal guidelines for new fonts?
by Jens-Ulrik Petersen 12 Mar '07

12 Mar '07

Hi, Would it be a good idea to add a page under Packaging describing basic legal requirements for new fonts being added to Fedora? Typically it is a good idea to contact the original authors and the maintainers of fonts to ascertain the origin and ownership of the design as part of the review process. I think this is something that we should consider making mandatory for all new fonts packages. Jens

1 0

perl-* build dependencies
by Ville Skyttä 12 Mar '07

12 Mar '07

Hello, Whether the perl/perl-devel split in devel (#226276) is here to stay or not, I'd like to make the attached change to the rpmdevtools perl spec template. Using perl(ExtUtils::MakeMaker) as the "base" build dependency is correct in the vast majority of cases, no matter in which package ExtUtils::MakeMaker is included. Packages using Module::Build should change the dep to perl(Module::Build) - that'll pull in ExtUtils::MakeMaker too in case it's needed for Module::Build's non-compat mode. Doing the build dep this way should work for all distro versions as-is without the need to put ugly conditionals on whether to pull in perl-devel or not or whatever other perl package reorganizations we might see in the future. I see some packagers have already started to make those unnecessary specfile complications/per-distro forks so it'd be good to have this in the spec template as well as applicable Wiki pages as soon as possible. Comments, objections?

5 5

Temporarily removing a sub-package
by Orion Poplawski 09 Mar '07

09 Mar '07

I'm looking to remove the -mpi subpackage of paraview because it does not build. I've poked upstream to no avail, and I haven't been able to figure out the problem myself. If this gets fixed, I'd like to add it back. In the meantime, what kind of Provides/Obsoletes makes sense? Provides: paraview-mpi Obsoletes: paraview-mpi < %{version}-%{release} ? -- 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

3 4

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

packaging March 2007