From ville.skytta at iki.fi Tue Nov 3 06:55:24 2009 From: ville.skytta at iki.fi (Ville =?windows-1252?q?Skytt=E4?=) Date: Tue, 3 Nov 2009 08:55:24 +0200 Subject: [Fedora-packaging] Python 3 compatibility update to Python guidelines In-Reply-To: <20091031014854.GA21217@clingman.lan> References: <200910171333.29486.ville.skytta@iki.fi> <20091031014854.GA21217@clingman.lan> Message-ID: <200911030855.25271.ville.skytta@iki.fi> On Saturday 31 October 2009, Toshio Kuratomi wrote: > Any reason not to do it this way? > > %{!?python_sitelib: %global python_sitelib %(%{__python} -c "from. > distutils.sysconfig import *; print (get_python_lib())")} > > %{!?python_sitearch: %global python_sitearch %(%{__python} -c "from. > distutils.sysconfig import *; print(get_python_lib(1))")} Assuming the "." after "from" is unintentional in both and that there should be a space after "print" and before "(" in the latter, that seems to work too. It does look a bit hackish to me though. > Also, dmalcolm, could we get these macros into the python and python3 (when > revewied) package so we don't have to add them as boilerplate to every > package? That would be good, but until they're in at least the latest EL as well, I intend to keep them also in the rpmdevtools spec template. From tibbs at math.uh.edu Tue Nov 3 15:23:13 2009 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Tue, 03 Nov 2009 09:23:13 -0600 Subject: [Fedora-packaging] Ownership of %{sugaractivitydir} Message-ID: The spec template in the Sugar packaging guidelines (https://fedoraproject.org/wiki/Packaging:SugarActivityGuidelines) indicates that the package should not own %{sugaractivitydir} (which evaluates to /usr/share/sugar/activities). Unfortunately, this means nothing in the filesystem owns that directory because sugar itself doesn't own it for some reason. I would suggest that the simplest way to fix it would be to have the sugar package own that directory, but alternately we could fix the sugar packaging guidelines and fix up all of the activity packages. - J< From richmattes at gmail.com Tue Nov 3 18:00:40 2009 From: richmattes at gmail.com (Rich Mattes) Date: Tue, 3 Nov 2009 13:00:40 -0500 Subject: [Fedora-packaging] File path clarification Message-ID: <7286730f0911031000l50e7dcd9k3eb5260aa66b9317@mail.gmail.com> I'm creating a package for a group of libraries, and I have a few questions about where to install some files. 1. The project creates its own folder in /usr/lib called /usr/lib/projectname, and installs its shared libraries there. What's the policy on doing this vs. putting all of the libraries into /usr/lib? 1a. The project also puts a few .cmake files in its libdir folder. Upstream informed me that some other projects use these files during their own build process, so moving these cmake files could be problematic. I think that putting .cmake files in /usr/lib might be a violation of linux filesystem rules, but doing a "yum provides *lib/*.cmake" shows that some other projects do this exact thing (install their libraries and cmake files into their own directory under /usr/lib). This leads me to believe that this practice is ok? 2. The project installs a bunch of other assorted cmake macros, which are also used by other projects. These don't take the form of FindProject.cmake though, so I don't think they belong in the system-wide cmake module path. I should put those in /usr/share/projectname/cmake? Thanks for the help, Rich -------------- next part -------------- An HTML attachment was scrubbed... URL: From a.badger at gmail.com Tue Nov 3 18:22:40 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 3 Nov 2009 10:22:40 -0800 Subject: [Fedora-packaging] Python 3 compatibility update to Python guidelines In-Reply-To: <200911030855.25271.ville.skytta@iki.fi> References: <200910171333.29486.ville.skytta@iki.fi> <20091031014854.GA21217@clingman.lan> <200911030855.25271.ville.skytta@iki.fi> Message-ID: <20091103182240.GA29121@clingman.lan> On Tue, Nov 03, 2009 at 08:55:24AM +0200, Ville Skytt? wrote: > On Saturday 31 October 2009, Toshio Kuratomi wrote: > > > Any reason not to do it this way? > > > > %{!?python_sitelib: %global python_sitelib %(%{__python} -c "from. > > distutils.sysconfig import *; print (get_python_lib())")} > > > > %{!?python_sitearch: %global python_sitearch %(%{__python} -c "from. > > distutils.sysconfig import *; print(get_python_lib(1))")} > > Assuming the "." after "from" is unintentional in both > Yeah, copy and paste from an editor that displays trailing spaces Sorry. > and that there should > be a space after "print" and before "(" in the latter, that seems to work too. > It does look a bit hackish to me though. > So.. this seems to be a matter of viewpoint. From a python3 standpoint, print is now a function so doing:: print(get_python_lib()) Seems perfectly normal whereas import sys; sys.stdout.write() looks hackish. From a python2 standpoint where print is a keyword the extra space makes more sense:: print (get_python_lib()) but does indeed look a little hackish. (Since you're either using parenthesis in a throwaway manner here, or worse, with multiple values making a tuple [which won't print correctly -- although py2.6+ has from __future__ import print_function which makes that work.]). Since this is purely stylistic (for python_sitelib definition, any of these ways work) we're just deciding whether we want to write these as python3 that's backwards compatible or python2 that's forward compatible. If we get these into the python/python3 packages, I don't care at all. If they stay in the Guidelienes alone, I'd go with the python3 viewpoint since we're starting the migration towards that. > > Also, dmalcolm, could we get these macros into the python and python3 (when > > revewied) package so we don't have to add them as boilerplate to every > > package? > > That would be good, but until they're in at least the latest EL as well, I > intend to keep them also in the rpmdevtools spec template. > +1 -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From ville.skytta at iki.fi Tue Nov 3 19:06:10 2009 From: ville.skytta at iki.fi (Ville =?windows-1252?q?Skytt=E4?=) Date: Tue, 3 Nov 2009 21:06:10 +0200 Subject: [Fedora-packaging] Python 3 compatibility update to Python guidelines In-Reply-To: <20091103182240.GA29121@clingman.lan> References: <200910171333.29486.ville.skytta@iki.fi> <200911030855.25271.ville.skytta@iki.fi> <20091103182240.GA29121@clingman.lan> Message-ID: <200911032106.10340.ville.skytta@iki.fi> On Tuesday 03 November 2009, Toshio Kuratomi wrote: > Since this is purely stylistic [...] I actually thought it wasn't purely stylistic and that without the space "print('foo')" would blow up with Python 2, but I was wrong, sorry about that. I don't care if the space is there or not or sys.stdout.write is used instead, will follow in rpmdevtools whatever ends up in the guidelines as long as it works for both Python 2 and 3. From a.badger at gmail.com Tue Nov 3 20:33:33 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 3 Nov 2009 12:33:33 -0800 Subject: [Fedora-packaging] Ownership of %{sugaractivitydir} In-Reply-To: References: Message-ID: <20091103203333.GB29121@clingman.lan> On Tue, Nov 03, 2009 at 09:23:13AM -0600, Jason L Tibbitts III wrote: > The spec template in the Sugar packaging guidelines > (https://fedoraproject.org/wiki/Packaging:SugarActivityGuidelines) > indicates that the package should not own %{sugaractivitydir} (which > evaluates to /usr/share/sugar/activities). Unfortunately, this means > nothing in the filesystem owns that directory because sugar itself > doesn't own it for some reason. > > I would suggest that the simplest way to fix it would be to have the > sugar package own that directory, but alternately we could fix the sugar > packaging guidelines and fix up all of the activity packages. > I asked dgilmore (since he wrote the Sugar Activity Guidelines). He took a look and said: [12:02:51] abadger1999: sugar should own it and for some reason it looks like we never added it I've opened a bug to have that corrected: https://bugzilla.redhat.com/show_bug.cgi?id=532796 -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From a.badger at gmail.com Wed Nov 4 01:11:18 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 3 Nov 2009 17:11:18 -0800 Subject: [Fedora-packaging] Python 3 compatibility update to Python guidelines In-Reply-To: <200911032106.10340.ville.skytta@iki.fi> References: <200910171333.29486.ville.skytta@iki.fi> <200911030855.25271.ville.skytta@iki.fi> <20091103182240.GA29121@clingman.lan> <200911032106.10340.ville.skytta@iki.fi> Message-ID: <20091104011118.GA1850@clingman.lan> On Tue, Nov 03, 2009 at 09:06:10PM +0200, Ville Skytt? wrote: > On Tuesday 03 November 2009, Toshio Kuratomi wrote: > > > Since this is purely stylistic [...] > > I actually thought it wasn't purely stylistic and that without the space > "print('foo')" would blow up with Python 2, but I was wrong, sorry about that. > I don't care if the space is there or not or sys.stdout.write is used instead, > will follow in rpmdevtools whatever ends up in the guidelines as long as it > works for both Python 2 and 3. > Updated: https://fedoraproject.org/wiki/Packaging:Python#System_Architecture -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From wdierkes at 5dollarwhitebox.org Wed Nov 4 08:49:40 2009 From: wdierkes at 5dollarwhitebox.org (BJ Dierkes) Date: Wed, 4 Nov 2009 02:49:40 -0600 Subject: [Fedora-packaging] Proposal: naming convention for Python 3 packages and subpackages In-Reply-To: <1256855255.3731.3394.camel@brick> References: <1254417309.9551.34.camel@radiator.bos.redhat.com> <4AC50044.6090804@gmail.com> <1256855255.3731.3394.camel@brick> Message-ID: On Oct 29, 2009, at 5:27 PM, David Malcolm wrote: > (NB: I hope that we'll eventually be in a place where we can cut over > embedders and users of python (e.g. gedit, gdb, mod_python etc) from 2 > to 3; I'm _not_ suggesting we do anything to their names. Obviously > such a move is a long way off) > >> This seems fine even though it's a bit redundant: python3-pygtk2 and >> python3-pygpgme. > > We could combine: > - the "always use a python3-" rule I invented just above (ahem) and > - the "When in doubt, use the name of the module that you type to > import it in a script" advice from the python module guidelines. > > This would make the above examples be "python3-gtk" and "python3- > gpgme" > My issue with a 'always use a python3-' rule is that the naming convention, to me, clarifies what the package is. For example: python3-GeoIP => A python 3 library installed to site_packages mod_python3 => An Apache module built against/for python 3 Suggesting such a package should be 'python3-mod_python' might be confusing. Where as mod_python3 makes more sense. It also serves to keep the organization of packages similar. For example: mod_python mod_python3 OR mod_python-python3 OR mod_python-py3 Will sit side by side in a yum list, or viewing a yum repo via browser... where as python3-mod_python would not list anywhere near mod_python. >> What to do with things that have python in their suffix: >> gstreamer-python => gstreamer-python3? Or python3-gstreamer? Or >> python3-gstreamer-python? Most of these are subpackages of existing >> packages. > > Again, following the combination of the two rules above: > "python3-gstreamer" Not sure I agree here, because '-python' is a sub package of gstreamer (and personally I hate subpackages that don't share the base package's base name). My vote would be for: gstreamer-python (built against stock python) gstreamer-python3 OR gstreamer-python-py3 (built against python3) > >> A cornercase is the gnome-python2 package. These are python >> bindings to >> gnome2. gnome-python2 is the upstream name. For python3, do we want >> python3-gnome-python2, python3-gnome2, python3-gnome-python2 ? >> From my reading of "rpm -qi gnome-python2", the upstream name is > "gnome-python", so perhaps "python3-gnome" is the thing to use here? > In the case of gnome-python2 where the '2' references the version of gnome it is built for... well I'd say that is just a complete hozer and we should convince upstream to change the name. ;) With regards to multiple versions of python in general, I'm maintaining such a setup currently via IUS [1] for RHEL/CentOS. It is essentially the same idea.. python26 with sub-packages such as python26-simplejson, python26-elixir, etc... as well as python31, python31-distribute. Additionally, there is mod_python26, mod_wsgi- python26, and mod_wsgi-python31. Not exactly applicable here in this thread, and there was no 'standards' discussion on naming conventions being that I'm currently the only developer... but regardless I wanted to point it out as perhaps a proof of concept of working with multiple versions of python (on RHEL/CentOS in my case). For my purposes, and I don't know that this would follow Fedora ideals, my primary goal for python 3 was/is that the base package is available for use without effecting the system/stock python. I honestly don't think it is that important at this point to push all the python packagers to rebuild/maintain python3 counterparts of their packages in order for python3 to be added. With python3, and python3- distribute installed as a base, developers can begin testing/using/ building against python 3 and over time the supporting sub packages will be added as they become python 3 compatible. With python3- distribute, users can install the necessary [read missing] dependencies via easy_install-3 (same as they would with pear/pecl for PHP for their additional needs). [1] See: http://iuscommunity.org, http://launchpad.net/ius --- derks From orion at cora.nwra.com Wed Nov 4 20:53:49 2009 From: orion at cora.nwra.com (Orion Poplawski) Date: Wed, 04 Nov 2009 13:53:49 -0700 Subject: [Fedora-packaging] Fortran guideline issues Message-ID: <4AF1E9DD.1050302@cora.nwra.com> http://www.fedoraproject.org/wiki/Packaging:Fortran states: As Fortran modules are architecture and GCC version specific, they MUST be placed into %{_fmoddir} (or its package-specific subfolder in case the modules have generic names), which is owned by 'gcc-gfortran'. For directory ownership any packages containing Fortran modules MUST Requires: gcc-gfortran%{_isa}. I did this in netcdf, and ended up with: The following packages in the repository suffer from broken dependencies: ====================================================================== The results in this summary consider Test Updates! ====================================================================== package: netcdf-devel-4.0.1-2.fc11.i586 from fedora-updates-testing-11-x86_64 unresolved deps: gcc-gfortran(x86-32) package: netcdf-devel-4.0.1-2.fc11.ppc64 from fedora-updates-testing-11-ppc unresolved deps: gcc-gfortran(ppc-64) because gcc-gfortran (like gcc) is apparently not multi-lib. So, what to do? -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From jussilehtola at fedoraproject.org Wed Nov 4 23:26:27 2009 From: jussilehtola at fedoraproject.org (Jussi Lehtola) Date: Thu, 05 Nov 2009 01:26:27 +0200 Subject: [Fedora-packaging] Fortran guideline issues In-Reply-To: <4AF1E9DD.1050302@cora.nwra.com> References: <4AF1E9DD.1050302@cora.nwra.com> Message-ID: <1257377187.11374.6.camel@localhost> On Wed, 2009-11-04 at 13:53 -0700, Orion Poplawski wrote: > http://www.fedoraproject.org/wiki/Packaging:Fortran states: > > As Fortran modules are architecture and GCC version specific, they MUST > be placed into %{_fmoddir} (or its package-specific subfolder in case > the modules have generic names), which is owned by 'gcc-gfortran'. For > directory ownership any packages containing Fortran modules MUST > Requires: gcc-gfortran%{_isa}. > > I did this in netcdf, and ended up with: Thanks for the report. The %{_fmoddir} ownership issue https://bugzilla.redhat.com/show_bug.cgi?id=513985 still isn't resolved due to inactivity (read: total silence) of the gcc maintainers. In the meantime I recommend just commenting out the Requires: gcc-gfortran%{_isa} line. ** Since 64-bit gcc is built to be able to compile in 32-bit mode, it would be logical to make the x86_64 gfortran own the 32-bit %{_fmoddir} and Provides: gfortran(x86-32) (and the same thing on other arches, too). This has to be discussed with the gcc maintainers, though. -- Jussi Lehtola Fedora Project Contributor jussilehtola at fedoraproject.org From taljurf at fedoraproject.org Thu Nov 5 06:05:01 2009 From: taljurf at fedoraproject.org (Tareq Al Jurf) Date: Thu, 5 Nov 2009 09:05:01 +0300 Subject: [Fedora-packaging] Removing file from .spec Message-ID: <12d8a2fa0911042205s37df4bb2gf260396786c668e5@mail.gmail.com> I have a spec file for a program that i'm packaging i was told to remove the INSTALL document from %files when i do that i get error: Installed (but unpackaged) file(s) found: > /usr/share/doc/invulgotracker/ >> >> INSTALL >> >> >> RPM build errors: >> Installed (but unpackaged) file(s) found: >> /usr/share/doc/invulgotracker/INSTALL > > what should i do? thanks -- Tareq Al Jurf Fedora Ambassador Riyadh, Saudi Arabia taljurf at fedoraproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomasj at fedoraproject.org Thu Nov 5 06:55:25 2009 From: thomasj at fedoraproject.org (Thomas Janssen) Date: Thu, 5 Nov 2009 07:55:25 +0100 Subject: [Fedora-packaging] Removing file from .spec In-Reply-To: <12d8a2fa0911042205s37df4bb2gf260396786c668e5@mail.gmail.com> References: <12d8a2fa0911042205s37df4bb2gf260396786c668e5@mail.gmail.com> Message-ID: 2009/11/5 Tareq Al Jurf : > I have a spec file for a program that i'm packaging > i was told to remove the INSTALL document from %files > > when i do that i get > >> error: Installed (but unpackaged) file(s) found: >> ?? /usr/share/doc/invulgotracker/ >>> >>> INSTALL >>> >>> >>> RPM build errors: >>> ??? Installed (but unpackaged) file(s) found: >>> ?? /usr/share/doc/invulgotracker/INSTALL Normal documentation is in %doc of your spec. Not in %files. So add it to the %doc line or rm the file in %prep. Depends on what's in this INSTALL file. -- LG Thomas Dubium sapientiae initium From christoph.wickert at googlemail.com Thu Nov 5 20:33:03 2009 From: christoph.wickert at googlemail.com (Christoph Wickert) Date: Thu, 05 Nov 2009 21:33:03 +0100 Subject: [Fedora-packaging] Removing file from .spec In-Reply-To: References: <12d8a2fa0911042205s37df4bb2gf260396786c668e5@mail.gmail.com> Message-ID: <1257453183.7175.41.camel@wicktop.localdomain> Am Donnerstag, den 05.11.2009, 07:55 +0100 schrieb Thomas Janssen: > 2009/11/5 Tareq Al Jurf : > > I have a spec file for a program that i'm packaging > > i was told to remove the INSTALL document from %files > > > > when i do that i get > > > >> error: Installed (but unpackaged) file(s) found: > >> /usr/share/doc/invulgotracker/ > >>> > >>> INSTALL If you remove the file from the %files section, then you also need to remove it from the installed files in $RPM_BUILD_ROOT. You can do this with a simple rm $RPM_BUILD_ROOT%{_docdir}/invulgotracker/INSTALL BTW: The docs should be versioned (invulgotracker-0.53), but you already do this in the spec that is linked in your review. The rest is explained in the private mails I just sent you before seeing this one. > Normal documentation is in %doc of your spec. Not in %files. So add it > to the %doc line or rm the file in %prep. Depends on what's in this > INSTALL file. It's just the generic install notes we usually don't ship. Regards, Christoph From tibbs at math.uh.edu Sat Nov 7 17:10:34 2009 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Sat, 07 Nov 2009 11:10:34 -0600 Subject: [Fedora-packaging] Duplicate files Message-ID: http://fedoraproject.org/wiki/Packaging:Guidelines#Duplicate_Files is pretty clear: ---- Duplicate Files A Fedora package must not list a file more than once in the spec file's %files listings. If you think your package is a valid exception to this, please bring it to the attention of the Packaging Committee so they can improve on this Guideline. ---- However, some packagers absolutely insist on duplicating license files (say, once in the main package, and again in the -devel package) and this issue keeps coming up. Can we make a clear determination as to whether there are circumstances where duplication of license files is permitted, and clearly outline those situations in the guidelines? My understanding of the current opinion from the legal folks is that we must duplicate the license files if there's no clear dependency chain between the packages. Otherwise I think that we have enough duplicated copies of the GPL floating around and we should try to keep the number down where we can. - J< From jonathan.underwood at gmail.com Sat Nov 7 21:05:20 2009 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Sat, 7 Nov 2009 21:05:20 +0000 Subject: [Fedora-packaging] Revised Emacs add-on guidelines Message-ID: <645d17210911071305h88141f7s28a6a97622fea6ae@mail.gmail.com> Dear All, We've recently added some macro definitions under /etc/rpm/macros.[x]emacs to simplify add on packaging for (X)Emacs. The main point being that we no longer use the pkg-config way of finding directory locations etc at add-on package build time, which removes all the boiler plate stufff that was being added to every add on package. A new draft of the guidelines is here: https://fedoraproject.org/wiki/PackagingDrafts/EmacsPackagingRevised Comments welcome! Best wishes, Jonathan From tibbs at math.uh.edu Sat Nov 7 21:33:19 2009 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Sat, 07 Nov 2009 15:33:19 -0600 Subject: [Fedora-packaging] Revised Emacs add-on guidelines In-Reply-To: <645d17210911071305h88141f7s28a6a97622fea6ae@mail.gmail.com> (Jonathan Underwood's message of "Sat, 7 Nov 2009 21:05:20 +0000") References: <645d17210911071305h88141f7s28a6a97622fea6ae@mail.gmail.com> Message-ID: >>>>> "JU" == Jonathan Underwood writes: JU> A new draft of the guidelines is here: JU> https://fedoraproject.org/wiki/PackagingDrafts/EmacsPackagingRevised These do look significantly simpler, which is generally a good thing. Is there a good way to see the actual diffs between this and the existing guidelines? Or could you summarize them in a bit more detail? Also, I think you might as well go ahead and remove BuildRoot: and the first line after %install from the templates, since they're not required in any supported Fedora release at this point. - J< From jonathan.underwood at gmail.com Sun Nov 8 10:26:51 2009 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Sun, 8 Nov 2009 10:26:51 +0000 Subject: [Fedora-packaging] Revised Emacs add-on guidelines In-Reply-To: References: <645d17210911071305h88141f7s28a6a97622fea6ae@mail.gmail.com> Message-ID: <645d17210911080226s7930fae4t642be561d25d3727@mail.gmail.com> 2009/11/7 Jason L Tibbitts III : >>>>>> "JU" == Jonathan Underwood writes: > > JU> A new draft of the guidelines is here: > JU> https://fedoraproject.org/wiki/PackagingDrafts/EmacsPackagingRevised > > These do look significantly simpler, which is generally a good thing. > Is there a good way to see the actual diffs between this and the > existing guidelines? ?Or could you summarize them in a bit more detail? > OK, I did diff the original and revised guidelines, but it's not that easily digested, so I'll attempt a summary. Some of the primary concerns with (x)emacs add on packages are: 1) Correct package and sub-package naming and organization 2) Installing the files in the right places 3) Ensuring that the version of (x)emacs that was used to byte compile the elisp files is a requirement of the package - requiring build time detection of the (x)emacs version With the current guidelines, points 2 and 3 were handled by calling pkg-config to define macros at add-on package build time. This makes use of a pkg-config file installed with the (x)emacs package. With the revised guidelines we make use of macros in the files /etc/rpm/macros.[x]emacs to ensure the relevant macros are defined for add-on package building. This removes the pkg-config complexity and removes a lot of boilerplate from the spec files. That's the main point of the guideline update. At the same time I've reorganised the guidelines for clarity and simplicity. I hope they're a lot easier to follow now. > Also, I think you might as well go ahead and remove BuildRoot: and the > first line after %install from the templates, since they're not > required in any supported Fedora release at this point. OK, thanks, have done that. Cheers, Jonathan From jonathan.underwood at gmail.com Sun Nov 8 10:30:32 2009 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Sun, 8 Nov 2009 10:30:32 +0000 Subject: [Fedora-packaging] Revised Emacs add-on guidelines In-Reply-To: <645d17210911080226s7930fae4t642be561d25d3727@mail.gmail.com> References: <645d17210911071305h88141f7s28a6a97622fea6ae@mail.gmail.com> <645d17210911080226s7930fae4t642be561d25d3727@mail.gmail.com> Message-ID: <645d17210911080230p3595e4d4y547bdbac8aa8f8f@mail.gmail.com> 2009/11/8 Jonathan Underwood : > 2009/11/7 Jason L Tibbitts III : >>>>>>> "JU" == Jonathan Underwood writes: >> >> JU> A new draft of the guidelines is here: >> JU> https://fedoraproject.org/wiki/PackagingDrafts/EmacsPackagingRevised >> >> These do look significantly simpler, which is generally a good thing. >> Is there a good way to see the actual diffs between this and the >> existing guidelines? ?Or could you summarize them in a bit more detail? >> > > OK, I did diff the original and revised guidelines, but it's not that > easily digested, so I'll attempt a summary. > > Some of the primary concerns with (x)emacs add on packages are: > 1) Correct package and sub-package naming and organization > 2) Installing the files in the right places > 3) Ensuring that the version of (x)emacs that was used to byte compile > the elisp files is a requirement of the package - requiring build time > detection of the (x)emacs version > > With the current guidelines, points 2 and 3 were handled by calling > pkg-config to define macros at add-on package build time. This makes > use of a pkg-config file installed with the (x)emacs package. > > With the revised guidelines we make use of macros in the files > /etc/rpm/macros.[x]emacs to ensure the relevant macros are defined for > add-on package building. This removes the pkg-config complexity and > removes a lot of boilerplate from the spec files. > > That's the main point of the guideline update. > > At the same time I've reorganised the guidelines for clarity and > simplicity. I hope they're a lot easier to follow now. Two extra points: I should have emphasized that the changes to the guidelines are purely about mechanism, and not policy. Nothing has changed with regard to emacs add-on packaging policy in the guidelines. I should also addd, as a sidenote, that the old pkg-config way of doing things still works, as we haven't removed the pkg-config files from the emacs/xemacs packages. So nothing breaks. J. From tcallawa at redhat.com Mon Nov 9 01:50:43 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Mon, 09 Nov 2009 11:50:43 +1000 Subject: [Fedora-packaging] Duplicate files In-Reply-To: References: Message-ID: <4AF77573.5030905@redhat.com> On 11/08/2009 03:10 AM, Jason L Tibbitts III wrote: > http://fedoraproject.org/wiki/Packaging:Guidelines#Duplicate_Files is > pretty clear: > > ---- > Duplicate Files > > A Fedora package must not list a file more than once in the spec file's > %files listings. If you think your package is a valid exception to this, > please bring it to the attention of the Packaging Committee so they can > improve on this Guideline. > ---- > > However, some packagers absolutely insist on duplicating license files > (say, once in the main package, and again in the -devel package) and > this issue keeps coming up. > > Can we make a clear determination as to whether there are circumstances > where duplication of license files is permitted, and clearly outline > those situations in the guidelines? My understanding of the current > opinion from the legal folks is that we must duplicate the license files > if there's no clear dependency chain between the packages. Otherwise I > think that we have enough duplicated copies of the GPL floating around > and we should try to keep the number down where we can. How about something like this: * For binary RPMs, the complete set of license files (as provided by upstream) must be included in the %doc section of either the main binary rpm or a common RPM that the other binary sub-packages depend on. Independent sub-packages are required to include their own copy of the relevant license texts (as provided by upstream). ~spot From oget.fedora at gmail.com Tue Nov 10 08:04:39 2009 From: oget.fedora at gmail.com (Orcan Ogetbil) Date: Tue, 10 Nov 2009 03:04:39 -0500 Subject: [Fedora-packaging] daemons vs services Message-ID: Services need to be stopped before uninstallation of the corresponding package. How about daemons? Orcan From tibbs at math.uh.edu Tue Nov 10 14:45:24 2009 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Tue, 10 Nov 2009 08:45:24 -0600 Subject: [Fedora-packaging] daemons vs services In-Reply-To: (Orcan Ogetbil's message of "Tue, 10 Nov 2009 03:04:39 -0500") References: Message-ID: >>>>> "OO" == Orcan Ogetbil writes: OO> Services need to be stopped before uninstallation of the OO> corresponding package. How about daemons? What's the difference? If it starts with an initscript, I'd expect that the terms "service" and "daemon" are interchangeable. - J< From richmattes at gmail.com Tue Nov 10 15:09:08 2009 From: richmattes at gmail.com (Rich Mattes) Date: Tue, 10 Nov 2009 10:09:08 -0500 Subject: [Fedora-packaging] Re: File path clarification In-Reply-To: <7286730f0911031000l50e7dcd9k3eb5260aa66b9317@mail.gmail.com> References: <7286730f0911031000l50e7dcd9k3eb5260aa66b9317@mail.gmail.com> Message-ID: <7286730f0911100709y4bd7a8bbk86706c21f827d7c9@mail.gmail.com> I found a link from the cmake people that suggests creating a /usr/lib/projectname folder for libraries and cmake files is suggested practice to allow other projects to import yours: http://www.itk.org/Wiki/CMake_2.6_Notes#Exporting_from_an_Installation_Tree Is this compatible with Fedora packaging, or should pacakges install all of their shared libs in %{_libdir}? If the libs do go right into the libdir, should the project-config.cmake files go somewhere like /usr/share/projectname/cmake? Rich On Tue, Nov 3, 2009 at 1:00 PM, Rich Mattes wrote: > I'm creating a package for a group of libraries, and I have a few questions > about where to install some files. > > 1. The project creates its own folder in /usr/lib called > /usr/lib/projectname, and installs its shared libraries there. What's the > policy on doing this vs. putting all of the libraries into /usr/lib? > > 1a. The project also puts a few .cmake files in its libdir folder. > Upstream informed me that some other projects use these files during their > own build process, so moving these cmake files could be problematic. I > think that putting .cmake files in /usr/lib might be a violation of linux > filesystem rules, but doing a "yum provides *lib/*.cmake" shows that some > other projects do this exact thing (install their libraries and cmake files > into their own directory under /usr/lib). This leads me to believe that > this practice is ok? > > 2. The project installs a bunch of other assorted cmake macros, which are > also used by other projects. These don't take the form of FindProject.cmake > though, so I don't think they belong in the system-wide cmake module path. > I should put those in /usr/share/projectname/cmake? > > Thanks for the help, > > Rich > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tibbs at math.uh.edu Tue Nov 10 15:44:07 2009 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Tue, 10 Nov 2009 09:44:07 -0600 Subject: [Fedora-packaging] Duplicate files In-Reply-To: <4AF77573.5030905@redhat.com> (Tom Callaway's message of "Mon, 09 Nov 2009 11:50:43 +1000") References: <4AF77573.5030905@redhat.com> Message-ID: >>>>> "TC" == Tom \"spot\" Callaway writes: TC> * For binary RPMs, the complete set of license files (as provided by TC> upstream) must be included in the %doc section of either the main TC> binary rpm or a common RPM that the other binary sub-packages depend TC> on. Independent sub-packages are required to include their own copy TC> of the relevant license texts (as provided by upstream). Seems fine to me as long as we otherwise stick to our prohibition on file duplication. Do we need to somehow define "license files"? If documentation specifies "this is GPL", does that make it a license file? Does the presence of a COPYING file change the answer? (I know, it's a relatively pointless question, but I know with certainty that it won't be too long before it is asked in a package review.) - J< From oget.fedora at gmail.com Tue Nov 10 18:21:26 2009 From: oget.fedora at gmail.com (Orcan Ogetbil) Date: Tue, 10 Nov 2009 13:21:26 -0500 Subject: [Fedora-packaging] daemons vs services In-Reply-To: References: Message-ID: On Tue, Nov 10, 2009 at 9:45 AM, Jason L Tibbitts III wrote: >>>>>> "OO" == Orcan Ogetbil writes: > > OO> Services need to be stopped before uninstallation of the > OO> corresponding package. How about daemons? > > What's the difference? ?If it starts with an initscript, I'd expect that > the terms "service" and "daemon" are ?interchangeable. > By daemons, I meant more in the lines of those programs that run in the background, but do not put an initscript in /etc. Userspace daemons for instance. e.g. jack, pulseaudio type daemons... Orcan From tcallawa at redhat.com Tue Nov 10 23:22:08 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 11 Nov 2009 09:22:08 +1000 Subject: [Fedora-packaging] Duplicate files In-Reply-To: References: <4AF77573.5030905@redhat.com> Message-ID: <4AF9F5A0.5070009@redhat.com> On 11/11/2009 01:44 AM, Jason L Tibbitts III wrote: > Seems fine to me as long as we otherwise stick to our prohibition on > file duplication. Do we need to somehow define "license files"? If > documentation specifies "this is GPL", does that make it a license file? > Does the presence of a COPYING file change the answer? (I know, it's a > relatively pointless question, but I know with certainty that it won't > be too long before it is asked in a package review.) I've had the idea for some time that it would be ideal if rpm supported something like this: %files %doc foo bar %license COPYING That would make it clear what the license file is, from an RPM perspective. From a definition perspective, I define a license file as: "A copy of the legal text which defines the copyright on the work and the permissions or restrictions placed upon that work by the copyright holder(s)." So, COPYING (where COPYING is a copy of the GPLv3 license text) is a license file. A README.txt which simply says "This code is under GPLv3." is not a license file. Worth mentioning in the Licensing guidelines? ~spot From dmalcolm at redhat.com Wed Nov 11 00:13:25 2009 From: dmalcolm at redhat.com (David Malcolm) Date: Tue, 10 Nov 2009 19:13:25 -0500 Subject: [Fedora-packaging] Python 3 packaging Message-ID: <1257898405.8419.312.camel@brick> I'm working on a python 3 stack for Fedora 13, parallel-installable with the default python 2 stack [1] I've attempted to package python 3, and package some python modules for python 3. So far, I've got a "python3-rpm", a "python3-lxml", and two different ways of packaging "python3-setuptools", though none of these are actually in our CVS yet [2]. Thanks everyone for your help so far. In doing so, I've been writing some proposals on packaging guidelines for Python 3 - both for secondary python runtimes, and for modules for them. You can see what I've written so far here: https://fedoraproject.org/wiki/PackagingDrafts/Python3 Obviously this is a work in progress but hopefully makes sense as far as it goes. I've also written a script to cover some of the automatable work that can given python-foo.spec will write a python3-foo.spec You can see the script here: http://dmalcolm.fedorapeople.org/python3-packaging/rpm2to3.py I got over-ambitious with this script: it can also be given a target srpm, and will then checkout the python 2 srpm, convert to python 3, then recursively walk the build requirements, building the python 3 packages in mock, attemping to build all a stack all the way up to the given srpm... well, that was the theory. However, most packages seem to need at least a little manual cleanup, and so I never managed to get far up the stack - and this is no substitute for actually engaging with the various upstream projects and working on python 3 support in the manner that each upstream wants (e.g. do they want a unified trunk for 2 and 3 vs separate branches) Thoughts? Dave [1] https://fedoraproject.org/wiki/Features/Python3F13 [2] See https://bugzilla.redhat.com/showdependencytree.cgi?id=530636 for the full details. From richmattes at gmail.com Wed Nov 11 19:42:08 2009 From: richmattes at gmail.com (Rich Mattes) Date: Wed, 11 Nov 2009 14:42:08 -0500 Subject: [Fedora-packaging] Re: File path clarification In-Reply-To: <7286730f0911100709y4bd7a8bbk86706c21f827d7c9@mail.gmail.com> References: <7286730f0911031000l50e7dcd9k3eb5260aa66b9317@mail.gmail.com> <7286730f0911100709y4bd7a8bbk86706c21f827d7c9@mail.gmail.com> Message-ID: <7286730f0911111142g14281202hb4b3322b29b62817@mail.gmail.com> I've scoured the packaging guidelines once more, there's no mention of when you should put libraries in %{_libdir} vs. when to create a subdirectory in %{_libdir}. I got a little bit of feedback in my package review request[1], but I'd appreciate more formal clarification. Anyone? [1]: https://bugzilla.redhat.com/show_bug.cgi?id=530251 On Tue, Nov 10, 2009 at 10:09 AM, Rich Mattes wrote: > I found a link from the cmake people that suggests creating > a /usr/lib/projectname folder for libraries and cmake files is suggested > practice to allow other projects to import yours: > http://www.itk.org/Wiki/CMake_2.6_Notes#Exporting_from_an_Installation_Tree > > Is this compatible with Fedora packaging, or should pacakges install all of > their shared libs in %{_libdir}? If the libs do go right into the libdir, > should the project-config.cmake files go somewhere like > /usr/share/projectname/cmake? > > Rich > > On Tue, Nov 3, 2009 at 1:00 PM, Rich Mattes wrote: > >> I'm creating a package for a group of libraries, and I have a few >> questions about where to install some files. >> >> 1. The project creates its own folder in /usr/lib called >> /usr/lib/projectname, and installs its shared libraries there. What's the >> policy on doing this vs. putting all of the libraries into /usr/lib? >> >> 1a. The project also puts a few .cmake files in its libdir folder. >> Upstream informed me that some other projects use these files during their >> own build process, so moving these cmake files could be problematic. I >> think that putting .cmake files in /usr/lib might be a violation of linux >> filesystem rules, but doing a "yum provides *lib/*.cmake" shows that some >> other projects do this exact thing (install their libraries and cmake files >> into their own directory under /usr/lib). This leads me to believe that >> this practice is ok? >> >> 2. The project installs a bunch of other assorted cmake macros, which are >> also used by other projects. These don't take the form of FindProject.cmake >> though, so I don't think they belong in the system-wide cmake module path. >> I should put those in /usr/share/projectname/cmake? >> >> Thanks for the help, >> >> Rich >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.underwood at gmail.com Sat Nov 14 13:40:41 2009 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Sat, 14 Nov 2009 13:40:41 +0000 Subject: [Fedora-packaging] Revised Emacs add-on guidelines In-Reply-To: <645d17210911080230p3595e4d4y547bdbac8aa8f8f@mail.gmail.com> References: <645d17210911071305h88141f7s28a6a97622fea6ae@mail.gmail.com> <645d17210911080226s7930fae4t642be561d25d3727@mail.gmail.com> <645d17210911080230p3595e4d4y547bdbac8aa8f8f@mail.gmail.com> Message-ID: <645d17210911140540q59419e81l9dc19d9a0db2a973@mail.gmail.com> Dear FPC, OK - since there seems to have been no issues with the revised guidelines raised, I've changed the entry in the PackagingDraftsTodo table to "Ratify" - hopefully this can be voted on at the next FPC meeting. Incidentally, I looked for the committee minutes for recent FPC meetings, and the latest available ones are 09/09 - has the FPC stopped meeting, or is it just the the minutes haven't been posted? Cheers, Jonathan From rjones at redhat.com Sat Nov 14 15:40:24 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Sat, 14 Nov 2009 15:40:24 +0000 Subject: [Fedora-packaging] Duplicate files In-Reply-To: <4AF9F5A0.5070009@redhat.com> References: <4AF77573.5030905@redhat.com> <4AF9F5A0.5070009@redhat.com> Message-ID: <20091114154024.GA18162@amd.home.annexia.org> We should run a program that dedupes files in /usr/share/doc, automaticallyq replacing identical files with hard links[0]. There are a number of these sorts of programs, "fdupes" being one that we have in Fedora. A quick calculation running "fdupes -r /usr/share/doc" on my Fedora 12 desktop machine, and some analysis: * 3484 files could be replaced by hard links (that count doesn't include the single remaining copy of the file). * Total files in /usr/share/doc is 31887, so that is 11% of all files in that directory. * Deduping would save 38896 (1K blocks) out of 473748 blocks used (about 8%). [1] By no means all the duplicates in /usr/share/doc are just license files. Many other types of file are also duplicated, including many images. Rich. [0] One day filesystems will do this for us automatically and transparently ... [1] Assumption: storing the directory entry and inode is free. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v From rjones at redhat.com Sat Nov 14 15:46:02 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Sat, 14 Nov 2009 15:46:02 +0000 Subject: [Fedora-packaging] Duplicate files In-Reply-To: References: Message-ID: <20091114154602.GB18162@amd.home.annexia.org> On Sat, Nov 07, 2009 at 11:10:34AM -0600, Jason L Tibbitts III wrote: > However, some packagers absolutely insist on duplicating license files > (say, once in the main package, and again in the -devel package) and > this issue keeps coming up. And it'll keep coming up in future too. We are distributing binary packages which you can download independently from http://download.fedora.redhat.com/pub/fedora/linux/development/i386/os/Packages/ using just a web browser or 'wget'. Web browsers and wget don't understand RPM dependencies, and RPM files can be unpacked by a variety of software, not just the rpm program. Some of those binary packages have the license stripped from them. The GPLv2 clearly says you should not do this: 1. [...] and give any other recipients of the Program a copy of this License along with the Program. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v From tibbs at math.uh.edu Sat Nov 14 15:58:42 2009 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Sat, 14 Nov 2009 09:58:42 -0600 Subject: [Fedora-packaging] Revised Emacs add-on guidelines In-Reply-To: <645d17210911140540q59419e81l9dc19d9a0db2a973@mail.gmail.com> (Jonathan Underwood's message of "Sat, 14 Nov 2009 13:40:41 +0000") References: <645d17210911071305h88141f7s28a6a97622fea6ae@mail.gmail.com> <645d17210911080226s7930fae4t642be561d25d3727@mail.gmail.com> <645d17210911080230p3595e4d4y547bdbac8aa8f8f@mail.gmail.com> <645d17210911140540q59419e81l9dc19d9a0db2a973@mail.gmail.com> Message-ID: >>>>> "JU" == Jonathan Underwood writes: JU> Dear FPC, OK - since there seems to have been no issues with the JU> revised guidelines raised, I've changed the entry in the JU> PackagingDraftsTodo table to "Ratify" - hopefully this can be voted JU> on at the next FPC meeting. That's putting the cart before the horse. We use ratify to indicate that the guidelines have been approved by FPC and are to be ratified by FESCo. - J< From jonathan.underwood at gmail.com Sun Nov 15 14:24:17 2009 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Sun, 15 Nov 2009 14:24:17 +0000 Subject: [Fedora-packaging] Revised Emacs add-on guidelines In-Reply-To: References: <645d17210911071305h88141f7s28a6a97622fea6ae@mail.gmail.com> <645d17210911080226s7930fae4t642be561d25d3727@mail.gmail.com> <645d17210911080230p3595e4d4y547bdbac8aa8f8f@mail.gmail.com> <645d17210911140540q59419e81l9dc19d9a0db2a973@mail.gmail.com> Message-ID: <645d17210911150624l705852bagd2792d85e95237d2@mail.gmail.com> 2009/11/14 Jason L Tibbitts III : >>>>>> "JU" == Jonathan Underwood writes: > > JU> Dear FPC, OK - since there seems to have been no issues with the > JU> revised guidelines raised, I've changed the entry in the > JU> PackagingDraftsTodo table to "Ratify" - hopefully this can be voted > JU> on at the next FPC meeting. > > That's putting the cart before the horse. ?We use ratify to indicate > that the guidelines have been approved by FPC and are to be ratified by > FESCo. > Oops, sorry. I;ve changed it to "Next meeting" From tcallawa at redhat.com Mon Nov 16 17:44:47 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Mon, 16 Nov 2009 12:44:47 -0500 Subject: [Fedora-packaging] Duplicate files In-Reply-To: <20091114154024.GA18162@amd.home.annexia.org> References: <4AF77573.5030905@redhat.com> <4AF9F5A0.5070009@redhat.com> <20091114154024.GA18162@amd.home.annexia.org> Message-ID: <4B018F8F.9000207@redhat.com> On 11/14/2009 10:40 AM, Richard W.M. Jones wrote: > > We should run a program that dedupes files in /usr/share/doc, > automaticallyq replacing identical files with hard links[0]. There > are a number of these sorts of programs, "fdupes" being one that we > have in Fedora. Really, RPM should do this as part of the transaction. If the file marked as %license in the package matches an identical file in %licensedir, hard link. If not, install. I've been meaning to open a ticket with RPM upstream for this for... oh, about forever. :) I'll bump it to the top of my todo pile. ~spot From oget.fedora at gmail.com Mon Nov 16 21:47:29 2009 From: oget.fedora at gmail.com (Orcan Ogetbil) Date: Mon, 16 Nov 2009 16:47:29 -0500 Subject: [Fedora-packaging] daemons vs services In-Reply-To: References: Message-ID: On Tue, Nov 10, 2009 at 1:21 PM, Orcan Ogetbil wrote: > On Tue, Nov 10, 2009 at 9:45 AM, Jason L Tibbitts III wrote: >>>>>>> "OO" == Orcan Ogetbil writes: >> >> OO> Services need to be stopped before uninstallation of the >> OO> corresponding package. How about daemons? >> >> What's the difference? ?If it starts with an initscript, I'd expect that >> the terms "service" and "daemon" are ?interchangeable. >> > > By daemons, I meant more in the lines of those programs that run in > the background, but do not put an initscript in /etc. > Userspace daemons for instance. e.g. jack, pulseaudio type daemons... > Ping? Another example would be gnome-settings-daemon. Don't they need to be killed when they are uninstalled? Orcan From a.badger at gmail.com Tue Nov 17 03:55:43 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 16 Nov 2009 19:55:43 -0800 Subject: [Fedora-packaging] Duplicate files In-Reply-To: <20091114154602.GB18162@amd.home.annexia.org> References: <20091114154602.GB18162@amd.home.annexia.org> Message-ID: <20091117035543.GB3153@clingman.lan> On Sat, Nov 14, 2009 at 03:46:02PM +0000, Richard W.M. Jones wrote: > On Sat, Nov 07, 2009 at 11:10:34AM -0600, Jason L Tibbitts III wrote: > > However, some packagers absolutely insist on duplicating license files > > (say, once in the main package, and again in the -devel package) and > > this issue keeps coming up. > > And it'll keep coming up in future too. > > We are distributing binary packages which you can download > independently from > http://download.fedora.redhat.com/pub/fedora/linux/development/i386/os/Packages/ > using just a web browser or 'wget'. Web browsers and wget don't > understand RPM dependencies, and RPM files can be unpacked by a > variety of software, not just the rpm program. > > Some of those binary packages have the license stripped from > them. The GPLv2 clearly says you should not do this: > > 1. [...] and give any other recipients of the Program a copy of this > License along with the Program. > So if legal says that it's okay to rely on rpm dependencies to do this for us, you'd still insist on doing your own thing? -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From oget.fedora at gmail.com Tue Nov 17 04:10:27 2009 From: oget.fedora at gmail.com (Orcan Ogetbil) Date: Mon, 16 Nov 2009 23:10:27 -0500 Subject: [Fedora-packaging] Duplicate files In-Reply-To: References: Message-ID: On Sat, Nov 7, 2009 at 12:10 PM, Jason L Tibbitts III wrote: > http://fedoraproject.org/wiki/Packaging:Guidelines#Duplicate_Files is > pretty clear: > > ---- > Duplicate Files > > A Fedora package must not list a file more than once in the spec file's > %files listings. If you think your package is a valid exception to this, > please bring it to the attention of the Packaging Committee so they can > improve on this Guideline. > ---- > > However, some packagers absolutely insist on duplicating license files > (say, once in the main package, and again in the -devel package) and > this issue keeps coming up. > Suppose the license of the corresponding software states that the COPYING file must be distributed in all derived work of the software. There is no problem with -devel packages since they pull the main package and the COPYING file makes its way to the target. But what if there is a -tools subpackage that does not require the main package? When you install the -tools subpackage, the COPYING file will not get installed. Thus the license is violated. Where am I wrong? Orcan From a.badger at gmail.com Tue Nov 17 04:11:47 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 16 Nov 2009 20:11:47 -0800 Subject: [Fedora-packaging] Revised Emacs add-on guidelines In-Reply-To: <645d17210911140540q59419e81l9dc19d9a0db2a973@mail.gmail.com> References: <645d17210911071305h88141f7s28a6a97622fea6ae@mail.gmail.com> <645d17210911080226s7930fae4t642be561d25d3727@mail.gmail.com> <645d17210911080230p3595e4d4y547bdbac8aa8f8f@mail.gmail.com> <645d17210911140540q59419e81l9dc19d9a0db2a973@mail.gmail.com> Message-ID: <20091117041147.GC3153@clingman.lan> On Sat, Nov 14, 2009 at 01:40:41PM +0000, Jonathan Underwood wrote: > > Incidentally, I looked for the committee minutes for recent FPC > meetings, and the latest available ones are 09/09 - has the FPC > stopped meeting, or is it just the the minutes haven't been posted? > We haven't been meeting -- I think it's because we finally got through all of the pending Guideline changes. But with this on the docket, we'll need to get together again :-) -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From rjones at redhat.com Tue Nov 17 09:52:39 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Tue, 17 Nov 2009 09:52:39 +0000 Subject: [Fedora-packaging] Duplicate files In-Reply-To: <20091117035543.GB3153@clingman.lan> References: <20091114154602.GB18162@amd.home.annexia.org> <20091117035543.GB3153@clingman.lan> Message-ID: <20091117095239.GA12206@amd.home.annexia.org> On Mon, Nov 16, 2009 at 07:55:43PM -0800, Toshio Kuratomi wrote: > On Sat, Nov 14, 2009 at 03:46:02PM +0000, Richard W.M. Jones wrote: > > On Sat, Nov 07, 2009 at 11:10:34AM -0600, Jason L Tibbitts III wrote: > > > However, some packagers absolutely insist on duplicating license files > > > (say, once in the main package, and again in the -devel package) and > > > this issue keeps coming up. > > > > And it'll keep coming up in future too. > > > > We are distributing binary packages which you can download > > independently from > > http://download.fedora.redhat.com/pub/fedora/linux/development/i386/os/Packages/ > > using just a web browser or 'wget'. Web browsers and wget don't > > understand RPM dependencies, and RPM files can be unpacked by a > > variety of software, not just the rpm program. > > > > Some of those binary packages have the license stripped from > > them. The GPLv2 clearly says you should not do this: > > > > 1. [...] and give any other recipients of the Program a copy of this > > License along with the Program. > > > So if legal says that it's okay to rely on rpm dependencies to do this for > us, you'd still insist on doing your own thing? If it was brought to their attention that there is other software that can unpack individual RPMs, and they gave a detailed response (not just "okay"), then I'd be interested in reading that response. Nuanced legal opinions are always interesting to read. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora From jonathan.underwood at gmail.com Tue Nov 17 10:40:03 2009 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Tue, 17 Nov 2009 10:40:03 +0000 Subject: [Fedora-packaging] Revised Emacs add-on guidelines In-Reply-To: <20091117041147.GC3153@clingman.lan> References: <645d17210911071305h88141f7s28a6a97622fea6ae@mail.gmail.com> <645d17210911080226s7930fae4t642be561d25d3727@mail.gmail.com> <645d17210911080230p3595e4d4y547bdbac8aa8f8f@mail.gmail.com> <645d17210911140540q59419e81l9dc19d9a0db2a973@mail.gmail.com> <20091117041147.GC3153@clingman.lan> Message-ID: <645d17210911170240v53ea4f86s29578b14f8870cf6@mail.gmail.com> 2009/11/17 Toshio Kuratomi : > On Sat, Nov 14, 2009 at 01:40:41PM +0000, Jonathan Underwood wrote: >> >> Incidentally, I looked for the committee minutes for recent FPC >> meetings, and the latest available ones are 09/09 - has the FPC >> stopped meeting, or is it just the the minutes haven't been posted? >> > We haven't been meeting -- I think it's because we finally got through all > of the pending Guideline changes. ?But with this on the docket, we'll need > to get together again :-) Ok, that's good to hear, thanks for clarifying. Incidentally, I notice the DraftsTodo table has two drafts labelled as "Next Meeting" and 4 others as "Discuss" so it's possible that a bit of a backlog has built up (or the table is out of date). J. From indigoblu at gmail.com Tue Nov 17 15:01:31 2009 From: indigoblu at gmail.com (Matt Sellers) Date: Tue, 17 Nov 2009 09:01:31 -0600 Subject: [Fedora-packaging] dont strip comments. Message-ID: <4208c80a0911170701p71246a04kefc1c09cb1139822@mail.gmail.com> Hi Everybody, I am trying to build a package that does not strip comments from the binary. example ( working ) : readelf -p .comment /usr/lib64/libnss_dns.so String dump of section '.comment': [ 1] GCC: (GNU) 4.3.2 20081105 (Red Hat 4.3.2-7) [ 2e] GCC: (GNU) 4.3.2 20081105 (Red Hat 4.3.2-7) [ 5b] GCC: (GNU) 4.3.2 20081105 (Red Hat 4.3.2-7) [ 88] GCC: (GNU) 4.3.2 20081105 (Red Hat 4.3.2-7) [ b5] GCC: (GNU) 4.3.2 20081105 (Red Hat 4.3.2-7) [ e2] GCC: (GNU) 4.3.2 20081105 (Red Hat 4.3.2-7) [ 10f] GCC: (GNU) 4.3.2 20081105 (Red Hat 4.3.2-7) [ 13c] GCC: (GNU) 4.3.2 20081105 (Red Hat 4.3.2-7) The binaries that I build with rpmbuild see to be stripped: readelf -p .comment /usr/local/lib64/testlib.so readelf: Warning: Section '.comment' was not dumped because it does not exist! I can see that the comments are there before the binary is stripped for packing. My goal is to have a package stripped of debug symbols but keep the .comment section intact. This seems to be performed by the script in /usr/lib/rpm/find-debug.sh using "eu-strip", and while hacking this script is easy, I would like to enable this functionality in a more sane fashion if possible. Any and all suggestions greatly appreciated! Thank You, Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From notting at redhat.com Tue Nov 17 15:45:15 2009 From: notting at redhat.com (Bill Nottingham) Date: Tue, 17 Nov 2009 10:45:15 -0500 Subject: [Fedora-packaging] daemons vs services In-Reply-To: References: Message-ID: <20091117154514.GB15334@nostromo.devel.redhat.com> Orcan Ogetbil (oget.fedora at gmail.com) said: > > By daemons, I meant more in the lines of those programs that run in > > the background, but do not put an initscript in /etc. > > Userspace daemons for instance. e.g. jack, pulseaudio type daemons... > > Ping? Another example would be gnome-settings-daemon. Don't they need > to be killed when they are uninstalled? If you are removing the running desktop out from under itself, I suspect this is the least of your problems. Bill From braden at endoframe.com Wed Nov 18 07:02:45 2009 From: braden at endoframe.com (Braden McDaniel) Date: Wed, 18 Nov 2009 02:02:45 -0500 Subject: [Fedora-packaging] Re: File path clarification In-Reply-To: <7286730f0911111142g14281202hb4b3322b29b62817@mail.gmail.com> References: <7286730f0911031000l50e7dcd9k3eb5260aa66b9317@mail.gmail.com> <7286730f0911100709y4bd7a8bbk86706c21f827d7c9@mail.gmail.com> <7286730f0911111142g14281202hb4b3322b29b62817@mail.gmail.com> Message-ID: <1258527765.15181.9.camel@localhost> On Wed, 2009-11-11 at 14:42 -0500, Rich Mattes wrote: > I've scoured the packaging guidelines once more, there's no mention of > when you should put libraries in %{_libdir} vs. when to create a > subdirectory in %{_libdir}. I got a little bit of feedback in my > package review request[1], but I'd appreciate more > formal clarification. > > Anyone? My understanding is that generally subdirectories of libdir are created for things that are dlopen'd. Otherwise, putting the .so in libdir is appropriate. -- Braden McDaniel From jdennis at redhat.com Wed Nov 18 17:34:05 2009 From: jdennis at redhat.com (John Dennis) Date: Wed, 18 Nov 2009 12:34:05 -0500 Subject: [Fedora-packaging] does removing a package also remove package data? Message-ID: <4B04300D.80205@redhat.com> I couldn't find this in the guidelines and I'm looking for clarification. When a package generates data as a consequence of it's runtime operation should the package data also be removed along with the package files when the package is uninstalled (i.e. rpm -e)? Issues: * It may be a user expectation that removing a package removes all the files associated with the package even if they are not package files (listed in %files). Most people remove packages because they don't want or need the package any more and don't want cruft left behind, they want a clean uninstall which recovers the maximum disk space possible without "orphans" * Generated data may have value after the package is removed, for some users it might be an unpleasant experience to discover after removing a package the data files were wiped out too. * It's not possible to query the user at uninstall time as to the disposition of data files because the uninstall (like install's) may be scripted. My inclination is the packaging guidelines should encourage the removal of data files generated by the package when the package is removed. Comments? -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From rdieter at math.unl.edu Wed Nov 18 17:45:08 2009 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 18 Nov 2009 11:45:08 -0600 Subject: [Fedora-packaging] does removing a package also remove package data? In-Reply-To: <4B04300D.80205@redhat.com> References: <4B04300D.80205@redhat.com> Message-ID: <4B0432A4.6070906@math.unl.edu> On 11/18/2009 11:34 AM, John Dennis wrote: > I couldn't find this in the guidelines and I'm looking for clarification. > > When a package generates data as a consequence of it's runtime operation > should the package data also be removed along with the package files > when the package is uninstalled (i.e. rpm -e)? > > Issues: > > * It may be a user expectation that removing a package removes all the > files associated with the package even if they are not package files > (listed in %files). Most people remove packages because they don't want > or need the package any more and don't want cruft left behind, they want > a clean uninstall which recovers the maximum disk space possible without > "orphans" > > * Generated data may have value after the package is removed, for some > users it might be an unpleasant experience to discover after removing a > package the data files were wiped out too. > > * It's not possible to query the user at uninstall time as to the > disposition of data files because the uninstall (like install's) may be > scripted. > > My inclination is the packaging guidelines should encourage the removal > of data files generated by the package when the package is removed. Packages, in general, should not create data outside of what's managed by %files. A crutch that could be beneficial here is prudent use of %ghost and/or %config(missingok) -- Rex From tgl at redhat.com Wed Nov 18 17:44:58 2009 From: tgl at redhat.com (Tom Lane) Date: Wed, 18 Nov 2009 12:44:58 -0500 Subject: [Fedora-packaging] does removing a package also remove package data? In-Reply-To: <4B04300D.80205@redhat.com> References: <4B04300D.80205@redhat.com> Message-ID: <22217.1258566298@sss.pgh.pa.us> John Dennis writes: > My inclination is the packaging guidelines should encourage the removal > of data files generated by the package when the package is removed. In the case of the database packages the longstanding policy is the opposite. I can see encouraging packagers to remove orphaned preference or configuration files, but not potentially-high-value user data. regards, tom lane From rdieter at math.unl.edu Wed Nov 18 17:49:17 2009 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 18 Nov 2009 11:49:17 -0600 Subject: [Fedora-packaging] does removing a package also remove package data? In-Reply-To: <22217.1258566298@sss.pgh.pa.us> References: <4B04300D.80205@redhat.com> <22217.1258566298@sss.pgh.pa.us> Message-ID: <4B04339D.3090508@math.unl.edu> On 11/18/2009 11:44 AM, Tom Lane wrote: > John Dennis writes: >> My inclination is the packaging guidelines should encourage the removal >> of data files generated by the package when the package is removed. > > In the case of the database packages the longstanding policy is the > opposite. I can see encouraging packagers to remove orphaned preference > or configuration files, but not potentially-high-value user data. whole-heartedly agree, it's something that really is best managed on a case-by-case basis (probably one reason why it's not in the guidelines... yet). -- Rex From tibbs at math.uh.edu Wed Nov 18 17:53:33 2009 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Wed, 18 Nov 2009 11:53:33 -0600 Subject: [Fedora-packaging] does removing a package also remove package data? In-Reply-To: <4B0432A4.6070906@math.unl.edu> (Rex Dieter's message of "Wed, 18 Nov 2009 11:45:08 -0600") References: <4B04300D.80205@redhat.com> <4B0432A4.6070906@math.unl.edu> Message-ID: >>>>> "RD" == Rex Dieter writes: RD> Packages, in general, should not create data outside of what's RD> managed by %files. Of course, the devil is in the specifics. I wouldn't expect that uninstalling a package would remove its logs, for example. I would hope that packagers would think about the data generated by the running code and consider whether there's a valid reason for keeping it around after the package is removed, or conversely whether removing it is likely to delete something that the user expects to keep. Actually deleting useful data is something to be avoided at all costs. I suspect that there's no other rules that could be applied other than common sense and the principle of least surprise. - J< From rjones at redhat.com Wed Nov 18 17:58:22 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Wed, 18 Nov 2009 17:58:22 +0000 Subject: [Fedora-packaging] does removing a package also remove package data? In-Reply-To: <4B04300D.80205@redhat.com> References: <4B04300D.80205@redhat.com> Message-ID: <20091118175822.GA23843@amd.home.annexia.org> Should just note here that dpkg is quite nuanced in how it removes packages compared to rpm: There are two states: normal removal of a package doesn't remove any configuration files. That's so you can reinstall a package and not have to reconfigure it. So called "purge" removes the configuration files too. I would think the same thing applies to removing generated data -- that there should be 3 states: remove just the package, remove the package and generated data, or remove the package and generated data and configuration files. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora From jdennis at redhat.com Wed Nov 18 18:02:53 2009 From: jdennis at redhat.com (John Dennis) Date: Wed, 18 Nov 2009 13:02:53 -0500 Subject: [Fedora-packaging] does removing a package also remove package data? In-Reply-To: <4B04339D.3090508@math.unl.edu> References: <4B04300D.80205@redhat.com> <22217.1258566298@sss.pgh.pa.us> <4B04339D.3090508@math.unl.edu> Message-ID: <4B0436CD.3080609@redhat.com> On 11/18/2009 12:49 PM, Rex Dieter wrote: > On 11/18/2009 11:44 AM, Tom Lane wrote: >> John Dennis writes: >>> My inclination is the packaging guidelines should encourage the removal >>> of data files generated by the package when the package is removed. >> >> In the case of the database packages the longstanding policy is the >> opposite. I can see encouraging packagers to remove orphaned preference >> or configuration files, but not potentially-high-value user data. > > whole-heartedly agree, it's something that really is best managed on a > case-by-case basis (probably one reason why it's not in the > guidelines... yet). Both Rex and Tom immediately converged on exactly the issue I was thinking about, database style packages. I can see a strong argument for preserving the content after package removal, if this is the precedence I think the guidelines should at least state this, but permit per-package interpretation as opposed to enforcing a mandate. However I can also see a strong argument for wanting a package to clean up after itself so that a user does not have to find every place a package has written files, which in many instances is not so easy to discern. The principle of least surprise might suggest removing a package removes everything associated with the package. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From skvidal at fedoraproject.org Wed Nov 18 18:02:22 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Wed, 18 Nov 2009 13:02:22 -0500 (EST) Subject: [Fedora-packaging] does removing a package also remove package data? In-Reply-To: <20091118175822.GA23843@amd.home.annexia.org> References: <4B04300D.80205@redhat.com> <20091118175822.GA23843@amd.home.annexia.org> Message-ID: On Wed, 18 Nov 2009, Richard W.M. Jones wrote: > > Should just note here that dpkg is quite nuanced in how it removes > packages compared to rpm: > > There are two states: normal removal of a package doesn't remove any > configuration files. That's so you can reinstall a package and not > have to reconfigure it. So called "purge" removes the configuration > files too. > > I would think the same thing applies to removing generated data -- > that there should be 3 states: remove just the package, remove the > package and generated data, or remove the package and generated data > and configuration files. If y'all want to change the behavior of an rpm -e then you need to talking to the rpm-maint list at rpm.org not here. -sv From wolfy at nobugconsulting.ro Thu Nov 19 04:55:31 2009 From: wolfy at nobugconsulting.ro (Manuel Wolfshant) Date: Thu, 19 Nov 2009 06:55:31 +0200 Subject: [Fedora-packaging] does removing a package also remove package data? In-Reply-To: <20091118175822.GA23843@amd.home.annexia.org> References: <4B04300D.80205@redhat.com> <20091118175822.GA23843@amd.home.annexia.org> Message-ID: <4B04CFC3.109@nobugconsulting.ro> On 11/18/2009 07:58 PM, Richard W.M. Jones wrote: > Should just note here that dpkg is quite nuanced in how it removes > packages compared to rpm: > > There are two states: normal removal of a package doesn't remove any > configuration files. That's so you can reinstall a package and not > have to reconfigure it. So called "purge" removes the configuration > files too. > > I would think the same thing applies to removing generated data -- > that there should be 3 states: remove just the package, great, let's just ignore %config(noreplace) / %config > remove the > package and generated data, I would be more than unpleasantly surprised if rpm -e mysql-server would remove the databases as well (you know, I might just want to move them to another server and I've started by removing the software first) or rpm -e rrdtool would remove all the collected / processed data. And so on, you get the drill. That is, unless you teach rpm about "--purge" or something similar, which should be neither default nor discussed on this list but in rpm's upstream. > or remove the package and generated data and configuration files. > From taljurf at fedoraproject.org Thu Nov 19 07:13:19 2009 From: taljurf at fedoraproject.org (Tareq Al Jurf) Date: Thu, 19 Nov 2009 10:13:19 +0300 Subject: [Fedora-packaging] How to patch against strip? Message-ID: <12d8a2fa0911182313h3de4350dg8306f471712d9671@mail.gmail.com> I'm building a package Probably the package?s ?make install? function invokes ?strip? on the binaries it produces. How do i patch the Makefile to not do that. Thanks in Advance -- Tareq Al Jurf Fedora Ambassador Riyadh, Saudi Arabia taljurf at fedoraproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From itamar at ispbrasil.com.br Thu Nov 19 07:26:19 2009 From: itamar at ispbrasil.com.br (Itamar Reis Peixoto) Date: Thu, 19 Nov 2009 05:26:19 -0200 Subject: [Fedora-packaging] How to patch against strip? In-Reply-To: <12d8a2fa0911182313h3de4350dg8306f471712d9671@mail.gmail.com> References: <12d8a2fa0911182313h3de4350dg8306f471712d9671@mail.gmail.com> Message-ID: On Thu, Nov 19, 2009 at 5:13 AM, Tareq Al Jurf wrote: > I'm building a package > Probably the package?s ?make install? function invokes ?strip? on the > binaries it produces. How do i patch the Makefile to not do that. > > Thanks in Advance > -- > Tareq Al Jurf > Fedora Ambassador > Riyadh, Saudi Arabia > taljurf at fedoraproject.org what package ? -- ------------ Itamar Reis Peixoto e-mail/msn/google talk/sip: itamar at ispbrasil.com.br skype: itamarjp icq: 81053601 +55 11 4063 5033 +55 34 3221 8599 From taljurf at fedoraproject.org Thu Nov 19 13:21:00 2009 From: taljurf at fedoraproject.org (Tareq Al Jurf) Date: Thu, 19 Nov 2009 16:21:00 +0300 Subject: [Fedora-packaging] https://www.redhat.com/archives/fedora-packaging/2009-November/msg00052.html Message-ID: <12d8a2fa0911190521x3da38571j8e01d68ec140b113@mail.gmail.com> The program is Invulgotracker 0.53.1 sorry if i opened a new thread because i'm using digest mode. -- Tareq Al Jurf Fedora Ambassador Riyadh, Saudi Arabia taljurf at fedoraproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: invulgotracker.spec Type: application/octet-stream Size: 1482 bytes Desc: not available URL: From rjones at redhat.com Thu Nov 19 19:40:37 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Thu, 19 Nov 2009 19:40:37 +0000 Subject: [Fedora-packaging] How to patch against strip? In-Reply-To: <12d8a2fa0911182313h3de4350dg8306f471712d9671@mail.gmail.com> References: <12d8a2fa0911182313h3de4350dg8306f471712d9671@mail.gmail.com> Message-ID: <20091119194037.GA3830@amd.home.annexia.org> On Thu, Nov 19, 2009 at 10:13:19AM +0300, Tareq Al Jurf wrote: > I'm building a package > Probably the package?s ?make install? function invokes ?strip? on the > binaries it produces. How do i patch the Makefile to not do that. You can redefine __strip in your RPM to another strip program or to /bin/true. However you should be cautious about doing this. We do it for legitimate reasons in Fedora MinGW packages, but are careful to invoke an alternate strip program that correctly strips Windows and Linux binaries (the default program strips Linux binaries and corrupts Windows binaries, hence the need for a replacement). Shipping a Fedora package that isn't stripped at all may contravene the guidelines, so it shouldn't be done lightly. You should also note that if you're having problems with strip corrupting your programs, then it's likely that you'll need to take steps to prevent prelink doing the same thing. (This is a problem with some older OCaml programs that I maintain). Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top From rc040203 at freenet.de Fri Nov 20 03:56:39 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 20 Nov 2009 04:56:39 +0100 Subject: [Fedora-packaging] code vs. content Message-ID: <4B061377.1080604@freenet.de> Hi, There is a package (london pictures) under review[1], which I consider to be a corner case wrt. "Code vs. content"[2]. The problem I have with this package providing a precedence of how to circumvent Fedora's regulations/guidelines etc. to use Fedora as means to distribute "mere content". In other words, I fear this package is a precedence to opens a can of worms for content packages. What to do about this package and about this issue in general? My gut feeling is, Fedora should refine their "code vs. content" rules, otherwise we will soon Fedora being filled up with arbitrary "photo/sound/video collections" disguised as "backgrounds", "sound fonts", etc. Ralf [1] https://bugzilla.redhat.com/show_bug.cgi?id=538557 [2] https://fedoraproject.org/wiki/Packaging:Guidelines#Code_Vs_Content From tibbs at math.uh.edu Fri Nov 20 04:53:59 2009 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Thu, 19 Nov 2009 22:53:59 -0600 Subject: [Fedora-packaging] code vs. content In-Reply-To: <4B061377.1080604@freenet.de> (Ralf Corsepius's message of "Fri, 20 Nov 2009 04:56:39 +0100") References: <4B061377.1080604@freenet.de> Message-ID: Just this morning I was noting ("complaining about", I guess) this on IRC. >>>>> "RC" == Ralf Corsepius writes: RC> The problem I have with this package providing a precedence of how RC> to circumvent Fedora's regulations/guidelines etc. to use Fedora as RC> means to distribute "mere content". Well, the interesting thing is that it's not this package which would provide the precedent. In fact, there are already several precedents in the distro, depending on which facet of the code vs. content issue you choose to examine. RC> What to do about this package and about this issue in general? All I know is that it's terribly difficult for anyone to finely define the boundary of acceptability here. Program documentation is obviously OK. What about programming documentation? A Perl tutorial or Dive into Python? A generic book on Java programming? It's not too far from there to all of Project Gutenberg, and it hasn't really been that long since the issue of books was discussed to death on fedora-devel. Not to mention that even if you could somehow accurately lay out a boundary of acceptability, you'd then have to turn around and address the issue of quality. I have to admit, though, that pictures of your favorite city or amphibian or whatever just don't seem to me to have much point, even if they are wrapped in the necessary bits so that they work as a screensaver. But then we ship a bunch of "*-backgrounds*" packages and nobody seems to complain. In the end, it isn't really up to FPC to make the policy on what's acceptable here, and if we're concerned about limiting the size of the distro then there's plenty of other cruft that you'd have to put up on the chopping block as well. I think FESCo is going to have to address this sooner or later, because it's not a big jump from some pictures of London to pictures of hot girls and who knows what else. For some reason this makes me wonder if we still patch out the "penis" configuration from the snake screensaver. - J< From rc040203 at freenet.de Fri Nov 20 05:30:50 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 20 Nov 2009 06:30:50 +0100 Subject: [Fedora-packaging] code vs. content In-Reply-To: References: <4B061377.1080604@freenet.de> Message-ID: <4B06298A.8060805@freenet.de> On 11/20/2009 05:53 AM, Jason L Tibbitts III wrote: > Just this morning I was noting ("complaining about", I guess) this on > IRC. > >>>>>> "RC" == Ralf Corsepius writes: > > RC> The problem I have with this package providing a precedence of how > RC> to circumvent Fedora's regulations/guidelines etc. to use Fedora as > RC> means to distribute "mere content". > > Well, the interesting thing is that it's not this package which would > provide the precedent. In fact, there are already several precedents in > the distro, depending on which facet of the code vs. content issue you > choose to examine. I wasn't aware about this. Which packages are you referring to? > RC> What to do about this package and about this issue in general? > > All I know is that it's terribly difficult for anyone to finely define > the boundary of acceptability here. Exactly. > Program documentation is obviously > OK. What about programming documentation? A Perl tutorial or Dive into > Python? A generic book on Java programming? It's not too far from > there to all of Project Gutenberg, and it hasn't really been that long > since the issue of books was discussed to death on fedora-devel. Not to > mention that even if you could somehow accurately lay out a boundary of > acceptability, you'd then have to turn around and address the issue of > quality. I for one, don't have much problems with such kind of content, as long as its somehow directly related to Linux and/or Fedora. > I have to admit, though, that pictures of your favorite city or > amphibian or whatever just don't seem to me to have much point, even if > they are wrapped in the necessary bits so that they work as a > screensaver. This is what I feel is going to happen here - Which "content collection" will be next? We should try to contact the tourism offices, marketing agencies and photographers all around the world and point them to the marketing opportunities Fedora offers to them. > But then we ship a bunch of "*-backgrounds*" packages and > nobody seems to complain. Well, may-be these packages should be revisited and re-reviewed? > In the end, it isn't really up to FPC to make the policy on what's > acceptable here, Agreed. Finding a solution would be FESCO's and/or FPB's job. > and if we're concerned about limiting the size of the > distro then there's plenty of other cruft that you'd have to put up on > the chopping block as well. I think FESCo is going to have to address > this sooner or later, because it's not a big jump from some pictures of > London to pictures of hot girls and who knows what else. > > For some reason this makes me wonder if we still patch out the "penis" > configuration from the snake screensaver. My concern isn't cultural issues/differences, mine is "mass" and "usefulness". Ralf From kanarip at kanarip.com Fri Nov 20 09:21:13 2009 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Fri, 20 Nov 2009 10:21:13 +0100 Subject: [Fedora-packaging] Obsoletes in renamed rubygem a blocker? Message-ID: <4B065F89.4070307@kanarip.com> Hi there, I've had rubygem-net-ldap packaged and deployed throughout my company, e.g. on all development workstations and on all dev/test/beta/prod servers. My company is letting me package this ruby gem for Fedora as well, along with a bunch of other ruby gems. During the review[1], M. Tasaka suggested the name should have been rubygem-ruby-net-ldap instead, and so I added an Obsoletes header for rubygem-net-ldap. This is now a blocker for M. Tasaka to approve the package, but if and when I remove it, and the new package is in Fedora I have to manually update all of approximately 40-50 development workstations and Fedora servers. I just need that Obsoletes header to be in the RPM, and that RPM with that header to be in the updates repository once. More details are in the review request[1], and I would appreciate your opinion on this Obsoletes header becoming a blocker. Kind regards, Jeroen van Meeuwen -kanarip [1] https://bugzilla.redhat.com/show_bug.cgi?id=532309 From loupgaroublond at gmail.com Fri Nov 20 12:22:45 2009 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Fri, 20 Nov 2009 13:22:45 +0100 Subject: [Fedora-packaging] code vs. content In-Reply-To: <4B061377.1080604@freenet.de> References: <4B061377.1080604@freenet.de> Message-ID: <7f692fec0911200422v4d319887oe874a0659724a708@mail.gmail.com> nn2009/11/20 Ralf Corsepius : > Hi, > > There is a package (london pictures) under review[1], which I consider to be > a corner case wrt. "Code vs. content"[2]. > > The problem I have with this package providing a precedence of how to > circumvent Fedora's regulations/guidelines etc. to use Fedora as means to > distribute "mere content". > > In other words, I fear this package is a precedence to opens a can of worms > for content packages. > > What to do about this package and about this issue in general? > > My gut feeling is, Fedora should refine their "code vs. content" rules, > otherwise we will soon Fedora being filled up with arbitrary > "photo/sound/video collections" disguised as "backgrounds", "sound fonts", > etc. This is really tricky since there's essentially a continuum from content that has no purpose in Fedora (project Gutenberg) to content that must be in fedora (default wallpapers). Just my 0.02 EUR in the situation, i wonder if it is a good idea to start up a third party repo, like the Repo-He-Who-Shall-Not-Be-Named that provides everything that's questionable from a purpose perspective. This could include packaging all the bits found in {gnome,kde}-look and similar sites. Then we can judge by how popular it is, and how the situation develops, how critical and necessary it is for Fedora's greater Purpose. I'd rather see the possibility to enable people to do this if they want than to categorically reject some idea, especially if it's done in a third party space. -Yaakov PS, i have to do something with those 2 eurocent coins i got in Germany, no one takes them here. From tibbs at math.uh.edu Fri Nov 20 14:13:06 2009 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Fri, 20 Nov 2009 08:13:06 -0600 Subject: [Fedora-packaging] Obsoletes in renamed rubygem a blocker? In-Reply-To: <4B065F89.4070307@kanarip.com> (Jeroen van Meeuwen's message of "Fri, 20 Nov 2009 10:21:13 +0100") References: <4B065F89.4070307@kanarip.com> Message-ID: >>>>> "JvM" == Jeroen van Meeuwen writes: JvM> More details are in the review request[1], and I would appreciate JvM> your opinion on this Obsoletes header becoming a blocker. I personally think that such things should indeed not be part of the Fedora repository. FPC actually discussed something similar to this; the results of that are Use of Epochs section: http://fedoraproject.org/wiki/Packaging:Guidelines#Use_of_Epochs Basically, you can carry over an epoch from a non-Fedora repository if it was "publicly accessible". I see package renames as essentially the same situation, although they certainly aren't as permanent as epochs so I can see room for considering them differently, and I'm sure we'd consider a proposal if someone wrote it up and submitted it. Finally, I really don't understand why there's a significant issue over this anyway. What would you have to do if any other package in your private repository entered the distribution under a different name? You wouldn't petition the maintainer to add an Obsoletes/Provides pair for you, you'd generate one yourself in your private repository and then transition to the Fedora package. - J< From giallu at gmail.com Fri Nov 20 15:00:15 2009 From: giallu at gmail.com (Gianluca Sforna) Date: Fri, 20 Nov 2009 16:00:15 +0100 Subject: [Fedora-packaging] How to patch against strip? In-Reply-To: <20091119194037.GA3830@amd.home.annexia.org> References: <12d8a2fa0911182313h3de4350dg8306f471712d9671@mail.gmail.com> <20091119194037.GA3830@amd.home.annexia.org> Message-ID: On Thu, Nov 19, 2009 at 8:40 PM, Richard W.M. Jones wrote: > On Thu, Nov 19, 2009 at 10:13:19AM +0300, Tareq Al Jurf wrote: >> I'm building a package >> Probably the package?s ?make install? function invokes ?strip? on the >> binaries it produces. How do i patch the Makefile to not do that. > > You can redefine __strip in your RPM to another strip program or to > /bin/true. ?However you should be cautious about doing this. > > We do it for legitimate reasons in Fedora MinGW packages, but are > careful to invoke an alternate strip program that correctly strips > Windows and Linux binaries (the default program strips Linux binaries > and corrupts Windows binaries, hence the need for a replacement). > > Shipping a Fedora package that isn't stripped at all may contravene > the guidelines, so it shouldn't be done lightly. > > You should also note that if you're having problems with strip > corrupting your programs, then it's likely that you'll need to take > steps to prevent prelink doing the same thing. ?(This is a problem > with some older OCaml programs that I maintain). Richard, I think he's just asking for help about where to look for avoid stripping his binaries _before_ RPM strips them and creates the debuginfo stuff. He's probably getting empty debuginfo packages at the moment and wants to fix the build. Tareq, is this the situation you're in? -- Gianluca Sforna http://morefedora.blogspot.com http://www.linkedin.com/in/gianlucasforna From taljurf at fedoraproject.org Fri Nov 20 17:09:14 2009 From: taljurf at fedoraproject.org (Tareq Al Jurf) Date: Fri, 20 Nov 2009 20:09:14 +0300 Subject: [Fedora-packaging] Re: How to patch against strip? Message-ID: <12d8a2fa0911200909s5d51c51x19fee8112b8e296b@mail.gmail.com> > > Richard, I think he's just asking for help about where to look for > avoid stripping his binaries _before_ RPM strips them and creates the > debuginfo stuff. > > He's probably getting empty debuginfo packages at the moment and wants > to fix the build. > > Tareq, is this the situation you're in? > Omg!! That's that's exactly my problem :) -- Tareq Al Jurf Fedora Ambassador Riyadh, Saudi Arabia taljurf at fedoraproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmalcolm at redhat.com Fri Nov 20 17:37:00 2009 From: dmalcolm at redhat.com (David Malcolm) Date: Fri, 20 Nov 2009 12:37:00 -0500 Subject: [Fedora-packaging] Proposal: support multiple Python minor versions Message-ID: <1258738620.27609.460.camel@brick> Proposal: support multiple Python minor version, as one instance of a generalized way of supporting variant stacks. Currently we support a single version of Python; we pick a specific minor-release of Python (currently "2.6", in fact 2.6.4 in rawhide), and all modules are assumed to be for that "2.MINOR" version of Python. We plan to extend this further in Fedora 13, with the idea that there's additionally a specific minor-release of Python 3 (currently "3.1", in fact 3.1.1), and all python3-foo rpms are assumed to be for that "3.MINOR" version of Python [1] Some people want more: they want additional minor versions: for example, when we want to upgrade "python" to mean "python 2.7", we will rebuild all our RPMs for 2.7, but some users may have code written to 2.6 that they don't want to bother porting. This makes more sense in an EPEL context: in EPEL5 we have the system python as "2.4", but many people want a "2.6" stack, others want "2.3", 2.5", "3.1", etc etc. There are ways of doing this within the current Fedora/EPEL packaging framework, but it would lead to an explosion of specfiles and CVS directories. I dislike this: I think of specfiles as human-readable source code for driving a reproducable build; I hate having many almost-identical copies of a source file. I had an idea for how this could be done whilst minimizing "specfile explosion"; it allows for the generation of parallel families of RPMs from one specfile, moving the complexity from the individual packager into the build system, and onto release-engineering (sorry Jesse!) - and eating up more disk space, build time, etc. Caveat: I haven't looked into the details of whether Koji, package CVS, and Makfile.common can actually cope with some of the ideas here, and I've not tested the specifics of the rpm macros; the proposal is independent of but compatible with the Python3 feature (I think). PROPOSAL: - Introduce the following new packaging macros: - "pyprefix": - defined as "python" for the system build of python - defined as "pythonMN" for a build of python-M.N e.g. "python26" for "python-2.6" - for use in the names of packages - "pysuffix": - defined as the empty string for the system build of python - defined as "-M.N" for builds of python-M.N e.g "-32" for "python-3.2" - for use in /usr/bin when giving alternative versions of tools e.g. "/usr/bin/pydoc-3.2" to be the python-3.2 version of "pydoc" - Within python-foo module specfiles and the python module packaging guidelines: - Add default definitions of the macros: %{!?pyprefix: %global pyprefix python} %{!?pysuffix: %global pysuffix} - Change: Name: python-foo to: Name: %{pyprefix}-foo and similarly for all dependencies, so that e.g.: BuildRequires: python-devel python-setuptools becomes: BuildRequires: %{pyprefix}-devel %{pyprefix}-setuptools - In %install, move scripts if necessary (to allow parallel-installability), adding: for script in foo bar baz ; do mv %{buildroot}/usr/bin/$script mv %{buildroot}/usr/bin/$script-%{pysuffix} done This gives us a single specfile, which can be used with different definitions of these macros to give multiple builds, leading to multiple SRPMs (the package changes name for the alternative builds). Where do these macros gets expanded out? Say in Koji's "dist-f14" we have python = python2.7 and python3 = python3.2, and we want to support alternative python stacks. Then for the dist-f14 build tags, introduce multiple new tags: dist-f14-altbuild-python23 dist-f14-altbuild-python24 dist-f14-altbuild-python25 dist-f14-altbuild-python26 dist-f14-altbuild-python30 dist-f14-altbuild-python31 Each of these "altbuild" tags inherit from the main dist-f14 build tag, adding a single RPM: "rpm-altbuild-macros-pythonMN-0.1-1.fc14" e.g. "rpm-altbuild-macros-python26-0.1-1.fc14" which contains a single file: /etc/rpm/altbuild-python26.macros (changing the version as appropriate), defining the macros: %global pyprefix python26 %global pysuffix -2.6 %global __python /usr/bin/python2.6 (need to ensure this last one actually gets used; need to move the define from rpm to python-devel) These Koji tags are in addition to the regular one ("dist-f14"), in which "python" and "python3" have their default meanings. All of these tags would deposit their built packages into dist-f14 Similarly, for EPEL5, extend "dist-5E-epel-testing-candidate", introducing multiple child tags: dist-5E-epel-testing-candidate-altbuild-python23 dist-5E-epel-testing-candidate-altbuild-python25 dist-5E-epel-testing-candidate-altbuild-python26 dist-5E-epel-testing-candidate-altbuild-python27 dist-5E-epel-testing-candidate-altbuild-python30 dist-5E-epel-testing-candidate-altbuild-python31 all of which would deposit their built packages into dist-5E-epel-testing-candidate For packaging CVS, add a new, optional file to a dist CVS subdirectory, "build-variability". So for package "python-foo", "python-foo/EL-5/build-variability" might contain these lines: dist-5E-epel-testing-candidate-altbuild-python23 dist-5E-epel-testing-candidate # 2.4 is the default in EPEL5 dist-5E-epel-testing-candidate-altbuild-python25 dist-5E-epel-testing-candidate-altbuild-python26 dist-5E-epel-testing-candidate-altbuild-python27 dist-5E-epel-testing-candidate-altbuild-python30 dist-5E-epel-testing-candidate-altbuild-python31 If "build-variability" is present, it would change the meaning of "make build": instead of triggering a job that does a single build into "dist-5E-epel-testing-candidate", it would create a job that builds into all of the build tags listed in the file. If any of these builds fail, the whole build fails, and no RPMs reach he destination tag. If a particular module only works with some minor-releases (perhaps it doesn't work with python 3 yet, or needs python>=2.4 etc), then the file would be edited appropriately. I have no great love for "build-variability" as a name. Caveat: I'm handwaving here; I haven't looked into the details of what it would take on the Koji side and to Makefile.common We'd be going from two dimensions of variability: - build architecture (i386, x86_64 etc; currently expressed internally in Koji) - OS release (devel, F12, EPEL5 etc) where we have a CVS directory per OS-release (one dimension) up to three dimensions of variability: - build architecture (i386, x86_64 etc) - OS release (devel, F12, EPEL5 etc) - Python minor release (2.3, 2.4, 2.5, 2.6, etc) whilst keeping just one CVS directory per OS-release; the package maintainer only has to edit a single specfile, and can attempt to ensure that it builds across all minor-releases he/she cares about; release-engineering would have a fair bit of extra complexity to deal with though. It may be necessary to add extra macros to the altbuild macro files so that specfiles can somehow easily conditionalize the build for altbuild variants matching some criteria (e.g. on altbuild for 2.6 and above, need this extra Patch3") I've tried to structure this so it can be reused for other language runtimes where we might want to support multiple versions; perhaps the Perl SIG would want a similar family of "altbuild" macros (I'm not a perl person so maybe I'm missing something here). The proposal only exposes a single extra dimension of variability; higher dimensionality seems to lead to combinatorial explosion (e.g sqlalchemy versions). It also assumes (perhaps overoptimistically) than these other language runtimes are independent, so that we never have collisions where e.g. something wants to consume both multiple python stacks and multiple perl stacks. This assumption fails for the case of e.g. multiple parallel versions of say postgres or httpd, etc where you might also want multiple versions of python, and multiple mod_pythons M * N combinatorial explosion [2] Thoughts? Total insanity? Dave [1] https://fedoraproject.org/wiki/Features/Python3F13 [2] so for e.g. python-psycopg2 you could unroll a 2-dimensional variability table into the file in dist-CVS, and into Koji tags, expressing all combinations of the postgres libs and of the python minor version; similarly for shipping multiple httpd versions versus python versions for mod_python. This many-dimensional approach quickly gets too complex to deal with, I think. From tibbs at math.uh.edu Fri Nov 20 17:47:04 2009 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Fri, 20 Nov 2009 11:47:04 -0600 Subject: [Fedora-packaging] Proposal: support multiple Python minor versions In-Reply-To: <1258738620.27609.460.camel@brick> (David Malcolm's message of "Fri, 20 Nov 2009 12:37:00 -0500") References: <1258738620.27609.460.camel@brick> Message-ID: >>>>> "DM" == David Malcolm writes: DM> Proposal: support multiple Python minor version, as one instance of DM> a generalized way of supporting variant stacks. Please note that it isn't for FPC to decide this. If FESCo tells us that this is wanted, FPC will work on the packaging guidelines to make this happen. FESCo has previously addressed and rejected precisely this proposal when Fedora switched to Python 2.5 and Zope could no longer be used (as it required 2.4, I believe). The rationale at the time (if I remember correctly, and I can be allowed to summarize) was that the Python maintainers did not wish for this to happen, and withhout their assent it would not be proper to force the burden of dealing with random "python" issues that have no relation to the version of the stack they maintain. Perhaps if proposed today FESCo's attitude would differ; I can't predict that. - J< From rjones at redhat.com Fri Nov 20 18:51:07 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Fri, 20 Nov 2009 18:51:07 +0000 Subject: [Fedora-packaging] code vs. content In-Reply-To: <4B061377.1080604@freenet.de> References: <4B061377.1080604@freenet.de> Message-ID: <20091120185107.GA10988@amd.home.annexia.org> On Fri, Nov 20, 2009 at 04:56:39AM +0100, Ralf Corsepius wrote: > There is a package (london pictures) under review[1], which I consider > to be a corner case wrt. "Code vs. content"[2]. > [1] https://bugzilla.redhat.com/show_bug.cgi?id=538557 I downloaded this package and looked at the pictures. Firstly, I have no objection to such a package. It's only 2.6 MB, and even if it "opens the floodgates" to having a corresponding package for every other city in the world, I wouldn't mind. However, the problem is that the pictures in this particular package are *rubbish*. (In some cases, they are pictures *of* rubbish!) Don't take my word for it, take a look for yourselves: http://annexia.org/tmp/londonpictures/ So I feel unfortunately this is a bad case. Superb, high-quality pictures from cities around the world would make a fantastic screensaver ... Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ From tibbs at math.uh.edu Fri Nov 20 19:02:05 2009 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Fri, 20 Nov 2009 13:02:05 -0600 Subject: [Fedora-packaging] code vs. content In-Reply-To: <20091120185107.GA10988@amd.home.annexia.org> (Richard W. M. Jones's message of "Fri, 20 Nov 2009 18:51:07 +0000") References: <4B061377.1080604@freenet.de> <20091120185107.GA10988@amd.home.annexia.org> Message-ID: >>>>> "RWMJ" == Richard W M Jones writes: RWMJ> So I feel unfortunately this is a bad case. Except that it's actually a spectacularly good case, because it perfectly illustrates the problem. Someone thinks this is a good package and wants it in Fedora. (Either that or they're actively trolling us to see what crap they can push through the review process.) It doesn't violate any guidelines. You happen to not like the content. Does that means the package stays out? I don't personally want to be the quality czar, but I also don't want to see people pushing their vacation photos into Fedora. Isn't there already a screensaver that will work from a directory of pictures? Isn't that good enough to cover all of these cases without us actually having to carry a bunch of pictures? - J< From limb at jcomserv.net Fri Nov 20 19:10:27 2009 From: limb at jcomserv.net (Jon Ciesla) Date: Fri, 20 Nov 2009 13:10:27 -0600 Subject: [Fedora-packaging] code vs. content In-Reply-To: References: <4B061377.1080604@freenet.de> <20091120185107.GA10988@amd.home.annexia.org> Message-ID: <4B06E9A3.6030105@jcomserv.net> Jason L Tibbitts III wrote: >>>>>> "RWMJ" == Richard W M Jones writes: >>>>>> > > RWMJ> So I feel unfortunately this is a bad case. > > Except that it's actually a spectacularly good case, because it > perfectly illustrates the problem. Someone thinks this is a good > package and wants it in Fedora. (Either that or they're actively > trolling us to see what crap they can push through the review process.) > It doesn't violate any guidelines. You happen to not like the content. > Does that means the package stays out? I don't personally want to be > the quality czar, but I also don't want to see people pushing their > vacation photos into Fedora. > > Isn't there already a screensaver that will work from a directory of > pictures? Isn't that good enough to cover all of these cases without us > actually having to carry a bunch of pictures? > > - J< > > -- > Fedora-packaging mailing list > Fedora-packaging at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-packaging > There is. I woke it up to read this. Works great. On any pictures I want, scads of formats. Now, write a new screensaver that does something different, and includes these pix as the default fodder for it, and you've got something else entirely. I'd err on the side of keeping this out. -J -- in your fear, seek only peace in your fear, seek only love -d. bowie From rjones at redhat.com Fri Nov 20 19:11:02 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Fri, 20 Nov 2009 19:11:02 +0000 Subject: [Fedora-packaging] code vs. content In-Reply-To: References: <4B061377.1080604@freenet.de> <20091120185107.GA10988@amd.home.annexia.org> Message-ID: <20091120191102.GA11140@amd.home.annexia.org> On Fri, Nov 20, 2009 at 01:02:05PM -0600, Jason L Tibbitts III wrote: > >>>>> "RWMJ" == Richard W M Jones writes: > > RWMJ> So I feel unfortunately this is a bad case. > > Except that it's actually a spectacularly good case, because it > perfectly illustrates the problem. Someone thinks this is a good > package and wants it in Fedora. (Either that or they're actively > trolling us to see what crap they can push through the review process.) > It doesn't violate any guidelines. You happen to not like the content. > Does that means the package stays out? I don't personally want to be > the quality czar, but I also don't want to see people pushing their > vacation photos into Fedora. No, I still think it's a bad case. Consider the cosmos screensaver that we carry: $ rpm -qf /usr/share/backgrounds/cosmos gnome-screensaver-2.28.0-1.fc12.x86_64 Those are some really beautiful NASA photographs, and I don't think anyone would object to the 3.9 MB consumed by those lovely pictures, particularly if you are in any way interested by space technology or science. I think if these were really beautiful pictures of London, no one would object to 2.6 MB. But because it's a bunch of rather crap pictures, it makes a bad case for what I think could potentially be a wonderful thing. > Isn't there already a screensaver that will work from a directory of > pictures? Isn't that good enough to cover all of these cases without us > actually having to carry a bunch of pictures? A directory of pictures isn't a hand-chosen set of great photographs that get installed from a single yum command. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones New in Fedora 11: Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 70 libraries supprt'd http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw From notting at redhat.com Fri Nov 20 19:23:24 2009 From: notting at redhat.com (Bill Nottingham) Date: Fri, 20 Nov 2009 14:23:24 -0500 Subject: [Fedora-packaging] code vs. content In-Reply-To: References: <4B061377.1080604@freenet.de> <20091120185107.GA10988@amd.home.annexia.org> Message-ID: <20091120192323.GA19353@nostromo.devel.redhat.com> Jason L Tibbitts III (tibbs at math.uh.edu) said: > Isn't there already a screensaver that will work from a directory of > pictures? Yes. > Isn't that good enough to cover all of these cases without us > actually having to carry a bunch of pictures? Maybe? I suspect the 'proper' solution is to implement a RSS-fed screensaver, so you can point it at whatever flickr/shutterfly/etc. feeds that you want. Bill From nicolas.mailhot at laposte.net Fri Nov 20 19:24:22 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 20 Nov 2009 20:24:22 +0100 Subject: [Fedora-packaging] code vs. content In-Reply-To: References: <4B061377.1080604@freenet.de> <20091120185107.GA10988@amd.home.annexia.org> Message-ID: <1258745062.30807.11.camel@arekh.okg> Le vendredi 20 novembre 2009 ? 13:02 -0600, Jason L Tibbitts III a ?crit : > You happen to not like the content. > Does that means the package stays out? I don't personally want to be > the quality czar, but I also don't want to see people pushing their > vacation photos into Fedora. I don't see why such decisions could not be pushed to the art team. They're responsible for the artistic decisions in Fedora. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From tibbs at math.uh.edu Fri Nov 20 19:36:30 2009 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Fri, 20 Nov 2009 13:36:30 -0600 Subject: [Fedora-packaging] code vs. content In-Reply-To: <20091120191102.GA11140@amd.home.annexia.org> (Richard W. M. Jones's message of "Fri, 20 Nov 2009 19:11:02 +0000") References: <4B061377.1080604@freenet.de> <20091120185107.GA10988@amd.home.annexia.org> <20091120191102.GA11140@amd.home.annexia.org> Message-ID: >>>>> "RWMJ" == Richard W M Jones writes: RWMJ> A directory of pictures isn't a hand-chosen set of great RWMJ> photographs that get installed from a single yum command. To someone, the londonpictures thing is a hand-chosen set of great photographs that get installed with a single yum command. You're just not that someone. - J< From rjones at redhat.com Fri Nov 20 19:53:28 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Fri, 20 Nov 2009 19:53:28 +0000 Subject: [Fedora-packaging] code vs. content In-Reply-To: References: <4B061377.1080604@freenet.de> <20091120185107.GA10988@amd.home.annexia.org> <20091120191102.GA11140@amd.home.annexia.org> Message-ID: <20091120195328.GA11422@amd.home.annexia.org> On Fri, Nov 20, 2009 at 01:36:30PM -0600, Jason L Tibbitts III wrote: > To someone, the londonpictures thing is a hand-chosen set of great > photographs [...] I don't want to go on arguing about this, but really this is different. I'm not being an "art ponce" and having some fine art debate about the londonpictures set. Even I can see that there are massive technical problems with them. This one has obvious aliasing problems, as if it was resized without using a decent scaling algorithm: http://annexia.org/tmp/londonpictures/londonpictures_01.jpg This one is a picture of a dog litter bin, with a camera flash and the photographer's shadow clearly visible: http://annexia.org/tmp/londonpictures/londonpictures_18.jpg No one (sane) would choose these as great photographs. So any argument around this particular set of photographs is going to be based on a poor example. I think it would be better to frame this in terms of good photographs. What if someone submitted a similar package, but with photos like these: http://commons.wikimedia.org/wiki/File:Palace_of_Westminster.jpg http://commons.wikimedia.org/wiki/File:London_Eye,_London.JPG http://commons.wikimedia.org/wiki/File:Tube_station_2_cz.jpg (Not just an RSS feed but a hand-picked selection of the best city photos from Wikicommons). Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://et.redhat.com/~rjones/libguestfs/ See what it can do: http://et.redhat.com/~rjones/libguestfs/recipes.html From tibbs at math.uh.edu Fri Nov 20 20:22:37 2009 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Fri, 20 Nov 2009 14:22:37 -0600 Subject: [Fedora-packaging] code vs. content In-Reply-To: <20091120195328.GA11422@amd.home.annexia.org> (Richard W. M. Jones's message of "Fri, 20 Nov 2009 19:53:28 +0000") References: <4B061377.1080604@freenet.de> <20091120185107.GA10988@amd.home.annexia.org> <20091120191102.GA11140@amd.home.annexia.org> <20091120195328.GA11422@amd.home.annexia.org> Message-ID: >>>>> "RWMJ" == Richard W M Jones writes: RWMJ> I don't want to go on arguing about this, but really this is RWMJ> different. The only difference I can see is that you personally like some photographs and don't like others, and you want to shift the discussion to photographs that you like. I can't comprehend what difference it makes to the underlying issue. I'm sure that it's easy to take photographs that satisfy all of those technical requirements you set out, with no aliasing problems, no visible camera flashes or photographer shadows, which would still elicit the same discussion. I have to agree with an earlier message in this thread: we have an art team, and I'd sure love to be able to defer to their opinion on this kind of thing. Of course, then you get into the tough issue of defining when something needs to be approved by the art team, and that's probably just as intractable a problem. - J< From a.badger at gmail.com Fri Nov 20 21:50:42 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 20 Nov 2009 13:50:42 -0800 Subject: [Fedora-packaging] Proposal: support multiple Python minor versions In-Reply-To: <1258738620.27609.460.camel@brick> References: <1258738620.27609.460.camel@brick> Message-ID: <20091120215042.GL6665@clingman.lan> On Fri, Nov 20, 2009 at 12:37:00PM -0500, David Malcolm wrote: > Proposal: support multiple Python minor version, as one instance of a > generalized way of supporting variant stacks. > > Currently we support a single version of Python; we pick a specific > minor-release of Python (currently "2.6", in fact 2.6.4 in rawhide), and > all modules are assumed to be for that "2.MINOR" version of Python. > > We plan to extend this further in Fedora 13, with the idea that there's > additionally a specific minor-release of Python 3 (currently "3.1", in > fact 3.1.1), and all python3-foo rpms are assumed to be for that > "3.MINOR" version of Python [1] > > > Some people want more: they want additional minor versions: for example, > when we want to upgrade "python" to mean "python 2.7", we will rebuild > all our RPMs for 2.7, but some users may have code written to 2.6 that > they don't want to bother porting. > > This makes more sense in an EPEL context: in EPEL5 we have the system > python as "2.4", but many people want a "2.6" stack, others want "2.3", > 2.5", "3.1", etc etc. > > There are ways of doing this within the current Fedora/EPEL packaging > framework, but it would lead to an explosion of specfiles and CVS > directories. I dislike this: I think of specfiles as human-readable > source code for driving a reproducable build; I hate having many > almost-identical copies of a source file. > > I had an idea for how this could be done whilst minimizing "specfile > explosion"; it allows for the generation of parallel families of RPMs > from one specfile, moving the complexity from the individual packager > into the build system, and onto release-engineering (sorry Jesse!) - and > eating up more disk space, build time, etc. > > Caveat: I haven't looked into the details of whether Koji, package CVS, > and Makfile.common can actually cope with some of the ideas here, and > I've not tested the specifics of the rpm macros; the proposal is > independent of but compatible with the Python3 feature (I think). > > PROPOSAL: > - Introduce the following new packaging macros: > - "pyprefix": > - defined as "python" for the system build of python > - defined as "pythonMN" for a build of python-M.N e.g. "python26" > for "python-2.6" > - for use in the names of packages > - "pysuffix": > - defined as the empty string for the system build of python > - defined as "-M.N" for builds of python-M.N e.g "-32" for > "python-3.2" > - for use in /usr/bin when giving alternative versions of tools e.g. > "/usr/bin/pydoc-3.2" to be the python-3.2 version of "pydoc" > > - Within python-foo module specfiles and the python module packaging > guidelines: > > - Add default definitions of the macros: > %{!?pyprefix: %global pyprefix python} > %{!?pysuffix: %global pysuffix} > > - Change: > Name: python-foo > to: > Name: %{pyprefix}-foo > > and similarly for all dependencies, so that e.g.: > BuildRequires: python-devel python-setuptools > becomes: > BuildRequires: %{pyprefix}-devel %{pyprefix}-setuptools > > - In %install, move scripts if necessary (to allow > parallel-installability), adding: > for script in foo bar baz ; do > mv %{buildroot}/usr/bin/$script mv > %{buildroot}/usr/bin/$script-%{pysuffix} > done > > This gives us a single specfile, which can be used with different > definitions of these macros to give multiple builds, leading to multiple > SRPMs (the package changes name for the alternative builds). > > Where do these macros gets expanded out? > > Say in Koji's "dist-f14" we have python = python2.7 and python3 = > python3.2, and we want to support alternative python stacks. > > Then for the dist-f14 build tags, introduce multiple new tags: > dist-f14-altbuild-python23 > dist-f14-altbuild-python24 > dist-f14-altbuild-python25 > dist-f14-altbuild-python26 > dist-f14-altbuild-python30 > dist-f14-altbuild-python31 > Each of these "altbuild" tags inherit from the main dist-f14 build tag, > adding a single RPM: "rpm-altbuild-macros-pythonMN-0.1-1.fc14" e.g. > "rpm-altbuild-macros-python26-0.1-1.fc14" which contains a single file: > /etc/rpm/altbuild-python26.macros > (changing the version as appropriate), defining the macros: > %global pyprefix python26 > %global pysuffix -2.6 > %global __python /usr/bin/python2.6 > (need to ensure this last one actually gets used; need to move the > define from rpm to python-devel) > > These Koji tags are in addition to the regular one ("dist-f14"), in > which "python" and "python3" have their default meanings. > > All of these tags would deposit their built packages into dist-f14 > > Similarly, for EPEL5, extend "dist-5E-epel-testing-candidate", > introducing multiple child tags: > dist-5E-epel-testing-candidate-altbuild-python23 > dist-5E-epel-testing-candidate-altbuild-python25 > dist-5E-epel-testing-candidate-altbuild-python26 > dist-5E-epel-testing-candidate-altbuild-python27 > dist-5E-epel-testing-candidate-altbuild-python30 > dist-5E-epel-testing-candidate-altbuild-python31 > all of which would deposit their built packages into > dist-5E-epel-testing-candidate > > For packaging CVS, add a new, optional file to a dist CVS subdirectory, > "build-variability". So for package "python-foo", > "python-foo/EL-5/build-variability" might contain these lines: > dist-5E-epel-testing-candidate-altbuild-python23 > dist-5E-epel-testing-candidate # 2.4 is the default in EPEL5 > dist-5E-epel-testing-candidate-altbuild-python25 > dist-5E-epel-testing-candidate-altbuild-python26 > dist-5E-epel-testing-candidate-altbuild-python27 > dist-5E-epel-testing-candidate-altbuild-python30 > dist-5E-epel-testing-candidate-altbuild-python31 > > If "build-variability" is present, it would change the meaning of "make > build": instead of triggering a job that does a single build into > "dist-5E-epel-testing-candidate", it would create a job that builds into > all of the build tags listed in the file. If any of these builds fail, > the whole build fails, and no RPMs reach he destination tag. > > If a particular module only works with some minor-releases (perhaps it > doesn't work with python 3 yet, or needs python>=2.4 etc), then the file > would be edited appropriately. > > I have no great love for "build-variability" as a name. > > Caveat: I'm handwaving here; I haven't looked into the details of what > it would take on the Koji side and to Makefile.common > > We'd be going from two dimensions of variability: > - build architecture (i386, x86_64 etc; currently expressed internally > in Koji) > - OS release (devel, F12, EPEL5 etc) > where we have a CVS directory per OS-release (one dimension) > > up to three dimensions of variability: > - build architecture (i386, x86_64 etc) > - OS release (devel, F12, EPEL5 etc) > - Python minor release (2.3, 2.4, 2.5, 2.6, etc) > whilst keeping just one CVS directory per OS-release; the package > maintainer only has to edit a single specfile, and can attempt to ensure > that it builds across all minor-releases he/she cares about; > release-engineering would have a fair bit of extra complexity to deal > with though. > > It may be necessary to add extra macros to the altbuild macro files so > that specfiles can somehow easily conditionalize the build for altbuild > variants matching some criteria (e.g. on altbuild for 2.6 and above, > need this extra Patch3") > > I've tried to structure this so it can be reused for other language > runtimes where we might want to support multiple versions; perhaps the > Perl SIG would want a similar family of "altbuild" macros (I'm not a > perl person so maybe I'm missing something here). > > The proposal only exposes a single extra dimension of variability; > higher dimensionality seems to lead to combinatorial explosion (e.g > sqlalchemy versions). > > It also assumes (perhaps overoptimistically) than these other language > runtimes are independent, so that we never have collisions where e.g. > something wants to consume both multiple python stacks and multiple perl > stacks. This assumption fails for the case of e.g. multiple parallel > versions of say postgres or httpd, etc where you might also want > multiple versions of python, and multiple mod_pythons M * N > combinatorial explosion [2] > > > Thoughts? Total insanity? > Yes, insanity! :-) But my objection is more along the implementation route taken rather than the general idea of multiple versions of python2. Right now, anyone can take an srpm, satisfy the BuildRequirements and a static list of build dependencies listed in a buildsys package and generate the builds. This proposal encodes some requirement information into the buildsystem so that you can't just build the package on your own system. Something that keeps all of the information in the SRPM is better. Also, this scheme would leave us forcing maintainers to, some extent care about multiple python versions. Even if, you only work with python3 and I only work with python2, if there's a bug preventing builds on one python version then the other person is partially blocked while that's being figured out. If one python version is requiring rebuilds to fix runtime bugs, users of the package on all python versions receive new packages because the build triggers package rebuilding for all versions. keeping binary rpms and srpms might be more difficult in this plan too. If python24-foo was built from python-foo-1.0-1 but python-foo-1.0-2 only builds python25-foo, do we reap the python24-foo and python-foo-1.0-1 SRPM from the repositories or do we leave them? I think if we do go for multiple python interpreter versions, having separate srpms is going to provide a better experience for managing the packages and for the end user. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From a.badger at gmail.com Fri Nov 20 22:38:41 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 20 Nov 2009 14:38:41 -0800 Subject: [Fedora-packaging] code vs. content In-Reply-To: <1258745062.30807.11.camel@arekh.okg> References: <4B061377.1080604@freenet.de> <20091120185107.GA10988@amd.home.annexia.org> <1258745062.30807.11.camel@arekh.okg> Message-ID: <20091120223841.GM6665@clingman.lan> On Fri, Nov 20, 2009 at 08:24:22PM +0100, Nicolas Mailhot wrote: > Le vendredi 20 novembre 2009 ? 13:02 -0600, Jason L Tibbitts III a > ?crit : > > You happen to not like the content. > > Does that means the package stays out? I don't personally want to be > > the quality czar, but I also don't want to see people pushing their > > vacation photos into Fedora. > > I don't see why such decisions could not be pushed to the art team. > They're responsible for the artistic decisions in Fedora. > Well... banning certain packages is a FESCo decision. they are welcome to delegate, though :-) I'd rather have a FESCo decision on what content is acceptable from FESCo, though. The art team can evaluate the quality of the art but that's not really waht we're after -- we want to know to what extent content is acceptable. Is it a free for all? Is it a must be releavant to computers? Is it relevant to computers or chosen by the art team? -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From rc040203 at freenet.de Sat Nov 21 03:31:04 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sat, 21 Nov 2009 04:31:04 +0100 Subject: [Fedora-packaging] code vs. content In-Reply-To: <7f692fec0911200422v4d319887oe874a0659724a708@mail.gmail.com> References: <4B061377.1080604@freenet.de> <7f692fec0911200422v4d319887oe874a0659724a708@mail.gmail.com> Message-ID: <4B075EF8.50301@freenet.de> On 11/20/2009 01:22 PM, Yaakov Nemoy wrote: > nn2009/11/20 Ralf Corsepius: >> Hi, >> >> There is a package (london pictures) under review[1], which I consider to be >> a corner case wrt. "Code vs. content"[2]. >> >> The problem I have with this package providing a precedence of how to >> circumvent Fedora's regulations/guidelines etc. to use Fedora as means to >> distribute "mere content". >> >> In other words, I fear this package is a precedence to opens a can of worms >> for content packages. >> >> What to do about this package and about this issue in general? >> >> My gut feeling is, Fedora should refine their "code vs. content" rules, >> otherwise we will soon Fedora being filled up with arbitrary >> "photo/sound/video collections" disguised as "backgrounds", "sound fonts", >> etc. > > This is really tricky since there's essentially a continuum from > content that has no purpose in Fedora (project Gutenberg) to content > that must be in fedora (default wallpapers). Just my 0.02 EUR in the > situation, i wonder if it is a good idea to start up a third party > repo, like the Repo-He-Who-Shall-Not-Be-Named that provides everything > that's questionable from a purpose perspective. Yes, this idea also had come to my mind. The more I think about it, the more I like it. However, I am having doubts if this would be practical and if it would have a long term perpective. Actually I'd expect such a repository to either starve out soon or to evolve into a huge Fedora "-media", "-tube", "-tunes", "-flickr" or similar. > This could include > packaging all the bits found in {gnome,kde}-look and similar sites. > Then we can judge by how popular it is, and how the situation > develops, how critical and necessary it is for Fedora's greater > Purpose. One problem would remain on Fedora's side: Where to draw the line between "contents allowed in Fedora" and "content not allowed in Fedora"? Ralf From nicolas.mailhot at laposte.net Sat Nov 21 09:42:06 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sat, 21 Nov 2009 10:42:06 +0100 Subject: [Fedora-packaging] code vs. content In-Reply-To: <4B075EF8.50301@freenet.de> References: <4B061377.1080604@freenet.de> <7f692fec0911200422v4d319887oe874a0659724a708@mail.gmail.com> <4B075EF8.50301@freenet.de> Message-ID: <1258796526.23753.13.camel@arekh.okg> Le samedi 21 novembre 2009 ? 04:31 +0100, Ralf Corsepius a ?crit : > On 11/20/2009 01:22 PM, Yaakov Nemoy wrote: > > This is really tricky since there's essentially a continuum from > > content that has no purpose in Fedora (project Gutenberg) to content > > that must be in fedora (default wallpapers). Just my 0.02 EUR in the > > situation, i wonder if it is a good idea to start up a third party > > repo, like the Repo-He-Who-Shall-Not-Be-Named that provides everything > > that's questionable from a purpose perspective. > Yes, this idea also had come to my mind. The more I think about it, the > more I like it. Well I don't, unless you decide to evaluate the "purpose" of every binary in Fedora. The "purpose" of "content" is that someone found it useful enough to jump through the hoops of Fedora packager sponsorship and Fedora review. Just like the "purpose" of a random binary. When you see the stuff that ends in the repo nowadays I don't see why "non-code" packagers should be guettoized just because they're not dealing with exalted code such as an nth broken music player, MUA, . The "code" vs "content" terminology is completely broken. No one really defined what "code" was. So people take "code" for "stuff produced by coders", and anything else, even if it's useful to our target audience, even if it's produced through a similar process to C code, even if it participates in the same "Free/Libre stuff" movement as code, is rejected, if the person producing does not call himself a "coder". OTOH if you are a "coder" you have free reign as long as you know someone ready to review you. PS Had someone packaged project Gutenberg cleanly in the past, I'm quite sure OLPC and edu Fedora spins would have been delighted. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From rc040203 at freenet.de Sat Nov 21 10:43:32 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sat, 21 Nov 2009 11:43:32 +0100 Subject: [Fedora-packaging] code vs. content In-Reply-To: <1258796526.23753.13.camel@arekh.okg> References: <4B061377.1080604@freenet.de> <7f692fec0911200422v4d319887oe874a0659724a708@mail.gmail.com> <4B075EF8.50301@freenet.de> <1258796526.23753.13.camel@arekh.okg> Message-ID: <4B07C454.7000404@freenet.de> On 11/21/2009 10:42 AM, Nicolas Mailhot wrote: > Le samedi 21 novembre 2009 ? 04:31 +0100, Ralf Corsepius a ?crit : >> On 11/20/2009 01:22 PM, Yaakov Nemoy wrote: > >>> This is really tricky since there's essentially a continuum from >>> content that has no purpose in Fedora (project Gutenberg) to content >>> that must be in fedora (default wallpapers). Just my 0.02 EUR in the >>> situation, i wonder if it is a good idea to start up a third party >>> repo, like the Repo-He-Who-Shall-Not-Be-Named that provides everything >>> that's questionable from a purpose perspective. >> Yes, this idea also had come to my mind. The more I think about it, the >> more I like it. > > Well I don't, unless you decide to evaluate the "purpose" of every > binary in Fedora. The "purpose" of "content" is that someone found it > useful enough to jump through the hoops of Fedora packager sponsorship > and Fedora review. You will always find somebody who finds any arbitrary content useful for something, ... > When you see the stuff that ends in the repo nowadays I don't see why > "non-code" packagers should be guettoized just because they're not > dealing with exalted code such as an nth broken music player, MUA, > . We are talking about _mere content_ packages, here, ie. strictly optional "eye/ear" candy packages, things like background package of "your favorite city", "your child", "your pet", "your car/house/boat", ... In this case, we are talking about somebody having submitted pictures of London as background images ... > The "code" vs "content" terminology is completely broken. No one really > defined what "code" was. Well, we had discussed this 100s of times before, however the topic is non-trivial. Ralf From nicolas.mailhot at laposte.net Sat Nov 21 11:26:35 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sat, 21 Nov 2009 12:26:35 +0100 Subject: [Fedora-packaging] code vs. content In-Reply-To: <4B07C454.7000404@freenet.de> References: <4B061377.1080604@freenet.de> <7f692fec0911200422v4d319887oe874a0659724a708@mail.gmail.com> <4B075EF8.50301@freenet.de> <1258796526.23753.13.camel@arekh.okg> <4B07C454.7000404@freenet.de> Message-ID: <1258802795.16422.5.camel@arekh.okg> Le samedi 21 novembre 2009 ? 11:43 +0100, Ralf Corsepius a ?crit : > On 11/21/2009 10:42 AM, Nicolas Mailhot wrote: > > Le samedi 21 novembre 2009 ? 04:31 +0100, Ralf Corsepius a ?crit : > > Well I don't, unless you decide to evaluate the "purpose" of every > > binary in Fedora. The "purpose" of "content" is that someone found it > > useful enough to jump through the hoops of Fedora packager sponsorship > > and Fedora review. > > You will always find somebody who finds any arbitrary content useful for > something, ... So what? You will always find somebody who finds any arbitrary binary useful > > When you see the stuff that ends in the repo nowadays I don't see why > > "non-code" packagers should be guettoized just because they're not > > dealing with exalted code such as an nth broken music player, MUA, > > . > > We are talking about _mere content_ packages, here, ie. strictly > optional "eye/ear" candy packages, things like background package of > "your favorite city", "your child", "your pet", "your car/house/boat", ... As opposed to _mere binary_ packages, ie strictly optional ego-gratification badly written binaries, things like yet another MUA, yet another music player, yet another id3 editor, wanda the fish or weyes, another cpu load viewer applet, etc? Get of your ivory tower, there is nothing in "content" that makes it magically less suitable than "code" for Fedora purposes (or the reverse) One of the "mere content" examples given in this thread, project Gutemberg, would be massively more useful than a lot of the "code" in Fedora today (if packaged properly) -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From loupgaroublond at gmail.com Sat Nov 21 11:26:38 2009 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Sat, 21 Nov 2009 12:26:38 +0100 Subject: [Fedora-packaging] code vs. content In-Reply-To: <4B075EF8.50301@freenet.de> References: <4B061377.1080604@freenet.de> <7f692fec0911200422v4d319887oe874a0659724a708@mail.gmail.com> <4B075EF8.50301@freenet.de> Message-ID: <7f692fec0911210326i6fda8215r88f44bef047ccc4e@mail.gmail.com> 2009/11/21 Ralf Corsepius : > On 11/20/2009 01:22 PM, Yaakov Nemoy wrote: >> >> nn2009/11/20 Ralf Corsepius: >>> >>> Hi, >>> >>> There is a package (london pictures) under review[1], which I consider to >>> be >>> a corner case wrt. "Code vs. content"[2]. >>> >>> The problem I have with this package providing a precedence of how to >>> circumvent Fedora's regulations/guidelines etc. to use Fedora as means to >>> distribute "mere content". >>> >>> In other words, I fear this package is a precedence to opens a can of >>> worms >>> for content packages. >>> >>> What to do about this package and about this issue in general? >>> >>> My gut feeling is, Fedora should refine their "code vs. content" rules, >>> otherwise we will soon Fedora being filled up with arbitrary >>> "photo/sound/video collections" disguised as "backgrounds", "sound >>> fonts", >>> etc. >> >> This is really tricky since there's essentially a continuum from >> content that has no purpose in Fedora (project Gutenberg) to content >> that must be in fedora (default wallpapers). Just my 0.02 EUR in the >> situation, i wonder if it is a good idea to start up a third party >> repo, like the Repo-He-Who-Shall-Not-Be-Named that provides everything >> that's questionable from a purpose perspective. > > Yes, this idea also had come to my mind. The more I think about it, the more > I like it. > > However, I am having doubts if this would be practical and if it would have > a long term perpective. > > Actually I'd expect such a repository to either starve out soon or to evolve > into a huge Fedora "-media", "-tube", "-tunes", "-flickr" or similar. That is exactly the idea. 1) It starves, and then we say, told you so, now get back to doing real packaging work. 2) It turns into a blob of a media repository, attracts a certain kind of attention and grows into its own project, i don't see anything wrong there either. This has some potential for alot of people, such as OLPC. Having Fedora's expertise on how to do packaging right means this project gets better quality too. 3) It finds a middle ground between the two. Now we're stuck with the tricky part where we have to evaluate if it fits in Fedora or not. The catch is we can't predict how it will develop though, so we can't even begin to discuss it. In all three scenarios, the idea is to let such a concept play out. Rather than trying to discuss it's merits now, just let it happen, and we can make a better decision later. > >> This could include >> packaging all the bits found in {gnome,kde}-look and similar sites. >> Then we can judge by how popular it is, and how the situation >> develops, how critical and necessary it is for Fedora's greater >> Purpose. > > One problem would remain on Fedora's side: Where to draw the line between > "contents allowed in Fedora" and "content not allowed in Fedora"? As long as there's a blessed third party repo (maybe we should call them second party repos), then if there's a doubt if it's really relevant, we can be conservative and say it doesn't belong in Fedora. Right now, the situation is that we're fussing around about where the line is. This is important because if something falls outside of the lines, then we don't include it, and we have nowhere clear for that kind of content to go. If we have an alternative destination, we're in a similar situation with the Repo Who Shall Not Be Named. Instead of saying, 'Sorry, No Dice', we can suggest, 'Try going here?'. There's no need to feel like we're being mean and obsessing about doing the wrong thing because both decisions are 'right'. (Disclaimer: Only if you believe in the idea of good and bad.) -Yaakov From giallu at gmail.com Sat Nov 21 13:45:32 2009 From: giallu at gmail.com (Gianluca Sforna) Date: Sat, 21 Nov 2009 14:45:32 +0100 Subject: [Fedora-packaging] Re: How to patch against strip? In-Reply-To: <12d8a2fa0911200909s5d51c51x19fee8112b8e296b@mail.gmail.com> References: <12d8a2fa0911200909s5d51c51x19fee8112b8e296b@mail.gmail.com> Message-ID: On Fri, Nov 20, 2009 at 6:09 PM, Tareq Al Jurf wrote: >> Richard, I think he's just asking for help about where to look for >> avoid stripping his binaries _before_ RPM strips them and creates the >> debuginfo stuff. >> >> He's probably getting empty debuginfo packages at the moment and wants >> to fix the build. >> >> Tareq, is this the situation you're in? > > Omg!! > That's that's exactly my problem :) I think the fix depend from the build system used by your package. If you can point us to a koji scratch build, or to the SRPM you are creating, I'm sure you could get some good suggestions. Please also consider asking in fedora-devel, where questions like this are more on-topic (this list is for discussions about the packaging guidelines) Cheers G. -- Gianluca Sforna http://morefedora.blogspot.com http://www.linkedin.com/in/gianlucasforna From debarshi.ray at gmail.com Sat Nov 21 13:53:43 2009 From: debarshi.ray at gmail.com (Debarshi Ray) Date: Sat, 21 Nov 2009 15:53:43 +0200 Subject: [Fedora-packaging] Re: How to patch against strip? In-Reply-To: <12d8a2fa0911200909s5d51c51x19fee8112b8e296b@mail.gmail.com> References: <12d8a2fa0911200909s5d51c51x19fee8112b8e296b@mail.gmail.com> Message-ID: <3170f42f0911210553m764ee556j1be96a7a421bbd5a@mail.gmail.com> > Omg!! > That's that's exactly my problem :) If the build system uses Autotools see if 'install -s' is being used somewhere or not. Cheers, Debarshi -- One reason that life is complex is that it has a real part and an imaginary part. -- Andrew Koenig From bruno at wolff.to Sat Nov 21 17:58:28 2009 From: bruno at wolff.to (Bruno Wolff III) Date: Sat, 21 Nov 2009 11:58:28 -0600 Subject: [Fedora-packaging] code vs. content In-Reply-To: <1258802795.16422.5.camel@arekh.okg> References: <4B061377.1080604@freenet.de> <7f692fec0911200422v4d319887oe874a0659724a708@mail.gmail.com> <4B075EF8.50301@freenet.de> <1258796526.23753.13.camel@arekh.okg> <4B07C454.7000404@freenet.de> <1258802795.16422.5.camel@arekh.okg> Message-ID: <20091121175828.GB27899@wolff.to> On Sat, Nov 21, 2009 at 12:26:35 +0100, Nicolas Mailhot wrote: > > Get of your ivory tower, there is nothing in "content" that makes it > magically less suitable than "code" for Fedora purposes (or the reverse) I think that some guidance might come out of who Fedora is for and what we are going to do for them discussions going on. > One of the "mere content" examples given in this thread, project > Gutemberg, would be massively more useful than a lot of the "code" in > Fedora today (if packaged properly) There are other interesting data sets that could also be put to interesting uses, for example the Tiger database covering roads and some other things in the US. I know of at least some databases with locations of municipal entities worldwide, and I haven't looked at this before Google started their mapping project, so there might be a lot more data available. From a.badger at gmail.com Sat Nov 21 18:59:25 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sat, 21 Nov 2009 10:59:25 -0800 Subject: [Fedora-packaging] code vs. content In-Reply-To: <7f692fec0911210326i6fda8215r88f44bef047ccc4e@mail.gmail.com> References: <4B061377.1080604@freenet.de> <7f692fec0911200422v4d319887oe874a0659724a708@mail.gmail.com> <4B075EF8.50301@freenet.de> <7f692fec0911210326i6fda8215r88f44bef047ccc4e@mail.gmail.com> Message-ID: <20091121185925.GC8087@clingman.lan> On Sat, Nov 21, 2009 at 12:26:38PM +0100, Yaakov Nemoy wrote: > > Actually I'd expect such a repository to either starve out soon or to evolve > > into a huge Fedora "-media", "-tube", "-tunes", "-flickr" or similar. > > That is exactly the idea. > > 1) It starves, and then we say, told you so, now get back to doing > real packaging work. > > 2) It turns into a blob of a media repository, attracts a certain kind > of attention and grows into its own project, i don't see anything > wrong there either. This has some potential for alot of people, such > as OLPC. Having Fedora's expertise on how to do packaging right means > this project gets better quality too. > > 3) It finds a middle ground between the two. Now we're stuck with the > tricky part where we have to evaluate if it fits in Fedora or not. The > catch is we can't predict how it will develop though, so we can't even > begin to discuss it. > > In all three scenarios, the idea is to let such a concept play out. > Rather than trying to discuss it's merits now, just let it happen, and > we can make a better decision later. > One technical point -- I don't think that Fedora rpm packaging is really the right technology for this. I don't think it scales to what we want. I don't know of any code-oriented packaging that would. Here are some of the limitations I see: * namespace: I package londonpictures. You also have pictures of london... what do you call your package? * repository size: How many individual photos are there on flikr? Potentially, we can have photo packages on that order of magnitude. * description and search: We're getting to the point where we have good searching via yum for packages. But how do we do the same thing for collections of photos? Let's say I want pictures of rubbish bins. How does that pull a single picture out of the londonpictures package? Is content useful? Yes, I think so. Should there be free software means of delivering content to others, yes I think so. Should there be a way to manage content on your computer? Yes, I think so. Is rpm packaging the right way to do that? No, I don't think so. Is the Fedora Project a venue where we can try to launch a free software means of doing this? I do think it fits in with our mission. I'm unsure of the overall benefit to our users (there *are* definite benefits in certain areas -- like being able to search Project Gutenberg, use a netbook like an ebook reader, have data for mapping software, etc) however, there might be other, distro neutral projects that we should work more closely with to achieve these goal -- for instance, partner with open street maps to let people upload and share mapping information there but provide a standard location for it to be on the filesystem, help code libraries and APIs to search and download them from the network to the local machine, and building desktop tools that use that information. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From loupgaroublond at gmail.com Sun Nov 22 14:05:49 2009 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Sun, 22 Nov 2009 15:05:49 +0100 (CET) Subject: [Fedora-packaging] code vs. content In-Reply-To: <20091121185925.GC8087@clingman.lan> Message-ID: 2009/11/21 Toshio Kuratomi : > On Sat, Nov 21, 2009 at 12:26:38PM +0100, Yaakov Nemoy wrote: >> > Actually I'd expect such a repository to either starve out soon or to evolve >> > into a huge Fedora "-media", "-tube", "-tunes", "-flickr" or similar. >> >> That is exactly the idea. >> >> 1) It starves, and then we say, told you so, now get back to doing >> real packaging work. >> >> 2) It turns into a blob of a media repository, attracts a certain kind >> of attention and grows into its own project, i don't see anything >> wrong there either. This has some potential for alot of people, such >> as OLPC. Having Fedora's expertise on how to do packaging right means >> this project gets better quality too. >> >> 3) It finds a middle ground between the two. Now we're stuck with the >> tricky part where we have to evaluate if it fits in Fedora or not. The >> catch is we can't predict how it will develop though, so we can't even >> begin to discuss it. >> >> In all three scenarios, the idea is to let such a concept play out. >> Rather than trying to discuss it's merits now, just let it happen, and >> we can make a better decision later. >> > One technical point -- I don't think that Fedora rpm packaging is really the > right technology for this. ?I don't think it scales to what we want. ?I > don't know of any code-oriented packaging that would. > > Here are some of the limitations I see: > * namespace: ?I package londonpictures. ?You also have pictures of london... > ?what do you call your package? > * repository size: ?How many individual photos are there on flikr? > ?Potentially, we can have photo packages on that order of magnitude. > * description and search: ?We're getting to the point where we have good > ?searching via yum for packages. ?But how do we do the same thing for > ?collections of photos? ?Let's say I want pictures of rubbish bins. ?How > ?does that pull a single picture out of the londonpictures package? Point taken. Can we agree this is just a technical issue though? > > Is content useful? ?Yes, I think so. ?Should there be free software means of > delivering content to others, yes I think so. ?Should there be a way to manage > content on your computer? ?Yes, I think so. ?Is rpm packaging the right way > to do that? ?No, I don't think so. ?Is the Fedora Project a venue where we > can try to launch a free software means of doing this? ?I do think it fits > in with our mission. ?I'm unsure of the overall benefit to our users (there > *are* definite benefits in certain areas -- like being able to search Project > Gutenberg, use a netbook like an ebook reader, have data for mapping > software, etc) ?however, there might be other, distro neutral projects that > we should work more closely with to achieve these goal -- for instance, > partner with open street maps to let people upload and share mapping > information there but provide a standard location for it to be on the > filesystem, help code libraries and APIs to search and download them from > the network to the local machine, and building desktop tools that use that > information. I'm thinking this might be a good candidate for a GSoC / Newcomer project. We can discuss it further, but if you find someone who's looking to become a new contributor somehow, i'm willing to mentor such an initiative. I think this goes beyond the scope of just creating another blessed third party repo but it's probably very useful in the end. -Yaakov -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 272 bytes Desc: OpenPGP digital signature URL: From a.badger at gmail.com Sun Nov 22 16:34:15 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sun, 22 Nov 2009 08:34:15 -0800 Subject: [Fedora-packaging] code vs. content In-Reply-To: References: <20091121185925.GC8087@clingman.lan> Message-ID: <20091122162332.GA3724@clingman.lan> On Sun, Nov 22, 2009 at 03:05:49PM +0100, Yaakov Nemoy wrote: > 2009/11/21 Toshio Kuratomi : > >One technical point -- I don't think that Fedora rpm packaging is really the > >right technology for this. ?I don't think it scales to what we want. ?I > >don't know of any code-oriented packaging that would. > > > Point taken. Can we agree this is just a technical issue though? > For me the big thing is the technical issue. > > > >Is content useful? ?Yes, I think so. ?Should there be free software means of > >delivering content to others, yes I think so. ?Should there be a way to manage > >content on your computer? ?Yes, I think so. ?Is rpm packaging the right way > >to do that? ?No, I don't think so. ?Is the Fedora Project a venue where we > >can try to launch a free software means of doing this? ?I do think it fits > >in with our mission. ?I'm unsure of the overall benefit to our users (there > >*are* definite benefits in certain areas -- like being able to search Project > >Gutenberg, use a netbook like an ebook reader, have data for mapping > >software, etc) ?however, there might be other, distro neutral projects that > >we should work more closely with to achieve these goal -- for instance, > >partner with open street maps to let people upload and share mapping > >information there but provide a standard location for it to be on the > >filesystem, help code libraries and APIs to search and download them from > >the network to the local machine, and building desktop tools that use that > >information. > > I'm thinking this might be a good candidate for a GSoC / Newcomer project. We can discuss it further, but if you find someone who's looking to become a new contributor somehow, i'm willing to mentor such an initiative. I think this goes beyond the scope of just creating another blessed third party repo but it's probably very useful in the end. > Possibly. But this is one which requires large amounts of non-coding skills. It's not about pure code here. There's a need to build something that crosses several different upstream projects. The data provider is the best place to host "packages". The other unixy distros need to be consulted to agree on where to put the files. Various desktop environments need to be influenced to agree on an API that the tools they promote can use. Actual coding parts of the project would be the library to access the data and creating the infrstructure upstream to take submissions of new data, search their data, and make sure their data can be retrieved programmatically (and scalably). -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From loupgaroublond at gmail.com Sun Nov 22 20:57:07 2009 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Sun, 22 Nov 2009 21:57:07 +0100 Subject: [Fedora-packaging] code vs. content In-Reply-To: <20091122162332.GA3724@clingman.lan> References: <20091121185925.GC8087@clingman.lan> <20091122162332.GA3724@clingman.lan> Message-ID: <7f692fec0911221257g1a9e8b4eh3f228da011a7866d@mail.gmail.com> 2009/11/22 Toshio Kuratomi : > On Sun, Nov 22, 2009 at 03:05:49PM +0100, Yaakov Nemoy wrote: >> 2009/11/21 Toshio Kuratomi : >> >One technical point -- I don't think that Fedora rpm packaging is really the >> >right technology for this. ?I don't think it scales to what we want. ?I >> >don't know of any code-oriented packaging that would. >> > >> Point taken. Can we agree this is just a technical issue though? >> > For me the big thing is the technical issue. > >> > >> >Is content useful? ?Yes, I think so. ?Should there be free software means of >> >delivering content to others, yes I think so. ?Should there be a way to manage >> >content on your computer? ?Yes, I think so. ?Is rpm packaging the right way >> >to do that? ?No, I don't think so. ?Is the Fedora Project a venue where we >> >can try to launch a free software means of doing this? ?I do think it fits >> >in with our mission. ?I'm unsure of the overall benefit to our users (there >> >*are* definite benefits in certain areas -- like being able to search Project >> >Gutenberg, use a netbook like an ebook reader, have data for mapping >> >software, etc) ?however, there might be other, distro neutral projects that >> >we should work more closely with to achieve these goal -- for instance, >> >partner with open street maps to let people upload and share mapping >> >information there but provide a standard location for it to be on the >> >filesystem, help code libraries and APIs to search and download them from >> >the network to the local machine, and building desktop tools that use that >> >information. >> >> I'm thinking this might be a good candidate for a GSoC / Newcomer project. We can discuss it further, but if you find someone who's looking to become a new contributor somehow, i'm willing to mentor such an initiative. ?I think this goes beyond the scope of just creating another blessed third party repo but it's probably very useful in the end. >> > Possibly. ?But this is one which requires large amounts of non-coding > skills. ?It's not about pure code here. ?There's a need to build something > that crosses several different upstream projects. ?The data provider is the > best place to host "packages". ?The other unixy distros need to be consulted > to agree on where to put the files. ?Various desktop environments need to be > influenced to agree on an API that the tools they promote can use. > > Actual coding parts of the project would be the library to access the data > and creating the infrstructure upstream to take submissions of new data, > search their data, and make sure their data can be retrieved > programmatically (and scalably). Depends on how the project is done. I'd rather take on a project with a new comer that is willing to work with both sides of the angle. I see a number of issues here. We need to decide how to take in various kinds of media, pictures, icons, annoying bleeps and bloops for the desktop, creative works such as window manager themes, and so on. We need to decide how to store it. How to deliver it to a particular machine (KDE has a decent example of this where you can go online to get new wallpaper). A way to manage the content stored on the machine. A way to mass deploy content. A way to manage 'collections' such as themes. All the nitty gritty file system details. How to do things system wide. Per Distro. etc... Part of this is just saying, 'we need', in a very general purpose manner, 'a system for sharing "content" that goes beyond packaging', and listen to the newcomer, potentially a GSoC student, to propose a plan that works. But that's my 0.02 cents. -Yaakov From ville.skytta at iki.fi Sun Nov 22 22:57:11 2009 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Mon, 23 Nov 2009 00:57:11 +0200 Subject: [Fedora-packaging] Re: How to patch against strip? In-Reply-To: <3170f42f0911210553m764ee556j1be96a7a421bbd5a@mail.gmail.com> References: <12d8a2fa0911200909s5d51c51x19fee8112b8e296b@mail.gmail.com> <3170f42f0911210553m764ee556j1be96a7a421bbd5a@mail.gmail.com> Message-ID: <200911230057.11263.ville.skytta@iki.fi> On Saturday 21 November 2009, Debarshi Ray wrote: > > Omg!! > > That's that's exactly my problem :) > > If the build system uses Autotools see if 'install -s' is being used > somewhere or not. See also the tips at http://fedoraproject.org/wiki/Packaging/Debuginfo From martial.paupe at metservice.com Mon Nov 23 03:09:54 2009 From: martial.paupe at metservice.com (Martial Paupe) Date: Mon, 23 Nov 2009 16:09:54 +1300 Subject: [Fedora-packaging] disttag doesn't work Message-ID: <200911231609.54269.martial.paupe@metservice.com> hello, I'm building packages and I want to use disttag as referred at this page. https://fedoraproject.org/wiki/Packaging:DistTag as a result the package is named as is packagename-1.0.0-1.noarch.rpm instead of packagename-1.0.0-1el5.noarch.rpm here the head of my specfile. Name: packagename Version: 1.0.0 Release: 1%{?dist} Summary: some text Group: application License: Propriatory URL: http://somewhere.domain.com Source0: %{name}-%{version}.tar.gz BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) BuildArch: noarch Conflicts: libgcj %description more text in these area %package binary Summary: packagename binary and library Group: System %if 0%{?rhel} >= 4 || 0%{?rhel} Requires: jre else Requires: java-1.6.0-openjdk Obsoletes: jre %endif Obsoletes: packagename-stack ...... ...... ...... ...... What I do wrong? Thanks for your help From tibbs at math.uh.edu Mon Nov 23 03:21:53 2009 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Sun, 22 Nov 2009 21:21:53 -0600 Subject: [Fedora-packaging] disttag doesn't work In-Reply-To: <200911231609.54269.martial.paupe@metservice.com> (Martial Paupe's message of "Mon, 23 Nov 2009 16:09:54 +1300") References: <200911231609.54269.martial.paupe@metservice.com> Message-ID: >>>>> "MP" == Martial Paupe writes: MP> hello, I'm building packages and I want to use disttag as referred MP> at this page. Note that page describes what works in the Fedora buildsystem. The %dist macro isn't going to be defined by default on most systems, although if you install the redhat-rpm-config package you should have it. Generally, for Fedora packaging you should probably just install the fedora-packager package which will pull in the above macros and various other useful things. - J< From christoph.wickert at googlemail.com Mon Nov 23 03:26:59 2009 From: christoph.wickert at googlemail.com (Christoph Wickert) Date: Mon, 23 Nov 2009 04:26:59 +0100 Subject: [Fedora-packaging] Naming guidelines: Parents & children Message-ID: <1258946819.2875.223.camel@wicktop.localdomain> Hi, I have packaged gtkhash [1]. The latest version comes with a nautilus extension that I'd like to package separately so gtkhash can be installed without GNOME/nautilus. I wonder what the proper name for the nautilus extension package is. gtkhash-nautilus-extension? gtkhash-nautilus? nautilus-gtkhash? The naming guidelines read [2]: "If a new package is considered an "addon" package that enhances or adds a new functionality to an existing Fedora package without being useful on its own, its name should reflect this fact." The extension is cannot be used without ether nautilus or gtkhash, so this wont help us to make a decision. From the "enhancement" point of view I'd say it's nautilus that gets enhanced, so the proper name would be nautilus-gtkhash. On the other hand gtkhash-nautilus(-extension) makes it easier to find the package in bugzilla. So the question is: What is the "parent"? The source package or the one that gets enhanced? This affects other nautilus packages as well. Currently we have: Package (Source package) * brasero-nautilus (brasero) * gnome-mplayer-nautilus (gnome-mplayer from "that other repo") * nautilus-actions (nautilus-actions) * nautilus-beesu-manager (beesu) * nautilus-bzr (bzr) * nautilus-extensions (nautilus) * nautilus-image-converter (no subpackage) * nautilus-open-terminal (nautilus-open-terminal) * nautilus-phatch (phatch) * nautilus-python (nautilus-python) * nautilus-search-tool (nautilus-search-tool) * nautilus-sendto (nautilus-sendto) * nautilus-sound-converter (nautilus-sound-converter) * tortoisehg-nautilus (tortoisehg) * totem-nautilus (totem) I think we should tighten the naming guidelines a little to make our package names more consistent, especially gnome-panel applets: Package (Upstream source name) * autobuild-applet (autobuild-applet) * contact-lookup-applet (contact-lookup-applet) * deskbar-applet (deskbar-applet) * file-browser-applet (file-browser-applet) * gdm-user-switch-applet (gdm) * gnome-applet-alarm-clock (alarmclock) * gnome-applet-bubblemon (bubblemon) * gnome-applet-cpufire (cpufire_applet) * gnome-applet-globalmenu (subpackage of gnome-globalmenu) * gnome-applet-grandr (grandr_applet) * gnome-applet-jalali-calendar (jalali-calendar) * gnome-applet-music (music-applet) * gnome-applet-netspeed (netspeed_applet) * gnome-applets * gnome-applet-sensors (sensors-applet) * gnome-applet-sshmenu (sshmenu) * gnome-applet-timer (timerapplet) * gnome-applet-window-picker (window-picker-applet) * hamster-applet (subpackage of hamster) * lock-keys-applet (lock-keys-applet) * resapplet (not an applet but a tray icon) * zapplet (not an applet but a tray icon) Proposal: 1. Leave tray icons as is. They can be used in all desktops. 2. Rename all gnome-panel applets to gnome-applet-* 3. Packages that don't match the upstream name get a "Provides: = %{version}" so they can be installed more easy Instead of 2. we could prefix all applets with "gnome-" and leave the upstream names intact. This is what we currently have in Xfce, upsteam has a consistent naming of their plugins, all are named xfce4-*-plugin. What do you think is best? Regards, Christoph [1] https://bugzilla.redhat.com/show_bug.cgi?id=540328 [2] http://fedoraproject.org/wiki/Packaging/NamingGuidelines#Addon_Packages_.28General.29 From christoph.wickert at googlemail.com Mon Nov 23 04:06:26 2009 From: christoph.wickert at googlemail.com (Christoph Wickert) Date: Mon, 23 Nov 2009 05:06:26 +0100 Subject: [Fedora-packaging] Re: How to patch against strip? In-Reply-To: <200911230057.11263.ville.skytta@iki.fi> References: <12d8a2fa0911200909s5d51c51x19fee8112b8e296b@mail.gmail.com> <3170f42f0911210553m764ee556j1be96a7a421bbd5a@mail.gmail.com> <200911230057.11263.ville.skytta@iki.fi> Message-ID: <1258949186.2875.225.camel@wicktop.localdomain> Am Montag, den 23.11.2009, 00:57 +0200 schrieb Ville Skytt?: > On Saturday 21 November 2009, Debarshi Ray wrote: > > > Omg!! > > > That's that's exactly my problem :) > > > > If the build system uses Autotools see if 'install -s' is being used > > somewhere or not. > > See also the tips at http://fedoraproject.org/wiki/Packaging/Debuginfo Thanks for the link, Ville. As Tareqs soon-to-be-sponsor I have already told him what to do. Regards, Christoph From martial.paupe at metservice.com Mon Nov 23 04:05:26 2009 From: martial.paupe at metservice.com (Martial Paupe) Date: Mon, 23 Nov 2009 17:05:26 +1300 Subject: [Fedora-packaging] disttag doesn't work In-Reply-To: References: <200911231609.54269.martial.paupe@metservice.com> Message-ID: <200911231705.26395.martial.paupe@metservice.com> On Monday 23 November 2009 16:21:53 Jason L Tibbitts III wrote: > >>>>> "MP" == Martial Paupe writes: > > MP> hello, I'm building packages and I want to use disttag as referred > MP> at this page. > > Note that page describes what works in the Fedora buildsystem. The > %dist macro isn't going to be defined by default on most systems, > although if you install the redhat-rpm-config package you should have > it. Have got that package (redhat-rpm-config-8.0.45-29.el5) but it's not working. How I can enable that on rhel5. > Generally, for Fedora packaging you should probably just install > the fedora-packager package which will pull in the above macros and > various other useful things. TA babatoko > > - J< > > -- > Fedora-packaging mailing list > Fedora-packaging at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-packaging > From oget.fedora at gmail.com Mon Nov 23 04:22:30 2009 From: oget.fedora at gmail.com (Orcan Ogetbil) Date: Sun, 22 Nov 2009 23:22:30 -0500 Subject: [Fedora-packaging] disttag doesn't work In-Reply-To: <200911231705.26395.martial.paupe@metservice.com> References: <200911231609.54269.martial.paupe@metservice.com> <200911231705.26395.martial.paupe@metservice.com> Message-ID: On Sun, Nov 22, 2009 at 11:05 PM, Martial Paupe wrote: > On Monday 23 November 2009 16:21:53 Jason L Tibbitts III wrote: >> >>>>> "MP" == Martial Paupe writes: >> >> MP> hello, I'm building packages and I want to use disttag as referred >> MP> at this page. >> >> Note that page describes what works in the Fedora buildsystem. ?The >> %dist macro isn't going to be defined by default on most systems, >> although if you install the redhat-rpm-config package you should have >> it. > Have got that package (redhat-rpm-config-8.0.45-29.el5) but it's not working. > How I can enable that on rhel5. > >> Generally, for Fedora packaging you should probably just install >> the fedora-packager package which will pull in the above macros and >> various other useful things. > The %dist macro is defined in /etc/rpm/macros.dist which (in Fedora) belongs to the fedora-release package. I don't know if you should install that package on rhel5. But you can define the %dist macro, or any macro in your ~/.rpmmacros file. just add this line: %dist el5 or something like that. Orcan From paul at city-fan.org Mon Nov 23 09:10:05 2009 From: paul at city-fan.org (Paul Howarth) Date: Mon, 23 Nov 2009 09:10:05 +0000 Subject: [Fedora-packaging] disttag doesn't work In-Reply-To: References: <200911231609.54269.martial.paupe@metservice.com> <200911231705.26395.martial.paupe@metservice.com> Message-ID: <20091123091005.113c2d4c@zion.intra.city-fan.org> On Sun, 22 Nov 2009 23:22:30 -0500 Orcan Ogetbil wrote: > On Sun, Nov 22, 2009 at 11:05 PM, Martial Paupe wrote: > > On Monday 23 November 2009 16:21:53 Jason L Tibbitts III wrote: > >> >>>>> "MP" == Martial Paupe writes: > >> > >> MP> hello, I'm building packages and I want to use disttag as > >> MP> referred at this page. > >> > >> Note that page describes what works in the Fedora buildsystem. ?The > >> %dist macro isn't going to be defined by default on most systems, > >> although if you install the redhat-rpm-config package you should > >> have it. > > Have got that package (redhat-rpm-config-8.0.45-29.el5) but it's > > not working. How I can enable that on rhel5. > > > >> Generally, for Fedora packaging you should probably just install > >> the fedora-packager package which will pull in the above macros and > >> various other useful things. > > > > The %dist macro is defined in /etc/rpm/macros.dist which (in Fedora) > belongs to the fedora-release package. I don't know if you should > install that package on rhel5. But you can define the %dist macro, or > any macro in your ~/.rpmmacros file. just add this line: > %dist el5 > or something like that. That would be: %dist .el5 (the leading dot is needed) This macro is not defined in any existing EL-5 package, only in the Fedora buildsystem, so unless you're building your packages using mock, you'll need this local macro definition. Paul. From sagarun at gmail.com Mon Nov 23 09:23:31 2009 From: sagarun at gmail.com (Arun SAG) Date: Mon, 23 Nov 2009 14:53:31 +0530 Subject: [Fedora-packaging] packaging Emacs-goodies - local mock build hangs running /usr/bin/idn Message-ID: Hi, I am trying to package emacs goodies for fedora, for some weird reason local mock build hangs running '/usr/bin/idn --quiet --idna-to-ascii --usestd3asciirules' (koji build was successful) . Any idea on how to fix this? Bugzilla url: https://bugzilla.redhat.com/show_bug.cgi?id=530090#c26 cheers, Arun S.A.G -------------- next part -------------- An HTML attachment was scrubbed... URL: From tmz at pobox.com Mon Nov 23 13:59:39 2009 From: tmz at pobox.com (Todd Zullinger) Date: Mon, 23 Nov 2009 08:59:39 -0500 Subject: [Fedora-packaging] disttag doesn't work In-Reply-To: <20091123091005.113c2d4c@zion.intra.city-fan.org> References: <200911231609.54269.martial.paupe@metservice.com> <200911231705.26395.martial.paupe@metservice.com> <20091123091005.113c2d4c@zion.intra.city-fan.org> Message-ID: <20091123135939.GN4509@inocybe.localdomain> Paul Howarth wrote: > That would be: > > %dist .el5 > > (the leading dot is needed) > > This macro is not defined in any existing EL-5 package, only in the > Fedora buildsystem, so unless you're building your packages using > mock, you'll need this local macro definition. Installing buildsys-macros from http://buildsys.fedoraproject.org/buildgroups/rhel5/i386/ is another alternative. That also provides %rhel and %el5 (well, %el$VERSION). -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ A fool's brain digests philosophy into folly, science into superstition, and art into pedantry. Hence University education. -- George Bernard Shaw -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From tcallawa at redhat.com Mon Nov 23 16:04:22 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Mon, 23 Nov 2009 11:04:22 -0500 Subject: [Fedora-packaging] Fedora Packaging Committee Meeting - Nov 24, 2009 - 1600 UTC Message-ID: <4B0AB286.1080805@redhat.com> The Fedora Packaging Committee will have its next meeting on Tuesday, November 24, 2009 @ 1600 UTC, in #fedora-meeting. Here is the tentative agenda: * pkgconfig autorequires: https://fedoraproject.org/wiki/PackagingDrafts/PkgconfigAutoRequires * Revised Emacs add-on guidelines: https://fedoraproject.org/wiki/PackagingDrafts/EmacsPackagingRevised * man-pages guidelines: https://fedoraproject.org/wiki/User:Varekova/man-pages/missing-man-pages * Python3 Guidelines: https://fedoraproject.org/wiki/PackagingDrafts/Python3 A reminder: If you have something that you want to get onto the FPC's agenda, the procedure is documented here: https://fedoraproject.org/wiki/Packaging:Committee#Guideline_Change_Procedure Thanks, ~spot From tcallawa at redhat.com Mon Nov 23 16:08:15 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Mon, 23 Nov 2009 11:08:15 -0500 Subject: [Fedora-packaging] Fedora Packaging Committee Meeting - Dec 2, 2009 - 1600 UTC In-Reply-To: <4B0AB286.1080805@redhat.com> References: <4B0AB286.1080805@redhat.com> Message-ID: <4B0AB36F.9090307@redhat.com> On 11/23/2009 11:04 AM, Tom "spot" Callaway wrote: > The Fedora Packaging Committee will have its next meeting on Tuesday, > November 24, 2009 @ 1600 UTC, in #fedora-meeting. Here is the tentative > agenda: Scratch that, this is wrong. I had forgotten that we'd moved to Wednesdays, and this coming Wednesday will not work due to the Thanksgiving holiday in the US. Lets try this again. The Fedora Packaging Committee will have its next meeting on Wednesday, December 2, 2009 @ 1600 UTC, in #fedora-meeting. Here is the tentative agenda: * pkgconfig autorequires: https://fedoraproject.org/wiki/PackagingDrafts/PkgconfigAutoRequires * Revised Emacs add-on guidelines: https://fedoraproject.org/wiki/PackagingDrafts/EmacsPackagingRevised * man-pages guidelines: https://fedoraproject.org/wiki/User:Varekova/man-pages/missing-man-pages * Python3 Guidelines: https://fedoraproject.org/wiki/PackagingDrafts/Python3 A reminder: If you have something that you want to get onto the FPC's agenda, the procedure is documented here: https://fedoraproject.org/wiki/Packaging:Committee#Guideline_Change_Procedure Thanks, ~spot From paul at city-fan.org Mon Nov 23 21:25:16 2009 From: paul at city-fan.org (Paul Howarth) Date: Mon, 23 Nov 2009 21:25:16 +0000 Subject: [Fedora-packaging] Fedora Packaging Committee Meeting - Dec 2, 2009 - 1600 UTC In-Reply-To: <4B0AB36F.9090307@redhat.com> References: <4B0AB286.1080805@redhat.com> <4B0AB36F.9090307@redhat.com> Message-ID: <20091123212516.50bafad3@city-fan.org> On Mon, 23 Nov 2009 11:08:15 -0500 "Tom \"spot\" Callaway" wrote: > On 11/23/2009 11:04 AM, Tom "spot" Callaway wrote: > > The Fedora Packaging Committee will have its next meeting on > > Tuesday, November 24, 2009 @ 1600 UTC, in #fedora-meeting. Here is > > the tentative agenda: > > Scratch that, this is wrong. I had forgotten that we'd moved to > Wednesdays, and this coming Wednesday will not work due to the > Thanksgiving holiday in the US. > > Lets try this again. > > The Fedora Packaging Committee will have its next meeting on > Wednesday, December 2, 2009 @ 1600 UTC, in #fedora-meeting. Here is > the tentative agenda: > > * pkgconfig autorequires: > https://fedoraproject.org/wiki/PackagingDrafts/PkgconfigAutoRequires A quick comment on this: if pkgconfig isn't an explicit dependency, what provides the ownership of the %{_libdir}/pkgconfig directory? If all packages with .pc files omit the pkgconfig dependency, there will be nothing actually pulling in pkgconfig itself, will there? Paul. From jussilehtola at fedoraproject.org Mon Nov 23 21:45:36 2009 From: jussilehtola at fedoraproject.org (Jussi Lehtola) Date: Mon, 23 Nov 2009 23:45:36 +0200 Subject: [Fedora-packaging] Fedora Packaging Committee Meeting - Dec 2, 2009 - 1600 UTC In-Reply-To: <20091123212516.50bafad3@city-fan.org> References: <4B0AB286.1080805@redhat.com> <4B0AB36F.9090307@redhat.com> <20091123212516.50bafad3@city-fan.org> Message-ID: <1259012736.18353.1.camel@localhost> On Mon, 2009-11-23 at 21:25 +0000, Paul Howarth wrote: > On Mon, 23 Nov 2009 11:08:15 -0500 > "Tom \"spot\" Callaway" wrote: > > * pkgconfig autorequires: > > https://fedoraproject.org/wiki/PackagingDrafts/PkgconfigAutoRequires > > A quick comment on this: if pkgconfig isn't an explicit dependency, > what provides the ownership of the %{_libdir}/pkgconfig directory? > > If all packages with .pc files omit the pkgconfig dependency, there > will be nothing actually pulling in pkgconfig itself, will there? RPM creates automatically a Requires: pkgconfig (actually, I think it is Requires: /usr/bin/pkg-config, which resolves to pkgconfig) for packages that contain .pc files. So the %{_libdir}/pkgconfig dir ownership is OK. -- Jussi Lehtola Fedora Project Contributor jussilehtola at fedoraproject.org From a.badger at gmail.com Mon Nov 23 22:32:18 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 23 Nov 2009 14:32:18 -0800 Subject: [Fedora-packaging] Fedora Packaging Committee Meeting - Dec 2, 2009 - 1600 UTC In-Reply-To: <20091123212516.50bafad3@city-fan.org> References: <4B0AB286.1080805@redhat.com> <4B0AB36F.9090307@redhat.com> <20091123212516.50bafad3@city-fan.org> Message-ID: <20091123223218.GI3724@clingman.lan> On Mon, Nov 23, 2009 at 09:25:16PM +0000, Paul Howarth wrote: > On Mon, 23 Nov 2009 11:08:15 -0500 > "Tom \"spot\" Callaway" wrote: > > > On 11/23/2009 11:04 AM, Tom "spot" Callaway wrote: > > > The Fedora Packaging Committee will have its next meeting on > > > Tuesday, November 24, 2009 @ 1600 UTC, in #fedora-meeting. Here is > > > the tentative agenda: > > > > Scratch that, this is wrong. I had forgotten that we'd moved to > > Wednesdays, and this coming Wednesday will not work due to the > > Thanksgiving holiday in the US. > > > > Lets try this again. > > > > The Fedora Packaging Committee will have its next meeting on > > Wednesday, December 2, 2009 @ 1600 UTC, in #fedora-meeting. Here is > > the tentative agenda: > > > > * pkgconfig autorequires: > > https://fedoraproject.org/wiki/PackagingDrafts/PkgconfigAutoRequires > > A quick comment on this: if pkgconfig isn't an explicit dependency, > what provides the ownership of the %{_libdir}/pkgconfig directory? > > If all packages with .pc files omit the pkgconfig dependency, there > will be nothing actually pulling in pkgconfig itself, will there? > pkgconfig should now be an automatic dependency. If you know of any corner cases where rpm doesn't autodetect, we should note those. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From martial.paupe at metservice.com Tue Nov 24 00:43:40 2009 From: martial.paupe at metservice.com (Martial Paupe) Date: Tue, 24 Nov 2009 13:43:40 +1300 Subject: [Fedora-packaging] disttag doesn't work In-Reply-To: <20091123091005.113c2d4c@zion.intra.city-fan.org> References: <200911231609.54269.martial.paupe@metservice.com> <20091123091005.113c2d4c@zion.intra.city-fan.org> Message-ID: <200911241343.40162.martial.paupe@metservice.com> > > This macro is not defined in any existing EL-5 package, only in the > Fedora buildsystem, so unless you're building your packages using mock, > you'll need this local macro definition. > Ok I see. Thanks for the help babatoko > Paul. > > -- > Fedora-packaging mailing list > Fedora-packaging at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-packaging > From Fedora at FamilleCollet.com Tue Nov 24 06:17:35 2009 From: Fedora at FamilleCollet.com (Remi Collet) Date: Tue, 24 Nov 2009 07:17:35 +0100 Subject: [Fedora-packaging] Fedora Packaging Committee Meeting - Dec 2, 2009 - 1600 UTC In-Reply-To: <4B0AB36F.9090307@redhat.com> References: <4B0AB286.1080805@redhat.com> <4B0AB36F.9090307@redhat.com> Message-ID: <4B0B7A7F.4020903@FamilleCollet.com> Le 23/11/2009 17:08, Tom "spot" Callaway a ?crit : > The Fedora Packaging Committee will have its next meeting on Wednesday, > December 2, 2009 @ 1600 UTC, in #fedora-meeting. Here is the tentative > agenda: I've add to the TODO discussion list : https://fedoraproject.org/wiki/PackagingDrafts/PHP There is 3 minor updates to the Guideline (to be clearer) - subfolder (in /usr/share/php) - ABI Check (for C extension, not only PECL official one) - additional comment (about scriptlet) And an FPC decision seems necessary about package name - most of old packages (>70) use only - (ex php-pear-Auth-SASL) - some recent packages use mixed - and _ (ex php-pear-Auth_HTTP) See https://www.redhat.com/archives/fedora-php-devel-list/2009-July/thread.html I should be available to discuss this if needed. Regards From tcallawa at redhat.com Tue Nov 24 16:53:04 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 24 Nov 2009 11:53:04 -0500 Subject: [Fedora-packaging] Fedora Packaging Committee Meeting - Dec 2, 2009 - 1600 UTC In-Reply-To: <4B0B7A7F.4020903@FamilleCollet.com> References: <4B0AB286.1080805@redhat.com> <4B0AB36F.9090307@redhat.com> <4B0B7A7F.4020903@FamilleCollet.com> Message-ID: <4B0C0F70.2060205@redhat.com> On 11/24/2009 01:17 AM, Remi Collet wrote: > And an FPC decision seems necessary about package name > - most of old packages (>70) use only - (ex php-pear-Auth-SASL) > - some recent packages use mixed - and _ (ex php-pear-Auth_HTTP) > See > https://www.redhat.com/archives/fedora-php-devel-list/2009-July/thread.html FWIW, I'd prefer the underscore not be used, but the guidelines currently permit it, assuming it is inherited from upstream's naming. However, given that practically all other packaged PHP modules use -, I could see the merit in requiring PHP packages to replace - with _. Is that what the PHP SIG is asking for FPC to approve? ~spot From rc040203 at freenet.de Tue Nov 24 17:11:04 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 24 Nov 2009 18:11:04 +0100 Subject: [Fedora-packaging] Fedora Packaging Committee Meeting - Dec 2, 2009 - 1600 UTC In-Reply-To: <4B0C0F70.2060205@redhat.com> References: <4B0AB286.1080805@redhat.com> <4B0AB36F.9090307@redhat.com> <4B0B7A7F.4020903@FamilleCollet.com> <4B0C0F70.2060205@redhat.com> Message-ID: <4B0C13A8.1050909@freenet.de> On 11/24/2009 05:53 PM, Tom "spot" Callaway wrote: > On 11/24/2009 01:17 AM, Remi Collet wrote: >> And an FPC decision seems necessary about package name >> - most of old packages (>70) use only - (ex php-pear-Auth-SASL) >> - some recent packages use mixed - and _ (ex php-pear-Auth_HTTP) >> See >> https://www.redhat.com/archives/fedora-php-devel-list/2009-July/thread.html > > FWIW, I'd prefer the underscore not be used, Would you mind to explain? I am not aware about any technical reason for disallowing underscores. Ralf From tcallawa at redhat.com Tue Nov 24 17:20:59 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 24 Nov 2009 12:20:59 -0500 Subject: [Fedora-packaging] Fedora Packaging Committee Meeting - Dec 2, 2009 - 1600 UTC In-Reply-To: <4B0C13A8.1050909@freenet.de> References: <4B0AB286.1080805@redhat.com> <4B0AB36F.9090307@redhat.com> <4B0B7A7F.4020903@FamilleCollet.com> <4B0C0F70.2060205@redhat.com> <4B0C13A8.1050909@freenet.de> Message-ID: <4B0C15FB.3070004@redhat.com> On 11/24/2009 12:11 PM, Ralf Corsepius wrote: > I am not aware about any technical reason for disallowing underscores. I'm not aware of any technical reason either. It is a personal preference, I think it makes the packages have a cleaner naming scheme. Accordingly, I have never pushed for it to be a requirement that _ not be used when upstream uses it in its naming, but if the PHP SIG asked for us to amend the PHP naming guidelines to exclude it, I would consider it. ~spot From rc040203 at freenet.de Tue Nov 24 17:37:27 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 24 Nov 2009 18:37:27 +0100 Subject: [Fedora-packaging] Fedora Packaging Committee Meeting - Dec 2, 2009 - 1600 UTC In-Reply-To: <4B0C15FB.3070004@redhat.com> References: <4B0AB286.1080805@redhat.com> <4B0AB36F.9090307@redhat.com> <4B0B7A7F.4020903@FamilleCollet.com> <4B0C0F70.2060205@redhat.com> <4B0C13A8.1050909@freenet.de> <4B0C15FB.3070004@redhat.com> Message-ID: <4B0C19D7.4040206@freenet.de> On 11/24/2009 06:20 PM, Tom "spot" Callaway wrote: > On 11/24/2009 12:11 PM, Ralf Corsepius wrote: >> I am not aware about any technical reason for disallowing underscores. > > I'm not aware of any technical reason either. It is a personal > preference, I think it makes the packages have a cleaner naming scheme. As you say, it's a matter of personal preference => insufficient rationale. > Accordingly, I have never pushed for it to be a requirement that _ not > be used when upstream uses it in its naming, but if the PHP SIG asked > for us to amend the PHP naming guidelines to exclude it, I would > consider it. Then they should better elaborate their rationale. I for one am opposed to any "transliteration", which isn't motivated by strong technical reasons, because they only add further confusion. Ralf From Fedora at FamilleCollet.com Tue Nov 24 17:44:42 2009 From: Fedora at FamilleCollet.com (Remi Collet) Date: Tue, 24 Nov 2009 18:44:42 +0100 Subject: [Fedora-packaging] Fedora Packaging Committee Meeting - Dec 2, 2009 - 1600 UTC In-Reply-To: <4B0C15FB.3070004@redhat.com> References: <4B0AB286.1080805@redhat.com> <4B0AB36F.9090307@redhat.com> <4B0B7A7F.4020903@FamilleCollet.com> <4B0C0F70.2060205@redhat.com> <4B0C13A8.1050909@freenet.de> <4B0C15FB.3070004@redhat.com> Message-ID: <4B0C1B8A.8060008@FamilleCollet.com> Le 24/11/2009 18:20, Tom "spot" Callaway a ?crit : > On 11/24/2009 12:11 PM, Ralf Corsepius wrote: >> I am not aware about any technical reason for disallowing underscores. > > I'm not aware of any technical reason either. It is a personal > preference, I think it makes the packages have a cleaner naming scheme. I agree (when - and _ are present at the same time, make name really awful IMHO) > Accordingly, I have never pushed for it to be a requirement that _ not > be used when upstream uses it in its naming, but if the PHP SIG asked > for us to amend the PHP naming guidelines to exclude it, I would > consider it. There is no censensus about this (if you have some time to read the thread linked in the previous message) First old packages (imported when the general Guidelines wasn't clear, and probably to do like perl packages) use only - (more than 70, ex php-pear-Auth-SASL) Some New recent packages use both (ex php-pear-Auth_HTTP) So I think decision go to FPC and must be written in the PHP Guidelines Choice : 1- package must use only - 2- package must use - at the beginning (php-pear-) and _ at the end 3- package could use - or _ according to packager pref. And I think maintainers are not ready to enter a massive rename plan. I'm waiting for this before submiting new review (at least 4 packages). + > > ~spot > > -- > Fedora-packaging mailing list > Fedora-packaging at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-packaging > From tcallawa at redhat.com Tue Nov 24 17:49:21 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 24 Nov 2009 12:49:21 -0500 Subject: [Fedora-packaging] Fedora Packaging Committee Meeting - Dec 2, 2009 - 1600 UTC In-Reply-To: <4B0C1B8A.8060008@FamilleCollet.com> References: <4B0AB286.1080805@redhat.com> <4B0AB36F.9090307@redhat.com> <4B0B7A7F.4020903@FamilleCollet.com> <4B0C0F70.2060205@redhat.com> <4B0C13A8.1050909@freenet.de> <4B0C15FB.3070004@redhat.com> <4B0C1B8A.8060008@FamilleCollet.com> Message-ID: <4B0C1CA1.40602@redhat.com> On 11/24/2009 12:44 PM, Remi Collet wrote: > So I think decision go to FPC and must be written in the PHP Guidelines > > Choice : > 1- package must use only - > 2- package must use - at the beginning (php-pear-) and _ at the end > 3- package could use - or _ according to packager pref. Well, the way the guidelines are now is that _ can only be used as part of the upstream name, and not as a separator. So, if the upstream name is HTML_Javascript, then the package can be either: php-pear-HTML_Javascript or php-pear-HTML-Javascript depending on the packager's preference. However, php_pear_HTML_Javascript is not acceptable, because _ should never be used as a separator. Unless you're proposing that PHP be excepted from these rules, I'm inclined to simply leave the guidelines as is. ~spot From Fedora at FamilleCollet.com Tue Nov 24 18:29:10 2009 From: Fedora at FamilleCollet.com (Remi Collet) Date: Tue, 24 Nov 2009 19:29:10 +0100 Subject: [Fedora-packaging] Fedora Packaging Committee Meeting - Dec 2, 2009 - 1600 UTC In-Reply-To: <4B0C1CA1.40602@redhat.com> References: <4B0AB286.1080805@redhat.com> <4B0AB36F.9090307@redhat.com> <4B0B7A7F.4020903@FamilleCollet.com> <4B0C0F70.2060205@redhat.com> <4B0C13A8.1050909@freenet.de> <4B0C15FB.3070004@redhat.com> <4B0C1B8A.8060008@FamilleCollet.com> <4B0C1CA1.40602@redhat.com> Message-ID: <4B0C25F6.1030406@FamilleCollet.com> Le 24/11/2009 18:49, Tom "spot" Callaway a ?crit : > On 11/24/2009 12:44 PM, Remi Collet wrote: >> So I think decision go to FPC and must be written in the PHP Guidelines >> >> Choice : >> 1- package must use only - >> 2- package must use - at the beginning (php-pear-) and _ at the end >> 3- package could use - or _ according to packager pref. > > Well, the way the guidelines are now is that _ can only be used as part > of the upstream name, and not as a separator. So, if the upstream name > is HTML_Javascript, then the package can be either: > > php-pear-HTML_Javascript > > or > > php-pear-HTML-Javascript > > depending on the packager's preference. Or reviewer choice ? > > However, > > php_pear_HTML_Javascript is not acceptable, because _ should never be > used as a separator. > > Unless you're proposing that PHP be excepted from these rules, I'm > inclined to simply leave the guidelines as is. Well, I remove the proposal from the draft. The 3 others minor change still need FPC approval. + > > ~spot > > -- > Fedora-packaging mailing list > Fedora-packaging at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-packaging > From tcallawa at redhat.com Tue Nov 24 18:30:13 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 24 Nov 2009 13:30:13 -0500 Subject: [Fedora-packaging] Fedora Packaging Committee Meeting - Dec 2, 2009 - 1600 UTC In-Reply-To: <4B0C25F6.1030406@FamilleCollet.com> References: <4B0AB286.1080805@redhat.com> <4B0AB36F.9090307@redhat.com> <4B0B7A7F.4020903@FamilleCollet.com> <4B0C0F70.2060205@redhat.com> <4B0C13A8.1050909@freenet.de> <4B0C15FB.3070004@redhat.com> <4B0C1B8A.8060008@FamilleCollet.com> <4B0C1CA1.40602@redhat.com> <4B0C25F6.1030406@FamilleCollet.com> Message-ID: <4B0C2635.9070609@redhat.com> On 11/24/2009 01:29 PM, Remi Collet wrote: >> depending on the packager's preference. > Or reviewer choice ? Technically, this is the packager's preference, either is acceptable. ~spot