From dag at wieers.com Sat Apr 2 03:26:40 2005 From: dag at wieers.com (Dag Wieers) Date: Sat, 2 Apr 2005 05:26:40 +0200 (CEST) Subject: [Fedora-packaging] perl module MODULE_COMPAT In-Reply-To: <20050331151213.12383119.bugs.michael@gmx.net> References: <424BBDEB.5070907@redhat.com> <20050331132959.79acc1ea.bugs.michael@gmx.net> <20050331151213.12383119.bugs.michael@gmx.net> Message-ID: On Thu, 31 Mar 2005, Michael Schwendt wrote: > On Thu, 31 Mar 2005 15:02:19 +0200 (CEST), Dag Wieers wrote: > > > On Thu, 31 Mar 2005, Michael Schwendt wrote: > > > > > On Wed, 30 Mar 2005 23:07:55 -1000, Warren Togami wrote: > > > > > > > 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? > > > > > > Certainly for all Perl module packages which install files into versioned > > > Perl vendor lib locations (or site lib, although that should not be done). > > > That's the only way to ensure that the main "perl" actually supports loading > > > from those versioned directories. > > > > One important point, you are (or have been) effectively dropping support > > for every distro prior to FC1. > > No. That's what the perl-forward-compat package has been for: > > http://download.fedora.us/fedora/redhat/8.0/i386/RPMS.stable/perl-forward-compat-5.8.0-0.fdr.2.i386.rpm Seems reasonable, only that it is yet again different than how it is handled with python. I know the situation is a bit different, but the implementation is completely different. (naming and how versioning works) -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power] From ville.skytta at iki.fi Sat Apr 2 08:10:15 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sat, 02 Apr 2005 11:10:15 +0300 Subject: [Fedora-packaging] perl module MODULE_COMPAT In-Reply-To: <200504010302.49909.symbiont@berlios.de> References: <424BBDEB.5070907@redhat.com> <200504010302.49909.symbiont@berlios.de> Message-ID: <1112429416.23456.22.camel@bobcat.mine.nu> On Fri, 2005-04-01 at 03:02 +0800, Jeff Pitman wrote: > On Thursday 31 March 2005 17:07, Warren Togami wrote: > > Requires: perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo > > $version)) > > What about Requires: perl(abi) = 5.8 or whatever? Similar in the vein > of how Python packages are being put together. :MODULE_COMPAT_ seems a > bit overkill. Maybe I'm not seeing the whole picture, but it'd be nice > to have some consistency even between different module-based > interpreted languages. Agreed in principle, but IMO hardly worth changing unless it's done automatically by rpmbuild, like it does for Python in Rawhide/FC4tX. This provision was added there specifically for the purpose of being the official interface for depending on a specific ABI-compatible version of Perl. Such interfaces cannot obviously be changed without good reasons and a deprecation period. :MODULE_COMPAT_* may not be eye candy, but it is there (and was there before Python got a similar one), does what it's intended to do, and masses of specfiles depend on its presence. IIRC cpanflute2 also adds those dependencies nowadays, so some tools would need fixes too, not only existing packages, if it went away. OT: ISTR the ruby package lacks this kind of "abi" provision, yet it has site-* in similar manner as python and perl packages. From bugs.michael at gmx.net Sat Apr 2 10:57:31 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 2 Apr 2005 12:57:31 +0200 Subject: [Fedora-packaging] perl module MODULE_COMPAT In-Reply-To: References: <424BBDEB.5070907@redhat.com> <20050331132959.79acc1ea.bugs.michael@gmx.net> <20050331151213.12383119.bugs.michael@gmx.net> Message-ID: <20050402125731.5811e06c.bugs.michael@gmx.net> On Sat, 2 Apr 2005 05:26:40 +0200 (CEST), Dag Wieers wrote: > > > One important point, you are (or have been) effectively dropping support > > > for every distro prior to FC1. > > > > No. That's what the perl-forward-compat package has been for: > > > > http://download.fedora.us/fedora/redhat/8.0/i386/RPMS.stable/perl-forward-compat-5.8.0-0.fdr.2.i386.rpm > > Seems reasonable, only that it is yet again different than how it is > handled with python. I know the situation is a bit different, but the > implementation is completely different. (naming and how versioning works) Yes, it's different, but it was subject to public discussion [1], and none of the few people who had comments disagreed strongly. With the new and automated 'python(abi) = ...' dependency in FC4 devel, the solution on the Python side has become even more different, btw. -- [1] http://www.redhat.com/archives/rhl-devel-list/2004-February/thread.html#00678 From wtogami at redhat.com Sun Apr 3 12:04:44 2005 From: wtogami at redhat.com (Warren Togami) Date: Sun, 03 Apr 2005 02:04:44 -1000 Subject: [Fedora-packaging] perl module MODULE_COMPAT In-Reply-To: <20050402125731.5811e06c.bugs.michael@gmx.net> References: <424BBDEB.5070907@redhat.com> <20050331132959.79acc1ea.bugs.michael@gmx.net> <20050331151213.12383119.bugs.michael@gmx.net> <20050402125731.5811e06c.bugs.michael@gmx.net> Message-ID: <424FDBDC.6010802@redhat.com> Michael Schwendt wrote: > On Sat, 2 Apr 2005 05:26:40 +0200 (CEST), Dag Wieers wrote: > > >>>>One important point, you are (or have been) effectively dropping support >>>>for every distro prior to FC1. >>> >>>No. That's what the perl-forward-compat package has been for: >>> >>>http://download.fedora.us/fedora/redhat/8.0/i386/RPMS.stable/perl-forward-compat-5.8.0-0.fdr.2.i386.rpm >> >>Seems reasonable, only that it is yet again different than how it is >>handled with python. I know the situation is a bit different, but the >>implementation is completely different. (naming and how versioning works) > > > Yes, it's different, but it was subject to public discussion [1], and > none of the few people who had comments disagreed strongly. > > With the new and automated 'python(abi) = ...' dependency in FC4 devel, > the solution on the Python side has become even more different, btw. > MODULE_COMPAT was designed to allow for distinctions of more than just the version (which is all python-abi does). This is necessary for perl and not python because it is possible to rebuild perl in different ways that breaks ABI compat, while python is almost entirely noarch. This happened with the perl package IIRC in the RH8-RH9-RHEL3 timeframe. Since then however perl has not broken ABI (?), so it seems that we have this seemingly overcomplicated construct. But if we do break ABI again like in FC5 because we recompile the same version of FC4 perl with some new flag, MODULE_COMPAT can enforce exact deps and prevent incompatible FC4 packages from being installed on FC5. Chip put a lot of thought into designing this. Warren Togami wtogami at redhat.com From bugs.michael at gmx.net Sun Apr 3 14:24:46 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 3 Apr 2005 16:24:46 +0200 Subject: [Fedora-packaging] perl module MODULE_COMPAT In-Reply-To: <424FDBDC.6010802@redhat.com> References: <424BBDEB.5070907@redhat.com> <20050331132959.79acc1ea.bugs.michael@gmx.net> <20050331151213.12383119.bugs.michael@gmx.net> <20050402125731.5811e06c.bugs.michael@gmx.net> <424FDBDC.6010802@redhat.com> Message-ID: <20050403162446.3d38b5e2.bugs.michael@gmx.net> On Sun, 03 Apr 2005 02:04:44 -1000, Warren Togami wrote: > MODULE_COMPAT was designed to allow for distinctions of more than just > the version (which is all python-abi does). This is necessary for perl > and not python because it is possible to rebuild perl in different ways > that breaks ABI compat, while python is almost entirely noarch. This > happened with the perl package IIRC in the RH8-RH9-RHEL3 timeframe. > > Since then however perl has not broken ABI (?), so it seems that we have > this seemingly overcomplicated construct. But if we do break ABI again > like in FC5 because we recompile the same version of FC4 perl with some > new flag, MODULE_COMPAT can enforce exact deps and prevent incompatible > FC4 packages from being installed on FC5. > > Chip put a lot of thought into designing this. I've thought the perl(:WITH_FOO) virtual provides define the Perl ABI requirements and not perl(:MODULE_COMPAT_...). From wtogami at redhat.com Mon Apr 4 01:19:20 2005 From: wtogami at redhat.com (Warren Togami) Date: Sun, 03 Apr 2005 15:19:20 -1000 Subject: [Fedora-packaging] perl module MODULE_COMPAT In-Reply-To: <424FDBDC.6010802@redhat.com> References: <424BBDEB.5070907@redhat.com> <20050331132959.79acc1ea.bugs.michael@gmx.net> <20050331151213.12383119.bugs.michael@gmx.net> <20050402125731.5811e06c.bugs.michael@gmx.net> <424FDBDC.6010802@redhat.com> Message-ID: <42509618.2010003@redhat.com> Warren Togami wrote: > Since then however perl has not broken ABI (?), so it seems that we have > this seemingly overcomplicated construct. But if we do break ABI again > like in FC5 because we recompile the same version of FC4 perl with some > new flag, MODULE_COMPAT can enforce exact deps and prevent incompatible > FC4 packages from being installed on FC5. > [root at fedora64 perl5]# ls 5.8.0 5.8.1 5.8.2 5.8.3 5.8.4 5.8.5 5.8.6 site_perl vendor_perl [root at fedora64 perl5]# pwd /usr/lib64/perl5 Hmm, FC4 still continues to have symlinks going back to 5.8.0 (RHEL3). I think this is a mistake. We haven't maintained ABI compat that long right? Dirs should have been removed when they are known to be incompatible. Warren Togami wtogami at redhat.com From tcallawa at redhat.com Mon Apr 4 01:39:07 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Sun, 03 Apr 2005 20:39:07 -0500 Subject: [Fedora-packaging] dist tag revisited In-Reply-To: <1111696922.3698.93.camel@localhost.localdomain> References: <1111696922.3698.93.camel@localhost.localdomain> Message-ID: <1112578748.15642.128.camel@localhost.localdomain> > Please ponder this implementation, and offer feedback. Since no one has offered any feedback, either no one cares, or what I've proposed is acceptable without comment. Please let me know which one is accurate. :) ~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! From dag at wieers.com Mon Apr 4 02:39:50 2005 From: dag at wieers.com (Dag Wieers) Date: Mon, 4 Apr 2005 04:39:50 +0200 (CEST) Subject: [Fedora-packaging] dist tag revisited In-Reply-To: <1112578748.15642.128.camel@localhost.localdomain> References: <1111696922.3698.93.camel@localhost.localdomain> <1112578748.15642.128.camel@localhost.localdomain> Message-ID: On Sun, 3 Apr 2005, Tom 'spot' Callaway wrote: > > Please ponder this implementation, and offer feedback. > > Since no one has offered any feedback, either no one cares, or what I've > proposed is acceptable without comment. > > Please let me know which one is accurate. :) I didn't reply because CVS and the internal buildsystem do not affect me. But if you want to know my opinion, I think the actual tagging should be done by the buildsystem and not by CVS, RPM or the packager. I have said this before during the disttag discussions, so nothing new here. PS Could you clarify again what's inside %{dist}, %{distnum} and %{disttype} ? My buildsystem currently knows: dist -> fc3 disttag -> 1.fc3 fc3 -> 1 and the necessary dot is added by the buildsystem to disttag. Only dist and fc3 are used inside SPEC files. I think we have to rely on the macro language for granularity anyway (say you want a patch only to apply for fc2 and fc3, not fc1 and fc4). Kind regards, -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power] From Axel.Thimm at ATrpms.net Mon Apr 4 02:46:37 2005 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 4 Apr 2005 04:46:37 +0200 Subject: [Fedora-packaging] Re: dist tag revisited In-Reply-To: References: <1111696922.3698.93.camel@localhost.localdomain> <1112578748.15642.128.camel@localhost.localdomain> Message-ID: <20050404024637.GC1802@neu.nirvana> On Mon, Apr 04, 2005 at 04:39:50AM +0200, Dag Wieers wrote: > On Sun, 3 Apr 2005, Tom 'spot' Callaway wrote: > > > > Please ponder this implementation, and offer feedback. > > > > Since no one has offered any feedback, either no one cares, or what I've > > proposed is acceptable without comment. > > > > Please let me know which one is accurate. :) > > I didn't reply because CVS and the internal buildsystem do not affect me. > But if you want to know my opinion, I think the actual tagging should be > done by the buildsystem and not by CVS, RPM or the packager. > > I have said this before during the disttag discussions, so nothing new > here. Same here. Very early at ATrpms I had the disttag internal to the buildsystem, but this is a very bad choice. It need to be passed from the outside. Nothing against a patch to rpm that makes it easier to manage the disttag, e.g. different distag for src.rpm that for binary rpm (i.e. no disttag for src.rpm). -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ville.skytta at iki.fi Mon Apr 4 06:40:23 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Mon, 04 Apr 2005 09:40:23 +0300 Subject: [Fedora-packaging] perl module MODULE_COMPAT In-Reply-To: <42509618.2010003@redhat.com> References: <424BBDEB.5070907@redhat.com> <20050331132959.79acc1ea.bugs.michael@gmx.net> <20050331151213.12383119.bugs.michael@gmx.net> <20050402125731.5811e06c.bugs.michael@gmx.net> <424FDBDC.6010802@redhat.com> <42509618.2010003@redhat.com> Message-ID: <1112596824.24368.152.camel@bobcat.mine.nu> On Sun, 2005-04-03 at 15:19 -1000, Warren Togami wrote: > [root at fedora64 perl5]# ls > 5.8.0 5.8.1 5.8.2 5.8.3 5.8.4 5.8.5 5.8.6 site_perl vendor_perl > [root at fedora64 perl5]# pwd > /usr/lib64/perl5 > > Hmm, FC4 still continues to have symlinks going back to 5.8.0 (RHEL3). > I think this is a mistake. We haven't maintained ABI compat that long > right? What makes you think so? > Dirs should have been removed when they are known to be incompatible. Yes, but do we _know_ some of the above are incompatible? From wtogami at redhat.com Mon Apr 4 09:51:37 2005 From: wtogami at redhat.com (Warren Togami) Date: Sun, 03 Apr 2005 23:51:37 -1000 Subject: [Fedora-packaging] perl module MODULE_COMPAT In-Reply-To: <1112596824.24368.152.camel@bobcat.mine.nu> References: <424BBDEB.5070907@redhat.com> <20050331132959.79acc1ea.bugs.michael@gmx.net> <20050331151213.12383119.bugs.michael@gmx.net> <20050402125731.5811e06c.bugs.michael@gmx.net> <424FDBDC.6010802@redhat.com> <42509618.2010003@redhat.com> <1112596824.24368.152.camel@bobcat.mine.nu> Message-ID: <42510E29.7010007@redhat.com> Ville Skytt? wrote: > On Sun, 2005-04-03 at 15:19 -1000, Warren Togami wrote: > > >>[root at fedora64 perl5]# ls >>5.8.0 5.8.1 5.8.2 5.8.3 5.8.4 5.8.5 5.8.6 site_perl vendor_perl >>[root at fedora64 perl5]# pwd >>/usr/lib64/perl5 >> >>Hmm, FC4 still continues to have symlinks going back to 5.8.0 (RHEL3). >>I think this is a mistake. We haven't maintained ABI compat that long >>right? > > > What makes you think so? > > >>Dirs should have been removed when they are known to be incompatible. > > > Yes, but do we _know_ some of the above are incompatible? > I recall Chip mentioning ABI broke sometime after 5.8.0. Maybe I'm wrong... Warren From bugs.michael at gmx.net Mon Apr 4 10:48:20 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 4 Apr 2005 12:48:20 +0200 Subject: [Fedora-packaging] dist tag revisited In-Reply-To: <1112578748.15642.128.camel@localhost.localdomain> References: <1111696922.3698.93.camel@localhost.localdomain> <1112578748.15642.128.camel@localhost.localdomain> Message-ID: <20050404124820.3773df5c.bugs.michael@gmx.net> On Sun, 03 Apr 2005 20:39:07 -0500, Tom 'spot' Callaway wrote: > > > Please ponder this implementation, and offer feedback. > > Since no one has offered any feedback, either no one cares, or what I've > proposed is acceptable without comment. > > Please let me know which one is accurate. :) IMO, the former. I've lost interest in dist tags which require more than appending %{?dist} (or a hardcoded tag) to the release field. We keep packages in a CVS layout with multiple branch directories, not in a single CVS directory with real CVS-style branches. If we wanted to share a single spec for multiple target distributions, we ought to have a build-system which can pull a src.rpm from a CVS-style branch, a single tag _or_ a specific directory and append a dist tag on-the-fly (e.g. by defining %dist). Then we would really share a single source for multiple platforms. The process you describe looks too manual and too error-prone to me. It involves automated modification of a spec file during CVS import, adding hardcoded distribution specific constants and leading to CVS contents which differ in multiple branches. To support this process, the package developer needs to keep a pristine src.rpm somewhere else (for pre-commit building and testing of a single src.rpm on multiple platforms) or import a modified fc4 src.rpm into the fc3/fc2 branches and let the script replace the inserted constants. Package development should look different for 98% of the package developers: update working copy, build test packages on all target platforms, test on all target platforms, cvs commit. With constants hardcoded in the spec--just to work around cvs tagging problems--this is changed. All it takes to add a dist tag, when there is minimal benefit, is to hardcode it in the spec file in the proper branch directory prior to commit. Tools like diff and patch make it convenient enough to duplicate package updates into multiple branch directories. The other rpm macros are helpful, though. From herrold at owlriver.com Mon Apr 4 13:35:32 2005 From: herrold at owlriver.com (R P Herrold) Date: Mon, 4 Apr 2005 09:35:32 -0400 (EDT) Subject: [Fedora-packaging] Re: fedora-pkg] dist tag revisited In-Reply-To: <1112578748.15642.128.camel@localhost.localdomain> References: <1111696922.3698.93.camel@localhost.localdomain> <1112578748.15642.128.camel@localhost.localdomain> Message-ID: On Sun, 3 Apr 2005, Tom 'spot' Callaway wrote: > >> Please ponder this implementation, and offer feedback. > > Since no one has offered any feedback, either no one cares, or what I've > proposed is acceptable without comment. > > Please let me know which one is accurate. :) There is another alternative: that prior forays through this have left the parties exhausted ;) - Russ Herrold From ville.skytta at iki.fi Tue Apr 5 14:59:02 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Tue, 05 Apr 2005 17:59:02 +0300 Subject: [Fedora-packaging] perl module MODULE_COMPAT In-Reply-To: <42510E29.7010007@redhat.com> References: <424BBDEB.5070907@redhat.com> <20050331132959.79acc1ea.bugs.michael@gmx.net> <20050331151213.12383119.bugs.michael@gmx.net> <20050402125731.5811e06c.bugs.michael@gmx.net> <424FDBDC.6010802@redhat.com> <42509618.2010003@redhat.com> <1112596824.24368.152.camel@bobcat.mine.nu> <42510E29.7010007@redhat.com> Message-ID: <1112713142.22818.30.camel@bobcat.mine.nu> On Sun, 2005-04-03 at 23:51 -1000, Warren Togami wrote: > I recall Chip mentioning ABI broke sometime after 5.8.0. Maybe I'm wrong... No, you're right, I forgot. man perl582delta or http://search.cpan.org/dist/perl/pod/perl582delta.pod#Incompatible_Changes FWIW, I don't remember running into this myself nor seeing any related bug reports. The changelog of the perl package does not contain hints of special patches having been applied in the shipped 5.8.1 series packages that would fix the incompatibility. So, 5.8.1 would be a candidate for removal from the compat list, and @INC and friends. All perl-* packages in Rawhide have been built with 5.8.3 or later, and IIRC no perl-* packages have been removed from FC since FC1 (5.8.1) so the removal wouldn't seem to need any actions there. It would affect 3rd party packages and locally installed modules done with 5.8.1 but still in use with current FC4 perl. But that is probably close to an empty set today. Also, the perl-5.8.0's shipped in RHL9 and RHEL3 have quite a few patches applied, including at least some upstream ones (according to the changelog of the package). If some of those patches introduced the binary incompatibility present in upstream 5.8.1, 5.8.0 would be a candidate for removal from the compat lists too. From rdieter at math.unl.edu Thu Apr 7 12:23:31 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 07 Apr 2005 07:23:31 -0500 Subject: [Fedora-packaging] Re: dist tag usage In-Reply-To: <1112872576.3405.55.camel@ignacio.ignacio.lan> References: <1112870961.3405.46.camel@ignacio.ignacio.lan> <425514FD.1000703@redhat.com> <1112872576.3405.55.camel@ignacio.ignacio.lan> Message-ID: <42552643.1070008@math.unl.edu> 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 From ghenry at suretecsystems.com Tue Apr 12 11:06:43 2005 From: ghenry at suretecsystems.com (Gavin Henry) Date: Tue, 12 Apr 2005 12:06:43 +0100 (BST) Subject: [Fedora-packaging] Can you review my specfile: rsnapshot.spec Message-ID: <52644.193.195.148.66.1113304003.squirrel@webmail.suretecsystems.com> 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 - Cleaned up a lot and imported to Fedora Extras * Sun Jan 29 2005 Nathan Rosenquist - Added upgrade script * Sat Jan 22 2005 Nathan Rosenquist - Added --with-du option * Thu Jan 15 2004 Nathan Rosenquist - Added "AutoReqProv: no" for SuSE compatibility * Fri Dec 26 2003 Nathan Rosenquist - Added util-linux dependency, and --with-logger= option * Fri Dec 19 2003 Nathan Rosenquist - now fully support autoconf * Tue Dec 16 2003 Nathan Rosenquist - changed rsnapshot.conf to rsnapshot.conf.default from the source tree * Wed Nov 05 2003 Nathan Rosenquist - Removed fileutils dependency, added verification info * Tue Nov 04 2003 Nathan Rosenquist - fixed anonymous rsync error * Thu Oct 30 2003 Nathan Rosenquist - update to 1.0.3 * Tue Oct 28 2003 Carl Wilhelm Soderstrom - 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 at suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/ From ghenry at suretecsystems.com Tue Apr 12 11:15:38 2005 From: ghenry at suretecsystems.com (Gavin Henry) Date: Tue, 12 Apr 2005 12:15:38 +0100 (BST) Subject: [Fedora-packaging] Can you review my specfile: rsnapshot.spec In-Reply-To: <52644.193.195.148.66.1113304003.squirrel@webmail.suretecsystems.com> References: <52644.193.195.148.66.1113304003.squirrel@webmail.suretecsystems.com> Message-ID: <53083.193.195.148.66.1113304538.squirrel@webmail.suretecsystems.com> Doh, I forgot I had already imported and that there is a ticket open with comments already: https://bugzilla.fedora.us/show_bug.cgi?id=1298 I get on with it then. Too much going on, sorry guys. -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 742001 E ghenry at suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/ From bugs.michael at gmx.net Tue Apr 12 12:18:39 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 12 Apr 2005 14:18:39 +0200 Subject: [Fedora-packaging] Can you review my specfile: rsnapshot.spec In-Reply-To: <52644.193.195.148.66.1113304003.squirrel@webmail.suretecsystems.com> References: <52644.193.195.148.66.1113304003.squirrel@webmail.suretecsystems.com> Message-ID: <20050412141839.0eb0a8e7.bugs.michael@gmx.net> On Tue, 12 Apr 2005 12:06:43 +0100 (BST), Gavin Henry wrote: > Dear all, > > Not sure if I should e-mail the Extras list or this, so here goes: Specific review requests should be posted to fedora-extras-list. > Anything stupid that I have missed? > > I have imported the srpm to Extras devel. CVS commits are posted to fedora-extras-commits list automatically: http://www.redhat.com/mailman/listinfo/fedora-extras-commits I've posted a comment there (but included you in Cc in case you didn't know about the list before). As I won't find time to take a deep look, another comment here. The overly verbose %verify(user group mode md5 size mtime) in the %files section should be deleted alltogether unless you have a good reason why to add them. > %prep > rm -rf %{buildroot} The rm -rf %buildroot is not needed here. "install" with option "-p" would be nice, because it preserves timestamps on installed files and enables users to see the age of static files easily. From ghenry at suretecsystems.com Tue Apr 12 13:05:38 2005 From: ghenry at suretecsystems.com (Gavin Henry) Date: Tue, 12 Apr 2005 14:05:38 +0100 (BST) Subject: [Fedora-packaging] Can you review my specfile: rsnapshot.spec In-Reply-To: <20050412141839.0eb0a8e7.bugs.michael@gmx.net> References: <52644.193.195.148.66.1113304003.squirrel@webmail.suretecsystems.com> <20050412141839.0eb0a8e7.bugs.michael@gmx.net> Message-ID: <63769.193.195.148.66.1113311138.squirrel@webmail.suretecsystems.com> > On Tue, 12 Apr 2005 12:06:43 +0100 (BST), Gavin Henry wrote: > >> Dear all, >> >> Not sure if I should e-mail the Extras list or this, so here goes: > > Specific review requests should be posted to fedora-extras-list. > >> Anything stupid that I have missed? >> >> I have imported the srpm to Extras devel. > > CVS commits are posted to fedora-extras-commits list automatically: > http://www.redhat.com/mailman/listinfo/fedora-extras-commits > > I've posted a comment there (but included you in Cc in case you > didn't know about the list before). > > As I won't find time to take a deep look, another comment here. > The overly verbose > > %verify(user group mode md5 size mtime) > > in the %files section should be deleted alltogether unless you > have a good reason why to add them. > > >> %prep >> rm -rf %{buildroot} > > The rm -rf %buildroot is not needed here. > > > "install" with option "-p" would be nice, because it preserves timestamps > on installed files and enables users to see the age of static files > easily. Done. Can you point me to the wiki page that shows how to checkout your own module again, I've forgotten. -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 742001 E ghenry at suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/ From bugs.michael at gmx.net Tue Apr 12 13:44:27 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 12 Apr 2005 15:44:27 +0200 Subject: [Fedora-packaging] Can you review my specfile: rsnapshot.spec In-Reply-To: <63769.193.195.148.66.1113311138.squirrel@webmail.suretecsystems.com> References: <52644.193.195.148.66.1113304003.squirrel@webmail.suretecsystems.com> <20050412141839.0eb0a8e7.bugs.michael@gmx.net> <63769.193.195.148.66.1113311138.squirrel@webmail.suretecsystems.com> Message-ID: <20050412154427.031c843d.bugs.michael@gmx.net> On Tue, 12 Apr 2005 14:05:38 +0100 (BST), Gavin Henry wrote: > Can you point me to the wiki page that shows how to checkout your own > module again, I've forgotten. http://cvs.fedora.redhat.com/ [ http://cvs.fedora.redhat.com/extras.shtml http://cvs.fedora.redhat.com/makefile.shtml ] http://fedoraproject.org/wiki/Extras F'up to fedora-extras-list, please. From jpo at di.uminho.pt Sun Apr 24 01:23:20 2005 From: jpo at di.uminho.pt (Jose Pedro Oliveira) Date: Sun, 24 Apr 2005 02:23:20 +0100 (WEST) Subject: [Fedora-packaging] Packages changing SELinux configurations Message-ID: <1721.213.13.86.100.1114305800.squirrel@webmail.lsd.di.uminho.pt> 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 at di.uminho.pt * http://gsd.di.uminho.pt/~jpo * * gpg fingerprint = F9B6 8D87 859D 1C94 48F0 84C0 9749 9EB5 91BD 851B *