packaging April 2005

packaging@lists.fedoraproject.org

10 participants
5 discussions

Packages changing SELinux configurations
by Jose Pedro Oliveira 23 Apr '05

23 Apr '05

Hi, I would like to ask a couple of questions regarding SELinux configurations: 1) is it valid to change SELinux booleans from within a specfile (via scripts/triggers) ? 2) and adding local rules and make selinux reload them (also via scripts/triggers)? In my particular case - the package syslog-ng [1] - needs to activate the "use_syslogng" SELinux boolean that exists only after selinux-policy-targeted >= 1.17.30-2.96 (to be correct the boolean exists after release 2.90 but the rules are more useful/correct after release 2.96 [2]). I have done the following changes to the base specfile but I am wondering if they are valid? I remember reading something a while back that packages *should not* change SELinux configurations. ----------------------------------------------------------- ... # SELinux (Fedora Core 3) Requires(preun): libselinux Requires(post): libselinux Requires: selinux-policy-targeted >= 1.17.30-2.96 ... %post if [ $1 = 1 ]; then setsebool -P use_syslogng 1 ... fi %preun if [ $1 = 0 ]; then ... setsebool -P use_syslogng 0 fi ... ----------------------------------------------------------- Feedback would be appreciated. Thanks in advance, jpo References: [1] Bug 1332 - syslog-ng is a sysklogd replacement https://bugzilla.fedora.us/show_bug.cgi?id=1332 [2] Fedora Core 3, SELinux, and syslog-ng See comment #33 of the above ticket -- José Pedro Oliveira * mailto: jpo(a)di.uminho.pt * http://gsd.di.uminho.pt/~jpo * * gpg fingerprint = F9B6 8D87 859D 1C94 48F0 84C0 9749 9EB5 91BD 851B *

1 0

Can you review my specfile: rsnapshot.spec
by Gavin Henry 12 Apr '05

12 Apr '05

Dear all, Not sure if I should e-mail the Extras list or this, so here goes: Anything stupid that I have missed? I have imported the srpm to Extras devel. ---------- Name: rsnapshot Summary: Local and remote filesystem snapshot utility Version: 1.2.1 Release: 1 License: GPL Group: Applications/System Url: http://www.rsnapshot.org Source0: http://www.rsnapshot.org/downloads/rsnapshot-1.2.1.tar.gz Patch0: rsnapshot.patch BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) Requires: perl, rsync, ssh AutoReqProv: no %description This is a remote backup program that uses rsync to take backup snapshots of filesystems. It uses hard links to save space on disk. %prep rm -rf %{buildroot} %setup %patch %build %configure %install install -d %{buildroot}/%{_bindir} install -m 755 rsnapshot %{buildroot}/%{_bindir}/rsnapshot install -d %{buildroot}/%{_mandir}/man1 install -m 644 rsnapshot.1 %{buildroot}/%{_mandir}/man1/ install -d %{buildroot}/%{_sysconfdir} install -m 644 rsnapshot.conf.default %{buildroot}/%{_sysconfdir}/rsnapshot.conf.default install -m 600 rsnapshot.conf.default %{buildroot}/%{_sysconfdir}/rsnapshot.conf %post # # upgrade rsnapshot config file # RSNAPSHOT_CONFIG_VERSION=`%{_bindir}/rsnapshot check-config-version` if test $? != 0; then echo "Error upgrading %{_sysconfdir}/rsnapshot.conf" fi if test "$RSNAPSHOT_CONFIG_VERSION" = "1.2"; then # already latest version exit 0 fi if test "$RSNAPSHOT_CONFIG_VERSION" = "unknown"; then %{_bindir}/rsnapshot upgrade-config-file RETVAL=$? exit $RETVAL fi echo "Error upgrading %{_sysconfdir}/rsnapshot.conf. Config format unknown!" exit 1 %clean rm -rf %{buildroot} %files %defattr(-,root,root) %verify(user group mode md5 size mtime) %doc AUTHORS COPYING ChangeLog README INSTALL TODO %verify(user group mode md5 size mtime) %config %{_sysconfdir}/rsnapshot.conf.default %verify(user group mode) %config(noreplace) %{_sysconfdir}/rsnapshot.conf %verify(user group mode md5 size mtime) %{_bindir}/rsnapshot %verify(user group mode md5 size mtime) %{_mandir}/man1/rsnapshot.1* %changelog * Tue Apr 12 2005 Gavin Henry <ghenry(a)suretecsystems.com> - Cleaned up a lot and imported to Fedora Extras * Sun Jan 29 2005 Nathan Rosenquist <nathan(a)rsnapshot.org> - Added upgrade script * Sat Jan 22 2005 Nathan Rosenquist <nathan(a)rsnapshot.org> - Added --with-du option * Thu Jan 15 2004 Nathan Rosenquist <nathan(a)rsnapshot.org> - Added "AutoReqProv: no" for SuSE compatibility * Fri Dec 26 2003 Nathan Rosenquist <nathan(a)rsnapshot.org> - Added util-linux dependency, and --with-logger= option * Fri Dec 19 2003 Nathan Rosenquist <nathan(a)rsnapshot.org> - now fully support autoconf * Tue Dec 16 2003 Nathan Rosenquist <nathan(a)rsnapshot.org> - changed rsnapshot.conf to rsnapshot.conf.default from the source tree * Wed Nov 05 2003 Nathan Rosenquist <nathan(a)rsnapshot.org> - Removed fileutils dependency, added verification info * Tue Nov 04 2003 Nathan Rosenquist <nathan(a)rsnapshot.org> - fixed anonymous rsync error * Thu Oct 30 2003 Nathan Rosenquist <nathan(a)rsnapshot.org> - update to 1.0.3 * Tue Oct 28 2003 Carl Wilhelm Soderstrom <chrome(a)real-time.com> - created spec file Thanks all. -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 742001 E ghenry(a)suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/

2 4

Re: dist tag usage
by Rex Dieter 07 Apr '05

07 Apr '05

Ignacio Vazquez-Abrams wrote on fedora-extras-list: > It's part of the disttag set. > http://www.fedoraproject.org/wiki/DistTag Here's a suggestion for that page: Replace %{?dist:%{dist}} references with %{?dist} (It's shorter and produces the same result). -- Rex

1 0

perl module MODULE_COMPAT
by Warren Togami 05 Apr '05

05 Apr '05

Requires: perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo $version)) As long as we're going through all FC4 perl modules, we might as well add this to all packages too. Just confirming, is this wanted in *ALL* packages that need perl, both regular arch and noarch? Warren Togami wtogami(a)redhat.com

5 14

dist tag revisited
by Tom Callaway 04 Apr '05

04 Apr '05

I had an insightful discussion with Sopwith this afternoon, and we discussed the idea of dist tags, and some important discussion arose: Elliot pointed out that for any given .src.rpm, the name-version-release needs to stay fixed for all builds of that .src.rpm. Otherwise it becomes impossible to track packages back to their source, keep an audit trail, etc. The problem with using the macros is that if a maintainer does 'make build' on an fc3 box, then they get the dist tag value from that machine in the n-v-r. When they go to check this into CVS (say, into the fc4 branch), its wrong. We don't want someone doing 'make tag' on the FC-4 branch and having n-v-r = foo-1.2-3.fc3. But at the same time, we also want to avoid forcing the packagers to have to put the dist value into the spec manually. This defeats the entire reason for dist tags, which is to have a single spec that can be used for multiple distributions. We discussed a lot of options, but Elliot came up with a good idea, which is best explained by giving an example of a new package commit: - I'm a maintainer, of package logjam. - I make a single spec for all possible fc builds using the documented "approved" dist macros - I set Release: 1 (note, no %{dist}) - I make my src.rpm. - I then run ./cvs-import.sh --use-dist --branch=fc4 logjam-1.0.0-1.src.rpm - The cvs-import script does the following: - Checks my spec to make sure that n-v-r doesn't have %{dist} in it already - Notes the value of the branch that I'm checking this package into - Uses that value and adds the following lines to the top of my spec %define fedora 4 %define dist .fc4 - Appends %{?dist} to the end of Release (so it becomes Release: 1%{?dist} ) - Commits the spec with the added defines into the branch. Now, with this mechanism, if I want to do multiple branches for a single spec, its easy, cvs-import.sh does the work for me. We keep a single n-v-r per branch, and there is no naming conflicts between branches. The branch-copy operations would just change the values of the macros, or add the macros near the top if they're not already in the .spec file. We'd want to add a check in the buildsystem to make sure that people haven't polluted the %{dist} defines, but that shouldn't be terribly difficult. Now, for people wanting to take their original spec and build it somewhere else, say for RHEL, we could use a set of rpm macros. Elliot and I worked on a simple shell script that parses /etc/redhat-release and returns (depending on the flag chosen): The version of RHEL for %{_el} (if on RHEL) The version of Fedora for %{_fedora} (if on Fedora) The version of RHL for %{_rhel} (if on RHL) The number of the distro for %{_distnum} The type of the distro for %{_disttype} The dist tag value for %{_dist} The macros then become as simple as: %_dist %{expand:%%(/usr/lib/rpm/redhat/dist.sh --dist)} %_distnum %{expand:%%(/usr/lib/rpm/redhat/dist.sh --distnum)} %_disttype %{expand:%%(/usr/lib/rpm/redhat/dist.sh --disttype)} %_rhel %{expand:%%(/usr/lib/rpm/redhat/dist.sh --el)} %_fedora %{expand:%%(/usr/lib/rpm/redhat/dist.sh --fc)} %_rhl %{expand:%%(/usr/lib/rpm/redhat/dist.sh --rhl)} The script is already checked into CVS for redhat-rpm-config. If you wanted to build off that spec for RHEL, you'd just need to add these 7 lines to your local .rpmmacros file. This provides a standardized, easy way to do single-spec, multiple distribution packaging. But of course, there are bound to be complications. Please ponder this implementation, and offer feedback. Thanks, ~spot -- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my!

5 5

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

packaging April 2005