From goyal.hemant at gmail.com Wed Feb 6 12:44:48 2008 From: goyal.hemant at gmail.com (Hemant Goyal) Date: Wed, 6 Feb 2008 18:14:48 +0530 Subject: [Fedora-packaging] speech-dispatcher packages Message-ID: <8c53493a0802060444h33c55787i6356d13cd0fa66a@mail.gmail.com> Hi, I am wondering whether anyone has taken a look at speech-dispatcher as a potential package to be included in Fedora. Is anyone interested in maintaining its packages? http://www.freebsoft.org/speechd -- Hemant -------------- next part -------------- An HTML attachment was scrubbed... URL: From goyal.hemant at gmail.com Wed Feb 6 12:52:03 2008 From: goyal.hemant at gmail.com (Hemant Goyal) Date: Wed, 6 Feb 2008 18:22:03 +0530 Subject: [Fedora-packaging] Re: speech-dispatcher packages In-Reply-To: <8c53493a0802060444h33c55787i6356d13cd0fa66a@mail.gmail.com> References: <8c53493a0802060444h33c55787i6356d13cd0fa66a@mail.gmail.com> Message-ID: <8c53493a0802060452m2759a41sa06f74f2ff2b2a9@mail.gmail.com> Hi again, We intend to use speech-dispatcher on the XO (OLPC) which uses a Fedora base. Hence it's rpm would be very useful. I do not have much experience wrt making packages, hence I thought if someone would be interested in helping out. If not, I'll get down to making one myself. Thanks Hemant On 2/6/08, Hemant Goyal wrote: > > Hi, > > I am wondering whether anyone has taken a look at speech-dispatcher as a > potential package to be included in Fedora. Is anyone interested in > maintaining its packages? > > http://www.freebsoft.org/speechd > > -- > Hemant -------------- next part -------------- An HTML attachment was scrubbed... URL: From timothy.selivanow at virtualxistenz.com Fri Feb 8 17:22:21 2008 From: timothy.selivanow at virtualxistenz.com (Timothy Selivanow) Date: Fri, 08 Feb 2008 09:22:21 -0800 Subject: [Fedora-packaging] python-svn build failed on koji Message-ID: <1202491341.17926.8.camel@denkiteki-penpen.easystreet.com> http://koji.fedoraproject.org/koji/taskinfo?taskID=403391 https://bugzilla.redhat.com/show_bug.cgi?id=428718 It looks like it is complaining about not being able to find the gssapi_krb5 library (libgssapi_krb5.so), which is part of krb5-devel. When I build it (manually) on my host after I remove krb5-devel (which also removes neon-devel and openssl-devel) it complains about needing neon-devel, which I then install neon-devel. neon-devel requires krb5-devel and openssl-devel (which *is* needed by python-svn to build), and it automatically installed when I `yum install neon-devel`. Does this not occur with koji? Do I need to specify *all* deps even though some of them are dep'd by other build deps? Also, I've been following , how exactly do I acquire a sponsor? Do I need to have this package build-able before I get a sponsor? Do I need a Fedora Account before/after a sponsor or the package is build-able? --Tim _______________________________________________________________________________ / Arithmetic is being able to count up to twenty without taking off your shoes. \ \ -- Mickey Mouse / ------------------------------------------------------------------------------- \ \ \ \ /\ ( ) .( o ). From ivazqueznet at gmail.com Fri Feb 8 17:48:16 2008 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Fri, 08 Feb 2008 12:48:16 -0500 Subject: [Fedora-packaging] python-svn build failed on koji In-Reply-To: <1202491341.17926.8.camel@denkiteki-penpen.easystreet.com> References: <1202491341.17926.8.camel@denkiteki-penpen.easystreet.com> Message-ID: <1202492896.26466.1.camel@ignacio.lan> On Fri, 2008-02-08 at 09:22 -0800, Timothy Selivanow wrote: > http://koji.fedoraproject.org/koji/taskinfo?taskID=403391 > https://bugzilla.redhat.com/show_bug.cgi?id=428718 > > It looks like it is complaining about not being able to find the > gssapi_krb5 library (libgssapi_krb5.so), which is part of krb5-devel. > When I build it (manually) on my host after I remove krb5-devel (which > also removes neon-devel and openssl-devel) it complains about needing > neon-devel, which I then install neon-devel. neon-devel requires > krb5-devel and openssl-devel (which *is* needed by python-svn to build), > and it automatically installed when I `yum install neon-devel`. Does > this not occur with koji? Do I need to specify *all* deps even though > some of them are dep'd by other build deps? From the neon-devel-0.27.2-4 changelog: * Tue Dec 04 2007 Joe Orton 0.27.2-3 - rebuild against GnuTLS - drop static library Looks to me like it no longer requires openssl-devel. -- Ignacio Vazquez-Abrams PLEASE don't CC me; I'm already subscribed -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From timothy.selivanow at virtualxistenz.com Fri Feb 8 18:12:51 2008 From: timothy.selivanow at virtualxistenz.com (Timothy Selivanow) Date: Fri, 08 Feb 2008 10:12:51 -0800 Subject: [Fedora-packaging] python-svn build failed on koji In-Reply-To: <1202492896.26466.1.camel@ignacio.lan> References: <1202491341.17926.8.camel@denkiteki-penpen.easystreet.com> <1202492896.26466.1.camel@ignacio.lan> Message-ID: <1202494371.17926.12.camel@denkiteki-penpen.easystreet.com> On Fri, 2008-02-08 at 12:48 -0500, Ignacio Vazquez-Abrams wrote: > On Fri, 2008-02-08 at 09:22 -0800, Timothy Selivanow wrote: > > http://koji.fedoraproject.org/koji/taskinfo?taskID=403391 > > https://bugzilla.redhat.com/show_bug.cgi?id=428718 > > > > It looks like it is complaining about not being able to find the > > gssapi_krb5 library (libgssapi_krb5.so), which is part of krb5-devel. > > When I build it (manually) on my host after I remove krb5-devel (which > > also removes neon-devel and openssl-devel) it complains about needing > > neon-devel, which I then install neon-devel. neon-devel requires > > krb5-devel and openssl-devel (which *is* needed by python-svn to build), > > and it automatically installed when I `yum install neon-devel`. Does > > this not occur with koji? Do I need to specify *all* deps even though > > some of them are dep'd by other build deps? > > From the neon-devel-0.27.2-4 changelog: > > * Tue Dec 04 2007 Joe Orton 0.27.2-3 > - rebuild against GnuTLS > - drop static library > > Looks to me like it no longer requires openssl-devel. > > -- > Fedora-packaging mailing list > Fedora-packaging at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-packaging Thanks! After seeing a comment by Mamoru Tasaka in BZ, I pretty much inferred that neon in rawhide must not dep openssl anymore, but I hadn't looked at the changelog. I'm updating the package now... --Tim ___________________________________________ / Even God lends a hand to honest boldness. \ \ -- Menander / ------------------------------------------- \ \ \ \ /\ ( ) .( o ). From timothy.selivanow at virtualxistenz.com Fri Feb 8 18:39:06 2008 From: timothy.selivanow at virtualxistenz.com (Timothy Selivanow) Date: Fri, 08 Feb 2008 10:39:06 -0800 Subject: [Fedora-packaging] python-svn build failed on koji In-Reply-To: <1202494371.17926.12.camel@denkiteki-penpen.easystreet.com> References: <1202491341.17926.8.camel@denkiteki-penpen.easystreet.com> <1202492896.26466.1.camel@ignacio.lan> <1202494371.17926.12.camel@denkiteki-penpen.easystreet.com> Message-ID: <1202495946.17926.17.camel@denkiteki-penpen.easystreet.com> On Fri, 2008-02-08 at 10:12 -0800, Timothy Selivanow wrote: > On Fri, 2008-02-08 at 12:48 -0500, Ignacio Vazquez-Abrams wrote: > > On Fri, 2008-02-08 at 09:22 -0800, Timothy Selivanow wrote: > > > http://koji.fedoraproject.org/koji/taskinfo?taskID=403391 > > > https://bugzilla.redhat.com/show_bug.cgi?id=428718 > > > > > > It looks like it is complaining about not being able to find the > > > gssapi_krb5 library (libgssapi_krb5.so), which is part of krb5-devel. > > > When I build it (manually) on my host after I remove krb5-devel (which > > > also removes neon-devel and openssl-devel) it complains about needing > > > neon-devel, which I then install neon-devel. neon-devel requires > > > krb5-devel and openssl-devel (which *is* needed by python-svn to build), > > > and it automatically installed when I `yum install neon-devel`. Does > > > this not occur with koji? Do I need to specify *all* deps even though > > > some of them are dep'd by other build deps? > > > > From the neon-devel-0.27.2-4 changelog: > > > > * Tue Dec 04 2007 Joe Orton 0.27.2-3 > > - rebuild against GnuTLS > > - drop static library > > > > Looks to me like it no longer requires openssl-devel. > > Thanks! After seeing a comment by Mamoru Tasaka in BZ, I pretty much > inferred that neon in rawhide must not dep openssl anymore, but I hadn't > looked at the changelog. I'm updating the package now... What is the policy for bumping release numbers when making pre-release (I'm assuming it could be different) spec changes? I'm defaulting to "yes, I need to bump the rel. ver. every time I make a spec change"; is that correct? I couldn't find the answer in (perhaps, I just missed it...): http://fedoraproject.org/wiki/Packaging/Guidelines http://fedoraproject.org/wiki/Packaging/NamingGuidelines --Tim ____________________________________ / But it does move! \ \ -- Galileo Galilei / ------------------------------------ \ \ \ \ /\ ( ) .( o ). From orion at cora.nwra.com Mon Feb 11 20:45:37 2008 From: orion at cora.nwra.com (Orion Poplawski) Date: Mon, 11 Feb 2008 13:45:37 -0700 Subject: [Fedora-packaging] Ada packages Message-ID: <47B0B3F1.5040901@cora.nwra.com> The latest release of plplot includes Ada bindings. The Ada development files are installed in: /usr/lib/ada/adalib/plplotadad/ (*.ali) and /usr/share/ada/adainclude/plplotadad/ (*.ads and *.adb) The PLplot project are following the recommendations made here: http://www.ada-france.org/debian/debian-ada-policy.html Now, there are currently no packages in Fedora that provide /usr/lib/ada/adalib and /usr/share/ada/adainclude. gcc-gnat does provide /usr/lib/gcc/i386-redhat-linux/4.1.2/adainclude, but this is clearly for internal use. So, what package should provide these two directories? filesystem? -- 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 tcallawa at redhat.com Tue Feb 12 14:49:05 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 12 Feb 2008 09:49:05 -0500 Subject: [Fedora-packaging] Ada packages In-Reply-To: <47B0B3F1.5040901@cora.nwra.com> References: <47B0B3F1.5040901@cora.nwra.com> Message-ID: <1202827745.3251.10.camel@dhcp83-61.boston.redhat.com> On Mon, 2008-02-11 at 13:45 -0700, Orion Poplawski wrote: > The latest release of plplot includes Ada bindings. The Ada development > files are installed in: > > /usr/lib/ada/adalib/plplotadad/ (*.ali) > > and > > /usr/share/ada/adainclude/plplotadad/ (*.ads and *.adb) > > The PLplot project are following the recommendations made here: > > http://www.ada-france.org/debian/debian-ada-policy.html Keep in mind that a lot of the debian packaging policies aren't terribly useful to us because Debian has no concept of multilib. So, where debian just dumps anything arch specific in /usr/lib, we want to use %{_libdir}. ~spot From orion at cora.nwra.com Tue Feb 12 16:46:07 2008 From: orion at cora.nwra.com (Orion Poplawski) Date: Tue, 12 Feb 2008 09:46:07 -0700 Subject: [Fedora-packaging] Ada packages In-Reply-To: <1202827745.3251.10.camel@dhcp83-61.boston.redhat.com> References: <47B0B3F1.5040901@cora.nwra.com> <1202827745.3251.10.camel@dhcp83-61.boston.redhat.com> Message-ID: <47B1CD4F.3070003@cora.nwra.com> Tom "spot" Callaway wrote: > On Mon, 2008-02-11 at 13:45 -0700, Orion Poplawski wrote: >> The latest release of plplot includes Ada bindings. The Ada development >> files are installed in: >> >> /usr/lib/ada/adalib/plplotadad/ (*.ali) >> >> and >> >> /usr/share/ada/adainclude/plplotadad/ (*.ads and *.adb) >> >> The PLplot project are following the recommendations made here: >> >> http://www.ada-france.org/debian/debian-ada-policy.html > > Keep in mind that a lot of the debian packaging policies aren't terribly > useful to us because Debian has no concept of multilib. So, where debian > just dumps anything arch specific in /usr/lib, we want to use > %{_libdir}. Sorry, that should have read %{_libdir}. The plplot package already does that. -- 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 rdieter at math.unl.edu Tue Feb 12 17:32:55 2008 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 12 Feb 2008 11:32:55 -0600 Subject: [Fedora-packaging] GGZ Draft guideline Message-ID: <47B1D847.5080906@math.unl.edu> Here's a quicky draft I threw together: http://fedoraproject.org/wiki/PackagingDrafts/GGZ Already got feedback from ggz upstream, and is in use in rawhide's gnome-games, kdegames, freeciv packaging. One small thing to consider maybe: Change Requires(post,preun): ggz-client-libs to Requires(post,preun): %_bindir/ggz-config ends up being the same thing, so may not make much/any difference. -- Rex From tcallawa at redhat.com Tue Feb 12 17:36:34 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 12 Feb 2008 12:36:34 -0500 Subject: [Fedora-packaging] Ada packages In-Reply-To: <47B0B3F1.5040901@cora.nwra.com> References: <47B0B3F1.5040901@cora.nwra.com> Message-ID: <1202837794.3251.41.camel@dhcp83-61.boston.redhat.com> On Mon, 2008-02-11 at 13:45 -0700, Orion Poplawski wrote: > So, what package should provide these two directories? filesystem? Is there anything that all ada packages will depend on for runtime functionality? If not, then filesystem seems like the only other way. ~spot From notting at redhat.com Tue Feb 12 17:39:43 2008 From: notting at redhat.com (Bill Nottingham) Date: Tue, 12 Feb 2008 12:39:43 -0500 Subject: [Fedora-packaging] Ada packages In-Reply-To: <1202837794.3251.41.camel@dhcp83-61.boston.redhat.com> References: <47B0B3F1.5040901@cora.nwra.com> <1202837794.3251.41.camel@dhcp83-61.boston.redhat.com> Message-ID: <20080212173943.GA15578@nostromo.devel.redhat.com> Tom spot Callaway (tcallawa at redhat.com) said: > > So, what package should provide these two directories? filesystem? > > Is there anything that all ada packages will depend on for runtime > functionality? libgnat, presumably. Bill From orion at cora.nwra.com Tue Feb 12 20:38:07 2008 From: orion at cora.nwra.com (Orion Poplawski) Date: Tue, 12 Feb 2008 13:38:07 -0700 Subject: [Fedora-packaging] Ada packages In-Reply-To: <20080212173943.GA15578@nostromo.devel.redhat.com> References: <47B0B3F1.5040901@cora.nwra.com> <1202837794.3251.41.camel@dhcp83-61.boston.redhat.com> <20080212173943.GA15578@nostromo.devel.redhat.com> Message-ID: <47B203AF.3030005@cora.nwra.com> Bill Nottingham wrote: > Tom spot Callaway (tcallawa at redhat.com) said: >>> So, what package should provide these two directories? filesystem? >> Is there anything that all ada packages will depend on for runtime >> functionality? > > libgnat, presumably. > Well, these directories are only required for Ada development, not runtime. For Ada development you're going to need gcc-gnat (and libgnat). -- 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 luitjens at cs.utah.edu Thu Feb 14 07:27:05 2008 From: luitjens at cs.utah.edu (Justin) Date: Thu, 14 Feb 2008 00:27:05 -0700 Subject: [Fedora-packaging] alsa-plugins-a52 in Fedora 8? Message-ID: <47B3ED49.7000205@cs.utah.edu> Hi, I'm sorry if this is not the right mailing list for this question. It seemed like the best fit for it. I have noticed the alsa package alsa-plugins-a52 seems to be missing in at least Fedora 8. Is this intentional? Is it possible to get this added? Thanks, Justin From rdieter at math.unl.edu Thu Feb 14 13:44:54 2008 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 14 Feb 2008 07:44:54 -0600 Subject: [Fedora-packaging] Re: alsa-plugins-a52 in Fedora 8? References: <47B3ED49.7000205@cs.utah.edu> Message-ID: Justin wrote: > I'm sorry if this is not the right mailing list for this question. It > seemed like the best fit for it. This list is for packaging guidelines and policy. > I have noticed the alsa package alsa-plugins-a52 seems to be missing in > at least Fedora 8. Is this intentional? Is it possible to get this > added? Good question, but asking on fedora-devel (or asking alsa-plugins maintainer directly) would likely get you better results. -- Rex From timothy.selivanow at virtualxistenz.com Thu Feb 14 18:55:05 2008 From: timothy.selivanow at virtualxistenz.com (Timothy Selivanow) Date: Thu, 14 Feb 2008 10:55:05 -0800 Subject: [Fedora-packaging] Package naming help, please Message-ID: <1203015305.19845.6.camel@denkiteki-penpen.easystreet.com> The way I interpreted the Package Naming Guidelines[1], the package I'm working on (pysvn) should be called python-svn. Is this not correct[2]? 1: http://fedoraproject.org/wiki/Packaging/NamingGuidelines 2: https://bugzilla.redhat.com/show_bug.cgi?id=428718#c11 --Tim ______________________________________________ < Beer -- it's not just for breakfast anymore. > ---------------------------------------------- \ \ \ \ /\ ( ) .( o ). From opensource at till.name Thu Feb 14 19:06:09 2008 From: opensource at till.name (Till Maas) Date: Thu, 14 Feb 2008 20:06:09 +0100 Subject: [Fedora-packaging] Package naming help, please In-Reply-To: <1203015305.19845.6.camel@denkiteki-penpen.easystreet.com> References: <1203015305.19845.6.camel@denkiteki-penpen.easystreet.com> Message-ID: <200802142006.18503.opensource@till.name> On Thu February 14 2008, Timothy Selivanow wrote: > The way I interpreted the Package Naming Guidelines[1], the package I'm > working on (pysvn) should be called python-svn. Is this not correct[2]? http://fedoraproject.org/wiki/Packaging/NamingGuidelines#head-8756a3bce652c376d7ba3908461b638784b6952d | There is an exception to this rule. If the upstream source has "py" | (or "Py") in its name, you can use that name for the package. So, for | example, pygtk is acceptable. pysvn is a valid name for your package. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From rdieter at math.unl.edu Thu Feb 14 19:09:43 2008 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 14 Feb 2008 13:09:43 -0600 Subject: [Fedora-packaging] Package naming help, please In-Reply-To: <1203015305.19845.6.camel@denkiteki-penpen.easystreet.com> References: <1203015305.19845.6.camel@denkiteki-penpen.easystreet.com> Message-ID: <47B491F7.9050000@math.unl.edu> Timothy Selivanow wrote: > The way I interpreted the Package Naming Guidelines[1], the package I'm > working on (pysvn) should be called python-svn. Is this not correct[2]? > > > 1: http://fedoraproject.org/wiki/Packaging/NamingGuidelines > 2: https://bugzilla.redhat.com/show_bug.cgi?id=428718#c11 http://fedoraproject.org/wiki/Packaging/NamingGuidelines#head-8756a3bce652c376d7ba3908461b638784b6952d "There is an exception to this rule. If the upstream source has "py" (or "Py") in its name, you can use that name for the package. So, for example, pygtk is acceptable." -- Rex From timothy.selivanow at virtualxistenz.com Thu Feb 14 19:27:38 2008 From: timothy.selivanow at virtualxistenz.com (Timothy Selivanow) Date: Thu, 14 Feb 2008 11:27:38 -0800 Subject: [Fedora-packaging] Package naming help, please In-Reply-To: <47B491F7.9050000@math.unl.edu> References: <1203015305.19845.6.camel@denkiteki-penpen.easystreet.com> <47B491F7.9050000@math.unl.edu> Message-ID: <1203017258.19845.11.camel@denkiteki-penpen.easystreet.com> On Thu, 2008-02-14 at 13:09 -0600, Rex Dieter wrote: > Timothy Selivanow wrote: > > The way I interpreted the Package Naming Guidelines[1], the package I'm > > working on (pysvn) should be called python-svn. Is this not correct[2]? > > > > > > 1: http://fedoraproject.org/wiki/Packaging/NamingGuidelines > > 2: https://bugzilla.redhat.com/show_bug.cgi?id=428718#c11 > > http://fedoraproject.org/wiki/Packaging/NamingGuidelines#head-8756a3bce652c376d7ba3908461b638784b6952d > > "There is an exception to this rule. If the upstream source has "py" (or > "Py") in its name, you can use that name for the package. So, for > example, pygtk is acceptable." > > -- Rex Thanks! Somehow I missed that little blurb under the examples. pysvn also falls under the "how it is called" rule, as it is used as "import pysvn". So many documents... --Tim ____________________________________________________________________ / It isn't necessary to have relatives in Kansas City in order to be \ | unhappy. | \ -- Groucho Marx / -------------------------------------------------------------------- \ \ \ \ /\ ( ) .( o ). From a.badger at gmail.com Thu Feb 14 19:50:59 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 14 Feb 2008 11:50:59 -0800 Subject: [Fedora-packaging] Package naming help, please In-Reply-To: <1203015305.19845.6.camel@denkiteki-penpen.easystreet.com> References: <1203015305.19845.6.camel@denkiteki-penpen.easystreet.com> Message-ID: <47B49BA3.2020005@gmail.com> Timothy Selivanow wrote: > The way I interpreted the Package Naming Guidelines[1], the package I'm > working on (pysvn) should be called python-svn. Is this not correct[2]? > > > 1: http://fedoraproject.org/wiki/Packaging/NamingGuidelines > 2: https://bugzilla.redhat.com/show_bug.cgi?id=428718#c11 For that package you could use either python-pysvn[1]_ or pysvn[2]_. .. _[1]: 'They should take into account the upstream name of the python module. This makes a package name format of python-$NAME. When in doubt, use the name of the module that you type to import it in a script.' You use "import pysvn" so $NAME = pysvn there. .. _[2]: 'There is an exception to this rule. If the upstream source has "py" (or "Py") in its name, you can use that name for the package. So, for example, pygtk is acceptable.' So a plain pysvn is fine. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From tibbs at math.uh.edu Fri Feb 15 06:07:48 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 15 Feb 2008 00:07:48 -0600 Subject: [Fedora-packaging] Duplication of documentation in subpackages Message-ID: I've seen a few packages which include things like a readme or license file in both the main package and one or more subpackages. The review guidelines are explicit that packages must not contain duplicate files in the %files listing, and generally these will abort a build, but in the case of %doc files this doesn't seem to be the case. I know spot has indicated in the past that there's no legal requirement to duplicate the license file between subpackages, even when they have names which don't relate them in any way to the main package. What I've never been sure of is whether it's something I need to block packages for. I guess if anyone is that concerned about saving space they can just do --nodocs installs. - J< From pertusus at free.fr Fri Feb 15 09:18:46 2008 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 15 Feb 2008 10:18:46 +0100 Subject: [Fedora-packaging] Duplication of documentation in subpackages In-Reply-To: References: Message-ID: <20080215091845.GB3386@free.fr> On Fri, Feb 15, 2008 at 12:07:48AM -0600, Jason L Tibbitts III wrote: > I've seen a few packages which include things like a readme or license > file in both the main package and one or more subpackages. > > The review guidelines are explicit that packages must not contain > duplicate files in the %files listing, and generally these will abort > a build, but in the case of %doc files this doesn't seem to be the > case. That's because they are not installed at the smae location since the package name is used when constructing the doc directory. > I know spot has indicated in the past that there's no legal > requirement to duplicate the license file between subpackages, even > when they have names which don't relate them in any way to the main > package. What I've never been sure of is whether it's something I > need to block packages for. I guess if anyone is that concerned about > saving space they can just do --nodocs installs. I personnally think that it can be left to the packager, but it also seems to me that we should discourage it in packages that depend on other packages that have the same doc files. But, in my opinion, in packages that don't depend on each other, duplicating at least the license makes sense (though should not be mandatory). -- Pat From rjones at redhat.com Fri Feb 15 14:55:36 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Fri, 15 Feb 2008 14:55:36 +0000 Subject: [Fedora-packaging] OCaml "LGPLv2 with exceptions" - what should be in the License field? Message-ID: <47B5A7E8.6060807@redhat.com> Jason Tibbitts who has been kindly reviewing many of my packages raises a question about the License field for a common license for OCaml. https://bugzilla.redhat.com/show_bug.cgi?id=432482 The license starts with this preamble, and then continues with the ordinary LGPLv2. Note that this license is more permissive than the standard LGPL, so this is not a question about whether this is free software or not. This Library is distributed under the terms of the GNU Library General Public License version 2 (included below). As a special exception to the GNU Library General Public License, you may link, statically or dynamically, a "work that uses the Library" with a publicly distributed version of the Library to produce an executable file containing portions of the Library, and distribute that executable file under terms of your choice, without any of the additional requirements listed in clause 6 of the GNU Library General Public License. By "a publicly distributed version of the Library", we mean either the unmodified Library as distributed by INRIA, or a modified version of the Library that is distributed under the conditions defined in clause 3 of the GNU Library General Public License. This exception does not however invalidate any other reasons why the executable file might be covered by the GNU Library General Public License. Many OCaml libraries use a license like this because the relinking requirements described in LGPL make no sense for OCaml libraries. Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3237 bytes Desc: S/MIME Cryptographic Signature URL: From rdieter at math.unl.edu Fri Feb 15 14:59:03 2008 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 15 Feb 2008 08:59:03 -0600 Subject: [Fedora-packaging] OCaml "LGPLv2 with exceptions" - what should be in the License field? In-Reply-To: <47B5A7E8.6060807@redhat.com> References: <47B5A7E8.6060807@redhat.com> Message-ID: <47B5A8B7.2000201@math.unl.edu> Richard W.M. Jones wrote: > Jason Tibbitts who has been kindly reviewing many of my packages raises > a question about the License field for a common license for OCaml. > > https://bugzilla.redhat.com/show_bug.cgi?id=432482 > > The license starts with this preamble, and then continues with the > ordinary LGPLv2. Note that this license is more permissive than the > standard LGPL, so this is not a question about whether this is free > software or not. Imo, License: LPGLv2 with exceptions is perfectly descriptive and valid. Folks will have to look at the license file for details anyway. For example, see also qt4 packaging that uses something similar. -- Rex From tcallawa at redhat.com Fri Feb 15 23:12:52 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Fri, 15 Feb 2008 18:12:52 -0500 Subject: [Fedora-packaging] OCaml "LGPLv2 with exceptions" - what should be in the License field? In-Reply-To: <47B5A8B7.2000201@math.unl.edu> References: <47B5A7E8.6060807@redhat.com> <47B5A8B7.2000201@math.unl.edu> Message-ID: <1203117172.10036.39.camel@localhost.localdomain> On Fri, 2008-02-15 at 08:59 -0600, Rex Dieter wrote: > Richard W.M. Jones wrote: > > Jason Tibbitts who has been kindly reviewing many of my packages raises > > a question about the License field for a common license for OCaml. > > > > https://bugzilla.redhat.com/show_bug.cgi?id=432482 > > > > The license starts with this preamble, and then continues with the > > ordinary LGPLv2. Note that this license is more permissive than the > > standard LGPL, so this is not a question about whether this is free > > software or not. > > Imo, > License: LPGLv2 with exceptions > is perfectly descriptive and valid. Folks will have to look at the > license file for details anyway. For example, see also qt4 packaging > that uses something similar. This specific exception is something which is OK for Fedora, please use "LGPLv2 with exceptions" as the license. ~spot From tcallawa at redhat.com Fri Feb 15 23:28:46 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Fri, 15 Feb 2008 18:28:46 -0500 Subject: [Fedora-packaging] Duplication of documentation in subpackages In-Reply-To: <20080215091845.GB3386@free.fr> References: <20080215091845.GB3386@free.fr> Message-ID: <1203118126.10036.42.camel@localhost.localdomain> On Fri, 2008-02-15 at 10:18 +0100, Patrice Dumas wrote: > But, in my opinion, in packages that don't depend on each other, > duplicating at least the license makes sense (though should not be > mandatory). I've got no problem with this approach, although, I don't necessarily want to encourage it, as it could get absurd in packages with a lot of subpackages. ~spot From pertusus at free.fr Fri Feb 15 23:34:25 2008 From: pertusus at free.fr (Patrice Dumas) Date: Sat, 16 Feb 2008 00:34:25 +0100 Subject: [Fedora-packaging] Duplication of documentation in subpackages In-Reply-To: <1203118126.10036.42.camel@localhost.localdomain> References: <20080215091845.GB3386@free.fr> <1203118126.10036.42.camel@localhost.localdomain> Message-ID: <20080215233425.GB2677@free.fr> On Fri, Feb 15, 2008 at 06:28:46PM -0500, Tom spot Callaway wrote: > > On Fri, 2008-02-15 at 10:18 +0100, Patrice Dumas wrote: > > But, in my opinion, in packages that don't depend on each other, > > duplicating at least the license makes sense (though should not be > > mandatory). > > I've got no problem with this approach, although, I don't necessarily > want to encourage it, as it could get absurd in packages with a lot of > subpackages. Indeed. I have no problem with it being discouraged, as long as it is not forbidden (by the guidelines). -- Pat From debarshi.ray at gmail.com Sat Feb 16 16:10:19 2008 From: debarshi.ray at gmail.com (Debarshi Ray) Date: Sat, 16 Feb 2008 21:40:19 +0530 Subject: [Fedora-packaging] Duplication of documentation in subpackages In-Reply-To: References: Message-ID: <3170f42f0802160810q79a0e746wdde7bde9474a6e35@mail.gmail.com> In packages with queer licensing (eg., multiple licensing scenarios) I duplicate the license(s) if they are relevant to the sub-packages as well. eg., in glade3, glade3-libgladeui and glade3-libgladeui-devel. Is this alright? Cheers, Debarshi -- "From what we get, we can make a living; what we give, however, makes a life." -- Arthur Ashe From tibbs at math.uh.edu Sat Feb 16 17:55:45 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 16 Feb 2008 11:55:45 -0600 Subject: [Fedora-packaging] Duplication of documentation in subpackages In-Reply-To: <3170f42f0802160810q79a0e746wdde7bde9474a6e35@mail.gmail.com> References: <3170f42f0802160810q79a0e746wdde7bde9474a6e35@mail.gmail.com> Message-ID: >>>>> "DR" == Debarshi Ray writes: DR> In packages with queer licensing (eg., multiple licensing DR> scenarios) I duplicate the license(s) if they are relevant to the DR> sub-packages as well. eg., in glade3, glade3-libgladeui and DR> glade3-libgladeui-devel. Is this alright? It's not necessary, but I don't see any problem with it. There was just some discussion about this on this list a couple of days ago. - J< From rdieter at math.unl.edu Mon Feb 18 14:04:42 2008 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 18 Feb 2008 08:04:42 -0600 Subject: [Fedora-packaging] java: building from source vs signed .jar's Message-ID: I've been approached by the dev's of a GPL'd java app (www.geogebra.org), wanting my assistance wrt rpm packaging (and eventual inclusion in fedora I hope), but there's a snag. They want (need) their java applet runable over the web (webstart'able), and that means signed jars. They proposed we simply package their prebuilt (and signed) .jars, but that is contrary to our usual "build from source" position. So, the dilemma is 1. come up with packaging policy and mechanism for fedora to produce signed jars. I raised this issue in the past, but we punted, since fedora, at the time, didn't include any java implementations that supported this. icedtea changes that. 2. allow an exception to the "build from source" guideline for pregenerated, signed .jar's. 3. just say no 4. insert suggestion here. ... 99. profit! -- Rex From tcallawa at redhat.com Mon Feb 18 17:13:00 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Mon, 18 Feb 2008 12:13:00 -0500 Subject: [Fedora-packaging] java: building from source vs signed .jar's In-Reply-To: References: Message-ID: <1203354780.5109.22.camel@localhost.localdomain> On Mon, 2008-02-18 at 08:04 -0600, Rex Dieter wrote: > I've been approached by the dev's of a GPL'd java app (www.geogebra.org), > wanting my assistance wrt rpm packaging (and eventual inclusion in fedora I > hope), but there's a snag. They want (need) their java applet runable over > the web (webstart'able), and that means signed jars. They proposed we > simply package their prebuilt (and signed) .jars, but that is contrary to > our usual "build from source" position. > > So, the dilemma is > 1. come up with packaging policy and mechanism for fedora to produce signed > jars. I raised this issue in the past, but we punted, since fedora, at the > time, didn't include any java implementations that supported this. icedtea > changes that. > 2. allow an exception to the "build from source" guideline for pregenerated, > signed .jar's. > 3. just say no > 4. insert suggestion here. > ... > 99. profit! OK, so this is my stance: * Unless Fedora can sign the jars that we build from source, this is a showstopper. We cannot permit pre-generated signed jars. I've seen too many horrifying java crapboxes stuffed full of proprietary components, ancient components, and illegal components to simply permit this under any conditions. If it doesn't build from source, we aren't shipping it. Now, I would be interested in hearing whether we can do this with IcedTea or not, and if so, how to accomplish it. This seems like it would be a very necessary component to the non-existent Java packaging guidelines. ~spot From rdieter at math.unl.edu Mon Feb 18 17:19:28 2008 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 18 Feb 2008 11:19:28 -0600 Subject: [Fedora-packaging] java: building from source vs signed .jar's In-Reply-To: <1203354780.5109.22.camel@localhost.localdomain> References: <1203354780.5109.22.camel@localhost.localdomain> Message-ID: <47B9BE20.5070308@math.unl.edu> Tom "spot" Callaway wrote: > OK, so this is my stance: > > * Unless Fedora can sign the jars that we build from source, this is a > showstopper. ... > Now, I would be interested in hearing whether we can do this with > IcedTea or not, and if so, how to accomplish it. This seems like it > would be a very necessary component to the non-existent Java packaging > guidelines. We're pretty much on that same page then, +1 to all that. This will definitely need some attention, input, and love from the fedora java folks alright. -- Rex From jkeating at redhat.com Mon Feb 18 17:28:47 2008 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 18 Feb 2008 12:28:47 -0500 Subject: [Fedora-packaging] java: building from source vs signed .jar's In-Reply-To: <47B9BE20.5070308@math.unl.edu> References: <1203354780.5109.22.camel@localhost.localdomain> <47B9BE20.5070308@math.unl.edu> Message-ID: <20080218122847.0e5f0bcb@redhat.com> On Mon, 18 Feb 2008 11:19:28 -0600 Rex Dieter wrote: > We're pretty much on that same page then, +1 to all that. This will > definitely need some attention, input, and love from the fedora java > folks alright. I don't recall if this was public or not, but I seem to recall having this conversation a while ago, and the conclusion was exactly as spot says it is. Also I think the problem here is that there is a cert system that is being held hostage by Sun, and nobody else gets to play. This is worse than the current web cert games we play with browsers. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From tibbs at math.uh.edu Mon Feb 18 17:45:57 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 18 Feb 2008 11:45:57 -0600 Subject: [Fedora-packaging] java: building from source vs signed .jar's In-Reply-To: <1203354780.5109.22.camel@localhost.localdomain> References: <1203354780.5109.22.camel@localhost.localdomain> Message-ID: >>>>> "TC" == Tom \"spot\" Callaway writes: TC> * Unless Fedora can sign the jars that we build from source, this TC> is a showstopper. I have to agree, although I thought we had already come to this conclusion in the past. - J< From Axel.Thimm at ATrpms.net Mon Feb 18 18:48:18 2008 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 18 Feb 2008 20:48:18 +0200 Subject: [Fedora-packaging] Re: java: building from source vs signed .jar's In-Reply-To: References: Message-ID: <20080218184818.GA24558@puariko.nirvana> Hi, On Mon, Feb 18, 2008 at 08:04:42AM -0600, Rex Dieter wrote: > I've been approached by the dev's of a GPL'd java app (www.geogebra.org), > wanting my assistance wrt rpm packaging (and eventual inclusion in fedora I > hope), but there's a snag. Not directly related to the signing issue, but I've had geogebra on my plate since some time, as I need it for a deployment. Do you want to join forces? -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Mon Feb 18 18:53:08 2008 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 18 Feb 2008 20:53:08 +0200 Subject: [Fedora-packaging] Re: java: building from source vs signed .jar's In-Reply-To: <20080218122847.0e5f0bcb@redhat.com> References: <1203354780.5109.22.camel@localhost.localdomain> <47B9BE20.5070308@math.unl.edu> <20080218122847.0e5f0bcb@redhat.com> Message-ID: <20080218185308.GB24558@puariko.nirvana> On Mon, Feb 18, 2008 at 12:28:47PM -0500, Jesse Keating wrote: > Also I think the problem here is that there is a cert system that is > being held hostage by Sun, and nobody else gets to play. This is worse > than the current web cert games we play with browsers. Can't we add a Fedora certificate to the distribution with a private key only the builders have access to? And maybe only for a whitelist of packages that the FPC would approve? As a short term solution for the geogebra case we could ship it unsigned until we have a procedure in place (of course all self-built from source). -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tcallawa at redhat.com Mon Feb 18 19:36:04 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Mon, 18 Feb 2008 14:36:04 -0500 Subject: [Fedora-packaging] Re: java: building from source vs signed .jar's In-Reply-To: <20080218185308.GB24558@puariko.nirvana> References: <1203354780.5109.22.camel@localhost.localdomain> <47B9BE20.5070308@math.unl.edu> <20080218122847.0e5f0bcb@redhat.com> <20080218185308.GB24558@puariko.nirvana> Message-ID: <1203363364.3736.5.camel@new-host-5> On Mon, 2008-02-18 at 20:53 +0200, Axel Thimm wrote: > On Mon, Feb 18, 2008 at 12:28:47PM -0500, Jesse Keating wrote: > > Also I think the problem here is that there is a cert system that is > > being held hostage by Sun, and nobody else gets to play. This is worse > > than the current web cert games we play with browsers. > > Can't we add a Fedora certificate to the distribution with a private > key only the builders have access to? And maybe only for a whitelist > of packages that the FPC would approve? > > As a short term solution for the geogebra case we could ship it > unsigned until we have a procedure in place (of course all self-built > from source). Not an expert here, but I think that many browsers will refuse to run unsigned java bits. ~spot From Axel.Thimm at ATrpms.net Mon Feb 18 19:55:27 2008 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 18 Feb 2008 21:55:27 +0200 Subject: [Fedora-packaging] Re: java: building from source vs signed .jar's In-Reply-To: <1203363364.3736.5.camel@new-host-5> References: <1203354780.5109.22.camel@localhost.localdomain> <47B9BE20.5070308@math.unl.edu> <20080218122847.0e5f0bcb@redhat.com> <20080218185308.GB24558@puariko.nirvana> <1203363364.3736.5.camel@new-host-5> Message-ID: <20080218195527.GF24558@puariko.nirvana> On Mon, Feb 18, 2008 at 02:36:04PM -0500, Tom spot Callaway wrote: > > On Mon, 2008-02-18 at 20:53 +0200, Axel Thimm wrote: > > On Mon, Feb 18, 2008 at 12:28:47PM -0500, Jesse Keating wrote: > > > Also I think the problem here is that there is a cert system that is > > > being held hostage by Sun, and nobody else gets to play. This is worse > > > than the current web cert games we play with browsers. > > > > Can't we add a Fedora certificate to the distribution with a private > > key only the builders have access to? And maybe only for a whitelist > > of packages that the FPC would approve? > > > > As a short term solution for the geogebra case we could ship it > > unsigned until we have a procedure in place (of course all self-built > > from source). > > Not an expert here, but I think that many browsers will refuse to run > unsigned java bits. They will issue a warning and let the user decide. There are quite a lot of appliances w/o a trusted key or not signed at all in routers, switches, kvm boxes etc. that fall into this category. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ville.skytta at iki.fi Mon Feb 18 20:11:07 2008 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Mon, 18 Feb 2008 22:11:07 +0200 Subject: [Fedora-packaging] Re: java: building from source vs signed .jar's In-Reply-To: <1203363364.3736.5.camel@new-host-5> References: <20080218185308.GB24558@puariko.nirvana> <1203363364.3736.5.camel@new-host-5> Message-ID: <200802182211.07932.ville.skytta@iki.fi> On Monday 18 February 2008, Tom "spot" Callaway wrote: > Not an expert here, but I think that many browsers will refuse to run > unsigned java bits. I don't remember seeing a browser that would flat out reject all unsigned applets. But some things are available for signed applets only. http://mindprod.com/jgloss/applet.html#RESTRICTIONS http://mindprod.com/jgloss/signedapplets.html http://java.sun.com/javase/6/docs/technotes/guides/plugin/developer_guide/contents.html From orion at cora.nwra.com Mon Feb 18 20:29:23 2008 From: orion at cora.nwra.com (Orion Poplawski) Date: Mon, 18 Feb 2008 13:29:23 -0700 Subject: [Fedora-packaging] Policy on packages whose source files require a login to download Message-ID: <47B9EAA3.4040206@cora.nwra.com> Is there an explicit policy one way or the other on allowing packages whose upstream requires a login to download? My current package ncarg and its replacement (ncl) have moved to this. It seems that this is also the case with ksh as well. Kevin might be able to tell us if there are others. -- 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 tcallawa at redhat.com Mon Feb 18 20:37:28 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Mon, 18 Feb 2008 15:37:28 -0500 Subject: [Fedora-packaging] Policy on packages whose source files require a login to download In-Reply-To: <47B9EAA3.4040206@cora.nwra.com> References: <47B9EAA3.4040206@cora.nwra.com> Message-ID: <1203367048.3736.29.camel@new-host-5> On Mon, 2008-02-18 at 13:29 -0700, Orion Poplawski wrote: > Is there an explicit policy one way or the other on allowing packages > whose upstream requires a login to download? > > My current package ncarg and its replacement (ncl) have moved to this. > > It seems that this is also the case with ksh as well. Kevin might be > able to tell us if there are others. There is no policy preventing this. ~spot From ville.skytta at iki.fi Mon Feb 18 19:55:05 2008 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Mon, 18 Feb 2008 21:55:05 +0200 Subject: [Fedora-packaging] java: building from source vs signed .jar's In-Reply-To: References: Message-ID: <200802182155.06227.ville.skytta@iki.fi> On Monday 18 February 2008, Rex Dieter wrote: > 1. come up with packaging policy and mechanism for fedora to produce signed > jars. I raised this issue in the past, but we punted, since fedora, at the > time, didn't include any java implementations that supported this. icedtea > changes that. Having Fedora's Java accept Fedora-signed jars would be of limited usefulness in the case of applets; you'd probably want to serve the applets to all kinds of non-Fedora clients too. From pertusus at free.fr Mon Feb 18 22:11:46 2008 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 18 Feb 2008 23:11:46 +0100 Subject: [Fedora-packaging] Policy on packages whose source files require a login to download In-Reply-To: <47B9EAA3.4040206@cora.nwra.com> References: <47B9EAA3.4040206@cora.nwra.com> Message-ID: <20080218221146.GA2761@free.fr> On Mon, Feb 18, 2008 at 01:29:23PM -0700, Orion Poplawski wrote: > Is there an explicit policy one way or the other on allowing packages whose > upstream requires a login to download? I guess that you are referring to https://bugzilla.redhat.com/show_bug.cgi?id=381241#c23 I said that I don't want personally to approve this package, but I think that it is not against the guidelines. It is just that I disapprove personnally this practice, so I won't approve it myself. -- Pat From ed at eh3.com Mon Feb 18 23:39:39 2008 From: ed at eh3.com (Ed Hill) Date: Mon, 18 Feb 2008 18:39:39 -0500 Subject: [Fedora-packaging] Policy on packages whose source files require a login to download In-Reply-To: <20080218221146.GA2761@free.fr> References: <47B9EAA3.4040206@cora.nwra.com> <20080218221146.GA2761@free.fr> Message-ID: <20080218183939.7161f3c2@localhost.localdomain> On Mon, 18 Feb 2008 23:11:46 +0100 Patrice Dumas wrote: > On Mon, Feb 18, 2008 at 01:29:23PM -0700, Orion Poplawski wrote: > > Is there an explicit policy one way or the other on allowing > > packages whose upstream requires a login to download? > > I guess that you are referring to > https://bugzilla.redhat.com/show_bug.cgi?id=381241#c23 Hi Patrice and Orion, I've registered for access at the ESL web site and (in "...in one or two business days...") might be able to confirm that the source matches upstream. I say "might" because I refused to give them any of my phone numbers and instead supplied them with a 555-... number. Assuming they accept the application, I'll be happy to give the package a cursory review. Would that help? Ed -- Edward H. Hill III, PhD | ed at eh3.com | http://eh3.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From orion at cora.nwra.com Tue Feb 19 00:08:16 2008 From: orion at cora.nwra.com (Orion Poplawski) Date: Mon, 18 Feb 2008 17:08:16 -0700 Subject: [Fedora-packaging] Policy on packages whose source files require a login to download In-Reply-To: <20080218183939.7161f3c2@localhost.localdomain> References: <47B9EAA3.4040206@cora.nwra.com> <20080218221146.GA2761@free.fr> <20080218183939.7161f3c2@localhost.localdomain> Message-ID: <47BA1DF0.3080207@cora.nwra.com> Ed Hill wrote: > On Mon, 18 Feb 2008 23:11:46 +0100 Patrice Dumas wrote: > >> On Mon, Feb 18, 2008 at 01:29:23PM -0700, Orion Poplawski wrote: >>> Is there an explicit policy one way or the other on allowing >>> packages whose upstream requires a login to download? >> I guess that you are referring to >> https://bugzilla.redhat.com/show_bug.cgi?id=381241#c23 > > > Hi Patrice and Orion, > > I've registered for access at the ESL web site and (in "...in one or > two business days...") might be able to confirm that the source matches > upstream. I say "might" because I refused to give them any of my phone > numbers and instead supplied them with a 555-... number. > > Assuming they accept the application, I'll be happy to give the package > a cursory review. > > Would that help? > > Ed Package is pretty much fully reviewed - Patrice did a great job. I just need someone willing to approve it. -- 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 ivazqueznet at gmail.com Tue Feb 19 02:43:38 2008 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Mon, 18 Feb 2008 21:43:38 -0500 Subject: [Fedora-packaging] compat package policy Message-ID: <1203389018.29154.10.camel@ignacio.lan> I would like for the Packaging group to discuss the following policy: """ compat-* packages ----------------- compat-* packages are for the sole purpose of providing obsolescent/obsolete libraries required by non-Fedora applications. No Fedora packages may be built against them, and no application packages may use the compat- namespace. Any -devel subpackage must be omitted via the removal or exclusion of development-related files. """ This policy would not be enforced retroactively (although maintainer compliance should be welcomed). -- Ignacio Vazquez-Abrams PLEASE don't CC me; I'm already subscribed -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From rc040203 at freenet.de Tue Feb 19 05:58:20 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 19 Feb 2008 06:58:20 +0100 Subject: [Fedora-packaging] compat package policy In-Reply-To: <1203389018.29154.10.camel@ignacio.lan> References: <1203389018.29154.10.camel@ignacio.lan> Message-ID: <1203400700.3380.199.camel@beck.corsepiu.local> On Mon, 2008-02-18 at 21:43 -0500, Ignacio Vazquez-Abrams wrote: > I would like for the Packaging group to discuss the following policy: > > """ > compat-* packages > ----------------- > > compat-* packages are for the sole purpose of providing > obsolescent/obsolete libraries required by non-Fedora applications. No > Fedora packages may be built against them, and no application packages > may use the compat- namespace. Any -devel subpackage must be omitted via > the removal or exclusion of development-related files. > """ -1 Closing out devel-packages closes out packages which require older APIs/ABIs from rebuilding. Ralf From a.badger at gmail.com Tue Feb 19 06:59:43 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 18 Feb 2008 22:59:43 -0800 Subject: [Fedora-packaging] compat package policy In-Reply-To: <1203400700.3380.199.camel@beck.corsepiu.local> References: <1203389018.29154.10.camel@ignacio.lan> <1203400700.3380.199.camel@beck.corsepiu.local> Message-ID: <47BA7E5F.3020301@gmail.com> Ralf Corsepius wrote: > On Mon, 2008-02-18 at 21:43 -0500, Ignacio Vazquez-Abrams wrote: >> I would like for the Packaging group to discuss the following policy: >> >> """ >> compat-* packages >> ----------------- >> >> compat-* packages are for the sole purpose of providing >> obsolescent/obsolete libraries required by non-Fedora applications. No >> Fedora packages may be built against them, and no application packages >> may use the compat- namespace. Any -devel subpackage must be omitted via >> the removal or exclusion of development-related files. >> """ > > -1 > > Closing out devel-packages closes out packages which require older > APIs/ABIs from rebuilding. > If I'm reading the proposal correctly, this is more of a naming convention than a limitation on whether packages of libraries with older APIs can be created. On that basis, I'm +1. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From rc040203 at freenet.de Tue Feb 19 07:11:10 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 19 Feb 2008 08:11:10 +0100 Subject: [Fedora-packaging] compat package policy In-Reply-To: <47BA7E5F.3020301@gmail.com> References: <1203389018.29154.10.camel@ignacio.lan> <1203400700.3380.199.camel@beck.corsepiu.local> <47BA7E5F.3020301@gmail.com> Message-ID: <1203405070.3380.208.camel@beck.corsepiu.local> On Mon, 2008-02-18 at 22:59 -0800, Toshio Kuratomi wrote: > Ralf Corsepius wrote: > > On Mon, 2008-02-18 at 21:43 -0500, Ignacio Vazquez-Abrams wrote: > >> I would like for the Packaging group to discuss the following policy: > >> > >> """ > >> compat-* packages > >> ----------------- > >> > >> compat-* packages are for the sole purpose of providing > >> obsolescent/obsolete libraries required by non-Fedora applications. No > >> Fedora packages may be built against them, and no application packages > >> may use the compat- namespace. Any -devel subpackage must be omitted via > >> the removal or exclusion of development-related files. > >> """ > > > > -1 > > > > Closing out devel-packages closes out packages which require older > > APIs/ABIs from rebuilding. > > > If I'm reading the proposal correctly, this is more of a naming > convention than a limitation on whether packages of libraries with older > APIs can be created. Hmm, I feel like reading a completely different text: I read: "No Fedora packages may be built against them (compat-*)" == Close out packages from Fedora which can't be built against upstream packages. I read: "Any -devel subpackage must be omitted via the removal or exclusion of development-related files." == NO devel files (comprising compat-*-devel packages) are allowed. Ralf From Axel.Thimm at ATrpms.net Tue Feb 19 21:35:02 2008 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 19 Feb 2008 23:35:02 +0200 Subject: [Fedora-packaging] Re: compat package policy In-Reply-To: <1203389018.29154.10.camel@ignacio.lan> References: <1203389018.29154.10.camel@ignacio.lan> Message-ID: <20080219213502.GA24504@puariko.nirvana> On Mon, Feb 18, 2008 at 09:43:38PM -0500, Ignacio Vazquez-Abrams wrote: > I would like for the Packaging group to discuss the following policy: > > """ > compat-* packages > ----------------- > > compat-* packages are for the sole purpose of providing > obsolescent/obsolete libraries required by non-Fedora applications. No > Fedora packages may be built against them, and no application packages > may use the compat- namespace. Any -devel subpackage must be omitted via > the removal or exclusion of development-related files. > """ > > This policy would not be enforced retroactively (although maintainer > compliance should be welcomed). Usually the kind of packages you describe simply vanish from rawhide - e.g. if there is no use for a non-leaf package it is very soon removed. Most current compat-* packages are used for some other Fedora package, or at least that was the case some time ago - maybe that changed. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Tue Feb 19 22:58:12 2008 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 20 Feb 2008 00:58:12 +0200 Subject: [Fedora-packaging] Re: compat package policy In-Reply-To: <20080219213502.GA24504@puariko.nirvana> References: <1203389018.29154.10.camel@ignacio.lan> <20080219213502.GA24504@puariko.nirvana> Message-ID: <20080219225812.GC24504@puariko.nirvana> On Tue, Feb 19, 2008 at 11:35:02PM +0200, Axel Thimm wrote: > On Mon, Feb 18, 2008 at 09:43:38PM -0500, Ignacio Vazquez-Abrams wrote: > > I would like for the Packaging group to discuss the following policy: > > > > """ > > compat-* packages > > ----------------- > > > > compat-* packages are for the sole purpose of providing > > obsolescent/obsolete libraries required by non-Fedora applications. No > > Fedora packages may be built against them, and no application packages > > may use the compat- namespace. Any -devel subpackage must be omitted via > > the removal or exclusion of development-related files. > > """ > > > > This policy would not be enforced retroactively (although maintainer > > compliance should be welcomed). > > Usually the kind of packages you describe simply vanish from rawhide - > e.g. if there is no use for a non-leaf package it is very soon > removed. > > Most current compat-* packages are used for some other Fedora package, > or at least that was the case some time ago - maybe that changed. BTW I was just trying to describe current usage of compat-*, I'm not against supplying Fedora users some libs that perhaps Fedora itself doesn't need anymore, but maybe a (significant?) amount of users still do. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From nicolas.mailhot at laposte.net Wed Feb 20 09:18:17 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 20 Feb 2008 10:18:17 +0100 Subject: [Fedora-packaging] Re: compat package policy In-Reply-To: <20080219213502.GA24504@puariko.nirvana> References: <1203389018.29154.10.camel@ignacio.lan> <20080219213502.GA24504@puariko.nirvana> Message-ID: <1203499097.7677.30.camel@rousalka.dyndns.org> Le mardi 19 f?vrier 2008 ? 23:35 +0200, Axel Thimm a ?crit : > Usually the kind of packages you describe simply vanish from rawhide - > e.g. if there is no use for a non-leaf package it is very soon > removed. +1 IMHO the most important property of compat packages is not that they have a devel conterpart or not, but that we clearly tell packagers "this bit is not to be used and will be removed mid-term". Restricting the compat naming to link-only packages will only make this removal process harder, as a lot of stuff will move to packages with no clear EOL target. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From rc040203 at freenet.de Wed Feb 20 09:41:04 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 20 Feb 2008 10:41:04 +0100 Subject: [Fedora-packaging] Re: compat package policy In-Reply-To: <1203499097.7677.30.camel@rousalka.dyndns.org> References: <1203389018.29154.10.camel@ignacio.lan> <20080219213502.GA24504@puariko.nirvana> <1203499097.7677.30.camel@rousalka.dyndns.org> Message-ID: <1203500464.3380.285.camel@beck.corsepiu.local> On Wed, 2008-02-20 at 10:18 +0100, Nicolas Mailhot wrote: > Le mardi 19 f?vrier 2008 ? 23:35 +0200, Axel Thimm a ?crit : > > > Usually the kind of packages you describe simply vanish from rawhide - > > e.g. if there is no use for a non-leaf package it is very soon > > removed. > > +1 > > IMHO the most important property of compat packages is not that they > have a devel conterpart or not, but that we clearly tell packagers "this > bit is not to be used and will be removed mid-term". Restricting the > compat naming to link-only packages will only make this removal process > harder, as a lot of stuff will move to packages with no clear EOL > target. Don't you realize the silliness of such a recommendation? 1. It's easy to circumvent (Simply don't use it) 2. It's technically counterproductive. compat packages are band aids to help out in cases where "upgrading" isn't easily applicable. Banning compat-*-devel packages voids this aspect. Ralf From nicolas.mailhot at laposte.net Wed Feb 20 09:56:21 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 20 Feb 2008 10:56:21 +0100 Subject: [Fedora-packaging] Re: compat package policy In-Reply-To: <1203500464.3380.285.camel@beck.corsepiu.local> References: <1203389018.29154.10.camel@ignacio.lan> <20080219213502.GA24504@puariko.nirvana> <1203499097.7677.30.camel@rousalka.dyndns.org> <1203500464.3380.285.camel@beck.corsepiu.local> Message-ID: <1203501381.7677.35.camel@rousalka.dyndns.org> Le mercredi 20 f?vrier 2008 ? 10:41 +0100, Ralf Corsepius a ?crit : > 2. It's technically counterproductive. > compat packages are band aids to help out in cases where "upgrading" > isn't easily applicable. Banning compat-*-devel packages voids this > aspect. I've seem people proposing the creation of foo123 packages just to get around the "no devel for compat packages" rule proposed there. Don't tell me this is progress ? those foo123 packages are going to stick a lot longer that compat packages would ever had. So the "no devel" rule is nothing but hiding problems under the carpet. It does not make people less inclined to build against old versions, you just have bandaids that do not look like bandaids anymore. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From rc040203 at freenet.de Wed Feb 20 10:37:41 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 20 Feb 2008 11:37:41 +0100 Subject: [Fedora-packaging] Re: compat package policy In-Reply-To: <1203501381.7677.35.camel@rousalka.dyndns.org> References: <1203389018.29154.10.camel@ignacio.lan> <20080219213502.GA24504@puariko.nirvana> <1203499097.7677.30.camel@rousalka.dyndns.org> <1203500464.3380.285.camel@beck.corsepiu.local> <1203501381.7677.35.camel@rousalka.dyndns.org> Message-ID: <1203503861.3380.316.camel@beck.corsepiu.local> On Wed, 2008-02-20 at 10:56 +0100, Nicolas Mailhot wrote: > Le mercredi 20 f?vrier 2008 ? 10:41 +0100, Ralf Corsepius a ?crit : > > > 2. It's technically counterproductive. > > compat packages are band aids to help out in cases where "upgrading" > > isn't easily applicable. Banning compat-*-devel packages voids this > > aspect. > > I've seem people proposing the creation of foo123 packages just to get > around the "no devel for compat packages" rule proposed there. Right, it's the escape to get around a silly proposal. > Don't > tell me this is progress ? those foo123 packages are going to stick a > lot longer that compat packages would ever had. They tend to stick longer, because they tend to be designed for parallel installation, often because of technical needs. compat- (without devel) tend to be introduced as temporary, legacy band-aid run-time packages. > So the "no devel" rule is nothing but hiding problems under the carpet. No. It's closing the eyes in front of actual problems. > It does not make people less inclined to build against old versions, you > just have bandaids that do not look like bandaids anymore. You seem to be missing that it's almost always not a matter of will, but a matter of technical requirement to ship compat*/foo123 packages, to keep things going at all. Or more abstract: Development is not a linear process, it has branches, curves and edges. Banning *devel packages from "compat" packages is trying to linearize development with a sledgehammer. Ralf From wolters.liste at gmx.net Wed Feb 20 10:51:25 2008 From: wolters.liste at gmx.net (Roland Wolters) Date: Wed, 20 Feb 2008 11:51:25 +0100 Subject: [Fedora-packaging] libcap and dbus? Message-ID: <200802201151.33061.wolters.liste@gmx.net> Hi list, The mass rebuild uncovered that there is something wrong with dbus: https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01685.html Since my few packages depend on dbus they of course fail: DEBUG util.py:261: Error: Missing Dependency: libcap.so.1()(64bit) is needed by package dbus DEBUG util.py:261: Error: Missing Dependency: libcap.so.1()(64bit) is needed by package avahi DEBUG util.py:261: Error: Missing Dependency: libcap.so.1()(64bit) is needed by package sudo DEBUG util.py:261: Error: Missing Dependency: libcap.so.1()(64bit) is needed by package dbus-libs So what should I do? Rebuild them when a new dbus is out there? Or just sit and wait until someone else sorts it out? Roland -- What kind of man would put a known criminal in charge of a major branch of goverment? Apart from, say, the average voter? -- Terry Pratchett -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: From jnovy at redhat.com Thu Feb 21 17:59:54 2008 From: jnovy at redhat.com (Jindrich Novy) Date: Thu, 21 Feb 2008 18:59:54 +0100 Subject: [Fedora-packaging] recent TeX Live packaging changes Message-ID: <20080221175954.GA7655@dhcp-lab-186.brq.redhat.com> Hi all, I made several modifications to TeXLive packaging recently so I want to make you aware of that, because some of your packages may need modifications to (Build)Requires, if you use documentation generation during build/your app uses TeXLive. The current list of subpackages that originates from TeXLive are: binaries: -------- dvipdfm dvipdfmx dvipng kpathsea kpathsea-devel mendexk texlive texlive-afm texlive-context texlive-doc texlive-dvips texlive-dviutils texlive-japanese texlive-latex texlive-utils texlive-xetex architecture independent bits: ----------------------------- texlive-texmf texlive-texmf-afm texlive-texmf-context texlive-texmf-doc texlive-texmf-dvips texlive-texmf-fonts texlive-texmf-japanese texlive-texmf-latex Major changes are that some stuff is moved out from main "texlive" package, mainly XeTeX and ConTeXt. Both now have their own packages. Note that also Metapost is moved to texlive-context. Motivation for packaging them separately is dependency of XeTeX on TECkit and dependency of ConTeXt to ruby, so that main texlive package no more depends on these. Packaging these bits separately is also natural as we should keep the baseline texlive package minimal. Support for Japanese and East Asian languages is now moved to texlive-japanese, including bg5conv, sjisconv, etc. utilities which were formerly in texlive-latex. Note that texlive-xdvi no more exists and it's now packaged separately in standalone xdvik package. Utilities that use Ghostscript are moved to texlive-utils to reduce dependency bloat, namely these: a2ping e2pall epstopdf gsftopk mf pdfcrop ps4pdf thumbpdf So please update your (Build)Requires in your packages if needed. TeXLive still contains virtual provides for teTeX, such as tetex-dvips, but better is to (Build)Require texlive-dvips. TeXLive packages now virtually provide: tex(tex) tex(latex) tex(dvips) tex(japanese) tex(context) So you can use these virual provides directly in order to not to be directly dependent on a particular TeX distribution in the future. Jindrich -- Jindrich Novy http://people.redhat.com/jnovy/ From jonathan.underwood at gmail.com Thu Feb 21 18:03:59 2008 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Thu, 21 Feb 2008 18:03:59 +0000 Subject: [Fedora-packaging] recent TeX Live packaging changes In-Reply-To: <20080221175954.GA7655@dhcp-lab-186.brq.redhat.com> References: <20080221175954.GA7655@dhcp-lab-186.brq.redhat.com> Message-ID: <645d17210802211003j69af04a8q80b6ad3039d986b5@mail.gmail.com> On 21/02/2008, Jindrich Novy wrote: > The current list of subpackages that originates from TeXLive are: > > binaries: > -------- > dvipdfm > dvipdfmx These two I am working on packaging separately from upstream (see Patrice's recent message on this) > dvipng This is now packaged separately and so we should remove this from the texlive build. J. From jnovy at redhat.com Thu Feb 21 18:19:51 2008 From: jnovy at redhat.com (Jindrich Novy) Date: Thu, 21 Feb 2008 19:19:51 +0100 Subject: [Fedora-packaging] recent TeX Live packaging changes In-Reply-To: <645d17210802211003j69af04a8q80b6ad3039d986b5@mail.gmail.com> References: <20080221175954.GA7655@dhcp-lab-186.brq.redhat.com> <645d17210802211003j69af04a8q80b6ad3039d986b5@mail.gmail.com> Message-ID: <20080221181951.GB7655@dhcp-lab-186.brq.redhat.com> On Thu, Feb 21, 2008 at 06:03:59PM +0000, Jonathan Underwood wrote: > On 21/02/2008, Jindrich Novy wrote: > > The current list of subpackages that originates from TeXLive are: > > > > binaries: > > -------- > > dvipdfm > > dvipdfmx > > These two I am working on packaging separately from upstream (see > Patrice's recent message on this) > > > dvipng > > This is now packaged separately and so we should remove this from the > texlive build. > Nice. I'll remove dvipng from TeXLive then. Thanks for the effort! Jindrich -- Jindrich Novy http://people.redhat.com/jnovy/ From jnovy at redhat.com Thu Feb 21 19:25:54 2008 From: jnovy at redhat.com (Jindrich Novy) Date: Thu, 21 Feb 2008 20:25:54 +0100 Subject: [Fedora-packaging] Re: recent TeX Live packaging changes In-Reply-To: <200802211818.m1LIIeV5010772@laptop13.inf.utfsm.cl> References: <20080221175954.GA7655@dhcp-lab-186.brq.redhat.com> <200802211818.m1LIIeV5010772@laptop13.inf.utfsm.cl> Message-ID: <20080221192554.GA29050@dhcp-lab-186.brq.redhat.com> On Thu, Feb 21, 2008 at 03:18:40PM -0300, Horst H. von Brand wrote: > Jindrich Novy wrote: > > Support for Japanese and East Asian languages is now moved to > > texlive-japanese, including bg5conv, sjisconv, etc. utilities which > > were formerly in texlive-latex. > > Shouldn't this be better called texlive-east-asian or some such? Makes sense. It is named texlive-japanese mostly for historical reasons, because only developers from Japan were actually interested in support for Japanese in Fedora TeXLive, particularly Matsuura Takanori who is behind the Fedora Japanese support. I haven't heard about anyone else using east Asian support unfortunatelly. Jindrich -- Jindrich Novy http://people.redhat.com/jnovy/ From jnovy at redhat.com Thu Feb 21 19:32:30 2008 From: jnovy at redhat.com (Jindrich Novy) Date: Thu, 21 Feb 2008 20:32:30 +0100 Subject: [Fedora-packaging] Re: recent TeX Live packaging changes In-Reply-To: <1203621427.20659.14.camel@valkyrie.localdomain> References: <20080221175954.GA7655@dhcp-lab-186.brq.redhat.com> <1203621427.20659.14.camel@valkyrie.localdomain> Message-ID: <20080221193230.GA8380@dhcp-lab-186.brq.redhat.com> On Thu, Feb 21, 2008 at 02:17:07PM -0500, Matthew Saltzman wrote: > On Thu, 2008-02-21 at 18:59 +0100, Jindrich Novy wrote: > > > > > Note that texlive-xdvi no more exists and it's now packaged separately > > in standalone xdvik package. > > Would it be possible to get a spin of xdvik that obsoletes the > tetex-xdvi package in Fedora 8 updates? yum keeps trying to replace my > xdvik with that tetex-xdvi package. Sure, the update is in pending state with a request to push directly into stable updates: https://admin.fedoraproject.org/updates/F8/pending/tetex-3.0-44.8.fc8 It also contains fix for the unversioned obsoletes that causes obsoletion of newer xdvik. Jindrich -- Jindrich Novy http://people.redhat.com/jnovy/ From pertusus at free.fr Fri Feb 22 11:38:01 2008 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 22 Feb 2008 12:38:01 +0100 Subject: [Fedora-packaging] Re: recent TeX Live packaging changes In-Reply-To: <1203621427.20659.14.camel@valkyrie.localdomain> References: <20080221175954.GA7655@dhcp-lab-186.brq.redhat.com> <1203621427.20659.14.camel@valkyrie.localdomain> Message-ID: <20080222113445.GA3399@free.fr> On Thu, Feb 21, 2008 at 02:17:07PM -0500, Matthew Saltzman wrote: > > On Thu, 2008-02-21 at 18:59 +0100, Jindrich Novy wrote: > > > > > Note that texlive-xdvi no more exists and it's now packaged separately > > in standalone xdvik package. > > Would it be possible to get a spin of xdvik that obsoletes the > tetex-xdvi package in Fedora 8 updates? yum keeps trying to replace my > xdvik with that tetex-xdvi package. Unless I am wrong, the problem is in the tetex-xdvi package that doesn't use versionned obsoletes. -- Pat From a.badger at gmail.com Tue Feb 26 18:25:45 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 26 Feb 2008 10:25:45 -0800 Subject: [Fedora-packaging] UTF-8 package names Message-ID: <47C459A9.7020609@gmail.com> Today the Packaging Committee began a discussion of whether package names should be allowed to contain the full range of Unicode characters (encoded as UTF-8) or be restricted to the ASCii subset. This is a bit of a contentious issue with the Packaging Committee members split but not yet set in stone about how to proceed. The main arguments seem to be: Pro Unicode: * Upstream knows best what name is most appropriate for their users. For us to change it locally in Fedora doesn't make much sense. * We allow Unicode in every other piece of the spec so why not in the package name? * We should be shaking out bugs in the handling of Unicode in our software rather than hiding issues with it. Pro ASCII: * Hard to type unicode package names, therefore it is a usability problem. * Is there a limit? Even if European letters are fine what about Kanji or Sanskrit? * Some pieces of software won't handle unicode package names and will need to be fixed. One package has been submitted for review with a unicode using package name and has some applicable comments: https://bugzilla.redhat.com/show_bug.cgi?id=261881 = Section of Packaging Committee Logs about Unicode Package Names = (09:32:18 AM) racor: banning non-ascii chars from package names (09:32:29 AM) spot: racor: eww. is someone actually doing that? (09:32:39 AM) f13: somebody did a + in a version I thought (09:32:40 AM) abadger1999: ivazquez sent something to the list. No actual draft but it was very simple. (09:32:47 AM) tibbs|h: spot: There's a review submitted. (09:32:49 AM) svahl left the room (quit: ). (09:32:51 AM) f13: but that doesn't count. (09:32:51 AM) rdieter: f13: inkscape, yeah, but fixed now. (09:32:59 AM) abadger1999: racor: What is the ratioinale? (09:33:01 AM) f13: tibbs|h: I bet its from nim-nim isn't it? (09:33:06 AM) racor: yes, there is a packaging under review ... (09:33:07 AM) tibbs|h: Yes, some fonts thing. (09:33:13 AM) spot: that seems like a no-brainer to me. (09:33:19 AM) abadger1999: spot: Why? (09:33:22 AM) tibbs|h: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=261881 (09:33:24 AM) buggbot: Bug 261881: medium, medium, ---, Nobody's working on this, feel free to take it, NEW , Review Request: ??colier-court-fonts - ??colier court fonts (09:33:37 AM) spot: because xchat rendered that two different ways for me? (09:33:45 AM) spot: i don't even want to think about yum. (09:34:02 AM) abadger1999: spot: yum does need a fix. There's an open bug. (09:34:05 AM) f13: well, it would be good to test our infrastructure. (09:34:08 AM) tibbs|h: I don't really have an issue with non-ascii package names; we can't keep falling back on "our infrastructure sucks" forever. (09:34:11 AM) abadger1999: But I'm wondering why it's a bad thing. (09:34:21 AM) abadger1999: Shouldn't we consider places where utf-8 fails to be bugs? (09:34:44 AM) f13: non-ascii packages may have to be renamed if they ever show up in RHEL (09:34:53 AM) f13: I'm not sure how the RHN beast will handle it. (09:35:07 AM) spot: well, that is RHEL's problem. (09:35:10 AM) f13: yep (09:35:17 AM) f13: I'm not saying it should have much bearing on our decision (09:35:27 AM) spot: racor: are you against it for aesthetic reasons or technical ones? (09:35:31 AM) racor: IMO, the technical issues are minor, the real issue is usabilitsy (09:35:44 AM) racor: spot: neither usability (09:35:51 AM) tibbs|h: I always said that I won't review what I can't type. (09:36:05 AM) tibbs|h: But my inability to type that is my dysfunction. (09:36:11 AM) spot: well, i suppose that it would make it more difficult for english typists to install/use a package (09:36:23 AM) spot: but not impossible (09:36:25 AM) racor: consider: 90% of US users are not even able to type accented chars (09:36:27 AM) tibbs|h: But is that a reason to ban something? (09:36:47 AM) tibbs|h: I can't read German either, so let's kick out German translations. (09:36:53 AM) racor: 99.89% of Western folks are not able to type east asian chars (09:37:07 AM) f13: and 40% of all statistics are made up on the spot (09:37:20 AM) spot: my concern is when people start naming packages in kanji. (09:37:40 AM) racor: tibbs: right type the char ? (this is not a beta it's a sharp ss) (09:37:46 AM) spot: we already mandate that the spec file must be written in american english (09:38:11 AM) tibbs|h: racor: I already said I can't type those characters; I don't see what point your question serves. (09:38:28 AM) rdieter: spot: +1, I think that covers the case here then, no? (09:38:48 AM) tibbs|h: But I don't see the practical difference between ideograms and accented vowels, either. (09:38:57 AM) racor: tibbs: my point: anything outside of ascii not universal enough (09:38:59 AM) abadger1999: Yum bug: https://bugzilla.redhat.com/show_bug.cgi?id=261961 (09:39:01 AM) buggbot: Bug 261961: low, medium, ---, Jeremy Katz, NEW , Yum does not like non-ascii package names (09:39:14 AM) spot: well, technically we only say summary and description (09:39:18 AM) spot: "Please put personal preferences aside and use American English spelling in the summary and description." (09:39:18 AM) tibbs|h: Either we say "ASCII" or "UTF-8"; there's no point in anything in the middle. (09:39:39 AM) tibbs|h: We do not mandate that the entire spec be in English. (09:39:42 AM) f13: we already support non-ascii file names (09:39:56 AM) f13: so lon gas they are UTF-8 (09:40:00 AM) tibbs|h: We permit translated descriptions. (09:40:28 AM) rdieter: Can we at least agree that ASCII *SHOULD* be used? Not sure if it warrants a MUST. (09:40:40 AM) spot: yeah, i can support that ASCII should be used (09:40:43 AM) abadger1999: rdieter: I'm not sure I would agree with that. (09:40:51 AM) tibbs|h: I don't know if there's really a point. (09:41:05 AM) racor: package names!!! descr, etc. are legacy, convenience, (09:41:21 AM) tibbs|h: But we have rules about naming packages after things like the upstream tarball. (09:41:27 AM) abadger1999: I mean, nim-nim's point is also valid -- if the upstream name is non-ascii who are we to differ from upstream? (09:41:40 AM) rdieter: shrug, I'm ok with pushing the envelope here too. (09:41:58 AM) spot: if only to encourage people not to be stupid and spell things like this: ???? (09:42:11 AM) f13: can we try this package as a trial run and see what all it breaks? (09:42:18 AM) racor: abadger1999: would you say the same if the package name was in cyrillian or turk? (09:42:28 AM) ***spot is getting pulled away (09:42:40 AM) spot: we'll have to pick this up next meeting (09:42:41 AM) spot: sorry. :( (09:42:52 AM) rdieter: f13: +1 :) (09:42:53 AM) abadger1999: racor: What does the package do? Is it a cyrillic font package? Is it something specific to Russian language speakers? (09:43:26 AM) abadger1999: spot: I think that needs to be addressed upstream. (09:43:35 AM) racor: abadger1999: not necessarily. Just author preference. (09:44:09 AM) abadger1999: racor: So that's the gray line for me. I think I'd say that we can try to influence upstream but it is an upstream decision. (09:44:09 AM) tibbs|h: We have a practical issue in any case, because our infrastructure doesn't properly support non-ASCII package names currently. (09:44:27 AM) racor: I could call a package: b?rens??chen ... (09:44:33 AM) tibbs|h: Why not? (09:45:00 AM) tibbs|h: Looks like as good a name as anything else. (09:45:54 AM) racor: tibbs: except that most people would not be able to type it .... yum install (09:46:09 AM) abadger1999: Copy and paste.... (09:46:19 AM) tibbs|h: Graphical interface. (09:46:25 AM) tibbs|h: Tab completion. (09:46:34 AM) tibbs|h: Learn to type German. (09:47:06 AM) racor: abadger1999, tibbs: that's laughable. (09:47:16 AM) tibbs|h: It's weird to see this argument backwards; usually the Americans are arguing for "nothing I can't understand" while the Europeans and Asians just laugh at the idiot luddites. (09:47:46 AM) tibbs|h: "Nothing in Fedora should use the metric system." (09:48:26 AM) racor: tibbs: learn to type Thai (09:49:15 AM) tibbs|h: I personally have no interest in doing so. (09:49:24 AM) tibbs|h: I don't see how that has any bearing on anything, though. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From notting at redhat.com Tue Feb 26 18:44:54 2008 From: notting at redhat.com (Bill Nottingham) Date: Tue, 26 Feb 2008 13:44:54 -0500 Subject: [Fedora-packaging] UTF-8 package names In-Reply-To: <47C459A9.7020609@gmail.com> References: <47C459A9.7020609@gmail.com> Message-ID: <20080226184454.GA27399@nostromo.devel.redhat.com> Toshio Kuratomi (a.badger at gmail.com) said: > Today the Packaging Committee began a discussion of whether package names > should be allowed to contain the full range of Unicode characters (encoded > as UTF-8) or be restricted to the ASCii subset. > > This is a bit of a contentious issue with the Packaging Committee members > split but not yet set in stone about how to proceed. > > The main arguments seem to be: > Pro Unicode: > * Upstream knows best what name is most appropriate for their users. For us > to change it locally in Fedora doesn't make much sense. > * We allow Unicode in every other piece of the spec so why not in the > package name? > * We should be shaking out bugs in the handling of Unicode in our software > rather than hiding issues with it. > > Pro ASCII: > * Hard to type unicode package names, therefore it is a usability problem. > * Is there a limit? Even if European letters are fine what about Kanji or > Sanskrit? > * Some pieces of software won't handle unicode package names and will need > to be fixed. The biggest issue I could see is that any issues in handling such a package would need to be fixed *everywhere* that package is deployed, whether it be current Fedora, earlier Fedora, or EPEL. It may not be practical to deploy such fixes everywhere. Bill From notting at redhat.com Tue Feb 26 18:49:06 2008 From: notting at redhat.com (Bill Nottingham) Date: Tue, 26 Feb 2008 13:49:06 -0500 Subject: [Fedora-packaging] UTF-8 package names In-Reply-To: <20080226184454.GA27399@nostromo.devel.redhat.com> References: <47C459A9.7020609@gmail.com> <20080226184454.GA27399@nostromo.devel.redhat.com> Message-ID: <20080226184906.GA27928@nostromo.devel.redhat.com> Bill Nottingham (notting at redhat.com) said: > The biggest issue I could see is that any issues in handling such a package > would need to be fixed *everywhere* that package is deployed, whether it > be current Fedora, earlier Fedora, or EPEL. It may not be practical to > deploy such fixes everywhere. Consider, for example, that such a package breaks bugzilla. Although I suppose that's one way to avoid getting bug reports. Bill From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Tue Feb 26 18:51:52 2008 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Tue, 26 Feb 2008 19:51:52 +0100 Subject: [Fedora-packaging] UTF-8 package names In-Reply-To: <20080226184454.GA27399@nostromo.devel.redhat.com> References: <47C459A9.7020609@gmail.com> <20080226184454.GA27399@nostromo.devel.redhat.com> Message-ID: <20080226195152.0efdc232@python3.es.egwn.lan> Bill Nottingham wrote : > Toshio Kuratomi (a.badger at gmail.com) said: > > Today the Packaging Committee began a discussion of whether package names > > should be allowed to contain the full range of Unicode characters (encoded > > as UTF-8) or be restricted to the ASCii subset. > > > > This is a bit of a contentious issue with the Packaging Committee members > > split but not yet set in stone about how to proceed. > > > > The main arguments seem to be: > > Pro Unicode: > > * Upstream knows best what name is most appropriate for their users. For us > > to change it locally in Fedora doesn't make much sense. > > * We allow Unicode in every other piece of the spec so why not in the > > package name? > > * We should be shaking out bugs in the handling of Unicode in our software > > rather than hiding issues with it. > > > > Pro ASCII: > > * Hard to type unicode package names, therefore it is a usability problem. > > * Is there a limit? Even if European letters are fine what about Kanji or > > Sanskrit? > > * Some pieces of software won't handle unicode package names and will need > > to be fixed. > > The biggest issue I could see is that any issues in handling such a package > would need to be fixed *everywhere* that package is deployed, whether it > be current Fedora, earlier Fedora, or EPEL. It may not be practical to > deploy such fixes everywhere. Not only where the packages are deployed, but also available from : Some of the ftp/http mirror servers that will be serving the packages might become a problem... Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora release 8 (Werewolf) - Linux kernel 2.6.23.15-137.fc8 Load : 0.21 0.14 0.10 From skvidal at fedoraproject.org Tue Feb 26 18:54:02 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Tue, 26 Feb 2008 13:54:02 -0500 Subject: [Fedora-packaging] UTF-8 package names In-Reply-To: <20080226184906.GA27928@nostromo.devel.redhat.com> References: <47C459A9.7020609@gmail.com> <20080226184454.GA27399@nostromo.devel.redhat.com> <20080226184906.GA27928@nostromo.devel.redhat.com> Message-ID: <1204052042.13100.47.camel@cutter> On Tue, 2008-02-26 at 13:49 -0500, Bill Nottingham wrote: > Bill Nottingham (notting at redhat.com) said: > > The biggest issue I could see is that any issues in handling such a package > > would need to be fixed *everywhere* that package is deployed, whether it > > be current Fedora, earlier Fedora, or EPEL. It may not be practical to > > deploy such fixes everywhere. > > Consider, for example, that such a package breaks bugzilla. Although I > suppose that's one way to avoid getting bug reports. > /me renames yum to ??? :-D -sv From Axel.Thimm at ATrpms.net Tue Feb 26 18:55:13 2008 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 26 Feb 2008 20:55:13 +0200 Subject: [Fedora-packaging] Re: UTF-8 package names In-Reply-To: <47C459A9.7020609@gmail.com> References: <47C459A9.7020609@gmail.com> Message-ID: <20080226185513.GA26656@puariko.nirvana> On Tue, Feb 26, 2008 at 10:25:45AM -0800, Toshio Kuratomi wrote: > Pro ASCII: > * Hard to type unicode package names, therefore it is a usability problem. > * Is there a limit? Even if European letters are fine what about Kanji or > Sanskrit? > * Some pieces of software won't handle unicode package names and will need > to be fixed. Also consider that package names define the file set that is to bemirrored and you thus need to assume that all mirrors properly support utf on their filesystems and their ftp/web/rsync servers. If not you end up with changed package names on their way to the consumer and non reproducable bug reports about yum not finding packages (as the metadata will contain the proper UTF8 name while the filesystem may present another). So it's not about UTF8 deficiencies in any Fedora component, but rather the (non) globality of UTF8. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From nicolas.mailhot at laposte.net Tue Feb 26 19:46:15 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 26 Feb 2008 20:46:15 +0100 Subject: [Fedora-packaging] Re: UTF-8 package names In-Reply-To: <20080226185513.GA26656@puariko.nirvana> References: <47C459A9.7020609@gmail.com> <20080226185513.GA26656@puariko.nirvana> Message-ID: <1204055175.9193.20.camel@rousalka.dyndns.org> Le mardi 26 f?vrier 2008 ? 20:55 +0200, Axel Thimm a ?crit : > On Tue, Feb 26, 2008 at 10:25:45AM -0800, Toshio Kuratomi wrote: > > Pro ASCII: > > * Hard to type unicode package names, therefore it is a usability problem. The solution to this particular problem has already been suggested by someone else: just have an ASCII transliteration alias as additional Provides. > > * Some pieces of software won't handle unicode package names and will need > > to be fixed. That's too bad for them :p > Also consider that package names define the file set that is to > bemirrored and you thus need to assume that all mirrors properly > support utf on their filesystems and their ftp/web/rsync servers. Is this really a problem? File systems do not interpret file names, so they are going to store byte strings as they get them. The typical UTF-8 problems you get are apps that write invalid UTF-8 names because they think they'll be interpreted as something else, or apps that display UTF-8 names wrong because they think they've been written in another encoding (and try to translate from this encoding to UTF-8), but low-level mirroring tools are just going to reproduce file names as-is. (that is unless you use one of the few non-unix/non-posix systems that store filename encoding information in the filesystem, but those can not import foreign filesystem data without the admin defining the encoding to use anyway) -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From nicolas.mailhot at laposte.net Tue Feb 26 19:48:11 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 26 Feb 2008 20:48:11 +0100 Subject: [Fedora-packaging] UTF-8 package names In-Reply-To: <20080226184906.GA27928@nostromo.devel.redhat.com> References: <47C459A9.7020609@gmail.com> <20080226184454.GA27399@nostromo.devel.redhat.com> <20080226184906.GA27928@nostromo.devel.redhat.com> Message-ID: <1204055291.9193.22.camel@rousalka.dyndns.org> Le mardi 26 f?vrier 2008 ? 13:49 -0500, Bill Nottingham a ?crit : > Bill Nottingham (notting at redhat.com) said: > > The biggest issue I could see is that any issues in handling such a package > > would need to be fixed *everywhere* that package is deployed, whether it > > be current Fedora, earlier Fedora, or EPEL. It may not be practical to > > deploy such fixes everywhere. > > Consider, for example, that such a package breaks bugzilla. Although I > suppose that's one way to avoid getting bug reports. The latest bugzilla versions are supposed to be UTF-8 compatible. Previous ones are just an encoding mess. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From ssorce at redhat.com Tue Feb 26 20:16:56 2008 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 26 Feb 2008 15:16:56 -0500 Subject: [Fedora-packaging] UTF-8 package names In-Reply-To: <47C459A9.7020609@gmail.com> References: <47C459A9.7020609@gmail.com> Message-ID: <1204057016.5684.21.camel@localhost.localdomain> On Tue, 2008-02-26 at 10:25 -0800, Toshio Kuratomi wrote: > Today the Packaging Committee began a discussion of whether package > names should be allowed to contain the full range of Unicode > characters > (encoded as UTF-8) or be restricted to the ASCii subset. 1. If the upstream package is an i18n name, how do you make up an ASCII name for it? 2. What is the technical reason to restrict package names to ASCII? NOTE: I do not consider broken apps a good reason, although I could understand for example having to wait before allowing non-ASCII name to when python is fixed, just to name a core package that may have problems. Simo. -- Simo Sorce * Red Hat, Inc * New York From Axel.Thimm at ATrpms.net Tue Feb 26 21:19:03 2008 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 26 Feb 2008 23:19:03 +0200 Subject: [Fedora-packaging] Re: UTF-8 package names In-Reply-To: <1204055175.9193.20.camel@rousalka.dyndns.org> References: <47C459A9.7020609@gmail.com> <20080226185513.GA26656@puariko.nirvana> <1204055175.9193.20.camel@rousalka.dyndns.org> Message-ID: <20080226211903.GA28078@puariko.nirvana> On Tue, Feb 26, 2008 at 08:46:15PM +0100, Nicolas Mailhot wrote: > > Also consider that package names define the file set that is to > > bemirrored and you thus need to assume that all mirrors properly > > support utf on their filesystems and their ftp/web/rsync servers. > > Is this really a problem? File systems do not interpret file names, so > they are going to store byte strings as they get them. Which is the problem. Since this is not any metadata you store anywhere it is something defined locally. And if you mirror the raw UTF8 filenames onto a mirror that has set local policy to be latin1 the web server will serve funny ~A names. There are many issues with filename encoding otherwise there wouldn't exist any tools like convmv which seems to be still widely used and had an update release just a month ago: http://www.j3e.de/linux/convmv/man/ BTW it quotes NFS4 and JFS as being encoding aware. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ssorce at redhat.com Tue Feb 26 21:58:44 2008 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 26 Feb 2008 16:58:44 -0500 Subject: [Fedora-packaging] Re: UTF-8 package names In-Reply-To: <20080226211903.GA28078@puariko.nirvana> References: <47C459A9.7020609@gmail.com> <20080226185513.GA26656@puariko.nirvana> <1204055175.9193.20.camel@rousalka.dyndns.org> <20080226211903.GA28078@puariko.nirvana> Message-ID: <1204063124.5684.43.camel@localhost.localdomain> On Tue, 2008-02-26 at 23:19 +0200, Axel Thimm wrote: > Which is the problem. Since this is not any metadata you store > anywhere it is something defined locally. And if you mirror the raw > UTF8 filenames onto a mirror that has set local policy to be latin1 > the web server will serve funny ~A names. So are you claiming that mirrors can't be fixed ? You know, it is very easy to test how many would break with an utf-8 name, just add somewhere an unused file with an utf-8 name and check if any mirror breaks. (not referring to you Axel from now on) I think that resistance against standardizing around utf8 is getting ridiculous at this point. I understand that people that never used anything but ASCII may find it annoying that there are people out there that use funny characters, but I wonder when they will realize that they are the minority in the world, and that the others would like to be treated like first class citizens like everybody else. Unless there is a very compelling technical problem, I think we should try as hard as possible to support and use by default utf8 everywhere. The more we use it, the more we uncover bugs that we can hopefully fix. And yes, I understand that a package name that is written in pure Cyrillic or Chinese, or Japanese maybe hard initially to swallow (and type), but how many chances are that everybody suddenly will start doing that? Upstream is usually not stupid and understands that using non ASCII characters may limit distribution. I guess only packages that make sense only locally "may" end up with something like a completely non-ASCII name. If this is really a usability problem I am sure that the proposal to provide an alternate ASCII only name (need rules to determine how you get from non-ASCII to ASCII) is a very good one, even if copy&paste, or other UIs can be used as well. Simo. -- Simo Sorce * Red Hat, Inc * New York From jkeating at redhat.com Tue Feb 26 22:29:34 2008 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 26 Feb 2008 17:29:34 -0500 Subject: [Fedora-packaging] UTF-8 package names In-Reply-To: <1204055291.9193.22.camel@rousalka.dyndns.org> References: <47C459A9.7020609@gmail.com> <20080226184454.GA27399@nostromo.devel.redhat.com> <20080226184906.GA27928@nostromo.devel.redhat.com> <1204055291.9193.22.camel@rousalka.dyndns.org> Message-ID: <20080226172934.071de958@redhat.com> On Tue, 26 Feb 2008 20:48:11 +0100 Nicolas Mailhot wrote: > The latest bugzilla versions are supposed to be UTF-8 compatible. > Previous ones are just an encoding mess. Sure, but we're not running the latest one, yet. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From rc040203 at freenet.de Tue Feb 26 22:09:28 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 26 Feb 2008 23:09:28 +0100 Subject: [Fedora-packaging] UTF-8 package names In-Reply-To: <1204052042.13100.47.camel@cutter> References: <47C459A9.7020609@gmail.com> <20080226184454.GA27399@nostromo.devel.redhat.com> <20080226184906.GA27928@nostromo.devel.redhat.com> <1204052042.13100.47.camel@cutter> Message-ID: <1204063768.3446.50.camel@beck.corsepiu.local> On Tue, 2008-02-26 at 13:54 -0500, seth vidal wrote: > On Tue, 2008-02-26 at 13:49 -0500, Bill Nottingham wrote: > > Bill Nottingham (notting at redhat.com) said: > > > The biggest issue I could see is that any issues in handling such a package > > > would need to be fixed *everywhere* that package is deployed, whether it > > > be current Fedora, earlier Fedora, or EPEL. It may not be practical to > > > deploy such fixes everywhere. To me, these are the least issues. They are of a technical nature and can be overcome/fixed (utf-8) My concern is usability of the distro. IMO, we can not avoid to restrict certain aspects of the distro to the least common denominator. Package-names are such a case. > > Consider, for example, that such a package breaks bugzilla. Although I > > suppose that's one way to avoid getting bug reports. > > > > /me renames yum to ??? Is this Farsi, Arab or Hebrew? Proposal: Let's rename the bodhi and koji packages + their primary executables into their Indian rsp. Japanese equivalents :) Ralf From dominik at greysector.net Wed Feb 27 00:56:34 2008 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Wed, 27 Feb 2008 01:56:34 +0100 Subject: [Fedora-packaging] UTF-8 package names In-Reply-To: <1204063768.3446.50.camel@beck.corsepiu.local> References: <47C459A9.7020609@gmail.com> <20080226184454.GA27399@nostromo.devel.redhat.com> <20080226184906.GA27928@nostromo.devel.redhat.com> <1204052042.13100.47.camel@cutter> <1204063768.3446.50.camel@beck.corsepiu.local> Message-ID: <20080227005634.GB3306@ryvius.greysector.net> On Tuesday, 26 February 2008 at 23:09, Ralf Corsepius wrote: > > On Tue, 2008-02-26 at 13:54 -0500, seth vidal wrote: > > On Tue, 2008-02-26 at 13:49 -0500, Bill Nottingham wrote: > > > Bill Nottingham (notting at redhat.com) said: > > > > The biggest issue I could see is that any issues in handling such a package > > > > would need to be fixed *everywhere* that package is deployed, whether it > > > > be current Fedora, earlier Fedora, or EPEL. It may not be practical to > > > > deploy such fixes everywhere. > To me, these are the least issues. They are of a technical nature and > can be overcome/fixed (utf-8) > > My concern is usability of the distro. > > IMO, we can not avoid to restrict certain aspects of the distro to the > least common denominator. Package-names are such a case. > > > > Consider, for example, that such a package breaks bugzilla. Although I > > > suppose that's one way to avoid getting bug reports. > > > > > > > /me renames yum to ??? > Is this Farsi, Arab or Hebrew? > > Proposal: Let's rename the bodhi and koji packages + their primary > executables into their Indian rsp. Japanese equivalents :) I, for one, have nothing against ??. At least I wouldn't have to cringe at the bad romanization that's used all over the place. :P As for executables, you can always do something like # ln -s ?? /usr/bin/koji and ship both... just kidding. Although this discussion sheds an entirely new light on l10n/i18n. Imagine a fully localised system, where not only messages, but also everything else is translated into local language. /me imagines typing (pl_PL.UTF-8 locale) $ znajd? . -typ p -upr 0600 -drukuj Oh, the horror. ;) Regards, R. -- Fedora contributor http://fedoraproject.org/wiki/DominikMierzejewski Livna contributor http://rpm.livna.org MPlayer developer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From jdennis at redhat.com Wed Feb 27 01:23:22 2008 From: jdennis at redhat.com (John Dennis) Date: Tue, 26 Feb 2008 20:23:22 -0500 Subject: [Fedora-packaging] are subpackages required for optional loadable libraries? Message-ID: <47C4BB8A.9090907@redhat.com> Historically when a package includes optional support via a loadable module we've put the loadable module in a subpackage. For example a package might include a module supporting mysql so we would create a mysql subpackage which contains the mysql loadable module and the subpackage would require mysql. I presume the reason we've historically created these little subpackages is to deal with dependency issues. But suppose your package includes dozens of optional loadable modules does it still make sense to create dozens of subpackages? It starts to get unwieldly really quick. Is it permissible to skip all the subpackages, have the rpm include all the loadable modules, and put the onus on the user such that if they edit the main package's config file to load the mysql module it's up to them to make sure the mysql libraries are installed? Here's another issue: Suppose the package puts it's loadable modules (e.g. .so's) in it's own subdirectory for loadable modules. RPM's automatic dependency checking seems to completely miss all the external libraries needed at run time to load one of the modules and resolve all it's references. The net result is none of these external dependencies get picked up at all. Is that O.K.? How does one deal with that in a spec file? The answer to this question probably drives the answer to the first question. FWIW, the upstream spec file does not create a subpackage per loadable module. It does create a subpackage containing all the loadable modules. When we build the loadable module subpackage the resulting rpm is missing a lot of the external dependencies on external .so's. That's unfortunate but I'm thinking it's the only practical way to deal with it. Trying to factor out all the dependencies will be a packaging nightmare and it's going to be a headache for users trying to install, they're going to have to deal with lots of subpackages. At least with the scheme where all the loadable modules are in one subpackage you won't pull in stuff you don't want or need, but at the expense of not pulling in something you might need. Comments? -- John Dennis From dominik at greysector.net Wed Feb 27 01:31:41 2008 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Wed, 27 Feb 2008 02:31:41 +0100 Subject: [Fedora-packaging] are subpackages required for optional loadable libraries? In-Reply-To: <47C4BB8A.9090907@redhat.com> References: <47C4BB8A.9090907@redhat.com> Message-ID: <20080227013141.GC3306@ryvius.greysector.net> On Wednesday, 27 February 2008 at 02:23, John Dennis wrote: > Historically when a package includes optional support via a loadable module > we've put the loadable module in a subpackage. For example a package might > include a module supporting mysql so we would create a mysql subpackage > which contains the mysql loadable module and the subpackage would require > mysql. I presume the reason we've historically created these little > subpackages is to deal with dependency issues. > > But suppose your package includes dozens of optional loadable modules does > it still make sense to create dozens of subpackages? IMHO it does make sense. I know disk space is cheap, but still I prefer to keep my system free of any unnecessary stuff. > It starts to get unwieldly really quick. What exactly is the problem? > Is it permissible to skip all the subpackages, have > the rpm include all the loadable modules, and put the onus on the user such > that if they edit the main package's config file to load the mysql module > it's up to them to make sure the mysql libraries are installed? > > Here's another issue: Suppose the package puts it's loadable modules (e.g. > .so's) in it's own subdirectory for loadable modules. RPM's automatic > dependency checking seems to completely miss all the external libraries > needed at run time to load one of the modules and resolve all it's > references. The net result is none of these external dependencies get > picked up at all. Is that O.K.? How does one deal with that in a spec file? > The answer to this question probably drives the answer to the first > question. I find it odd that it doesn't find the dependencies on external libraries. Could you show the package to us? It may be a bug in the dependency generator. > FWIW, the upstream spec file does not create a subpackage per loadable > module. It does create a subpackage containing all the loadable modules. > When we build the loadable module subpackage the resulting rpm is missing a > lot of the external dependencies on external .so's. That's unfortunate but > I'm thinking it's the only practical way to deal with it. Trying to factor > out all the dependencies will be a packaging nightmare and it's going to be > a headache for users trying to install, they're going to have to deal with > lots of subpackages. At least with the scheme where all the loadable > modules are in one subpackage you won't pull in stuff you don't want or > need, but at the expense of not pulling in something you might need. > Comments? Well, without seeing the package, it's difficult to comment on this. I still think it's desirable to split the parts that require additional external libraries as much as possible. Regards, R. -- Fedora contributor http://fedoraproject.org/wiki/DominikMierzejewski Livna contributor http://rpm.livna.org MPlayer developer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From a.badger at gmail.com Wed Feb 27 01:33:33 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 26 Feb 2008 17:33:33 -0800 Subject: [Fedora-packaging] UTF-8 package names In-Reply-To: <20080227005634.GB3306@ryvius.greysector.net> References: <47C459A9.7020609@gmail.com> <20080226184454.GA27399@nostromo.devel.redhat.com> <20080226184906.GA27928@nostromo.devel.redhat.com> <1204052042.13100.47.camel@cutter> <1204063768.3446.50.camel@beck.corsepiu.local> <20080227005634.GB3306@ryvius.greysector.net> Message-ID: <47C4BDED.20308@gmail.com> Dominik 'Rathann' Mierzejewski wrote: > On Tuesday, 26 February 2008 at 23:09, Ralf Corsepius wrote: >> On Tue, 2008-02-26 at 13:54 -0500, seth vidal wrote: >>> On Tue, 2008-02-26 at 13:49 -0500, Bill Nottingham wrote: >>>> Bill Nottingham (notting at redhat.com) said: >>>>> The biggest issue I could see is that any issues in handling such a package >>>>> would need to be fixed *everywhere* that package is deployed, whether it >>>>> be current Fedora, earlier Fedora, or EPEL. It may not be practical to >>>>> deploy such fixes everywhere. >> To me, these are the least issues. They are of a technical nature and >> can be overcome/fixed (utf-8) >> >> My concern is usability of the distro. >> >> IMO, we can not avoid to restrict certain aspects of the distro to the >> least common denominator. Package-names are such a case. >> >>>> Consider, for example, that such a package breaks bugzilla. Although I >>>> suppose that's one way to avoid getting bug reports. >>>> >>> /me renames yum to ??? >> Is this Farsi, Arab or Hebrew? >> >> Proposal: Let's rename the bodhi and koji packages + their primary >> executables into their Indian rsp. Japanese equivalents :) > > I, for one, have nothing against ??. At least I wouldn't have to cringe > at the bad romanization that's used all over the place. :P > > As for executables, you can always do something like > # ln -s ?? /usr/bin/koji > and ship both... just kidding. > This does bring up on interesting point. The package name has been brought up as a usability concern for those who aren't used to trying to type non-ASCii characters. However if an upstream was producing a program whose binary was non-ASCii we'd currently allow inclusion (and I would be even more opposed to changing that without getting upstream to make the change than changing the package name.) For a possible valid use, think of this potential pair of tools for students learning Japanese: /usr/bin/????2r?maji /usr/bin/r?maji2???? > Although this discussion sheds an entirely new light on l10n/i18n. Imagine > a fully localised system, where not only messages, but also everything else > is translated into local language. > > /me imagines typing (pl_PL.UTF-8 locale) > > $ znajd? . -typ p -upr 0600 -drukuj > > Oh, the horror. ;) Nonsense! Since there are so many things on the filesystem which aren't real words (what's a "usr", what's a "gnumeric"?) we should obviously forgo translation and instead do transliteration! :-) -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From jkeating at redhat.com Wed Feb 27 01:53:16 2008 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 26 Feb 2008 20:53:16 -0500 Subject: [Fedora-packaging] are subpackages required for optional loadable libraries? In-Reply-To: <20080227013141.GC3306@ryvius.greysector.net> References: <47C4BB8A.9090907@redhat.com> <20080227013141.GC3306@ryvius.greysector.net> Message-ID: <20080226205316.2962349d@redhat.com> On Wed, 27 Feb 2008 02:31:41 +0100 "Dominik 'Rathann' Mierzejewski" wrote: > I find it odd that it doesn't find the dependencies on external > libraries. Could you show the package to us? It may be a bug in the > dependency generator. First guess, the shared objects aren't marked as executable. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From jdennis at redhat.com Wed Feb 27 02:07:52 2008 From: jdennis at redhat.com (John Dennis) Date: Tue, 26 Feb 2008 21:07:52 -0500 Subject: [Fedora-packaging] are subpackages required for optional loadable libraries? In-Reply-To: <20080226205316.2962349d@redhat.com> References: <47C4BB8A.9090907@redhat.com> <20080227013141.GC3306@ryvius.greysector.net> <20080226205316.2962349d@redhat.com> Message-ID: <47C4C5F8.8090700@redhat.com> Jesse Keating wrote: > On Wed, 27 Feb 2008 02:31:41 +0100 > "Dominik 'Rathann' Mierzejewski" wrote: > >> I find it odd that it doesn't find the dependencies on external >> libraries. Could you show the package to us? It may be a bug in the >> dependency generator. > > First guess, the shared objects aren't marked as executable. The are marked executable, but they aren't in a standard lib directory. -- John Dennis From peter at thecodergeek.com Wed Feb 27 02:08:10 2008 From: peter at thecodergeek.com (Peter Gordon) Date: Tue, 26 Feb 2008 18:08:10 -0800 Subject: [Fedora-packaging] UTF-8 package names In-Reply-To: <47C459A9.7020609@gmail.com> References: <47C459A9.7020609@gmail.com> Message-ID: <1204078090.8024.34.camel@tuxhugs> On Tue, 2008-02-26 at 10:25 -0800, Toshio Kuratomi wrote: > Pro ASCII: > * Hard to type unicode package names, therefore it is a usability problem. > * Is there a limit? Even if European letters are fine what about Kanji > or Sanskrit? Japanese package names would really be odd here. Would we spell the package name with its kanji or its phonetic (e.g., hiragana) reading? For example, say there were a package called ?????(R?maji: "benkyoo", English: study) which had flash-cards or some helpful studying software. Would we name this package by this Kanji, or its hiragana equivalent ???????? Would we require the package to have Provides for this kana reading if named in Kanji, and vice-versa? What about transliterations (so-called "R?maji"): What transliteration system [1] should we use? If we do require the Provides, what if two packages end up being different kanji names that are homophones (read the same, phonetically)? One example that comes to mind is between ? and ? (both flower) and ? (nose), all read as "hana" (hiragana: ??)? For even more fun, ? (god), ? (paper), and ? (hair) all have readings of "kami" (??). And extending this to kanji compounds will yield even further enjoyment: ?? (tomorrow) can be read as "asu" (??) or "ashita" (???), and ? ? (yesterday) can be read as?"kinoo" (???) or "sakujitsu" (??? ?) depending on formality. I suppose it would be similar for other languages based on both phonetic and logographic scripts, but I use Japanese as my example since that's what I'm attempting to learn currently. :) What about misc technical characters too - arrows (? ? ? ?) or the like? This can get quite overwhelming if we're not very careful. In closing, I think it would be best to limit this to diacritic/accented characters. With an additional transliterated Provides, the ease case would be satisified, without the complexities provided by such writing systems as above. [1] http://en.wikipedia.org/wiki/R?maji#Modern_systems (And as a completely tangential aside, SCIM is *awesome*.) -- Peter Gordon (codergeek42) GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jdennis at redhat.com Wed Feb 27 02:27:57 2008 From: jdennis at redhat.com (John Dennis) Date: Tue, 26 Feb 2008 21:27:57 -0500 Subject: [Fedora-packaging] are subpackages required for optional loadable libraries? In-Reply-To: <20080227013141.GC3306@ryvius.greysector.net> References: <47C4BB8A.9090907@redhat.com> <20080227013141.GC3306@ryvius.greysector.net> Message-ID: <47C4CAAD.5080904@redhat.com> Dominik 'Rathann' Mierzejewski wrote: > On Wednesday, 27 February 2008 at 02:23, John Dennis wrote: >> Historically when a package includes optional support via a loadable module >> we've put the loadable module in a subpackage. For example a package might >> include a module supporting mysql so we would create a mysql subpackage >> which contains the mysql loadable module and the subpackage would require >> mysql. I presume the reason we've historically created these little >> subpackages is to deal with dependency issues. >> >> But suppose your package includes dozens of optional loadable modules does >> it still make sense to create dozens of subpackages? > > IMHO it does make sense. I know disk space is cheap, but still I prefer > to keep my system free of any unnecessary stuff. Using the scheme upstream uses (a subpackage with all the loadable modules) you won't pull in any unnecessary stuff. >> It starts to get unwieldly really quick. > > What exactly is the problem? Creating a lot of subpackages, figuring out the dependency list for each of them, and then asking the user understand which of many subpackages he really needs, something which changes when he edits the main packages config file which changes the set of loaded modules. I see two potential complaints, each representing one end of a spectrum: 1) The main package is broken, it pulls in stuff I don't want (your issue). 2) The main package is broken, every time I try running the package in a different configuration I have to install some other subpackage, why can't they all just be there so I don't have to figure it out? (btw, figuring out which subpackage is needed means knowing enough to look for errors in the daemon's error log when it doesn't start successfully, that doesn't seem very friendly either). -- John Dennis From a.badger at gmail.com Wed Feb 27 02:52:24 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 26 Feb 2008 18:52:24 -0800 Subject: [Fedora-packaging] UTF-8 package names In-Reply-To: <1204078090.8024.34.camel@tuxhugs> References: <47C459A9.7020609@gmail.com> <1204078090.8024.34.camel@tuxhugs> Message-ID: <47C4D068.8060809@gmail.com> Peter Gordon wrote: > On Tue, 2008-02-26 at 10:25 -0800, Toshio Kuratomi wrote: >> Pro ASCII: >> * Hard to type unicode package names, therefore it is a usability problem. >> * Is there a limit? Even if European letters are fine what about Kanji >> or Sanskrit? > > Japanese package names would really be odd here. Would we spell the > package name with its kanji or its phonetic (e.g., hiragana) reading? > For example, say there were a package called ?????(R?maji: > "benkyoo", English: study) which had flash-cards or some helpful > studying software. Would we name this package by this Kanji, or its > hiragana equivalent > ???????? Would we require the package to have Provides for this > kana reading if named in Kanji, and vice-versa? What about > transliterations (so-called "R?maji"): What transliteration system [1] > should we use? > > If we do require the Provides, what if two packages end up being > different kanji names that are homophones (read the same, phonetically)? > One example that comes to mind is between ? and ? (both flower) and ? > (nose), all read as "hana" (hiragana: ??)? For even more fun, ? > (god), ? (paper), and ? (hair) all have readings of "kami" (??). And > extending this to kanji compounds will yield even further enjoyment: > ?? (tomorrow) can be read as "asu" (??) or "ashita" (???), and ? > ? (yesterday) can be read as?"kinoo" (???) or "sakujitsu" (??? > ?) depending on formality. > > I suppose it would be similar for other languages based on both phonetic > and logographic scripts, but I use Japanese as my example since that's > what I'm attempting to learn currently. :) > > What about misc technical characters too - arrows (? ? ? ?) or the like? > This can get quite overwhelming if we're not very careful. > Well, there was ? for a while but that looks to be pretty dead upstream. I'm sure that there will be more at some point, though. > In closing, I think it would be best to limit this to diacritic/accented > characters. With an additional transliterated Provides, the ease case > would be satisified, without the complexities provided by such writing > systems as above. > You do a wonderful job of explaining what's wrong with us trying to adjust upstream's name to be ASCII but I just want to be certain we're on the same page by the end: Package names should follow upstream since attempting to transliterate or translate upstream names can't be done sanely on our side. For things that map easily into the ASCii set (diacritic/accented characters, for instance, as found in latin-1) a transliterated Provides can be added to make installation easier for ASCii-conditioned users but carrying this on to other scripts is a losing proposition. Thanks, -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From a.badger at gmail.com Wed Feb 27 02:55:53 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 26 Feb 2008 18:55:53 -0800 Subject: [Fedora-packaging] are subpackages required for optional loadable libraries? In-Reply-To: <47C4BB8A.9090907@redhat.com> References: <47C4BB8A.9090907@redhat.com> Message-ID: <47C4D139.3020904@gmail.com> John Dennis wrote: > I presume the reason we've historically > created these little subpackages is to deal with dependency issues. > Yep. > But suppose your package includes dozens of optional loadable modules > does it still make sense to create dozens of subpackages? It starts to > get unwieldly really quick. Is it permissible to skip all the > subpackages, have the rpm include all the loadable modules, and put the > onus on the user such that if they edit the main package's config file > to load the mysql module it's up to them to make sure the mysql > libraries are installed? > I'm inclined to say it depends. A specific package would help. [snip] > > FWIW, the upstream spec file does not create a subpackage per loadable > module. It does create a subpackage containing all the loadable modules. > When we build the loadable module subpackage the resulting rpm is > missing a lot of the external dependencies on external .so's. That's > unfortunate but I'm thinking it's the only practical way to deal with > it. Trying to factor out all the dependencies will be a packaging > nightmare This is what a packager is supposed to do, however... deal with the pain so that the user gets the best experience possible. > and it's going to be a headache for users trying to install, > they're going to have to deal with lots of subpackages. This is the real concern, I'd think. We want to make user's lives as easy as possible. In some cases this means we need to break up a package and in other cases we don't. For instance, I would say that most packages that have a separate plugin for each of postgres, mysql, and sqlite need to have those plugins separated into different subpackages as an end-user is most likely going to be using one of the above databases, not all three. In this case, the subpackages should also depend on the libraries necessary to make it work right out of the box. OTOH, there's a package like python-sqlalchemy which provides a database abstraction and ORM library for programs to use. It doesn't make sense for this library to depend on all three of postgres, mysql, and sqlite when it can work equally well with any of them. So the questions I'd see us needing to address are: 1) What are the criteria to split a package into multiple subpackages as opposed to keeping modules in a single/few subpackage. 2) When a subpackage is not split, should Requires be used to pull in all of the dependencies or should they be used to pull in none of the dependencies. 3) What is the default level of functionality that should work out of the box? -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From dominik at greysector.net Wed Feb 27 03:17:54 2008 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Wed, 27 Feb 2008 04:17:54 +0100 Subject: [Fedora-packaging] are subpackages required for optional loadable libraries? In-Reply-To: <47C4D139.3020904@gmail.com> References: <47C4BB8A.9090907@redhat.com> <47C4D139.3020904@gmail.com> Message-ID: <20080227031753.GE3306@ryvius.greysector.net> On Wednesday, 27 February 2008 at 03:55, Toshio Kuratomi wrote: [...] > So the questions I'd see us needing to address are: > > 1) What are the criteria to split a package into multiple subpackages as > opposed to keeping modules in a single/few subpackage. Plugins implementing the same functionality using different external libraries (database engine support plugins are a typical example) must be packaged separately. A developer testing if the software works equally well with all supported DBEs will just have to install all of them by hand. We'll assume he's competent enough to do it. If the plugins do different things, it should be left for the packager to decide. Meta-packages come handy here (and are my preferred solution). > 2) When a subpackage is not split, should Requires be used to pull in all > of the dependencies or should they be used to pull in none of the > dependencies. All, of course. Otherwise we end up with bugreports saying the plugins don't work (because we intentionally crippled them). > 3) What is the default level of functionality that should work out of the > box? That should be left for the packager to decide. Regards, R. -- Fedora contributor http://fedoraproject.org/wiki/DominikMierzejewski Livna contributor http://rpm.livna.org MPlayer developer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From skvidal at fedoraproject.org Wed Feb 27 03:51:32 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Tue, 26 Feb 2008 22:51:32 -0500 Subject: [Fedora-packaging] UTF-8 package names In-Reply-To: <47C459A9.7020609@gmail.com> References: <47C459A9.7020609@gmail.com> Message-ID: <1204084292.13100.66.camel@cutter> On Tue, 2008-02-26 at 10:25 -0800, Toshio Kuratomi wrote: > (09:38:59 AM) abadger1999: Yum bug: > https://bugzilla.redhat.com/show_bug.cgi?id=261961 > (09:39:01 AM) buggbot: Bug 261961: low, medium, ---, Jeremy Katz, NEW , > Yum does not like non-ascii package names I was talking with Tim about this some today since he recently applied a patch for a similar (and somewhat related) problem. We need to make sure we catch it in a number of places but it is something we want to do. there's no institutional resistance to fixing this. -sv From skvidal at fedoraproject.org Wed Feb 27 03:52:02 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Tue, 26 Feb 2008 22:52:02 -0500 Subject: [Fedora-packaging] UTF-8 package names In-Reply-To: <1204063768.3446.50.camel@beck.corsepiu.local> References: <47C459A9.7020609@gmail.com> <20080226184454.GA27399@nostromo.devel.redhat.com> <20080226184906.GA27928@nostromo.devel.redhat.com> <1204052042.13100.47.camel@cutter> <1204063768.3446.50.camel@beck.corsepiu.local> Message-ID: <1204084322.13100.68.camel@cutter> On Tue, 2008-02-26 at 23:09 +0100, Ralf Corsepius wrote: > > > > /me renames yum to ??? > Is this Farsi, Arab or Hebrew? It is 3 random chars pulled off of the gnome-character-map :) -sv From peter at thecodergeek.com Wed Feb 27 04:05:01 2008 From: peter at thecodergeek.com (Peter Gordon) Date: Tue, 26 Feb 2008 20:05:01 -0800 Subject: [Fedora-packaging] UTF-8 package names In-Reply-To: <47C4D068.8060809@gmail.com> References: <47C459A9.7020609@gmail.com> <1204078090.8024.34.camel@tuxhugs> <47C4D068.8060809@gmail.com> Message-ID: <1204085101.10949.36.camel@tuxhugs> On Tue, 2008-02-26 at 18:52 -0800, Toshio Kuratomi wrote: > You do a wonderful job of explaining what's wrong with us trying to > adjust upstream's name to be ASCII but I just want to be certain we're > on the same page by the end: > > Package names should follow upstream since attempting to transliterate > or translate upstream names can't be done sanely on our side. For > things that map easily into the ASCii set (diacritic/accented > characters, for instance, as found in latin-1) a transliterated Provides > can be added to make installation easier for ASCii-conditioned users but > carrying this on to other scripts is a losing proposition. That's exactly what I was trying to explain, yes. Sorry for the rambling if it seemed that way. Rethinking this though, I feel that accented and diacritic-related characters (?, ?, ?, ?, ?, et al.) would be quite suitable but we would have to pay attention to the language of origin. For our example here, the transliterations would probably be simply removing the diacritic as appropriate: a, e, o, n, and ae. In some languages, though, the diacritic differentiates the character from the "plain" form. For example, a Spanish package name for a similar studying software could be "?Estudiar?!" (third-person indicative future tense; literally, "You will study!"). However, we would need to be careful here because, without that accent, this changes the conjugation to "estudiara," which is the first- and third-person imperfect subjunctive (which really makes no sense on its own, since the subjunctive tense is meant to be used in a subjective or predictive clause of a sentence, such as referring to one's wants and desires for the future). Also, transliterating ? if we know the source language to be Spanish (or other similar languages) would change it a bit, since it's actually pronounced as "ny-": "?o" would be pronounced as "nyo"; "?at" would be "nyat" and so on. (Not that these are actual words, but they are parts thereof.) If we allowed accents and whatnot, maybe we should restrict the transliteration to simply removing all diacritics and splitting "merged" letters (? --> ae, etc.). That way we would not have to worry too much more. (Again, using Spanish as an example due to familiarity.) However, trying to force things into ASCII or even some variation of roman-alphabet text is going to be extremely difficult and quite confusing for languages for which that is not the norm. I just though of another example for my previous message. (Jee, I seem to love these. Apologies...) What happens when the package name is only Han characters? Do we transliterate it to the Japanese (Kanji) reading, or the Korean (Hanja) reading, or the native Chinese reading? :P But I digress. Thanks for your time. -- Peter Gordon (codergeek42) GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From smooge at gmail.com Wed Feb 27 04:47:39 2008 From: smooge at gmail.com (Stephen John Smoogen) Date: Tue, 26 Feb 2008 21:47:39 -0700 Subject: [Fedora-packaging] UTF-8 package names In-Reply-To: <1204084322.13100.68.camel@cutter> References: <47C459A9.7020609@gmail.com> <20080226184454.GA27399@nostromo.devel.redhat.com> <20080226184906.GA27928@nostromo.devel.redhat.com> <1204052042.13100.47.camel@cutter> <1204063768.3446.50.camel@beck.corsepiu.local> <1204084322.13100.68.camel@cutter> Message-ID: <80d7e4090802262047u2b7448e7qd0b891f925bfc08b@mail.gmail.com> On Tue, Feb 26, 2008 at 8:52 PM, seth vidal wrote: > > On Tue, 2008-02-26 at 23:09 +0100, Ralf Corsepius wrote: > > > > > > /me renames yum to ??? > > Is this Farsi, Arab or Hebrew? > > It is 3 random chars pulled off of the gnome-character-map :) > The area that I am going to look forward to is when a package has what looks like an ascii character but turns out to be a different UTF version of that letter. The example I remember from class was where the word nonny-nonny had 6 different 'types' of n. Looking at it where they all showed up as \uBLAH was easy but in a completely UTF compliant screen you couldnt just type it. Not that Fedora has to deal with support tickets.. -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From rc040203 at freenet.de Wed Feb 27 01:43:37 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 27 Feb 2008 02:43:37 +0100 Subject: [Fedora-packaging] Re: UTF-8 package names In-Reply-To: <1204063124.5684.43.camel@localhost.localdomain> References: <47C459A9.7020609@gmail.com> <20080226185513.GA26656@puariko.nirvana> <1204055175.9193.20.camel@rousalka.dyndns.org> <20080226211903.GA28078@puariko.nirvana> <1204063124.5684.43.camel@localhost.localdomain> Message-ID: <1204076617.3446.187.camel@beck.corsepiu.local> On Tue, 2008-02-26 at 16:58 -0500, Simo Sorce wrote: > On Tue, 2008-02-26 at 23:19 +0200, Axel Thimm wrote: > And yes, I understand that a package name that is written in pure > Cyrillic or Chinese, or Japanese maybe hard initially to swallow (and > type), Whether something is hard to type is a matter of the locale one is using. It's relative to one's cultural background. Have a look at the package currently under review: ?colier-courts-fonts How many people would be able to type this package's name to install it? Personal experience with my last name (contains an "?") tells me, the majority of people with a French, Portuguese or Spanish language background are able to do so. The majority of people outside of this group (Noteworthy: The naive ASCII-typing/English-speaking world) isn't. Similar considerations apply to any other arbitrary non-ASCII char. > but how many chances are that everybody suddenly will start doing > that? Devil's advocate question: Why should a 16 year old student in an arbitrary country not use his native language/charset for his package's name? That said, I would consider these chances to be increasing with the size of the non-English speaking Linux user-base, who are not aware about the historic and cultural issues of i18n. > If this is really a usability problem I am sure that the proposal to > provide an alternate ASCII only name (need rules to determine how you > get from non-ASCII to ASCII) is a very good one, even if copy&paste, or > other UIs can be used as well. In bugzilla, I had proposed the opposite: Mandate ASCII-only _package names_ (=> ASCII-only file names), but additionally allow alternative (utf-8) "Provides" if desired. This would allow GUI tools to display these utf-names, while it would help keep things simple for command-line tools. Ralf From j.w.r.degoede at hhs.nl Wed Feb 27 08:47:30 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 27 Feb 2008 09:47:30 +0100 Subject: [Fedora-packaging] are subpackages required for optional loadable libraries? In-Reply-To: <47C4D139.3020904@gmail.com> References: <47C4BB8A.9090907@redhat.com> <47C4D139.3020904@gmail.com> Message-ID: <47C523A2.8090002@hhs.nl> Toshio Kuratomi wrote: > So the questions I'd see us needing to address are: > > 1) What are the criteria to split a package into multiple subpackages as > opposed to keeping modules in a single/few subpackage. > I say that varies too much from package to package, I believe that in the end that is best left to the packager, I see no way we can sanely regulate this. So we shouldn't try to write rules / procedures for this. All we need is a procedure how to handle disputes between a bug-reporter and a packager, when they cannot agree on wether to split / not to split. As long as there is no such dispute I would like to see the FPC not looking into this. As for the toplevel poster, please name the package and describe the exact situation, trying to generalize this problem is not a good idea. > 2) When a subpackage is not split, should Requires be used to pull in > all of the dependencies or should they be used to pull in none of the > dependencies. > When using plugings, the .so files should have all there dependencies installed, if you don't want those deps in the main package, put the plugin in a subpackage However when a program is designed to have increased functionality by directly dlopening a library (as oposed to a plugin where the plugin is linked against the library), then you should probably not Require the library, but in cases where the program is pretty crippled without it you might add a Requires for the lib. This leads me to the conclusion we really need something like recommends, so that diskspace / bandwidth restricted people can install a light version, and "normal" users just get all functionality of a package. > 3) What is the default level of functionality that should work out of > the box? > Varies from package to package. Regards, Hans From pertusus at free.fr Wed Feb 27 09:24:24 2008 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 27 Feb 2008 10:24:24 +0100 Subject: [Fedora-packaging] UTF-8 package names In-Reply-To: <1204085101.10949.36.camel@tuxhugs> References: <47C459A9.7020609@gmail.com> <1204078090.8024.34.camel@tuxhugs> <47C4D068.8060809@gmail.com> <1204085101.10949.36.camel@tuxhugs> Message-ID: <20080227092424.GB2693@free.fr> On Tue, Feb 26, 2008 at 08:05:01PM -0800, Peter Gordon wrote: > > In some languages, though, the diacritic differentiates the character > from the "plain" form. For example, a Spanish package name for a similar > studying software could be "?Estudiar?!" (third-person indicative future > tense; literally, "You will study!"). However, we would need to be > careful here because, without that accent, this changes the conjugation > to "estudiara," which is the first- and third-person imperfect > subjunctive (which really makes no sense on its own, since the > subjunctive tense is meant to be used in a subjective or predictive > clause of a sentence, such as referring to one's wants and desires for > the future). If wikipedia is right in http://en.wikipedia.org/wiki/Transliteration what you are trying to do is not transliteration (in a narrow sense), but transcription. Transliterated word are not necessarily pronounced the same. There is an automatic mapping between characters only, irrespective of the correctness of the result in the original language (the character mapping is in general based on characters similitude or sounds in english when it comes to transliteration in ASCII 7 bit). I think that we should not permit non ASCII 7 bit letters in package names, but the transliteration or transcription scheme used should be left to the packager. We can have aids, still, for packagers who don't have an idea on how to transliterate an upstream name. For example in texi2html/texinfo we transliterate non ascii characters in file names. There are tables in texinfo for some characters, and I use Text::Unidecode to complete in texi2html. That way the file names are ascii 7 bit and are unlikely to be problematic in any platform (but the portability issue is more severe than in fedora, since we want these file names to be usable everywhere). This scheme seems to work for a lot of characters -- though maybe better schemes could be devised, if needed. But I don't think this would be needed, instead left to the packager. -- Pat From mtasaka at ioa.s.u-tokyo.ac.jp Wed Feb 27 13:24:04 2008 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Wed, 27 Feb 2008 22:24:04 +0900 Subject: [Fedora-packaging] handing files under $HOME directory on scriptlet Message-ID: <47C56474.4090800@ioa.s.u-tokyo.ac.jp> Hi. Now I am trying to review gnome-menu-extended. https://bugzilla.redhat.com/show_bug.cgi?id=426026 The main purpose of this package is to add KDE related submenus to GNOME panel menu. What I cannot judge for now is about the %postun scriptlet of the spec file: ------------------------------------------------------------- %postun rm -f /home/*/.local/share/applications/%{name}.desktop rm -f /root/.local/share/applications/%{name}.desktop -------------------------------------------------------------- Well, at least - if [ $1 = 0 ] ; then ..... ; fi is needed - This scriptlet cannot handle the case in which $HOME is not /home However the point is that this scriptlet is trying to handle (in this case delete) files under $HOME directory at %postun. Is this allowed? Regards, Mamoru From pertusus at free.fr Wed Feb 27 13:44:08 2008 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 27 Feb 2008 14:44:08 +0100 Subject: [SPAM] Re: [Fedora-packaging] handing files under $HOME directory on scriptlet In-Reply-To: <47C56474.4090800@ioa.s.u-tokyo.ac.jp> References: <47C56474.4090800@ioa.s.u-tokyo.ac.jp> Message-ID: <20080227134408.GB2709@free.fr> On Wed, Feb 27, 2008 at 10:24:04PM +0900, Mamoru Tasaka wrote: > Hi. > > However the point is that this scriptlet is trying to handle > (in this case delete) files under $HOME directory at %postun. > Is this allowed? In any case it shouldn't be allowed. A script can be done that makes the same and a documentation file could be done too. -- Pat From rdieter at math.unl.edu Wed Feb 27 13:53:14 2008 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 27 Feb 2008 07:53:14 -0600 Subject: [Fedora-packaging] handing files under $HOME directory on scriptlet In-Reply-To: <47C56474.4090800@ioa.s.u-tokyo.ac.jp> References: <47C56474.4090800@ioa.s.u-tokyo.ac.jp> Message-ID: <47C56B4A.4040706@math.unl.edu> Mamoru Tasaka wrote: > However the point is that this scriptlet is trying to handle > (in this case delete) files under $HOME directory at %postun. > Is this allowed? That's just plain broken, no. -- Rex From Axel.Thimm at ATrpms.net Wed Feb 27 15:52:07 2008 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 27 Feb 2008 17:52:07 +0200 Subject: [Fedora-packaging] Re: UTF-8 package names In-Reply-To: <1204063124.5684.43.camel@localhost.localdomain> References: <47C459A9.7020609@gmail.com> <20080226185513.GA26656@puariko.nirvana> <1204055175.9193.20.camel@rousalka.dyndns.org> <20080226211903.GA28078@puariko.nirvana> <1204063124.5684.43.camel@localhost.localdomain> Message-ID: <20080227155207.GA3223@puariko.nirvana> On Tue, Feb 26, 2008 at 04:58:44PM -0500, Simo Sorce wrote: > > On Tue, 2008-02-26 at 23:19 +0200, Axel Thimm wrote: > > Which is the problem. Since this is not any metadata you store > > anywhere it is something defined locally. And if you mirror the raw > > UTF8 filenames onto a mirror that has set local policy to be latin1 > > the web server will serve funny ~A names. > > So are you claiming that mirrors can't be fixed ? No, anything, but my car can be fixed, but are you willing to take on the task to support all admins current and future to properly migrate to utf8 whether it's a Fedora/RHEL/Debian/Solaris OS of arbitrary age running on the mirror? > I think that resistance against standardizing around utf8 is getting > ridiculous at this point. I understand that people that never used > anything but ASCII may find it annoying that there are people out there > that use funny characters, but I wonder when they will realize that they > are the minority in the world, and that the others would like to be > treated like first class citizens like everybody else. Actually most people against using UTF8 are such that got bitten by the encoding problems, e.g. living in a locale that actually uses non-ASCII characters. I have had to fix too many times encoding errors of say ?bersetzungen.tex and ?bersetzungen.tex to use the transiliterated Uebersetzungen.tex. > Unless there is a very compelling technical problem, I think we should > try as hard as possible to support and use by default utf8 everywhere. > The more we use it, the more we uncover bugs that we can hopefully fix. And what will happen if I can't even read the package's name like say an arabic version of libenese-fonts. Even if I can read libanese, if I haven'z installed the font, the package will display as many empty boxes to me to select from (among many other packages with empty boxes). You run into a catch22 situation here. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From a.badger at gmail.com Wed Feb 27 15:46:09 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 27 Feb 2008 07:46:09 -0800 Subject: [Fedora-packaging] are subpackages required for optional loadable libraries? In-Reply-To: <20080227031753.GE3306@ryvius.greysector.net> References: <47C4BB8A.9090907@redhat.com> <47C4D139.3020904@gmail.com> <20080227031753.GE3306@ryvius.greysector.net> Message-ID: <47C585C1.3080109@gmail.com> Dominik 'Rathann' Mierzejewski wrote: > On Wednesday, 27 February 2008 at 03:55, Toshio Kuratomi wrote: > [...] >> So the questions I'd see us needing to address are: >> >> 1) What are the criteria to split a package into multiple subpackages as >> opposed to keeping modules in a single/few subpackage. > > Plugins implementing the same functionality using different external libraries > (database engine support plugins are a typical example) must be packaged > separately. A developer testing if the software works equally well with all > supported DBEs will just have to install all of them by hand. We'll assume > he's competent enough to do it. > +1 > If the plugins do different things, it should be left for the packager to > decide. Meta-packages come handy here (and are my preferred solution). > Not sure here. When coupled with the answer to #2 I think we should have some guidance (packager gets final say but still some guidance) We want the packager to know that leaving multiple disparate plugins in a single package should have benefit to the end-user. If it doesn't help the end user to have a single package then they need to break it up. It can be a lot of work to package correctly but that is what the packager is agreeing to when they submit a package. >> 2) When a subpackage is not split, should Requires be used to pull in all >> of the dependencies or should they be used to pull in none of the >> dependencies. > > All, of course. Otherwise we end up with bugreports saying the plugins > don't work (because we intentionally crippled them). > +1 >> 3) What is the default level of functionality that should work out of the >> box? > > That should be left for the packager to decide. > I think we need guidance here as well. For instance, if a web application needs a database to work out of the box but that database could be any of mysql, postgres, or sqlite, do we require that one of those be installed? So... I don't see anything here that needs to go into the Guidelines but I do think there's some stuff that should be thought about and go on the wiki as recommendations of how to tell whether a subpackage needs to be made. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From Axel.Thimm at ATrpms.net Wed Feb 27 15:56:27 2008 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 27 Feb 2008 17:56:27 +0200 Subject: [Fedora-packaging] Re: UTF-8 package names In-Reply-To: <47C4BDED.20308@gmail.com> References: <47C459A9.7020609@gmail.com> <20080226184454.GA27399@nostromo.devel.redhat.com> <20080226184906.GA27928@nostromo.devel.redhat.com> <1204052042.13100.47.camel@cutter> <1204063768.3446.50.camel@beck.corsepiu.local> <20080227005634.GB3306@ryvius.greysector.net> <47C4BDED.20308@gmail.com> Message-ID: <20080227155627.GB3223@puariko.nirvana> On Tue, Feb 26, 2008 at 05:33:33PM -0800, Toshio Kuratomi wrote: > For a possible valid use, think of this potential pair of tools for > students learning Japanese: > /usr/bin/????2r?maji > /usr/bin/r?maji2???? If I were going to learn Japanese tomorrow and were looking for such a tool I wouldn't be actually able to even comprehend that these tools can help me. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Wed Feb 27 16:05:09 2008 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 27 Feb 2008 18:05:09 +0200 Subject: [Fedora-packaging] Re: UTF-8 package names In-Reply-To: <80d7e4090802262047u2b7448e7qd0b891f925bfc08b@mail.gmail.com> References: <47C459A9.7020609@gmail.com> <20080226184454.GA27399@nostromo.devel.redhat.com> <20080226184906.GA27928@nostromo.devel.redhat.com> <1204052042.13100.47.camel@cutter> <1204063768.3446.50.camel@beck.corsepiu.local> <1204084322.13100.68.camel@cutter> <80d7e4090802262047u2b7448e7qd0b891f925bfc08b@mail.gmail.com> Message-ID: <20080227160509.GC3223@puariko.nirvana> On Tue, Feb 26, 2008 at 09:47:39PM -0700, Stephen John Smoogen wrote: > On Tue, Feb 26, 2008 at 8:52 PM, seth vidal wrote: > > > > On Tue, 2008-02-26 at 23:09 +0100, Ralf Corsepius wrote: > > > > > > > > /me renames yum to ??? > > > Is this Farsi, Arab or Hebrew? > > > > It is 3 random chars pulled off of the gnome-character-map :) > > > > The area that I am going to look forward to is when a package has what > looks like an ascii character but turns out to be a different UTF > version of that letter. The example I remember from class was where > the word nonny-nonny had 6 different 'types' of n. Looking at it where > they all showed up as \uBLAH was easy but in a completely UTF > compliant screen you couldnt just type it. Not that Fedora has to deal > with support tickets.. 5+ years ago there was an example where this could be even used in a malicious way to spoof URLs like microsoft.com with non-ASCII characters. http://portal.acm.org/citation.cfm?id=503156 -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Wed Feb 27 16:10:42 2008 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 27 Feb 2008 18:10:42 +0200 Subject: [Fedora-packaging] Re: UTF-8 package names In-Reply-To: <47C4D068.8060809@gmail.com> References: <47C459A9.7020609@gmail.com> <1204078090.8024.34.camel@tuxhugs> <47C4D068.8060809@gmail.com> Message-ID: <20080227161042.GD3223@puariko.nirvana> On Tue, Feb 26, 2008 at 06:52:24PM -0800, Toshio Kuratomi wrote: > Package names should follow upstream since attempting to transliterate or > translate upstream names can't be done sanely on our side. For things that > map easily into the ASCii set (diacritic/accented characters, for instance, > as found in latin-1) a transliterated Provides can be added to make > installation easier for ASCii-conditioned users but carrying this on to > other scripts is a losing proposition. We violate this rule with capitalization, python/perl/php/.... packages and what not and we'll stick with an upstream's name that seems to want to ship its project only is certain locales? I would instead propose a rule that says "if the transliteration to ASCII can't be done by the packager, he should contact upstream to provide one and use that". -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From a.badger at gmail.com Wed Feb 27 16:33:22 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 27 Feb 2008 08:33:22 -0800 Subject: [Fedora-packaging] Re: UTF-8 package names In-Reply-To: <20080227155627.GB3223@puariko.nirvana> References: <47C459A9.7020609@gmail.com> <20080226184454.GA27399@nostromo.devel.redhat.com> <20080226184906.GA27928@nostromo.devel.redhat.com> <1204052042.13100.47.camel@cutter> <1204063768.3446.50.camel@beck.corsepiu.local> <20080227005634.GB3306@ryvius.greysector.net> <47C4BDED.20308@gmail.com> <20080227155627.GB3223@puariko.nirvana> Message-ID: <47C590D2.60802@gmail.com> Axel Thimm wrote: > On Tue, Feb 26, 2008 at 05:33:33PM -0800, Toshio Kuratomi wrote: >> For a possible valid use, think of this potential pair of tools for >> students learning Japanese: >> /usr/bin/????2r?maji >> /usr/bin/r?maji2???? > > If I were going to learn Japanese tomorrow and were looking for such a > tool I wouldn't be actually able to even comprehend that these tools > can help me. > Sure. But that can happen regardless of the language. If I were trying to avoid getting computer viruses how would I know that replacing Windows with a *nix variant is an option? How do I know that I can browse the web with "Firefox"? You need to know something about the problem space before you can search for a tool to help you. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From nicolas.mailhot at laposte.net Wed Feb 27 17:00:46 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 27 Feb 2008 18:00:46 +0100 (CET) Subject: [Fedora-packaging] Re: UTF-8 package names In-Reply-To: <20080227161042.GD3223@puariko.nirvana> References: <47C459A9.7020609@gmail.com> <1204078090.8024.34.camel@tuxhugs> <47C4D068.8060809@gmail.com> <20080227161042.GD3223@puariko.nirvana> Message-ID: <40500.192.54.193.59.1204131646.squirrel@rousalka.dyndns.org> Le Mer 27 f?vrier 2008 17:10, Axel Thimm a ?crit : > We violate this rule with capitalization, > python/perl/php/.... packages and what not and we'll stick with an > upstream's name that seems to want to ship its project only is certain > locales? > > I would instead propose a rule that says "if the transliteration to > ASCII can't be done by the packager, he should contact upstream to > provide one and use that". Nevertheless even if a transliteration can be found (and I agree with you asking upstream is best as transliteration rules vary from country to country and some like China even had different transliteration styles at different points of time) that's no reason to restrict the main package name (that is displayed in packagekit and various tools) to this transliteration. Most of us can understand SMS-speak. SMS-speak has various properties that make it easier to type in some conditions. Would we like someone to change our name to its SMS variant to make it easier on SMS users? I guess not. Transliteration should be strictly limited to a failover for users that for some reason use the CLI and can not type the upstream name of a package they need. Capitalization is something else entirely. Capitalization is common editorial work that makes a whole more pleasant by applying the same conventions everywhere. It's a neutral transformation. Transliteration to ASCII OTOH is a very violent transform, and probably offensive to an upstream that chose an non-ASCII name. And as Simo I don't buy the argument that since it's broken, it must not be fixed. -- Nicolas Mailhot From tibbs at math.uh.edu Wed Feb 27 17:12:37 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 27 Feb 2008 11:12:37 -0600 Subject: [Fedora-packaging] are subpackages required for optional loadable libraries? In-Reply-To: <47C585C1.3080109@gmail.com> References: <47C4BB8A.9090907@redhat.com> <47C4D139.3020904@gmail.com> <20080227031753.GE3306@ryvius.greysector.net> <47C585C1.3080109@gmail.com> Message-ID: >>>>> "TK" == Toshio Kuratomi writes: TK> I think we need guidance here as well. For instance, if a web TK> application needs a database to work out of the box but that TK> database could be any of mysql, postgres, or sqlite, do we require TK> that one of those be installed? Actually, no. Don't forget that the first two of those don't need to actually be on the machine running the application. Client libraries are another issue, but they should end up being much smaller. And these days we should be thinking of sqlite as a default system component. - J< From tibbs at math.uh.edu Wed Feb 27 17:17:44 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 27 Feb 2008 11:17:44 -0600 Subject: [Fedora-packaging] handing files under $HOME directory on scriptlet In-Reply-To: <47C56474.4090800@ioa.s.u-tokyo.ac.jp> References: <47C56474.4090800@ioa.s.u-tokyo.ac.jp> Message-ID: >>>>> "MT" == Mamoru Tasaka writes: MT> rm -f /home/*/.local/share/applications/%{name}.desktop Absolutely, positively broken. Aside for all of the obvious stuff, consider that it doesn't even do what you expect on a bunch of systems: > ls /home tibbs/ > df ~dave Filesystem 1K-blocks Used Available Use% Mounted on nas07:/export/h-dave/dave 41284928 27274880 13970048 67% /home/dave > ls /home dave/ tibbs/ > df /home Filesystem 1K-blocks Used Available Use% Mounted on - 0 0 0 - /home Hooray for autofs. (Yeah, I could make the mountpoint browseable, but there's really no need to do so and I don't really like mount storms.) /home is mine; packages cannot ever safely touch anything there. - J< From a.badger at gmail.com Wed Feb 27 18:23:08 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 27 Feb 2008 10:23:08 -0800 Subject: [Fedora-packaging] are subpackages required for optional loadable libraries? In-Reply-To: References: <47C4BB8A.9090907@redhat.com> <47C4D139.3020904@gmail.com> <20080227031753.GE3306@ryvius.greysector.net> <47C585C1.3080109@gmail.com> Message-ID: <47C5AA8C.5010001@gmail.com> Jason L Tibbitts III wrote: >>>>>> "TK" == Toshio Kuratomi writes: > > TK> I think we need guidance here as well. For instance, if a web > TK> application needs a database to work out of the box but that > TK> database could be any of mysql, postgres, or sqlite, do we require > TK> that one of those be installed? > > Actually, no. Don't forget that the first two of those don't need to > actually be on the machine running the application. > > Client libraries are another issue, but they should end up being much > smaller. And these days we should be thinking of sqlite as a default > system component. > True. So, would the general best practice be: 1) should work out of the box. 2) When several alternative but non-optional components exist for that, the packager should pick one to depend on. 2a) The packager's decision of default can use many criteria for preference including whether the dependency is a system component (something that would be installed on most systems anyway), size, or promoted by upstream when making this decision. Just be sure to put some thought into it. The bugzilla package is an example of this. As is python-SQLAlchemy. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From tcallawa at redhat.com Wed Feb 27 18:43:36 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 27 Feb 2008 13:43:36 -0500 Subject: [Fedora-packaging] handing files under $HOME directory on scriptlet In-Reply-To: References: <47C56474.4090800@ioa.s.u-tokyo.ac.jp> Message-ID: <1204137816.3364.34.camel@dhcp83-61.boston.redhat.com> On Wed, 2008-02-27 at 11:17 -0600, Jason L Tibbitts III wrote: > /home is mine; packages cannot ever safely touch anything there. This seems like a succinct point to add to the Guidelines. ~spot From j.w.r.degoede at hhs.nl Wed Feb 27 18:46:52 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 27 Feb 2008 19:46:52 +0100 Subject: [Fedora-packaging] handing files under $HOME directory on scriptlet In-Reply-To: <1204137816.3364.34.camel@dhcp83-61.boston.redhat.com> References: <47C56474.4090800@ioa.s.u-tokyo.ac.jp> <1204137816.3364.34.camel@dhcp83-61.boston.redhat.com> Message-ID: <47C5B01C.10407@hhs.nl> Tom "spot" Callaway wrote: > On Wed, 2008-02-27 at 11:17 -0600, Jason L Tibbitts III wrote: >> /home is mine; packages cannot ever safely touch anything there. > > This seems like a succinct point to add to the Guidelines. > +1 Regards, Hans From tibbs at math.uh.edu Wed Feb 27 18:49:20 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 27 Feb 2008 12:49:20 -0600 Subject: [Fedora-packaging] are subpackages required for optional loadable libraries? In-Reply-To: <47C5AA8C.5010001@gmail.com> References: <47C4BB8A.9090907@redhat.com> <47C4D139.3020904@gmail.com> <20080227031753.GE3306@ryvius.greysector.net> <47C585C1.3080109@gmail.com> <47C5AA8C.5010001@gmail.com> Message-ID: >>>>> "TK" == Toshio Kuratomi writes: TK> So, would the general best practice be: TK> should work out of the box. Well, don't forget that it's a general rule that these database-driven applications don't work out of the box. You always have to configure it to talk to your database and it's not abnormal for you to have to run some provided SQL to create the database and set up the schemas. Maybe we could achieve betterness by storing that kind of configuration information somewhere, but it still doesn't solve the dependency problem unless. So honestly I don't have a big problem saying that some assembly is required. On the other hand, mysql-libs is 3.6M (and it's not really possible to trim that down by much unless you split out the translations). The postgres client libs are roughly the same size as sqlite (about 500K). If we can decide that we don't care about 4.5M of dependencies then I guess things would be easier. - J< From a.badger at gmail.com Wed Feb 27 19:04:31 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 27 Feb 2008 11:04:31 -0800 Subject: [Fedora-packaging] Re: UTF-8 package names In-Reply-To: <20080227161042.GD3223@puariko.nirvana> References: <47C459A9.7020609@gmail.com> <1204078090.8024.34.camel@tuxhugs> <47C4D068.8060809@gmail.com> <20080227161042.GD3223@puariko.nirvana> Message-ID: <47C5B43F.4050004@gmail.com> Axel Thimm wrote: > On Tue, Feb 26, 2008 at 06:52:24PM -0800, Toshio Kuratomi wrote: >> Package names should follow upstream since attempting to transliterate or >> translate upstream names can't be done sanely on our side. For things that >> map easily into the ASCii set (diacritic/accented characters, for instance, >> as found in latin-1) a transliterated Provides can be added to make >> installation easier for ASCii-conditioned users but carrying this on to >> other scripts is a losing proposition. > > We violate this rule with capitalization, > python/perl/php/.... packages and what not and we'll stick with an > upstream's name that seems to want to ship its project only is certain > locales? > You raise some good points. Why do we change upstream WRT capitalization? Probably usability. What will we do if capitalization matters? (ie: foobar and FooBar are separate projects) Not approve a package that has a conflicting name and try to get either or both projects to rename upstream. If the packages weren't changed upstream (because, says upstream, FooBar and foobar are plainly different names) what would we do? This is an unknown that seems very relevant here. OTOH, there is a single straightforward, non-controversial mapping from uppercase ASCii to lowercase ASCii. Transliteration and transcription from other scripts is not so blessed. So the rationale for wanting to ban Unicode could be the same as wanting to ban capitalization but the ramifications are very different. Changing module names is interesting. Speaking for python we do two things: 1) We use "import foo" to determine what the package's upstream name is rather than the name of the tarball. I don't consider this changing the name as there are several equally valid ways to determine what the upstream name is so we've just standardized on one. 2) We prepend "python-" to the name in most cases. This is partially categorization and partially a namespacing issue. Categorization is changing the name to make it easier for users to recognize the purpose of a package. python-turboflot doesn't need the "python-" for anything other than making *people* aware that turboflot is a python module. Namespacing is a valid issue, though. python-json != php-json != perl-json even if they all use the equivalent of "import json" and distributed their binaries in tarballs called json-1.0.tar.gz. I think justifying banning unicode with the module namespace as a precedent is illogical. If anything, converting unicode characters in a user's chosen script to a ASCii-ization is removing a means of categorizing the package by sight. It will also lead to more namespace collisions rather than less. > I would instead propose a rule that says "if the transliteration to > ASCII can't be done by the packager, he should contact upstream to > provide one and use that". > If you said that upstream should always be in charge of transliterating I think this rule would be better. To use an example that people might know from non-computer life what if upstream named their package ??? One distribution might feel perfectly confident transliterating that as beijing while another one uses peking. Having upstream manage transliteration pushes the decision to the correct level to coordinate and avoid confusion. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From Axel.Thimm at ATrpms.net Wed Feb 27 21:34:26 2008 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 27 Feb 2008 23:34:26 +0200 Subject: [Fedora-packaging] Re: UTF-8 package names In-Reply-To: <47C5B43F.4050004@gmail.com> References: <47C459A9.7020609@gmail.com> <1204078090.8024.34.camel@tuxhugs> <47C4D068.8060809@gmail.com> <20080227161042.GD3223@puariko.nirvana> <47C5B43F.4050004@gmail.com> Message-ID: <20080227213426.GA9108@puariko.nirvana> On Wed, Feb 27, 2008 at 11:04:31AM -0800, Toshio Kuratomi wrote: >> I would instead propose a rule that says "if the transliteration to >> ASCII can't be done by the packager, he should contact upstream to >> provide one and use that". >> > If you said that upstream should always be in charge of transliterating I > think this rule would be better. I just want to cover the case where upstream doesn't care and doesn't reply to a packager's question on how to name the package. "Always in charge" would mean that if there is no feedback there is no name. > To use an example that people might know from non-computer life what > if upstream named their package ??? One distribution might feel > perfectly confident transliterating that as beijing while another > one uses peking. Having upstream manage transliteration pushes the > decision to the correct level to coordinate and avoid confusion. "Ask upstream and if it doesn't respond take the best guess of the packager"? -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rjones at redhat.com Thu Feb 28 19:55:40 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Thu, 28 Feb 2008 19:55:40 +0000 Subject: [Fedora-packaging] Perl package guidelines and filtering provides/requires Message-ID: <20080228195540.GA30331@amd.home.annexia.org> The Perl packaging guidelines are big on the need to filter provides and requires using some complex shell scripting: http://fedoraproject.org/wiki/Packaging/Perl I'm reviewing some Perl packages which don't do this. Furthermore I grabbed 10 approved Perl specfiles from CVS and only 2 of them (perl-Catalyst-Plugin-Static-Simple and perl-Class-MOP) actually did it. So is this packaging requirement real? Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.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 tcallawa at redhat.com Thu Feb 28 19:59:46 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Thu, 28 Feb 2008 14:59:46 -0500 Subject: [Fedora-packaging] Perl package guidelines and filtering provides/requires In-Reply-To: <20080228195540.GA30331@amd.home.annexia.org> References: <20080228195540.GA30331@amd.home.annexia.org> Message-ID: <1204228786.3140.24.camel@localhost.localdomain> On Thu, 2008-02-28 at 19:55 +0000, Richard W.M. Jones wrote: > The Perl packaging guidelines are big on the need to filter provides > and requires using some complex shell scripting: > > http://fedoraproject.org/wiki/Packaging/Perl > > I'm reviewing some Perl packages which don't do this. Furthermore I > grabbed 10 approved Perl specfiles from CVS and only 2 of them > (perl-Catalyst-Plugin-Static-Simple and perl-Class-MOP) actually did > it. > > So is this packaging requirement real? It is real if the perl package you're working on picks up some false Provides and/or Requires. :) ~spot From rjones at redhat.com Thu Feb 28 20:09:53 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Thu, 28 Feb 2008 20:09:53 +0000 Subject: [Fedora-packaging] Perl package guidelines and filtering provides/requires In-Reply-To: <1204228786.3140.24.camel@localhost.localdomain> References: <20080228195540.GA30331@amd.home.annexia.org> <1204228786.3140.24.camel@localhost.localdomain> Message-ID: <20080228200953.GA30434@amd.home.annexia.org> On Thu, Feb 28, 2008 at 02:59:46PM -0500, Tom spot Callaway wrote: > On Thu, 2008-02-28 at 19:55 +0000, Richard W.M. Jones wrote: > > The Perl packaging guidelines are big on the need to filter provides > > and requires using some complex shell scripting: > > > > http://fedoraproject.org/wiki/Packaging/Perl > > > > I'm reviewing some Perl packages which don't do this. Furthermore I > > grabbed 10 approved Perl specfiles from CVS and only 2 of them > > (perl-Catalyst-Plugin-Static-Simple and perl-Class-MOP) actually did > > it. > > > > So is this packaging requirement real? > > It is real if the perl package you're working on picks up some false > Provides and/or Requires. :) The text on that page is a bit unclear then. I read it initially to mean that I always had to do the filtering, not that I had to only do it if the deps were wrong. Reading it again it seems ambiguous. Anyway, here are the deps for the packages I'm looking at. What sort of wrong deps am I looking for? (FWIW these deps seem OK to me). $ rpm -q --requires -p perl-Dir-Which-0.3-1.fc9.noarch.rpm perl >= 0:5.006 perl(:MODULE_COMPAT_5.8.8) perl(Carp) perl(File::Spec) perl(base) perl(strict) perl(vars) perl(warnings) rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(VersionedDependencies) <= 3.0.3-1 $ rpm -q --provides -p perl-Dir-Which-0.3-1.fc9.noarch.rpm perl(Dir::Which) = 0.3 perl-Dir-Which = 0.3-1.fc9 $ rpm -q --requires -p perl-File-Tempdir-0.02-7.fc9.noarch.rpm perl(:MODULE_COMPAT_5.8.8) perl(File::Path) perl(File::Temp) perl(strict) perl(warnings) rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(VersionedDependencies) <= 3.0.3-1 $ rpm -q --provides -p perl-File-Tempdir-0.02-7.fc9.noarch.rpm perl(File::Tempdir) = 0.02 perl-File-Tempdir = 0.02-7.fc9 Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.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 tcallawa at redhat.com Thu Feb 28 20:17:50 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Thu, 28 Feb 2008 15:17:50 -0500 Subject: [Fedora-packaging] Perl package guidelines and filtering provides/requires In-Reply-To: <20080228200953.GA30434@amd.home.annexia.org> References: <20080228195540.GA30331@amd.home.annexia.org> <1204228786.3140.24.camel@localhost.localdomain> <20080228200953.GA30434@amd.home.annexia.org> Message-ID: <1204229870.3140.27.camel@localhost.localdomain> On Thu, 2008-02-28 at 20:09 +0000, Richard W.M. Jones wrote: > Anyway, here are the deps for the packages I'm looking at. What sort > of wrong deps am I looking for? (FWIW these deps seem OK to me). All of those are fine. The scripts are really for the case when the rpm perl dependency scripts generate things like: Requires: perl(thisisnotarealmodule) Provides: perl(ExtUtils::MakeMaker) (and your package is perl-SuperWidget, not perl-ExtUtils-MakeMaker) ~spot From orion at cora.nwra.com Fri Feb 29 21:48:38 2008 From: orion at cora.nwra.com (Orion Poplawski) Date: Fri, 29 Feb 2008 14:48:38 -0700 Subject: [Fedora-packaging] %bits macro? Message-ID: <47C87DB6.5090006@cora.nwra.com> It might me useful to have a %bits macro automatically set to 32 or 64 as appropriate. Does this seem useful or is there a better way? I'm try to follow the following tip from http://fedoraproject.org/wiki/PackagingDrafts/MultilibTricks: #if __WORDSIZE == 32 #include "myautoconfig-32.h" #elif __WORDSIZE == 64 #include "myautoconfig-64.h" #else #error "Unknown word size" #endif So in my spec I want to move "myautoconfig.h" to "myautoconfig-32.h" (or 64) as appropriate. Would be nice to do: mv myautoconfig.h myautoconfig-%{bits}.h Thoughts? -- 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 tcallawa at redhat.com Fri Feb 29 21:50:50 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Fri, 29 Feb 2008 16:50:50 -0500 Subject: [Fedora-packaging] %bits macro? In-Reply-To: <47C87DB6.5090006@cora.nwra.com> References: <47C87DB6.5090006@cora.nwra.com> Message-ID: <1204321850.4065.22.camel@localhost.localdomain> On Fri, 2008-02-29 at 14:48 -0700, Orion Poplawski wrote: > It might me useful to have a %bits macro automatically set to 32 or 64 > as appropriate. Does this seem useful or is there a better way? I'm not aware of a better way, this would be quite useful IMHO. ~spot From rc040203 at freenet.de Fri Feb 29 22:02:40 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 29 Feb 2008 23:02:40 +0100 Subject: [Fedora-packaging] %bits macro? In-Reply-To: <1204321850.4065.22.camel@localhost.localdomain> References: <47C87DB6.5090006@cora.nwra.com> <1204321850.4065.22.camel@localhost.localdomain> Message-ID: <1204322560.3446.396.camel@beck.corsepiu.local> On Fri, 2008-02-29 at 16:50 -0500, Tom "spot" Callaway wrote: > On Fri, 2008-02-29 at 14:48 -0700, Orion Poplawski wrote: > > It might me useful to have a %bits macro automatically set to 32 or 64 > > as appropriate. Does this seem useful or is there a better way? > > I'm not aware of a better way, this would be quite useful IMHO. A better way would be to rewrite any code requiring such tricks to not require them. In modern C/C++ there hardly is any need for such band-aids (cf. stdint.h, inttypes.h, limits.h) Ralf From skvidal at fedoraproject.org Fri Feb 29 22:14:34 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Fri, 29 Feb 2008 17:14:34 -0500 Subject: [Fedora-packaging] %bits macro? In-Reply-To: <1204322560.3446.396.camel@beck.corsepiu.local> References: <47C87DB6.5090006@cora.nwra.com> <1204321850.4065.22.camel@localhost.localdomain> <1204322560.3446.396.camel@beck.corsepiu.local> Message-ID: <1204323274.8099.110.camel@cutter> On Fri, 2008-02-29 at 23:02 +0100, Ralf Corsepius wrote: > On Fri, 2008-02-29 at 16:50 -0500, Tom "spot" Callaway wrote: > > On Fri, 2008-02-29 at 14:48 -0700, Orion Poplawski wrote: > > > It might me useful to have a %bits macro automatically set to 32 or 64 > > > as appropriate. Does this seem useful or is there a better way? > > > > I'm not aware of a better way, this would be quite useful IMHO. > > A better way would be to rewrite any code requiring such tricks to not > require them. > > In modern C/C++ there hardly is any need for such band-aids (cf. > stdint.h, inttypes.h, limits.h) But this would be handy if we can use it during the build. We could do little tricks like: Requires: foo.%bits Provides: foo.%bits and it would let us get rid of multilib file-requires like: /usr/lib[64]/libgcj.so.9 -sv From pertusus at free.fr Fri Feb 29 22:50:05 2008 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 29 Feb 2008 23:50:05 +0100 Subject: [Fedora-packaging] %bits macro? In-Reply-To: <47C87DB6.5090006@cora.nwra.com> References: <47C87DB6.5090006@cora.nwra.com> Message-ID: <20080229225005.GH2845@free.fr> On Fri, Feb 29, 2008 at 02:48:38PM -0700, Orion Poplawski wrote: > It might me useful to have a %bits macro automatically set to 32 or 64 as > appropriate. Does this seem useful or is there a better way? > > I'm try to follow the following tip from > http://fedoraproject.org/wiki/PackagingDrafts/MultilibTricks: > > #if __WORDSIZE == 32 > #include "myautoconfig-32.h" > #elif __WORDSIZE == 64 > #include "myautoconfig-64.h" > #else > #error "Unknown word size" > #endif > > So in my spec I want to move "myautoconfig.h" to "myautoconfig-32.h" (or > 64) as appropriate. Would be nice to do: > > mv myautoconfig.h myautoconfig-%{bits}.h > > Thoughts? You can use %_arch instead. -- Pat