From mmahut at fedoraproject.org Tue Jan 1 23:11:31 2008 From: mmahut at fedoraproject.org (Marek Mahut) Date: Wed, 02 Jan 2008 00:11:31 +0100 Subject: [Fedora-packaging] Contributor License Agreement (CLA) In-Reply-To: <20071230101946.0c1428ad@redhat.com> References: <4777AE3B.6050508@seanet.com> <20071230101946.0c1428ad@redhat.com> Message-ID: <477AC8A3.100@fedoraproject.org> Jesse Keating wrote: > On Sun, 30 Dec 2007 06:42:03 -0800 > Brad Bell wrote: > >> I would like to understand a special case with respect to the CLA. It >> is the case where the Fedora packager is also the copyright holder >> for the package being contributed. >> >> I am the original author and copyright holder for a package. That >> package is currently distributed with the GPLv2 license. If I sign >> the CLA and complete the package contribution, does this mean that >> the original upstream source would no longer covered by the GPLv2 >> license, but rather by the CLA ? > > No. The CLA does not and cannot alter the licensing of any work > brought to Fedora. It is purely for the work done for Fedora by Fedora > contributors, such as wiki entries, spec files (that aren't otherwise > provided/licensed via upstream), documentation, etc... What about patches? Is it under CLA or/and under package license? -- Marek Mahut https://fedoraproject.org/wiki/SIGs/Astronomy/ Fedora Project http://www.jamendo.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From jkeating at redhat.com Wed Jan 2 02:00:28 2008 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 1 Jan 2008 21:00:28 -0500 Subject: [Fedora-packaging] Contributor License Agreement (CLA) In-Reply-To: <477AC8A3.100@fedoraproject.org> References: <4777AE3B.6050508@seanet.com> <20071230101946.0c1428ad@redhat.com> <477AC8A3.100@fedoraproject.org> Message-ID: <20080101210028.66492592@redhat.com> On Wed, 02 Jan 2008 00:11:31 +0100 Marek Mahut wrote: > What about patches? Is it under CLA or/and under package license? Depends on where the patch comes from. You could snake a patch that is a diff from upstream and then it would fall under the upstream license. You could create it from scratch and unless you apply a license to it (which would have to be compatible with the software you're patching's license) I do believe it would fall under the software's license itself. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mtasaka at ioa.s.u-tokyo.ac.jp Wed Jan 2 15:02:54 2008 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Thu, 03 Jan 2008 00:02:54 +0900 Subject: [Fedora-packaging] release of subpackage with version different from main rpm Message-ID: <477BA79E.8020902@ioa.s.u-tokyo.ac.jp> Hi: I guess there are some packages of which subpackage rpms have versions which are different from those of the main rpm. For example, on rawhide perl has 4:5.8.8-32.fc8 EVR and its subpackage perl-ExtUtils-MakeMaker has 0:6.30-32.fc8 EVR. On such case are there any policy for release number? For perl currently the main perl rpm and its subpackages have the same release number. However in other rpms the case may happen that only the version of main rpm will be bumped where the version of its subpackage won't change. In that case usually we want to switch the release number of main rpm to 1%{?dist}, however if its subpackage has different version the release number of the subpackage usually can't be back to 1%{?dist}. How should we treat this case? Regards, Mamoru From rdieter at math.unl.edu Wed Jan 2 15:08:44 2008 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 02 Jan 2008 09:08:44 -0600 Subject: [Fedora-packaging] release of subpackage with version different from main rpm In-Reply-To: <477BA79E.8020902@ioa.s.u-tokyo.ac.jp> References: <477BA79E.8020902@ioa.s.u-tokyo.ac.jp> Message-ID: <477BA8FC.7080103@math.unl.edu> Mamoru Tasaka wrote: > I guess there are some packages of which subpackage rpms have versions > which are different from those of the main rpm. > For example, on rawhide perl has 4:5.8.8-32.fc8 EVR and its subpackage > perl-ExtUtils-MakeMaker has 0:6.30-32.fc8 EVR. > > On such case are there any policy for release number? For perl currently > the main perl rpm and its subpackages have the same release number. > However in other rpms the case may happen that only the version of > main rpm will be bumped where the version of its subpackage won't change. > In that case usually we want to switch the release number of main rpm > to 1%{?dist}, however if its subpackage has different version the release > number of the subpackage usually can't be back to 1%{?dist}. How should > we treat this case? imo, the simplest solutions for cases like this are: 1. don't munge versions for subpkgs, ie, subpkg EVR = main pkg EVR 2. where different Versions are desired, make these a *completely separate* pkg, not just a sub-pkg. -- Rex From rc040203 at freenet.de Wed Jan 2 15:20:41 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 02 Jan 2008 16:20:41 +0100 Subject: [Fedora-packaging] release of subpackage with version different from main rpm In-Reply-To: <477BA79E.8020902@ioa.s.u-tokyo.ac.jp> References: <477BA79E.8020902@ioa.s.u-tokyo.ac.jp> Message-ID: <1199287241.6022.30.camel@beck.corsepiu.local> On Thu, 2008-01-03 at 00:02 +0900, Mamoru Tasaka wrote: > Hi: > > I guess there are some packages of which subpackage rpms have versions > which are different from those of the main rpm. > For example, on rawhide perl has 4:5.8.8-32.fc8 EVR and its subpackage > perl-ExtUtils-MakeMaker has 0:6.30-32.fc8 EVR. > > On such case are there any policy for release number? Except that all packages' and sub-packages' NEVRs must be steadily increasing, there are no explicit policies. > For perl currently > the main perl rpm and its subpackages have the same release number. Right, ... because they are being built as part of the main-perl package. > However in other rpms the case may happen that only the version of > main rpm will be bumped where the version of its subpackage won't change. Right, this also happens for the perl-package. Actually, ATM, the main-perl-package-sources and the sub-packages's sources are independently released, but built simultaneously. I.e. if wanting to be pendantic, theoretically the main-perl package and it's sub-packages are independent. I.e. the fact the sub-packages currently receive identical %rel-tags as the main perl-packages is motivated from "trying to keep the perl package's spec file simple" (and to avoid rpmbuild bugs - processing %version/%release in *.specs is error-prone at best) and can be considered somewhat "sloppy"/"lazy". > In that case usually we want to switch the release number of main rpm > to 1%{?dist}, however if its subpackage has different version the release > number of the subpackage usually can't be back to 1%{?dist}. Right. > How should > we treat this case? I don't see any alternative to having to start with a %release != %{?dist} or to play tricks with epochs (Which I'd rather not recommend to do). Ralf From rc040203 at freenet.de Wed Jan 2 15:21:27 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 02 Jan 2008 16:21:27 +0100 Subject: [Fedora-packaging] release of subpackage with version different from main rpm In-Reply-To: <477BA8FC.7080103@math.unl.edu> References: <477BA79E.8020902@ioa.s.u-tokyo.ac.jp> <477BA8FC.7080103@math.unl.edu> Message-ID: <1199287287.6022.31.camel@beck.corsepiu.local> On Wed, 2008-01-02 at 09:08 -0600, Rex Dieter wrote: > Mamoru Tasaka wrote: > > > I guess there are some packages of which subpackage rpms have versions > > which are different from those of the main rpm. > > For example, on rawhide perl has 4:5.8.8-32.fc8 EVR and its subpackage > > perl-ExtUtils-MakeMaker has 0:6.30-32.fc8 EVR. > > > > On such case are there any policy for release number? For perl currently > > the main perl rpm and its subpackages have the same release number. > > However in other rpms the case may happen that only the version of > > main rpm will be bumped where the version of its subpackage won't change. > > In that case usually we want to switch the release number of main rpm > > to 1%{?dist}, however if its subpackage has different version the release > > number of the subpackage usually can't be back to 1%{?dist}. How should > > we treat this case? > > imo, the simplest solutions for cases like this are: > 1. don't munge versions for subpkgs, ie, subpkg EVR = main pkg EVR > 2. where different Versions are desired, make these a *completely > separate* pkg, not just a sub-pkg. ACK. The perl package should remain a special case and an exception. Ralf From mtasaka at ioa.s.u-tokyo.ac.jp Wed Jan 2 16:52:53 2008 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Thu, 03 Jan 2008 01:52:53 +0900 Subject: [Fedora-packaging] release of subpackage with version different from main rpm In-Reply-To: <1199287287.6022.31.camel@beck.corsepiu.local> References: <477BA79E.8020902@ioa.s.u-tokyo.ac.jp> <477BA8FC.7080103@math.unl.edu> <1199287287.6022.31.camel@beck.corsepiu.local> Message-ID: <477BC165.8050402@ioa.s.u-tokyo.ac.jp> Ralf Corsepius wrote, at 01/03/2008 12:21 AM +9:00: > On Wed, 2008-01-02 at 09:08 -0600, Rex Dieter wrote: >> Mamoru Tasaka wrote: >> >>> I guess there are some packages of which subpackage rpms have versions >>> which are different from those of the main rpm. >>> For example, on rawhide perl has 4:5.8.8-32.fc8 EVR and its subpackage >>> perl-ExtUtils-MakeMaker has 0:6.30-32.fc8 EVR. >>> >>> On such case are there any policy for release number? For perl currently >>> the main perl rpm and its subpackages have the same release number. >>> However in other rpms the case may happen that only the version of >>> main rpm will be bumped where the version of its subpackage won't change. >>> In that case usually we want to switch the release number of main rpm >>> to 1%{?dist}, however if its subpackage has different version the release >>> number of the subpackage usually can't be back to 1%{?dist}. How should >>> we treat this case? >> imo, the simplest solutions for cases like this are: >> 1. don't munge versions for subpkgs, ie, subpkg EVR = main pkg EVR >> 2. where different Versions are desired, make these a *completely >> separate* pkg, not just a sub-pkg. > ACK. The perl package should remain a special case and an exception. > > Ralf Okay, thanks, Rex and Ralf! Mamoru From wart at kobold.org Wed Jan 2 22:51:29 2008 From: wart at kobold.org (Michael Thomas) Date: Wed, 02 Jan 2008 14:51:29 -0800 Subject: [Fedora-packaging] Tcl packaging guidelines proposal In-Reply-To: <45E35ED3.6080708@kobold.org> References: <45D3A413.8040606@kobold.org> <20070226201354.0bd51344@python3.es.egwn.lan> <1172519832.10152.1.camel@peecee.hoentjen.eu> <45E35ED3.6080708@kobold.org> Message-ID: <477C1571.3030008@kobold.org> Michael Thomas wrote: > Sander Hoentjen wrote: >> On Mon, 2007-02-26 at 20:13 +0100, Matthias Saou wrote: >>> Michael Thomas wrote : >>> >>>> http://fedoraproject.org/wiki/PackagingDrafts/Tcl >>> Quick comment : You should add the "= %{version}-%{release}" to the >>> "Provides:" in your document. >>> >>> Otherwise, Tcl seems completely broken when it comes to multilib... [1] >>> and you seem to be aware of the major issues as the TODO section shows. >>> But it contains tasks so critical that I wouldn't bother trying to push >>> these packaging rules forward until they are taken care of. For >>> instance, replacing the "/usr/lib/tcl8.4 -> /usr/share/tcl8.4" >>> symlink with a real directory is... errr... pretty much impossible for >>> rpm to do. You might be able to hack around it, but it'll be ugly. >> >> I thought about it and it might be best if this was done during the move >> to 8.5. That way you don't really have to deal with it, the first 8.5 >> package just has to use the new way. > > Yes, the 8.5 upgrade might be the best time to make the change with the > link. The other two items above it in the list in the guidelines can > still be done pre-8.5, though, and would allow existing extensions to be > migrated to these new guidelines ahead of the 8.5 release. Now that Tcl 8.5 has been released and build (but not yet pushed, it seems) for Rawhide, I'd like to resurrect the Tcl packaging guidelines proposal. Is there anything more I can do in order to move forward on this? --Wart From timothy.selivanow at virtualxistenz.com Sat Jan 5 00:35:44 2008 From: timothy.selivanow at virtualxistenz.com (Timothy Selivanow) Date: Fri, 04 Jan 2008 16:35:44 -0800 Subject: [Fedora-packaging] Package for pysvn Message-ID: <1199493344.25346.53.camel@denkiteki-penpen.easystreet.com> I'm trying to make a package for pysvn [http://pysvn.tigris.org] and I have a few questions. Right now it's not compiling, rpmbuild is complaining about "error: line 27: Package does not exist: %description debuginfo", this must have changed either in F7 or F8 because this spec worked a long time ago (F6/F7, not sure which). Also, I discovered that the installer makes a differently named .so depending on the version of python that it is compiling against, and I'd like to know the best way to do an if style statement that will solve that (I'd like to be able to use the same spec on CentOS too). So, any help and comments would be much appreciated. Thanks! Below is the spec file. ---BEGIN SPEC--- %{!?python_sitearch: %define python_sitearch %(%{__python} -c "from distutils.sysconfig import get_python_lib; print get_python_lib(1)")} %{!?python_version: %define python_version %(%{__python} -c 'from sys import version_info; print str(version_info[0]) + "." + str(version_info[1])')} Name: pysvn Version: 1.5.2 Release: 1%{dist} Summary: Pythonic style bindings for Subversion Group: Development/Languages License: http://www.apache.org/LICENSE.txt URL: http://pysvn.tigris.org/ Source0: pysvn-%{version}.tar.gz BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) Requires: python > 2.3 BuildRequires: python-devel BuildRequires: PyXML BuildRequires: subversion-devel BuildRequires: libgssapi-devel BuildRequires: neon-devel BuildRequires: chrpath %description Pythonic style bindings for Subversion %description debuginfo debug info %prep %setup -q %build cd Source CFLAGS="$RPM_OPT_FLAGS" %{__python} setup.py configure make cd ../Tests make %install rm -rf $RPM_BUILD_ROOT mkdir -p $RPM_BUILD_ROOT%{python_sitearch}/pysvn cp Source/pysvn/__init__.py $RPM_BUILD_ROOT%{python_sitearch}/pysvn cp Source/pysvn/__init__.pyc $RPM_BUILD_ROOT%{python_sitearch}/pysvn #%if %(test [ "%{python_version}" == "2.5" ]) cp Source/pysvn/_pysvn_2_5.so $RPM_BUILD_ROOT%{python_sitearch}/pysvn chrpath --delete $RPM_BUILD_ROOT%{python_sitearch}/pysvn/_pysvn_2_5.so cd $RPM_BUILD_ROOT%{python_sitearch}/pysvn ln -s _pysvn_2_5.so _pysvn.so #%else #cp Source/pysvn/_pysvn.so $RPM_BUILD_ROOT%{python_sitearch}/pysvn #chrpath --delete $RPM_BUILD_ROOT%{python_sitearch}/pysvn/_pysvn.so #%endif %clean rm -rf $RPM_BUILD_ROOT %files %defattr(-,root,root,-) %doc Docs/pysvn.html Docs/pysvn_prog_guide.html Docs/pysvn_prog_ref.html Docs/pysvn_prog_ref.js %{python_sitearch}/pysvn %changelog * Fri Jan 04 2008 Timothy Selivanow - 1.5.2-2 - Attempting to make the spec work with different versions of Python * Mon Sep 03 2007 Timothy Selivanow - 1.5.2-1 - Update to 1.5.2 - Some spec clean up * Fri Jan 12 2007 Timothy Selivanow - 1.5.0-1 - Initial spec creation ---END SPEC--- --Tim ____________________________________________________________________________ / If you will practice being fictional for a while, you will understand that \ | fictional characters are sometimes more real than people with bodies and | \ heartbeats. / ---------------------------------------------------------------------------- \ \ \ \ /\ ( ) .( o ). From ivazqueznet at gmail.com Sat Jan 5 04:27:04 2008 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Fri, 04 Jan 2008 23:27:04 -0500 Subject: [Fedora-packaging] Package for pysvn In-Reply-To: <1199493344.25346.53.camel@denkiteki-penpen.easystreet.com> References: <1199493344.25346.53.camel@denkiteki-penpen.easystreet.com> Message-ID: <1199507224.3463.15.camel@ignacio.lan> On Fri, 2008-01-04 at 16:35 -0800, Timothy Selivanow wrote: > I'm trying to make a package for pysvn [http://pysvn.tigris.org] and I > have a few questions. Right now it's not compiling, rpmbuild is > complaining about "error: line 27: Package does not exist: %description > debuginfo", this must have changed either in F7 or F8 because this spec > worked a long time ago (F6/F7, not sure which). I've never seen a package that tries to set the description of its debuginfo subpackage. I don't know what's changed to make it not work, but it isn't necessary. Feel free to remove. > Also, I discovered that the installer makes a differently named .so > depending on the version of python that it is compiling against, and I'd > like to know the best way to do an if style statement that will solve > that (I'd like to be able to use the same spec on CentOS too). *headdesk* ... Hrm. That's fairly obnoxious. I would say just patch out the parts of the code that do this (result in a different filename). There's certainly no need for it after install. -- Ignacio Vazquez-Abrams PLEASE don't CC me; I'm already subscribed -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jnovy at redhat.com Sat Jan 5 08:54:30 2008 From: jnovy at redhat.com (Jindrich Novy) Date: Sat, 5 Jan 2008 09:54:30 +0100 Subject: [Fedora-packaging] release of subpackage with version different from main rpm In-Reply-To: <477BA8FC.7080103@math.unl.edu> References: <477BA79E.8020902@ioa.s.u-tokyo.ac.jp> <477BA8FC.7080103@math.unl.edu> Message-ID: <20080105085430.GA2855@dhcp-lab-186.brq.redhat.com> On Wed, Jan 02, 2008 at 09:08:44AM -0600, Rex Dieter wrote: > Mamoru Tasaka wrote: > > > I guess there are some packages of which subpackage rpms have versions > > which are different from those of the main rpm. > > For example, on rawhide perl has 4:5.8.8-32.fc8 EVR and its subpackage > > perl-ExtUtils-MakeMaker has 0:6.30-32.fc8 EVR. > > > > On such case are there any policy for release number? For perl currently > > the main perl rpm and its subpackages have the same release number. > > However in other rpms the case may happen that only the version of > > main rpm will be bumped where the version of its subpackage won't change. > > In that case usually we want to switch the release number of main rpm > > to 1%{?dist}, however if its subpackage has different version the release > > number of the subpackage usually can't be back to 1%{?dist}. How should > > we treat this case? > > imo, the simplest solutions for cases like this are: > 1. don't munge versions for subpkgs, ie, subpkg EVR = main pkg EVR > 2. where different Versions are desired, make these a *completely > separate* pkg, not just a sub-pkg. None of these approaches are possible in some cases, say TeXLive. The distribution consists of many independent parts, but as a distribution it has one huge tarball. Following your suggestion would lead to have a couple of separate packages containing full tarball from which only a particular part which is packaged is ripped off, which is quite wasteful IMO. In case of one package and many subpackages, the "subpkg EVR = main pkg EVR" is also not possible, because each bit has a different version, because they are developed independently. Why to strictly avoid subpackages with a different NEVR than the main one? I can imagine many of situations where it makes perfectly sense, the one I described is one of these. Jindrich -- Jindrich Novy http://people.redhat.com/jnovy/ From mtasaka at ioa.s.u-tokyo.ac.jp Sat Jan 5 10:59:40 2008 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Sat, 05 Jan 2008 19:59:40 +0900 Subject: [Fedora-packaging] release of subpackage with version different from main rpm In-Reply-To: <20080105085430.GA2855@dhcp-lab-186.brq.redhat.com> References: <477BA79E.8020902@ioa.s.u-tokyo.ac.jp> <477BA8FC.7080103@math.unl.edu> <20080105085430.GA2855@dhcp-lab-186.brq.redhat.com> Message-ID: <477F631C.3000304@ioa.s.u-tokyo.ac.jp> Jindrich Novy wrote, at 01/05/2008 05:54 PM +9:00: > On Wed, Jan 02, 2008 at 09:08:44AM -0600, Rex Dieter wrote: >> Mamoru Tasaka wrote: >> >>> I guess there are some packages of which subpackage rpms have versions >>> which are different from those of the main rpm. >>> For example, on rawhide perl has 4:5.8.8-32.fc8 EVR and its subpackage >>> perl-ExtUtils-MakeMaker has 0:6.30-32.fc8 EVR. >>> >>> On such case are there any policy for release number? For perl currently >>> the main perl rpm and its subpackages have the same release number. >>> However in other rpms the case may happen that only the version of >>> main rpm will be bumped where the version of its subpackage won't change. >>> In that case usually we want to switch the release number of main rpm >>> to 1%{?dist}, however if its subpackage has different version the release >>> number of the subpackage usually can't be back to 1%{?dist}. How should >>> we treat this case? >> imo, the simplest solutions for cases like this are: >> 1. don't munge versions for subpkgs, ie, subpkg EVR = main pkg EVR >> 2. where different Versions are desired, make these a *completely >> separate* pkg, not just a sub-pkg. > > None of these approaches are possible in some cases, say TeXLive. The > distribution consists of many independent parts, but as a distribution it has > one huge tarball. Following your suggestion would lead to have a couple of > separate packages containing full tarball from which only a particular > part which is packaged is ripped off, which is quite wasteful IMO. > > In case of one package and many subpackages, the "subpkg EVR = main pkg EVR" is > also not possible, because each bit has a different version, because > they are developed independently. Well, it can be that one (huge) tarball has several sub-components which are developed independency and they has different versions _internally_ however they are released in one tarball anyway? Generally if one component of the tarball is updated (for example xdvi is updated from 22.84.12 to 22.84.13), then upstream should also bump the version of the tarball because even if only one component of the (huge) tarball is changed it means from external it means that the tarball is changed anyway (i.e. texlive must have version "2007.1", for example). If upstream releases new version of the tarball without changing the version but with changing one of the components, it is very confusing and in the case "we" (rpm packager) should change version intentionally (like ImageMagick). IMO "version" of rpm should respect from what "tarball" the rpm is generated. For xdvi if providing "22.84.12" is preferable, it must be treated by vertial provides, i.e. the name of rpm should be "texlive-xdvi" with version "2007", with providing "xdvi = 22.84.12". Mamoru From pertusus at free.fr Sat Jan 5 12:00:35 2008 From: pertusus at free.fr (Patrice Dumas) Date: Sat, 5 Jan 2008 13:00:35 +0100 Subject: [Fedora-packaging] release of subpackage with version different from main rpm In-Reply-To: <477F631C.3000304@ioa.s.u-tokyo.ac.jp> References: <477BA79E.8020902@ioa.s.u-tokyo.ac.jp> <477BA8FC.7080103@math.unl.edu> <20080105085430.GA2855@dhcp-lab-186.brq.redhat.com> <477F631C.3000304@ioa.s.u-tokyo.ac.jp> Message-ID: <20080105120035.GI2570@free.fr> On Sat, Jan 05, 2008 at 07:59:40PM +0900, Mamoru Tasaka wrote: > Jindrich Novy wrote, at 01/05/2008 05:54 PM +9:00: > > Well, it can be that one (huge) tarball has several sub-components which > are developed independency and they has different versions _internally_ > however they are released in one tarball anyway? Internally or not internally is not a simple matter. In the case of texlive, for example, the softwares come from CTAN, in general or are in teexlive svn taken from somewhere else. However it may happen that texlive has become something like the new upstream... though intermediate release may still happen out of texlive. > Generally if one component of the tarball is updated (for example > xdvi is updated from 22.84.12 to 22.84.13), then upstream should also bump the > version of the tarball because even if only one component of the (huge) > tarball is changed it means from external it means that the tarball is changed > anyway (i.e. texlive must have version "2007.1", for example). > If upstream releases new version of the tarball without changing the version > but with changing one of the components, it is very confusing and in the case > "we" (rpm packager) should change version intentionally (like ImageMagick). This is not an issue with texlive, there is only one release a year with change in version. > IMO "version" of rpm should respect from what "tarball" the rpm is generated. > For xdvi if providing "22.84.12" is preferable, it must be treated by > vertial provides, i.e. the name of rpm should be "texlive-xdvi" with version > "2007", with providing "xdvi = 22.84.12". That's another option, but if we split it in the future we'll have to add obsoletes and provides, this is avoided in the current situation. It should be noted that for texlive some subpackages should be packaged completly separately, but they were already in tetex, so I allowed Jindrich to ship them with texlive. Still some are better taken from texlive though they have their own veresioning. -- Pat From Axel.Thimm at ATrpms.net Sat Jan 5 13:01:38 2008 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 5 Jan 2008 15:01:38 +0200 Subject: [Fedora-packaging] Re: release of subpackage with version different from main rpm In-Reply-To: <20080105085430.GA2855@dhcp-lab-186.brq.redhat.com> References: <477BA79E.8020902@ioa.s.u-tokyo.ac.jp> <477BA8FC.7080103@math.unl.edu> <20080105085430.GA2855@dhcp-lab-186.brq.redhat.com> Message-ID: <20080105130138.GA6244@puariko.nirvana> On Sat, Jan 05, 2008 at 09:54:30AM +0100, Jindrich Novy wrote: > On Wed, Jan 02, 2008 at 09:08:44AM -0600, Rex Dieter wrote: > > Mamoru Tasaka wrote: > > > > > I guess there are some packages of which subpackage rpms have versions > > > which are different from those of the main rpm. > > > For example, on rawhide perl has 4:5.8.8-32.fc8 EVR and its subpackage > > > perl-ExtUtils-MakeMaker has 0:6.30-32.fc8 EVR. > > > > > > On such case are there any policy for release number? For perl currently > > > the main perl rpm and its subpackages have the same release number. > > > However in other rpms the case may happen that only the version of > > > main rpm will be bumped where the version of its subpackage won't change. > > > In that case usually we want to switch the release number of main rpm > > > to 1%{?dist}, however if its subpackage has different version the release > > > number of the subpackage usually can't be back to 1%{?dist}. How should > > > we treat this case? > > > > imo, the simplest solutions for cases like this are: > > 1. don't munge versions for subpkgs, ie, subpkg EVR = main pkg EVR > > 2. where different Versions are desired, make these a *completely > > separate* pkg, not just a sub-pkg. > > None of these approaches are possible in some cases, say TeXLive. The > distribution consists of many independent parts, but as a distribution it has > one huge tarball. Following your suggestion would lead to have a couple of > separate packages containing full tarball from which only a particular > part which is packaged is ripped off, which is quite wasteful IMO. > > In case of one package and many subpackages, the "subpkg EVR = main pkg EVR" is > also not possible, because each bit has a different version, because > they are developed independently. > > Why to strictly avoid subpackages with a different NEVR than the main one? I can > imagine many of situations where it makes perfectly sense, the one I > described is one of these. texlive is a special case, there are not that many in-between-upstreams that do a collection of other projects. In general it is desirable to have one-tarball-one-specfile-one- version setups. For texlive it would have meant to split up texlive into its components and retarball them (or persuade upstream to do so). Since using texlive means relying on an in between upstream to do the intergration work the above is nonsense, of course, so keep on the subpackaging versioning as you do. But other than texlive or maybe even the kernel (with many subsystems having their own version) I don't think this applies to many other examples, so we can special-case texlive and have otherwise a general rule of thumb that "using different evr in subpackages is an indication of something wrong". Just as an example about the wrong setup: Look at how often rpm/popt packages broke in their upgrade path in the past for having two versions in a tarball - thank god we have finally two sources for them. -- 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 rdieter at math.unl.edu Sat Jan 5 13:17:30 2008 From: rdieter at math.unl.edu (Rex Dieter) Date: Sat, 05 Jan 2008 07:17:30 -0600 Subject: [Fedora-packaging] release of subpackage with version different from main rpm In-Reply-To: <477F631C.3000304@ioa.s.u-tokyo.ac.jp> References: <477BA79E.8020902@ioa.s.u-tokyo.ac.jp> <477BA8FC.7080103@math.unl.edu> <20080105085430.GA2855@dhcp-lab-186.brq.redhat.com> <477F631C.3000304@ioa.s.u-tokyo.ac.jp> Message-ID: <477F836A.3000502@math.unl.edu> Mamoru Tasaka wrote: > Well, it can be that one (huge) tarball has several sub-components which > are developed independency and they has different versions _internally_ > however they are released in one tarball anyway? *cough* kde *cough*. :) -- Rex From mtasaka at ioa.s.u-tokyo.ac.jp Sat Jan 5 13:22:26 2008 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Sat, 05 Jan 2008 22:22:26 +0900 Subject: [Fedora-packaging] release of subpackage with version different from main rpm In-Reply-To: <477F836A.3000502@math.unl.edu> References: <477BA79E.8020902@ioa.s.u-tokyo.ac.jp> <477BA8FC.7080103@math.unl.edu> <20080105085430.GA2855@dhcp-lab-186.brq.redhat.com> <477F631C.3000304@ioa.s.u-tokyo.ac.jp> <477F836A.3000502@math.unl.edu> Message-ID: <477F8492.2060400@ioa.s.u-tokyo.ac.jp> Rex Dieter wrote, at 01/05/2008 10:17 PM +9:00: > Mamoru Tasaka wrote: > >> Well, it can be that one (huge) tarball has several sub-components which >> are developed independency and they has different versions _internally_ >> however they are released in one tarball anyway? > > *cough* kde *cough*. :) > > -- Rex I must say that kde packaging is very confusing... Mamoru From tcallawa at redhat.com Sat Jan 5 14:11:36 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Sat, 05 Jan 2008 09:11:36 -0500 Subject: [Fedora-packaging] release of subpackage with version different from main rpm In-Reply-To: <477F631C.3000304@ioa.s.u-tokyo.ac.jp> References: <477BA79E.8020902@ioa.s.u-tokyo.ac.jp> <477BA8FC.7080103@math.unl.edu> <20080105085430.GA2855@dhcp-lab-186.brq.redhat.com> <477F631C.3000304@ioa.s.u-tokyo.ac.jp> Message-ID: <477F9018.9010702@redhat.com> On 01/05/2008 Mamoru Tasaka wrote: > Well, it can be that one (huge) tarball has several sub-components > which are developed independency and they has different versions > _internally_ however they are released in one tarball anyway? Perl does this too. :/ ~spot From tibbs at math.uh.edu Sat Jan 5 16:56:53 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 05 Jan 2008 10:56:53 -0600 Subject: [Fedora-packaging] release of subpackage with version different from main rpm In-Reply-To: <477F9018.9010702@redhat.com> References: <477BA79E.8020902@ioa.s.u-tokyo.ac.jp> <477BA8FC.7080103@math.unl.edu> <20080105085430.GA2855@dhcp-lab-186.brq.redhat.com> <477F631C.3000304@ioa.s.u-tokyo.ac.jp> <477F9018.9010702@redhat.com> Message-ID: >>>>> "TC" == Tom \"spot\" Callaway writes: TC> Perl does this too. :/ And it causes pain, as we all know. The problem is that we're a distribution, packaging up another distribution. I guess we could bypass texlive altogether and just pull in all of the various upstreams ourselves, but of course that would require a hideous amount of maintainer time. If there's a component (of texlive, Perl, or whatever distro we're repackaging) which we frequently feel like we need to update out of sync with the distro that packages it, we shouldn't hesitate to package it separately. - J< From tibbs at math.uh.edu Sat Jan 5 17:15:25 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 05 Jan 2008 11:15:25 -0600 Subject: [Fedora-packaging] Services enabled by default when installed Message-ID: I've always understood that services should not be enabled by default, because people tend to install more than they actually want to run. And of course rpmlint complains about any initscript that starts on by default. However, I don't actually see any mention of this in the guidelines, only this text in ScriptletSnippets: " Why don't we.... * run 'chkconfig on'? o If a service should be enabled by default, make this the default in the init script. Doing otherwise will cause the service to be turned on on upgrades if the user explicitly disabled it. Note that the default for most network-listening scripts is off. This is done for better security. We have multiple tools that can enable services, including GUIs. * start the service after installation? o Installations can be in changeroots, in an installer context, or in other situations where you don't want the services started. " So, is it OK if a packager wants their service enabled by default? - J< From Axel.Thimm at ATrpms.net Sat Jan 5 19:47:49 2008 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 5 Jan 2008 21:47:49 +0200 Subject: [Fedora-packaging] Re: Services enabled by default when installed In-Reply-To: References: Message-ID: <20080105194749.GA9464@puariko.nirvana> On Sat, Jan 05, 2008 at 11:15:25AM -0600, Jason L Tibbitts III wrote: > I've always understood that services should not be enabled by default, > because people tend to install more than they actually want to run. > And of course rpmlint complains about any initscript that starts on by > default. > > However, I don't actually see any mention of this in the guidelines, > only this text in ScriptletSnippets: > > " > Why don't we.... > > * run 'chkconfig on'? > o If a service should be enabled by default, make this the > default in the init script. Doing otherwise will cause the > service to be turned on on upgrades if the user explicitly > disabled it. Note that the default for most > network-listening scripts is off. This is done for better > security. We have multiple tools that can enable services, > including GUIs. > * start the service after installation? > o Installations can be in changeroots, in an installer > context, or in other situations where you don't want the > services started. > " > > So, is it OK if a packager wants their service enabled by default? It probably very much depends on the service in question and the guidelines can't cover all possible situations, but I can think of quite a few cases where you'd like it enabled by default like messagebus, firstboot, crond, etc. -- 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 tibbs at math.uh.edu Sat Jan 5 20:29:32 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 05 Jan 2008 14:29:32 -0600 Subject: [Fedora-packaging] Re: Services enabled by default when installed In-Reply-To: <20080105194749.GA9464@puariko.nirvana> References: <20080105194749.GA9464@puariko.nirvana> Message-ID: >>>>> "AT" == Axel Thimm writes: AT> It probably very much depends on the service in question and the AT> guidelines can't cover all possible situations, but I can think of AT> quite a few cases where you'd like it enabled by default like AT> messagebus, firstboot, crond, etc. The package in question is kerneloops, a service which watches your logs for oops output and notifies a userspace applet via dbus: https://bugzilla.redhat.com/show_bug.cgi?id=427586 I guess a big issue for me would be whether the service is network-facing, since that means that installing and rebooting gives you a service that you never enabled. - J< From tcallawa at redhat.com Sun Jan 6 00:30:46 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Sat, 05 Jan 2008 19:30:46 -0500 Subject: [Fedora-packaging] release of subpackage with version different from main rpm In-Reply-To: References: <477BA79E.8020902@ioa.s.u-tokyo.ac.jp> <477BA8FC.7080103@math.unl.edu> <20080105085430.GA2855@dhcp-lab-186.brq.redhat.com> <477F631C.3000304@ioa.s.u-tokyo.ac.jp> <477F9018.9010702@redhat.com> Message-ID: <47802136.1030108@redhat.com> On 01/05/2008 Jason L Tibbitts III wrote: > If there's a component (of texlive, Perl, or whatever distro we're > repackaging) which we frequently feel like we need to update out of > sync with the distro that packages it, we shouldn't hesitate to > package it separately. Well, yes and no. This is a place where I've got to assume that upstream has a good reason for bundling these components together in the same tarball. If one of those bundled components frequently needs updates, we should be having dialogs with upstream about: A. Whether that component needs to be bundled in B. Whether the supertarball needs to be updated more often C. What the effect of Fedora updating the component will be on the supportability of the whole, from an upstream perspective With that data, when needed and with upstream support, we shouldn't shy away from packaging it separately. ~spot From Axel.Thimm at ATrpms.net Sun Jan 6 13:36:13 2008 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 6 Jan 2008 15:36:13 +0200 Subject: [Fedora-packaging] Re: release of subpackage with version different from main rpm In-Reply-To: <47802136.1030108@redhat.com> References: <477BA79E.8020902@ioa.s.u-tokyo.ac.jp> <477BA8FC.7080103@math.unl.edu> <20080105085430.GA2855@dhcp-lab-186.brq.redhat.com> <477F631C.3000304@ioa.s.u-tokyo.ac.jp> <477F9018.9010702@redhat.com> <47802136.1030108@redhat.com> Message-ID: <20080106133613.GB11663@puariko.nirvana> On Sat, Jan 05, 2008 at 07:30:46PM -0500, Tom spot Callaway wrote: > On 01/05/2008 Jason L Tibbitts III wrote: > > If there's a component (of texlive, Perl, or whatever distro we're > > repackaging) which we frequently feel like we need to update out of > > sync with the distro that packages it, we shouldn't hesitate to > > package it separately. > > Well, yes and no. This is a place where I've got to assume that upstream > has a good reason for bundling these components together in the same > tarball. If one of those bundled components frequently needs updates, we > should be having dialogs with upstream about: > > A. Whether that component needs to be bundled in > B. Whether the supertarball needs to be updated more often > C. What the effect of Fedora updating the component will be on the > supportability of the whole, from an upstream perspective > > With that data, when needed and with upstream support, we shouldn't shy > away from packaging it separately. I guess the question is whether to keep it technically possible to perform such updates. If you have a supertarball and use for all subpackages a common evr, even one that doesn't match the real upstream's subpackages' versioning, then for updating one subpackage you need to update them all, or you would have to package an external package or upstream foo using a false version, e.g. adapting a version scheme like the superpackage's. And you would run into evr races with the supertarball. So it boils down to either total commitment to the intermediate upstream's updating and versioning or keeping separate versioning matching the true upstream thus allowing to deviate from the intermediate upstream. All in all it's about the future freedom of choice. And given that tex distributions even very stable and solid ones like tetex can decide to disappear into thin air from one day to another, I wouldn't bind ourselves to versioning and naming of intermediate upstreams. E.g. I wouldn't even use texlive/tetex prefixes to subpackages and dependencies. After all a package requiring some version of LaTeX or dvips doesn't require that it comes from tetex, TeXlive etc., so the dependency should be kept subvendor-free. IOT the tetex/texlive prefixing is separate from perl/python/... prefixing as tetex/texlive is a vendor string, not the real universe which would probably be simply "tex". (The current packages go into the right direction wrt above, e.g.: texlive-2007-7 texlive-afm-2007-7 texlive-dvips-2007-7 texlive-dviutils-2007-7 texlive-latex-2007-7 kpathsea-2007-7 kpathsea-devel-2007-7 xdvi-22.84.12-7 dvipng-1.9-7 mendexk-2.6e-7 dvipdfm-0.13.2d-7 dvipdfmx-0-7 Ideally latex, dvips etc will also land into their "own" subpackage) -- 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 pertusus at free.fr Sun Jan 6 14:02:51 2008 From: pertusus at free.fr (Patrice Dumas) Date: Sun, 6 Jan 2008 15:02:51 +0100 Subject: [Fedora-packaging] Re: release of subpackage with version different from main rpm In-Reply-To: <20080106133613.GB11663@puariko.nirvana> References: <477BA79E.8020902@ioa.s.u-tokyo.ac.jp> <477BA8FC.7080103@math.unl.edu> <20080105085430.GA2855@dhcp-lab-186.brq.redhat.com> <477F631C.3000304@ioa.s.u-tokyo.ac.jp> <477F9018.9010702@redhat.com> <47802136.1030108@redhat.com> <20080106133613.GB11663@puariko.nirvana> Message-ID: <20080106140251.GA2522@free.fr> On Sun, Jan 06, 2008 at 03:36:13PM +0200, Axel Thimm wrote: > On Sat, Jan 05, 2008 at 07:30:46PM -0500, Tom spot Callaway wrote: > > And given that tex distributions even very stable and solid ones like > tetex can decide to disappear into thin air from one day to another, I > wouldn't bind ourselves to versioning and naming of intermediate > upstreams. E.g. I wouldn't even use texlive/tetex prefixes to > subpackages and dependencies. After all a package requiring some > version of LaTeX or dvips doesn't require that it comes from tetex, > TeXlive etc., so the dependency should be kept subvendor-free. There is a plan to have virtual provides for tex/latex, discussion is at https://bugzilla.redhat.com/show_bug.cgi?id=410401 > (The current packages go into the right direction wrt above, e.g.: > texlive-2007-7 > texlive-afm-2007-7 > texlive-dvips-2007-7 > texlive-dviutils-2007-7 > texlive-latex-2007-7 > kpathsea-2007-7 > kpathsea-devel-2007-7 > xdvi-22.84.12-7 > dvipng-1.9-7 > mendexk-2.6e-7 > dvipdfm-0.13.2d-7 > dvipdfmx-0-7 > Ideally latex, dvips etc will also land into their "own" subpackage) I don't think so. The package name should be what upstream is. It's up to the virtual provides to provide vendor independance. -- Pat From Axel.Thimm at ATrpms.net Sun Jan 6 19:44:38 2008 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 6 Jan 2008 21:44:38 +0200 Subject: [Fedora-packaging] Re: release of subpackage with version different from main rpm In-Reply-To: <20080106140251.GA2522@free.fr> References: <477BA79E.8020902@ioa.s.u-tokyo.ac.jp> <477BA8FC.7080103@math.unl.edu> <20080105085430.GA2855@dhcp-lab-186.brq.redhat.com> <477F631C.3000304@ioa.s.u-tokyo.ac.jp> <477F9018.9010702@redhat.com> <47802136.1030108@redhat.com> <20080106133613.GB11663@puariko.nirvana> <20080106140251.GA2522@free.fr> Message-ID: <20080106194438.GD15106@puariko.nirvana> On Sun, Jan 06, 2008 at 03:02:51PM +0100, Patrice Dumas wrote: > > (The current packages go into the right direction wrt above, e.g.: > > texlive-2007-7 > > texlive-afm-2007-7 > > texlive-dvips-2007-7 > > texlive-dviutils-2007-7 > > texlive-latex-2007-7 > > kpathsea-2007-7 > > kpathsea-devel-2007-7 > > xdvi-22.84.12-7 > > dvipng-1.9-7 > > mendexk-2.6e-7 > > dvipdfm-0.13.2d-7 > > dvipdfmx-0-7 > > Ideally latex, dvips etc will also land into their "own" subpackage) > > I don't think so. The package name should be what upstream is. Upstream versions latex with version "2005/12/01" (one could argue whether fixltx2e makes that "2006/03/24" instead). This is quite distinct from texlive-latex-2007. Or seen from a different perspective: If naming/versioning latex as texlive-latex-2007 is fine, why isn't texlive-xdvi-2007 fine as well? > It's up to the virtual provides to provide vendor independance. Of course, if you a) have these virtual provides b) make this public enough that packagers use them instead of the package names (and really how many packagers check to see whether some dependent on package provides some virtual entities that they should pull in instead, and more importantly how certain can this packager be that this virtual Provides: will be around long enough and not have his package broken by the next texlive package update?). c) rpm, yum and friends deal better with virtual provides vs real entities than they do now. Thankfully the aged bug on packages auto-obsoleting when providing a virtual dependency has been recently fixed, but not yet in the rpms we use (I think so at least, perhaps F8 has the fix), and more importantly it created confusion and aversion to using virtual provides for upgrade paths and that's what this is about. Instead it would be better to have the real package names prompty display to other packagers what they should require and keep compatibility provides internally. -- 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 pertusus at free.fr Sun Jan 6 22:22:18 2008 From: pertusus at free.fr (Patrice Dumas) Date: Sun, 6 Jan 2008 23:22:18 +0100 Subject: [Fedora-packaging] Re: release of subpackage with version different from main rpm In-Reply-To: <20080106194438.GD15106@puariko.nirvana> References: <477BA79E.8020902@ioa.s.u-tokyo.ac.jp> <477BA8FC.7080103@math.unl.edu> <20080105085430.GA2855@dhcp-lab-186.brq.redhat.com> <477F631C.3000304@ioa.s.u-tokyo.ac.jp> <477F9018.9010702@redhat.com> <47802136.1030108@redhat.com> <20080106133613.GB11663@puariko.nirvana> <20080106140251.GA2522@free.fr> <20080106194438.GD15106@puariko.nirvana> Message-ID: <20080106222218.GB2554@free.fr> On Sun, Jan 06, 2008 at 09:44:38PM +0200, Axel Thimm wrote: > > Upstream versions latex with version "2005/12/01" (one could argue > whether fixltx2e makes that "2006/03/24" instead). That could be a good idea for numbering the virtual provides in my opinion. > This is quite distinct from texlive-latex-2007. Or seen from a > different perspective: If naming/versioning latex as > texlive-latex-2007 is fine, why isn't texlive-xdvi-2007 fine as well? Because xdvi is really a distinct package with its own upstream. It has just been submitted anyway, so this issue won't be there for long. > > It's up to the virtual provides to provide vendor independance. > > Of course, if you > > a) have these virtual provides > b) make this public enough that packagers use them instead of the > package names (and really how many packagers check to see whether > some dependent on package provides some virtual entities that they > should pull in instead, and more importantly how certain can this > packager be that this virtual Provides: will be around long enough > and not have his package broken by the next texlive package > update?). We will make sure that only the virtual provides are used. Hopefully it will become a guideline. Just like the python and emacs virtual provides. > c) rpm, yum and friends deal better with virtual provides vs real > entities than they do now. Thankfully the aged bug on packages > auto-obsoleting when providing a virtual dependency has been > recently fixed, but not yet in the rpms we use (I think so at > least, perhaps F8 has the fix), and more importantly it created > confusion and aversion to using virtual provides for upgrade paths > and that's what this is about. It has to work rergardless of texlive/tex. It is a requirement for alternate provides. > Instead it would be better to have the real package names prompty > display to other packagers what they should require and keep > compatibility provides internally. Why internally? They are here exactly for independence with regard with tex distribution vendor, so must be virtual. (It is certainly not for soon, but we could even imagine packaging 2 tex distros in parallel in fedora). Having a) and b) is the plan, as for c) it has to be fixed anyway. In th emean time, the tetex-* provides can be kept (and will have to for a long period of time in EPEL anyway). -- Pat From ekalin at gmail.com Mon Jan 7 12:40:05 2008 From: ekalin at gmail.com (Eduardo M KALINOWSKI) Date: Mon, 7 Jan 2008 10:40:05 -0200 Subject: [Fedora-packaging] Automatic detection of Requires and versions Message-ID: <9cea66a70801070440t602093d9j845e6d81938773bd@mail.gmail.com> Hi, I'm attempting to package a program I wrote, that uses the GTK+ libraries. It uses features first found in the 2.10.X series, so I include BuildRequires: gtk2-devel >= 2.10.0 (and similar lines for glib and other required libraries). All this is OK. The problem is regarding the Requires for the generated .rpm. I could use Requires: gtk2 >= 2.10.0 but apparently this is bad style and bad for maintenance, because dependencies are found automatically on build time. However, without manually adding the requires, the generated .rpm contains (with regard to GTK+) this: libgtk-x11-2.0.so.0 that is, no mention of the version, and I expect that even a GTK+ 2.8 package (old as that may be) should provide that file with that name. What is the best way to handle that? Include the Require manually? Leave this as-is? Thanks in advance, From rdieter at math.unl.edu Mon Jan 7 13:20:41 2008 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 07 Jan 2008 07:20:41 -0600 Subject: [Fedora-packaging] Automatic detection of Requires and versions In-Reply-To: <9cea66a70801070440t602093d9j845e6d81938773bd@mail.gmail.com> References: <9cea66a70801070440t602093d9j845e6d81938773bd@mail.gmail.com> Message-ID: <47822729.5070102@math.unl.edu> Eduardo M KALINOWSKI wrote: > I'm attempting to package a program I wrote, that uses the GTK+ > libraries. It uses features first found in the 2.10.X series, so I > include > > BuildRequires: gtk2-devel >= 2.10.0 > > (and similar lines for glib and other required libraries). All this is > OK. The problem is regarding the Requires for the generated .rpm. I > could use > > Requires: gtk2 >= 2.10.0 > > but apparently this is bad style and bad for maintenance, because > dependencies are found automatically on build time. However, without > manually adding the requires, the generated .rpm contains (with regard > to GTK+) this: > > libgtk-x11-2.0.so.0 > > that is, no mention of the version, and I expect that even a GTK+ 2.8 > package (old as that may be) should provide that file with that name. > > What is the best way to handle that? Include the Require manually? > Leave this as-is? Leave as is (imo). -- Rex From pertusus at free.fr Mon Jan 7 15:15:39 2008 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 7 Jan 2008 16:15:39 +0100 Subject: [Fedora-packaging] Automatic detection of Requires and versions In-Reply-To: <9cea66a70801070440t602093d9j845e6d81938773bd@mail.gmail.com> References: <9cea66a70801070440t602093d9j845e6d81938773bd@mail.gmail.com> Message-ID: <20080107151539.GJ2614@free.fr> On Mon, Jan 07, 2008 at 10:40:05AM -0200, Eduardo M KALINOWSKI wrote: > Hi, > > I'm attempting to package a program I wrote, that uses the GTK+ > libraries. It uses features first found in the 2.10.X series, so I > include > > BuildRequires: gtk2-devel >= 2.10.0 > > (and similar lines for glib and other required libraries). All this is > OK. The problem is regarding the Requires for the generated .rpm. I > could use > > Requires: gtk2 >= 2.10.0 > > but apparently this is bad style and bad for maintenance, because > dependencies are found automatically on build time. However, without > manually adding the requires, the generated .rpm contains (with regard > to GTK+) this: > > libgtk-x11-2.0.so.0 > > that is, no mention of the version, and I expect that even a GTK+ 2.8 > package (old as that may be) should provide that file with that name. > > What is the best way to handle that? Include the Require manually? > Leave this as-is? I'd say the reverse than Rex, include the Require manually. But I may well be wrong. -- Pat From rc040203 at freenet.de Mon Jan 7 15:20:54 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 07 Jan 2008 16:20:54 +0100 Subject: [Fedora-packaging] Automatic detection of Requires and versions In-Reply-To: <20080107151539.GJ2614@free.fr> References: <9cea66a70801070440t602093d9j845e6d81938773bd@mail.gmail.com> <20080107151539.GJ2614@free.fr> Message-ID: <1199719254.6022.125.camel@beck.corsepiu.local> On Mon, 2008-01-07 at 16:15 +0100, Patrice Dumas wrote: > On Mon, Jan 07, 2008 at 10:40:05AM -0200, Eduardo M KALINOWSKI wrote: > > Hi, > > > > I'm attempting to package a program I wrote, that uses the GTK+ > > libraries. It uses features first found in the 2.10.X series, so I > > include > > > > BuildRequires: gtk2-devel >= 2.10.0 > > > > (and similar lines for glib and other required libraries). All this is > > OK. The problem is regarding the Requires for the generated .rpm. I > > could use > > > > Requires: gtk2 >= 2.10.0 > > > > but apparently this is bad style and bad for maintenance, because > > dependencies are found automatically on build time. However, without > > manually adding the requires, the generated .rpm contains (with regard > > to GTK+) this: > > > > libgtk-x11-2.0.so.0 > > > > that is, no mention of the version, and I expect that even a GTK+ 2.8 > > package (old as that may be) should provide that file with that name. > > > > What is the best way to handle that? Include the Require manually? > > Leave this as-is? > > I'd say the reverse than Rex, include the Require manually. But I may > well be wrong. Well, you are. If an upstream has its package properly designed (Esp. uses SONAMEs properly), then there should not be any need to let a run-time/application-package explicitly require a package by name. Ralf From pertusus at free.fr Mon Jan 7 15:43:22 2008 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 7 Jan 2008 16:43:22 +0100 Subject: [Fedora-packaging] Automatic detection of Requires and versions In-Reply-To: <1199719254.6022.125.camel@beck.corsepiu.local> References: <9cea66a70801070440t602093d9j845e6d81938773bd@mail.gmail.com> <20080107151539.GJ2614@free.fr> <1199719254.6022.125.camel@beck.corsepiu.local> Message-ID: <20080107154322.GK2614@free.fr> On Mon, Jan 07, 2008 at 04:20:54PM +0100, Ralf Corsepius wrote: > > On Mon, 2008-01-07 at 16:15 +0100, Patrice Dumas wrote: > > > > I'd say the reverse than Rex, include the Require manually. But I may > > well be wrong. > > Well, you are. If an upstream has its package properly designed (Esp. > uses SONAMEs properly), then there should not be any need to let a > run-time/application-package explicitly require a package by name. Unless I am wrong, the sonames of 2.8 nad 2.10 are the same, but above 2.10 is needed. -- Pat From rc040203 at freenet.de Mon Jan 7 16:38:52 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 07 Jan 2008 17:38:52 +0100 Subject: [Fedora-packaging] Automatic detection of Requires and versions In-Reply-To: <20080107154322.GK2614@free.fr> References: <9cea66a70801070440t602093d9j845e6d81938773bd@mail.gmail.com> <20080107151539.GJ2614@free.fr> <1199719254.6022.125.camel@beck.corsepiu.local> <20080107154322.GK2614@free.fr> Message-ID: <1199723932.6022.134.camel@beck.corsepiu.local> On Mon, 2008-01-07 at 16:43 +0100, Patrice Dumas wrote: > On Mon, Jan 07, 2008 at 04:20:54PM +0100, Ralf Corsepius wrote: > > > > On Mon, 2008-01-07 at 16:15 +0100, Patrice Dumas wrote: > > > > > > I'd say the reverse than Rex, include the Require manually. But I may > > > well be wrong. > > > > Well, you are. If an upstream has its package properly designed (Esp. > > uses SONAMEs properly), then there should not be any need to let a > > run-time/application-package explicitly require a package by name. > > Unless I am wrong, the sonames of 2.8 nad 2.10 are the same, but above > 2.10 is needed. If the SONAMEs are the same, the libraries MUST be compatible. => No need for a package dep. Ralf From tibbs at math.uh.edu Mon Jan 7 16:45:33 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 07 Jan 2008 10:45:33 -0600 Subject: [Fedora-packaging] Automatic detection of Requires and versions In-Reply-To: <1199723932.6022.134.camel@beck.corsepiu.local> References: <9cea66a70801070440t602093d9j845e6d81938773bd@mail.gmail.com> <20080107151539.GJ2614@free.fr> <1199719254.6022.125.camel@beck.corsepiu.local> <20080107154322.GK2614@free.fr> <1199723932.6022.134.camel@beck.corsepiu.local> Message-ID: >>>>> "RC" == Ralf Corsepius writes: RC> If the SONAMEs are the same, the libraries MUST be compatible. Well, either that or the developers of said library have screwed up. It's not as if we haven't seen that before. RC> => No need for a package dep. In the case where you depend on a package that's broken as above, though, you may not have a lot of choice. Of course, I think this is all moot as we don't generally go updating gtk within a release, and all supported Fedora releases already have gtk2 2.10 anyway. So a versioned dependency on gtk2 would be pointless because it's always going to be satisfied in situations we support. - J< From Axel.Thimm at ATrpms.net Mon Jan 7 21:19:11 2008 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 7 Jan 2008 23:19:11 +0200 Subject: [Fedora-packaging] Re: Automatic detection of Requires and versions In-Reply-To: <1199719254.6022.125.camel@beck.corsepiu.local> References: <9cea66a70801070440t602093d9j845e6d81938773bd@mail.gmail.com> <20080107151539.GJ2614@free.fr> <1199719254.6022.125.camel@beck.corsepiu.local> Message-ID: <20080107211911.GB15418@puariko.nirvana> On Mon, Jan 07, 2008 at 04:20:54PM +0100, Ralf Corsepius wrote: > > On Mon, 2008-01-07 at 16:15 +0100, Patrice Dumas wrote: > > On Mon, Jan 07, 2008 at 10:40:05AM -0200, Eduardo M KALINOWSKI wrote: > > > Hi, > > > > > > I'm attempting to package a program I wrote, that uses the GTK+ > > > libraries. It uses features first found in the 2.10.X series, so I > > > include > > > > > > BuildRequires: gtk2-devel >= 2.10.0 > > > > > > (and similar lines for glib and other required libraries). All this is > > > OK. The problem is regarding the Requires for the generated .rpm. I > > > could use > > > > > > Requires: gtk2 >= 2.10.0 > > > > > > but apparently this is bad style and bad for maintenance, because > > > dependencies are found automatically on build time. However, without > > > manually adding the requires, the generated .rpm contains (with regard > > > to GTK+) this: > > > > > > libgtk-x11-2.0.so.0 > > > > > > that is, no mention of the version, and I expect that even a GTK+ 2.8 > > > package (old as that may be) should provide that file with that name. > > > > > > What is the best way to handle that? Include the Require manually? > > > Leave this as-is? > > > > I'd say the reverse than Rex, include the Require manually. But I may > > well be wrong. > > Well, you are. If an upstream has its package properly designed (Esp. > uses SONAMEs properly), then there should not be any need to let a > run-time/application-package explicitly require a package by name. That's a big if actually. But I would reason differently - if the package *build* ensured that gtk2-devel was larger than 2.10.0 then gtk2 will also be larger than that when pulled from the same repo. So in the (usual) case of using a Fedora X package within Fedora X one doesn't have to add versioned Requires:. In the rare case that one would want to use the package in a different environment then things change - for example it has happened a couple of times in the past that using a package built on the *updated* gtk2/glib2 will require symbols not found in the non-updated *release* version and will break the app. It has happened with synaptic a couple of times, e.g. a user installs from DVD then wants to use apt/synaptic from updates-released to update his system and this synaptic bails out as it is not compatible to the old libs from the release (I think it was glib2 that had some more symbols used than the release had) In order to avoid this catch22 depsolver updates should in theory be built against the released non-updated bits only, but this is probably not really worth the trouble - I once maintained non-updated build chroots just for that reason until the maintenance was too much to handle (and all depsolvers eventually made it into Fedora anyway, so I hadn't had to deal with the problem anymore ;) -- 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 pertusus at free.fr Mon Jan 7 22:08:38 2008 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 7 Jan 2008 23:08:38 +0100 Subject: [Fedora-packaging] Automatic detection of Requires and versions In-Reply-To: <1199723932.6022.134.camel@beck.corsepiu.local> References: <9cea66a70801070440t602093d9j845e6d81938773bd@mail.gmail.com> <20080107151539.GJ2614@free.fr> <1199719254.6022.125.camel@beck.corsepiu.local> <20080107154322.GK2614@free.fr> <1199723932.6022.134.camel@beck.corsepiu.local> Message-ID: <20080107220838.GB2761@free.fr> On Mon, Jan 07, 2008 at 05:38:52PM +0100, Ralf Corsepius wrote: > > If the SONAMEs are the same, the libraries MUST be compatible. > > => No need for a package dep. They can be backward compatible and not forward compatible and have the same sonames. It is the case with usual libtool versionning. Though, as Axel said it may be a bit pointless since the updated library will be in the updated repo. -- Pat From timothy.selivanow at virtualxistenz.com Tue Jan 8 00:16:00 2008 From: timothy.selivanow at virtualxistenz.com (Timothy Selivanow) Date: Mon, 07 Jan 2008 16:16:00 -0800 Subject: [Fedora-packaging] Re: Package for pysvn In-Reply-To: References: <1199493344.25346.53.camel@denkiteki-penpen.easystreet.com> Message-ID: <1199751360.27234.10.camel@denkiteki-penpen.easystreet.com> On Mon, 2008-01-07 at 13:09 +0100, Terje Rosten wrote: > * Timothy Selivanow > | > | I'm trying to make a package for pysvn [http://pysvn.tigris.org] and I > | have a few questions. Right now it's not compiling, rpmbuild is > | complaining about "error: line 27: Package does not exist: %description > | debuginfo", this must have changed either in F7 or F8 because this spec > | worked a long time ago (F6/F7, not sure which). > | > | Also, I discovered that the installer makes a differently named .so > | depending on the version of python that it is compiling against, and I'd > | like to know the best way to do an if style statement that will solve > | that (I'd like to be able to use the same spec on CentOS too). > | > | So, any help and comments would be much appreciated. Thanks! > | > | Below is the spec file. > | > | ---BEGIN SPEC--- > > Hi Tim, > > I took your spec and improved it a bit, spec, patches, srpm and rpm are > available here: > > http://terjeros.fedorapeople.org/python-svn/ > > Some notes: > o renamed to python-svn (that's the proper way) > o fixed license tag > o add patch to remove rpath issue > o add patch to remove the python version stuff > o move tests to %%check (however they are failing...) > o fixed src url > o compile with fedora compile flags > o use macros etc random clean up > > Feel free to improve further and submit for inclusion. > > > - Terje Thanks for all of that. I'm still getting the "Package does not exist" error (full error below). Even after removing rpm-build, `yum clean all`, and reinstalling rpm-build I still get that error. I tried it on my home computer just now and it worked (both x86_64, but one intel and the other amd). What do I need to look at to fix this? Error: "error: line 38: Package does not exist: %description debuginfo" --Tim ______________________________________________________________________ < Be careful when a loop exits to the same place from side and bottom. > ---------------------------------------------------------------------- \ \ \ \ /\ ( ) .( o ). From timothy.selivanow at virtualxistenz.com Tue Jan 8 01:00:14 2008 From: timothy.selivanow at virtualxistenz.com (Timothy Selivanow) Date: Mon, 07 Jan 2008 17:00:14 -0800 Subject: [Fedora-packaging] Re: Package for pysvn In-Reply-To: <1199751360.27234.10.camel@denkiteki-penpen.easystreet.com> References: <1199493344.25346.53.camel@denkiteki-penpen.easystreet.com> <1199751360.27234.10.camel@denkiteki-penpen.easystreet.com> Message-ID: <1199754014.27234.24.camel@denkiteki-penpen.easystreet.com> On Mon, 2008-01-07 at 16:16 -0800, Timothy Selivanow wrote: > On Mon, 2008-01-07 at 13:09 +0100, Terje Rosten wrote: > > * Timothy Selivanow > > | > > | I'm trying to make a package for pysvn [http://pysvn.tigris.org] and I > > | have a few questions. Right now it's not compiling, rpmbuild is > > | complaining about "error: line 27: Package does not exist: %description > > | debuginfo", this must have changed either in F7 or F8 because this spec > > | worked a long time ago (F6/F7, not sure which). > > | > > | Also, I discovered that the installer makes a differently named .so > > | depending on the version of python that it is compiling against, and I'd > > | like to know the best way to do an if style statement that will solve > > | that (I'd like to be able to use the same spec on CentOS too). > > | > > | So, any help and comments would be much appreciated. Thanks! > > | > > | Below is the spec file. > > | > > | ---BEGIN SPEC--- > > > > Hi Tim, > > > > I took your spec and improved it a bit, spec, patches, srpm and rpm are > > available here: > > > > http://terjeros.fedorapeople.org/python-svn/ > > > > Some notes: > > o renamed to python-svn (that's the proper way) > > o fixed license tag > > o add patch to remove rpath issue > > o add patch to remove the python version stuff > > o move tests to %%check (however they are failing...) Yah, I see that. The error log shows multiple "ImportError: No module named _pysvn". I'll continue to track this down, first things that come to mind are: "did the pysvn-1.5.2-drop-version.patch mess the tests up?" --or-- "putting the test in %check somehow changed the expected enviro." > > o fixed src url > > o compile with fedora compile flags > > o use macros etc random clean up > > > > Feel free to improve further and submit for inclusion. > > > > > > - Terje The package works as expected other-wise. I installed it on my home machine and was able to do a quick test by checking something out. I know that the _pysvn module connects to _pysvn.so, so I'll start there... --Tim ___________________________________ < All intelligent species own cats. > ----------------------------------- \ \ \ \ /\ ( ) .( o ). From overholt at redhat.com Tue Jan 8 14:02:33 2008 From: overholt at redhat.com (Andrew Overholt) Date: Tue, 8 Jan 2008 09:02:33 -0500 Subject: [Fedora-packaging] Proposal: Eclipse Plugins Guidelines Message-ID: <20080108140231.GA14726@redhat.com> Hi, Rob, Alphonse, and myself have written packaging guidelines for Eclipse plugins. We'd like to propose them for FPC consideration. I'll be at the meeting today (1700 UTC, right?) and I've added an item to http://fedoraproject.org/wiki/Packaging/GuidelinesTodo. The guidelines are here: http://fedoraproject.org/wiki/PackagingDrafts/EclipsePlugins Thanks, Andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tcallawa at redhat.com Tue Jan 8 15:17:55 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 08 Jan 2008 10:17:55 -0500 Subject: [Fedora-packaging] Proposal: Eclipse Plugins Guidelines In-Reply-To: <20080108140231.GA14726@redhat.com> References: <20080108140231.GA14726@redhat.com> Message-ID: <1199805475.3522.3.camel@localhost.localdomain> On Tue, 2008-01-08 at 09:02 -0500, Andrew Overholt wrote: > Hi, > > Rob, Alphonse, and myself have written packaging guidelines for Eclipse > plugins. We'd like to propose them for FPC consideration. I'll be at > the meeting today (1700 UTC, right?) and I've added an item to > http://fedoraproject.org/wiki/Packaging/GuidelinesTodo. > > The guidelines are here: > > http://fedoraproject.org/wiki/PackagingDrafts/EclipsePlugins One item that jumped out at me: In that draft, you refer to Packaging/Java, which doesn't exist, since we've never had anyone submit Java packaging guidelines, and no one on the Packaging Committee is qualified to write them. ~spot From overholt at redhat.com Tue Jan 8 15:22:02 2008 From: overholt at redhat.com (Andrew Overholt) Date: Tue, 08 Jan 2008 10:22:02 -0500 Subject: [Fedora-packaging] Proposal: Eclipse Plugins Guidelines In-Reply-To: <1199805475.3522.3.camel@localhost.localdomain> References: <20080108140231.GA14726@redhat.com> <1199805475.3522.3.camel@localhost.localdomain> Message-ID: <4783951A.7030906@redhat.com> Tom "spot" Callaway wrote: > On Tue, 2008-01-08 at 09:02 -0500, Andrew Overholt wrote: >> Hi, >> >> Rob, Alphonse, and myself have written packaging guidelines for Eclipse >> plugins. We'd like to propose them for FPC consideration. I'll be at >> the meeting today (1700 UTC, right?) and I've added an item to >> http://fedoraproject.org/wiki/Packaging/GuidelinesTodo. >> >> The guidelines are here: >> >> http://fedoraproject.org/wiki/PackagingDrafts/EclipsePlugins > > One item that jumped out at me: > > In that draft, you refer to Packaging/Java, which doesn't exist, since > we've never had anyone submit Java packaging guidelines, and no one on > the Packaging Committee is qualified to write them. Yeah, I've been trying to drum up some interest to get those written. I think something will happen this week. I punted to them since it's not really the place of the Eclipse plugin guidelines to specify gcj/IcedTea and related stuff. Andrew From rc040203 at freenet.de Wed Jan 9 09:14:09 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 09 Jan 2008 10:14:09 +0100 Subject: [Fedora-packaging] Automatic detection of Requires and versions In-Reply-To: <20080107220838.GB2761@free.fr> References: <9cea66a70801070440t602093d9j845e6d81938773bd@mail.gmail.com> <20080107151539.GJ2614@free.fr> <1199719254.6022.125.camel@beck.corsepiu.local> <20080107154322.GK2614@free.fr> <1199723932.6022.134.camel@beck.corsepiu.local> <20080107220838.GB2761@free.fr> Message-ID: <1199870049.5534.202.camel@beck.corsepiu.local> On Mon, 2008-01-07 at 23:08 +0100, Patrice Dumas wrote: > On Mon, Jan 07, 2008 at 05:38:52PM +0100, Ralf Corsepius wrote: > > > > If the SONAMEs are the same, the libraries MUST be compatible. > > > > => No need for a package dep. > > They can be backward compatible and not forward compatible and have the > same sonames. It is the case with usual libtool versionning. And were is the problem? I feel you are splitting hairs. Ralf From pertusus at free.fr Wed Jan 9 09:46:07 2008 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 9 Jan 2008 10:46:07 +0100 Subject: [Fedora-packaging] Automatic detection of Requires and versions In-Reply-To: <1199870049.5534.202.camel@beck.corsepiu.local> References: <9cea66a70801070440t602093d9j845e6d81938773bd@mail.gmail.com> <20080107151539.GJ2614@free.fr> <1199719254.6022.125.camel@beck.corsepiu.local> <20080107154322.GK2614@free.fr> <1199723932.6022.134.camel@beck.corsepiu.local> <20080107220838.GB2761@free.fr> <1199870049.5534.202.camel@beck.corsepiu.local> Message-ID: <20080109094607.GD2761@free.fr> On Wed, Jan 09, 2008 at 10:14:09AM +0100, Ralf Corsepius wrote: > > On Mon, 2008-01-07 at 23:08 +0100, Patrice Dumas wrote: > > On Mon, Jan 07, 2008 at 05:38:52PM +0100, Ralf Corsepius wrote: > > > > > > If the SONAMEs are the same, the libraries MUST be compatible. > > > > > > => No need for a package dep. > > > > They can be backward compatible and not forward compatible and have the > > same sonames. It is the case with usual libtool versionning. > And were is the problem? I feel you are splitting hairs. If something is added between 2.8 and 2.10 while ABI is kept compatible and the soname isn't changed, and that new thing is needed, then the soname is not enough. -- Pat From timothy.selivanow at virtualxistenz.com Wed Jan 9 16:24:46 2008 From: timothy.selivanow at virtualxistenz.com (Timothy Selivanow) Date: Wed, 09 Jan 2008 08:24:46 -0800 Subject: [Fedora-packaging] Re: Package for pysvn In-Reply-To: <989a1fddc9f8c8707e2a0e4aec46a079@ntnu.no> References: <1199751360.27234.10.camel@denkiteki-penpen.easystreet.com> <989a1fddc9f8c8707e2a0e4aec46a079@ntnu.no> Message-ID: <1199895886.30572.6.camel@denkiteki-penpen.easystreet.com> On Wed, 2008-01-09 at 11:09 +0100, Terje R?sten wrote: > > Thanks for all of that. I'm still getting the "Package does not exist" > > error (full error below). Even after removing rpm-build, `yum clean > > all`, and reinstalling rpm-build I still get that error. I tried it on > > my home computer just now and it worked (both x86_64, but one intel and > > the other amd). What do I need to look at to fix this? > > > > Error: > > "error: line 38: Package does not exist: %description debuginfo" > > OK, I need some more info. Can you try the following: > > Download the srpm: > > http://terjeros.fedorapeople.org/python-svn/python-svn-1.5.2-2.fc8.src.rpm > > Install by > > $ rpm -Uvh python-svn-1.5.2-2.fc8.src.rpm > > Now build by > > $ rpmbuild -ba /path/to/python-svn.spec > > > Post any error output. > > Note: these lines > > %description debuginfo > debug info > > in your original spec file should not be there, debuginfo packages is > generated > automagically by rpmbuild itself. Just remove those lines. > > > - Terje Same thing. I even did a rpmdev-wipetree to make sure I was using the spec from the srpm. I think something is stuck in my environment, and I don't know what it would be... $ rpmdev-wipetree Removing all build files... $ ls -Al ./rpmbuild/SPECS/ total 0 $ rpm -Uvh ./python-svn-1.5.2-2.fc8.src.rpm 1:python-svn warning: user terjeros does not exist - using root warning: group fysikk does not exist - using root warning: user terjeros does not exist - using root warning: group fysikk does not exist - using root warning: user terjeros does not exist - using root warning: group fysikk does not exist - using root ########################################### [100%] warning: user terjeros does not exist - using root warning: group fysikk does not exist - using root $ rpmbuild -ba ./rpmbuild/SPECS/python-svn.spec error: line 38: Package does not exist: %description debuginfo --Tim ______________________________________________________________ / "Oh dear, I think you'll find reality's on the blink again." \ \ -- Marvin The Paranoid Android / -------------------------------------------------------------- \ \ \ \ /\ ( ) .( o ). From tcallawa at redhat.com Wed Jan 9 16:32:10 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 09 Jan 2008 11:32:10 -0500 Subject: [Fedora-packaging] Re: Package for pysvn In-Reply-To: <1199895886.30572.6.camel@denkiteki-penpen.easystreet.com> References: <1199751360.27234.10.camel@denkiteki-penpen.easystreet.com> <989a1fddc9f8c8707e2a0e4aec46a079@ntnu.no> <1199895886.30572.6.camel@denkiteki-penpen.easystreet.com> Message-ID: <1199896330.32054.16.camel@localhost.localdomain> On Wed, 2008-01-09 at 08:24 -0800, Timothy Selivanow wrote: > $ rpmbuild -ba ./rpmbuild/SPECS/python-svn.spec > error: line 38: Package does not exist: %description debuginfo For what it is worth, I downloaded the package from Terje's URL and it builds fine on my end. Look at your ~/.rpmmacros file, see if anything odd is in there. Double check that you're using the clean spec file, with no "% description debuginfo". ~spot From notting at redhat.com Wed Jan 9 16:58:23 2008 From: notting at redhat.com (Bill Nottingham) Date: Wed, 9 Jan 2008 11:58:23 -0500 Subject: [Fedora-packaging] Automatic detection of Requires and versions In-Reply-To: <20080109094607.GD2761@free.fr> References: <9cea66a70801070440t602093d9j845e6d81938773bd@mail.gmail.com> <20080107151539.GJ2614@free.fr> <1199719254.6022.125.camel@beck.corsepiu.local> <20080107154322.GK2614@free.fr> <1199723932.6022.134.camel@beck.corsepiu.local> <20080107220838.GB2761@free.fr> <1199870049.5534.202.camel@beck.corsepiu.local> <20080109094607.GD2761@free.fr> Message-ID: <20080109165823.GE12763@nostromo.devel.redhat.com> Patrice Dumas (pertusus at free.fr) said: > If something is added between 2.8 and 2.10 while ABI is kept compatible > and the soname isn't changed, and that new thing is needed, then the > soname is not enough. Only in the case when you're running something built against, say Fedora 8, on Fedora < 8. (Or Fedora 8 from some number of months ago, I suppose, if people are gratuitously upgrading libraries.) Bill From pertusus at free.fr Wed Jan 9 17:12:30 2008 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 9 Jan 2008 18:12:30 +0100 Subject: [Fedora-packaging] Automatic detection of Requires and versions In-Reply-To: <20080109165823.GE12763@nostromo.devel.redhat.com> References: <9cea66a70801070440t602093d9j845e6d81938773bd@mail.gmail.com> <20080107151539.GJ2614@free.fr> <1199719254.6022.125.camel@beck.corsepiu.local> <20080107154322.GK2614@free.fr> <1199723932.6022.134.camel@beck.corsepiu.local> <20080107220838.GB2761@free.fr> <1199870049.5534.202.camel@beck.corsepiu.local> <20080109094607.GD2761@free.fr> <20080109165823.GE12763@nostromo.devel.redhat.com> Message-ID: <20080109171230.GA2798@free.fr> On Wed, Jan 09, 2008 at 11:58:23AM -0500, Bill Nottingham wrote: > Patrice Dumas (pertusus at free.fr) said: > > If something is added between 2.8 and 2.10 while ABI is kept compatible > > and the soname isn't changed, and that new thing is needed, then the > > soname is not enough. > > Only in the case when you're running something built against, say > Fedora 8, on Fedora < 8. (Or Fedora 8 from some number of months > ago, I suppose, if people are gratuitously upgrading libraries.) Indeed. But the point is that sometime sonames are not enough. Now it is up to the packager, he may consider that there is no need of the versionned requires because there is no such lib in relevant and maintained fedora/EPEL distros or there is such lib, but also an updated version and people are supposed to be uptodate. -- Pat From timothy.selivanow at virtualxistenz.com Wed Jan 9 18:08:20 2008 From: timothy.selivanow at virtualxistenz.com (Timothy Selivanow) Date: Wed, 09 Jan 2008 10:08:20 -0800 Subject: [Fedora-packaging] Re: Package for pysvn In-Reply-To: <1199896330.32054.16.camel@localhost.localdomain> References: <1199751360.27234.10.camel@denkiteki-penpen.easystreet.com> <989a1fddc9f8c8707e2a0e4aec46a079@ntnu.no> <1199895886.30572.6.camel@denkiteki-penpen.easystreet.com> <1199896330.32054.16.camel@localhost.localdomain> Message-ID: <1199902100.30572.19.camel@denkiteki-penpen.easystreet.com> On Wed, 2008-01-09 at 11:32 -0500, Tom "spot" Callaway wrote: > On Wed, 2008-01-09 at 08:24 -0800, Timothy Selivanow wrote: > > > $ rpmbuild -ba ./rpmbuild/SPECS/python-svn.spec > > error: line 38: Package does not exist: %description debuginfo > > For what it is worth, I downloaded the package from Terje's URL and it > builds fine on my end. > > Look at your ~/.rpmmacros file, see if anything odd is in there. > > Double check that you're using the clean spec file, with no "% > description debuginfo". > > ~spot Aarg! ~/.rpmmacros was the first thing I checked initially, but I missed it the first time. FWIW: %packager != %package :) As soon as I get the %check section fixed, I'll repost it for comments. --Tim ___________________________________________________ / court, n.: \ | A place where they dispense with justice. | \ -- Arthur Train / --------------------------------------------------- \ \ \ \ /\ ( ) .( o ). From Axel.Thimm at ATrpms.net Wed Jan 9 18:58:55 2008 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 9 Jan 2008 20:58:55 +0200 Subject: [Fedora-packaging] Re: Automatic detection of Requires and versions In-Reply-To: <20080109165823.GE12763@nostromo.devel.redhat.com> References: <9cea66a70801070440t602093d9j845e6d81938773bd@mail.gmail.com> <20080107151539.GJ2614@free.fr> <1199719254.6022.125.camel@beck.corsepiu.local> <20080107154322.GK2614@free.fr> <1199723932.6022.134.camel@beck.corsepiu.local> <20080107220838.GB2761@free.fr> <1199870049.5534.202.camel@beck.corsepiu.local> <20080109094607.GD2761@free.fr> <20080109165823.GE12763@nostromo.devel.redhat.com> Message-ID: <20080109185855.GC4150@puariko.nirvana> On Wed, Jan 09, 2008 at 11:58:23AM -0500, Bill Nottingham wrote: > Patrice Dumas (pertusus at free.fr) said: > > If something is added between 2.8 and 2.10 while ABI is kept compatible > > and the soname isn't changed, and that new thing is needed, then the > > soname is not enough. > > Only in the case when you're running something built against, say > Fedora 8, on Fedora < 8. (Or Fedora 8 from some number of months > ago, I suppose, if people are gratuitously upgrading libraries.) As said this has happened with real life use cases: Users did install some bare Fedora Core X w/o updates, then considered it proper to first upgrade synaptic which required updated (but still within the same Fedora Core release) gtk/glib etc. libs and then wouldn't start on the non-updated Fedora Core system. If this depsolver & GUI is your preferred method of updating then you are suddenly in a chicken/egg situation - you need to depsolver to update the system and the depsolver needs the system to be updated to even start. So for some cases like for deplsovers and their GUIs maybe adding strict automatic dependencies (e.g. like Requires: foo >= %(rpm -q foo)) is a safe keeper to not run into similar situations again. Or rephrased: ABI backward-compatibility (which constant sonames imply) is not enough if the matter of upgrade ordering matters. -- 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 rdieter at math.unl.edu Wed Jan 9 19:14:37 2008 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 09 Jan 2008 13:14:37 -0600 Subject: [Fedora-packaging] Re: Automatic detection of Requires and versions In-Reply-To: <20080109185855.GC4150@puariko.nirvana> References: <9cea66a70801070440t602093d9j845e6d81938773bd@mail.gmail.com> <20080107151539.GJ2614@free.fr> <1199719254.6022.125.camel@beck.corsepiu.local> <20080107154322.GK2614@free.fr> <1199723932.6022.134.camel@beck.corsepiu.local> <20080107220838.GB2761@free.fr> <1199870049.5534.202.camel@beck.corsepiu.local> <20080109094607.GD2761@free.fr> <20080109165823.GE12763@nostromo.devel.redhat.com> <20080109185855.GC4150@puariko.nirvana> Message-ID: <47851D1D.405@math.unl.edu> Axel Thimm wrote: > On Wed, Jan 09, 2008 at 11:58:23AM -0500, Bill Nottingham wrote: >> Patrice Dumas (pertusus at free.fr) said: >>> If something is added between 2.8 and 2.10 while ABI is kept compatible >>> and the soname isn't changed, and that new thing is needed, then the >>> soname is not enough. >> Only in the case when you're running something built against, say >> Fedora 8, on Fedora < 8. (Or Fedora 8 from some number of months >> ago, I suppose, if people are gratuitously upgrading libraries.) > > As said this has happened with real life use cases: But these cases are (should be!) much the exception, and not the rule. -- Rex From petersen at redhat.com Fri Jan 11 01:26:35 2008 From: petersen at redhat.com (Jens Petersen) Date: Fri, 11 Jan 2008 11:26:35 +1000 Subject: [Fedora-packaging] naming of "documentation-devel" package Message-ID: <4786C5CB.4020900@redhat.com> Hi, A package named "documentation-devel" has been submitted for review to Fedora recently: https://bugzilla.redhat.com/show_bug.cgi?id=427481 It provides a comprehensive set of tools used by the Red Hat Docs team and some others to build documentation written in docbook and its translations into various formats. The question is can we keep the name as is, since they are not keen on changing it, or should the name of the package be changed? Jens From rc040203 at freenet.de Fri Jan 11 02:55:48 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 11 Jan 2008 03:55:48 +0100 Subject: [Fedora-packaging] naming of "documentation-devel" package In-Reply-To: <4786C5CB.4020900@redhat.com> References: <4786C5CB.4020900@redhat.com> Message-ID: <1200020148.5534.594.camel@beck.corsepiu.local> On Fri, 2008-01-11 at 11:26 +1000, Jens Petersen wrote: > Hi, > > A package named "documentation-devel" has been submitted for review to > Fedora recently: > > https://bugzilla.redhat.com/show_bug.cgi?id=427481 > > It provides a comprehensive set of tools used by the Red Hat Docs team > and some others to build documentation written in docbook and its > translations into various formats. > > The question is can we keep the name as is, since they are not keen on > changing it, or should the name of the package be changed? My 0.02?: Formally, wrt. the FPC, there is nothing wrong with this name, ... The upstream package name choice is very unfortunate and raises false associations/confusion on the users' side. It should be changed do something more descriptive. If I were reviewing this package, I would not accept this package. Ralf From timothy.selivanow at virtualxistenz.com Fri Jan 11 23:29:38 2008 From: timothy.selivanow at virtualxistenz.com (Timothy Selivanow) Date: Fri, 11 Jan 2008 15:29:38 -0800 Subject: [Fedora-packaging] Package for python-svn (was pysvn) Message-ID: <1200094178.3143.4.camel@denkiteki-penpen.easystreet.com> So, I've finally had some extra time to work on this and I've made a few tweaks to the spec and one of the patches. It now builds fine, including the tests in %check. Thank you Terje, and others for your help :) Here is the latest stuff: http://yum.virtualxistenz.com/python-svn/ Questions, comments, screams-of-outrage, moral or immoral indignations? --Tim _____________________________________________________________ < Please, won't somebody tell me what diddie-wa-diddie means? > ------------------------------------------------------------- \ \ \ \ /\ ( ) .( o ). From karsten at redhat.com Tue Jan 15 13:39:47 2008 From: karsten at redhat.com (Karsten Hopp) Date: Tue, 15 Jan 2008 14:39:47 +0100 Subject: [Fedora-packaging] Should vim-X11 conflict with vim-enhanced ? Message-ID: <478CB7A3.8000206@redhat.com> Hello, Till proposed in bugzilla #311061 to use alternatives in vim-enhanced and vim-X11 so that both of them can provide /usr/bin/vim. His reasoning as that when gvim gets started as vim (via a symlink) it opens the text mode vim with the additional benefit of xterm clipboard support. I agree with the /usr/bin/vim stuff, but I think a better solution would be to add a conflict between vim-X11 and vim-enhanced. vim-enhanced is only of use on systems without X11/gtk. On all other systems vim-X11 can provide the same (and more) functionality as vim-enhanced. Karsten -- Karsten Hopp | Mail: karsten at redhat.de Red Hat Deutschland | Tel: +49-711-96437-0 Hauptstaetterstr.58 | Fax: +49-711-613590 D-70178 Stuttgart | http://www.redhat.de From opensource at till.name Tue Jan 15 13:50:18 2008 From: opensource at till.name (Till Maas) Date: Tue, 15 Jan 2008 14:50:18 +0100 Subject: [Fedora-packaging] Should vim-X11 conflict with vim-enhanced ? In-Reply-To: <478CB7A3.8000206@redhat.com> References: <478CB7A3.8000206@redhat.com> Message-ID: <200801151450.32656.opensource@till.name> On Tue January 15 2008, Karsten Hopp wrote: > I agree with the /usr/bin/vim stuff, but I think a better solution would be > to add a conflict between vim-X11 and vim-enhanced. vim-enhanced is only of > use on systems without X11/gtk. On all other systems vim-X11 can provide > the same (and more) functionality as vim-enhanced. Ah, the only possible problem I can think of would be that an "update" from vim-enhanced to vim-X11 may not be possible. It should be possbile to do # yum install vim-enhanced # yum install vim-X11 and then vim-enhanced would be removed and vim-X11 installed. I do not know, whether this works with only Conflicts: or if e.g. a Obsoletes: or something else then needs to be added to vim-X11. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From opensource at till.name Tue Jan 15 13:57:15 2008 From: opensource at till.name (Till Maas) Date: Tue, 15 Jan 2008 14:57:15 +0100 Subject: [Fedora-packaging] Should vim-X11 conflict with vim-enhanced ? In-Reply-To: <200801151450.32656.opensource@till.name> References: <478CB7A3.8000206@redhat.com> <200801151450.32656.opensource@till.name> Message-ID: <200801151457.16213.opensource@till.name> On Tue January 15 2008, Till Maas wrote: > On Tue January 15 2008, Karsten Hopp wrote: > > I agree with the /usr/bin/vim stuff, but I think a better solution would > > be to add a conflict between vim-X11 and vim-enhanced. vim-enhanced is > > only of use on systems without X11/gtk. On all other systems vim-X11 can > > provide the same (and more) functionality as vim-enhanced. > > Ah, the only possible problem I can think of would be that an "update" from > vim-enhanced to vim-X11 may not be possible. It should be possbile to do Using alternatives would make it easier for users in another case, too. When someone wants to remove X11 from a default Fedora install ans still keep his favourite editor. Then one could install both vim-X11 and vim-enhanced and after removing X11, vim-enhanced would be still there. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From rms at 1407.org Tue Jan 15 15:35:36 2008 From: rms at 1407.org (Rui Miguel Silva Seabra) Date: Tue, 15 Jan 2008 15:35:36 +0000 Subject: [Fedora-packaging] Re: Should vim-X11 conflict with vim-enhanced ? In-Reply-To: <478CB7A3.8000206@redhat.com> References: <478CB7A3.8000206@redhat.com> Message-ID: <20080115153536.GB6483@roque.1407.org> On Tue, Jan 15, 2008 at 02:39:47PM +0100, Karsten Hopp wrote: > I agree with the /usr/bin/vim stuff, but I think a better solution would be > to add a conflict between > vim-X11 and vim-enhanced. vim-enhanced is only of use on systems without > X11/gtk. On all other > systems vim-X11 can provide the same (and more) functionality as > vim-enhanced. I would strongly disagree that vim-enhanced is only of use on systems without X11/gtk. vim is far more pratical on an terminal emulator than gvim, even on a system with X11/gtk. Rui -- Or not. Today is Setting Orange, the 15th day of Chaos in the YOLD 3174 + No matter how much you do, you never do enough -- unknown + Whatever you do will be insignificant, | but it is very important that you do it -- Gandhi + So let's do it...? From cjdahlin at ncsu.edu Tue Jan 15 15:35:16 2008 From: cjdahlin at ncsu.edu (Casey Dahlin) Date: Tue, 15 Jan 2008 10:35:16 -0500 Subject: [Fedora-packaging] Re: Should vim-X11 conflict with vim-enhanced ? In-Reply-To: <478CB7A3.8000206@redhat.com> References: <478CB7A3.8000206@redhat.com> Message-ID: <478CD2B4.6040205@ncsu.edu> Karsten Hopp wrote: > Hello, > > Till proposed in bugzilla #311061 to use alternatives in vim-enhanced > and vim-X11 so that > both of them can provide /usr/bin/vim. His reasoning as that when gvim > gets started as vim > (via a symlink) it opens the text mode vim with the additional > benefit of xterm clipboard support. > This can be turned on in vim-enhanced just by adding a few flags to the spec. It seems not to cause any trouble without an X server too. I've done it on RHEL. > I agree with the /usr/bin/vim stuff, but I think a better solution > would be to add a conflict between > vim-X11 and vim-enhanced. vim-enhanced is only of use on systems > without X11/gtk. On all other > systems vim-X11 can provide the same (and more) functionality as > vim-enhanced. > > Karsten > > -- > Karsten Hopp | Mail: karsten at redhat.de > Red Hat Deutschland | Tel: +49-711-96437-0 > Hauptstaetterstr.58 | Fax: +49-711-613590 > D-70178 Stuttgart | http://www.redhat.de > From opensource at till.name Tue Jan 15 15:47:52 2008 From: opensource at till.name (Till Maas) Date: Tue, 15 Jan 2008 16:47:52 +0100 Subject: [Fedora-packaging] Re: Should vim-X11 conflict with vim-enhanced ? In-Reply-To: <20080115153536.GB6483@roque.1407.org> References: <478CB7A3.8000206@redhat.com> <20080115153536.GB6483@roque.1407.org> Message-ID: <200801151647.53632.opensource@till.name> On Tue January 15 2008, Rui Miguel Silva Seabra wrote: > vim is far more pratical on an terminal emulator than gvim, even on a > system with X11/gtk. The gvim binary runs without any problems in an terminal emulator or a terminal when it is run with the name vim. Or do you know anything that breaks then? Btw. you can test it with: cd /tmp ln -s /usr/bin/gvim vim /tmp/vim Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From pertusus at free.fr Tue Jan 15 16:03:28 2008 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 15 Jan 2008 17:03:28 +0100 Subject: [Fedora-packaging] tex/latex doc install location Message-ID: <20080115160328.GA2619@free.fr> Hello, In tex/latex bundled in fedora (I guess it comes from tetex and it is now in texlive) there is a simple system to view documentation. The files are found below /usr/share/texmf/doc using kpathsea (so hopefully rapidly) and opened using the appropriate application (currently using xdg-open for everything...). In fedora should we use this system and put the doc files below /usr/share/texmf/doc/ or use %doc? -- Pat From jamatos at fc.up.pt Tue Jan 15 16:25:49 2008 From: jamatos at fc.up.pt (=?iso-8859-1?q?Jos=E9_Matos?=) Date: Tue, 15 Jan 2008 16:25:49 +0000 Subject: [Fedora-packaging] tex/latex doc install location In-Reply-To: <20080115160328.GA2619@free.fr> References: <20080115160328.GA2619@free.fr> Message-ID: <200801151625.49822.jamatos@fc.up.pt> On Tuesday 15 January 2008 16:03:28 Patrice Dumas wrote: > Hello, > > In tex/latex bundled in fedora (I guess it comes from tetex and it is > now in texlive) there is a simple system to view documentation. The > files are found below /usr/share/texmf/doc using kpathsea (so hopefully > rapidly) and opened using the appropriate application (currently using > xdg-open for everything...). > > In fedora should we use this system and put the doc files below > /usr/share/texmf/doc/ or use %doc? Notice that this is in line with other languages, the documentation for R packages (as an example) in under the R tree. I would like to favour the texmf tree as the natural packaging place of latex documentation. The package that started this discussion is the review https://bugzilla.redhat.com/show_bug.cgi?id=428686 I would like to use this package to be an example to draft the fedora (la)tex package guidelines. Sooner or later we need them and now is good time. :-) Notice that the package follows the consensus on this list in August, naming the package as tex-simplecv. All feedback is welcome. :-) > -- > Pat -- Jos? Ab?lio From katzj at redhat.com Tue Jan 15 16:25:33 2008 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 15 Jan 2008 11:25:33 -0500 Subject: [Fedora-packaging] Should vim-X11 conflict with vim-enhanced ? In-Reply-To: <478CB7A3.8000206@redhat.com> References: <478CB7A3.8000206@redhat.com> Message-ID: <1200414333.3433.1.camel@aglarond.local> On Tue, 2008-01-15 at 14:39 +0100, Karsten Hopp wrote: > I agree with the /usr/bin/vim stuff, but I think a better solution would be to add a conflict between > vim-X11 and vim-enhanced. vim-enhanced is only of use on systems without X11/gtk. On all other > systems vim-X11 can provide the same (and more) functionality as vim-enhanced. Conflicts make the user experience of installing software incredibly painful. You end up in the dialog hell of "which option do you want" between options which are largely the same. As an end-user, how would I conceivably know the "right" thing to pick between vim-X11 and vim-enhanced? Just say no to conflicts. Jeremy From notting at redhat.com Tue Jan 15 18:52:23 2008 From: notting at redhat.com (Bill Nottingham) Date: Tue, 15 Jan 2008 13:52:23 -0500 Subject: [Fedora-packaging] Should vim-X11 conflict with vim-enhanced ? In-Reply-To: <200801151457.16213.opensource@till.name> References: <478CB7A3.8000206@redhat.com> <200801151450.32656.opensource@till.name> <200801151457.16213.opensource@till.name> Message-ID: <20080115185223.GC9082@nostromo.devel.redhat.com> Till Maas (opensource at till.name) said: > On Tue January 15 2008, Till Maas wrote: > > On Tue January 15 2008, Karsten Hopp wrote: > > > I agree with the /usr/bin/vim stuff, but I think a better solution would > > > be to add a conflict between vim-X11 and vim-enhanced. vim-enhanced is > > > only of use on systems without X11/gtk. On all other systems vim-X11 can > > > provide the same (and more) functionality as vim-enhanced. > > > > Ah, the only possible problem I can think of would be that an "update" from > > vim-enhanced to vim-X11 may not be possible. It should be possbile to do > > Using alternatives would make it easier for users in another case, too. When > someone wants to remove X11 from a default Fedora install ans still keep his > favourite editor. Then one could install both vim-X11 and vim-enhanced and > after removing X11, vim-enhanced would be still there. Define 'X11'. You can remove the servers just fine. Bill From opensource at till.name Tue Jan 15 20:31:20 2008 From: opensource at till.name (Till Maas) Date: Tue, 15 Jan 2008 21:31:20 +0100 Subject: [Fedora-packaging] Should vim-X11 conflict with vim-enhanced ? In-Reply-To: <20080115185223.GC9082@nostromo.devel.redhat.com> References: <478CB7A3.8000206@redhat.com> <200801151457.16213.opensource@till.name> <20080115185223.GC9082@nostromo.devel.redhat.com> Message-ID: <200801152131.21470.opensource@till.name> On Tue January 15 2008, Bill Nottingham wrote: > Till Maas (opensource at till.name) said: > > On Tue January 15 2008, Till Maas wrote: > > > On Tue January 15 2008, Karsten Hopp wrote: > > > > I agree with the /usr/bin/vim stuff, but I think a better solution > > > > would be to add a conflict between vim-X11 and vim-enhanced. > > > > vim-enhanced is only of use on systems without X11/gtk. On all other > > > > systems vim-X11 can provide the same (and more) functionality as > > > > vim-enhanced. > > > > > > Ah, the only possible problem I can think of would be that an "update" > > > from vim-enhanced to vim-X11 may not be possible. It should be possbile > > > to do > > > > Using alternatives would make it easier for users in another case, too. > > When someone wants to remove X11 from a default Fedora install ans still > > keep his favourite editor. Then one could install both vim-X11 and > > vim-enhanced and after removing X11, vim-enhanced would be still there. > > Define 'X11'. You can remove the servers just fine. The X11 that gives the vim-X11 package its name. To be more precise, I meant with X11 every package that provides a requirement for vim-X11, that vim-enhanced does not have. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From notting at redhat.com Tue Jan 15 20:42:38 2008 From: notting at redhat.com (Bill Nottingham) Date: Tue, 15 Jan 2008 15:42:38 -0500 Subject: [Fedora-packaging] Should vim-X11 conflict with vim-enhanced ? In-Reply-To: <200801152131.21470.opensource@till.name> References: <478CB7A3.8000206@redhat.com> <200801151457.16213.opensource@till.name> <20080115185223.GC9082@nostromo.devel.redhat.com> <200801152131.21470.opensource@till.name> Message-ID: <20080115204238.GA21991@nostromo.devel.redhat.com> Till Maas (opensource at till.name) said: > > Define 'X11'. You can remove the servers just fine. > > The X11 that gives the vim-X11 package its name. To be more precise, I meant > with X11 every package that provides a requirement for vim-X11, that > vim-enhanced does not have. I just don't see what having a separate package *just* for that gains you, especially with the complicated lengths suggested in this thread to maintain it? (alternatives is never the answer...) Bill From opensource at till.name Tue Jan 15 21:14:42 2008 From: opensource at till.name (Till Maas) Date: Tue, 15 Jan 2008 22:14:42 +0100 Subject: [Fedora-packaging] Should vim-X11 conflict with vim-enhanced ? In-Reply-To: <20080115204238.GA21991@nostromo.devel.redhat.com> References: <478CB7A3.8000206@redhat.com> <200801152131.21470.opensource@till.name> <20080115204238.GA21991@nostromo.devel.redhat.com> Message-ID: <200801152214.42820.opensource@till.name> On Tue January 15 2008, Bill Nottingham wrote: > Till Maas (opensource at till.name) said: > > > Define 'X11'. You can remove the servers just fine. > > > > The X11 that gives the vim-X11 package its name. To be more precise, I > > meant with X11 every package that provides a requirement for vim-X11, > > that vim-enhanced does not have. > > I just don't see what having a separate package *just* for that gains you, > especially with the complicated lengths suggested in this thread to > maintain it? (alternatives is never the answer...) I do not know, whether or not seperating vim-X11 and vim-enhanced is worth it. This is only what is currently the case. All I want to achive is that the /usr/bin/gvim binary from vim-X11 will have symlinks with the names {vim,vimdiff,ex,view,rview,rvim,vimtutor} in /usr/bin. So now there are three ways to do it: 1) use Conflicts 2) use alternatives 3) use the binary from vim-X11 in vim-enhanced instead Is there an easy way to compare the amount of packages that need to be installed for vim-X11 but do not need to be installed for vim-enhanced? Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From rdieter at math.unl.edu Tue Jan 15 21:20:48 2008 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 15 Jan 2008 15:20:48 -0600 Subject: [Fedora-packaging] Should vim-X11 conflict with vim-enhanced ? In-Reply-To: <200801152214.42820.opensource@till.name> References: <478CB7A3.8000206@redhat.com> <200801152131.21470.opensource@till.name> <20080115204238.GA21991@nostromo.devel.redhat.com> <200801152214.42820.opensource@till.name> Message-ID: <478D23B0.3090508@math.unl.edu> Till Maas wrote: > I do not know, whether or not seperating vim-X11 and vim-enhanced is worth it. > This is only what is currently the case. All I want to achive is that > the /usr/bin/gvim binary from vim-X11 will have symlinks with the names > {vim,vimdiff,ex,view,rview,rvim,vimtutor} in /usr/bin. So now there are three > ways to do it: > > 1) use Conflicts > 2) use alternatives > 3) use the binary from vim-X11 in vim-enhanced instead And 1 really isn't an option. fedora ninjas will find you in your sleep... -- Rex From mr.ecik at gmail.com Tue Jan 15 21:23:45 2008 From: mr.ecik at gmail.com (=?ISO-8859-2?Q?Micha=B3_Bentkowski?=) Date: Tue, 15 Jan 2008 22:23:45 +0100 Subject: [Fedora-packaging] Should vim-X11 conflict with vim-enhanced ? In-Reply-To: <200801152214.42820.opensource@till.name> References: <478CB7A3.8000206@redhat.com> <200801152131.21470.opensource@till.name> <20080115204238.GA21991@nostromo.devel.redhat.com> <200801152214.42820.opensource@till.name> Message-ID: <668bb39a0801151323s17a720c5jc69d6db1c73d55e6@mail.gmail.com> 2008/1/15, Till Maas : > Is there an easy way to compare the amount of packages that need to be > installed for vim-X11 but do not need to be installed for vim-enhanced? > Here's the list of packages that are required by vim-X11 and NOT required by vim-enhanced: atk-1.20.0-1.fc8.x86_64 cairo-1.4.12-1.fc8.x86_64 glib2-2.14.4-1.fc8.x86_64 gtk2-2.12.3-3.fc8.i386 gtk2-2.12.3-3.fc8.x86_64 libICE-1.0.4-2.fc8.x86_64 libSM-1.0.2-4.fc8.x86_64 libX11-1.1.3-4.fc8.x86_64 libXt-1.0.4-3.fc8.x86_64 libattr-2.4.38-2.fc8.i386 libattr-2.4.38-2.fc8.x86_64 pango-1.18.3-1.fc8.x86_64 -- Micha? Bentkowski mr.ecik at gmail.com From notting at redhat.com Tue Jan 15 21:27:46 2008 From: notting at redhat.com (Bill Nottingham) Date: Tue, 15 Jan 2008 16:27:46 -0500 Subject: [Fedora-packaging] Should vim-X11 conflict with vim-enhanced ? In-Reply-To: <668bb39a0801151323s17a720c5jc69d6db1c73d55e6@mail.gmail.com> References: <478CB7A3.8000206@redhat.com> <200801152131.21470.opensource@till.name> <20080115204238.GA21991@nostromo.devel.redhat.com> <200801152214.42820.opensource@till.name> <668bb39a0801151323s17a720c5jc69d6db1c73d55e6@mail.gmail.com> Message-ID: <20080115212746.GC22768@nostromo.devel.redhat.com> Micha? Bentkowski (mr.ecik at gmail.com) said: > 2008/1/15, Till Maas : > > Is there an easy way to compare the amount of packages that need to be > > installed for vim-X11 but do not need to be installed for vim-enhanced? > > > > Here's the list of packages that are required by vim-X11 and NOT > required by vim-enhanced: > > atk-1.20.0-1.fc8.x86_64 > cairo-1.4.12-1.fc8.x86_64 > glib2-2.14.4-1.fc8.x86_64 > gtk2-2.12.3-3.fc8.i386 > gtk2-2.12.3-3.fc8.x86_64 > libICE-1.0.4-2.fc8.x86_64 > libSM-1.0.2-4.fc8.x86_64 > libX11-1.1.3-4.fc8.x86_64 > libXt-1.0.4-3.fc8.x86_64 > libattr-2.4.38-2.fc8.i386 > libattr-2.4.38-2.fc8.x86_64 > pango-1.18.3-1.fc8.x86_64 If you extrapolate that out to their deps, you get: atk-1.21.5-1.fc9 cairo-1.5.4-1.fc9 cups-libs-1.3.5-1.fc9 fontconfig-2.5.0-1.fc9 freetype-2.3.5-3.fc8 gamin-0.1.9-4.fc8 glib2-2.15.2-1.fc9 gnutls-2.0.4-1.fc9 gtk2-2.12.5-1.fc9 hicolor-icon-theme-0.10-4 libgcrypt-1.4.0-1 libgpg-error-1.6-1 libICE-1.0.4-2.fc8 libjpeg-6b-40.fc9 libpng-1.2.22-1.fc8 libSM-1.0.2-4.fc8 libthai-0.1.9-2.fc9 libtiff-3.8.2-9.fc8 libX11-1.1.3-4.fc8 libXau-1.0.3-3.fc8 libxcb-1.1-1.fc9 libXcomposite-0.4.0-3.fc8 libXcursor-1.1.9-1.fc8 libXdmcp-1.0.2-4.fc8 libXext-1.0.1-5.fc9 libXfixes-4.0.3-2.fc8 libXft-2.1.12-3.fc8 libXi-1.1.3-3.fc9 libXinerama-1.0.2-3.fc8 libXrandr-1.2.2-2.fc9 libXrender-0.9.4-2.fc9 libXt-1.0.4-4.fc9 pango-1.19.2-1.fc9 pixman-0.9.6-3.fc9 xorg-x11-filesystem-7.1-2.fc6 34 packages. 54MB on disk (x86_64). Bill From opensource at till.name Tue Jan 15 21:48:20 2008 From: opensource at till.name (Till Maas) Date: Tue, 15 Jan 2008 22:48:20 +0100 Subject: [Fedora-packaging] Should vim-X11 conflict with vim-enhanced ? In-Reply-To: <20080115212746.GC22768@nostromo.devel.redhat.com> References: <478CB7A3.8000206@redhat.com> <668bb39a0801151323s17a720c5jc69d6db1c73d55e6@mail.gmail.com> <20080115212746.GC22768@nostromo.devel.redhat.com> Message-ID: <200801152248.22038.opensource@till.name> On Tue January 15 2008, Bill Nottingham wrote: > Micha? Bentkowski (mr.ecik at gmail.com) said: > > 2008/1/15, Till Maas : > > > Is there an easy way to compare the amount of packages that need to be > > > installed for vim-X11 but do not need to be installed for vim-enhanced? > > > > Here's the list of packages that are required by vim-X11 and NOT > > required by vim-enhanced: [...] > If you extrapolate that out to their deps, you get: [...] > 34 packages. 54MB on disk (x86_64). How did you generate these lists? The only way I found, was to compare the output of "fakeroot yum --installroot=/tmp/foo install $package" (after hardcoding releasever=7 in /usr/lib/python2.5/site-packages/yum/config.py btw.). Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From notting at redhat.com Tue Jan 15 22:03:46 2008 From: notting at redhat.com (Bill Nottingham) Date: Tue, 15 Jan 2008 17:03:46 -0500 Subject: [Fedora-packaging] Should vim-X11 conflict with vim-enhanced ? In-Reply-To: <200801152248.22038.opensource@till.name> References: <478CB7A3.8000206@redhat.com> <668bb39a0801151323s17a720c5jc69d6db1c73d55e6@mail.gmail.com> <20080115212746.GC22768@nostromo.devel.redhat.com> <200801152248.22038.opensource@till.name> Message-ID: <20080115220346.GB26378@nostromo.devel.redhat.com> Till Maas (opensource at till.name) said: > > If you extrapolate that out to their deps, you get: > > [...] > > > 34 packages. 54MB on disk (x86_64). > > How did you generate these lists? The only way I found, was to compare the > output of "fakeroot yum --installroot=/tmp/foo install $package" (after > hardcoding releasever=7 in /usr/lib/python2.5/site-packages/yum/config.py > btw.). mkdir /tmp/whererver, yum --installroot /tmp/wherever install vim-X11. Bill From ville.skytta at iki.fi Tue Jan 15 22:06:40 2008 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Wed, 16 Jan 2008 00:06:40 +0200 Subject: [Fedora-packaging] Should vim-X11 conflict with vim-enhanced ? In-Reply-To: <200801152214.42820.opensource@till.name> References: <478CB7A3.8000206@redhat.com> <20080115204238.GA21991@nostromo.devel.redhat.com> <200801152214.42820.opensource@till.name> Message-ID: <200801160006.40936.ville.skytta@iki.fi> On Tuesday 15 January 2008, Till Maas wrote: > > I do not know, whether or not seperating vim-X11 and vim-enhanced is worth > it. This is only what is currently the case. All I want to achive is that > the /usr/bin/gvim binary from vim-X11 will have symlinks with the names > {vim,vimdiff,ex,view,rview,rvim,vimtutor} in /usr/bin. So now there are > three ways to do it: > > 1) use Conflicts > 2) use alternatives > 3) use the binary from vim-X11 in vim-enhanced instead I wouldn't like any of the above. But didn't someone already suggest: 4) Use wrapper scripts in /usr/bin/{vim,vimdiff,ex,view,rview,rvim,vimtutor} that first look for the -X11 executables, then -enhanced. Maybe something like: #!/bin/sh exe=${0##*/} vim=/usr/libexec/vim/enhanced/$exe if [ -x /usr/libexec/vim/X11/$exe ] ; then # maybe test "-n $DISPLAY" here too vim=/usr/libexec/vim/X11/$exe fi exec $vim "$@" ...and ship it in vim-enhanced, and make vim-X11 require it (and obviously set up so that the desired executables/links are found in /usr/libexec/vim/{enhanced,X11})? From mr.ecik at gmail.com Tue Jan 15 23:53:26 2008 From: mr.ecik at gmail.com (=?ISO-8859-2?Q?Micha=B3_Bentkowski?=) Date: Wed, 16 Jan 2008 00:53:26 +0100 Subject: [Fedora-packaging] Should vim-X11 conflict with vim-enhanced ? In-Reply-To: <200801160006.40936.ville.skytta@iki.fi> References: <478CB7A3.8000206@redhat.com> <20080115204238.GA21991@nostromo.devel.redhat.com> <200801152214.42820.opensource@till.name> <200801160006.40936.ville.skytta@iki.fi> Message-ID: <668bb39a0801151553r51417c13u644c85e2c0c742ab@mail.gmail.com> 2008/1/15, Ville Skytt? : > I wouldn't like any of the above. But didn't someone already suggest: > > 4) Use wrapper scripts in /usr/bin/{vim,vimdiff,ex,view,rview,rvim,vimtutor} > that first look for the -X11 executables, then -enhanced. Maybe something > like: > > #!/bin/sh > exe=${0##*/} > vim=/usr/libexec/vim/enhanced/$exe > if [ -x /usr/libexec/vim/X11/$exe ] ; then # maybe test "-n $DISPLAY" here too > vim=/usr/libexec/vim/X11/$exe > fi > exec $vim "$@" > > ...and ship it in vim-enhanced, and make vim-X11 require it (and obviously set > up so that the desired executables/links are found > in /usr/libexec/vim/{enhanced,X11})? > Yes, that's what I suggested and it still seems to me it's the best solution. Still thinking though whether there should be a way to choose one's preferred vim when both are installed. For some reasons (no idea what reasons that can be) user may want to prefer -enhanced to -X11. -- Micha? Bentkowski mr.ecik at gmail.com From opensource at till.name Wed Jan 16 09:11:47 2008 From: opensource at till.name (Till Maas) Date: Wed, 16 Jan 2008 10:11:47 +0100 Subject: [Fedora-packaging] Should vim-X11 conflict with vim-enhanced ? In-Reply-To: <200801160006.40936.ville.skytta@iki.fi> References: <478CB7A3.8000206@redhat.com> <200801152214.42820.opensource@till.name> <200801160006.40936.ville.skytta@iki.fi> Message-ID: <200801161011.52112.opensource@till.name> On Tue January 15 2008, Ville Skytt? wrote: > 4) Use wrapper scripts in > /usr/bin/{vim,vimdiff,ex,view,rview,rvim,vimtutor} that first look for the > -X11 executables, then -enhanced. Maybe something like: Why is this better than using alternatives? Using alternatives recommended in http://fedoraproject.org/wiki/Packaging/Conflicts#head-f0b97bf1035a16427332c84bfef0f2b63f1c3223 (Binary Name Conflicts). Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From pertusus at free.fr Wed Jan 16 09:16:07 2008 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 16 Jan 2008 10:16:07 +0100 Subject: [Fedora-packaging] Should vim-X11 conflict with vim-enhanced ? In-Reply-To: <200801161011.52112.opensource@till.name> References: <478CB7A3.8000206@redhat.com> <200801152214.42820.opensource@till.name> <200801160006.40936.ville.skytta@iki.fi> <200801161011.52112.opensource@till.name> Message-ID: <20080116091607.GB2491@free.fr> On Wed, Jan 16, 2008 at 10:11:47AM +0100, Till Maas wrote: > On Tue January 15 2008, Ville Skytt? wrote: > > > 4) Use wrapper scripts in > > /usr/bin/{vim,vimdiff,ex,view,rview,rvim,vimtutor} that first look for the > > -X11 executables, then -enhanced. Maybe something like: > > Why is this better than using alternatives? Using alternatives recommended in > http://fedoraproject.org/wiki/Packaging/Conflicts#head-f0b97bf1035a16427332c84bfef0f2b63f1c3223 > (Binary Name Conflicts). This is only a suggestion, and it is right like that, it is better to avoid guidelines on that and let the packager choose what he prefers in such cases. -- Pat From geoff at programmer-monk.net Wed Jan 16 08:33:19 2008 From: geoff at programmer-monk.net (Geoff Reedy) Date: Wed, 16 Jan 2008 01:33:19 -0700 Subject: [Fedora-packaging] bootstrapping for scala Message-ID: <20080116083318.GA18286@programmer-monk.net> I am working on a package (BZ#426867) for scala (http://www.scala-lang.org) that requires bootstrapping with a previously compiled toolchain. According to the Packaging Guidelines this package requires approval from the Packaging Committee for inclusion in fedora since pre-built components are require to build the package from source. The Packaging/Committee page on the wiki leads me to believe this is the appropriate forum to do so. What steps need to happen to get this approval? From tcallawa at redhat.com Wed Jan 16 12:33:56 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 16 Jan 2008 07:33:56 -0500 Subject: [Fedora-packaging] bootstrapping for scala In-Reply-To: <20080116083318.GA18286@programmer-monk.net> References: <20080116083318.GA18286@programmer-monk.net> Message-ID: <1200486836.25467.12.camel@localhost.localdomain> On Wed, 2008-01-16 at 01:33 -0700, Geoff Reedy wrote: > I am working on a package (BZ#426867) for scala > (http://www.scala-lang.org) that requires bootstrapping with a > previously compiled toolchain. According to the Packaging Guidelines > this package requires approval from the Packaging Committee for > inclusion in fedora since pre-built components are require to build the > package from source. The Packaging/Committee page on the wiki leads me > to believe this is the appropriate forum to do so. What steps need to > happen to get this approval? Does the scala package cleanly rebuild from source after it is bootstrapped? It would be nice to see the SRPM before we signed off on this. ~spot From geoff at programmer-monk.net Wed Jan 16 14:43:11 2008 From: geoff at programmer-monk.net (Geoff Reedy) Date: Wed, 16 Jan 2008 09:43:11 -0500 Subject: [Fedora-packaging] bootstrapping for scala In-Reply-To: <1200486836.25467.12.camel@localhost.localdomain> References: <20080116083318.GA18286@programmer-monk.net> <1200486836.25467.12.camel@localhost.localdomain> Message-ID: <20080116144311.GA19703@programmer-monk.net> On Wed, Jan 16, 2008 at 07:33:56AM -0500, Tom spot Callaway said > Does the scala package cleanly rebuild from source after it is > bootstrapped? Yes. The build procedure for scala uses multiple phases to ensure that the code cleanly bootstraps. The sequence is like this: bootstrap (starr) -> locker -> quick -> strap The results of the quick phase are packaged. The results of the strap phase are compared byte-for-byte with the resuts of the quick phase to ensure that the compiler is stable. For more details, see http://tinyurl.com/3e3l55 which is the README of the source distribution. It describes in detail the process used to build scala. I use this process unaltered when building the RPM. > It would be nice to see the SRPM before we signed off on this. Sure, you can check out the review request in progress at https://bugzilla.redhat.com/show_bug.cgi?id=426867 From rpjday at crashcourse.ca Wed Jan 16 18:10:42 2008 From: rpjday at crashcourse.ca (Robert P. J. Day) Date: Wed, 16 Jan 2008 13:10:42 -0500 (EST) Subject: [Fedora-packaging] Possible restructuring of docbook-related packages? Message-ID: i'm wondering if there might be some benefit to repackaging some of the docbook-related packages. first, there are the two "utils" packages: docbook-utils docbook-utils-pdf it seems awkward to have one package advertising itself as "utils", only for some of those utils to be broken off and put in a more specific package, which wouldn't be obvious to anyone who simply saw "docbook-utils" and figured that's all he needed. more to the point, that second package contains additional utilities anyway: $ rpm -ql docbook-utils-pdf /usr/bin/db2dvi /usr/bin/db2pdf /usr/bin/db2ps /usr/bin/docbook2dvi /usr/bin/docbook2pdf /usr/bin/docbook2ps /usr/share/man/man1/db2pdf.1.gz /usr/share/man/man1/docbook2dvi.1.gz /usr/share/man/man1/docbook2pdf.1.gz /usr/share/man/man1/docbook2ps.1.gz $ so there's DVI and PS stuff in there as well -- certainly not obvious from the package name. is there some reason this can's just be all in one package? also, is there any clean way to separate the SGML and XML stuff in the docbook-dtds package? even the XML DTDs for docbook are under /usr/share/sgml. does XML processing still require underlying functionality? if not, is there no way to separate all of that into SGML versus XML content, and perhaps load only the XML-related packages if that's all one needs? rday -- ======================================================================== Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA Home page: http://crashcourse.ca Fedora Cookbook: http://crashcourse.ca/wiki/index.php/Fedora_Cookbook ======================================================================== From tcallawa at redhat.com Wed Jan 16 18:55:30 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 16 Jan 2008 13:55:30 -0500 Subject: [Fedora-packaging] Possible restructuring of docbook-related packages? In-Reply-To: References: Message-ID: <1200509730.11327.0.camel@localhost.localdomain> On Wed, 2008-01-16 at 13:10 -0500, Robert P. J. Day wrote: > i'm wondering if there might be some benefit to repackaging some of > the docbook-related packages. > > first, there are the two "utils" packages: > > docbook-utils > docbook-utils-pdf We're not mandating this split. You should open a bug against this package and see if the maintainer is willing to stop doing it. ~spot From rpjday at crashcourse.ca Wed Jan 16 18:58:31 2008 From: rpjday at crashcourse.ca (Robert P. J. Day) Date: Wed, 16 Jan 2008 13:58:31 -0500 (EST) Subject: [Fedora-packaging] Possible restructuring of docbook-related packages? In-Reply-To: <1200509730.11327.0.camel@localhost.localdomain> References: <1200509730.11327.0.camel@localhost.localdomain> Message-ID: On Wed, 16 Jan 2008, Tom "spot" Callaway wrote: > > On Wed, 2008-01-16 at 13:10 -0500, Robert P. J. Day wrote: > > i'm wondering if there might be some benefit to repackaging some of > > the docbook-related packages. > > > > first, there are the two "utils" packages: > > > > docbook-utils > > docbook-utils-pdf > > We're not mandating this split. You should open a bug against this > package and see if the maintainer is willing to stop doing it. ok, just so long as there was no obvious rationale about that split that i was overlooking. thanks. rday -- ======================================================================== Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA Home page: http://crashcourse.ca Fedora Cookbook: http://crashcourse.ca/wiki/index.php/Fedora_Cookbook ======================================================================== From green at redhat.com Fri Jan 18 19:46:50 2008 From: green at redhat.com (Anthony Green) Date: Fri, 18 Jan 2008 11:46:50 -0800 Subject: [Fedora-packaging] Lisp packaging draft Message-ID: <4791022A.2080103@redhat.com> For your review... http://fedoraproject.org/wiki/PackagingDrafts/Lisp AG From a.badger at gmail.com Sat Jan 19 01:42:33 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 18 Jan 2008 17:42:33 -0800 Subject: [Fedora-packaging] Lisp packaging draft In-Reply-To: <4791022A.2080103@redhat.com> References: <4791022A.2080103@redhat.com> Message-ID: <47915589.6080205@gmail.com> Anthony Green wrote: > For your review... > > http://fedoraproject.org/wiki/PackagingDrafts/Lisp > Cool. Thanks for taking charge of this. A bit of feedback: High level: * The guidelines need to be written so that a reviewer can effectively use them to decide if a package is conforming. This means that you might have to explain things that the packager will understand (since they come from a lisp background) but the reviewer might not. Specifics: * What is adsf? Is it a format or a utility? If the former, how do we get libraries into that format, if the latter, how and when do we invoke it? * What differentiates a lisp library from another piece of lisp? * How do the various register/unregister commands translate to %post/%preun scriptlets? * What package are the register/unregister commands provided in? * What package provides /usr/lib/common-lisp? * What package provides /usr/share/common-lisp? * Why do we use /usr/lib/common-lisp instead of /usr/libexec/common-lisp? * What are fasls? * What provides /var/cache/common-lisp-controller? * What is being created in /var/cache/common-lisp-controller//// ? * What creates those directories? Who creates those directories? * You mention compiling of libraries. Where do those get dropped on the system? What are the commands to generate those during %build? * It looks like some of the Debian Guidelines aren't going necessary for Fedora... for instance:: {{{ - register-common-lisp-source: does nothing }}} In Fedora, we try to avoid doing things that are no-ops. I'm sure there will be more questions after these are answered and incorporated into your draft :-) -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From pertusus at free.fr Mon Jan 21 13:54:13 2008 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 21 Jan 2008 14:54:13 +0100 Subject: [Fedora-packaging] tex/latex doc install location In-Reply-To: <200801151625.49822.jamatos@fc.up.pt> References: <20080115160328.GA2619@free.fr> <200801151625.49822.jamatos@fc.up.pt> Message-ID: <20080121135413.GC3465@free.fr> On Tue, Jan 15, 2008 at 04:25:49PM +0000, Jos? Matos wrote: > > > > In fedora should we use this system and put the doc files below > > /usr/share/texmf/doc/ or use %doc? > > Notice that this is in line with other languages, the documentation for R > packages (as an example) in under the R tree. I would like to favour the > texmf tree as the natural packaging place of latex documentation. Anybody else has an advice? -- Pat From jonathan.underwood at gmail.com Mon Jan 21 15:03:24 2008 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Mon, 21 Jan 2008 15:03:24 +0000 Subject: [Fedora-packaging] tex/latex doc install location In-Reply-To: <20080121135413.GC3465@free.fr> References: <20080115160328.GA2619@free.fr> <200801151625.49822.jamatos@fc.up.pt> <20080121135413.GC3465@free.fr> Message-ID: <645d17210801210703n5415c426ue4c2eca1c344cde9@mail.gmail.com> On 21/01/2008, Patrice Dumas wrote: > On Tue, Jan 15, 2008 at 04:25:49PM +0000, Jos? Matos wrote: > > > > > > In fedora should we use this system and put the doc files below > > > /usr/share/texmf/doc/ or use %doc? > > > > Notice that this is in line with other languages, the documentation for R > > packages (as an example) in under the R tree. I would like to favour the > > texmf tree as the natural packaging place of latex documentation. > > Anybody else has an advice? > My feeling is we want to make it as easy as possible for users to find the docs they need. Adding lots of different locations really is counter to that desire, and we should strive to keep docs in one location. However If we're going down the /usr/share/texmf/doc route, I guess we could just have a symlink from /usr/share/doc/tex to /usr/share/texmf/doc as a best of both worlds fix. j. From a.badger at gmail.com Mon Jan 21 16:12:32 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 21 Jan 2008 08:12:32 -0800 Subject: [Fedora-packaging] tex/latex doc install location In-Reply-To: <645d17210801210703n5415c426ue4c2eca1c344cde9@mail.gmail.com> References: <20080115160328.GA2619@free.fr> <200801151625.49822.jamatos@fc.up.pt> <20080121135413.GC3465@free.fr> <645d17210801210703n5415c426ue4c2eca1c344cde9@mail.gmail.com> Message-ID: <4794C470.7040906@gmail.com> Jonathan Underwood wrote: > On 21/01/2008, Patrice Dumas wrote: >> On Tue, Jan 15, 2008 at 04:25:49PM +0000, Jos? Matos wrote: >>>> In fedora should we use this system and put the doc files below >>>> /usr/share/texmf/doc/ or use %doc? >>> Notice that this is in line with other languages, the documentation for R >>> packages (as an example) in under the R tree. I would like to favour the >>> texmf tree as the natural packaging place of latex documentation. >> Anybody else has an advice? >> > > My feeling is we want to make it as easy as possible for users to find > the docs they need. Adding lots of different locations really is > counter to that desire, and we should strive to keep docs in one > location. > I also favor this reasoning but I know that we presently have other examples of documentation following a different upstream convention (For instance, ruby gems). In addition, this case may be more like man, info, or ghelp than like ruby gems. One thing I'd like to ask about from the original post:: In tex/latex bundled in fedora (I guess it comes from tetex and it is now in texlive) there is a simple system to view documentation. What is this "simple system"? We do have a rule that nothing marked as %doc should break an application if it is not present on the system. If this help system is integrated into applications (like ghelp for gnome) then this would count under that rule. If it's more like man and info pages then we'd want them to be marked as doc even if they are located somewhere other than %{_docdir}. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From jlaska at redhat.com Mon Jan 21 17:03:50 2008 From: jlaska at redhat.com (James Laska) Date: Mon, 21 Jan 2008 12:03:50 -0500 Subject: [Fedora-packaging] Conditionally building a sub-package? Message-ID: <4794D076.90706@redhat.com> Greetings, Looking for a recommendation or thoughts around resolving a EPEL deps issue noted in bug#429479. The snake package contains a server and client utility. The client is intended to run on distribution from FC3 and newer. The server must be run in an environment that includes pykickstart >= 1.1. At this time, this means anything newer than FC7. In bug#429479 it was discussed that conditionally building the sub-package on environments < FC7 was a good method to avoid EPEL deps issues. My plan was to implement something like the following: %define has_pykickstart_version %{python -c "import pykickstart.version;" 2>/dev/null && echo "1" || echo "0"} %if %{has_pykickstart_version} ... %endif Do folks have any experience or recommendations in the realm of conditional sub-package builds? Thanks, James -- ========================================== James Laska -- jlaska at redhat.com Quality Engineering -- Red Hat, Inc. ========================================== From bruno at postle.net Mon Jan 21 17:08:56 2008 From: bruno at postle.net (Bruno Postle) Date: Mon, 21 Jan 2008 17:08:56 +0000 Subject: [Fedora-packaging] Reviewing an existing package with major changes Message-ID: <20080121170855.GE32247@postle.net> Not sure if this is the right list for this question. Sorry I can't find anything about this in the wiki. I'm planning on updating the hugin package, but there have been so many changes that the spec file is largely rewritten - I've split out a hugin-base sub-package, the build system has changed to cmake, there are now .so libraries etc... Should I submit a bugzilla review request even though this is an 'old' package? -- Bruno From ivazqueznet at gmail.com Mon Jan 21 17:34:46 2008 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Mon, 21 Jan 2008 12:34:46 -0500 Subject: [Fedora-packaging] Reviewing an existing package with major changes In-Reply-To: <20080121170855.GE32247@postle.net> References: <20080121170855.GE32247@postle.net> Message-ID: <1200936887.11577.3.camel@ignacio.lan> On Mon, 2008-01-21 at 17:08 +0000, Bruno Postle wrote: > Not sure if this is the right list for this question. Sorry I can't > find anything about this in the wiki. > > I'm planning on updating the hugin package, but there have been so > many changes that the spec file is largely rewritten - I've split > out a hugin-base sub-package, the build system has changed to cmake, > there are now .so libraries etc... > > Should I submit a bugzilla review request even though this is an > 'old' package? If you can make it so that a user can type "yum update" to update the packages and still use the application the same way as before then I don't see a need for a re-review. -- Ignacio Vazquez-Abrams PLEASE don't CC me; I'm already subscribed -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Mon Jan 21 17:52:22 2008 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 21 Jan 2008 12:52:22 -0500 Subject: [Fedora-packaging] Conditionally building a sub-package? In-Reply-To: <4794D076.90706@redhat.com> References: <4794D076.90706@redhat.com> Message-ID: <20080121125222.7e6ff328@redhat.com> On Mon, 21 Jan 2008 12:03:50 -0500 James Laska wrote: > Do folks have any experience or recommendations in the realm of > conditional sub-package builds? Instead of testing python like that, you could just use the dist tag and turn that off unless you're in a sufficiently high enough Fedora or RHEL. http://fedoraproject.org/wiki/Packaging/DistTag?#head-1c550109af0705ccb71329619b99428af2fd3e25 -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Mon Jan 21 17:54:54 2008 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 21 Jan 2008 12:54:54 -0500 Subject: [Fedora-packaging] Reviewing an existing package with major changes In-Reply-To: <20080121170855.GE32247@postle.net> References: <20080121170855.GE32247@postle.net> Message-ID: <20080121125454.09903518@redhat.com> On Mon, 21 Jan 2008 17:08:56 +0000 Bruno Postle wrote: > I'm planning on updating the hugin package, but there have been so > many changes that the spec file is largely rewritten - I've split > out a hugin-base sub-package, the build system has changed to cmake, > there are now .so libraries etc... > > Should I submit a bugzilla review request even though this is an > 'old' package? At any time you want to have a fresh review done of your package you should feel free to set the flag accordingly and ask for a new review. We only currently require a review when bringing a new package in, but we shouldn't stop folks who want to get a fresh look at their package. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jlaska at redhat.com Mon Jan 21 18:06:58 2008 From: jlaska at redhat.com (James Laska) Date: Mon, 21 Jan 2008 13:06:58 -0500 Subject: [Fedora-packaging] Conditionally building a sub-package? In-Reply-To: <20080121125222.7e6ff328@redhat.com> References: <4794D076.90706@redhat.com> <20080121125222.7e6ff328@redhat.com> Message-ID: <4794DF42.9020609@redhat.com> Jesse Keating wrote: > On Mon, 21 Jan 2008 12:03:50 -0500 > James Laska wrote: > >> Do folks have any experience or recommendations in the realm of >> conditional sub-package builds? > > Instead of testing python like that, you could just use the dist tag > and turn that off unless you're in a sufficiently high enough Fedora or > RHEL. > > http://fedoraproject.org/wiki/Packaging/DistTag?#head-1c550109af0705ccb71329619b99428af2fd3e25 Thanks for the suggestion! Eeew, I just realized that I'll have to do some additional munging to handle the conditionally unpackaged files now. RPM build errors: Installed (but unpackaged) file(s) found: ... Thanks, James -- ========================================== James Laska -- jlaska at redhat.com Quality Engineering -- Red Hat, Inc. ========================================== From tibbs at math.uh.edu Mon Jan 21 18:07:35 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 21 Jan 2008 12:07:35 -0600 Subject: [Fedora-packaging] tex/latex doc install location In-Reply-To: <20080121135413.GC3465@free.fr> References: <20080115160328.GA2619@free.fr> <200801151625.49822.jamatos@fc.up.pt> <20080121135413.GC3465@free.fr> Message-ID: Just a note that R essentially has an internal documentation browsing system, and as far as I know it has not been our policy to dictate where applications keep their internal help files, even if those files are in standard formats. So perhaps R is not the best example to use here. - J< From foster at in.tum.de Mon Jan 21 19:15:30 2008 From: foster at in.tum.de (Mary Ellen Foster) Date: Mon, 21 Jan 2008 19:15:30 +0000 Subject: [Fedora-packaging] tex/latex doc install location In-Reply-To: <4794C470.7040906@gmail.com> References: <20080115160328.GA2619@free.fr> <200801151625.49822.jamatos@fc.up.pt> <20080121135413.GC3465@free.fr> <645d17210801210703n5415c426ue4c2eca1c344cde9@mail.gmail.com> <4794C470.7040906@gmail.com> Message-ID: On 21/01/2008, Toshio Kuratomi wrote: > One thing I'd like to ask about from the original post:: > In tex/latex bundled in fedora (I guess it comes from tetex and it is > now in texlive) there is a simple system to view documentation. > > What is this "simple system"? We do have a rule that nothing marked as > %doc should break an application if it is not present on the system. If > this help system is integrated into applications (like ghelp for gnome) > then this would count under that rule. If it's more like man and info > pages then we'd want them to be marked as doc even if they are located > somewhere other than %{_docdir}. In theory, to get documentation on any tex package, you type "texdoc ". The system then looks in texmf/tex/doc/ for .{pdf,html,ps,dvi,...} and loads it in the appropriate viewer. This doesn't always work, for example with packages whose documentation isn't named after the package, but that's the theory. More information at http://linux.die.net/man/1/texdoc or http://www.ctan.org/tex-archive/help/Catalogue/entries/texdoc.html MEF -- Dr. Mary Ellen Foster -- http://homepages.inf.ed.ac.uk/mef/ Informatik 6: Robotics and Embedded Systems, Technische Universit?t M?nchen and ICCS, School of Informatics, University of Edinburgh From jnovy at redhat.com Mon Jan 21 19:32:44 2008 From: jnovy at redhat.com (Jindrich Novy) Date: Mon, 21 Jan 2008 20:32:44 +0100 Subject: [Fedora-packaging] tex/latex doc install location In-Reply-To: References: <20080115160328.GA2619@free.fr> <200801151625.49822.jamatos@fc.up.pt> <20080121135413.GC3465@free.fr> <645d17210801210703n5415c426ue4c2eca1c344cde9@mail.gmail.com> <4794C470.7040906@gmail.com> Message-ID: <20080121193243.GA9782@dhcp-lab-186.brq.redhat.com> On Mon, Jan 21, 2008 at 07:15:30PM +0000, Mary Ellen Foster wrote: > On 21/01/2008, Toshio Kuratomi wrote: > > One thing I'd like to ask about from the original post:: > > In tex/latex bundled in fedora (I guess it comes from tetex and it is > > now in texlive) there is a simple system to view documentation. > > > > What is this "simple system"? We do have a rule that nothing marked as > > %doc should break an application if it is not present on the system. If > > this help system is integrated into applications (like ghelp for gnome) > > then this would count under that rule. If it's more like man and info > > pages then we'd want them to be marked as doc even if they are located > > somewhere other than %{_docdir}. > > In theory, to get documentation on any tex package, you type "texdoc > ". The system then looks in texmf/tex/doc/ for > .{pdf,html,ps,dvi,...} and loads it in the appropriate > viewer. > > This doesn't always work, for example with packages whose > documentation isn't named after the package, but that's the theory. > More information at http://linux.die.net/man/1/texdoc or > http://www.ctan.org/tex-archive/help/Catalogue/entries/texdoc.html > There are two tools for browsing documentation actually, texdoc and texdoctk. The both are now packaged in texlive-doc subpackage. The texdoctk provides a nice GUI where one can navigate to a particular part of docs. If we want to move docs anywhere else than to $TEXMFMAIN/doc, we need to rework texdoctk a bit as it expects in its configuration file (texdocrc.defaults) a path to documentation relative to the main texmf tree. It's not worth the effort IMO, as $TEXMFMAIN/doc has always been a directory where to put documentation so more things could break if we change that. Jindrich -- Jindrich Novy http://people.redhat.com/jnovy/ From pertusus at free.fr Mon Jan 21 19:38:48 2008 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 21 Jan 2008 20:38:48 +0100 Subject: [Fedora-packaging] tex/latex doc install location In-Reply-To: <4794C470.7040906@gmail.com> References: <20080115160328.GA2619@free.fr> <200801151625.49822.jamatos@fc.up.pt> <20080121135413.GC3465@free.fr> <645d17210801210703n5415c426ue4c2eca1c344cde9@mail.gmail.com> <4794C470.7040906@gmail.com> Message-ID: <20080121193848.GA3303@free.fr> On Mon, Jan 21, 2008 at 08:12:32AM -0800, Toshio Kuratomi wrote: >> location. >> > I also favor this reasoning but I know that we presently have other > examples of documentation following a different upstream convention (For > instance, ruby gems). In addition, this case may be more like man, info, > or ghelp than like ruby gems. > > One thing I'd like to ask about from the original post:: > In tex/latex bundled in fedora (I guess it comes from tetex and it is > now in texlive) there is a simple system to view documentation. > > What is this "simple system"? We do have a rule that nothing marked as > %doc should break an application if it is not present on the system. If > this help system is integrated into applications (like ghelp for gnome) > then this would count under that rule. If it's more like man and info > pages then we'd want them to be marked as doc even if they are located > somewhere other than %{_docdir}. It is more like info pages (and see the other response for more in-depth explanations...), and should be marked as %doc. And they are rightly marked as %doc in packages that installs them here (texlive, for example). -- Pat From a.badger at gmail.com Mon Jan 21 20:15:55 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 21 Jan 2008 12:15:55 -0800 Subject: [Fedora-packaging] tex/latex doc install location In-Reply-To: <20080121193848.GA3303@free.fr> References: <20080115160328.GA2619@free.fr> <200801151625.49822.jamatos@fc.up.pt> <20080121135413.GC3465@free.fr> <645d17210801210703n5415c426ue4c2eca1c344cde9@mail.gmail.com> <4794C470.7040906@gmail.com> <20080121193848.GA3303@free.fr> Message-ID: <4794FD7B.5040404@gmail.com> Patrice Dumas wrote: > On Mon, Jan 21, 2008 at 08:12:32AM -0800, Toshio Kuratomi wrote: >>> location. >>> >> I also favor this reasoning but I know that we presently have other >> examples of documentation following a different upstream convention (For >> instance, ruby gems). In addition, this case may be more like man, info, >> or ghelp than like ruby gems. >> >> One thing I'd like to ask about from the original post:: >> In tex/latex bundled in fedora (I guess it comes from tetex and it is >> now in texlive) there is a simple system to view documentation. >> >> What is this "simple system"? We do have a rule that nothing marked as >> %doc should break an application if it is not present on the system. If >> this help system is integrated into applications (like ghelp for gnome) >> then this would count under that rule. If it's more like man and info >> pages then we'd want them to be marked as doc even if they are located >> somewhere other than %{_docdir}. > > It is more like info pages (and see the other response for more in-depth > explanations...), and should be marked as %doc. And they are rightly marked > as %doc in packages that installs them here (texlive, for example). > Sounds good. FWIW, I think %{_datadir}/texmf/doc is fine. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From pertusus at free.fr Tue Jan 22 10:56:31 2008 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 22 Jan 2008 11:56:31 +0100 Subject: [Fedora-packaging] help on PreReq and trigges for texinfo Message-ID: <20080122105630.GC2579@free.fr> Hello, In texinfo, for the info subpackage that contains /sbin/install-info, there is: # By making info prereq bash, other packages which have triggers based on # info don't run those triggers until bash is in place as well. This is an # ugly method of doing it (triggers which fire on set intersection would # be better), but it's the best we can do for now. Talk to Erik before # removing this. Prereq: bash I have found http://people.redhat.com/laroche/pyrpm/pyrpm-devel.html which states that triggers are run after %post. So I think that it could be replaced by Requires(post): bash But it also seems that rpm adds automatically a Requires(post): /bin/sh for packages that have a %post. So it even seems to me that this can be entirely dropped. Advices? -- Pat From tibbs at math.uh.edu Tue Jan 22 17:22:59 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 22 Jan 2008 11:22:59 -0600 Subject: [Fedora-packaging] help on PreReq and trigges for texinfo In-Reply-To: <20080122105630.GC2579@free.fr> References: <20080122105630.GC2579@free.fr> Message-ID: >>>>> "PD" == Patrice Dumas writes: PD> But it also seems that rpm adds automatically a Requires(post): PD> /bin/sh for packages that have a %post. Unless you do %post -p to set the interpreter. Honestly I have never been too clear on what the semantics of PreReq: were supposed to have been. My understanding is that in this case it ensures that bash is installed at all times that the info package is installed, which I guess would be emulated by Requires(pre): bash Requires: bash Requires(post): bash and if you have scriptlets without -p then some of these are done automatically. - J< From cheese at nosuchhost.net Wed Jan 23 18:07:33 2008 From: cheese at nosuchhost.net (josef radinger) Date: Wed, 23 Jan 2008 19:07:33 +0100 Subject: [Fedora-packaging] pike packages Message-ID: <1201111653.4620.34.camel@cheese.daheim> Hello, I currently work on creating pike-packages. the next lines of text are shameless ripped from http://pike.ida.liu.se/about/ Pike is a general purpose programming language, which means that you can put it to use for almost any task. Its application domain spans anything from the world of the Net to the world of multimedia applications, or environments where your shell could use some spicy text processing or system administration tools. Your imagination sets the limit, but Pike will probably extend it far beyond what you previously considered within reach. the - in my opinion - main application using pike is caudium/roxen, which is a cool webserver, i personally use since years and love to use it. creating caudium-packages would be my next step. to be honest, there are problems too: there are not enough developers to keep up with new developments, but theses days this seems to improve and would improve further, if fedora-users would join in as deveopers AND as endusers (without the obstacle to compile pike). I would need someone willing to review the pike-packages. yours josef ps.: i did not send a link to the packages, as those are currently somewhat rough and i need to find some time to work around the biggestr problems, before showing them to the public. pps.: i wanted to send this after the packages where ready, but i never got to that point, and now i have to finish them, as hopefully i get some response from the list. ppps.: http://www.caudium.net is currently under rework From tibbs at math.uh.edu Thu Jan 24 01:51:37 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 23 Jan 2008 19:51:37 -0600 Subject: [Fedora-packaging] Re: pike packages In-Reply-To: <1201111653.4620.34.camel@cheese.daheim> References: <1201111653.4620.34.camel@cheese.daheim> Message-ID: >>>>> "jr" == josef radinger writes: jr> I would need someone willing to review the pike-packages. All I can say is, first submit pike itself and get it reviewed. If you have many library packages which will need review, submit a couple of them along with a set of packaging guidelines so that the packaging committee can help you to get them to an acceptable state. Then start submitting the rest of your addon packages according to those guidelines. Honestly, there is very little chance that anyone in the pool of reviewers is going to know anything at all about pike, and so it is an absolute must that we have proper guidelines that will enable us to review those packages. - J< From pertusus at free.fr Fri Jan 25 23:11:53 2008 From: pertusus at free.fr (Patrice Dumas) Date: Sat, 26 Jan 2008 00:11:53 +0100 Subject: [Fedora-packaging] rpc service description headers packaging Message-ID: <20080125231153.GI2656@free.fr> Hello, There is some dissension on the packaging of the rpc service headers that comes with quota /usr/include/rpcsvc/rquota.h /usr/include/rpcsvc/rquota.x see https://bugzilla.redhat.com/show_bug.cgi?id=226353 The same issue exists for ypserv for /usr/include/rpcsvc/ypxfrd.x All the remaining service header files are owned by glibc-headers. Reviewers insist on putting those files in a -devel subpackage. I am not sure that it is really needed since these are not API description. The devel package won't need to require the main package, and it seems to me that it would better be called -headers than -devel. Also maybe all the rpc service headers could be in glibc. Advices? -- Pat From limb at jcomserv.net Mon Jan 28 12:09:53 2008 From: limb at jcomserv.net (Jon Ciesla) Date: Mon, 28 Jan 2008 06:09:53 -0600 (CST) Subject: [Fedora-packaging] rpc service description headers packaging In-Reply-To: <20080125231153.GI2656@free.fr> References: <20080125231153.GI2656@free.fr> Message-ID: <10518.63.85.68.164.1201522193.squirrel@mail.jcomserv.net> > Hello, > > There is some dissension on the packaging of the rpc service headers that > comes with quota > /usr/include/rpcsvc/rquota.h > /usr/include/rpcsvc/rquota.x > see > https://bugzilla.redhat.com/show_bug.cgi?id=226353 > > The same issue exists for ypserv for > /usr/include/rpcsvc/ypxfrd.x > > All the remaining service header files are owned by glibc-headers. > > Reviewers insist on putting those files in a -devel subpackage. I am not > sure that it is really needed since these are not API description. The > devel package won't need to require the main package, and it seems to me > that it would better be called -headers than -devel. Also maybe all the > rpc service headers could be in glibc. Reviewer for quota here, see https://bugzilla.redhat.com/process_bug.cgi#c19 > Advices? > > -- > Pat > > -- > Fedora-packaging mailing list > Fedora-packaging at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-packaging > -- novus ordo absurdum From a.badger at gmail.com Tue Jan 29 17:26:30 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 29 Jan 2008 09:26:30 -0800 Subject: [Fwd: Re: [Fedora-packaging] Lisp packaging draft] Message-ID: <479F61C6.6050607@gmail.com> Hey Anthony, It just occurred to me that you might not be on the packaging list so I thought I better resend this to you. -------- Original Message -------- Subject: Re: [Fedora-packaging] Lisp packaging draft Date: Fri, 18 Jan 2008 17:42:33 -0800 From: Toshio Kuratomi To: Discussion of RPM packaging standards and practices for Fedora References: <4791022A.2080103 at redhat.com> Anthony Green wrote: > For your review... > > http://fedoraproject.org/wiki/PackagingDrafts/Lisp > Cool. Thanks for taking charge of this. A bit of feedback: High level: * The guidelines need to be written so that a reviewer can effectively use them to decide if a package is conforming. This means that you might have to explain things that the packager will understand (since they come from a lisp background) but the reviewer might not. Specifics: * What is adsf? Is it a format or a utility? If the former, how do we get libraries into that format, if the latter, how and when do we invoke it? * What differentiates a lisp library from another piece of lisp? * How do the various register/unregister commands translate to %post/%preun scriptlets? * What package are the register/unregister commands provided in? * What package provides /usr/lib/common-lisp? * What package provides /usr/share/common-lisp? * Why do we use /usr/lib/common-lisp instead of /usr/libexec/common-lisp? * What are fasls? * What provides /var/cache/common-lisp-controller? * What is being created in /var/cache/common-lisp-controller//// ? * What creates those directories? Who creates those directories? * You mention compiling of libraries. Where do those get dropped on the system? What are the commands to generate those during %build? * It looks like some of the Debian Guidelines aren't going necessary for Fedora... for instance:: {{{ - register-common-lisp-source: does nothing }}} In Fedora, we try to avoid doing things that are no-ops. I'm sure there will be more questions after these are answered and incorporated into your draft :-) -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: