From rc040203 at freenet.de Tue Oct 2 15:01:10 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 02 Oct 2007 17:01:10 +0200 Subject: [Fedora-packaging] missing today's meeting Message-ID: <1191337270.3395.131.camel@mccallum.corsepiu.local> Hi, today's meeting collides with other personal obligations, which will cause me not to be able to attend today's FPC meeting. Ralf From dan at danny.cz Tue Oct 2 19:01:11 2007 From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=) Date: Tue, 02 Oct 2007 21:01:11 +0200 Subject: [Fedora-packaging] packaging of Atari emulators Message-ID: <1191351671.4280.43.camel@eagle.danny.cz> Hello, I have prepared packages for atari800 (emulator of 8-bit Atari machines) and ARAnyM (emulator of m68k based Ataris). As there doesn't exist any free OS ROM for atari800, it is clear "no go" into Fedora. I will try to submit it into Rpmfusion. But another situation exists for ARAnyM. There is a package called AFROS, which contains a fully running ROM image and OS distribution all based on GPLed software packages. So I think it is possible to include both ARAnyM and AFROS (in binary directly usable form) in Fedora. I would compare AFROS with a free data files for games. What are your opinions? Thanks Dan From orion at cora.nwra.com Wed Oct 3 16:59:27 2007 From: orion at cora.nwra.com (Orion Poplawski) Date: Wed, 03 Oct 2007 10:59:27 -0600 Subject: [Fedora-packaging] Octave package standard In-Reply-To: <46FD46FD.70201@cora.nwra.com> References: <46F96B79.1010902@cora.nwra.com> <46FD4456.1060704@gmail.com> <46FD46FD.70201@cora.nwra.com> Message-ID: <4703CA6F.4050407@cora.nwra.com> Orion Poplawski wrote: > Toshio Kuratomi wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Orion Poplawski wrote: >>> >>> - Currently octave uses the /usr/libexec tree to install the .oct files. >>> These are really shared libraries. It does use an arch/api versioned >>> directory, e.g.: >>> >>> /usr/libexec/octave/packages/java-1.2.1/i386-redhat-linux-gnu-api-v26/ >>> >>> Some other package files (PKG_ADD/PKG_DEL) get added there too. >>> >> This is the only part that needs more clarification to me. If the .oct >> files are really shared libraries it seems that they belong in >> %{_libdir}. libexec is more useful for binaries that shouldn't be >> multilib like helper programs that are invoked by other programs on the >> system and need to match arch with the invoking program for them to work >> correctly. > > Well, it would be trivial to change /usr/libexec to /usr/lib. Multi-lib > is then handled by the arch string farther down. Similar to java in > /usr/lib/jvm/java/jre/lib/amd64/. Using %{_libdir} would be harder and > I'm not sure for what gain. These are all dlopen libraries only for > octave so as long as it knows where to go, that's okay. > > I also just updated the noarch spec to install from the source tarball > directly. The package install script simply unpacks that tarball into > the temp directory then. This assumes that nothing in the source needs > patching. > Any final thoughts on this? I'd like to get this decided before a final release of octave 3.0 is made (soon now). Personally, I'd like to leave it as libexec since we may need to put some arch dependent executables there too. -- 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 Wed Oct 3 17:30:28 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 03 Oct 2007 12:30:28 -0500 Subject: [Fedora-packaging] Octave package standard In-Reply-To: <46FD46FD.70201@cora.nwra.com> References: <46F96B79.1010902@cora.nwra.com> <46FD4456.1060704@gmail.com> <46FD46FD.70201@cora.nwra.com> Message-ID: <4703D1B4.30100@math.unl.edu> Orion Poplawski wrote: > Toshio Kuratomi wrote: >> Orion Poplawski wrote: >>> >>> - Currently octave uses the /usr/libexec tree to install the .oct files. >>> These are really shared libraries. It does use an arch/api versioned >>> directory, e.g.: >>> >>> /usr/libexec/octave/packages/java-1.2.1/i386-redhat-linux-gnu-api-v26/ >>> >>> Some other package files (PKG_ADD/PKG_DEL) get added there too. >>> >> This is the only part that needs more clarification to me. If the .oct >> files are really shared libraries it seems that they belong in >> %{_libdir}. libexec is more useful for binaries that shouldn't be >> multilib like helper programs that are invoked by other programs on the >> system and need to match arch with the invoking program for them to work >> correctly. > > Well, it would be trivial to change /usr/libexec to /usr/lib. Multi-lib > is then handled by the arch string farther down. Similar to java in > /usr/lib/jvm/java/jre/lib/amd64/. I'm ok with it either way. > Using %{_libdir} would be harder and > I'm not sure for what gain. *nod*, changing your proposal to try to use %{_libdir} may well be much pain for little payoff, so I personally wouldn't consider it a blocker. -- Rex From skasal at redhat.com Tue Oct 9 15:16:52 2007 From: skasal at redhat.com (Stepan Kasal) Date: Tue, 9 Oct 2007 17:16:52 +0200 Subject: [Fedora-packaging] rpmlint: W: strange-permission foo.init 0755 Message-ID: <20071009151652.GA24604@camelia.ucw.cz> Hello, many packages contain executable scripts (shell, perl, etc.) In most cases, these scripts have +x set in the fedora CVS. (After a quick inspection, I see that all *.init scripts in the fedora packages which I happen to have checked out have +x set.) Please note as long as we use CVS for Fedora and the cvs://... URLs in koji, we are not able to change flags of an existing file without a rename or a server side hack. (A limitation of CVS.) I reported the problem upstream, but I was told that this feature is configurable. Could you please change the configuration for Fedora rpmlint? Thanks, Stepan Kasal From ville.skytta at iki.fi Tue Oct 9 16:02:22 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Tue, 9 Oct 2007 19:02:22 +0300 Subject: [Fedora-packaging] rpmlint: W: strange-permission foo.init 0755 In-Reply-To: <20071009151652.GA24604@camelia.ucw.cz> References: <20071009151652.GA24604@camelia.ucw.cz> Message-ID: <200710091902.23102.ville.skytta@iki.fi> On Tuesday 09 October 2007, Stepan Kasal wrote: > Hello, > many packages contain executable scripts (shell, perl, etc.) > In most cases, these scripts have +x set in the fedora CVS. > (After a quick inspection, I see that all *.init scripts in the > fedora packages which I happen to have checked out have +x set.) >From a pedantic POV: I don't see the point of init scripts being executable inside the SRPM or when unpacked from it. And many other scripts in SRPMs need to be run in a very controlled environment/with specific parameters that are easily settable only from within a build anyway, so removing the executable bits (and invoking them with a specified interpreter from the specfile) kind of communicates the intent that they shouldn't be run outside of the package build and thus there's no need for them to be executable. > Please note as long as we use CVS for Fedora and the cvs://... URLs > in koji, we are not able to change flags of an existing file without > a rename or a server side hack. (A limitation of CVS.) Yep, that's an unfortunate one. > I reported the problem upstream, but I was told that this feature is > configurable. Right, by me :) > Could you please change the configuration for Fedora rpmlint? If the consensus is that eg. 0755 and 0775 should be accepted, will change the defaults. Personally, no strong opinions, but mildly against it. Note that people who dislike the current default config can already override it in their ~/.rpmlintrc or /etc/rpmlint/config: setOption("ValidSrcPerms", (0664, 0644, 0775, 0755, )) From pertusus at free.fr Sat Oct 20 22:24:43 2007 From: pertusus at free.fr (Patrice Dumas) Date: Sun, 21 Oct 2007 00:24:43 +0200 Subject: [Fedora-packaging] fortran .mod files Message-ID: <20071020222443.GA23353@free.fr> Hello, Currently there is no guideline regarding fortran 90 .mod, it seems to me that one is needed. These files are generated by gfortran when building a module. These are text files, but not intended to be read by humans. They are architecture dependent. When compiling some code that uses the module, the .mod has to be found in the include path (for example in a directory specified by -I). Where should the .mod be installed? I propose %_libdir %_libdir/include %_libdir/modules %_libdir/mod %_libdir/f90 %_includedir/%_lib %_includedir/%_lib/modules %_includedir/%_lib/mod %_includedir/%_lib/f90 (f90 may also be replaced by another meaningfull subdirectory name). This directory could be called %_fmoddir And add -I%_fmoddir in FFLAGS when compiling some code that requires the module. The optimal situation would be to have %_fmoddir defined in rpm macros and -I%_fmoddir added to default FFLAGS. So my first question is what is your advice about fortran modules directories? My second is, in case it is meaningful, what about my proposal regarding rpm macros? -- Pat From mmahut at fedoraproject.org Sat Oct 20 22:43:00 2007 From: mmahut at fedoraproject.org (Marek Mahut) Date: Sun, 21 Oct 2007 00:43:00 +0200 Subject: [Fedora-packaging] fortran .mod files In-Reply-To: <20071020222443.GA23353@free.fr> References: <20071020222443.GA23353@free.fr> Message-ID: <471A8474.2080306@fedoraproject.org> Hello Patrice, This list is being to be deprecated, please ask on fedora-devel-list at redhat.com. Patrice Dumas wrote: > Hello, > > Currently there is no guideline regarding fortran 90 .mod, it seems to > me that one is needed. These files are generated by gfortran when > building a module. These are text files, but not intended to be read by > humans. They are architecture dependent. When compiling some code that > uses the module, the .mod has to be found in the include path (for > example in a directory specified by -I). > > Where should the .mod be installed? I propose > > %_libdir > %_libdir/include > %_libdir/modules > %_libdir/mod > %_libdir/f90 > %_includedir/%_lib > %_includedir/%_lib/modules > %_includedir/%_lib/mod > %_includedir/%_lib/f90 > > (f90 may also be replaced by another meaningfull subdirectory name). > > This directory could be called %_fmoddir > > And add -I%_fmoddir in FFLAGS when compiling some code that > requires the module. > > > The optimal situation would be to have %_fmoddir defined in rpm macros > and -I%_fmoddir added to default FFLAGS. > > > So my first question is what is your advice about fortran modules > directories? > > My second is, in case it is meaningful, what about my proposal regarding > rpm macros? > > -- > Pat > > -- > Fedora-packaging mailing list > Fedora-packaging at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-packaging -- Marek Mahut http://www.fedoraproject.org/ Fedora Project http://www.jamendo.com/ From pertusus at free.fr Sat Oct 20 22:50:49 2007 From: pertusus at free.fr (Patrice Dumas) Date: Sun, 21 Oct 2007 00:50:49 +0200 Subject: [Fedora-packaging] fortran .mod files In-Reply-To: <471A8474.2080306@fedoraproject.org> References: <20071020222443.GA23353@free.fr> <471A8474.2080306@fedoraproject.org> Message-ID: <20071020225049.GB23353@free.fr> On Sun, Oct 21, 2007 at 12:43:00AM +0200, Marek Mahut wrote: > Hello Patrice, > > This list is being to be deprecated, please ask on > fedora-devel-list at redhat.com. I already did (not exactly the same, but similar). No response. -- Pat From tibbs at math.uh.edu Sat Oct 20 23:02:55 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 20 Oct 2007 18:02:55 -0500 Subject: [Fedora-packaging] fortran .mod files In-Reply-To: <471A8474.2080306@fedoraproject.org> References: <20071020222443.GA23353@free.fr> <471A8474.2080306@fedoraproject.org> Message-ID: >>>>> "MM" == Marek Mahut writes: MM> This list is being to be deprecated, please ask on MM> fedora-devel-list at redhat.com. Why do you think that? Deprecation of this list was proposed and rejected: http://fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20070913 fedora-test-list & fedora-packaging-list * FESCo decided to keep both lists for now. - J< From mmahut at fedoraproject.org Sun Oct 21 07:07:54 2007 From: mmahut at fedoraproject.org (Marek Mahut) Date: Sun, 21 Oct 2007 09:07:54 +0200 Subject: [Fedora-packaging] fortran .mod files In-Reply-To: References: <20071020222443.GA23353@free.fr> <471A8474.2080306@fedoraproject.org> Message-ID: <471AFACA.8000002@fedoraproject.org> Jason L Tibbitts III wrote: >>>>>> "MM" == Marek Mahut writes: > > MM> This list is being to be deprecated, please ask on > MM> fedora-devel-list at redhat.com. > > Why do you think that? I saw a mail about this in this or -devel mailing list, but I can't it now. (our mailing lists does not support search, argh.) If I'm wrong, please apologize. > Deprecation of this list was proposed and > rejected: > > http://fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20070913 > > fedora-test-list & fedora-packaging-list > > * FESCo decided to keep both lists for now. > > - J< > > -- > Fedora-packaging mailing list > Fedora-packaging at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-packaging -- Marek Mahut http://www.fedoraproject.org/ Fedora Project http://www.jamendo.com/ From tcallawa at redhat.com Sun Oct 21 14:18:42 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Sun, 21 Oct 2007 10:18:42 -0400 Subject: [Fedora-packaging] fortran .mod files In-Reply-To: <20071020222443.GA23353@free.fr> References: <20071020222443.GA23353@free.fr> Message-ID: <1192976322.22958.4.camel@localhost.localdomain> On Sun, 2007-10-21 at 00:24 +0200, Patrice Dumas wrote: > Hello, > > Currently there is no guideline regarding fortran 90 .mod, it seems to > me that one is needed. These files are generated by gfortran when > building a module. These are text files, but not intended to be read by > humans. They are architecture dependent. When compiling some code that > uses the module, the .mod has to be found in the include path (for > example in a directory specified by -I). > > Where should the .mod be installed? I propose > > %_libdir > %_libdir/include > %_libdir/modules > %_libdir/mod > %_libdir/f90 > %_includedir/%_lib > %_includedir/%_lib/modules > %_includedir/%_lib/mod > %_includedir/%_lib/f90 > > (f90 may also be replaced by another meaningfull subdirectory name). > > This directory could be called %_fmoddir > > And add -I%_fmoddir in FFLAGS when compiling some code that > requires the module. > > > The optimal situation would be to have %_fmoddir defined in rpm macros > and -I%_fmoddir added to default FFLAGS. So, I think that if they're searched in the include path, they should be under the %_includedir. Modules/mod is too vague, but perhaps f90 is too specific? Wouldn't later fortran modules hit this as well? (f95? 2003?) I'm also not opposed to making this a macro, it seems logical to me. ~spot From pertusus at free.fr Sun Oct 21 17:55:44 2007 From: pertusus at free.fr (Patrice Dumas) Date: Sun, 21 Oct 2007 19:55:44 +0200 Subject: [Fedora-packaging] fortran .mod files In-Reply-To: <1192976322.22958.4.camel@localhost.localdomain> References: <20071020222443.GA23353@free.fr> <1192976322.22958.4.camel@localhost.localdomain> Message-ID: <20071021175544.GA23187@free.fr> On Sun, Oct 21, 2007 at 10:18:42AM -0400, Tom spot Callaway wrote: > > So, I think that if they're searched in the include path, they should be > under the %_includedir. Modules/mod is too vague, but perhaps f90 is too > specific? Wouldn't later fortran modules hit this as well? (f95? 2003?) Yes, I chose f90 because it was the oldest fortran standard version with these .mod. To be more genereic, maybe %_includedir/%_lib/fortran -- Pat From tcallawa at redhat.com Sun Oct 21 18:23:42 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Sun, 21 Oct 2007 14:23:42 -0400 Subject: [Fedora-packaging] fortran .mod files In-Reply-To: <20071021175544.GA23187@free.fr> References: <20071020222443.GA23353@free.fr> <1192976322.22958.4.camel@localhost.localdomain> <20071021175544.GA23187@free.fr> Message-ID: <1192991022.22958.6.camel@localhost.localdomain> On Sun, 2007-10-21 at 19:55 +0200, Patrice Dumas wrote: > On Sun, Oct 21, 2007 at 10:18:42AM -0400, Tom spot Callaway wrote: > > > > So, I think that if they're searched in the include path, they should be > > under the %_includedir. Modules/mod is too vague, but perhaps f90 is too > > specific? Wouldn't later fortran modules hit this as well? (f95? 2003?) > > Yes, I chose f90 because it was the oldest fortran standard version with > these .mod. To be more genereic, maybe > > %_includedir/%_lib/fortran This seems reasonable to me. Anyone else? ~spot From pertusus at free.fr Sun Oct 21 21:52:55 2007 From: pertusus at free.fr (Patrice Dumas) Date: Sun, 21 Oct 2007 23:52:55 +0200 Subject: [Fedora-packaging] virtual provides for local servers Message-ID: <20071021215255.GC23187@free.fr> Hello, I sent this on the devel list, nobody responded. ltsp5 requires an xdmcp server, but more than one package provides the functionnality. What about adding a virtual provides for local servers like Provides: server(xdmcp) This could also be used for smtpdaemon and webserver, which would become server(smtp) and server(web) (or server(http))? What do you think about that idea? -- Pat From jkeating at redhat.com Mon Oct 22 02:11:28 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 21 Oct 2007 22:11:28 -0400 Subject: [Fedora-packaging] virtual provides for local servers In-Reply-To: <20071021215255.GC23187@free.fr> References: <20071021215255.GC23187@free.fr> Message-ID: <20071021221128.36d86e9e@redhat.com> On Sun, 21 Oct 2007 23:52:55 +0200 Patrice Dumas wrote: > What do you think about that idea? My immediate reaction is that it adds more and more Provides that tools have to process, making things slower and slower. It also gets us into the game of "shortest name wins" once more with these things, but maybe that's not a problem per se. Why don't you work up a proposal on the wiki to consolidate all these things like 'web-server' that you want to change to a more commonly used server(web), generate a list of all the packages that would have to be changed both for provides and for Requires, propose a time for the work to be done, etc.. Treat it almost like a Feature page. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rc040203 at freenet.de Mon Oct 22 03:40:35 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 22 Oct 2007 05:40:35 +0200 Subject: [Fedora-packaging] fortran .mod files In-Reply-To: <1192991022.22958.6.camel@localhost.localdomain> References: <20071020222443.GA23353@free.fr> <1192976322.22958.4.camel@localhost.localdomain> <20071021175544.GA23187@free.fr> <1192991022.22958.6.camel@localhost.localdomain> Message-ID: <1193024435.25729.66.camel@mccallum.corsepiu.local> On Sun, 2007-10-21 at 14:23 -0400, Tom "spot" Callaway wrote: > On Sun, 2007-10-21 at 19:55 +0200, Patrice Dumas wrote: > > On Sun, Oct 21, 2007 at 10:18:42AM -0400, Tom spot Callaway wrote: > > > > > > So, I think that if they're searched in the include path, they should be > > > under the %_includedir. Modules/mod is too vague, but perhaps f90 is too > > > specific? Wouldn't later fortran modules hit this as well? (f95? 2003?) > > > > Yes, I chose f90 because it was the oldest fortran standard version with > > these .mod. To be more genereic, maybe > > > > %_includedir/%_lib/fortran > > This seems reasonable to me. Anyone else? I think we will need some gcc's f90 specialist's opinion. My gut feeling is, a manually multilib'ed include directory like the one above (%_includedir/%_lib) can't be right, unless GCC starts to support searching multilib'ed include dirs (It currently doesn't). That said, I am in favor of a directory rooted at %{_libdir}, say %{_libdir}/finclude or %{_libdir}/f90 or %{_libdir}/gfortran Ralf From pertusus at free.fr Mon Oct 22 08:36:00 2007 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 22 Oct 2007 10:36:00 +0200 Subject: [Fedora-packaging] virtual provides for local servers In-Reply-To: <20071021221128.36d86e9e@redhat.com> References: <20071021215255.GC23187@free.fr> <20071021221128.36d86e9e@redhat.com> Message-ID: <20071022083600.GA2941@free.fr> On Sun, Oct 21, 2007 at 10:11:28PM -0400, Jesse Keating wrote: > On Sun, 21 Oct 2007 23:52:55 +0200 > Patrice Dumas wrote: > > > What do you think about that idea? > > My immediate reaction is that it adds more and more Provides that tools > have to process, making things slower and slower. It also gets us into > the game of "shortest name wins" once more with these things, but maybe > that's not a problem per se. The aim is not to add more virtual provides, but have a consistent naming for the proivdes such that there is a rule to find out the virtual provide name. My proposal is therefore like: When a program provides a server listening on a given port, and a virtual provide for that functionality is neeeded, the corresponding provide should named server(port_name), port_name being the official name of the port, as in /etc/services. > Why don't you work up a proposal on the wiki to consolidate all these > things like 'web-server' that you want to change to a more commonly As there is no common naming scheme I can't say what other virtual provides exist beside smtpdaemon and webserver. > used server(web), generate a list of all the packages that would have > to be changed both for provides and for Requires, propose a time for > the work to be done, etc.. Treat it almost like a Feature page. I was gathering opinions before doing that. -- Pat From jkeating at redhat.com Mon Oct 22 13:48:13 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 22 Oct 2007 09:48:13 -0400 Subject: [Fedora-packaging] virtual provides for local servers In-Reply-To: <20071022083600.GA2941@free.fr> References: <20071021215255.GC23187@free.fr> <20071021221128.36d86e9e@redhat.com> <20071022083600.GA2941@free.fr> Message-ID: <20071022094813.5154247c@redhat.com> On Mon, 22 Oct 2007 10:36:00 +0200 Patrice Dumas wrote: > The aim is not to add more virtual provides, but have a consistent > naming for the proivdes such that there is a rule to find out the > virtual provide name. > > My proposal is therefore like: > > When a program provides a server listening on a given port, and a > virtual provide for that functionality is neeeded, the corresponding > provide should named server(port_name), port_name being the official > name of the port, as in /etc/services. That seems somewhat reasonable, how often do names change or get added to /etc/services? > > > Why don't you work up a proposal on the wiki to consolidate all > > these things like 'web-server' that you want to change to a more > > commonly > > As there is no common naming scheme I can't say what other virtual > provides exist beside smtpdaemon and webserver. We have them in perl like perl(Make::Maker) or in python python(abi), we have it in rpm itself rpmlib(CompressedFileNames) <= 3.0.4-1. I think there is enough evidence out there that foo(bar) is the defacto standard for virtual provides that are more complicated than a single name or library. > > used server(web), generate a list of all the packages that would > > have to be changed both for provides and for Requires, propose a > > time for the work to be done, etc.. Treat it almost like a Feature > > page. > > I was gathering opinions before doing that. Chicken, meet egg? (: -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ed at eh3.com Mon Oct 22 14:24:00 2007 From: ed at eh3.com (Ed Hill) Date: Mon, 22 Oct 2007 10:24:00 -0400 Subject: [Fedora-packaging] fortran .mod files In-Reply-To: <1192976322.22958.4.camel@localhost.localdomain> References: <20071020222443.GA23353@free.fr> <1192976322.22958.4.camel@localhost.localdomain> Message-ID: <20071022102400.65c5c380@localhost.localdomain> Greetings gfortran wizards, Could some kind soul please provide some guidance (or perhaps just opinions/perspective?) regarding the handling of *.mod files within a Linux distribution? The "where should they live?" question came up on the Fedora packaging list at: https://www.redhat.com/archives/fedora-packaging/2007-October/msg00006.html And, here is a concrete example: 0) netcdf provides a netcdf.mod file 1) the mod file provided for i386 is (aha!) not identical to the one provided for x86_64 (and for ppc/ppc64) 2) we'd like to be able to simultaneously install both the i386 and x86_64 versions (and ditto for ppc/ppc64) 3) where, in your opinion, is the "best" or "standard" place to put the netcdf.mod files? Any help or insights are appreciated! thank you, 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 sgk at troutmask.apl.washington.edu Mon Oct 22 14:41:09 2007 From: sgk at troutmask.apl.washington.edu (Steve Kargl) Date: Mon, 22 Oct 2007 07:41:09 -0700 Subject: [Fedora-packaging] fortran .mod files In-Reply-To: <20071022102400.65c5c380@localhost.localdomain> References: <20071020222443.GA23353@free.fr> <1192976322.22958.4.camel@localhost.localdomain> <20071022102400.65c5c380@localhost.localdomain> Message-ID: <20071022144109.GA39919@troutmask.apl.washington.edu> /usr/local/modules// PS: This is off-topic for this specific list. -- Steve From fxcoudert at gmail.com Mon Oct 22 14:56:56 2007 From: fxcoudert at gmail.com (=?ISO-8859-1?Q?Fran=E7ois-Xavier_Coudert?=) Date: Mon, 22 Oct 2007 15:56:56 +0100 Subject: [Fedora-packaging] fortran .mod files In-Reply-To: <20071022102400.65c5c380@localhost.localdomain> References: <20071020222443.GA23353@free.fr> <1192976322.22958.4.camel@localhost.localdomain> <20071022102400.65c5c380@localhost.localdomain> Message-ID: <19c433eb0710220756g4c22e9ceu16962446bfd81eb5@mail.gmail.com> Hello, > Could some kind soul please provide some guidance (or perhaps just > opinions/perspective?) regarding the handling of *.mod files within a > Linux distribution? The "where should they live?" question came up on > the Fedora packaging list at: > > https://www.redhat.com/archives/fedora-packaging/2007-October/msg00006.html Well, I think the constraints detailed in that thread are correct, including the fact that they are architecture-dependent. Moreover, something that might not have been considered by you until now is that they also are compiler-dependent: different compilers will generate different .mod files for the same source, and different versions of the same compiler might generate different .mod files. For this reason, I think it's considered bad programming style for a project to require mod files from another project in order to compile. But, since there appears to be existing examples of this practice, we probably have to find a practical solution to this issue anyway. We had some discussion a while back about where to put module files (thread starting at http://gcc.gnu.org/ml/fortran/2005-11/msg00516.html), but a conclusion was easier to reach because we were only dealing with gfortran intrinsic (or "internal") module files, so we ended up hidding them inside the gcc directories (/usr/lib*/gcc/${target}/${version}/finclude). For the naming, there was a general agreement about "finclude" (with F for Fortran). A minority was leaning towards "mod" or "modules", which is more correct from the Fortran point of view (these files are module files, and are not "included" in the Fortran terminology), but then there is a risk of confusion with other meanings for modules (kernel modules, or whatever). Now, my personnal opinion is that since these files are compiler-generated and target-dependent, they are very similar to libraries. For that reason, I think they probably should be placed in /usr/lib*/finclude, or in /usr/finclude*, where * can be 32, 64 or nothing. Regards, FX From burnus at net-b.de Mon Oct 22 15:10:20 2007 From: burnus at net-b.de (Tobias Burnus) Date: Mon, 22 Oct 2007 17:10:20 +0200 Subject: [Fedora-packaging] fortran .mod files In-Reply-To: <20071022102400.65c5c380@localhost.localdomain> References: <20071020222443.GA23353@free.fr> <1192976322.22958.4.camel@localhost.localdomain> <20071022102400.65c5c380@localhost.localdomain> Message-ID: <471CBD5C.9060501@net-b.de> Ed Hill wrote: > https://www.redhat.com/archives/fedora-packaging/2007-October/msg00006.html > And, here is a concrete example: > > 0) netcdf provides a netcdf.mod file > 1) the mod file provided for i386 is (aha!) not identical to > the one provided for x86_64 (and for ppc/ppc64) > 2) we'd like to be able to simultaneously install both > the i386 and x86_64 versions (and ditto for ppc/ppc64) > 3) where, in your opinion, is the "best" or "standard" place to > put the netcdf.mod files? > .mod files are in a way like C's .h file: They store the interface of procedures (functions). However, they are generated from a source code file which contains a module (= collection of procedures, type ("struct") declarations and module variables). As they are generated from a source file, their content may differ depending on the preprocessor flags and processor-defined variable (e.g. size of a pointer on 32 bit or 64 bit systems). As C's include files, -Idir can be used to add more directories to the .mod (and "include" and the preprocessor's "#include") path. Thus the natural place would be, e.g., /usr/include/netcdf.mod (where it is on my openSUSE system). However, as noted, this makes problems on systems where both a 32bit and 64bit version has to be provided. I have frankly no idea how to solve this. You could put the files into different directories, but then the user has to specify the path which is rather inconvenient. One could also put the default file (the one generated without specifiying e.g. -m32 or -m64) into /usr/include and put the other version somewhere else. Or ... Tobias From rc040203 at freenet.de Mon Oct 22 15:44:35 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 22 Oct 2007 17:44:35 +0200 Subject: [Fedora-packaging] fortran .mod files In-Reply-To: <471CBD5C.9060501@net-b.de> References: <20071020222443.GA23353@free.fr> <1192976322.22958.4.camel@localhost.localdomain> <20071022102400.65c5c380@localhost.localdomain> <471CBD5C.9060501@net-b.de> Message-ID: <1193067876.3693.9.camel@mccallum.corsepiu.local> On Mon, 2007-10-22 at 17:10 +0200, Tobias Burnus wrote: > Ed Hill wrote: > > https://www.redhat.com/archives/fedora-packaging/2007-October/msg00006.html > > And, here is a concrete example: > > > > 0) netcdf provides a netcdf.mod file > > 1) the mod file provided for i386 is (aha!) not identical to > > the one provided for x86_64 (and for ppc/ppc64) > > 2) we'd like to be able to simultaneously install both > > the i386 and x86_64 versions (and ditto for ppc/ppc64) > > 3) where, in your opinion, is the "best" or "standard" place to > > put the netcdf.mod files? > > > .mod files are in a way like C's .h file: Are they processed by cpp? IMO, there should not be anything under /usr/include which can't be processed by cpp. > They store the interface of > procedures (functions). However, they are generated from a source code > file which contains a module (= collection of procedures, type > ("struct") declarations and module variables). > > As they are generated from a source file, their content may differ > depending on the preprocessor flags and processor-defined variable (e.g. > size of a pointer on 32 bit or 64 bit systems). > > As C's include files, -Idir can be used to add more directories to the > .mod (and "include" and the preprocessor's "#include") path. Well, I am not sure GCC using -I<> has been a clever decision, but that's beyond the scope of this thread. > Thus the natural place would be, e.g., /usr/include/netcdf.mod (where it > is on my openSUSE system). > > However, as noted, this makes problems on systems where both a 32bit and > 64bit version has to be provided. Exactly. Therefore it would be natural to put them somewhere inside of a multilib'ed subdir ($libdir/ in GCC terms, %_libdir in rpm terms) > I have frankly no idea how to solve this. You could put the files into > different directories, but then the user has to specify the path which > is rather inconvenient. One could also put the default file (the one > generated without specifiying e.g. -m32 or -m64) into /usr/include and > put the other version somewhere else. Or ... How do other languages which have similar files, such as Ada, Modula 2 and some variants of PASCAL handle this issue? IIRC, ancient VAX/VMS Pascal/Modula installed their *mod equivalents (Sorry, this his was > 15 years ago) next to their libraries. Ralf From a.badger at gmail.com Mon Oct 22 16:16:22 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 22 Oct 2007 09:16:22 -0700 Subject: [Fedora-packaging] fortran .mod files In-Reply-To: <1193024435.25729.66.camel@mccallum.corsepiu.local> References: <20071020222443.GA23353@free.fr> <1192976322.22958.4.camel@localhost.localdomain> <20071021175544.GA23187@free.fr> <1192991022.22958.6.camel@localhost.localdomain> <1193024435.25729.66.camel@mccallum.corsepiu.local> Message-ID: <471CCCD6.3060804@gmail.com> Ralf Corsepius wrote: > On Sun, 2007-10-21 at 14:23 -0400, Tom "spot" Callaway wrote: >> On Sun, 2007-10-21 at 19:55 +0200, Patrice Dumas wrote: >>> On Sun, Oct 21, 2007 at 10:18:42AM -0400, Tom spot Callaway wrote: >>>> So, I think that if they're searched in the include path, they should be >>>> under the %_includedir. Modules/mod is too vague, but perhaps f90 is too >>>> specific? Wouldn't later fortran modules hit this as well? (f95? 2003?) >>> Yes, I chose f90 because it was the oldest fortran standard version with >>> these .mod. To be more genereic, maybe >>> >>> %_includedir/%_lib/fortran >> This seems reasonable to me. Anyone else? > > I think we will need some gcc's f90 specialist's opinion. > > My gut feeling is, a manually multilib'ed include directory like the one > above (%_includedir/%_lib) can't be right, unless GCC starts to support > searching multilib'ed include dirs (It currently doesn't). > > That said, I am in favor of a directory rooted at %{_libdir}, say > %{_libdir}/finclude > or %{_libdir}/f90 > or %{_libdir}/gfortran > We have precedent (on a smaller scale) for this from the C world as well with things like %{_libdir}/glib-2.0/include/glibconfig.h. After reading that these mod files are potentially compiler dependent as well, using %{_libdir}/f90 and %{_libdir}/gfortran makes a lot of sense to me. -Toshio From pertusus at free.fr Mon Oct 22 20:49:12 2007 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 22 Oct 2007 22:49:12 +0200 Subject: [Fedora-packaging] fortran .mod files In-Reply-To: <471CCCD6.3060804@gmail.com> References: <20071020222443.GA23353@free.fr> <1192976322.22958.4.camel@localhost.localdomain> <20071021175544.GA23187@free.fr> <1192991022.22958.6.camel@localhost.localdomain> <1193024435.25729.66.camel@mccallum.corsepiu.local> <471CCCD6.3060804@gmail.com> Message-ID: <20071022204912.GD2653@free.fr> On Mon, Oct 22, 2007 at 09:16:22AM -0700, Toshio Kuratomi wrote: > We have precedent (on a smaller scale) for this from the C world as well > with things like %{_libdir}/glib-2.0/include/glibconfig.h. > > After reading that these mod files are potentially compiler dependent as > well, using %{_libdir}/f90 and %{_libdir}/gfortran makes a lot of sense to > me. f90 is not a compiler. Or it is a compiler like cc of f77 are. Since the files are compiler specific, it may make sense to use the compiler name. So the fortran modules dir could be %{_libdir}/gfortran, or %{_libdir}/gfortran/modules (and similar in other directories). -- Pat From tcallawa at redhat.com Mon Oct 22 20:50:48 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Mon, 22 Oct 2007 16:50:48 -0400 Subject: [Fedora-packaging] fortran .mod files In-Reply-To: <20071022204912.GD2653@free.fr> References: <20071020222443.GA23353@free.fr> <1192976322.22958.4.camel@localhost.localdomain> <20071021175544.GA23187@free.fr> <1192991022.22958.6.camel@localhost.localdomain> <1193024435.25729.66.camel@mccallum.corsepiu.local> <471CCCD6.3060804@gmail.com> <20071022204912.GD2653@free.fr> Message-ID: <1193086248.22958.25.camel@localhost.localdomain> On Mon, 2007-10-22 at 22:49 +0200, Patrice Dumas wrote: > %{_libdir}/gfortran/modules ^^^ I like this the best so far. ~spot From rc040203 at freenet.de Tue Oct 23 03:30:03 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 23 Oct 2007 05:30:03 +0200 Subject: [Fedora-packaging] fortran .mod files In-Reply-To: <20071022204912.GD2653@free.fr> References: <20071020222443.GA23353@free.fr> <1192976322.22958.4.camel@localhost.localdomain> <20071021175544.GA23187@free.fr> <1192991022.22958.6.camel@localhost.localdomain> <1193024435.25729.66.camel@mccallum.corsepiu.local> <471CCCD6.3060804@gmail.com> <20071022204912.GD2653@free.fr> Message-ID: <1193110203.3693.12.camel@mccallum.corsepiu.local> On Mon, 2007-10-22 at 22:49 +0200, Patrice Dumas wrote: > On Mon, Oct 22, 2007 at 09:16:22AM -0700, Toshio Kuratomi wrote: > > We have precedent (on a smaller scale) for this from the C world as well > > with things like %{_libdir}/glib-2.0/include/glibconfig.h. > > > > After reading that these mod files are potentially compiler dependent as > > well, using %{_libdir}/f90 and %{_libdir}/gfortran makes a lot of sense to > > me. > > f90 is not a compiler. f90 is a language dialect of fortran. It's compiler is gfortran. Ralf From rc040203 at freenet.de Tue Oct 23 03:33:11 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 23 Oct 2007 05:33:11 +0200 Subject: [Fedora-packaging] fortran .mod files In-Reply-To: <1193086248.22958.25.camel@localhost.localdomain> References: <20071020222443.GA23353@free.fr> <1192976322.22958.4.camel@localhost.localdomain> <20071021175544.GA23187@free.fr> <1192991022.22958.6.camel@localhost.localdomain> <1193024435.25729.66.camel@mccallum.corsepiu.local> <471CCCD6.3060804@gmail.com> <20071022204912.GD2653@free.fr> <1193086248.22958.25.camel@localhost.localdomain> Message-ID: <1193110391.3693.17.camel@mccallum.corsepiu.local> On Mon, 2007-10-22 at 16:50 -0400, Tom "spot" Callaway wrote: > On Mon, 2007-10-22 at 22:49 +0200, Patrice Dumas wrote: > > %{_libdir}/gfortran/modules > > ^^^ I like this the best so far. Well, it actually is irrelevant what we think. gfortran should have a default search path being implied by f90, and it there where packages should install it's *.mod's into. If gfortran doesn't have a default search path, this would qualify as a bug in gcc-gfortran. Ralf From pertusus at free.fr Tue Oct 23 07:07:02 2007 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 23 Oct 2007 09:07:02 +0200 Subject: [Fedora-packaging] fortran .mod files In-Reply-To: <1193110203.3693.12.camel@mccallum.corsepiu.local> References: <20071020222443.GA23353@free.fr> <1192976322.22958.4.camel@localhost.localdomain> <20071021175544.GA23187@free.fr> <1192991022.22958.6.camel@localhost.localdomain> <1193024435.25729.66.camel@mccallum.corsepiu.local> <471CCCD6.3060804@gmail.com> <20071022204912.GD2653@free.fr> <1193110203.3693.12.camel@mccallum.corsepiu.local> Message-ID: <20071023070702.GB2675@free.fr> On Tue, Oct 23, 2007 at 05:30:03AM +0200, Ralf Corsepius wrote: > On Mon, 2007-10-22 at 22:49 +0200, Patrice Dumas wrote: > > On Mon, Oct 22, 2007 at 09:16:22AM -0700, Toshio Kuratomi wrote: > > > We have precedent (on a smaller scale) for this from the C world as well > > > with things like %{_libdir}/glib-2.0/include/glibconfig.h. > > > > > > After reading that these mod files are potentially compiler dependent as > > > well, using %{_libdir}/f90 and %{_libdir}/gfortran makes a lot of sense to > > > me. > > > > f90 is not a compiler. > f90 is a language dialect of fortran. It's compiler is gfortran. Could also be g95 (or any other f90 compiler). But is it reasonable to think about providing 2 compilers in fedora? -- Pat From pertusus at free.fr Tue Oct 23 07:08:43 2007 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 23 Oct 2007 09:08:43 +0200 Subject: [Fedora-packaging] fortran .mod files In-Reply-To: <1193110391.3693.17.camel@mccallum.corsepiu.local> References: <20071020222443.GA23353@free.fr> <1192976322.22958.4.camel@localhost.localdomain> <20071021175544.GA23187@free.fr> <1192991022.22958.6.camel@localhost.localdomain> <1193024435.25729.66.camel@mccallum.corsepiu.local> <471CCCD6.3060804@gmail.com> <20071022204912.GD2653@free.fr> <1193086248.22958.25.camel@localhost.localdomain> <1193110391.3693.17.camel@mccallum.corsepiu.local> Message-ID: <20071023070843.GC2675@free.fr> On Tue, Oct 23, 2007 at 05:33:11AM +0200, Ralf Corsepius wrote: > On Mon, 2007-10-22 at 16:50 -0400, Tom "spot" Callaway wrote: > > On Mon, 2007-10-22 at 22:49 +0200, Patrice Dumas wrote: > > > %{_libdir}/gfortran/modules > > > > ^^^ I like this the best so far. > Well, it actually is irrelevant what we think. > > gfortran should have a default search path being implied by f90, and it > there where packages should install it's *.mod's into. > > If gfortran doesn't have a default search path, this would qualify as a > bug in gcc-gfortran. It has, it is includedir, but it is not usable. -- Pat From pertusus at free.fr Tue Oct 23 09:39:05 2007 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 23 Oct 2007 11:39:05 +0200 Subject: [Fedora-packaging] server provides packaging draft Message-ID: <20071023093905.GD2675@free.fr> Hello, I wrote down the virtual provides for server listening on a given port at: http://fedoraproject.org/wiki/PackagingDrafts/ServerProvides for consideration by the packaging commitee. If you know about existing virtual provides like smtpdaemon or webserver, you can tell them to me such that I inspect them, even if the proposal is not accepted. -- Pat From rc040203 at freenet.de Tue Oct 23 11:46:40 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 23 Oct 2007 13:46:40 +0200 Subject: [Fedora-packaging] fortran .mod files In-Reply-To: <20071023111940.GV5451@devserv.devel.redhat.com> References: <20071020222443.GA23353@free.fr> <1192976322.22958.4.camel@localhost.localdomain> <20071021175544.GA23187@free.fr> <1192991022.22958.6.camel@localhost.localdomain> <1193024435.25729.66.camel@mccallum.corsepiu.local> <471CCCD6.3060804@gmail.com> <20071022204912.GD2653@free.fr> <1193086248.22958.25.camel@localhost.localdomain> <1193110391.3693.17.camel@mccallum.corsepiu.local> <20071023111940.GV5451@devserv.devel.redhat.com> Message-ID: <1193140000.9342.60.camel@mccallum.corsepiu.local> On Tue, 2007-10-23 at 07:19 -0400, Jakub Jelinek wrote: > On Tue, Oct 23, 2007 at 05:33:11AM +0200, Ralf Corsepius wrote: > > On Mon, 2007-10-22 at 16:50 -0400, Tom "spot" Callaway wrote: > > > On Mon, 2007-10-22 at 22:49 +0200, Patrice Dumas wrote: > > > > %{_libdir}/gfortran/modules > > > > > > ^^^ I like this the best so far. > > Well, it actually is irrelevant what we think. > > > > gfortran should have a default search path being implied by f90, and it > > there where packages should install it's *.mod's into. > > > > If gfortran doesn't have a default search path, this would qualify as a > > bug in gcc-gfortran. > > `gcc $RPM_OPT_FLAGS -print-file-name=finclude` > > (which is /usr/lib/gcc/*-redhat-linux/*/finclude ). OK this is what I had presumed to be a GCC-internal/private directory. > This is a compiler version and arch dependent path, but *.mod files > are heavily compiler version dependent. Hmm, ... > But I guess I'll need to make some changes, because say on > i386 this is /usr/lib/gcc/i386-redhat-linux/4.1.2/finclude, > while on x86_64 for 32-bit rpms > /usr/lib/gcc/x86_64-redhat-linux/4.1.2/finclude/ ) What I was referring to (and implicitly proposing) was GCC/gfortran to be extended to have a "standard, system-wide, GCC-independent" *.mod installation directory/*.mod-search path, similar to /usr/include for cpp'ed sources (c/c++-headers). But ... if, as you say, *.mod's are really are compiler-dependent, then gcc-gfortran(f90) has a real problem. Ralf From burnus at net-b.de Mon Oct 22 16:04:46 2007 From: burnus at net-b.de (Tobias Burnus) Date: Mon, 22 Oct 2007 18:04:46 +0200 Subject: [Fedora-packaging] fortran .mod files In-Reply-To: <19c433eb0710220756g4c22e9ceu16962446bfd81eb5@mail.gmail.com> References: <20071020222443.GA23353@free.fr> <1192976322.22958.4.camel@localhost.localdomain> <20071022102400.65c5c380@localhost.localdomain> <19c433eb0710220756g4c22e9ceu16962446bfd81eb5@mail.gmail.com> Message-ID: <471CCA1E.9040009@net-b.de> Fran?ois-Xavier Coudert wrote: > Well, I think the constraints detailed in that thread are correct, > including the fact that they are architecture-dependent. Moreover, > something that might not have been considered by you until now is that > they also are compiler-dependent: different compilers will generate > different .mod files for the same source, and different versions of > the same compiler might generate different .mod files. For Linux distributions the latter part should be no problem as there is usually only one true system compiler. (Even if the distributions ships several compiler such as gcc 4.1, 4.2 and 4.3, usually the libraries are only compiled by one of them, e.g. 4.2.) > For this reason, I think it's considered bad programming style for a project to > require mod files from another project in order to compile. I'm quite happy that I can use the libraries which come with my linux distribution without needing to compile blas, lapack, netcdf, openmpi, fft etc. myself. > We had some discussion a while back about where to put module files, > but a conclusion was easier to reach because we were only dealing with > gfortran intrinsic (or "internal") module files, so we ended up hidding > them inside the gcc directories > (/usr/lib*/gcc/${target}/${version}/finclude). At least on my system this gives the *same* directory for -m32 and -m64 (see output by "gfortran -v -c -m32 file.f90"). Actually, only the 64bit version is installed on my x86_64-unknown-linux-gnu system. > Now, my personnal opinion is that since these files are > compiler-generated and target-dependent, they are very similar to > libraries. For that reason, I think they probably should be placed in > /usr/lib*/finclude, or in /usr/finclude*, where * can be 32, 64 or > nothing. > I see two proper places: a) A library/compiler specific place; this would be the natural choice for a non-default/system compiler, e.g. /usr/lib64/mpi/gcc/openmpi/lib64/mpi.mod or /usr/lib64/mpi/gcc/openmpi/include/mpi.mod This always works, but one needs either a wrapper ("mpif90") or to specify the -Ipath. b) A generic place for the system compiler, here, I like the location /usr/lib*/finclude/ or, why not, /usr/lib*//finclude For (b) one still needs to make it generally work that -m32 and -m64 have different search paths; this is (see above) currently not the case. I don't know whether one needs to distinguish other -m* options as well -- such as e.g. IA64's -mbig-endian/-mlittle-endian etc. Tobias From jakub at redhat.com Tue Oct 23 11:19:40 2007 From: jakub at redhat.com (Jakub Jelinek) Date: Tue, 23 Oct 2007 07:19:40 -0400 Subject: [Fedora-packaging] fortran .mod files In-Reply-To: <1193110391.3693.17.camel@mccallum.corsepiu.local> References: <20071020222443.GA23353@free.fr> <1192976322.22958.4.camel@localhost.localdomain> <20071021175544.GA23187@free.fr> <1192991022.22958.6.camel@localhost.localdomain> <1193024435.25729.66.camel@mccallum.corsepiu.local> <471CCCD6.3060804@gmail.com> <20071022204912.GD2653@free.fr> <1193086248.22958.25.camel@localhost.localdomain> <1193110391.3693.17.camel@mccallum.corsepiu.local> Message-ID: <20071023111940.GV5451@devserv.devel.redhat.com> On Tue, Oct 23, 2007 at 05:33:11AM +0200, Ralf Corsepius wrote: > On Mon, 2007-10-22 at 16:50 -0400, Tom "spot" Callaway wrote: > > On Mon, 2007-10-22 at 22:49 +0200, Patrice Dumas wrote: > > > %{_libdir}/gfortran/modules > > > > ^^^ I like this the best so far. > Well, it actually is irrelevant what we think. > > gfortran should have a default search path being implied by f90, and it > there where packages should install it's *.mod's into. > > If gfortran doesn't have a default search path, this would qualify as a > bug in gcc-gfortran. `gcc $RPM_OPT_FLAGS -print-file-name=finclude` (which is /usr/lib/gcc/*-redhat-linux/*/finclude ). This is a compiler version and arch dependent path, but *.mod files are heavily compiler version dependent. But I guess I'll need to make some changes, because say on i386 this is /usr/lib/gcc/i386-redhat-linux/4.1.2/finclude, while on x86_64 for 32-bit rpms /usr/lib/gcc/x86_64-redhat-linux/4.1.2/finclude/ ). Jakub From ed at eh3.com Tue Oct 23 14:07:18 2007 From: ed at eh3.com (Ed Hill) Date: Tue, 23 Oct 2007 10:07:18 -0400 Subject: [Fedora-packaging] fortran .mod files In-Reply-To: <1193140000.9342.60.camel@mccallum.corsepiu.local> References: <20071020222443.GA23353@free.fr> <1192976322.22958.4.camel@localhost.localdomain> <20071021175544.GA23187@free.fr> <1192991022.22958.6.camel@localhost.localdomain> <1193024435.25729.66.camel@mccallum.corsepiu.local> <471CCCD6.3060804@gmail.com> <20071022204912.GD2653@free.fr> <1193086248.22958.25.camel@localhost.localdomain> <1193110391.3693.17.camel@mccallum.corsepiu.local> <20071023111940.GV5451@devserv.devel.redhat.com> <1193140000.9342.60.camel@mccallum.corsepiu.local> Message-ID: <20071023100718.0e70d380@localhost.localdomain> On Tue, 23 Oct 2007 13:46:40 +0200 Ralf Corsepius wrote: > On Tue, 2007-10-23 at 07:19 -0400, Jakub Jelinek wrote: > > > But I guess I'll need to make some changes, because say on > > i386 this is /usr/lib/gcc/i386-redhat-linux/4.1.2/finclude, > > while on x86_64 for 32-bit rpms > > /usr/lib/gcc/x86_64-redhat-linux/4.1.2/finclude/ ) > What I was referring to (and implicitly proposing) was GCC/gfortran to > be extended to have a "standard, system-wide, GCC-independent" *.mod > installation directory/*.mod-search path, similar to /usr/include for > cpp'ed sources (c/c++-headers). > > But ... if, as you say, *.mod's are really are compiler-dependent, > then gcc-gfortran(f90) has a real problem. Yes, the F90/F95/F2003 *.mod files are compiler- and target-specific. As FX Coudert (one of the gfortran developers) pointed out: http://gcc.gnu.org/ml/fortran/2007-10/msg00306.html it may be best to treat the *.mod files more like libraries (and less like headers). FX's recommendation was: /usr/lib*/finclude or /usr/finclude* where * can be 32, 64 or nothing which is quite similar to Spot's "I like this the best so far" comment regarding the location: %{_libdir}/gfortran/modules So are we reaching a consensus here on "%{_libdir}/gfortran/modules"? Does anyone have any technical objections to it? 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 pertusus at free.fr Tue Oct 23 17:04:13 2007 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 23 Oct 2007 19:04:13 +0200 Subject: [Fedora-packaging] fortran .mod files In-Reply-To: <20071023100718.0e70d380@localhost.localdomain> References: <20071021175544.GA23187@free.fr> <1192991022.22958.6.camel@localhost.localdomain> <1193024435.25729.66.camel@mccallum.corsepiu.local> <471CCCD6.3060804@gmail.com> <20071022204912.GD2653@free.fr> <1193086248.22958.25.camel@localhost.localdomain> <1193110391.3693.17.camel@mccallum.corsepiu.local> <20071023111940.GV5451@devserv.devel.redhat.com> <1193140000.9342.60.camel@mccallum.corsepiu.local> <20071023100718.0e70d380@localhost.localdomain> Message-ID: <20071023170413.GB2680@free.fr> On Tue, Oct 23, 2007 at 10:07:18AM -0400, Ed Hill wrote: > > So are we reaching a consensus here on "%{_libdir}/gfortran/modules"? > Does anyone have any technical objections to it? Somebody from the gfortran team told that they were dependent on the compiler version. Do we take that into account? -- Pat From ed at eh3.com Tue Oct 23 22:12:04 2007 From: ed at eh3.com (Ed Hill) Date: Tue, 23 Oct 2007 18:12:04 -0400 Subject: [Fedora-packaging] fortran .mod files In-Reply-To: <20071023170413.GB2680@free.fr> References: <20071021175544.GA23187@free.fr> <1192991022.22958.6.camel@localhost.localdomain> <1193024435.25729.66.camel@mccallum.corsepiu.local> <471CCCD6.3060804@gmail.com> <20071022204912.GD2653@free.fr> <1193086248.22958.25.camel@localhost.localdomain> <1193110391.3693.17.camel@mccallum.corsepiu.local> <20071023111940.GV5451@devserv.devel.redhat.com> <1193140000.9342.60.camel@mccallum.corsepiu.local> <20071023100718.0e70d380@localhost.localdomain> <20071023170413.GB2680@free.fr> Message-ID: <20071023181204.40c95857@localhost.localdomain> On Tue, 23 Oct 2007 19:04:13 +0200 Patrice Dumas wrote: > On Tue, Oct 23, 2007 at 10:07:18AM -0400, Ed Hill wrote: > > > > So are we reaching a consensus here on > > "%{_libdir}/gfortran/modules"? Does anyone have any technical > > objections to it? > > Somebody from the gfortran team told that they were dependent on the > compiler version. Do we take that into account? Hi Patrice, Here is the latest from the GCC gfortran developers: http://gcc.gnu.org/ml/fortran/2007-10/msg00324.html http://gcc.gnu.org/ml/fortran/2007-10/msg00325.html Since there is no guarantee, it is (at least in theory) possible for a Fedora GCC update to cause *.mod file incompatibilities. It seems rather unlikely, though. Maybe this issue could be best handled as a check-list item when GCC updates occur? There are only a small number of Fedora packages that provide *.mod files. And they could be re-built whenever GCC is updated. What do you think? 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 pertusus at free.fr Tue Oct 23 22:32:15 2007 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 24 Oct 2007 00:32:15 +0200 Subject: [Fedora-packaging] fortran .mod files In-Reply-To: <20071023181204.40c95857@localhost.localdomain> References: <1193024435.25729.66.camel@mccallum.corsepiu.local> <471CCCD6.3060804@gmail.com> <20071022204912.GD2653@free.fr> <1193086248.22958.25.camel@localhost.localdomain> <1193110391.3693.17.camel@mccallum.corsepiu.local> <20071023111940.GV5451@devserv.devel.redhat.com> <1193140000.9342.60.camel@mccallum.corsepiu.local> <20071023100718.0e70d380@localhost.localdomain> <20071023170413.GB2680@free.fr> <20071023181204.40c95857@localhost.localdomain> Message-ID: <20071023223215.GA500@free.fr> On Tue, Oct 23, 2007 at 06:12:04PM -0400, Ed Hill wrote: > Here is the latest from the GCC gfortran developers: > > http://gcc.gnu.org/ml/fortran/2007-10/msg00324.html > http://gcc.gnu.org/ml/fortran/2007-10/msg00325.html > > Since there is no guarantee, it is (at least in theory) possible for a > Fedora GCC update to cause *.mod file incompatibilities. It seems > rather unlikely, though. We can assume that it is only for branch releases. > Maybe this issue could be best handled as a check-list item when GCC > updates occur? There are only a small number of Fedora packages that > provide *.mod files. And they could be re-built whenever GCC is > updated. It means that the API is broken with every gcc release. This is a lot of pain. gcc, g77 and g++ have much more stable API/ABI. But maybe this is the max occurence of breakage and it is not systematic? For us it is a bit annoying, but not too much since there aren't that much f90 packages and we are used to fix things, but for users, especially in science, it is likely to be very problematic since it implies that they must rebuild their in-house libraries very often. Anyway, it is not like if we have any choice. What could be interesting would be to have gfortran maintainers state for each release whether the .mod API was broken or not. And dependng on that we could make an announce for fedora packagers, like it is done when new gcc features requires a rebuild. -- Pat From nicolas.mailhot at laposte.net Wed Oct 24 11:38:58 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 24 Oct 2007 13:38:58 +0200 (CEST) Subject: [Fedora-packaging] Fonts spec template validation Message-ID: <8041.192.54.193.51.1193225938.squirrel@rousalka.dyndns.org> Hi all, While the current spec template in the Fonts SIG wiki (http://fedoraproject.org/wiki/SIGs/Fonts/Packaging/SpecTemplate) only documents common Fedora Fonts packaging practices, it's never been formally approved. I intend to submit it to FPC soon. If anyone on the fonts list object to part of this page or wants something clarified, please speak now Regards, -- Nicolas Mailhot From pertusus at free.fr Wed Oct 24 11:53:26 2007 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 24 Oct 2007 13:53:26 +0200 Subject: [Fedora-packaging] Fonts spec template validation In-Reply-To: <8041.192.54.193.51.1193225938.squirrel@rousalka.dyndns.org> References: <8041.192.54.193.51.1193225938.squirrel@rousalka.dyndns.org> Message-ID: <20071024115326.GB22623@free.fr> On Wed, Oct 24, 2007 at 01:38:58PM +0200, Nicolas Mailhot wrote: > Hi all, > > While the current spec template in the Fonts SIG wiki > (http://fedoraproject.org/wiki/SIGs/Fonts/Packaging/SpecTemplate) only > documents common Fedora Fonts packaging practices, it's never been > formally approved. It is very nice. > If anyone on the fonts list object to part of this page or wants > something clarified, please speak now Maybe I am demanding too much, but I would hae liked to have explanation on what to do for all of the different fonts, bitmap fonts, truetype fonts and type1 fonts (latex fonts?). There is nothing about /etc/X11/fontpath.d/ for example. -- Pat From nicolas.mailhot at laposte.net Wed Oct 24 12:17:11 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 24 Oct 2007 14:17:11 +0200 (CEST) Subject: [Fedora-packaging] Fonts spec template validation Message-ID: <37213.192.54.193.51.1193228231.squirrel@rousalka.dyndns.org> Le Mer 24 octobre 2007 13:53, Patrice Dumas a ?crit : > On Wed, Oct 24, 2007 at 01:38:58PM +0200, Nicolas Mailhot wrote: >> If anyone on the fonts list object to part of this page or wants >> something clarified, please speak now > > Maybe I am demanding too much, but I would hae liked to have > explanation on what to do for all of the different fonts, bitmap > fonts, > truetype fonts and type1 fonts (latex fonts?). There is nothing about > /etc/X11/fontpath.d/ > for example. Well nothing stops anyone from pushing a legacy font template through the Fonts SIG later (either by extending this one or by writing another). It's up to the packagers of these legacy fonts to agree in the SIG on a proposal. Right now no one wrote a legacy fonts template, so there's nothing to submit to FPC. Regards, -- Nicolas Mailhot From opensource at till.name Wed Oct 24 13:38:02 2007 From: opensource at till.name (Till Maas) Date: Wed, 24 Oct 2007 15:38:02 +0200 Subject: [Fedora-packaging] server provides packaging draft In-Reply-To: <20071023093905.GD2675@free.fr> References: <20071023093905.GD2675@free.fr> Message-ID: <200710241538.03470.opensource@till.name> On Di Oktober 23 2007, Patrice Dumas wrote: > If you know about existing virtual provides like smtpdaemon or > webserver, you can tell them to me such that I inspect them, even if the > proposal is not accepted. There is a propably incomplete list at: http://fedoraproject.org/wiki/VilleSkytt%C3%A4/VirtualProvides Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From pertusus at free.fr Wed Oct 24 15:26:18 2007 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 24 Oct 2007 17:26:18 +0200 Subject: [Fedora-packaging] server provides packaging draft In-Reply-To: <200710241538.03470.opensource@till.name> References: <20071023093905.GD2675@free.fr> <200710241538.03470.opensource@till.name> Message-ID: <20071024152618.GI22623@free.fr> On Wed, Oct 24, 2007 at 03:38:02PM +0200, Till Maas wrote: > On Di Oktober 23 2007, Patrice Dumas wrote: > > > If you know about existing virtual provides like smtpdaemon or > > webserver, you can tell them to me such that I inspect them, even if the > > proposal is not accepted. > > There is a propably incomplete list at: > http://fedoraproject.org/wiki/VilleSkytt%C3%A4/VirtualProvides Indeed, I add a look there. -- Pat From petersen at redhat.com Thu Oct 25 01:00:11 2007 From: petersen at redhat.com (Jens Petersen) Date: Thu, 25 Oct 2007 11:00:11 +1000 Subject: [Fedora-fonts-list] Re: [Fedora-packaging] Fonts spec template validation In-Reply-To: <37213.192.54.193.51.1193228231.squirrel@rousalka.dyndns.org> References: <37213.192.54.193.51.1193228231.squirrel@rousalka.dyndns.org> Message-ID: <471FEA9B.6060206@redhat.com> Nicolas Mailhot ????????: > Well nothing stops anyone from pushing a legacy font template through > the Fonts SIG later (either by extending this one or by writing > another). It's up to the packagers of these legacy fonts to agree in > the SIG on a proposal. Right now no one wrote a legacy fonts template, > so there's nothing to submit to FPC. True. A few legacy fonts went into Fedora recently: baekmuk-fonts-bdf, taipei-fonts, wqy-unibit-fonts, and a couple of Japanese bitmaps too. Some of them might be helpful starting points for a template. Jens From petersen at redhat.com Thu Oct 25 02:17:30 2007 From: petersen at redhat.com (Jens Petersen) Date: Thu, 25 Oct 2007 12:17:30 +1000 Subject: [Fedora-packaging] Re: [Fedora-fonts-list] Fonts spec template validation In-Reply-To: <8041.192.54.193.51.1193225938.squirrel@rousalka.dyndns.org> References: <8041.192.54.193.51.1193225938.squirrel@rousalka.dyndns.org> Message-ID: <471FFCBA.3070801@redhat.com> Nicolas Mailhot ????????: > While the current spec template in the Fonts SIG wiki > (http://fedoraproject.org/wiki/SIGs/Fonts/Packaging/SpecTemplate) only > documents common Fedora Fonts packaging practices, it's never been > formally approved. Just a minor quibble, but I would rather %fontdir and %fontconfdir do not end in '/'. One thing that is missing currently is the use of mkfontdir and ttmkfdir (or mkfontscale) to generate fonts.dir and fonts.scale even for truetype fonts. When we split out various CJK fonts from the fonts-* packages for F8 we moved that from %post to %install and keep fonts from different packages in separate directories. See for example sazanami-fonts. Jens From orion at cora.nwra.com Thu Oct 25 17:15:24 2007 From: orion at cora.nwra.com (Orion Poplawski) Date: Thu, 25 Oct 2007 11:15:24 -0600 Subject: [Fedora-packaging] Should /usr/share/aclocal be in filesystem? Message-ID: <4720CF2C.8070001@cora.nwra.com> Many packages dump their aclocal files in /usr/share/aclocal, but really don't need to require automake for normal usage. Should all of these packages also own /usr/share/aclocal, or should it get moved to 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 nicolas.mailhot at laposte.net Thu Oct 25 17:37:21 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 25 Oct 2007 19:37:21 +0200 Subject: [Fedora-packaging] Re: [Fedora-fonts-list] Fonts spec template validation In-Reply-To: <471FFCBA.3070801@redhat.com> References: <8041.192.54.193.51.1193225938.squirrel@rousalka.dyndns.org> <471FFCBA.3070801@redhat.com> Message-ID: <1193333841.24738.8.camel@rousalka.dyndns.org> Le jeudi 25 octobre 2007 ? 12:17 +1000, Jens Petersen a ?crit : > Nicolas Mailhot ????????: > > While the current spec template in the Fonts SIG wiki > > (http://fedoraproject.org/wiki/SIGs/Fonts/Packaging/SpecTemplate) only > > documents common Fedora Fonts packaging practices, it's never been > > formally approved. > > Just a minor quibble, but I would rather %fontdir and %fontconfdir do > not end in '/'. I have no strong feelings one way or another, existing rpm directoy macros are somewhat unconsistent on this (buildroot is /-terminated, other not), I've already changed it both ways several times, it's not problem to change it again. > One thing that is missing currently is the use of mkfontdir and ttmkfdir > (or mkfontscale) to generate fonts.dir and fonts.scale even for truetype > fonts. When we split out various CJK fonts from the fonts-* packages > for F8 we moved that from %post to %install and keep fonts from > different packages in separate directories. See for example sazanami-fonts. I'll let packagers of those examples to complete the template. As long as core fonts stuff is clearly marked optional (with a specific colour and text explaining it should not be added to new font packages). When Vera was added to Fedora years ago the xorg maintainer and desktop team strongly objected to adding new fonts to the legacy subsystem, and my own experience is they were right ? fonts that have been used a long time with the core fonts backend tend to work, new fonts tend to expose many bugs no one wants to fix anymore. Regards, -- 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 tcallawa at redhat.com Thu Oct 25 18:05:40 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Thu, 25 Oct 2007 14:05:40 -0400 Subject: [Fedora-packaging] Should /usr/share/aclocal be in filesystem? In-Reply-To: <4720CF2C.8070001@cora.nwra.com> References: <4720CF2C.8070001@cora.nwra.com> Message-ID: <1193335540.5563.4.camel@localhost.localdomain> On Thu, 2007-10-25 at 11:15 -0600, Orion Poplawski wrote: > Many packages dump their aclocal files in /usr/share/aclocal, but really > don't need to require automake for normal usage. Should all of these > packages also own /usr/share/aclocal, or should it get moved to filesystem? Seems like a decent idea to move to filesystem. ~spot From mclasen at redhat.com Thu Oct 25 18:07:54 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Thu, 25 Oct 2007 14:07:54 -0400 Subject: [Fedora-packaging] Should /usr/share/aclocal be in filesystem? In-Reply-To: <1193335540.5563.4.camel@localhost.localdomain> References: <4720CF2C.8070001@cora.nwra.com> <1193335540.5563.4.camel@localhost.localdomain> Message-ID: <1193335674.5924.1.camel@localhost.localdomain> On Thu, 2007-10-25 at 14:05 -0400, Tom "spot" Callaway wrote: > On Thu, 2007-10-25 at 11:15 -0600, Orion Poplawski wrote: > > Many packages dump their aclocal files in /usr/share/aclocal, but really > > don't need to require automake for normal usage. Should all of these > > packages also own /usr/share/aclocal, or should it get moved to filesystem? > > Seems like a decent idea to move to filesystem. > Can we please not change our stance on this every other release ? I've added tons of Requires: automake for this exact reason. And it doesn't seem like a big burden for a devel package to require automake. If we are not talking about devel packages, then that would be the thing to fix... From tcallawa at redhat.com Thu Oct 25 18:24:35 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Thu, 25 Oct 2007 14:24:35 -0400 Subject: [Fedora-packaging] Should /usr/share/aclocal be in filesystem? In-Reply-To: <1193335674.5924.1.camel@localhost.localdomain> References: <4720CF2C.8070001@cora.nwra.com> <1193335540.5563.4.camel@localhost.localdomain> <1193335674.5924.1.camel@localhost.localdomain> Message-ID: <1193336675.5563.8.camel@localhost.localdomain> On Thu, 2007-10-25 at 14:07 -0400, Matthias Clasen wrote: > On Thu, 2007-10-25 at 14:05 -0400, Tom "spot" Callaway wrote: > > On Thu, 2007-10-25 at 11:15 -0600, Orion Poplawski wrote: > > > Many packages dump their aclocal files in /usr/share/aclocal, but really > > > don't need to require automake for normal usage. Should all of these > > > packages also own /usr/share/aclocal, or should it get moved to filesystem? > > > > Seems like a decent idea to move to filesystem. > > > > Can we please not change our stance on this every other release ? > I've added tons of Requires: automake for this exact reason. > And it doesn't seem like a big burden for a devel package to require > automake. If we are not talking about devel packages, then that would be > the thing to fix... Technically, we're not really changing our stance here. If all of the packages putting aclocal bits are -devel packages, then it should be ok to let automake own that directory, and have those -devel packages depend on automake. If we've got non-devel packages doing this, then we need to look into moving that directory ownership to something more universal, like filesystem. The stance here is that packages need to Require (either directly, or implicitly through a dep chain) the packages which provide directories that they put files in. ~spot From orion at cora.nwra.com Thu Oct 25 19:02:11 2007 From: orion at cora.nwra.com (Orion Poplawski) Date: Thu, 25 Oct 2007 13:02:11 -0600 Subject: [Fedora-packaging] Should /usr/share/aclocal be in filesystem? In-Reply-To: <1193336675.5563.8.camel@localhost.localdomain> References: <4720CF2C.8070001@cora.nwra.com> <1193335540.5563.4.camel@localhost.localdomain> <1193335674.5924.1.camel@localhost.localdomain> <1193336675.5563.8.camel@localhost.localdomain> Message-ID: <4720E833.4010800@cora.nwra.com> Tom "spot" Callaway wrote: > Technically, we're not really changing our stance here. > > If all of the packages putting aclocal bits are -devel packages, then it > should be ok to let automake own that directory, and have those -devel > packages depend on automake. If we've got non-devel packages doing this, > then we need to look into moving that directory ownership to something > more universal, like filesystem. It was a -devel package in question, so we'll have it require automake ( though it still rankles a little - the -devel package is easily used without automake). -- 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 pertusus at free.fr Thu Oct 25 20:04:14 2007 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 25 Oct 2007 22:04:14 +0200 Subject: [Fedora-packaging] Should /usr/share/aclocal be in filesystem? In-Reply-To: <1193336675.5563.8.camel@localhost.localdomain> References: <4720CF2C.8070001@cora.nwra.com> <1193335540.5563.4.camel@localhost.localdomain> <1193335674.5924.1.camel@localhost.localdomain> <1193336675.5563.8.camel@localhost.localdomain> Message-ID: <20071025200414.GA2688@free.fr> On Thu, Oct 25, 2007 at 02:24:35PM -0400, Tom spot Callaway wrote: > > > Technically, we're not really changing our stance here. > > If all of the packages putting aclocal bits are -devel packages, then it > should be ok to let automake own that directory, and have those -devel > packages depend on automake. If we've got non-devel packages doing this, I don't think every package shipping an autoconf macro should mandatorily depend in automake. It should be left to the packager. So if /usr/share/aclocal isn't owned by the filesystem package, packages have to own /usr/share/aclocal. -- Pat From nicolas.mailhot at laposte.net Fri Oct 26 08:29:28 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 26 Oct 2007 10:29:28 +0200 (CEST) Subject: [Fedora-packaging] Metapackage guidelines Message-ID: <29670.192.54.193.51.1193387368.squirrel@rousalka.dyndns.org> Hi all, Recently metapackages have been rearing their ugly head again, and there is some disagreement on the proper use case and limits of metapackaging: https://bugzilla.redhat.com/show_bug.cgi?id=351571 I'd like FPC to clarify the Fedora policy on metapackages and publish this policy in the wiki Regards, -- Nicolas Mailhot From pertusus at free.fr Sun Oct 28 11:01:12 2007 From: pertusus at free.fr (Patrice Dumas) Date: Sun, 28 Oct 2007 12:01:12 +0100 Subject: [Fedora-packaging] ltsp root directory Message-ID: <20071028110112.GA2634@free.fr> Hello, The linux terminal project needs a directory for the filesystems exported to the terminals. Upstream uses /opt/ltsp. Upstream asked the lsb/fhs, but nobody answered something definitive, and nobody said that /opt/ltsp was wrong when upstream proposed it. In fedora, I think that /opt/ltsp is not very good. I asked on devel list and people objected to /opt/ltsp, proposing /var/lib/ltsp and /srv/ltsp. (as a side note, it is in fact along /opt/ltsp5/i386 and so on and so forth but it isn't of major interest, the issue is about the directory the ltsp directory should be in). What is your recommentdation? /opt /var/lib /srv Something else? -- Pat From pertusus at free.fr Sun Oct 28 11:11:45 2007 From: pertusus at free.fr (Patrice Dumas) Date: Sun, 28 Oct 2007 12:11:45 +0100 Subject: [Fedora-packaging] fortran .mod files In-Reply-To: <20071022144109.GA39919@troutmask.apl.washington.edu> References: <20071020222443.GA23353@free.fr> <1192976322.22958.4.camel@localhost.localdomain> <20071022102400.65c5c380@localhost.localdomain> <20071022144109.GA39919@troutmask.apl.washington.edu> Message-ID: <20071028111145.GB2634@free.fr> On Mon, Oct 22, 2007 at 07:41:09AM -0700, Steve Kargl wrote: > /usr/local/modules// > > PS: This is off-topic for this specific list. Which list would be the right one? /usr/local/modules// (or /usr/modules//) is not right, since one cannot add a new directory in /usr or /usr/local. The current proposal is to use /usr/lib*/gfortran/modules/ -- Pat From pertusus at free.fr Sun Oct 28 11:43:12 2007 From: pertusus at free.fr (Patrice Dumas) Date: Sun, 28 Oct 2007 12:43:12 +0100 Subject: [Fedora-packaging] fortran .mod files In-Reply-To: <20071023100718.0e70d380@localhost.localdomain> References: <20071021175544.GA23187@free.fr> <1192991022.22958.6.camel@localhost.localdomain> <1193024435.25729.66.camel@mccallum.corsepiu.local> <471CCCD6.3060804@gmail.com> <20071022204912.GD2653@free.fr> <1193086248.22958.25.camel@localhost.localdomain> <1193110391.3693.17.camel@mccallum.corsepiu.local> <20071023111940.GV5451@devserv.devel.redhat.com> <1193140000.9342.60.camel@mccallum.corsepiu.local> <20071023100718.0e70d380@localhost.localdomain> Message-ID: <20071028114312.GC2634@free.fr> On Tue, Oct 23, 2007 at 10:07:18AM -0400, Ed Hill wrote: > > So are we reaching a consensus here on "%{_libdir}/gfortran/modules"? > Does anyone have any technical objections to it? I have put a proposal here: https://fedoraproject.org/wiki/PackagingDrafts/FortranModulesDir for consideration by the packaging commitee. -- Pat From rc040203 at freenet.de Sun Oct 28 12:17:25 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sun, 28 Oct 2007 13:17:25 +0100 Subject: [Fedora-packaging] ltsp root directory In-Reply-To: <20071028110112.GA2634@free.fr> References: <20071028110112.GA2634@free.fr> Message-ID: <1193573845.9878.150.camel@mccallum.corsepiu.local> On Sun, 2007-10-28 at 12:01 +0100, Patrice Dumas wrote: > Hello, > > The linux terminal project needs a directory for the filesystems > exported to the terminals. Upstream uses /opt/ltsp. Upstream asked the > lsb/fhs, but nobody answered something definitive, and nobody said that > /opt/ltsp was wrong when upstream proposed it. > > In fedora, I think that /opt/ltsp is not very good. /opt/ltsp is absurd (for upstream, for a vendor and for a distro) > I asked on devel > list and people objected to /opt/ltsp, proposing /var/lib/ltsp and > /srv/ltsp. (as a side note, it is in fact along /opt/ltsp5/i386 and > so on and so forth but it isn't of major interest, the issue is about > the directory the ltsp directory should be in). > > > What is your recommentdation? > /opt > /var/lib > /srv Depends on what */ltsp is supposed to take. Could you elaborate? So far, of these alternative only /var/lib/ltsp would resemble to something potentially making sense. Ralf From dyoung at mesd.k12.or.us Sun Oct 28 16:46:04 2007 From: dyoung at mesd.k12.or.us (Dan Young) Date: Sun, 28 Oct 2007 09:46:04 -0700 Subject: [Fedora-packaging] ltsp root directory In-Reply-To: <1193573845.9878.150.camel@mccallum.corsepiu.local> References: <20071028110112.GA2634@free.fr> <1193573845.9878.150.camel@mccallum.corsepiu.local> Message-ID: <994441ae0710280946s4b19a2c1xa908520d5200d6ea@mail.gmail.com> On 10/28/07, Ralf Corsepius wrote: > On Sun, 2007-10-28 at 12:01 +0100, Patrice Dumas wrote: > > What is your recommentdation? > > /opt > > /var/lib > > /srv > > Depends on what */ltsp is supposed to take. Could you elaborate? > > So far, of these alternative only /var/lib/ltsp would resemble to > something potentially making sense. Mostly NFS mounted root FS for terminals; possibly NBD swapfiles too. -- Dan Young Multnomah ESD - Technology Services 503-257-1562 From pertusus at free.fr Sun Oct 28 16:52:16 2007 From: pertusus at free.fr (Patrice Dumas) Date: Sun, 28 Oct 2007 17:52:16 +0100 Subject: [Fedora-packaging] ltsp root directory In-Reply-To: <1193573845.9878.150.camel@mccallum.corsepiu.local> References: <20071028110112.GA2634@free.fr> <1193573845.9878.150.camel@mccallum.corsepiu.local> Message-ID: <20071028165216.GA2632@free.fr> On Sun, Oct 28, 2007 at 01:17:25PM +0100, Ralf Corsepius wrote: > > What is your recommentdation? > > /opt > > /var/lib > > /srv > > Depends on what */ltsp is supposed to take. Could you elaborate? ltsp5/i386 would hold a complete filesystem exported through nfs to the terminal clients. This filesystem is used as the filesystem for the clients. The idea is to have a fedora install in this filesystem (with a package that allows to create writable files in a rw filesystem and maybe other goodies). (but it could also be an ubuntu fillesystem too ;-). > So far, of these alternative only /var/lib/ltsp would resemble to > something potentially making sense. -- Pat From rc040203 at freenet.de Sun Oct 28 17:07:31 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sun, 28 Oct 2007 18:07:31 +0100 Subject: [Fedora-packaging] ltsp root directory In-Reply-To: <994441ae0710280946s4b19a2c1xa908520d5200d6ea@mail.gmail.com> References: <20071028110112.GA2634@free.fr> <1193573845.9878.150.camel@mccallum.corsepiu.local> <994441ae0710280946s4b19a2c1xa908520d5200d6ea@mail.gmail.com> Message-ID: <1193591251.9878.175.camel@mccallum.corsepiu.local> On Sun, 2007-10-28 at 09:46 -0700, Dan Young wrote: > On 10/28/07, Ralf Corsepius wrote: > > On Sun, 2007-10-28 at 12:01 +0100, Patrice Dumas wrote: > > > What is your recommentdation? > > > /opt > > > /var/lib > > > /srv > > > > Depends on what */ltsp is supposed to take. Could you elaborate? > > > > So far, of these alternative only /var/lib/ltsp would resemble to > > something potentially making sense. > > Mostly NFS mounted root FS for terminals; Hmm, I don't fully understand (I have no clues about ltsp), so let me ask for details: * Are these mount-points or root-filesystems to be mounted (== constant data)? * Is this data which customizable (== configurable)? * Is this data which is automatically generated or constant data to be shipped as part of rpms. * Is this automatically regenerated? * Is this data machine dependent? Depending on the answers to these questions even a directory below /etc/ltsp or /usr/share/ltsp or %{_libdir)/ltsp could make sense. > possibly NBD swapfiles too. Dunno what NBD is, but this sounds like volatile data. Then /var/lib/ltsp (or subdirs thereof) most likely looks like at least a suitable candidate to getting started. Ralf From rc040203 at freenet.de Sun Oct 28 17:11:22 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sun, 28 Oct 2007 18:11:22 +0100 Subject: [Fedora-packaging] ltsp root directory In-Reply-To: <20071028165216.GA2632@free.fr> References: <20071028110112.GA2634@free.fr> <1193573845.9878.150.camel@mccallum.corsepiu.local> <20071028165216.GA2632@free.fr> Message-ID: <1193591482.9878.180.camel@mccallum.corsepiu.local> On Sun, 2007-10-28 at 17:52 +0100, Patrice Dumas wrote: > On Sun, Oct 28, 2007 at 01:17:25PM +0100, Ralf Corsepius wrote: > > > What is your recommentdation? > > > /opt > > > /var/lib > > > /srv > > > > Depends on what */ltsp is supposed to take. Could you elaborate? > > ltsp5/i386 would hold a complete filesystem exported through nfs to > the terminal clients. Are you familiar with /net and autofs (/etc/auto.net)? > This filesystem is used as the filesystem for the > clients. The idea is to have a fedora install in this filesystem (with > a package that allows to create writable files in a rw filesystem and > maybe other goodies). (but it could also be an ubuntu fillesystem > too ;-). OK, our mails crossed, this answers most of my questions. My current vote goes for /var/lib/ltsp. This would allow all ltsp* packages to treat this directory and sub-dirs thereof as their "private play ground". Ralf From pertusus at free.fr Sun Oct 28 17:18:11 2007 From: pertusus at free.fr (Patrice Dumas) Date: Sun, 28 Oct 2007 18:18:11 +0100 Subject: [Fedora-packaging] ltsp root directory In-Reply-To: <1193591251.9878.175.camel@mccallum.corsepiu.local> References: <20071028110112.GA2634@free.fr> <1193573845.9878.150.camel@mccallum.corsepiu.local> <994441ae0710280946s4b19a2c1xa908520d5200d6ea@mail.gmail.com> <1193591251.9878.175.camel@mccallum.corsepiu.local> Message-ID: <20071028171811.GB2632@free.fr> On Sun, Oct 28, 2007 at 06:07:31PM +0100, Ralf Corsepius wrote: > > > > Mostly NFS mounted root FS for terminals; > Hmm, I don't fully understand (I have no clues about ltsp), so let me > ask for details: > > * Are these mount-points or root-filesystems to be mounted (== constant > data)? Yes they are constant from the client point of view. But they may be modified on the server. > * Is this data which customizable (== configurable)? This is a complete filesystem, in this filesystem there is a full FHS tree. > * Is this data which is automatically generated or constant data to be > shipped as part of rpms. It is generated. Plan is more or less to install rpms in the direrctory like a chroot. > * Is this automatically regenerated? The plan is to install it as a rpm chroot, but it will also be configurated, with a file in the *ltsp5/i386/etc/ltsp.conf or the like holding information for all the hosts using this root filesystem. > * Is this data machine dependent? It is an arch dependent chroot (depending on the terminal hardware), so there will be */ltsp5/i386 */ltsp5/ppc .... > Depending on the answers to these questions even a directory > below /etc/ltsp or /usr/share/ltsp or %{_libdir)/ltsp could make sense. It is a full filesystem with its own /etc, /usr/share and so on and so forth. It is more similar with mock chroots in my opinion. With the difference that these chroots are to be NFS exported. > > possibly NBD swapfiles too. > Dunno what NBD is, but this sounds like volatile data. It may hold the swap partition of the terminal, nbd is the protocol used to transparently use it from the terminal, although it is on another host (NBD is Network Block Device). -- Pat From a.badger at gmail.com Sun Oct 28 18:12:29 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sun, 28 Oct 2007 11:12:29 -0700 Subject: [Fedora-packaging] ltsp root directory In-Reply-To: <1193591482.9878.180.camel@mccallum.corsepiu.local> References: <20071028110112.GA2634@free.fr> <1193573845.9878.150.camel@mccallum.corsepiu.local> <20071028165216.GA2632@free.fr> <1193591482.9878.180.camel@mccallum.corsepiu.local> Message-ID: <4724D10D.4010001@gmail.com> Ralf Corsepius wrote: > On Sun, 2007-10-28 at 17:52 +0100, Patrice Dumas wrote: >> This filesystem is used as the filesystem for the >> clients. The idea is to have a fedora install in this filesystem (with >> a package that allows to create writable files in a rw filesystem and >> maybe other goodies). (but it could also be an ubuntu fillesystem >> too ;-). > OK, our mails crossed, this answers most of my questions. > > My current vote goes for /var/lib/ltsp. This would allow all ltsp* > packages to treat this directory and sub-dirs thereof as their "private > play ground". > +1. -Toshio From pertusus at free.fr Wed Oct 31 20:26:44 2007 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 31 Oct 2007 21:26:44 +0100 Subject: [Fedora-packaging] ltsp root directory In-Reply-To: <20071028110112.GA2634@free.fr> References: <20071028110112.GA2634@free.fr> Message-ID: <20071031202644.GB23272@free.fr> On Sun, Oct 28, 2007 at 12:01:12PM +0100, Patrice Dumas wrote: > Hello, > The consensus is going to /var/lib. To clarify, the packages don't put anything in that directory (except maybe subdirectories), but this is used as the default for the ltsp root. If somebody don't want, he just has to modify /etc/ltsp5/ltsp.conf and set the variable to another value. It is used by scripts afterwards, to put stuff in it. -- Pat