From dlutter at redhat.com Tue May 1 01:10:53 2007 From: dlutter at redhat.com (David Lutterkort) Date: Mon, 30 Apr 2007 18:10:53 -0700 Subject: [Fedora-packaging] rubygems guideline Message-ID: <1177981853.25820.68.camel@galia.watzmann.net> Hi, I updated the proposed rubygems guideline [1] with a blurb about packaging the same bits for use as a Gem and as a straight Ruby library. My experimentation indicates that that even works ;) David [1] http://fedoraproject.org/wiki/PackagingDrafts/RubyGems From kevin.kofler at chello.at Tue May 1 03:14:07 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 1 May 2007 03:14:07 +0000 (UTC) Subject: [Fedora-packaging] Cross-compiling guidelines Message-ID: There are at least 2 review requests for cross compilers which have been stuck in FE-GUIDELINES for over a year (to the point where the submitter closed the reports) supposedly waiting for specific guidelines for cross-compiling, so I wonder what happened to those guidelines. Is there any chance some guidelines are going to be voted by the packaging committee or some SIG or both at some point? Or is the consensus now that none are needed? In the first case, I'd like to see something getting done about this sooner rather than later, as I think we lose on useful packages by holding them up forever (and admittedly, I also have an interest in this), in the second case (no guidelines needed) I'll just put the bugs out of FE-GUIDELINES and review them according to the general packaging guidelines and the things interested parties agreed upon on the fedora-extras-list a few months ago. Kevin Kofler From ville.skytta at iki.fi Tue May 1 11:20:07 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Tue, 1 May 2007 14:20:07 +0300 Subject: [Fedora-packaging] Re: missing tomorrow's FPC meeting In-Reply-To: <20070430200443.GG13906@neu.nirvana> References: <1177938190.4283.43.camel@mccallum.corsepiu.local> <20070430200443.GG13906@neu.nirvana> Message-ID: <200705011420.07771.ville.skytta@iki.fi> On Monday 30 April 2007, Axel Thimm wrote: > Hi, > > On Mon, Apr 30, 2007 at 03:03:10PM +0200, Ralf Corsepius wrote: > > Hi, > > > > Due to a public holiday in Germany, I'll be AFK most of the day and > > therefore probably will not be able to attend the FPC meeting. > > > > No matter if it will take place at 17:00 or 16:00 UTC ;) > > > > Ralf > > the same is true for me. Me too. From rdieter at math.unl.edu Tue May 1 12:30:56 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 01 May 2007 07:30:56 -0500 Subject: [Fedora-packaging] Re: Cross-compiling guidelines References: Message-ID: Kevin Kofler wrote: > There are at least 2 review requests for cross compilers which have been > stuck in FE-GUIDELINES for over a year (to the point where the submitter > closed the reports) supposedly waiting for specific guidelines for > cross-compiling, so I wonder what happened to those guidelines. http://fedoraproject.org/wiki/PackagingDrafts/CrossCompilers -- Rex From tcallawa at redhat.com Tue May 1 12:40:46 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 01 May 2007 07:40:46 -0500 Subject: [Fedora-packaging] Re: Cross-compiling guidelines In-Reply-To: References: Message-ID: <1178023246.3609.11.camel@localhost.localdomain> On Tue, 2007-05-01 at 07:30 -0500, Rex Dieter wrote: > Kevin Kofler wrote: > > > There are at least 2 review requests for cross compilers which have been > > stuck in FE-GUIDELINES for over a year (to the point where the submitter > > closed the reports) supposedly waiting for specific guidelines for > > cross-compiling, so I wonder what happened to those guidelines. > > http://fedoraproject.org/wiki/PackagingDrafts/CrossCompilers That draft needs some work. Ralf added notes to each item that essentially says "don't need it. don't want it." I'd tend to agree with him on everything but the package naming (I think having the "cross-" prefix fits in with our existing naming policies), but I'm not married to it. If the people packaging cross toolchains are vehemently against that naming, it would be good to know. ~spot From tibbs at math.uh.edu Tue May 1 16:42:02 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 01 May 2007 11:42:02 -0500 Subject: [Fedora-packaging] Re: Cross-compiling guidelines In-Reply-To: References: Message-ID: >>>>> "RD" == Rex Dieter writes: RD> http://fedoraproject.org/wiki/PackagingDrafts/CrossCompilers That's a really old thing I put together to get some ideas out there. It generated plenty of flames but nobody stepped up to actually produce a useful draft. At least I was trying. There's discussion in http://fedoraproject.org/wiki/Packaging/IRCLog20061128 if anyone really cares. - J< From tcallawa at redhat.com Tue May 1 17:09:21 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 01 May 2007 12:09:21 -0500 Subject: [Fedora-packaging] http://fedoraproject.org/wiki/Packaging/NewMeetingTime In-Reply-To: <1177446532.5956.42.camel@localhost.localdomain> References: <1177443042.5956.38.camel@localhost.localdomain> <1177446532.5956.42.camel@localhost.localdomain> Message-ID: <1178039361.3609.23.camel@localhost.localdomain> European FPC members! Please vote, we want to know what times/days are good for you. ~spot From rc040203 at freenet.de Wed May 2 05:56:44 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 02 May 2007 07:56:44 +0200 Subject: [Fedora-packaging] Re: Cross-compiling guidelines In-Reply-To: <1178023246.3609.11.camel@localhost.localdomain> References: <1178023246.3609.11.camel@localhost.localdomain> Message-ID: <1178085404.4283.231.camel@mccallum.corsepiu.local> On Tue, 2007-05-01 at 07:40 -0500, Tom "spot" Callaway wrote: > On Tue, 2007-05-01 at 07:30 -0500, Rex Dieter wrote: > > Kevin Kofler wrote: > > > > > There are at least 2 review requests for cross compilers which have been > > > stuck in FE-GUIDELINES for over a year (to the point where the submitter > > > closed the reports) supposedly waiting for specific guidelines for > > > cross-compiling, so I wonder what happened to those guidelines. > > > > http://fedoraproject.org/wiki/PackagingDrafts/CrossCompilers > > That draft needs some work. IMO, this draft should be deleted. > Ralf added notes to each item that > essentially says "don't need it. don't want it." I essentially say: Cross toolchains are ordinary applications. There should be no need to special case them. In practice, this is not a much of a problem, with one exception: The GNU toolchains use ${prefix}/${target_alias}/. This directory is not covered by the FHS. Changing the GNU toolchains to use something else, is technically hardly possible (More precisely: It would imply a lot of hard work and can easily evolve into a package maintainer's nightmare). I.e. to cater the GNU toolchains practice, only one addition to the guidelines would be required: - %_prefix/${target_alias} is reserved for cross toolchains targetting target "$target_alias - cross-toolchains must consistently use the same target_alias for all of its components. Another wide area would be "recipes to workaround the various bugs in rpm cross-building triggers". I don't think this should be covered by the FPG. May-be an addendum to the FPG, or a wiki owned and written by the "Embedded SIG" would be appropriate. Better: rpm and redhat-rpm-config should be fixed. > I'd tend to agree with him on everything but the package naming (I think > having the "cross-" prefix fits in with our existing naming policies), > but I'm not married to it. If the people packaging cross toolchains are > vehemently against that naming, it would be good to know. I say: Mandating prefixing with "cross-" is non-sense, like mandating prefixing native tools with "native-" would be. Shall people wanting it use it, I won't. Package names should be "unique" and "sufficiently self- explanatory" - For GNU toolchains, I recommend $target_alias-, but that's just my personal preference. Ralf From kevin.kofler at chello.at Wed May 2 16:46:10 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 2 May 2007 16:46:10 +0000 (UTC) Subject: [Fedora-packaging] Re: Cross-compiling guidelines References: Message-ID: Rex Dieter math.unl.edu> writes: > http://fedoraproject.org/wiki/PackagingDrafts/CrossCompilers My opinion about these: > Naming It's hard to tell the right thing to do here. Some things to consider: * The current cross-compilation packages for the AVR don't have the "cross-" prefix, if you want to mandate it, those packages will have to be renamed. * While I can see the use of the "cross-" prefix for packages like "gcc" or "binutils" which already have a native version (though IMHO "i386-rtems4.7-gcc" is enough to specify that, and it would also have the advantage of fitting with the names of the executables as installed by upstream GCC), packages like "tigcc", "sdcc" or "z88dk" are implicitly cross-compilation packages and definitely don't need a "cross-" prefix. In fact, z88dk and sdcc are already in Fedora with those names, and I don't think adding "cross-" in front would make any sense for these. So all in all I think mandating the "cross-" prefix is not that great an idea, but I'm open to discussion on this point. I'd suggest a guideline like: "If the cross-compiler does not have a native equivalent with the same name, and if the compiler either supports only one target or includes support for all targets in the same package, using the upstream name for the package is sufficient. An example is 'sdcc'. Otherwise, prefix the package name with the target name, e.g. 'avr-gcc' or 'i386-rtems4.7-gcc'." > File Naming I don't think dictating the exact names of files installed into the bindir is a good idea. As in the above case with the package names, I don't think prefixing names which are already unique upstream is a good idea, consider names like "tigcc" or "tprbuilder", they don't conflict with any other package's files. If the names would conflict, e.g. with native tools, again prefixing with the target name is the right thing to do, and in fact what the GNU toolchain already does. > File Locations As Ralf explained, /usr/targetname is what the GNU toolchain uses by default, so if you want anything else, you'll be up for patching the toolchain. A lot of patching. I know what I'm talking about here, TIGCC patches GCC so it can work out of any directory (it doesn't currently support split installations, i.e. the "/usr/{bin,lib,...}/ARCH-ENV" suggestion would need patches to TIGCC too) and that needs a lot of adjustments (patching all the hardcoded paths out of GCC, there's a lot of those, then using a "tigcc" wrapper which among other things passes the correct -B option to GCC to set the real location at runtime). Just changing the hardcoded paths to something different might be easier (than full relocatability as done in TIGCC) though. As for split installations, I don't know, the GNU toolchain does use stuff like prefix/lib/gcc/target/version/ and prefix/libexec/gcc/target/version, but I don't know how hard it is to get it to use _only_ such directories. I think going with a prefix of /usr/targetname is probably easiest, it's the recommended/default way for the GNU toolchain and it's most likely to work with other toolchains too. (It definitely works for TIGCC.) If other toolchains need different directory setups, these can always be looked at on a case-by-case basis (and allowed as alternatives). Another open question is: what does "targetname" have to include, in particular for non-GNU toolchains? Does it have to be a full target triplet, e.g. "m68k-ti-tigcc"? (But "avr-" already isn't...) Otherwise, what parts are required? Is the CPU required (e.g. "m68k-tigcc")? Or would installing to "/usr/tigcc" be OK? My personal opinion is that any target name which uniquely identifies the target is OK, if that's just "avr" or "tigcc", that's OK, if it needs more components (e.g. "i386-rtems4.7" vs. "someothercpu-rtems4.7" or "i386-someotheros"), then these are required. Kevin Kofler From rc040203 at freenet.de Thu May 3 08:55:33 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 03 May 2007 10:55:33 +0200 Subject: [Fedora-packaging] Re: Cross-compiling guidelines In-Reply-To: References: Message-ID: <1178182533.4283.502.camel@mccallum.corsepiu.local> On Wed, 2007-05-02 at 16:46 +0000, Kevin Kofler wrote: > Rex Dieter math.unl.edu> writes: > > http://fedoraproject.org/wiki/PackagingDrafts/CrossCompilers > > Another open question is: what does "targetname" have to include, in particular > for non-GNU toolchains? Does it have to be a full target triplet, Generally speaking, the "targetname" needs to be sufficiently "unique" to identify the target. In practice, this means it needs to supported by config.sub, which is supposed to return the correct target triplet when being invoked with a "target_alias"[1]. > e.g. "m68k-ti-tigcc"? TIGCC is problematic, but helping you here would require to look into your sources (see below). > (But "avr-" already isn't...) Well, I know and consider this to be a design flaw. avr-elf would have been better ... (see below) > Otherwise, what parts are > required? Is the CPU required (e.g. "m68k-tigcc")? Or would installing > to "/usr/tigcc" be OK? My personal opinion is that any target name which > uniquely identifies the target is OK, if that's just "avr" or "tigcc", that's > OK, if it needs more components (e.g. "i386-rtems4.7" > vs. "someothercpu-rtems4.7" or "i386-someotheros"), then these are required. OK, some background about the target triplet: >From a user's side, each target is identified by a target-id-string (often called target-alias), e.g. i386-rtems4.7 Inside of autoconf based configurations (e.g. in binutils, GCC, gdb) each target-alias is expanded into a target-triplet (by config.sub and config.guess[1]), consisting of _exactly: 3 fields separated by "-" delimiters (often referred to as arch-vendor-os) Each of these target triplets must be sufficiently unique. The traditional definition of the target triplet had been: ARCHITECTURE-MANUFACTURER-OS with ARCHITECTURE ... target architecture MANUFACTURER ... target HW manufacturer OS ... target OS e.g. sparc-sun-sunos4.2 This applied well to the situation when the target-triplet had been introduced, but this definition has evolved (some say abused): * The definition of ARCHITECTURE is not clear and leaves a lot of room for interpretation (Is an x86_64 an i386? Is i386 a family?) Nowadays, toolchain vendors set it to what meets their demands best. * HW manufacturers have mushroomed, so tying a particular toolchain to a particular HW manufacturer had been found to be impractical (i386-delldimension5100-fedora?). This resulted into "MANUFACTURER" having hardly been used in useful ways anywhere and simply being carried around. Linux vendors started to use it to put their brand into it (*-redhat-*), most other vendors simply "don't use it" (i.e. are using the implict default" - in most cases: "unknown"). * With regard to OS, the problem occurred that OSes (esp. Linux) have changed in incompatible ways. Toolchain suppliers had to find ways to reflect such changes into the target triplet to sufficiently denote such incompatibilties. The OS field had been found to be the most practical approach and nowadays is widely used for this purpose. Typical changes of this kind had been: - Changing the object format (Linux: a.out -> coff -> elf) - Changing libc (Linux: libc4 -> libc5 -> libc6 (aka glibc6)) - API changes (RTEMS: rtems, Solaris: solaris) - Political/branding issues ("Linux" vs. Linux/GNU, "SunOS" vs. "Solaris") - OS variants (Linux: e.g. uclinux) - Alternative libcs (Linux: newlib vs. glibc.) Esp. on Linux this all had resulted into a pretty large series of "canonicalization triplet" changes over the years. This all is more or less without any impact on normal users, except for one situation: Cross compilation. GNU conventions are use "target-alias"-prefixed binaries for cross-compilation to allow installation of several toolchains in parallel and mixing native and cross compilation in one package. Somewhat oversimplified, autoconf uses the rule "if --host and --build are different, then a package is being cross compiled" (=> search from "host-alias"-prefixed tools instead of non-prefixed tools, e.g. search for "m68k-rtems4.8-gcc" instead of "gcc") Back to your questions: - avr: Using a target alias of "avr" is sufficient at this point in time, because its toolchain doesn't have a sufficiently long history for a need for more. The situation the avr is in is not unique for new targets, but I consider this to be a typical beginner's fault, they'll probably regret in longer terms. - tigcc: I don't know. If I understand correctly, your tigcc is a fork from GCC. I.e. it can use any arbitrary target-alias as long as its binaries' names do not clash with GCC. If they can clash, you must use different target-identifiers. If tigcc is a standard GCC with "some architectures" having been added which are not present in the FSF's GCC, then you can chose whatever you find appropriate, because its binaries can't clash with those of the FSF's GCC. If its a "value added/extended GCC", the least risky approach would be best to use -ti- (i.e. to set "vendor"). The even better approach would be to have your changes integrated into upstream (FSF-GCC). Ralf [1] config.sub expands a target-alias into a full target-triplet using a couple of "implicit conventions" having accumulated over time (have a look into it for details). e.g. # ./config.sub avr-rtems4.8 avr-unknown-rtems4.8 # ./config.sub avr avr-unknown-none (autoconf) configure scripts and GCC internally use the full target-triplet and individual fields of the triplet. From kevin.kofler at chello.at Thu May 3 17:03:26 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 3 May 2007 17:03:26 +0000 (UTC) Subject: [Fedora-packaging] Re: Cross-compiling guidelines References: <1178182533.4283.502.camel@mccallum.corsepiu.local> Message-ID: Ralf Corsepius freenet.de> writes: > OK, some background about the target triplet: I knew most of this already, actually. It doesn't quite answer my question though. ;-) > - tigcc: I don't know. If I understand correctly, your tigcc is a fork > from GCC. I.e. it can use any arbitrary target-alias as long as its > binaries' names do not clash with GCC. If they can clash, you must use > different target-identifiers. If tigcc is a standard GCC with "some > architectures" having been added which are not present in the FSF's GCC, > then you can chose whatever you find appropriate, because its binaries > can't clash with those of the FSF's GCC. TIGCC only needs need 2 binaries in the PATH (this can be done e.g. by symlinking/copying/moving to /usr/bin): tigcc and tprbuilder. These are both TIGCC-specific, so no target prefix is needed. (tprbuilder stands for "TIGCC Project Builder" and compiles .tpr project files, which are only used by the TIGCC IDEs, i.e. TIGCC IDE for Windows and KTIGCC.) Our GCC is installed into $TIGCC/bin/gcc, where $TIGCC currently defaults to /usr/local/tigcc, but I want to change that, and thus I need to know whether /usr/tigcc is going to cut it or whether I should use something like /usr/m68k-ti-tigcc. If the environment variable is a problem, I can also pretty easily change the tools which currently use $TIGCC to use a default if the environment variable is not set, which would of course "happen to" be the path the Fedora package uses. ;-) Similarly, we have $TIGCC/bin/cc1 and $TIGCC/bin/as, and our non-GNU (but GPL) toolchain components are also in $TIGCC/bin. As this is within the target prefix (directory), and need not be in the PATH, the executable names need not be prefixed (in the file name). So the only place where the target name is relevant at all is the name of the $TIGCC directory. Internally, GCC and GNU as are being configured for a m68k-coff target, but due to how TIGCC's patched GCC searches for its components, a conflict with an unpatched m68k-coff toolchain is very unlikely. (And if it did happen, it would be a TIGCC bug I'd fix.) The unpatched m68k-coff toolchain won't accidentally find TIGCC's components because they're not in the PATH nor in its search path, the TIGCC toolchain won't accidentally find an unpatched m68k-coff toolchain's components because it only searches in the prefix explicitly passed from the "tigcc" wrapper to GCC, which is currently the contents of the $TIGCC environment variable. The internal triplet name "m68k-coff" only shows up in --version output. Kevin Kofler From jspaleta at gmail.com Sat May 5 03:30:14 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 4 May 2007 19:30:14 -0800 Subject: [Fedora-packaging] Pulling with bzr to create source tarballs. Message-ID: <604aa7910705042030i3c01df2et6f3e6a4f2455436@mail.gmail.com> Good Morning Campers, It appears that pulling from bzr to produce a source tarball can not be done in a way that preserves file timestamps. This makes it impossible to easily verify the md5sum of a tarball created this way. The review guidance implies that that a comment block in the spec file needs to provide enough information to recreate and verify such a tarball. Unfortunately for bzr, the verification of the tarball will always fail due to the timestamp issue. As a workaround, i suggest that for tarballs built from a bzr export that the spec file include a note that the contents of the tarball must be verified individually, and that a note concerning bzr's inability to preserve timestamps (and the dire consequences of that) be added to the code control related review guidance. For reference see the discussion in: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235191 I have manually verified that the contents of the included source1 tarball match the files pulled from call to bzr in the specfile comment block. and for bzr's plan for timestamps: https://blueprints.launchpad.net/bzr/+spec/export-original-timestamps -jef"why am i not drinking tequila right now?"spaleta From jonathan.underwood at gmail.com Mon May 7 15:55:14 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Mon, 7 May 2007 16:55:14 +0100 Subject: [Fedora-packaging] Packaging guidelines for Emacsen add-on packages Message-ID: <645d17210705070855j1c76a34eoc4f9f65cae2766ec@mail.gmail.com> Dear Packaging Committee, I have placed a draft Guidelines document on the wiki for your consideration. This document covers the packaging of Emacs and XEmacs add-on packages, and provides two template spec files with the intention of lowering the inertial barrier to developing packages for (X)Emacs. The doc can be found here: http://fedoraproject.org/wiki/PackagingDrafts/EmacsenAddOns And I have added it to the table here: http://fedoraproject.org/wiki/PackagingDrafts/DraftsTodo This document doesn't attempt to change guidelines in any way, but rather clarify the situation as presented in the Package Naming Guidelines, and codify them in the form of spec templates. Comments gladly received! Best wishes, Jonathan From ville.skytta at iki.fi Mon May 7 18:57:07 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Mon, 7 May 2007 21:57:07 +0300 Subject: [Fedora-packaging] Packaging guidelines for Emacsen add-on packages In-Reply-To: <645d17210705070855j1c76a34eoc4f9f65cae2766ec@mail.gmail.com> References: <645d17210705070855j1c76a34eoc4f9f65cae2766ec@mail.gmail.com> Message-ID: <200705072157.08023.ville.skytta@iki.fi> On Monday 07 May 2007, Jonathan Underwood wrote: > Dear Packaging Committee, > > I have placed a draft Guidelines document on the wiki for your > consideration. This document covers the packaging of Emacs and XEmacs > add-on packages, and provides two template spec files with the > intention of lowering the inertial barrier to developing packages for > (X)Emacs. Thanks. > Comments gladly received! Quickly reading through it, here's a couple. 1) I think cases where install time dependencies on plain "emacs" or "xemacs" are desirable are very rare. The usual problem with those is that they bind the add-on packages to the corresponding full featured variants, ie. ones built with X etc, so one can't use them with only the -nox variant installed. That's why I addded a virtual "xemacs(bin)" Provides to the xemacs and xemacs-nox packages - that'd be a better thing to have a dependency on than eg. "xemacs" unless the full featured GUI version is specifically required. The emacs packages don't have that functionality (yet?), so I think the best thing for them for now would be to have a dependency on emacs-common instead of emacs or emacs-nox. 2) At least in the XEmacs case, the dependency on xemacs(bin) should be versioned, like "Requires: xemacs(bin) >= $evr_of_xemacs_used_to_build_the_package". The xemacs-bytecompiled *.elc files are in the vast majority of cases forwards compatible, but much less often backwards compatible. See the xemacs-packages-base and xemacs-packages-extras packages for examples. (Hm, I see those have deps on xemacs-common instead of xemacs(bin), will have a look.) From jonathan.underwood at gmail.com Mon May 7 21:43:46 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Mon, 7 May 2007 22:43:46 +0100 Subject: [Fedora-packaging] Packaging guidelines for Emacsen add-on packages In-Reply-To: <200705072157.08023.ville.skytta@iki.fi> References: <645d17210705070855j1c76a34eoc4f9f65cae2766ec@mail.gmail.com> <200705072157.08023.ville.skytta@iki.fi> Message-ID: <645d17210705071443x4298217bt69fc8c86c187f428@mail.gmail.com> On 07/05/07, Ville Skytt? wrote: > > Comments gladly received! > > Quickly reading through it, here's a couple. > Thanks for taking a look, Ville. I'll incoorporate your suggestions in a couple of days, once other people have also commented. A couple of questions though: > 1) I think cases where install time dependencies on plain "emacs" or "xemacs" > are desirable are very rare. The usual problem with those is that they bind > the add-on packages to the corresponding full featured variants, ie. ones > built with X etc, so one can't use them with only the -nox variant installed. > That's why I addded a virtual "xemacs(bin)" Provides to the xemacs and > xemacs-nox packages - that'd be a better thing to have a dependency on than > eg. "xemacs" unless the full featured GUI version is specifically required. OK, I'll incoorporate that into the templates and make a note about it. Can I ask though - there's no special meaning given to parentheses in Provides: foo(bar) is there? > The emacs packages don't have that functionality (yet?), so I think the best > thing for them for now would be to have a dependency on emacs-common instead > of emacs or emacs-nox. > Yes; I checked and both emacs and emacs-nox Require: emacs-common so that would work. I will open a bugzilla RFE asking for a virtual Provides: emacs(bin) though for the future, I think that's a good idea. > 2) At least in the XEmacs case, the dependency on xemacs(bin) should be > versioned, like "Requires: xemacs(bin) >= > $evr_of_xemacs_used_to_build_the_package". The xemacs-bytecompiled *.elc > files are in the vast majority of cases forwards compatible, but much less > often backwards compatible. See the xemacs-packages-base and > xemacs-packages-extras packages for examples. (Hm, I see those have deps on > xemacs-common instead of xemacs(bin), will have a look.) Yes, I could expliti#ly add mention of that. I had assumed that would fall within a packagers general knowledge as it's not especially significant to X#(X)Emacs. But, no harm adding it anyway, you're right. Thanks again for the input, Jonathan. From jonathan.underwood at gmail.com Mon May 7 22:22:49 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Mon, 7 May 2007 23:22:49 +0100 Subject: [Fedora-packaging] Packaging guidelines for Emacsen add-on packages In-Reply-To: <645d17210705071443x4298217bt69fc8c86c187f428@mail.gmail.com> References: <645d17210705070855j1c76a34eoc4f9f65cae2766ec@mail.gmail.com> <200705072157.08023.ville.skytta@iki.fi> <645d17210705071443x4298217bt69fc8c86c187f428@mail.gmail.com> Message-ID: <645d17210705071522n23ecc84ei5ada7a7d4f1f4245@mail.gmail.com> To reply to my own post.. On 07/05/07, Jonathan Underwood wrote: > > The emacs packages don't have that functionality (yet?), so I think the best > > thing for them for now would be to have a dependency on emacs-common instead > > of emacs or emacs-nox. > > > > Yes; I checked and both emacs and emacs-nox Require: emacs-common so > that would work. Actually, thinking more about it, having a Requires:emacs-common is sub-optimal, as the user who oesn't have any emacs package installed could install the add-on, which would pull in emacs-commonm, but not emacs or emacs-nox. > > I will open a bugzilla RFE asking for a virtual Provides: emacs(bin) > though for the future, I think that's a good idea. > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=239374 Jonathan. From ville.skytta at iki.fi Mon May 7 22:44:35 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Tue, 8 May 2007 01:44:35 +0300 Subject: [Fedora-packaging] Packaging guidelines for Emacsen add-on packages In-Reply-To: <645d17210705071443x4298217bt69fc8c86c187f428@mail.gmail.com> References: <645d17210705070855j1c76a34eoc4f9f65cae2766ec@mail.gmail.com> <200705072157.08023.ville.skytta@iki.fi> <645d17210705071443x4298217bt69fc8c86c187f428@mail.gmail.com> Message-ID: <200705080144.35416.ville.skytta@iki.fi> On Tuesday 08 May 2007, Jonathan Underwood wrote: > Can I ask though - there's no special meaning given to parentheses in > Provides: foo(bar) is there? No, it's just a notion commonly used in various "virtual" packages, and may help distinguishing them from real package names which are unlikely to contain parens. From ville.skytta at iki.fi Mon May 7 22:53:08 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Tue, 8 May 2007 01:53:08 +0300 Subject: [Fedora-packaging] Packaging guidelines for Emacsen add-on packages In-Reply-To: <645d17210705071522n23ecc84ei5ada7a7d4f1f4245@mail.gmail.com> References: <645d17210705070855j1c76a34eoc4f9f65cae2766ec@mail.gmail.com> <645d17210705071443x4298217bt69fc8c86c187f428@mail.gmail.com> <645d17210705071522n23ecc84ei5ada7a7d4f1f4245@mail.gmail.com> Message-ID: <200705080153.08476.ville.skytta@iki.fi> On Tuesday 08 May 2007, Jonathan Underwood wrote: > > Actually, thinking more about it, having a Requires:emacs-common is > sub-optimal, as the user who oesn't have any emacs package installed > could install the add-on, which would pull in emacs-commonm, but not > emacs or emacs-nox. That's right, but IMHO it's the lesser evil when compared to insisting on a particular flavour of the actual emacs binary. Mileages vary and I'm not going to insist on that though ;), especially because: > > I will open a bugzilla RFE asking for a virtual Provides: emacs(bin) > > though for the future, I think that's a good idea. > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=239374 Thanks, added a comment there. From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Tue May 8 08:38:00 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Tue, 8 May 2007 10:38:00 +0200 Subject: [Fedora-packaging] Requires: initscripts? Message-ID: <20070508103800.5771dfe0@python3.es.egwn.lan> Hi, I've never added "Requires: initscripts" to packages which contain an init script before. I've now been asked to in this review : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=233455 I like to avoid as many explicit requirements as possible, and in this particular case, the "require packages owning parent directories of our files and directories" of recent rpm versions (unfortunately not in Fedora, though IIRC) would take care of things. So my question : As long as the Requires(...) for the scriplets are fine in order to get the package properly installed, updated and erased, do we still need to add that explicit requirement? I would say we don't, but I prefer asking to be sure... Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 6 (Zod) - Linux kernel 2.6.20-1.2948.fc6 Load : 0.34 0.48 0.47 From Axel.Thimm at ATrpms.net Tue May 8 09:40:18 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 8 May 2007 11:40:18 +0200 Subject: [Fedora-packaging] Re: Requires: initscripts? In-Reply-To: <20070508103800.5771dfe0@python3.es.egwn.lan> References: <20070508103800.5771dfe0@python3.es.egwn.lan> Message-ID: <20070508094018.GE26342@neu.nirvana> On Tue, May 08, 2007 at 10:38:00AM +0200, Matthias Saou wrote: > Hi, > > I've never added "Requires: initscripts" to packages which contain an > init script before. I've now been asked to in this review : > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=233455 > > I like to avoid as many explicit requirements as possible, and in this > particular case, the "require packages owning parent directories of our > files and directories" of recent rpm versions (unfortunately not in > Fedora, though IIRC) would take care of things. > > So my question : As long as the Requires(...) for the scriplets are fine > in order to get the package properly installed, updated and erased, do > we still need to add that explicit requirement? > > I would say we don't, but I prefer asking to be sure... > > Matthias Doesn't initscripts belong to the always-assume-installed-set-of-packages- so-don't-redundandly-require-it-unless-you-need-a-versioned-dependency? Just like gcc, make etc? -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Tue May 8 09:52:04 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Tue, 8 May 2007 11:52:04 +0200 Subject: [Fedora-packaging] Re: Requires: initscripts? In-Reply-To: <20070508094018.GE26342@neu.nirvana> References: <20070508103800.5771dfe0@python3.es.egwn.lan> <20070508094018.GE26342@neu.nirvana> Message-ID: <20070508115204.4f13aaeb@python3.es.egwn.lan> Axel Thimm wrote : > On Tue, May 08, 2007 at 10:38:00AM +0200, Matthias Saou wrote: > > Hi, > > > > I've never added "Requires: initscripts" to packages which contain an > > init script before. I've now been asked to in this review : > > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=233455 > > > > I like to avoid as many explicit requirements as possible, and in this > > particular case, the "require packages owning parent directories of our > > files and directories" of recent rpm versions (unfortunately not in > > Fedora, though IIRC) would take care of things. > > > > So my question : As long as the Requires(...) for the scriplets are fine > > in order to get the package properly installed, updated and erased, do > > we still need to add that explicit requirement? > > > > I would say we don't, but I prefer asking to be sure... > > > > Matthias > > Doesn't initscripts belong to the always-assume-installed-set-of-packages- > so-don't-redundandly-require-it-unless-you-need-a-versioned-dependency? > > Just like gcc, make etc? That would be the list of assumed _build_ requirements. I was asking about a normal requirement for a package containing an init script in /etc/rc.d/init.d/. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 6 (Zod) - Linux kernel 2.6.20-1.2948.fc6 Load : 1.04 2.30 2.26 From Axel.Thimm at ATrpms.net Tue May 8 09:57:13 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 8 May 2007 11:57:13 +0200 Subject: [Fedora-packaging] Re: Requires: initscripts? In-Reply-To: <20070508115204.4f13aaeb@python3.es.egwn.lan> References: <20070508103800.5771dfe0@python3.es.egwn.lan> <20070508094018.GE26342@neu.nirvana> <20070508115204.4f13aaeb@python3.es.egwn.lan> Message-ID: <20070508095713.GF26342@neu.nirvana> On Tue, May 08, 2007 at 11:52:04AM +0200, Matthias Saou wrote: > Axel Thimm wrote : > > > On Tue, May 08, 2007 at 10:38:00AM +0200, Matthias Saou wrote: > > > Hi, > > > > > > I've never added "Requires: initscripts" to packages which contain an > > > init script before. I've now been asked to in this review : > > > > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=233455 > > > > > > I like to avoid as many explicit requirements as possible, and in this > > > particular case, the "require packages owning parent directories of our > > > files and directories" of recent rpm versions (unfortunately not in > > > Fedora, though IIRC) would take care of things. > > > > > > So my question : As long as the Requires(...) for the scriplets are fine > > > in order to get the package properly installed, updated and erased, do > > > we still need to add that explicit requirement? > > > > > > I would say we don't, but I prefer asking to be sure... > > > > > > Matthias > > > > Doesn't initscripts belong to the always-assume-installed-set-of-packages- > > so-don't-redundandly-require-it-unless-you-need-a-versioned-dependency? > > > > Just like gcc, make etc? > > That would be the list of assumed _build_ requirements. I was asking > about a normal requirement for a package containing an init script > in /etc/rc.d/init.d/. Yes, you're right. But unless this package is installed in a chroot w/o kernel and friends you always have initscripts present. OTOH it isn't quite wrong to run daemons in chroots where appropriate. Does your script make any actual use of initscripts (like sourcing in parts of it) or is this just the parent directory ownership issue? -- 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 thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Tue May 8 10:02:35 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Tue, 8 May 2007 12:02:35 +0200 Subject: [Fedora-packaging] Re: Requires: initscripts? In-Reply-To: <20070508095713.GF26342@neu.nirvana> References: <20070508103800.5771dfe0@python3.es.egwn.lan> <20070508094018.GE26342@neu.nirvana> <20070508115204.4f13aaeb@python3.es.egwn.lan> <20070508095713.GF26342@neu.nirvana> Message-ID: <20070508120235.500bde46@python3.es.egwn.lan> Axel Thimm wrote : > > > Doesn't initscripts belong to the always-assume-installed-set-of-packages- > > > so-don't-redundandly-require-it-unless-you-need-a-versioned-dependency? > > > > > > Just like gcc, make etc? > > > > That would be the list of assumed _build_ requirements. I was asking > > about a normal requirement for a package containing an init script > > in /etc/rc.d/init.d/. > > Yes, you're right. > > But unless this package is installed in a chroot w/o kernel and > friends you always have initscripts present. OTOH it isn't quite wrong > to run daemons in chroots where appropriate. > > Does your script make any actual use of initscripts (like sourcing in > parts of it) or is this just the parent directory ownership issue? Nothing fancy. Just a simple "service" to have run on startup, control with chkconfig and service. I don't think "Requires: initscripts" would improve nor fix anything, but I wanted an authoritative answer to be 100% sure :-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 6 (Zod) - Linux kernel 2.6.20-1.2948.fc6 Load : 2.57 1.55 1.65 From Axel.Thimm at ATrpms.net Tue May 8 11:10:30 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 8 May 2007 13:10:30 +0200 Subject: [Fedora-packaging] Re: Requires: initscripts? In-Reply-To: <20070508120235.500bde46@python3.es.egwn.lan> References: <20070508103800.5771dfe0@python3.es.egwn.lan> <20070508094018.GE26342@neu.nirvana> <20070508115204.4f13aaeb@python3.es.egwn.lan> <20070508095713.GF26342@neu.nirvana> <20070508120235.500bde46@python3.es.egwn.lan> Message-ID: <20070508111030.GI26342@neu.nirvana> On Tue, May 08, 2007 at 12:02:35PM +0200, Matthias Saou wrote: > Axel Thimm wrote : > > > > > Doesn't initscripts belong to the always-assume-installed-set-of-packages- > > > > so-don't-redundandly-require-it-unless-you-need-a-versioned-dependency? > > > > > > > > Just like gcc, make etc? > > > > > > That would be the list of assumed _build_ requirements. I was asking > > > about a normal requirement for a package containing an init script > > > in /etc/rc.d/init.d/. > > > > Yes, you're right. > > > > But unless this package is installed in a chroot w/o kernel and > > friends you always have initscripts present. OTOH it isn't quite wrong > > to run daemons in chroots where appropriate. > > > > Does your script make any actual use of initscripts (like sourcing in > > parts of it) or is this just the parent directory ownership issue? > > Nothing fancy. Just a simple "service" to have run on startup, control > with chkconfig and service. I don't think "Requires: initscripts" would > improve nor fix anything, but I wanted an authoritative answer to be > 100% sure :-) Well, the authoritative answer might be that accroding to the guidelines you should add it, but given the precedent of a ton of other packages not doing it, either the ton of packages are broken (unlikely) or the guidelines need adjustment/exceptions. So if this is stalling your work we should have a quickvote on list or in the channel today. Perhaps it would help if you submit a diff to the guideline text. -- 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 thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Tue May 8 11:36:06 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Tue, 8 May 2007 13:36:06 +0200 Subject: [Fedora-packaging] Re: Requires: initscripts? In-Reply-To: <20070508111030.GI26342@neu.nirvana> References: <20070508103800.5771dfe0@python3.es.egwn.lan> <20070508094018.GE26342@neu.nirvana> <20070508115204.4f13aaeb@python3.es.egwn.lan> <20070508095713.GF26342@neu.nirvana> <20070508120235.500bde46@python3.es.egwn.lan> <20070508111030.GI26342@neu.nirvana> Message-ID: <20070508133606.550b5bfa@python3.es.egwn.lan> Axel Thimm wrote : > > Nothing fancy. Just a simple "service" to have run on startup, control > > with chkconfig and service. I don't think "Requires: initscripts" would > > improve nor fix anything, but I wanted an authoritative answer to be > > 100% sure :-) > > Well, the authoritative answer might be that accroding to the > guidelines you should add it, but given the precedent of a ton of > other packages not doing it, either the ton of packages are broken > (unlikely) or the guidelines need adjustment/exceptions. > > So if this is stalling your work we should have a quickvote on list or > in the channel today. Perhaps it would help if you submit a diff to > the guideline text. Well, I'm not in favour of adding the requirement, so I'm not really wanting to submit guideline changes either ;-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 6 (Zod) - Linux kernel 2.6.20-1.2948.fc6 Load : 0.62 0.75 1.25 From Axel.Thimm at ATrpms.net Tue May 8 11:38:02 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 8 May 2007 13:38:02 +0200 Subject: [Fedora-packaging] Re: Requires: initscripts? In-Reply-To: <20070508133606.550b5bfa@python3.es.egwn.lan> References: <20070508103800.5771dfe0@python3.es.egwn.lan> <20070508094018.GE26342@neu.nirvana> <20070508115204.4f13aaeb@python3.es.egwn.lan> <20070508095713.GF26342@neu.nirvana> <20070508120235.500bde46@python3.es.egwn.lan> <20070508111030.GI26342@neu.nirvana> <20070508133606.550b5bfa@python3.es.egwn.lan> Message-ID: <20070508113802.GJ26342@neu.nirvana> On Tue, May 08, 2007 at 01:36:06PM +0200, Matthias Saou wrote: > Axel Thimm wrote : > > > > Nothing fancy. Just a simple "service" to have run on startup, control > > > with chkconfig and service. I don't think "Requires: initscripts" would > > > improve nor fix anything, but I wanted an authoritative answer to be > > > 100% sure :-) > > > > Well, the authoritative answer might be that accroding to the > > guidelines you should add it, but given the precedent of a ton of > > other packages not doing it, either the ton of packages are broken > > (unlikely) or the guidelines need adjustment/exceptions. > > > > So if this is stalling your work we should have a quickvote on list or > > in the channel today. Perhaps it would help if you submit a diff to > > the guideline text. > > Well, I'm not in favour of adding the requirement, so I'm not really > wanting to submit guideline changes either ;-) But, if I understand you correctly the current guidelines would force you to add it, no? -- 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 thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Tue May 8 11:48:29 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Tue, 8 May 2007 13:48:29 +0200 Subject: [Fedora-packaging] Re: Requires: initscripts? In-Reply-To: <20070508113802.GJ26342@neu.nirvana> References: <20070508103800.5771dfe0@python3.es.egwn.lan> <20070508094018.GE26342@neu.nirvana> <20070508115204.4f13aaeb@python3.es.egwn.lan> <20070508095713.GF26342@neu.nirvana> <20070508120235.500bde46@python3.es.egwn.lan> <20070508111030.GI26342@neu.nirvana> <20070508133606.550b5bfa@python3.es.egwn.lan> <20070508113802.GJ26342@neu.nirvana> Message-ID: <20070508134829.7703742c@python3.es.egwn.lan> Axel Thimm wrote : > On Tue, May 08, 2007 at 01:36:06PM +0200, Matthias Saou wrote: > > Axel Thimm wrote : > > > > > > Nothing fancy. Just a simple "service" to have run on startup, control > > > > with chkconfig and service. I don't think "Requires: initscripts" would > > > > improve nor fix anything, but I wanted an authoritative answer to be > > > > 100% sure :-) > > > > > > Well, the authoritative answer might be that accroding to the > > > guidelines you should add it, but given the precedent of a ton of > > > other packages not doing it, either the ton of packages are broken > > > (unlikely) or the guidelines need adjustment/exceptions. > > > > > > So if this is stalling your work we should have a quickvote on list or > > > in the channel today. Perhaps it would help if you submit a diff to > > > the guideline text. > > > > Well, I'm not in favour of adding the requirement, so I'm not really > > wanting to submit guideline changes either ;-) > > But, if I understand you correctly the current guidelines would force > you to add it, no? Nope. The current guidelines don't mention anything about this AFAICT. It's the reviewer of my package who thinks it should be added, and had it confirmed by someone on IRC (which isn't something I'd consider trustworthy!). Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 6 (Zod) - Linux kernel 2.6.20-1.2948.fc6 Load : 0.57 0.47 0.76 From Axel.Thimm at ATrpms.net Tue May 8 11:57:40 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 8 May 2007 13:57:40 +0200 Subject: [Fedora-packaging] Re: Requires: initscripts? In-Reply-To: <20070508134829.7703742c@python3.es.egwn.lan> References: <20070508103800.5771dfe0@python3.es.egwn.lan> <20070508094018.GE26342@neu.nirvana> <20070508115204.4f13aaeb@python3.es.egwn.lan> <20070508095713.GF26342@neu.nirvana> <20070508120235.500bde46@python3.es.egwn.lan> <20070508111030.GI26342@neu.nirvana> <20070508133606.550b5bfa@python3.es.egwn.lan> <20070508113802.GJ26342@neu.nirvana> <20070508134829.7703742c@python3.es.egwn.lan> Message-ID: <20070508115740.GN26342@neu.nirvana> On Tue, May 08, 2007 at 01:48:29PM +0200, Matthias Saou wrote: > Axel Thimm wrote : > > > On Tue, May 08, 2007 at 01:36:06PM +0200, Matthias Saou wrote: > > > Axel Thimm wrote : > > > > > > > > Nothing fancy. Just a simple "service" to have run on startup, control > > > > > with chkconfig and service. I don't think "Requires: initscripts" would > > > > > improve nor fix anything, but I wanted an authoritative answer to be > > > > > 100% sure :-) > > > > > > > > Well, the authoritative answer might be that accroding to the > > > > guidelines you should add it, but given the precedent of a ton of > > > > other packages not doing it, either the ton of packages are broken > > > > (unlikely) or the guidelines need adjustment/exceptions. > > > > > > > > So if this is stalling your work we should have a quickvote on list or > > > > in the channel today. Perhaps it would help if you submit a diff to > > > > the guideline text. > > > > > > Well, I'm not in favour of adding the requirement, so I'm not really > > > wanting to submit guideline changes either ;-) > > > > But, if I understand you correctly the current guidelines would force > > you to add it, no? > > Nope. The current guidelines don't mention anything about this AFAICT. > It's the reviewer of my package who thinks it should be added, and had > it confirmed by someone on IRC (which isn't something I'd consider > trustworthy!). Well, we do have guidelines on how to deal with file/directory ownerships that try to manage not to orphan anything and not to over-own as well. http://fedoraproject.org/wiki/Packaging/Guidelines#head-a5931a7372c4a00065713430984fa5875513e6d4 But I guess it's a matter of interpretation as well as understanding that guidelines != law. -- 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 Tue May 8 14:28:02 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 08 May 2007 09:28:02 -0500 Subject: [Fedora-packaging] Requires: initscripts? In-Reply-To: <20070508103800.5771dfe0@python3.es.egwn.lan> References: <20070508103800.5771dfe0@python3.es.egwn.lan> Message-ID: <1178634483.3661.78.camel@localhost.localdomain> On Tue, 2007-05-08 at 10:38 +0200, Matthias Saou wrote: > Hi, > > I've never added "Requires: initscripts" to packages which contain an > init script before. I've now been asked to in this review : kernel requires initscripts. You'd be hard-pressed to find a proper Fedora install that didn't have initscripts. I think this is one of those "use your best judgement" issues here. If it were my package, I wouldn't add it. It's a tiny step from Requires: initscripts to Requires: kernel. ~spot From tibbs at math.uh.edu Tue May 8 15:59:35 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 08 May 2007 10:59:35 -0500 Subject: [Fedora-packaging] Requires: initscripts? In-Reply-To: <1178634483.3661.78.camel@localhost.localdomain> References: <20070508103800.5771dfe0@python3.es.egwn.lan> <1178634483.3661.78.camel@localhost.localdomain> Message-ID: >>>>> "TC" == Tom \"spot\" Callaway writes: TC> kernel requires initscripts. You'd be hard-pressed to find a TC> proper Fedora install that didn't have initscripts. Packages don't have requirements on "filesystem" either. The initscripts thing might get interesting once we start moving away from old-school init. And right now there are people running "Fedora-like" distros that don't have initscripts, but I'm not sure there's much point in going out of your way to cater to them. Besides, if things change so that it's required, it will be trivial to add. - J< From enrico.scholz at informatik.tu-chemnitz.de Tue May 8 16:06:39 2007 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Tue, 08 May 2007 18:06:39 +0200 Subject: [Fedora-packaging] Re: Requires: initscripts? In-Reply-To: <20070508103800.5771dfe0@python3.es.egwn.lan> (Matthias Saou's message of "Tue, 8 May 2007 10:38:00 +0200") References: <20070508103800.5771dfe0@python3.es.egwn.lan> Message-ID: <87hcqncnao.fsf@fc5.bigo.ensc.de> Matthias Saou writes: > I've never added "Requires: initscripts" to packages which contain an > init script before. When your initscripts do not work without /etc/init.d/functions and the initscripts are an essential part of your package (e.g. not sample %doc), you have to add corresponding Requires: entries. > So my question : As long as the Requires(...) for the scriplets are fine > in order to get the package properly installed, updated and erased, do > we still need to add that explicit requirement? It depends how far we want to abuse rpm bugs/missing features. With current rpm, it is fine to add only the tagged Requires(...) because they implicate an untagged Requires: too. The feature, that deps from Requires(post/preun): can be removed after installation, and will be reinstalled at removal, is not implemented, afaik. Enrico From enrico.scholz at informatik.tu-chemnitz.de Tue May 8 17:05:07 2007 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Tue, 08 May 2007 19:05:07 +0200 Subject: [Fedora-packaging] Re: Requires: initscripts? In-Reply-To: (Jason L. Tibbitts, III's message of "08 May 2007 10:59:35 -0500") References: <20070508103800.5771dfe0@python3.es.egwn.lan> <1178634483.3661.78.camel@localhost.localdomain> Message-ID: <87abwfckl8.fsf@fc5.bigo.ensc.de> Jason L Tibbitts III writes: > TC> kernel requires initscripts. You'd be hard-pressed to find a > TC> proper Fedora install that didn't have initscripts. > > Packages don't have requirements on "filesystem" either. That's an implicit requirement ( -> glibc -> .* -> filesystem). Plain -filesystem packages resp. noarch packages without other deps MUST add 'Requires: filesystem'. It is hard to find such an implicit requirement for 'initscripts' (try e.g. 'rpm -e --test initscripts' and see how small the deptree is). The 'kernel -> initscripts' example from this thread does not really apply. At first, I do not see, why the kernel needs initscripts. Then, you have to differ between the 'kernel' package and the kernel-environment. Lot of Fedora installations do not require the 'kernel' package (packaging bugs like gnome-volume-manager do not count ;)) because they are inside chroots. And the requirement on a Linux kernel environment can not be tracked by rpm (e.g. it is similarly to the requirement on an MTA). Enrico From Axel.Thimm at ATrpms.net Tue May 8 17:08:19 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 8 May 2007 19:08:19 +0200 Subject: [Fedora-packaging] Re: Requires: initscripts? In-Reply-To: <1178634483.3661.78.camel@localhost.localdomain> References: <20070508103800.5771dfe0@python3.es.egwn.lan> <1178634483.3661.78.camel@localhost.localdomain> Message-ID: <20070508170819.GB19969@neu.nirvana> On Tue, May 08, 2007 at 09:28:02AM -0500, Tom spot Callaway wrote: > On Tue, 2007-05-08 at 10:38 +0200, Matthias Saou wrote: > > I've never added "Requires: initscripts" to packages which contain an > > init script before. I've now been asked to in this review : > > kernel requires initscripts. You'd be hard-pressed to find a proper > Fedora install that didn't have initscripts. Not if this is a chroot, for example like an i386 chroot on x86_64, if one wants to avoid multilib headaches. > I think this is one of those "use your best judgement" issues here. If > it were my package, I wouldn't add it. It's a tiny step from Requires: > initscripts to Requires: kernel. -- 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 thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Tue May 8 18:13:25 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Tue, 8 May 2007 20:13:25 +0200 Subject: [Fedora-packaging] Re: Requires: initscripts? In-Reply-To: <87abwfckl8.fsf@fc5.bigo.ensc.de> References: <20070508103800.5771dfe0@python3.es.egwn.lan> <1178634483.3661.78.camel@localhost.localdomain> <87abwfckl8.fsf@fc5.bigo.ensc.de> Message-ID: <20070508201325.4237b712@python3.es.egwn.lan> Enrico Scholz wrote : > The 'kernel -> initscripts' example from this thread does not really > apply. At first, I do not see, why the kernel needs initscripts. It seems to be because it requires a minimal version of it. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 6 (Zod) - Linux kernel 2.6.20-1.2948.fc6 Load : 1.33 1.07 0.96 From bjohnson-dated-1172832473.ba5e95 at symetrix.com Tue May 8 18:18:25 2007 From: bjohnson-dated-1172832473.ba5e95 at symetrix.com (Bernard Johnson) Date: Tue, 08 May 2007 12:18:25 -0600 Subject: [Fedora-packaging] Re: Requires: initscripts? In-Reply-To: <20070508134829.7703742c@python3.es.egwn.lan> References: <20070508103800.5771dfe0@python3.es.egwn.lan> <20070508094018.GE26342@neu.nirvana> <20070508115204.4f13aaeb@python3.es.egwn.lan> <20070508095713.GF26342@neu.nirvana> <20070508120235.500bde46@python3.es.egwn.lan> <20070508111030.GI26342@neu.nirvana> <20070508133606.550b5bfa@python3.es.egwn.lan> <20070508113802.GJ26342@neu.nirvana> <20070508134829.7703742c@python3.es.egwn.lan> Message-ID: Matthias Saou wrote: > Nope. The current guidelines don't mention anything about this AFAICT. > It's the reviewer of my package who thinks it should be added, and had > it confirmed by someone on IRC (which isn't something I'd consider > trustworthy!). Really, how can you say that. You don't even know who weighed in on the discussion. Surely you realize that a lot of people that are on this list are on #fedora-devel as well. But let me be clear with my position (I am the reviewer for anyone who hasn't bothered to pull up the bug yet). It is unclear for me whether you think your program /doesn't need/ initscripts or /shouldn't require initscripts/. These are two totally different things, so I'll cover them both. Let's overlook the guideline for requiring the initscripts based on the fact that you put files in it's directories - this will simplify things for the moment. You must ask yourself, "is my package fully functional if initscripts is not installed". The answer is no. And not only no, but generates errors. Here's why: 1) . /etc/init.d/functions This will fail with an error message. 2) daemon /usr/sbin/autodir ... cmdline opts This will fail with an error message and fail to start the program. 3) pid=`pidfileofproc $prog` This will fail with an error message and cause the initfile to give incorrect status information. 4) killproc $prog This will fail with an error message and also fail to shutdown the program properly. Now, given the above, I think we can agree that your program "needs" initscripts (let's not say requires just yet). You might now argue that initscript will always be installed so that this is a non-issue. With that argument you are probably assuming that it will be required by the /installed/ kernel (this was my argument on #fedora-devel, because I was arguing your side of the discussion). So consider the case that someone compiles and runs their own kernel and removes the fedora kernel from the system. Until this was pointed out to me, I did not know how few dependencies there were (at least in newer fedora releases). This is totally plausible. And then if they remove initscripts (because nothing else depends on it), your package is broken. This is why it should require initscripts. From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Tue May 8 18:31:36 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Tue, 8 May 2007 20:31:36 +0200 Subject: [Fedora-packaging] Re: Requires: initscripts? In-Reply-To: References: <20070508103800.5771dfe0@python3.es.egwn.lan> <20070508094018.GE26342@neu.nirvana> <20070508115204.4f13aaeb@python3.es.egwn.lan> <20070508095713.GF26342@neu.nirvana> <20070508120235.500bde46@python3.es.egwn.lan> <20070508111030.GI26342@neu.nirvana> <20070508133606.550b5bfa@python3.es.egwn.lan> <20070508113802.GJ26342@neu.nirvana> <20070508134829.7703742c@python3.es.egwn.lan> Message-ID: <20070508203136.3acc9ca7@python3.es.egwn.lan> Bernard Johnson wrote : > Matthias Saou wrote: > > Nope. The current guidelines don't mention anything about this AFAICT. > > It's the reviewer of my package who thinks it should be added, and had > > it confirmed by someone on IRC (which isn't something I'd consider > > trustworthy!). > > Really, how can you say that. [...] I'm not sure what you mean : - The current init scripts guidelines don't mention anything else than the fact that the scripts shouldn't be marked as %config. - The reviewer of my package (you) thinks the requirement should be added. - You had someone on IRC (I don't know who) confirm your opinion... without further details, I can definitely not consider this a strong or even valid argument. Basically, this is what "I can say that" :-) > So consider the case that someone compiles and runs their own kernel and > removes the fedora kernel from the system. Until this was pointed out > to me, I did not know how few dependencies there were (at least in newer > fedora releases). This is totally plausible. And then if they remove > initscripts (because nothing else depends on it), your package is > broken. This is why it should require initscripts. Hey, I'm not saying you're wrong! I'm just saying that I've never put an explicit "initscripts" requirement in any package with an init script (nor do I recall seeing any Red Hat package with it). I'm also saying that my preference would be to not put it there, since it's assumed to be there, and any Fedora system will have it installed. If the Packaging Committee decides that it's best to put it, then so be it, but I prefer discussing the matter here. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 6 (Zod) - Linux kernel 2.6.20-1.2948.fc6 Load : 0.67 0.67 0.82 From ville.skytta at iki.fi Tue May 8 18:51:04 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Tue, 8 May 2007 21:51:04 +0300 Subject: [Fedora-packaging] Re: Requires: initscripts? In-Reply-To: <87hcqncnao.fsf@fc5.bigo.ensc.de> References: <20070508103800.5771dfe0@python3.es.egwn.lan> <87hcqncnao.fsf@fc5.bigo.ensc.de> Message-ID: <200705082151.04470.ville.skytta@iki.fi> On Tuesday 08 May 2007, Enrico Scholz wrote: > It depends how far we want to abuse rpm bugs/missing features. With > current rpm, it is fine to add only the tagged Requires(...) because > they implicate an untagged Requires: too. Not all of them; Requires(pre) and Requires(post) don't. From notting at redhat.com Tue May 8 19:05:22 2007 From: notting at redhat.com (Bill Nottingham) Date: Tue, 8 May 2007 15:05:22 -0400 Subject: [Fedora-packaging] Re: Requires: initscripts? In-Reply-To: <20070508120235.500bde46@python3.es.egwn.lan> References: <20070508103800.5771dfe0@python3.es.egwn.lan> <20070508094018.GE26342@neu.nirvana> <20070508115204.4f13aaeb@python3.es.egwn.lan> <20070508095713.GF26342@neu.nirvana> <20070508120235.500bde46@python3.es.egwn.lan> Message-ID: <20070508190522.GK21326@nostromo.devel.redhat.com> Matthias Saou (thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net) said: > Nothing fancy. Just a simple "service" to have run on startup, control > with chkconfig and service. I don't think "Requires: initscripts" would > improve nor fix anything, but I wanted an authoritative answer to be > 100% sure :-) If you require /sbin/service, initscripts will get pulled in... Bill From bjohnson-dated-1172832473.ba5e95 at symetrix.com Tue May 8 19:14:14 2007 From: bjohnson-dated-1172832473.ba5e95 at symetrix.com (Bernard Johnson) Date: Tue, 08 May 2007 13:14:14 -0600 Subject: [Fedora-packaging] Re: Requires: initscripts? In-Reply-To: <20070508203136.3acc9ca7@python3.es.egwn.lan> References: <20070508103800.5771dfe0@python3.es.egwn.lan> <20070508094018.GE26342@neu.nirvana> <20070508115204.4f13aaeb@python3.es.egwn.lan> <20070508095713.GF26342@neu.nirvana> <20070508120235.500bde46@python3.es.egwn.lan> <20070508111030.GI26342@neu.nirvana> <20070508133606.550b5bfa@python3.es.egwn.lan> <20070508113802.GJ26342@neu.nirvana> <20070508134829.7703742c@python3.es.egwn.lan> <20070508203136.3acc9ca7@python3.es.egwn.lan> Message-ID: Matthias Saou wrote: > Bernard Johnson wrote : > >> Matthias Saou wrote: >>> Nope. The current guidelines don't mention anything about this AFAICT. >>> It's the reviewer of my package who thinks it should be added, and had >>> it confirmed by someone on IRC (which isn't something I'd consider >>> trustworthy!). >> Really, how can you say that. [...] > > I'm not sure what you mean : > - The current init scripts guidelines don't mention anything else than > the fact that the scripts shouldn't be marked as %config. > - The reviewer of my package (you) thinks the requirement should be > added. > - You had someone on IRC (I don't know who) confirm your opinion... > without further details, I can definitely not consider this a strong or > even valid argument. > > Basically, this is what "I can say that" :-) I should have been more clear. I was only talking about your misrepresentation of the irc sources as not "trustworthy". > without further details, I can definitely not consider this a strong > or even valid argument. And you made this decision without knowing anything about the discussion, people involved, etc. - without asking for details. Please don't. If you want to say that opinions were collected "off the record" and you'd like to bring it to the mailing list, that's fine. Furthermore, I did not ask someone to "confirm my opinion". I simply asked "can initscripts be assumed to always be installed". Everyone who responded said no. I then pointed out the kernel->initscripts requires were present at which point it was pointed out to me that kernel can be removed if a custom kernel is built - then initscripts would be not necessarily required on the system. I would say that I was arguing your position more than getting mine confirmed. I am not trying to be your adversary here. Your position was presented fairly. I'm giving you feedback, which IMHO, is correct. >> So consider the case that someone compiles and runs their own kernel and >> removes the fedora kernel from the system. Until this was pointed out >> to me, I did not know how few dependencies there were (at least in newer >> fedora releases). This is totally plausible. And then if they remove >> initscripts (because nothing else depends on it), your package is >> broken. This is why it should require initscripts. > > Hey, I'm not saying you're wrong! I'm just saying that I've never put > an explicit "initscripts" requirement in any package with an init > script (nor do I recall seeing any Red Hat package with it). I'm also > saying that my preference would be to not put it there, since it's > assumed to be there, and any Fedora system will have it installed. Since you did not respond to the clarification that your program "needs" initscripts, I'll assume you agree with that point. The remaining discussion should then be around your claim that "it's assumed to be there, and any Fedora system will have it installed.". I've shown a case for when it may not. I would also like clarification (and opinions) from everyone on what exactly can be assumed to be ALWAYS installed on the system. We have such a list for BRs but I haven't seen any more Requires. (Maybe I'm just missing it). If running a non-Fedora kernel can be considered unsupported (you must always run / have installed a Fedora kernel), then that should be clarified. > If the Packaging Committee decides that it's best to put it, then so be > it, but I prefer discussing the matter here. I hardly think this is appropriate for the PC at this point, but feel free free to throw anything you want to them - I won't be offended. From hq4ever at gmail.com Tue May 8 20:00:23 2007 From: hq4ever at gmail.com (Maxim Veksler) Date: Tue, 8 May 2007 23:00:23 +0300 Subject: [Fedora-packaging] Upgrading databases as part of the RPM postinst script? Message-ID: Hi list, As part of the software (binaries) upgrade process my rpm will need to update database scheme (and possibly some configurations data) inside a mysql database. Are there any recommendations or case studies I should follow to screw things up as little as possible ? Thanks and happy hacking, Maxim. -- Cheers, Maxim Veksler "Free as in Freedom" - Do u GNU ? From Axel.Thimm at ATrpms.net Tue May 8 20:16:06 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 8 May 2007 22:16:06 +0200 Subject: [Fedora-packaging] Re: Requires: initscripts? In-Reply-To: <20070508190522.GK21326@nostromo.devel.redhat.com> References: <20070508103800.5771dfe0@python3.es.egwn.lan> <20070508094018.GE26342@neu.nirvana> <20070508115204.4f13aaeb@python3.es.egwn.lan> <20070508095713.GF26342@neu.nirvana> <20070508120235.500bde46@python3.es.egwn.lan> <20070508190522.GK21326@nostromo.devel.redhat.com> Message-ID: <20070508201606.GC1348@neu.nirvana> On Tue, May 08, 2007 at 03:05:22PM -0400, Bill Nottingham wrote: > Matthias Saou (thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net) said: > > Nothing fancy. Just a simple "service" to have run on startup, control > > with chkconfig and service. I don't think "Requires: initscripts" would > > improve nor fix anything, but I wanted an authoritative answer to be > > 100% sure :-) > > If you require /sbin/service, initscripts will get pulled in... Looks like the wrong people sit in the FPC - this was just too obvious and our brains jammed in accord. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tibbs at math.uh.edu Tue May 8 20:30:09 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 08 May 2007 15:30:09 -0500 Subject: [Fedora-packaging] Upgrading databases as part of the RPM postinst script? In-Reply-To: References: Message-ID: >>>>> "MV" == Maxim Veksler writes: MV> As part of the software (binaries) upgrade process my rpm will MV> need to update database scheme (and possibly some configurations MV> data) inside a mysql database. I would recommend not even attempting to do that kind of thing. How do you know the database is running at the time, or even that it's on the same machine? - J< From hq4ever at gmail.com Tue May 8 20:35:46 2007 From: hq4ever at gmail.com (Maxim Veksler) Date: Tue, 8 May 2007 23:35:46 +0300 Subject: [Fedora-packaging] Upgrading databases as part of the RPM postinst script? In-Reply-To: References: Message-ID: On 08 May 2007 15:30:09 -0500, Jason L Tibbitts III wrote: > >>>>> "MV" == Maxim Veksler writes: > > MV> As part of the software (binaries) upgrade process my rpm will > MV> need to update database scheme (and possibly some configurations > MV> data) inside a mysql database. > > I would recommend not even attempting to do that kind of thing. How > do you know the database is running at the time, or even that it's on > the same machine? > I check, or ask the user. I think that my questions is more of "how to do this" then who/when to do this. I think we can agree that if my databases changes between version and I wish to allow my users to continue running with their existing data I need to provide some method for them to upgrade their scheme while not loosing their data. Pointers on the above would be very welcome. Thank you. > - J< > > -- > Fedora-packaging mailing list > Fedora-packaging at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-packaging > -- Cheers, Maxim Veksler "Free as in Freedom" - Do u GNU ? From rayvd at bludgeon.org Tue May 8 20:40:18 2007 From: rayvd at bludgeon.org (Ray Van Dolson) Date: Tue, 8 May 2007 13:40:18 -0700 Subject: [Fedora-packaging] Upgrading databases as part of the RPM postinst script? In-Reply-To: References: Message-ID: <20070508204018.GB27843@bludgeon.org> On Tue, May 08, 2007 at 11:35:46PM +0300, Maxim Veksler wrote: > >I would recommend not even attempting to do that kind of thing. How > >do you know the database is running at the time, or even that it's on > >the same machine? > > > > I check, or ask the user. > > I think that my questions is more of "how to do this" then who/when to > do this. I think we can agree that if my databases changes between > version and I wish to allow my users to continue running with their > existing data I need to provide some method for them to upgrade their > scheme while not loosing their data. > > Pointers on the above would be very welcome. > Thank you. > Perhaps providing migration/conversion/update scripts as part of your new RPM that the user is then instructed to run manually? I guess this could potentially mean things won't work correctly if the udpate happened automatically and the user wasn't around. Ray From tibbs at math.uh.edu Tue May 8 21:01:36 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 08 May 2007 16:01:36 -0500 Subject: [Fedora-packaging] Upgrading databases as part of the RPM postinst script? In-Reply-To: References: Message-ID: >>>>> "MV" == Maxim Veksler writes: MV> I check, or ask the user. You can never ask the user; packages cannot be interactive. - J< From giallu at gmail.com Wed May 9 08:28:39 2007 From: giallu at gmail.com (Gianluca Sforna) Date: Wed, 9 May 2007 10:28:39 +0200 Subject: [Fedora-packaging] Upgrading databases as part of the RPM postinst script? In-Reply-To: References: Message-ID: On 08 May 2007 15:30:09 -0500, Jason L Tibbitts III wrote: > >>>>> "MV" == Maxim Veksler writes: > > MV> As part of the software (binaries) upgrade process my rpm will > MV> need to update database scheme (and possibly some configurations > MV> data) inside a mysql database. > > I would recommend not even attempting to do that kind of thing. How > do you know the database is running at the time, or even that it's on > the same machine? That is quite the same situation I am facing right now with mantis: in older releases, users was forced to browse a specific page to update the schema. Now I proposed upstream the addition of a script for performing the same updates from the command line, so I could add it in a scriptlet: of course it could fail for many reasons, but if you have a working installation then the configuration files has all the information required to connect to the database. I don't know if a similar solution is applicable at all in your situation, because it mostly depends on how the schema update is implemented upstream From nicolas.mailhot at laposte.net Wed May 9 08:44:44 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 9 May 2007 10:44:44 +0200 (CEST) Subject: [Fedora-packaging] Upgrading databases as part of the RPM postinst script? In-Reply-To: References: Message-ID: <32064.192.54.193.51.1178700284.squirrel@rousalka.dyndns.org> Le Mer 9 mai 2007 10:28, Gianluca Sforna a ?crit : > Now I proposed upstream the addition of a script for performing the > same updates from the command line, so I could add it in a scriptlet: > of course it could fail for many reasons, but if you have a working > installation then the configuration files has all the information > required to connect to the database. This kind of script is very dangerous to run from a scriplet, especially if the operations behind are not designed to be run unattended or output info that must be checked by the admin. Even if it works most of the time, if there is a significant risk of total or partial failure (the real dangerous one) it should not be scriplet-run. Getting updates to work across version jumps (someone updating directly from Fx to Fx+2) is also tricky in a scriplet context. You'll almost sure to hit someday a version jump or a local database customization upstream forgot to check. -- Nicolas Mailhot From ville.skytta at iki.fi Wed May 9 19:47:44 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Wed, 9 May 2007 22:47:44 +0300 Subject: [Fedora-packaging] Upgrading databases as part of the RPM postinst script? In-Reply-To: References: Message-ID: <200705092247.44304.ville.skytta@iki.fi> On Tuesday 08 May 2007, Maxim Veksler wrote: > I think we can agree that if my databases changes between > version and I wish to allow my users to continue running with their > existing data I need to provide some method for them to upgrade their > scheme while not loosing their data. Note also that schema updates are operations that people generally want to do only after making a full backup of existing data, so that they have something to return to in case something goes south with the update, or if the new version does not for one reason or another meet their needs and they want to downgrade. Upgrade scripts that upgrade the schema but leave it in a backwards compatible state are to some extent safer (and rarer), but I wouldn't be happy to see them being run automatically from package scriptlets either. From rdieter at math.unl.edu Thu May 10 04:48:39 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 09 May 2007 23:48:39 -0500 Subject: [Fedora-packaging] RFC: Signed JAR Packaging Policy In-Reply-To: <4642729C.1010105@math.unl.edu> References: <4642729C.1010105@math.unl.edu> Message-ID: <4642A427.1070603@math.unl.edu> Per RFC: Signed JAR Packaging Policy http://lwn.net/Articles/225981/ Review Request: jss - Java Security Services (JSS), http://bugzilla.redhat.com/230262 The "jar signing issue" is something we'll have to address somehow sooner or later. Imo, it can/should be considered on the same level as Fedora's signed rpms. Maybe fedora could have some sort of fedora-ca-keys pkg containing java CA's that's *only* available to the buildsys (ie, private, similar to fedora's rpm keys). We could also provide some sort of dummy fedora-ca-keys pkg in our public repos (or some other means for folks to generate/create their own ca-keys-containing pkg) to satisfy the reproducibility(*) issue. comments? -- Rex (*) reproducible in that you could build signed jars, but they wouldn't be identical, obviously. From rdieter at math.unl.edu Thu May 10 05:04:00 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 10 May 2007 00:04:00 -0500 Subject: [Fedora-packaging] RFC: Signed JAR Packaging Policy In-Reply-To: <4642A427.1070603@math.unl.edu> References: <4642729C.1010105@math.unl.edu> <4642A427.1070603@math.unl.edu> Message-ID: <4642A7C0.4020006@math.unl.edu> Rex Dieter wrote: > Per > RFC: Signed JAR Packaging Policy http://lwn.net/Articles/225981/ > Review Request: jss - Java Security Services (JSS), > http://bugzilla.redhat.com/230262 > > The "jar signing issue" is something we'll have to address somehow > sooner or later. Imo, it can/should be considered on the same level > as Fedora's signed rpms. > > > Maybe fedora could have some sort of fedora-ca-keys pkg containing > java CA's that's *only* available to the buildsys (ie, private, > similar to fedora's rpm keys). We could also provide some sort of > dummy fedora-ca-keys pkg in our public repos (or some other means for > folks to generate/create their own ca-keys-containing pkg) to satisfy > the reproducibility(*) issue. > > Duh, my bad for not actually re-reading the *whole* previous thread. spot pointed out that only "companies" can ask Sun for CA's, and that Fedora wouldn't qualify. But, hey, why not try and ask anyway? The worst that can happen is that Sun says no, in which case, what's so evil about using a "Red Hat" java CA? Regardless, for lack of a CA cert to work with, this discussion is moot. -- Rex From ville.skytta at iki.fi Thu May 10 20:38:34 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Thu, 10 May 2007 23:38:34 +0300 Subject: [Fedora-packaging] Second user/group handling draft In-Reply-To: <200704252219.37024.ville.skytta@iki.fi> References: <200704252219.37024.ville.skytta@iki.fi> Message-ID: <200705102338.35115.ville.skytta@iki.fi> On Wednesday 25 April 2007, I wrote: > The first draft about user and group handling (creation etc) is ready for > discussion: http://fedoraproject.org/wiki/PackagingDrafts/UsersAndGroups As noted in this week's FPC meeting minutes, the draft is probably going to be voted on next week. A more fleshed out and cleaned up version which also takes into account some findings in the FPC meeting as well as other feedback on -maintainers is now online. Comments still welcome. From Axel.Thimm at ATrpms.net Thu May 10 21:09:04 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 10 May 2007 23:09:04 +0200 Subject: [Fedora-packaging] Re: Second user/group handling draft In-Reply-To: <200705102338.35115.ville.skytta@iki.fi> References: <200704252219.37024.ville.skytta@iki.fi> <200705102338.35115.ville.skytta@iki.fi> Message-ID: <20070510210904.GA10369@neu.nirvana> On Thu, May 10, 2007 at 11:38:34PM +0300, Ville Skytt? wrote: > On Wednesday 25 April 2007, I wrote: > > > The first draft about user and group handling (creation etc) is ready for > > discussion: http://fedoraproject.org/wiki/PackagingDrafts/UsersAndGroups > > As noted in this week's FPC meeting minutes, the draft is probably going to be > voted on next week. A more fleshed out and cleaned up version which also > takes into account some findings in the FPC meeting as well as other feedback > on -maintainers is now online. Comments still welcome. Just a recomendation and two minor bits: o static uids/gids: They are covered, but there are semantically two typed of them: such that the Fedora project globally wants to define and such that a site admin may want to define. Both go through "setup", but we should mention what steps a packager needs to undertake if he want to officially register a uid/gid (while at the same time discouraging registring static id for the registration's sake only). Maybe something like "If you think that your package really requires allocation of global static uids/gids (because you need to hardwire these values into the binaries) then contact and ask for such an allocation. Only very few packages require a global static uid/gid, so verify that you indeed need one before contacting <>". o /srv/PACKAGE: We don't want to suggest to packagers to put anything under /srv as this is up to the admin to specify the layout. While one needs to admit that this may still be controversial within Fedora it's safer to not mention it. o /usr/sbin -> %{_sbindir} just as an educational measure? (Perhaps even rpmlint will cry if it's hardcoded?) Other than that (and even with that): +1 -- 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 fedora at leemhuis.info Fri May 11 06:36:32 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 11 May 2007 08:36:32 +0200 Subject: [Fedora-packaging] Second user/group handling draft In-Reply-To: <200705102338.35115.ville.skytta@iki.fi> References: <200704252219.37024.ville.skytta@iki.fi> <200705102338.35115.ville.skytta@iki.fi> Message-ID: <46440EF0.1000706@leemhuis.info> On 10.05.2007 22:38, Ville Skytt? wrote: > On Wednesday 25 April 2007, I wrote: > >> The first draft about user and group handling (creation etc) is ready for >> discussion: http://fedoraproject.org/wiki/PackagingDrafts/UsersAndGroups > > As noted in this week's FPC meeting minutes, the draft is probably going to be > voted on next week. A more fleshed out and cleaned up version which also > takes into account some findings in the FPC meeting as well as other feedback > on -maintainers is now online. Comments still welcome. Thx for writing this up; some comments (if they were discussed already then sorry for the noise): ---- I'd like to see clarifications somewhere for which existing branches we applies this/what it means to existing packages that use some magic tools to create users and groups currently. This probably should be tracked in a separate document, to not mix up "general good packaging standards" with packaging in practice for Fedora/EPEL. ---- What does this guideline mean for former Core packages that create groups and users hardcoded GIDs/UIDs? ---- "User accounts created by packages are rarely used for interactive logons, and should thus generally use /sbin/nologin as the user's shell." What about those core packages that don't follow this? My system has some: sync:x:5:0:sync:/sbin:/bin/sync shutdown:x:6:0:shutdown:/sbin:/sbin/shutdown halt:x:7:0:halt:/sbin:/sbin/halt news:x:9:13:news:/etc/news: netdump:x:34:34:Network Crash Dump user:/var/crash:/bin/bash I suspect there are more in former Core packages. Do they have a good reason for their doings maybe? Should that be handled by the Guideline? ---- Just wondering: Should we have some kind of "user/gid registry" in the wiki to track packages that create users/groups? Then sysadmins could create a fedora-meta-users-and-groups package in their private repo that creates all the users and groups that Fedora packages might create beforeband with static numbers; that workaround could be of interest for sysadmins that want to have the same UIDs/GIDs everywhere. ---- CU knurd From Axel.Thimm at ATrpms.net Fri May 11 10:00:34 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 11 May 2007 12:00:34 +0200 Subject: [Fedora-packaging] Re: Second user/group handling draft In-Reply-To: <46440EF0.1000706@leemhuis.info> References: <200704252219.37024.ville.skytta@iki.fi> <200705102338.35115.ville.skytta@iki.fi> <46440EF0.1000706@leemhuis.info> Message-ID: <20070511100034.GE28109@neu.nirvana> On Fri, May 11, 2007 at 08:36:32AM +0200, Thorsten Leemhuis wrote: > On 10.05.2007 22:38, Ville Skytt? wrote: > > On Wednesday 25 April 2007, I wrote: > > > >> The first draft about user and group handling (creation etc) is ready for > >> discussion: http://fedoraproject.org/wiki/PackagingDrafts/UsersAndGroups > > > > As noted in this week's FPC meeting minutes, the draft is probably going to be > > voted on next week. A more fleshed out and cleaned up version which also > > takes into account some findings in the FPC meeting as well as other feedback > > on -maintainers is now online. Comments still welcome. > > Thx for writing this up; some comments (if they were discussed already > then sorry for the noise): > > ---- > > I'd like to see clarifications somewhere for which existing branches we > applies this/what it means to existing packages that use some magic > tools to create users and groups currently. Just as any guideline, they apply to all, and packages will need to conform within a reasonable timeframe. It will most certainly practically not apply anymore to FC5, since this will go EOL almost the next day this guideline may have gotten through all instances. > What does this guideline mean for former Core packages that create > groups and users hardcoded GIDs/UIDs? Get the uid/gid in "setup" (which all of them already do). > "User accounts created by packages are rarely used for interactive > logons, and should thus generally use /sbin/nologin as the user's shell." > > What about those core packages that don't follow this? My system has some: That's why Ville wrote "generally" > sync:x:5:0:sync:/sbin:/bin/sync > shutdown:x:6:0:shutdown:/sbin:/sbin/shutdown > halt:x:7:0:halt:/sbin:/sbin/halt > news:x:9:13:news:/etc/news: > netdump:x:34:34:Network Crash Dump user:/var/crash:/bin/bash > > I suspect there are more in former Core packages. Do they have a good > reason for their doings maybe? Yes. > Should that be handled by the Guideline? No, if they have a good reason, then it's a case-by-case situation, we won't be able to cover every possible sane use. That's why there the guideline talks about "*should* thus *generally* use /sbin/nologin". > Just wondering: Should we have some kind of "user/gid registry" in the > wiki to track packages that create users/groups? Maybe, but this would require the maintainer of "setup" to make painfully sure wiki and "setup" are always in sync. The moment this deviates we're in trouble, so if the maintainer(s) of setup can't commit to simultaneous edits of "setup" and wiki contents, we should better keep "setup" as the only authoritative source. Which can be easily checked from the cvs viewer online I guess, so packagers will be able to check rawhide allocation immediately. > Then sysadmins could create a fedora-meta-users-and-groups package > in their private repo that creates all the users and groups that > Fedora packages might create beforeband with static numbers; There are no such packages other than "setup" in Ville's draft, so it's only one place to look this up (and to modify it) > that workaround could be of interest for sysadmins that want to have > the same UIDs/GIDs everywhere. It's far better for them to get the "setup" src.rpm package, edit it to their liking, and deploy their custom "setup". -- 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 fedora at leemhuis.info Fri May 11 10:37:57 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 11 May 2007 12:37:57 +0200 Subject: [Fedora-packaging] Re: Second user/group handling draft In-Reply-To: <20070511100034.GE28109@neu.nirvana> References: <200704252219.37024.ville.skytta@iki.fi> <200705102338.35115.ville.skytta@iki.fi> <46440EF0.1000706@leemhuis.info> <20070511100034.GE28109@neu.nirvana> Message-ID: <46444785.7070102@leemhuis.info> Hi! Thx for the answers Axel! On 11.05.2007 12:00, Axel Thimm wrote: > On Fri, May 11, 2007 at 08:36:32AM +0200, Thorsten Leemhuis wrote: >> On 10.05.2007 22:38, Ville Skytt? wrote: >>> On Wednesday 25 April 2007, I wrote: >>> >>>> The first draft about user and group handling (creation etc) is ready for >>>> discussion: http://fedoraproject.org/wiki/PackagingDrafts/UsersAndGroups >>> As noted in this week's FPC meeting minutes, the draft is probably going to be >>> voted on next week. A more fleshed out and cleaned up version which also >>> takes into account some findings in the FPC meeting as well as other feedback >>> on -maintainers is now online. Comments still welcome. >> Thx for writing this up; some comments (if they were discussed already >> then sorry for the noise): >> ---- >> I'd like to see clarifications somewhere for which existing branches we >> applies this/what it means to existing packages that use some magic >> tools to create users and groups currently. > Just as any guideline, they apply to all, and packages will need to > conform within a reasonable timeframe. It will most certainly > practically not apply anymore to FC5, since this will go EOL almost > the next day this guideline may have gotten through all instances. Side note: Who makes sure stuff gets enforced? FESCO and EPEL SIG? It generally seems to me hat some of the package guideline changes don't get applied to existing packages (or only the devel branch) because no one enforces them. The FPC, FESCO and EPEL SIG probably need to work something out together to improve that in the future. Especially for EPEL due to it's long life-time things might get complicated if we enforce new rules to existing packages for released branches. But that's a different discussion we probably should not open here and now. >> Just wondering: Should we have some kind of "user/gid registry" in the >> wiki to track packages that create users/groups? > Maybe, but this would require the maintainer of "setup" to make > painfully sure wiki and "setup" are always in sync. The moment this > deviates we're in trouble, so if the maintainer(s) of setup can't > commit to simultaneous edits of "setup" and wiki contents, we should > better keep "setup" as the only authoritative source. Which can be > easily checked from the cvs viewer online I guess, so packagers will > be able to check rawhide allocation immediately. Agreed. But sysadmins need to have a list of all possible users accounts somewhere afaics, otherwise it will be hard for them to modify setup (or am I missing something?). Maybe we could maintain such a list somewhere inside the setup rpm or it's cvs? Cu knurd From jorton at redhat.com Fri May 11 10:42:39 2007 From: jorton at redhat.com (Joe Orton) Date: Fri, 11 May 2007 11:42:39 +0100 Subject: [Fedora-packaging] Second user/group handling draft In-Reply-To: <200705102338.35115.ville.skytta@iki.fi> References: <200704252219.37024.ville.skytta@iki.fi> <200705102338.35115.ville.skytta@iki.fi> Message-ID: <20070511104239.GA14293@redhat.com> On Thu, May 10, 2007 at 11:38:34PM +0300, Ville Skytt? wrote: > On Wednesday 25 April 2007, I wrote: > > > The first draft about user and group handling (creation etc) is ready for > > discussion: http://fedoraproject.org/wiki/PackagingDrafts/UsersAndGroups > > As noted in this week's FPC meeting minutes, the draft is probably going to be > voted on next week. A more fleshed out and cleaned up version which also > takes into account some findings in the FPC meeting as well as other feedback > on -maintainers is now online. Comments still welcome. Is it really a good idea to run /bin/id in scriptlets? Depending on nsswitch configuration, couldn't this block waiting for NIS/etc lookups? (though maybe the same is true of useradd; I've always wondered whether it would be better to be using l{user,group}add instead) joe From Axel.Thimm at ATrpms.net Fri May 11 11:01:33 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 11 May 2007 13:01:33 +0200 Subject: [Fedora-packaging] Re: Second user/group handling draft In-Reply-To: <46444785.7070102@leemhuis.info> References: <200704252219.37024.ville.skytta@iki.fi> <200705102338.35115.ville.skytta@iki.fi> <46440EF0.1000706@leemhuis.info> <20070511100034.GE28109@neu.nirvana> <46444785.7070102@leemhuis.info> Message-ID: <20070511110133.GJ28109@neu.nirvana> On Fri, May 11, 2007 at 12:37:57PM +0200, Thorsten Leemhuis wrote: > Side note: Who makes sure stuff gets enforced? FESCO and EPEL SIG? Yes. The fpc is just the legislative and fesco is the judicial and executive with veto rights over the legislative's outcome. ;) > It generally seems to me hat some of the package guideline changes > don't get applied to existing packages (or only the devel branch) > because no one enforces them. The FPC, FESCO and EPEL SIG probably > need to work something out together to improve that in the > future. Especially for EPEL due to it's long life-time things might > get complicated if we enforce new rules to existing packages for > released branches. > > But that's a different discussion we probably should not open here and now. I agree, the fpc or the packaging discussion is less suited on topics about hunting down bad & lazy packagers. FWIW until now it was a cooperative work of the contributors, I hope it doesn't need to change in the future. But whatever punishment methods against lazyness will be envised they would not appear in the guidelines ;) > >> Just wondering: Should we have some kind of "user/gid registry" in the > >> wiki to track packages that create users/groups? > > Maybe, but this would require the maintainer of "setup" to make > > painfully sure wiki and "setup" are always in sync. The moment this > > deviates we're in trouble, so if the maintainer(s) of setup can't > > commit to simultaneous edits of "setup" and wiki contents, we should > > better keep "setup" as the only authoritative source. Which can be > > easily checked from the cvs viewer online I guess, so packagers will > > be able to check rawhide allocation immediately. > > Agreed. But sysadmins need to have a list of all possible users accounts > somewhere afaics, otherwise it will be hard for them to modify setup (or > am I missing something?). Maybe we could maintain such a list somewhere > inside the setup rpm or it's cvs? The list *is* part of "setup": passwd and group are *the* authoritative source and uidgid is a documented registry which already has to be manually maintained. So a wiki entry would make three different manually to maintain master lists. Unfortunately "setup" contents in cvs are "tarball-protected", but you could ask the maintainer(s) (officially Phil, but Bill is the uid/gid man) to keep these 20 files out of the tarball for the sake of online viewing of the latest bits. It would also make it easier for customizing "setup". -- 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 fedora at leemhuis.info Fri May 11 11:40:21 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 11 May 2007 13:40:21 +0200 Subject: [Fedora-packaging] Re: Second user/group handling draft In-Reply-To: <20070511110133.GJ28109@neu.nirvana> References: <200704252219.37024.ville.skytta@iki.fi> <200705102338.35115.ville.skytta@iki.fi> <46440EF0.1000706@leemhuis.info> <20070511100034.GE28109@neu.nirvana> <46444785.7070102@leemhuis.info> <20070511110133.GJ28109@neu.nirvana> Message-ID: <46445625.5050109@leemhuis.info> On 11.05.2007 13:01, Axel Thimm wrote: > On Fri, May 11, 2007 at 12:37:57PM +0200, Thorsten Leemhuis wrote: > >> But that's a different discussion we probably should not open here and now. > I agree, the fpc or the packaging discussion is less suited on topics > about hunting down bad & lazy packagers. FWIW until now it was a > cooperative work of the contributors, I hope it doesn't need to change > in the future. But whatever punishment methods against lazyness will > be envised they would not appear in the guidelines ;) Well, some "punishment methods" might be needed -- but I'm had mainly stuff like scripts in mind, that simply change spec files (semi-)automatically. Or a kind of QA-gang, that makes adjustments where needed. >>>> Just wondering: Should we have some kind of "user/gid registry" in the >>>> wiki to track packages that create users/groups? >>> Maybe, but this would require the maintainer of "setup" to make >>> painfully sure wiki and "setup" are always in sync. The moment this >>> deviates we're in trouble, so if the maintainer(s) of setup can't >>> commit to simultaneous edits of "setup" and wiki contents, we should >>> better keep "setup" as the only authoritative source. Which can be >>> easily checked from the cvs viewer online I guess, so packagers will >>> be able to check rawhide allocation immediately. >> Agreed. But sysadmins need to have a list of all possible users accounts >> somewhere afaics, otherwise it will be hard for them to modify setup (or >> am I missing something?). Maybe we could maintain such a list somewhere >> inside the setup rpm or it's cvs? > The list *is* part of "setup": Seems we don't understand each other here :-/ So I'm trying it in a different way: say I'm a sysadmin and I want to have the same static UIDs and GIDs on all my systems for *all* Fedora packages that create UIDs or GIDs during install. I need a list of groupnames and usernames such packages might create to prepare a modified setup package. So we need to have a kind of list like this somewhere: ||package||groupname||username|| ||clamav||clamavfoo||clamavbar|| ||zaptel||zaptelfoo||zaptelbar|| Then I as a sysadmin could easily create a modified setup.rpm with static UID and GIDs in case clamav or zaptel get installed sooner or later. Without such a list it would be really hard to modify setup. CU thl From Axel.Thimm at ATrpms.net Fri May 11 11:20:35 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 11 May 2007 13:20:35 +0200 Subject: [Fedora-packaging] Re: Second user/group handling draft In-Reply-To: <20070511104239.GA14293@redhat.com> References: <200704252219.37024.ville.skytta@iki.fi> <200705102338.35115.ville.skytta@iki.fi> <20070511104239.GA14293@redhat.com> Message-ID: <20070511112035.GL28109@neu.nirvana> On Fri, May 11, 2007 at 11:42:39AM +0100, Joe Orton wrote: > On Thu, May 10, 2007 at 11:38:34PM +0300, Ville Skytt? wrote: > > On Wednesday 25 April 2007, I wrote: > > > > > The first draft about user and group handling (creation etc) is ready for > > > discussion: http://fedoraproject.org/wiki/PackagingDrafts/UsersAndGroups > > > > As noted in this week's FPC meeting minutes, the draft is probably going to be > > voted on next week. A more fleshed out and cleaned up version which also > > takes into account some findings in the FPC meeting as well as other feedback > > on -maintainers is now online. Comments still welcome. > > Is it really a good idea to run /bin/id in scriptlets? Depending on > nsswitch configuration, couldn't this block waiting for NIS/etc lookups? You do have a point there, but the same is true for a simple ls -l command, so if NIS is in trouble rpm installs/upgrades will be the least that break, and they do break in %pre, e.g. there is no harm done. -- 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 Fri May 11 12:04:03 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 11 May 2007 14:04:03 +0200 Subject: [Fedora-packaging] Re: Second user/group handling draft In-Reply-To: <46445625.5050109@leemhuis.info> References: <200704252219.37024.ville.skytta@iki.fi> <200705102338.35115.ville.skytta@iki.fi> <46440EF0.1000706@leemhuis.info> <20070511100034.GE28109@neu.nirvana> <46444785.7070102@leemhuis.info> <20070511110133.GJ28109@neu.nirvana> <46445625.5050109@leemhuis.info> Message-ID: <20070511120403.GA2014@neu.nirvana> On Fri, May 11, 2007 at 01:40:21PM +0200, Thorsten Leemhuis wrote: > >>>> Just wondering: Should we have some kind of "user/gid registry" in the > >>>> wiki to track packages that create users/groups? > Seems we don't understand each other here :-/ > > So I'm trying it in a different way: say I'm a sysadmin and I want to > have the same static UIDs and GIDs on all my systems for *all* Fedora > packages that create UIDs or GIDs during install. I need a list of > groupnames and usernames such packages might create to prepare a > modified setup package. I understand, I thought you wanted to have an official registry for uid/gid mappings, but you just want to know which user/groups exist at all. > Then I as a sysadmin could easily create a modified setup.rpm with > static UID and GIDs in case clamav or zaptel get installed sooner or > later. Without such a list it would be really hard to modify setup. I think if the site admin does not know what users/groups he would like to sync across his site, then he doesn't really need to sync them. The site syncing makes sense when o mixing different Linuxes/Unices (but there you have even worse problems like different user/group splitting, so this use case is hardly worth going through troubles anyway) o or sharing package controlled parts over the network (like apache owned nfs shares). In these cases the admin has to know beforehand what his setup requires from a uid/gid POV, since these setups are his unique, custom deployment. So instead of requiring from all packagers that creat a group to maintain a list, which 10% won't do no matter what punishment you will threaten and being poked on bad quality by the site admins that think that Fedora should design their customized setups, have them (the admins) do their work and really think and design about their deployment including which user/groups they might need. But maybe the following can make you happy: A script that greps through the CVS and extracts these for you automatically. so no hunting down bad and lazy packagers and a rather up to date table to weekly import into the wiki. But that's not something we would mention in the guidelines. -- 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 enrico.scholz at informatik.tu-chemnitz.de Fri May 11 12:16:00 2007 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Fri, 11 May 2007 14:16:00 +0200 Subject: [Fedora-packaging] Re: Second user/group handling draft In-Reply-To: <46445625.5050109@leemhuis.info> (Thorsten Leemhuis's message of "Fri, 11 May 2007 13:40:21 +0200") References: <200704252219.37024.ville.skytta@iki.fi> <200705102338.35115.ville.skytta@iki.fi> <46440EF0.1000706@leemhuis.info> <20070511100034.GE28109@neu.nirvana> <46444785.7070102@leemhuis.info> <20070511110133.GJ28109@neu.nirvana> <46445625.5050109@leemhuis.info> Message-ID: <87ejlnwo73.fsf@fc5.bigo.ensc.de> Thorsten Leemhuis writes: > So I'm trying it in a different way: say I'm a sysadmin and I want to > have the same static UIDs and GIDs on all my systems for *all* Fedora > packages that create UIDs or GIDs during install. I need a list of > groupnames and usernames such packages might create to prepare a > modified setup package. > > So we need to have a kind of list like this somewhere: > > ||package||groupname||username|| > ||clamav||clamavfoo||clamavbar|| > ||zaptel||zaptelfoo||zaptelbar|| Such a list exists already: http://fedoraproject.org/wiki/PackageUserRegistry Additional requirements (full 'useradd' commandline, delay of 7-14 days before pushing into repos) are given in http://fedoraproject.org/wiki/PackagingDrafts/UsersAndGroups?action=recall&rev=5 Using wrappers like 'fedora-usermgmt' will make life of admins easier because they have to configure their system only once instead of updating their 'setup' package regularly. Enrico From fedora at leemhuis.info Fri May 11 12:18:22 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 11 May 2007 14:18:22 +0200 Subject: [Fedora-packaging] Re: Second user/group handling draft In-Reply-To: <20070511120403.GA2014@neu.nirvana> References: <200704252219.37024.ville.skytta@iki.fi> <200705102338.35115.ville.skytta@iki.fi> <46440EF0.1000706@leemhuis.info> <20070511100034.GE28109@neu.nirvana> <46444785.7070102@leemhuis.info> <20070511110133.GJ28109@neu.nirvana> <46445625.5050109@leemhuis.info> <20070511120403.GA2014@neu.nirvana> Message-ID: <46445F0E.1030400@leemhuis.info> On 11.05.2007 14:04, Axel Thimm wrote: > On Fri, May 11, 2007 at 01:40:21PM +0200, Thorsten Leemhuis wrote: >> >> So I'm trying it in a different way: say I'm a sysadmin and I want to >> have the same static UIDs and GIDs on all my systems for *all* Fedora >> packages that create UIDs or GIDs during install. I need a list of >> groupnames and usernames such packages might create to prepare a >> modified setup package. > I understand, I thought you wanted to have an official registry for > uid/gid mappings, but you just want to know which user/groups exist at > all. Yes. > [...] > But maybe the following can make you happy: A script that greps > through the CVS and extracts these for you automatically. If that works: sure. But we should not force sysadmins to download the whole cvs and run such a script -- we instead should autogenerate and upload it somewhere IMHO. > But that's not something we would mention in the guidelines. Agreed. CU thl From fedora at leemhuis.info Fri May 11 12:23:00 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 11 May 2007 14:23:00 +0200 Subject: [Fedora-packaging] Re: Second user/group handling draft In-Reply-To: <46445F0E.1030400@leemhuis.info> References: <200704252219.37024.ville.skytta@iki.fi> <200705102338.35115.ville.skytta@iki.fi> <46440EF0.1000706@leemhuis.info> <20070511100034.GE28109@neu.nirvana> <46444785.7070102@leemhuis.info> <20070511110133.GJ28109@neu.nirvana> <46445625.5050109@leemhuis.info> <20070511120403.GA2014@neu.nirvana> <46445F0E.1030400@leemhuis.info> Message-ID: <46446024.7090500@leemhuis.info> On 11.05.2007 14:18, Thorsten Leemhuis wrote: > On 11.05.2007 14:04, Axel Thimm wrote: >> On Fri, May 11, 2007 at 01:40:21PM +0200, Thorsten Leemhuis wrote: >> But that's not something we would mention in the guidelines. > Agreed. Or better: Agreed if someone creates such a script. Otherwise I'm for the wiki solution for now, and then it should be mentioned in the guidelines. Sure, some packagers will forget to update the wiki now and then, but that what we have the review for. And even if now and then a package gets forgotten: that happens, will get noticed, and then can easily get added to the wiki. CU thl From fedora at leemhuis.info Fri May 11 12:32:57 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 11 May 2007 14:32:57 +0200 Subject: [Fedora-packaging] Re: Second user/group handling draft In-Reply-To: <87ejlnwo73.fsf@fc5.bigo.ensc.de> References: <200704252219.37024.ville.skytta@iki.fi> <200705102338.35115.ville.skytta@iki.fi> <46440EF0.1000706@leemhuis.info> <20070511100034.GE28109@neu.nirvana> <46444785.7070102@leemhuis.info> <20070511110133.GJ28109@neu.nirvana> <46445625.5050109@leemhuis.info> <87ejlnwo73.fsf@fc5.bigo.ensc.de> Message-ID: <46446279.9030603@leemhuis.info> On 11.05.2007 14:16, Enrico Scholz wrote: > Thorsten Leemhuis writes: > >> So I'm trying it in a different way: say I'm a sysadmin and I want to >> have the same static UIDs and GIDs on all my systems for *all* Fedora >> packages that create UIDs or GIDs during install. I need a list of >> groupnames and usernames such packages might create to prepare a >> modified setup package. >> So we need to have a kind of list like this somewhere: >> ||package||groupname||username|| >> ||clamav||clamavfoo||clamavbar|| >> ||zaptel||zaptelfoo||zaptelbar|| > Such a list exists already: > http://fedoraproject.org/wiki/PackageUserRegistry It misses username and groupname -- those would be needed for the proposed solution. And the list only contains packages that use fedora-usermgmt. > [...] > Using wrappers like 'fedora-usermgmt' will make life of admins easier > because they have to configure their system only once instead of updating > their 'setup' package regularly. Maybe. But it seems it made lots of people really unhappy, so something is wrong somewhere. /me prefers not to comment more then the above -- I leave the user/group handling stuff to the packaging committee and trust it to make a good decision CU thl From Axel.Thimm at ATrpms.net Fri May 11 12:42:28 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 11 May 2007 14:42:28 +0200 Subject: [Fedora-packaging] Re: Second user/group handling draft In-Reply-To: <46445F0E.1030400@leemhuis.info> References: <200704252219.37024.ville.skytta@iki.fi> <200705102338.35115.ville.skytta@iki.fi> <46440EF0.1000706@leemhuis.info> <20070511100034.GE28109@neu.nirvana> <46444785.7070102@leemhuis.info> <20070511110133.GJ28109@neu.nirvana> <46445625.5050109@leemhuis.info> <20070511120403.GA2014@neu.nirvana> <46445F0E.1030400@leemhuis.info> Message-ID: <20070511124228.GB2014@neu.nirvana> On Fri, May 11, 2007 at 02:18:22PM +0200, Thorsten Leemhuis wrote: > On 11.05.2007 14:04, Axel Thimm wrote: > > On Fri, May 11, 2007 at 01:40:21PM +0200, Thorsten Leemhuis wrote: > >> > >> So I'm trying it in a different way: say I'm a sysadmin and I want to > >> have the same static UIDs and GIDs on all my systems for *all* Fedora > >> packages that create UIDs or GIDs during install. I need a list of > >> groupnames and usernames such packages might create to prepare a > >> modified setup package. > > I understand, I thought you wanted to have an official registry for > > uid/gid mappings, but you just want to know which user/groups exist at > > all. > > Yes. > > > [...] > > But maybe the following can make you happy: A script that greps > > through the CVS and extracts these for you automatically. > > If that works: sure. But we should not force sysadmins to download the > whole cvs and run such a script -- we instead should autogenerate and > upload it somewhere IMHO. Yes, that's what I meant. > > But that's not something we would mention in the guidelines. > > Agreed. -- 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 enrico.scholz at informatik.tu-chemnitz.de Fri May 11 13:04:26 2007 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Fri, 11 May 2007 15:04:26 +0200 Subject: [Fedora-packaging] Re: Second user/group handling draft In-Reply-To: <46446279.9030603@leemhuis.info> (Thorsten Leemhuis's message of "Fri, 11 May 2007 14:32:57 +0200") References: <200704252219.37024.ville.skytta@iki.fi> <200705102338.35115.ville.skytta@iki.fi> <46440EF0.1000706@leemhuis.info> <20070511100034.GE28109@neu.nirvana> <46444785.7070102@leemhuis.info> <20070511110133.GJ28109@neu.nirvana> <46445625.5050109@leemhuis.info> <87ejlnwo73.fsf@fc5.bigo.ensc.de> <46446279.9030603@leemhuis.info> Message-ID: <87abwbwlyd.fsf@fc5.bigo.ensc.de> Thorsten Leemhuis writes: >>> So we need to have a kind of list like this somewhere: >>> ||package||groupname||username|| >>> ||clamav||clamavfoo||clamavbar|| >> Such a list exists already: >> http://fedoraproject.org/wiki/PackageUserRegistry > > It misses username and groupname You mean supplementary groups? They are not listed in your proposal either and afais, they are not covered by the draft either. Packagers will have to execute | usermod -a -G They MUST NOT be set by 'useradd -G ...' Else, imo there is no special reason to distinguish between users and groups in the table. It does not cost extra when you need only one but register both. EnricoOB From enrico.scholz at informatik.tu-chemnitz.de Fri May 11 13:09:44 2007 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Fri, 11 May 2007 15:09:44 +0200 Subject: [Fedora-packaging] Re: Second user/group handling draft In-Reply-To: <46445F0E.1030400@leemhuis.info> (Thorsten Leemhuis's message of "Fri, 11 May 2007 14:18:22 +0200") References: <200704252219.37024.ville.skytta@iki.fi> <200705102338.35115.ville.skytta@iki.fi> <46440EF0.1000706@leemhuis.info> <20070511100034.GE28109@neu.nirvana> <46444785.7070102@leemhuis.info> <20070511110133.GJ28109@neu.nirvana> <46445625.5050109@leemhuis.info> <20070511120403.GA2014@neu.nirvana> <46445F0E.1030400@leemhuis.info> Message-ID: <87646zwlpj.fsf@fc5.bigo.ensc.de> Thorsten Leemhuis writes: >> But maybe the following can make you happy: A script that greps >> through the CVS and extracts these for you automatically. > > If that works: sure. But we should not force sysadmins to download the > whole cvs and run such a script Before I see such a script I do not believe that a such one is possible. E.g. please extract the needed information (username, homedir, gecos) from: | %global user foo | %global home %_var/lib/%name | | %post | useradd -r -d '%home' %user | | u='%user' | prog=/usr/sbin/useradd | $prog -r \ | $u Enrico From Axel.Thimm at ATrpms.net Fri May 11 13:40:27 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 11 May 2007 15:40:27 +0200 Subject: [Fedora-packaging] Re: Second user/group handling draft In-Reply-To: <87646zwlpj.fsf@fc5.bigo.ensc.de> References: <200704252219.37024.ville.skytta@iki.fi> <200705102338.35115.ville.skytta@iki.fi> <46440EF0.1000706@leemhuis.info> <20070511100034.GE28109@neu.nirvana> <46444785.7070102@leemhuis.info> <20070511110133.GJ28109@neu.nirvana> <46445625.5050109@leemhuis.info> <20070511120403.GA2014@neu.nirvana> <46445F0E.1030400@leemhuis.info> <87646zwlpj.fsf@fc5.bigo.ensc.de> Message-ID: <20070511134027.GD2014@neu.nirvana> On Fri, May 11, 2007 at 03:09:44PM +0200, Enrico Scholz wrote: > Thorsten Leemhuis writes: > > >> But maybe the following can make you happy: A script that greps > >> through the CVS and extracts these for you automatically. > > > > If that works: sure. But we should not force sysadmins to download the > > whole cvs and run such a script > > Before I see such a script I do not believe that a such one is possible. There is a proposed guideline that says how to create users/groups. Of course we can obscure anything so that one can't even read off the Name: tag of the package ... -- 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 Fri May 11 13:56:07 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 11 May 2007 15:56:07 +0200 Subject: [Fedora-packaging] Re: Second user/group handling draft In-Reply-To: <46446279.9030603@leemhuis.info> References: <200704252219.37024.ville.skytta@iki.fi> <200705102338.35115.ville.skytta@iki.fi> <46440EF0.1000706@leemhuis.info> <20070511100034.GE28109@neu.nirvana> <46444785.7070102@leemhuis.info> <20070511110133.GJ28109@neu.nirvana> <46445625.5050109@leemhuis.info> <87ejlnwo73.fsf@fc5.bigo.ensc.de> <46446279.9030603@leemhuis.info> Message-ID: <20070511135607.GE2014@neu.nirvana> On Fri, May 11, 2007 at 02:32:57PM +0200, Thorsten Leemhuis wrote: > On 11.05.2007 14:16, Enrico Scholz wrote: > > Thorsten Leemhuis writes: > > Using wrappers like 'fedora-usermgmt' will make life of admins easier > > because they have to configure their system only once instead of updating > > their 'setup' package regularly. Well, 'fedora-usermgmt' is a masterpiece of marketing: Promising the best of static and dynamic uid/gid and delivering the worst ;) > Maybe. But it seems it made lots of people really unhappy, so something > is wrong somewhere. The I wonder why you voted for keeping it. -- 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 thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Fri May 11 14:24:01 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Fri, 11 May 2007 16:24:01 +0200 Subject: [Fedora-packaging] Re: Requires: initscripts? In-Reply-To: <20070508201606.GC1348@neu.nirvana> References: <20070508103800.5771dfe0@python3.es.egwn.lan> <20070508094018.GE26342@neu.nirvana> <20070508115204.4f13aaeb@python3.es.egwn.lan> <20070508095713.GF26342@neu.nirvana> <20070508120235.500bde46@python3.es.egwn.lan> <20070508190522.GK21326@nostromo.devel.redhat.com> <20070508201606.GC1348@neu.nirvana> Message-ID: <20070511162401.57dddcd5@python3.es.egwn.lan> Axel Thimm wrote : > On Tue, May 08, 2007 at 03:05:22PM -0400, Bill Nottingham wrote: > > Matthias Saou (thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net) said: > > > Nothing fancy. Just a simple "service" to have run on startup, control > > > with chkconfig and service. I don't think "Requires: initscripts" would > > > improve nor fix anything, but I wanted an authoritative answer to be > > > 100% sure :-) > > > > If you require /sbin/service, initscripts will get pulled in... > > Looks like the wrong people sit in the FPC - this was just too obvious > and our brains jammed in accord. Not entirely... since /sbin/service is only Requires(preun) and Requires(postun), nothing is making initscripts a "pre" or runtime requirement of the package AFAICT. I still can't really picture a working system which wouldn't have initscripts installed, though. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 6 (Zod) - Linux kernel 2.6.20-1.2948.fc6 Load : 0.18 0.33 0.43 From fedora at leemhuis.info Fri May 11 14:30:23 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 11 May 2007 16:30:23 +0200 Subject: [Fedora-packaging] Re: Second user/group handling draft In-Reply-To: <20070511135607.GE2014@neu.nirvana> References: <200704252219.37024.ville.skytta@iki.fi> <200705102338.35115.ville.skytta@iki.fi> <46440EF0.1000706@leemhuis.info> <20070511100034.GE28109@neu.nirvana> <46444785.7070102@leemhuis.info> <20070511110133.GJ28109@neu.nirvana> <46445625.5050109@leemhuis.info> <87ejlnwo73.fsf@fc5.bigo.ensc.de> <46446279.9030603@leemhuis.info> <20070511135607.GE2014@neu.nirvana> Message-ID: <46447DFF.90603@leemhuis.info> Axel Thimm schrieb: > On Fri, May 11, 2007 at 02:32:57PM +0200, Thorsten Leemhuis wrote: >> On 11.05.2007 14:16, Enrico Scholz wrote: >>> Thorsten Leemhuis writes: >>> Using wrappers like 'fedora-usermgmt' will make life of admins easier >>> because they have to configure their system only once instead of updating >>> their 'setup' package regularly. > Well, 'fedora-usermgmt' is a masterpiece of marketing: Promising the > best of static and dynamic uid/gid and delivering the worst ;) You should be aware that some people think different about fedora-usermgmt. Especially as Enrico is the creator of fedora-usermgmt. So please be a bit more diplomatic and avoid such flamebits, as that might help to avoid yet another flamewar. >> Maybe. But it seems it made lots of people really unhappy, so something >> is wrong somewhere. > The I wonder why you voted for keeping it. In EPEL? I didn't want rules for packaging to be different between Fedora and EPEL. CU thl From ville.skytta at iki.fi Fri May 11 14:52:47 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Fri, 11 May 2007 17:52:47 +0300 Subject: [Fedora-packaging] Re: Requires: initscripts? In-Reply-To: <20070511162401.57dddcd5@python3.es.egwn.lan> References: <20070508103800.5771dfe0@python3.es.egwn.lan> <20070508201606.GC1348@neu.nirvana> <20070511162401.57dddcd5@python3.es.egwn.lan> Message-ID: <200705111752.47630.ville.skytta@iki.fi> On Friday 11 May 2007, Matthias Saou wrote: > Not entirely... since /sbin/service is only Requires(preun) and > Requires(postun), nothing is making initscripts a "pre" or runtime > requirement of the package AFAICT. http://rpm.org/max-rpm-snapshot/s1-rpm-depend-manual-dependencies.html#S3-RPM-DEPEND-CONTEXT-DEPENDS From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Fri May 11 15:08:19 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Fri, 11 May 2007 17:08:19 +0200 Subject: [Fedora-packaging] Re: Requires: initscripts? In-Reply-To: <200705111752.47630.ville.skytta@iki.fi> References: <20070508103800.5771dfe0@python3.es.egwn.lan> <20070508201606.GC1348@neu.nirvana> <20070511162401.57dddcd5@python3.es.egwn.lan> <200705111752.47630.ville.skytta@iki.fi> Message-ID: <20070511170819.0f5ad5f0@python3.es.egwn.lan> Ville Skytt? wrote : > On Friday 11 May 2007, Matthias Saou wrote: > > > Not entirely... since /sbin/service is only Requires(preun) and > > Requires(postun), nothing is making initscripts a "pre" or runtime > > requirement of the package AFAICT. > > http://rpm.org/max-rpm-snapshot/s1-rpm-depend-manual-dependencies.html#S3-RPM-DEPEND-CONTEXT-DEPENDS Makes perfect sense, and all is fine. Thanks for the pointer ;-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 6 (Zod) - Linux kernel 2.6.20-1.2948.fc6 Load : 0.37 0.46 0.46 From notting at redhat.com Fri May 11 16:47:58 2007 From: notting at redhat.com (Bill Nottingham) Date: Fri, 11 May 2007 12:47:58 -0400 Subject: [Fedora-packaging] Re: Requires: initscripts? In-Reply-To: <20070511162401.57dddcd5@python3.es.egwn.lan> References: <20070508103800.5771dfe0@python3.es.egwn.lan> <20070508094018.GE26342@neu.nirvana> <20070508115204.4f13aaeb@python3.es.egwn.lan> <20070508095713.GF26342@neu.nirvana> <20070508120235.500bde46@python3.es.egwn.lan> <20070508190522.GK21326@nostromo.devel.redhat.com> <20070508201606.GC1348@neu.nirvana> <20070511162401.57dddcd5@python3.es.egwn.lan> Message-ID: <20070511164758.GF2444@nostromo.devel.redhat.com> Matthias Saou (thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net) said: > Not entirely... since /sbin/service is only Requires(preun) and > Requires(postun), nothing is making initscripts a "pre" or runtime > requirement of the package AFAICT. preun must be installed when the package is. rpm doesn't support making you install it before you remove the package. Bill From notting at redhat.com Fri May 11 17:58:35 2007 From: notting at redhat.com (Bill Nottingham) Date: Fri, 11 May 2007 13:58:35 -0400 Subject: [Fedora-packaging] Second user/group handling draft In-Reply-To: <200705102338.35115.ville.skytta@iki.fi> References: <200704252219.37024.ville.skytta@iki.fi> <200705102338.35115.ville.skytta@iki.fi> Message-ID: <20070511175835.GI2444@nostromo.devel.redhat.com> Ville Skytt? (ville.skytta at iki.fi) said: > On Wednesday 25 April 2007, I wrote: > > > The first draft about user and group handling (creation etc) is ready for > > discussion: http://fedoraproject.org/wiki/PackagingDrafts/UsersAndGroups > > As noted in this week's FPC meeting minutes, the draft is probably going to be > voted on next week. A more fleshed out and cleaned up version which also > takes into account some findings in the FPC meeting as well as other feedback > on -maintainers is now online. Comments still welcome. Requiring shadow-utils as opposed to /usr/sbin/{user,group}add cuts down on a layer of indirection when resolving deps. Bill From notting at redhat.com Fri May 11 18:04:37 2007 From: notting at redhat.com (Bill Nottingham) Date: Fri, 11 May 2007 14:04:37 -0400 Subject: [Fedora-packaging] Second user/group handling draft In-Reply-To: <20070511104239.GA14293@redhat.com> References: <200704252219.37024.ville.skytta@iki.fi> <200705102338.35115.ville.skytta@iki.fi> <20070511104239.GA14293@redhat.com> Message-ID: <20070511180437.GJ2444@nostromo.devel.redhat.com> Joe Orton (jorton at redhat.com) said: > > As noted in this week's FPC meeting minutes, the draft is probably going to be > > voted on next week. A more fleshed out and cleaned up version which also > > takes into account some findings in the FPC meeting as well as other feedback > > on -maintainers is now online. Comments still welcome. > > Is it really a good idea to run /bin/id in scriptlets? Depending on > nsswitch configuration, couldn't this block waiting for NIS/etc lookups? Why not just check the exit status of useradd? There is a specific exit status for 'user already exists'. I'm of the opinion that we should handle static IDs by just assigning static IDs up to 500 for everything. That's orthogonal to this, though. Bill From jkeating at redhat.com Fri May 11 20:32:38 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 11 May 2007 13:32:38 -0700 Subject: [Fedora-packaging] RFC: Signed JAR Packaging Policy In-Reply-To: <4642A7C0.4020006@math.unl.edu> References: <4642729C.1010105@math.unl.edu> <4642A427.1070603@math.unl.edu> <4642A7C0.4020006@math.unl.edu> Message-ID: <200705111332.50263.jkeating@redhat.com> On Wednesday 09 May 2007 22:04:00 Rex Dieter wrote: > Duh, my bad for not actually re-reading the *whole* previous thread. > spot pointed out that only "companies" can ask Sun for CA's, and that > Fedora wouldn't qualify. ?But, hey, why not try and ask anyway? ?The > worst that can happen is that Sun says no, in which case, what's so evil > about using a "Red Hat" java CA? ?Regardless, for lack of a CA cert to > work with, this discussion is moot. redistributability. -- Jesse Keating Release Engineer: Fedora -------------- 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 Sat May 12 09:08:13 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-15?q?Skytt=E4?=) Date: Sat, 12 May 2007 12:08:13 +0300 Subject: [Fedora-packaging] Re: Second user/group handling draft In-Reply-To: <46444785.7070102@leemhuis.info> References: <200704252219.37024.ville.skytta@iki.fi> <20070511100034.GE28109@neu.nirvana> <46444785.7070102@leemhuis.info> Message-ID: <200705121208.14355.ville.skytta@iki.fi> On Friday 11 May 2007, Thorsten Leemhuis wrote: > Agreed. But sysadmins need to have a list of all possible users accounts > somewhere afaics, otherwise it will be hard for them to modify setup (or > am I missing something?). Maybe we could maintain such a list somewhere > inside the setup rpm or it's cvs? I do think such a list would be a good thing, not only because of the above, but it could also be helpful in the case where a same-named user/group exists beforehand for an unrelated purpose (the last paragraph in the draft). From ville.skytta at iki.fi Sat May 12 09:18:09 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Sat, 12 May 2007 12:18:09 +0300 Subject: [Fedora-packaging] Re: Second user/group handling draft In-Reply-To: <20070510210904.GA10369@neu.nirvana> References: <200704252219.37024.ville.skytta@iki.fi> <200705102338.35115.ville.skytta@iki.fi> <20070510210904.GA10369@neu.nirvana> Message-ID: <200705121218.09432.ville.skytta@iki.fi> On Friday 11 May 2007, Axel Thimm wrote: > "If you think that your package really requires allocation of global > static uids/gids (because you need to hardwire these values into the > binaries) then contact > and ask for such an allocation. Only very few packages require a > global static uid/gid, so verify that you indeed need one before > contacting <>". Adding users/groups to the "setup" package in the distro is an upgrade problem - /etc/passwd and friends will end up as *.rpmnew so something needs to ensure that the users/groups get created by other means - and at that point, it's not clear to me that it is a good idea to have this stuff in the distro "setup" package any more. > o /srv/PACKAGE: We don't want to suggest to packagers to put anything > under /srv as this is up to the admin to specify the layout. While > one needs to admit that this may still be controversial within > Fedora it's safer to not mention it. Ok, removed all explicit examples, now referring to just "data directory". > o /usr/sbin -> %{_sbindir} just as an educational measure? (Perhaps > even rpmlint will cry if it's hardcoded?) Perhaps, as the shadow-utils package uses %{_sbindir} as well, changed to that for now. Another option would be to require shadow-utils (like Bill suggested) and use pathless useradd/groupadd. From ville.skytta at iki.fi Sat May 12 09:22:49 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Sat, 12 May 2007 12:22:49 +0300 Subject: [Fedora-packaging] Second user/group handling draft In-Reply-To: <20070511180437.GJ2444@nostromo.devel.redhat.com> References: <200704252219.37024.ville.skytta@iki.fi> <20070511104239.GA14293@redhat.com> <20070511180437.GJ2444@nostromo.devel.redhat.com> Message-ID: <200705121222.49703.ville.skytta@iki.fi> On Friday 11 May 2007, Bill Nottingham wrote: > Why not just check the exit status of useradd? There is a specific > exit status for 'user already exists'. Possible, but would result in quite a bit of "useradd: user foo exists" noise on package upgrades or more complicated %pre scriptlets that filter out this particular error message but let others through. useradd would benefit from an option similar to groupadd's -f. From Axel.Thimm at ATrpms.net Sat May 12 09:31:47 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 12 May 2007 11:31:47 +0200 Subject: [Fedora-packaging] Re: Second user/group handling draft In-Reply-To: <200705121218.09432.ville.skytta@iki.fi> References: <200704252219.37024.ville.skytta@iki.fi> <200705102338.35115.ville.skytta@iki.fi> <20070510210904.GA10369@neu.nirvana> <200705121218.09432.ville.skytta@iki.fi> Message-ID: <20070512093147.GC31330@neu.nirvana> On Sat, May 12, 2007 at 12:18:09PM +0300, Ville Skytt? wrote: > On Friday 11 May 2007, Axel Thimm wrote: > > > "If you think that your package really requires allocation of global > > static uids/gids (because you need to hardwire these values into the > > binaries) then contact > > and ask for such an allocation. Only very few packages require a > > global static uid/gid, so verify that you indeed need one before > > contacting <>". > > Adding users/groups to the "setup" package in the distro is an upgrade > problem - /etc/passwd and friends will end up as *.rpmnew That's everyday's Fedora setup, the first ever user you create already modifies these, and how many users are really creating all users in LDAP/NIS, I think in the Fedora world most are still on nss file switch, so passwd/group are almost always user modified on each upgrade. We wouldn't change anything in today's procedures, we're just writing them down. -- 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 enrico.scholz at informatik.tu-chemnitz.de Sat May 12 09:34:14 2007 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Sat, 12 May 2007 11:34:14 +0200 Subject: [Fedora-packaging] Re: Second user/group handling draft In-Reply-To: <46446279.9030603@leemhuis.info> (Thorsten Leemhuis's message of "Fri, 11 May 2007 14:32:57 +0200") References: <200704252219.37024.ville.skytta@iki.fi> <200705102338.35115.ville.skytta@iki.fi> <46440EF0.1000706@leemhuis.info> <20070511100034.GE28109@neu.nirvana> <46444785.7070102@leemhuis.info> <20070511110133.GJ28109@neu.nirvana> <46445625.5050109@leemhuis.info> <87ejlnwo73.fsf@fc5.bigo.ensc.de> <46446279.9030603@leemhuis.info> Message-ID: <87mz0abd2h.fsf@kosh.bigo.ensc.de> Thorsten Leemhuis writes: >> Using wrappers like 'fedora-usermgmt' will make life of admins easier >> because they have to configure their system only once instead of >> updating their 'setup' package regularly. > > Maybe. But it seems it made lots of people really unhappy, so something > is wrong somewhere. Yep... although 'fedora-usermgmt' delivers the best of of static and dynamic uid/gid, it has an horrible marketing :( Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From ville.skytta at iki.fi Sat May 12 09:38:22 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Sat, 12 May 2007 12:38:22 +0300 Subject: [Fedora-packaging] Second user/group handling draft In-Reply-To: <20070511175835.GI2444@nostromo.devel.redhat.com> References: <200704252219.37024.ville.skytta@iki.fi> <200705102338.35115.ville.skytta@iki.fi> <20070511175835.GI2444@nostromo.devel.redhat.com> Message-ID: <200705121238.24529.ville.skytta@iki.fi> On Friday 11 May 2007, Bill Nottingham wrote: > > Requiring shadow-utils as opposed to /usr/sbin/{user,group}add cuts down > on a layer of indirection when resolving deps. Sure, but it also introduces an indirection within the specfile as we'd no longer have explicit scriptlet dependencies to executables being used in them. I think this is somewhat frowned upon, but I can't find a guideline reference right now. BTW, somehow I feel that if the dependency would be on shadow-utils, it'd be more natural to also invoke useradd/groupadd from $PATH without hardwired /usr/sbin (or %{_sbindir}). Anyone else have the same feeling? From ville.skytta at iki.fi Sat May 12 09:52:05 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Sat, 12 May 2007 12:52:05 +0300 Subject: [Fedora-packaging] Re: Second user/group handling draft In-Reply-To: <20070512093147.GC31330@neu.nirvana> References: <200704252219.37024.ville.skytta@iki.fi> <200705121218.09432.ville.skytta@iki.fi> <20070512093147.GC31330@neu.nirvana> Message-ID: <200705121252.05746.ville.skytta@iki.fi> On Saturday 12 May 2007, Axel Thimm wrote: > On Sat, May 12, 2007 at 12:18:09PM +0300, Ville Skytt? wrote: > > On Friday 11 May 2007, Axel Thimm wrote: > > > "If you think that your package really requires allocation of global > > > static uids/gids (because you need to hardwire these values into the > > > binaries) then contact > > > and ask for such an allocation. Only very few packages require a > > > global static uid/gid, so verify that you indeed need one before > > > contacting <>". > > > > Adding users/groups to the "setup" package in the distro is an upgrade > > problem - /etc/passwd and friends will end up as *.rpmnew [...] > We wouldn't change anything in today's procedures, we're just writing > them down. Note that your phrasing above mentions contacting the maintainer of the setup package. This implies to me as if adding users/groups to the distro setup package would be a possibility. That's certainly not today's procedure - there has been no user additions to /etc/passwd since RHL 6.2 (maybe even earlier?), and only the "lock" group was added to /etc/group in 7.2, otherwise no new groups in it since RHL 6.2 either. From Axel.Thimm at ATrpms.net Sat May 12 11:03:28 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 12 May 2007 13:03:28 +0200 Subject: [Fedora-packaging] Re: Second user/group handling draft In-Reply-To: <200705121252.05746.ville.skytta@iki.fi> References: <200704252219.37024.ville.skytta@iki.fi> <200705121218.09432.ville.skytta@iki.fi> <20070512093147.GC31330@neu.nirvana> <200705121252.05746.ville.skytta@iki.fi> Message-ID: <20070512110328.GD31330@neu.nirvana> On Sat, May 12, 2007 at 12:52:05PM +0300, Ville Skytt? wrote: > On Saturday 12 May 2007, Axel Thimm wrote: > > On Sat, May 12, 2007 at 12:18:09PM +0300, Ville Skytt? wrote: > > > On Friday 11 May 2007, Axel Thimm wrote: > > > > "If you think that your package really requires allocation of global > > > > static uids/gids (because you need to hardwire these values into the > > > > binaries) then contact > > > > and ask for such an allocation. Only very few packages require a > > > > global static uid/gid, so verify that you indeed need one before > > > > contacting <>". > > > > > > Adding users/groups to the "setup" package in the distro is an upgrade > > > problem - /etc/passwd and friends will end up as *.rpmnew > [...] > > We wouldn't change anything in today's procedures, we're just writing > > them down. > > Note that your phrasing above mentions contacting the maintainer of the setup > package. This implies to me as if adding users/groups to the distro setup > package would be a possibility. That's certainly not today's procedure - > there has been no user additions to /etc/passwd since RHL 6.2 (maybe even > earlier?), and only the "lock" group was added to /etc/group in 7.2, > otherwise no new groups in it since RHL 6.2 either. Yes, you are right, but still passwd changed as well for other reasons like the passwd field of root or home of news. So while this package is being held rather stable (and it will continue to, we are discouraging static uids if there is not a real need for one) there are changes made to the files of this package. OTOH the content of passwd are *always* modified in post install (all passwd fields are x'd), so you never get a passwd upgrade, which is a really bad mechanism of the "setup" package, IMHO. Can we assume that the uid/gids < 100 were always considered sacred to the users, e.g. only to be set/modified by the vendor and not misused for local purposes? In other words, can we assume that these uid/gid are under the authority of the "setup" package? If we can answer this with yes (which IMHO we should), then we can have "setup" upgrade passwd/group by removing all uid/gid < 100 in the files found on the system and insert its fresh ones. This would not only solve the issues at hand, but is an important mechanism to have in place for the "setup" package in general. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rdieter at math.unl.edu Mon May 14 14:00:16 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 14 May 2007 09:00:16 -0500 Subject: [Fedora-packaging] Re: RFC: Signed JAR Packaging Policy References: <4642729C.1010105@math.unl.edu> <4642A427.1070603@math.unl.edu> <4642A7C0.4020006@math.unl.edu> <200705111332.50263.jkeating@redhat.com> Message-ID: Jesse Keating wrote: > On Wednesday 09 May 2007 22:04:00 Rex Dieter wrote: >> Duh, my bad for not actually re-reading the *whole* previous thread. >> spot pointed out that only "companies" can ask Sun for CA's, and that >> Fedora wouldn't qualify. ?But, hey, why not try and ask anyway? ?The >> worst that can happen is that Sun says no, in which case, what's so evil >> about using a "Red Hat" java CA? ?Regardless, for lack of a CA cert to >> work with, this discussion is moot. > > redistributability. huh? redistributability of what exactly? If you're talking about the keys, I'm not advocating (re)distributing the java CA keys, any more than I'd advocate (re)distributing the keys fedora uses to sign it's rpms (cause that'd be silly/useless). -- Rex From jkeating at redhat.com Mon May 14 15:20:13 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 14 May 2007 11:20:13 -0400 Subject: [Fedora-packaging] Re: RFC: Signed JAR Packaging Policy In-Reply-To: References: <4642729C.1010105@math.unl.edu> <200705111332.50263.jkeating@redhat.com> Message-ID: <200705141120.14010.jkeating@redhat.com> On Monday 14 May 2007 10:00:16 Rex Dieter wrote: > If you're talking about the keys, I'm not advocating (re)distributing the > java CA keys, any more than I'd advocate (re)distributing the keys fedora > uses to sign it's rpms (cause that'd be silly/useless). Right, but our packages are perfectly usable without being signed. Without changes to the java stuff, the package is completely UNusable without being signed. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rdieter at math.unl.edu Mon May 14 15:25:21 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 14 May 2007 10:25:21 -0500 Subject: [Fedora-packaging] Re: RFC: Signed JAR Packaging Policy In-Reply-To: <200705141120.14010.jkeating@redhat.com> References: <4642729C.1010105@math.unl.edu> <200705111332.50263.jkeating@redhat.com> <200705141120.14010.jkeating@redhat.com> Message-ID: <46487F61.9050603@math.unl.edu> Jesse Keating wrote: > ... our packages are perfectly usable without being signed. Without > changes to the java stuff, the package is completely UNusable without being > signed. agreed, precisely why I'm trying to come up with mechanisms/policy wrt signed .jars in Fedora. :) -- Rex From jkeating at redhat.com Mon May 14 15:27:50 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 14 May 2007 11:27:50 -0400 Subject: [Fedora-packaging] Re: RFC: Signed JAR Packaging Policy In-Reply-To: <46487F61.9050603@math.unl.edu> References: <4642729C.1010105@math.unl.edu> <200705141120.14010.jkeating@redhat.com> <46487F61.9050603@math.unl.edu> Message-ID: <200705141127.50575.jkeating@redhat.com> On Monday 14 May 2007 11:25:21 Rex Dieter wrote: > agreed, precisely why I'm trying to come up with mechanisms/policy wrt > signed .jars in Fedora. :) Simple. Fix java so that it operates with an unsigned jar in a blatantly 'insecure' mode, like a self signed cert in apache. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From notting at redhat.com Mon May 14 18:30:20 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 14 May 2007 14:30:20 -0400 Subject: [Fedora-packaging] Re: Second user/group handling draft In-Reply-To: <20070512110328.GD31330@neu.nirvana> References: <200704252219.37024.ville.skytta@iki.fi> <200705121218.09432.ville.skytta@iki.fi> <20070512093147.GC31330@neu.nirvana> <200705121252.05746.ville.skytta@iki.fi> <20070512110328.GD31330@neu.nirvana> Message-ID: <20070514183020.GM5267@nostromo.devel.redhat.com> Axel Thimm (Axel.Thimm at ATrpms.net) said: > Can we assume that the uid/gids < 100 were always considered sacred to > the users, e.g. only to be set/modified by the vendor and not misused > for local purposes? In other words, can we assume that these uid/gid > are under the authority of the "setup" package? Yes, absolutely. > If we can answer this with yes (which IMHO we should), then we can > have "setup" upgrade passwd/group by removing all uid/gid < 100 in the > files found on the system and insert its fresh ones. This would not > only solve the issues at hand, but is an important mechanism to have > in place for the "setup" package in general. No, you can't. No prereqs allowed that early in the transaction. Bill From Axel.Thimm at ATrpms.net Mon May 14 19:53:14 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 14 May 2007 21:53:14 +0200 Subject: [Fedora-packaging] Re: Second user/group handling draft In-Reply-To: <20070514183020.GM5267@nostromo.devel.redhat.com> References: <200704252219.37024.ville.skytta@iki.fi> <200705121218.09432.ville.skytta@iki.fi> <20070512093147.GC31330@neu.nirvana> <200705121252.05746.ville.skytta@iki.fi> <20070512110328.GD31330@neu.nirvana> <20070514183020.GM5267@nostromo.devel.redhat.com> Message-ID: <20070514195314.GS24904@neu.nirvana> On Mon, May 14, 2007 at 02:30:20PM -0400, Bill Nottingham wrote: > Axel Thimm (Axel.Thimm at ATrpms.net) said: > > Can we assume that the uid/gids < 100 were always considered sacred to > > the users, e.g. only to be set/modified by the vendor and not misused > > for local purposes? In other words, can we assume that these uid/gid > > are under the authority of the "setup" package? > > Yes, absolutely. > > > If we can answer this with yes (which IMHO we should), then we can > > have "setup" upgrade passwd/group by removing all uid/gid < 100 in the > > files found on the system and insert its fresh ones. This would not > > only solve the issues at hand, but is an important mechanism to have > > in place for the "setup" package in general. > > No, you can't. No prereqs allowed that early in the transaction. prereqs? I was thinking more in the line of %post scripts that create a new passwd/group with the most current shipped uid/gid < 100 and save over the >= 100 uid/gids. E.g. (untested) # lock passwd/group file ... # create secure tmpfiles tmpfile_passwd=... ... # initialize with sacred uid/gid content cat /usr/share/setup/passwd > $tmpfile_passwd # filter out all uid < 100 from current passwd and save them over grep -v '^[^:]*:[^:]*:[0-9][0-9]?:' < /etc/passwd >> $tmpfile_passwd # can also use sort -n and sed ...similar with shadow/group/gshadow # cat $tmpfile_passwd > /etc/passwd rm -f $tmpfile_passwd ... # unlock passwd/group That way we could always ensure that if users have installed/upgraded setup the sacred uid/gid space will be properly under our control. -- 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 notting at redhat.com Mon May 14 20:47:28 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 14 May 2007 16:47:28 -0400 Subject: [Fedora-packaging] Re: Second user/group handling draft In-Reply-To: <20070514195314.GS24904@neu.nirvana> References: <200704252219.37024.ville.skytta@iki.fi> <200705121218.09432.ville.skytta@iki.fi> <20070512093147.GC31330@neu.nirvana> <200705121252.05746.ville.skytta@iki.fi> <20070512110328.GD31330@neu.nirvana> <20070514183020.GM5267@nostromo.devel.redhat.com> <20070514195314.GS24904@neu.nirvana> Message-ID: <20070514204728.GJ8473@nostromo.devel.redhat.com> Axel Thimm (Axel.Thimm at ATrpms.net) said: > > No, you can't. No prereqs allowed that early in the transaction. > > prereqs? I was thinking more in the line of %post scripts that create > a new passwd/group with the most current shipped uid/gid < 100 and > save over the >= 100 uid/gids. You said 'have setup upgrade'. setup cannot have scriptlets (and this sort of thing is horribly ugly anyways.) Bill From Axel.Thimm at ATrpms.net Mon May 14 21:03:24 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 14 May 2007 23:03:24 +0200 Subject: [Fedora-packaging] Re: Second user/group handling draft In-Reply-To: <20070514204728.GJ8473@nostromo.devel.redhat.com> References: <200704252219.37024.ville.skytta@iki.fi> <200705121218.09432.ville.skytta@iki.fi> <20070512093147.GC31330@neu.nirvana> <200705121252.05746.ville.skytta@iki.fi> <20070512110328.GD31330@neu.nirvana> <20070514183020.GM5267@nostromo.devel.redhat.com> <20070514195314.GS24904@neu.nirvana> <20070514204728.GJ8473@nostromo.devel.redhat.com> Message-ID: <20070514210324.GV24904@neu.nirvana> On Mon, May 14, 2007 at 04:47:28PM -0400, Bill Nottingham wrote: > Axel Thimm (Axel.Thimm at ATrpms.net) said: > > > No, you can't. No prereqs allowed that early in the transaction. > > > > prereqs? I was thinking more in the line of %post scripts that create > > a new passwd/group with the most current shipped uid/gid < 100 and > > save over the >= 100 uid/gids. > > You said 'have setup upgrade'. setup cannot have scriptlets (and this > sort of thing is horribly ugly anyways.) Well, what do you propose on how to deal with changes in passwd short of requiring the user to run anaconda? Every age and a while there are changes needed after all. -- 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 notting at redhat.com Tue May 15 03:23:36 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 14 May 2007 23:23:36 -0400 Subject: [Fedora-packaging] Re: Second user/group handling draft In-Reply-To: <20070514210324.GV24904@neu.nirvana> References: <200704252219.37024.ville.skytta@iki.fi> <200705121218.09432.ville.skytta@iki.fi> <20070512093147.GC31330@neu.nirvana> <200705121252.05746.ville.skytta@iki.fi> <20070512110328.GD31330@neu.nirvana> <20070514183020.GM5267@nostromo.devel.redhat.com> <20070514195314.GS24904@neu.nirvana> <20070514204728.GJ8473@nostromo.devel.redhat.com> <20070514210324.GV24904@neu.nirvana> Message-ID: <20070515032336.GD14692@nostromo.devel.redhat.com> Axel Thimm (Axel.Thimm at ATrpms.net) said: > > You said 'have setup upgrade'. setup cannot have scriptlets (and this > > sort of thing is horribly ugly anyways.) > > Well, what do you propose on how to deal with changes in passwd short > of requiring the user to run anaconda? Every age and a while there are > changes needed after all. usermod run somewhere else. It's been done before. Obviously, the answer is 'don't break anything in the stock passwd file, and don't add things to it.' Bill From pmatilai at laiskiainen.org Tue May 15 06:42:15 2007 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Tue, 15 May 2007 09:42:15 +0300 (EEST) Subject: [Fedora-packaging] Re: Second user/group handling draft In-Reply-To: <20070514204728.GJ8473@nostromo.devel.redhat.com> References: <200704252219.37024.ville.skytta@iki.fi> <200705121218.09432.ville.skytta@iki.fi> <20070512093147.GC31330@neu.nirvana> <200705121252.05746.ville.skytta@iki.fi> <20070512110328.GD31330@neu.nirvana> <20070514183020.GM5267@nostromo.devel.redhat.com> <20070514195314.GS24904@neu.nirvana> <20070514204728.GJ8473@nostromo.devel.redhat.com> Message-ID: On Mon, 14 May 2007, Bill Nottingham wrote: > Axel Thimm (Axel.Thimm at ATrpms.net) said: >>> No, you can't. No prereqs allowed that early in the transaction. >> >> prereqs? I was thinking more in the line of %post scripts that create >> a new passwd/group with the most current shipped uid/gid < 100 and >> save over the >= 100 uid/gids. > > You said 'have setup upgrade'. setup cannot have scriptlets (and this > sort of thing is horribly ugly anyways.) Well setup *could* use Lua-scriptlets to "do stuff." Whether it's sane or not in this case is another question :) - Panu - From Axel.Thimm at ATrpms.net Tue May 15 07:44:26 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 15 May 2007 09:44:26 +0200 Subject: [Fedora-packaging] Re: Second user/group handling draft In-Reply-To: <20070515032336.GD14692@nostromo.devel.redhat.com> References: <200704252219.37024.ville.skytta@iki.fi> <200705121218.09432.ville.skytta@iki.fi> <20070512093147.GC31330@neu.nirvana> <200705121252.05746.ville.skytta@iki.fi> <20070512110328.GD31330@neu.nirvana> <20070514183020.GM5267@nostromo.devel.redhat.com> <20070514195314.GS24904@neu.nirvana> <20070514204728.GJ8473@nostromo.devel.redhat.com> <20070514210324.GV24904@neu.nirvana> <20070515032336.GD14692@nostromo.devel.redhat.com> Message-ID: <20070515074426.GB19890@neu.nirvana> On Mon, May 14, 2007 at 11:23:36PM -0400, Bill Nottingham wrote: > Axel Thimm (Axel.Thimm at ATrpms.net) said: > > > You said 'have setup upgrade'. setup cannot have scriptlets (and this > > > sort of thing is horribly ugly anyways.) > > > > Well, what do you propose on how to deal with changes in passwd short > > of requiring the user to run anaconda? Every age and a while there are > > changes needed after all. > > usermod run somewhere else. It's been done before. Obviously, the answer > is 'don't break anything in the stock passwd file, and don't add things > to it.' Yes, but where? And do you really want to record all diffs from passwd over time into usermod statements? -- 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 dlutter at redhat.com Tue May 15 10:10:15 2007 From: dlutter at redhat.com (David Lutterkort) Date: Tue, 15 May 2007 12:10:15 +0200 Subject: [Fedora-packaging] Missing today's meeting Message-ID: <1179223815.4286.55.camel@galia.watzmann.net> Unfortunately, I won't be able to come to today's FPC meeting. sorry about that, David From rdieter at math.unl.edu Tue May 15 12:10:18 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 15 May 2007 07:10:18 -0500 Subject: [Fedora-packaging] Re: RFC: Signed JAR Packaging Policy In-Reply-To: <200705141127.50575.jkeating@redhat.com> References: <4642729C.1010105@math.unl.edu> <200705141120.14010.jkeating@redhat.com> <46487F61.9050603@math.unl.edu> <200705141127.50575.jkeating@redhat.com> Message-ID: <4649A32A.6000300@math.unl.edu> Jesse Keating wrote: > On Monday 14 May 2007 11:25:21 Rex Dieter wrote: >> agreed, precisely why I'm trying to come up with mechanisms/policy wrt >> signed .jars in Fedora. :) > > Simple. Fix java so that it operates with an unsigned jar in a > blatantly 'insecure' mode, like a self signed cert in apache. Fine, it's one thing to make jvm's at least usable without signed .jars, but that shouldn't block the bigger issue of finding a workable mechanism to get signed .jars into Fedora packaging. -- Rex From Axel.Thimm at ATrpms.net Tue May 15 12:58:23 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 15 May 2007 14:58:23 +0200 Subject: [Fedora-packaging] Re: Missing today's meeting In-Reply-To: <1179223815.4286.55.camel@galia.watzmann.net> References: <1179223815.4286.55.camel@galia.watzmann.net> Message-ID: <20070515125823.GA2832@neu.nirvana> On Tue, May 15, 2007 at 12:10:15PM +0200, David Lutterkort wrote: > Unfortunately, I won't be able to come to today's FPC meeting. > > sorry about that, > David Me, too. If it comes to voting Ville's current proposal count my +1 in, please. Thanks! -- 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 rc040203 at freenet.de Tue May 15 14:18:00 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 15 May 2007 16:18:00 +0200 Subject: [Fedora-packaging] Re: Missing today's meeting In-Reply-To: <20070515125823.GA2832@neu.nirvana> References: <1179223815.4286.55.camel@galia.watzmann.net> <20070515125823.GA2832@neu.nirvana> Message-ID: <1179238680.4735.494.camel@mccallum.corsepiu.local> On Tue, 2007-05-15 at 14:58 +0200, Axel Thimm wrote: > On Tue, May 15, 2007 at 12:10:15PM +0200, David Lutterkort wrote: > > Unfortunately, I won't be able to come to today's FPC meeting. > > > > sorry about that, > > David > > Me, too. Me very likely, too (There is a small chance I will be able to join in, but things are not settled yet). Ralf From notting at redhat.com Tue May 15 19:29:53 2007 From: notting at redhat.com (Bill Nottingham) Date: Tue, 15 May 2007 15:29:53 -0400 Subject: [Fedora-packaging] Re: Second user/group handling draft In-Reply-To: <20070515074426.GB19890@neu.nirvana> References: <200705121218.09432.ville.skytta@iki.fi> <20070512093147.GC31330@neu.nirvana> <200705121252.05746.ville.skytta@iki.fi> <20070512110328.GD31330@neu.nirvana> <20070514183020.GM5267@nostromo.devel.redhat.com> <20070514195314.GS24904@neu.nirvana> <20070514204728.GJ8473@nostromo.devel.redhat.com> <20070514210324.GV24904@neu.nirvana> <20070515032336.GD14692@nostromo.devel.redhat.com> <20070515074426.GB19890@neu.nirvana> Message-ID: <20070515192953.GB26837@nostromo.devel.redhat.com> Axel Thimm (Axel.Thimm at ATrpms.net) said: > > usermod run somewhere else. It's been done before. Obviously, the answer > > is 'don't break anything in the stock passwd file, and don't add things > > to it.' > > Yes, but where? And do you really want to record all diffs from passwd > over time into usermod statements? Over 'the history of the world',there have been roughly *two* changes. I really don't think it's a big deal. For example, changing the homedir of ftp was done in either wu-ftpd or vsftpd at the time. Bill From petersen at redhat.com Thu May 17 03:57:15 2007 From: petersen at redhat.com (Jens Petersen) Date: Thu, 17 May 2007 13:57:15 +1000 Subject: [Fedora-packaging] Packaging guidelines for Emacsen add-on packages In-Reply-To: <645d17210705070855j1c76a34eoc4f9f65cae2766ec@mail.gmail.com> References: <645d17210705070855j1c76a34eoc4f9f65cae2766ec@mail.gmail.com> Message-ID: <464BD29B.60609@redhat.com> Hi, Jonathan Underwood wrote: > I have placed a draft Guidelines document on the wiki for your > consideration. This document covers the packaging of Emacs and XEmacs > add-on packages, and provides two template spec files with the > intention of lowering the inertial barrier to developing packages for > (X)Emacs. The doc can be found here: > http://fedoraproject.org/wiki/PackagingDrafts/EmacsenAddOns Thanks for doing this. I agree it would be very good to have guidelines for packaging elisp packages. My only comment so far FWIW is that I don't like naming the source packages emacs-common- so much. I think it is a bit confusing with emacs-common (an emacs subpackage) already existing and it makes the source package names rather long. (I just noticed some submitted an emacs-common- package for review...) For me at least it would make more sense just to name the main package emacs- to be honest, and then sure there could still be a emacs--common package and xemacs- package as appropriate. Traditionally that is what we did in the old days when we had elisp packages in RHL. Jens From jonathan.underwood at gmail.com Thu May 17 10:06:54 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Thu, 17 May 2007 11:06:54 +0100 Subject: [Fedora-packaging] Packaging guidelines for Emacsen add-on packages In-Reply-To: <464BD29B.60609@redhat.com> References: <645d17210705070855j1c76a34eoc4f9f65cae2766ec@mail.gmail.com> <464BD29B.60609@redhat.com> Message-ID: <645d17210705170306j3eb78fd1pd638e87513798d64@mail.gmail.com> On 17/05/07, Jens Petersen wrote: > My only comment so far FWIW is that I don't like naming the source > packages emacs-common- so much. I think it is a bit > confusing with emacs-common (an emacs subpackage) already existing > and it makes the source package names rather long. (I just noticed > some submitted an emacs-common- package for review...) > > For me at least it would make more sense just to name the main package > emacs- to be honest, and then sure there could still be a > emacs--common package and xemacs- package as appropriate. > Traditionally that is what we did in the old days when we had elisp > packages in RHL. Jens, I happen to mostly agree with you. However, the guideline I created is taking the package naming guidelines for emacs add-ons as gospel, as this was discussed a lot before being decided on, and the reasons for chosing the current scheme were a bit convoluted. See these threads for the long discussions: https://www.redhat.com/archives/fedora-extras-list/2006-May/msg00262.html (you'll need to read through a fair few posts to see how it evolved) https://www.redhat.com/archives/fedora-extras-list/2006-May/msg00740.html Tom in particular was in favour of the "common" part of the naming scheme, as I recall. Question is, do we want to revisit this? J. From rjones at redhat.com Sat May 19 16:36:33 2007 From: rjones at redhat.com (Richard W.M. Jones) Date: Sat, 19 May 2007 17:36:33 +0100 Subject: OCaml and static linking (was old thread: Re: [Fedora-packaging] Issues with Ocaml and Static Linking) Message-ID: <464F2791.1060309@redhat.com> Toshio Kuratomi wrote: > On Sun, 2007-04-15 at 23:53 +1200, Nigel Jones wrote: >> Nigel Jones wrote: >> > Hi everyone, >> > >> > While putting in a couple of packages for Extras Review I've stumbled >> > into a couple of issues regarding how Ocaml links libraries and how the >> > Fedora Packaging Guidelines are set. >> > >> > My packages in question are: >> > ocamlSDL (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235804) >> > camlimages (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235805) >> > freetennis (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235815) >> > >> > Basically, ocamlSDL and camlimages produce two sets of libraries (a set >> > of dynamic libraries, and another set for development etc), sadly when >> > other packages like freetennis build, they staticly link to libraries >> > such as camlimages/ocamlSDL. >> > >> > I found it semi-suspect when I built freetennis, and hence why I asked >> > on bugzilla when I posted the three packages for review, however I did >> > some more questioning today and after a quick IRC discussion in #ocaml >> > was told: >> > >> > 12/04 13:39 < G> hmmm, .a .cma and .cmxa are all static ocaml libraries >> > right? >> > 12/04 13:44 < Smerdyakov> Those are the two library extensions, yes. >> > 12/04 13:44 < Smerdyakov> Native code OCaml doesn't support dynamic loading. >> > 12/04 13:44 < Smerdyakov> I expect that bytecode uses the same files for >> > dynamic loading as static loading. >> > >> > Looking at my installed files on my laptop, lablgl, lablgtk and labltk >> > (as well as the main ocaml package) store .a, .cma and .cmxa files in >> > /usr/lib/ocaml (and subfolders). >> > >> > As I'm only new to Fedora packaging, could someone please advise on >> > where I should from here on the matter and what the position of FESCO is >> > on Ocaml static libraries, and where I should go from here. >> > >> > Thanks, >> > >> > Nigel Jones >> >> I'm just wondering if anyone has any thoughts on this issue. >> >> I've talked to some more people in #ocaml (Freenode), who suggested that >> I try a patch by the name of 'scaml' which is a year or two old (and >> although can be manually applied to the ocaml source, it does not work >> (problems with assembly which I've not comfortable meddling with). >> >> We'd actually need to downgrade to 3.07 which was removed from Fedora in >> Feb 05 to get the patch working to satisfy the need for dynamic loading >> which I'm sure would upset a few people. >> >> Upstream already have a bug opened stating that they need to fix the >> issue but they have never updated it, or assigned it to anyone. >> >> So my main question is "where to from here?" > > I think, if the ocaml compiler doesn't support dynamic libraries, static > linking would be acceptable. This doesn't mean that we shouldn't press > upstream to add dynamic linking (and convert all our packages when that > becomes available) just an acknowledgment that fixing the limitation has > to be done upstream (it could be done by someone within Fedora but the > fix needs to go upstream). > > This is similar to allowing C libraries in even if they only build > statically. > > If I'm not understanding precisely what the limitation is, feel free to > clarify. There are two issues here: (a) Having OCaml binaries link dynamically instead of statically to OCaml libraries. (b) Writing a dynamic library in OCaml, and having it used by programs written in other languages, particularly C. I suspect it's unlikely that upstream will do (a), ever. There's a technical issue. OCaml really doesn't have a concept of an ABI. It does a kind of whole-program optimisation where even changes to the internal implementation of a library can affect the resulting binary. Moreover even if you "fixed" that, any change whatsoever to the library's signature or the version of compiler it was built with (even bugfix releases which have the same version number) will make the library incompatible. You might also find this entertaining: http://caml.inria.fr/pub/ml-archives/caml-list/2004/05/775714fbf05c17e0cbf5c365d6671704.en.html Another issue which Xavier doesn't mention is the ability to fix a security bug in a shared library, and not require all dependent applications be recompiled. Well, there aren't many (any?) widely used OCaml libraries, and there aren't a lot of binaries which would need to be recompiled either. But it could be a problem for OCaml world domination plans. As for (b), the ability to write libraries in a sane language and have them called through a C API: This almost works. Well, it works well on i386, but there are some problems on x86-64. I'm looking forward to having this. It needs some tools to make it work well - it would be nice to have the C header files and the complex Makefile fragments to get it to work generated automatically. 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 rjones at redhat.com Mon May 21 08:49:56 2007 From: rjones at redhat.com (Richard W.M. Jones) Date: Mon, 21 May 2007 09:49:56 +0100 Subject: OCaml and static linking (was old thread: Re: [Fedora-packaging] Issues with Ocaml and Static Linking) In-Reply-To: <1179663307.8438.30.camel@shinybook.infradead.org> References: <464F2791.1060309@redhat.com> <1179663307.8438.30.camel@shinybook.infradead.org> Message-ID: <46515D34.208@redhat.com> David Woodhouse wrote: > On Sat, 2007-05-19 at 17:36 +0100, Richard W.M. Jones wrote: >> I suspect it's unlikely that upstream will do (a), ever. There's a >> technical issue. OCaml really doesn't have a concept of an ABI. It >> does a kind of whole-program optimisation where even changes to the >> internal implementation of a library can affect the resulting binary. >> Moreover even if you "fixed" that, any change whatsoever to the >> library's signature or the version of compiler it was built with (even >> bugfix releases which have the same version number) will make the >> library incompatible. > > Our current package scheme doesn't handle this at all, does it? Should > our ocaml-*-devel packages have runtime Requires: on the precise n-v-r > of ocaml used to build them? Yes definitely. In fact any other behaviour is broken. (All packages should have this Requires -- I'm not sure why you elected for just the -devel packages). Furthermore, if one library or program depends on another library, then it must contain a dependency on the precise n-v-r of the library. The only reason I didn't do it for the four packages I just put up for review is that I couldn't work out _how_ to do it in the spec file :-( [My packages for review: http://tinyurl.com/2rl4w6] Example: ocaml-3.09.3-1 ocaml-pcre-5.11.4-1 Requires: ocaml = 3.09.3-1 ocaml-extlib-1.5-1 Requires: ocaml = 3.09.3-1 cocanwiki-1.4.3-1 Requires: ocaml-pcre = 5.11.4-1, ocaml-extlib = 1.5-1, ocaml = 3.09.3-1 The final package requires the precise versions of the two libraries it was built against, plus the precise version of OCaml that it was built with. I don't know how well this will interact with the Fedora build system. For instance if a new version of a fairly fundamental library (eg. ocaml itself, or something like ocaml-pcre) is released, everything which depends on that has to be recompiled. This is something of a perpetual problem for the Debian folks. At one point I remember that OCaml in Ubuntu was really broken, apparently because they'd taken packages from upstream Debian half way through a transition like this, so some packages were compiled against one version of ocaml-pcre, and others against another version, with the result that you couldn't use certain combinations of libraries if the libraries depended on different ocaml-pcre. 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 rjones at redhat.com Mon May 21 11:00:23 2007 From: rjones at redhat.com (Richard W.M. Jones) Date: Mon, 21 May 2007 12:00:23 +0100 Subject: OCaml and static linking (was old thread: Re: [Fedora-packaging] Issues with Ocaml and Static Linking) In-Reply-To: <46515D34.208@redhat.com> References: <464F2791.1060309@redhat.com> <1179663307.8438.30.camel@shinybook.infradead.org> <46515D34.208@redhat.com> Message-ID: <46517BC7.3010401@redhat.com> Richard W.M. Jones wrote: > David Woodhouse wrote: >> On Sat, 2007-05-19 at 17:36 +0100, Richard W.M. Jones wrote: >>> I suspect it's unlikely that upstream will do (a), ever. There's a >>> technical issue. OCaml really doesn't have a concept of an ABI. It >>> does a kind of whole-program optimisation where even changes to the >>> internal implementation of a library can affect the resulting binary. >>> Moreover even if you "fixed" that, any change whatsoever to the >>> library's signature or the version of compiler it was built with >>> (even bugfix releases which have the same version number) will make >>> the library incompatible. >> >> Our current package scheme doesn't handle this at all, does it? Should >> our ocaml-*-devel packages have runtime Requires: on the precise n-v-r >> of ocaml used to build them? > > Yes definitely. In fact any other behaviour is broken. (All packages > should have this Requires -- I'm not sure why you elected for just the > -devel packages). Furthermore, if one library or program depends on > another library, then it must contain a dependency on the precise n-v-r > of the library. > > The only reason I didn't do it for the four packages I just put up for > review is that I couldn't work out _how_ to do it in the spec file :-( Looking at this a bit closer, seems like we need an OCaml version of "find-requires" and "find-provides"? There is a program called objinfo (packaged in Debian as "ocamlobjinfo"). This isn't part of our RPM, but it should be. You can get this program by building OCaml from the current SRPM, then: cd ~/rpmbuild/BUILD/ocaml-3.09.3 cd tools make objinfo cp objinfo ~/bin/ocamlobjinfo Now, a bit of background first. When OCaml builds a module, it takes a MD5 hash over the interface and some of the internals. It also stores in the module the MD5 hashes of any modules that it depends upon. At link time the MD5 hashes are compared, and the link is only allowed to proceed if they match. You can use ocamlobjinfo to find the hashes of modules (and what they depend upon). For example: $ ocamlobjinfo /usr/lib64/ocaml/calendar/calendar.cma gives output like this (heavily cut down): Unit name: Time_Zone Interfaces imported: 71f888453b0f26895819460a72f07493 Pervasives 1876ce678cfa5a1961fac21850f71efd Unix 8d84727c6f398e1a8b710d8161e26479 Time_Zone This means that the library file calendar.cma contains a module called Time_Zone. Time_Zone depends on two modules from the stdlib (Pervasives and Unix) and gives the expected MD5 hashes of those modules. It also gives the MD5 hash of the Time_Zone module itself. Confusingly the hashes of the module and its dependencies are all mixed up... Parsing the output of ocamlobjinfo is annoying. So my first idea was to write a "ocaml-find-requires.sh" script which would look at the output of ocamlobjinfo and try to work out which files (and therefore RPMs) a library depends upon. This turned out to be quite difficult because of the problem of what if a library is already installed. Anyhow I had (I think) a much better idea ... How about we store the actual module names and MD5 sums as actual provides and requires? So for example the base ocaml module would provide: ocaml-Pervasives-71f888453b0f26895819460a72f07493 ocaml-Unix-1876ce678cfa5a1961fac21850f71efd and the ocaml-calendar module would require the above, as well as providing: ocaml-Time_Zone-8d84727c6f398e1a8b710d8161e26479 (It would still need to depend on the exact n-v-r of the ocaml compiler). So RPM enforces the exact same dependency requirements as OCaml itself. Hopefully with such a scheme it would be impossible to install incompatible OCaml modules, at least not without forcing them. Attached are two candidate ocaml-find-requires.sh and ocaml-find-provides.sh scripts. $ echo /usr/lib64/ocaml/calendar/calendar.cma | ./ocaml-find-requires.sh ocaml-Array-a904b798dd9665c2d3635636d293403c ocaml-Buffer-45f466ce46f213dae41be77dd8505f5f ocaml-Format-67f81fa527012cf0f70f6f6a24f07417 ocaml-Lazy-27baa9469b2986a6ccbba3e85275ecf1 ocaml-List-5a0e3217fc356bd18f60bff31861dfd3 ocaml-Period-d99e051c4c63bb80cd2586ea99584429 ocaml-Pervasives-71f888453b0f26895819460a72f07493 ocaml-Str-8a11c5ef144a995903cc9e1bac5e353c ocaml-String-fec8292bb1a02d2c7b8b4ba7b83a7d8b ocaml-Unix-1876ce678cfa5a1961fac21850f71efd ocaml = 3.09.3-1.fc6 $ echo /usr/lib64/ocaml/calendar/calendar.cma | ./ocaml-find-provides.sh ocaml-Calendar-514a56b1c3e9c1e5139e81e0e2736ab8 ocaml-Date-0b9d8d46ec722919ef4a2b4f7576d8f1 ocaml-Printer-de9afc53dc6db958fdf5927dc86df9aa ocaml-Time-1b657b86bb0e7ba36acf02910897b2eb ocaml-Time_Zone-8d84727c6f398e1a8b710d8161e26479 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: ocaml-find-provides.sh Type: application/x-shellscript Size: 624 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ocaml-find-requires.sh Type: application/x-shellscript Size: 783 bytes Desc: not available URL: -------------- 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 rjones at redhat.com Mon May 21 15:54:49 2007 From: rjones at redhat.com (Richard W.M. Jones) Date: Mon, 21 May 2007 16:54:49 +0100 Subject: OCaml and static linking (was old thread: Re: [Fedora-packaging] Issues with Ocaml and Static Linking) In-Reply-To: <1179761555.2771.6.camel@shinybook.infradead.org> References: <464F2791.1060309@redhat.com> <1179663307.8438.30.camel@shinybook.infradead.org> <46515D34.208@redhat.com> <46517BC7.3010401@redhat.com> <1179761555.2771.6.camel@shinybook.infradead.org> Message-ID: <4651C0C9.8010104@redhat.com> David Woodhouse wrote: > On Mon, 2007-05-21 at 12:00 +0100, Richard W.M. Jones wrote: >> Now, a bit of background first. When OCaml builds a module, it takes a >> MD5 hash over the interface and some of the internals. It also stores >> in the module the MD5 hashes of any modules that it depends upon. At >> link time the MD5 hashes are compared, and the link is only allowed to >> proceed if they match. > > Hm. Can we use this to make dynamic linking work safely too? If you mean Dynlink (the bytecode-only dynamic linker), then that uses the same hashing scheme and has the same requirements (matching hashes, matching compiler). So yes. 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 petersen at redhat.com Tue May 22 01:57:50 2007 From: petersen at redhat.com (Jens Petersen) Date: Tue, 22 May 2007 11:57:50 +1000 Subject: [Fedora-packaging] Packaging guidelines for Emacsen add-on packages In-Reply-To: <645d17210705170306j3eb78fd1pd638e87513798d64@mail.gmail.com> References: <645d17210705070855j1c76a34eoc4f9f65cae2766ec@mail.gmail.com> <464BD29B.60609@redhat.com> <645d17210705170306j3eb78fd1pd638e87513798d64@mail.gmail.com> Message-ID: <46524E1E.3020508@redhat.com> Jonathan Underwood ????????: > Jens, I happen to mostly agree with you. However, the guideline I > created is taking the package naming guidelines for emacs add-ons as > gospel, as this was discussed a lot before being decided on, and the > reasons for chosing the current scheme were a bit convoluted. See > these threads for the long discussions: > > https://www.redhat.com/archives/fedora-extras-list/2006-May/msg00262.html > (you'll need to read through a fair few posts to see how it evolved) > https://www.redhat.com/archives/fedora-extras-list/2006-May/msg00740.html Ok thanks, that clarifies the status quo. > Tom in particular was in favour of the "common" part of the naming > scheme, as I recall. I still think the emacs-common prefix is confusing with the emacs-common package but I should have made that comment a year ago I guess. ;-) There are alternative prefix's (elisp or emacsen) that could be (have been) used but perhaps it is too late now? IMHO it would be better to avoid hyphened prefixes in package naming afap possible in the future. Jens From a.badger at gmail.com Tue May 22 03:47:56 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 21 May 2007 20:47:56 -0700 Subject: [Fedora-packaging] Draft Changes to static libraries Message-ID: <1179805676.5161.66.camel@localhost.localdomain> I've written a draft of changes to the static library guidelines:: http://fedoraproject.org/wiki/PackagingDrafts/StaticLibraryChanges There are three pieces which can be voted on separately or together depending on how controversial they are: 1) Separate static library inclusion from static library linkage and make static library inclusion less strict. 2) Change how to package static libraries when the package does not include dynamic libraries (per Ralf's note to the list) 3) Incorporate mschwendt's note about *.la files directly into the guidelines instead of as a footnote. Comments welcome. == Exclusion of Static Libraries == Packages including libraries should exclude static libs as far as possible (eg by configuring with ''--disable-static''). Static libraries should only be included in exceptional circumstances. Applications linking against libraries should as far as possible link against shared libraries not static versions. Libtool archives, ''foo.la'' files, should not be included. Packages using libtool will install these by default even if you configure with ''--disable-static'', so they may need to be removed before packaging. Due to bugs in older versions of libtool or bugs in programs that use it, there are times when it is not always possible to remove *.la files without modifying the program. In most cases it is fairly easy to work with upstream to fix these issues. === Packaging Static Libraries === * In general, packagers are strongly encouraged not to ship static libs unless a compelling reason exists. * We want to be able to track which packages are using static libraries (so we can find which packages need to be rebuilt if a security flaw in a static library is fixed, for instance.) * When a package provides both dynamic and static libraries the static libraries must be placed in a ''*-static'' subpackage. Separating the static libs from the other development files in ''*-devel'' allow us to track this usage by checking which packages Build''''''Require the ''*-static'' package. * When a package only provides static libraries you can place all the files in the ''*-devel'' subpackage. When doing this you also have to have a virtual Provide for the static package: {{{ %package devel Provides: foo-static = %{version}-%{release} }}} This way other packages which will link against a dynamic library when your package starts providing one can {{{BuildRequire: foo-devel}}} and packages which explicitly need to link against the static version can {{{BuildRequire: foo-static}}} === Staticly Linking Executables === * Static linkage is a special exception and should be decided on a case-by-case basis. The packager must provide rationale for linking statically, including precedences where available, to FESCO for approval. -Toshio -------------- 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 a.badger at gmail.com Tue May 22 03:55:48 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 21 May 2007 20:55:48 -0700 Subject: OCaml and static linking (was old thread: Re: [Fedora-packaging] Issues with Ocaml and Static Linking) In-Reply-To: <464F2791.1060309@redhat.com> References: <464F2791.1060309@redhat.com> Message-ID: <1179806148.5161.72.camel@localhost.localdomain> On Sat, 2007-05-19 at 17:36 +0100, Richard W.M. Jones wrote: > Toshio Kuratomi wrote: > > I think, if the ocaml compiler doesn't support dynamic libraries, static > > linking would be acceptable. This doesn't mean that we shouldn't press > > upstream to add dynamic linking (and convert all our packages when that > > becomes available) just an acknowledgment that fixing the limitation has > > to be done upstream (it could be done by someone within Fedora but the > > fix needs to go upstream). > > > > This is similar to allowing C libraries in even if they only build > > statically. > > > > If I'm not understanding precisely what the limitation is, feel free to > > clarify. > > There are two issues here: (a) Having OCaml binaries link dynamically > instead of statically to OCaml libraries. (b) Writing a dynamic library > in OCaml, and having it used by programs written in other languages, > particularly C. > > I suspect it's unlikely that upstream will do (a), ever. There's a > technical issue. OCaml really doesn't have a concept of an ABI. It > does a kind of whole-program optimisation where even changes to the > internal implementation of a library can affect the resulting binary. > Moreover even if you "fixed" that, any change whatsoever to the > library's signature or the version of compiler it was built with (even > bugfix releases which have the same version number) will make the > library incompatible. > > You might also find this entertaining: > > http://caml.inria.fr/pub/ml-archives/caml-list/2004/05/775714fbf05c17e0cbf5c365d6671704.en.html > > Another issue which Xavier doesn't mention is the ability to fix a > security bug in a shared library, and not require all dependent > applications be recompiled. Well, there aren't many (any?) widely used > OCaml libraries, and there aren't a lot of binaries which would need to > be recompiled either. But it could be a problem for OCaml world > domination plans. > > As for (b), the ability to write libraries in a sane language and have > them called through a C API: This almost works. Well, it works well on > i386, but there are some problems on x86-64. I'm looking forward to > having this. It needs some tools to make it work well - it would be > nice to have the C header files and the complex Makefile fragments to > get it to work generated automatically. Could you add something to http://fedoraproject.org/wiki/PackagingDrafts/OCaml about this? I'd imagine we'd need to say something like "OCaml packages must have a strict Requires: on the version and release of ocaml" with some examples. And something should be said about rebuilding OCaml packages when libraries they depend on are updated as well so that security problems and bugfixes are incorporated into the new package. Thanks, -Toshio -------------- 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 May 22 06:13:18 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 22 May 2007 08:13:18 +0200 Subject: [Fedora-packaging] Draft Changes to static libraries In-Reply-To: <1179805676.5161.66.camel@localhost.localdomain> References: <1179805676.5161.66.camel@localhost.localdomain> Message-ID: <1179814398.4735.1396.camel@mccallum.corsepiu.local> On Mon, 2007-05-21 at 20:47 -0700, Toshio Kuratomi wrote: > I've written a draft of changes to the static library guidelines:: > http://fedoraproject.org/wiki/PackagingDrafts/StaticLibraryChanges > > There are three pieces which can be voted on separately or together > depending on how controversial they are: > 1) Separate static library inclusion from static library linkage and > make static library inclusion less strict. > 2) Change how to package static libraries when the package does not > include dynamic libraries (per Ralf's note to the list) > 3) Incorporate mschwendt's note about *.la files directly into the > guidelines instead of as a footnote. > > Comments welcome. +1 +1 +1 One comment interspersed below, also I'd like so see another addition: "Development libraries" (libraries not being used at runtime) must not be packaged in /%{_lib}. If a package needs "runtime libs in /%{_lib} (Normally lib*.so.* being used by applications which shall be run at times when /usr might not be available, typically apps being used at bootup), the corresponding development libraries (Normally: lib*.so and *.a) should be packaged into %{_libdir} > == Exclusion of Static Libraries == > Packages including libraries should exclude static libs as far as > possible (eg by configuring with ''--disable-static''). Static > libraries should only be included in exceptional circumstances. > Applications linking against libraries should as far as possible link > against shared libraries not static versions. > > Libtool archives, ''foo.la'' files, should not be included. Packages > using libtool will install these by default even if you configure with > ''--disable-static'', so they may need to be removed before packaging. > Due to bugs in older versions of libtool or bugs in programs that use > it, there are times when it is not always possible to remove *.la files > without modifying the program. In most cases it is fairly easy to work > with upstream to fix these issues. If a Fedora release had been shipped with lib*.la's they must not be removed during this Fedora release's life-time. > === Packaging Static Libraries === > * In general, packagers are strongly encouraged not to ship static libs > unless a compelling reason exists. > > * We want to be able to track which packages are using static libraries > (so we can find which packages need to be rebuilt if a security flaw in > a static library is fixed, for instance.) > * When a package provides both dynamic and static libraries the static > libraries must be placed in a ''*-static'' subpackage. Separating the > static libs from the other development files in ''*-devel'' allow us to > track this usage by checking which packages Build''''''Require the > ''*-static'' package. > * When a package only provides static libraries you can place all the > files in the ''*-devel'' subpackage. When doing this you also have to > have a virtual Provide for the static package: > {{{ > %package devel > Provides: foo-static = %{version}-%{release} > }}} > This way other packages which will link against a dynamic library when > your package starts providing one can {{{BuildRequire: foo-devel}}} and > packages which explicitly need to link against the static version can > {{{BuildRequire: foo-static}}} > > === Staticly Linking Executables === > * Static linkage is a special exception and should be decided on a > case-by-case basis. The packager must provide rationale for linking > statically, including precedences where available, to FESCO for > approval. Ralf From rjones at redhat.com Tue May 22 07:32:46 2007 From: rjones at redhat.com (Richard W.M. Jones) Date: Tue, 22 May 2007 08:32:46 +0100 Subject: OCaml and static linking (was old thread: Re: [Fedora-packaging] Issues with Ocaml and Static Linking) In-Reply-To: <1179806148.5161.72.camel@localhost.localdomain> References: <464F2791.1060309@redhat.com> <1179806148.5161.72.camel@localhost.localdomain> Message-ID: <46529C9E.4070003@redhat.com> Toshio Kuratomi wrote: > Could you add something to > http://fedoraproject.org/wiki/PackagingDrafts/OCaml > about this? I'd imagine we'd need to say something like "OCaml packages > must have a strict Requires: on the version and release of ocaml" with > some examples. And something should be said about rebuilding OCaml > packages when libraries they depend on are updated as well so that > security problems and bugfixes are incorporated into the new package. Yes ... Revising that page is next on my list of things to do - it's totally wrong. However before I do that I would like to have someone look over my spec files - see: http://tinyurl.com/2rl4w6 (goes to a long bugzilla URL). 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 rjones at redhat.com Tue May 22 07:36:36 2007 From: rjones at redhat.com (Richard W.M. Jones) Date: Tue, 22 May 2007 08:36:36 +0100 Subject: [Fedora-packaging] Draft Changes to static libraries In-Reply-To: <1179805676.5161.66.camel@localhost.localdomain> References: <1179805676.5161.66.camel@localhost.localdomain> Message-ID: <46529D84.40407@redhat.com> Toshio Kuratomi wrote: > == Exclusion of Static Libraries == Can we exclude OCaml from this, because upstream are highly unlikely to add full support for dynamic linking. > === Packaging Static Libraries === This one looks OK (from an OCaml p.o.v.) > === Staticly Linking Executables === Again, OCaml binaries are always statically linked to OCaml libraries (not to the C libraries they may use however). 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 jonathan.underwood at gmail.com Tue May 22 09:29:27 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Tue, 22 May 2007 10:29:27 +0100 Subject: [Fedora-packaging] Packaging guidelines for Emacsen add-on packages In-Reply-To: <46524E1E.3020508@redhat.com> References: <645d17210705070855j1c76a34eoc4f9f65cae2766ec@mail.gmail.com> <464BD29B.60609@redhat.com> <645d17210705170306j3eb78fd1pd638e87513798d64@mail.gmail.com> <46524E1E.3020508@redhat.com> Message-ID: <645d17210705220229n48bfacadh5f8f5c479f04476e@mail.gmail.com> On 22/05/07, Jens Petersen wrote: > I still think the emacs-common prefix is confusing with the emacs-common > package but I should have made that comment a year ago I guess. ;-) > There are alternative prefix's (elisp or emacsen) that could be (have > been) used but perhaps it is too late now? IMHO it would be better to > avoid hyphened prefixes in package naming afap possible in the future. Jens, you're of course right. The fact that emacs-common is a subpackage of emacs didn't come up during the discussions a year ago. I did try for "emacsen" but people didn't like that so much, am not sure why. Anyway, I'm happy to revisit the package naming guidelines for (X)Emacs add-ons, Jens seems inclined to do so. Does anyone else have strong feelings either way? Jonathan From tcallawa at redhat.com Tue May 22 12:47:36 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 22 May 2007 07:47:36 -0500 Subject: [Fedora-packaging] Packaging guidelines for Emacsen add-on packages In-Reply-To: <645d17210705220229n48bfacadh5f8f5c479f04476e@mail.gmail.com> References: <645d17210705070855j1c76a34eoc4f9f65cae2766ec@mail.gmail.com> <464BD29B.60609@redhat.com> <645d17210705170306j3eb78fd1pd638e87513798d64@mail.gmail.com> <46524E1E.3020508@redhat.com> <645d17210705220229n48bfacadh5f8f5c479f04476e@mail.gmail.com> Message-ID: <1179838056.6254.266.camel@localhost.localdomain> On Tue, 2007-05-22 at 10:29 +0100, Jonathan Underwood wrote: > On 22/05/07, Jens Petersen wrote: > > I still think the emacs-common prefix is confusing with the emacs-common > > package but I should have made that comment a year ago I guess. ;-) > > There are alternative prefix's (elisp or emacsen) that could be (have > > been) used but perhaps it is too late now? IMHO it would be better to > > avoid hyphened prefixes in package naming afap possible in the future. > > Jens, you're of course right. The fact that emacs-common is a > subpackage of emacs didn't come up during the discussions a year ago. > I did try for "emacsen" but people didn't like that so much, am not > sure why. > > Anyway, I'm happy to revisit the package naming guidelines for > (X)Emacs add-ons, Jens seems inclined to do so. Does anyone else have > strong feelings either way? I'm not convinced that emacs-common-foo is broken as a naming scheme. It seems more intuitive than emacsen to me. Then again, I'm not an emacs user. ~spot From pertusus at free.fr Tue May 22 17:31:30 2007 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 22 May 2007 19:31:30 +0200 Subject: [Fedora-packaging] Draft Changes to static libraries In-Reply-To: <1179805676.5161.66.camel@localhost.localdomain> References: <1179805676.5161.66.camel@localhost.localdomain> Message-ID: <20070522173130.GA4650@free.fr> On Mon, May 21, 2007 at 08:47:56PM -0700, Toshio Kuratomi wrote: > > == Exclusion of Static Libraries == > Applications linking against libraries should as far as possible link > against shared libraries not static versions. I think it could be even stricter, like When there are shared and static libraries, applications should link against shared libraries except for exceptionnal circumstances, like dynamically linked applications being non-functionnal. I am perfectly happy with this draft. I will try to work on a paragraph trying to explain the case of numerical libs/portability and so on to provide guidance on this kind of 'exceptionnal circumstances'. -- Pat From mlichvar at redhat.com Thu May 24 13:40:25 2007 From: mlichvar at redhat.com (Miroslav Lichvar) Date: Thu, 24 May 2007 15:40:25 +0200 Subject: [Fedora-packaging] Exit status in rpm scriptlets Message-ID: <20070524134025.GA22658@localhost> >From http://fedoraproject.org/wiki/Packaging/ScriptletSnippets: "Most commands in the snippets in this document have a "|| :" appended to them. This little piece of code causes each such command to exit with a successful exit status whether or not the command worked. This is important because the scriptlet as a whole will error the moment it tries to execute a command that has a non-zero exit status." That's not quite correct, at least with rpm we have in Fedora. Scriptlets (contrary to build scripts) are not actually executed through sh -e, therefore a failed command won't cause the whole scriptlet to fail. Only the last command executed matters. Generally we want to have scriptlets that always succeed, so added "|| :" doesn't break anything, but in case where we want to fail the installation of the package (as in UsersAndGroups packaging draft that wants to abort installation if required user isn't available) this doesn't work as one might expect. For scriptlets that should always return 0 just add : as the last line of the script and add "|| exit 1" to a command that should abort the whole script when failed. -- Miroslav Lichvar From rjones at redhat.com Fri May 25 19:01:57 2007 From: rjones at redhat.com (Richard W.M. Jones) Date: Fri, 25 May 2007 20:01:57 +0100 Subject: [Fedora-packaging] Meaning of -devel Message-ID: <465732A5.7050903@redhat.com> Is there a policy which describes precisely what should go into a -devel subpackage? Here is an example case where I'm unsure: In OCaml there's a thing called the "toplevel". Think of it as being like the python command line (where you just type "python" on its own, then start typing in Python expressions). $ ocaml -I +calendar Objective Caml version 3.09.3 # #load "unix.cma";; # #load "str.cma";; # #load "calendar.cma";; # let d = Printer.DatePrinter.from_string "2007-01-01";; val d : Printer.DatePrinter.t = # Printer.DatePrinter.to_string (Date.next d `Week);; - : string = "2007-01-08" So my question: If I'm packaging ocaml-calendar (a library) then should the parts which make the above possible go into the main package or ocaml-calendar-devel? Note that as far as I can see in Python -- and I'm not hugely familiar with that language so forgive me if I've made a mistake -- but it seems they go in the main package. Another thing is that if I move the parts into the -devel subpackage, then ocaml-calendar will literally be empty! 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 tcallawa at redhat.com Fri May 25 19:05:20 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Fri, 25 May 2007 14:05:20 -0500 Subject: [Fedora-packaging] Meaning of -devel In-Reply-To: <465732A5.7050903@redhat.com> References: <465732A5.7050903@redhat.com> Message-ID: <1180119920.6254.381.camel@localhost.localdomain> On Fri, 2007-05-25 at 20:01 +0100, Richard W.M. Jones wrote: > Is there a policy which describes precisely what should go into a -devel > subpackage? > > Here is an example case where I'm unsure: > > In OCaml there's a thing called the "toplevel". Think of it as being > like the python command line (where you just type "python" on its own, > then start typing in Python expressions). > > $ ocaml -I +calendar > Objective Caml version 3.09.3 > > # #load "unix.cma";; > > # #load "str.cma";; > > # #load "calendar.cma";; > > # let d = Printer.DatePrinter.from_string "2007-01-01";; > > val d : Printer.DatePrinter.t = > # Printer.DatePrinter.to_string (Date.next d `Week);; > > - : string = "2007-01-08" > > So my question: If I'm packaging ocaml-calendar (a library) then should > the parts which make the above possible go into the main package or > ocaml-calendar-devel? We've already determined that OCaml is ... special. Here's the rule of thumb I've always used: In the traditional library/binary model: The main package is for libraries and components that another binary would need to execute. I can't _run_ foo without libbar.so.6 being present. The -devel package is for headers and components that are needed to build that binary. I can't _build_ foo without bar.h being present. So, in the OCaml universe, I'd say those .cma files fall into the main package, as I can't run _foo_ without those .cma files present. Note that I know absolutely NOTHING about OCaml besides what you've told me. ~spot From rjones at redhat.com Fri May 25 19:21:44 2007 From: rjones at redhat.com (Richard W.M. Jones) Date: Fri, 25 May 2007 20:21:44 +0100 Subject: [Fedora-packaging] Meaning of -devel In-Reply-To: <1180119920.6254.381.camel@localhost.localdomain> References: <465732A5.7050903@redhat.com> <1180119920.6254.381.camel@localhost.localdomain> Message-ID: <46573748.6010102@redhat.com> Tom "spot" Callaway wrote: > On Fri, 2007-05-25 at 20:01 +0100, Richard W.M. Jones wrote: >> So my question: If I'm packaging ocaml-calendar (a library) then should >> the parts which make the above possible go into the main package or >> ocaml-calendar-devel? > > We've already determined that OCaml is ... special. Thanks for your prompt reply! > Here's the rule of thumb I've always used: > > In the traditional library/binary model: > > The main package is for libraries and components that another binary > would need to execute. I can't _run_ foo without libbar.so.6 being > present. > > The -devel package is for headers and components that are needed to > build that binary. I can't _build_ foo without bar.h being present. > > So, in the OCaml universe, I'd say those .cma files fall into the main > package, as I can't run _foo_ without those .cma files present. In fact because OCaml binaries are statically linked to OCaml libraries foo doesn't require anything to run. The *.cma file is a bit more like a *.a file, but as ever the parallels aren't precise. However by the sounds of it, it seems that everything should go in -devel. Is it a problem if the main package is completely empty? > Note that I know absolutely NOTHING about OCaml besides what you've told > me. I've been programming in OCaml nearly exclusively for 4 years, and even _I_ don't know all the ins and outs of the various files used. Mostly this stuff just happens. I had to 'strace' the toplevel running to see which files it needed. 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 tcallawa at redhat.com Fri May 25 19:37:25 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Fri, 25 May 2007 14:37:25 -0500 Subject: [Fedora-packaging] Meaning of -devel In-Reply-To: <46573748.6010102@redhat.com> References: <465732A5.7050903@redhat.com> <1180119920.6254.381.camel@localhost.localdomain> <46573748.6010102@redhat.com> Message-ID: <1180121845.6254.386.camel@localhost.localdomain> On Fri, 2007-05-25 at 20:21 +0100, Richard W.M. Jones wrote: > However by the sounds of it, it seems that everything should go in > -devel. Is it a problem if the main package is completely empty? If the main package is empty, don't make one. Just have a -devel section in %files and it won't make a main package, only an SRPM with the main name. ~spot From pertusus at free.fr Fri May 25 19:37:25 2007 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 25 May 2007 21:37:25 +0200 Subject: [Fedora-packaging] Meaning of -devel In-Reply-To: <46573748.6010102@redhat.com> References: <465732A5.7050903@redhat.com> <1180119920.6254.381.camel@localhost.localdomain> <46573748.6010102@redhat.com> Message-ID: <20070525193725.GB2902@free.fr> On Fri, May 25, 2007 at 08:21:44PM +0100, Richard W.M. Jones wrote: > > However by the sounds of it, it seems that everything should go in > -devel. Is it a problem if the main package is completely empty? No, it is not a problem, and it looks like it is the way to go in your case. When there is only a static library in a package the main package is empty. -- Pat From a.badger at gmail.com Fri May 25 19:53:12 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 25 May 2007 12:53:12 -0700 Subject: [Fedora-packaging] Meaning of -devel In-Reply-To: <46573748.6010102@redhat.com> References: <465732A5.7050903@redhat.com> <1180119920.6254.381.camel@localhost.localdomain> <46573748.6010102@redhat.com> Message-ID: <1180122792.22279.52.camel@localhost.localdomain> On Fri, 2007-05-25 at 20:21 +0100, Richard W.M. Jones wrote: > Tom "spot" Callaway wrote: > > Here's the rule of thumb I've always used: > > > > In the traditional library/binary model: > > > > The main package is for libraries and components that another binary > > would need to execute. I can't _run_ foo without libbar.so.6 being > > present. > > > > The -devel package is for headers and components that are needed to > > build that binary. I can't _build_ foo without bar.h being present. > > > > So, in the OCaml universe, I'd say those .cma files fall into the main > > package, as I can't run _foo_ without those .cma files present. > > In fact because OCaml binaries are statically linked to OCaml libraries > foo doesn't require anything to run. > > The *.cma file is a bit more like a *.a file, but as ever the parallels > aren't precise. > You have an interesting case here. Like spot, I lean towards the *.cma files being available from the main (non-devel) package as the toplevel and interpreted OCaml scripts won't run without them. They are loadable modules in this sense. The fact that they are also included statically in compiled OCaml programs seems to be a red herring for this decision but I'm sure their dual nature will raise other interesting issues later. -Toshio -------------- 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 rjones at redhat.com Fri May 25 21:10:12 2007 From: rjones at redhat.com (Richard W.M. Jones) Date: Fri, 25 May 2007 22:10:12 +0100 Subject: [Fedora-packaging] Meaning of -devel In-Reply-To: <1180122792.22279.52.camel@localhost.localdomain> References: <465732A5.7050903@redhat.com> <1180119920.6254.381.camel@localhost.localdomain> <46573748.6010102@redhat.com> <1180122792.22279.52.camel@localhost.localdomain> Message-ID: <465750B4.50401@redhat.com> Toshio Kuratomi wrote: > On Fri, 2007-05-25 at 20:21 +0100, Richard W.M. Jones wrote: >> Tom "spot" Callaway wrote: >>> Here's the rule of thumb I've always used: >>> >>> In the traditional library/binary model: >>> >>> The main package is for libraries and components that another binary >>> would need to execute. I can't _run_ foo without libbar.so.6 being >>> present. >>> >>> The -devel package is for headers and components that are needed to >>> build that binary. I can't _build_ foo without bar.h being present. >>> >>> So, in the OCaml universe, I'd say those .cma files fall into the main >>> package, as I can't run _foo_ without those .cma files present. >> In fact because OCaml binaries are statically linked to OCaml libraries >> foo doesn't require anything to run. >> >> The *.cma file is a bit more like a *.a file, but as ever the parallels >> aren't precise. >> > You have an interesting case here. Like spot, I lean towards the *.cma > files being available from the main (non-devel) package as the toplevel > and interpreted OCaml scripts won't run without them. They are loadable > modules in this sense. Of course I'd completely forgotten about OCaml scripts ... They're not used very often, but they are an argument for putting the *.cma and *.cmi files into the main package. Here's an example of an OCaml script, albeit one which in this case doesn't use any external libraries (but in general they can do): http://en.wikipedia.org/wiki/Objective_CAML#Birthday_paradox > The fact that they are also included statically in compiled OCaml > programs seems to be a red herring for this decision but I'm sure their > dual nature will raise other interesting issues later. After playing around with strace, I'm pretty sure that it's safe just to put the *.cma, *.cmi and *.so files (if present) into the main package, to get the toplevel and scripts working. That is what I did in these spec files: http://annexia.org/tmp/ocaml-extlib.spec [https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=240655] http://annexia.org/tmp/ocaml-calendar.spec [https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=240571] http://annexia.org/tmp/ocaml-pcre.spec [https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=240652] 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 pertusus at free.fr Sat May 26 10:41:56 2007 From: pertusus at free.fr (Patrice Dumas) Date: Sat, 26 May 2007 12:41:56 +0200 Subject: [Fedora-packaging] paragraph on shipping static numerical libs Message-ID: <20070526104156.GB3105@free.fr> Hello, Here is a paragraph explaining why some libs may be usefull in their static version: * in the case of user compiled programs doing numerical computations or data analysis, using static libraries may be useful. Indeed it allows to build static executables that have more chance to be run on other platforms than the box they were compiled in, that have different dynamic library versions or even that don't have the library installed at all. At the same time those applications, in general, don't need the features brought in by shared libraries (no need for nss, no security issue, no need for iconv...). Therefore it may be acceptable or even desirable to ship static libraries for numerical and data processing libraries to help users needing to link statically their locally compiled executables. The static libraries still need to be in separate sub-packages. -- Pat From pertusus at free.fr Sat May 26 13:05:43 2007 From: pertusus at free.fr (Patrice Dumas) Date: Sat, 26 May 2007 15:05:43 +0200 Subject: [Fedora-packaging] tricks for multilib proposal Message-ID: <20070526130543.GD3105@free.fr> Hello, I propose the following with tricks for packaging multilibs. It tries to be a summary of a thread about multilibs. There may be mistakes, or statements everybody doesn't agree with, so please comment. This is pseudo wiki and I don't know where it should be put in the wiki. = Multi lib tricks = == Architecture independent files == For architecture independent the conflicts should be avoided, so the files should be identical among arches. It may involve some work with upstream when header files include architecture specific files, for example header files which contains autoconf conditionals like HAVE_INT32. Files should also have the same timestamps. For most of the files this means taking care to keep the timestamps (which should be done in every package). For autoconf based packages this is in general achieved by doing something along: make install DESTDIR=$RPM_BUILD_ROOT INSTALL="%{__install} -p" For the architecture independent files generated at build time it is possible to use the timestamp of a reference file. For example: touch -r ../cernlib.in src/scripts/cernlib or touch -r NEWS $RPM_BUILD_ROOT%{_includedir}/Xbae/patchlevel.h == Multiarch, binaries and compilation scripts == In multilib environments there is a preferred architecture, 64 bit over 32 bit in x86_64, 32 bit over 64 bit in ppc64. When a conflict is found between two packages corresponding with different arches, the installed file is the one from the preferred arch. This is very common for executables in /usr/bin, for example. If the file /usr/bin/foo is found in an x86_64 package and in an i386 package, the executable from x86_64 will be installed. These implicit conflicts are accepted in Fedora, though they are considered bad by some contributors. There may be some long-term solution for these issues, but before that there are some tricks that may allow to avoid those conflicts that are presented below. Once again they are optional. * In compilation scripts (in general named along mylib-config) it should be advisable to remove -L$libdir when $libdir is the default library directory on this platform. Indeed this is automatically added when linking with the gcc compiler (it may be needed when linking with ld, but using ld is wrong in general, so a user linking with ld should add the flag by himself). * binaries may be put outside of the packages selected to be included in multilib repositories. In general the devel subpackages and their dependencies are included in multilib repositories. A typical split of a package is: foo for the binaries foo-libs for the libraries foo-devel for the development headers, and development symlinks foo-devel and foo both requires foo-libs, and foo isn't present in multilib repository. * wrapper scripts may be used to run a binaries based on which one is present. Here is a script example (adapted from firefox) ARCH=$(uname -m) case $ARCH in x86_64 | ia64 | s390 ) LIB_DIR=/usr/lib64 SECONDARY_LIB_DIR=/usr/lib ;; * ) LIB_DIR=/usr/lib SECONDARY_LIB_DIR=/usr/lib64 ;; esac if [ ! -x $LIB_DIR/package-0.0.1/foo ]; then if [ ! -x $SECONDARY_LIB_DIR/package-0.0.1/foo ]; then echo "Error: $LIB_DIR/package-0.0.1/foo not found" if [ -d $SECONDARY_LIB_DIR ]; then echo " $SECONDARY_LIB_DIR/package-0.0.1/foo not found" fi exit 1 fi LIB_DIR=$SECONDARY_LIB_DIR fi Another way to handle those conflicts could be to have a different directory for each architecture, even for executables, enabling Fedora to be multiarch and not only multilib. -- Pat From rjones at redhat.com Sat May 26 14:16:55 2007 From: rjones at redhat.com (Richard W.M. Jones) Date: Sat, 26 May 2007 15:16:55 +0100 Subject: OCaml and static linking (was old thread: Re: [Fedora-packaging] Issues with Ocaml and Static Linking) In-Reply-To: <1179806148.5161.72.camel@localhost.localdomain> References: <464F2791.1060309@redhat.com> <1179806148.5161.72.camel@localhost.localdomain> Message-ID: <46584157.2010100@redhat.com> Toshio Kuratomi wrote: > Could you add something to > http://fedoraproject.org/wiki/PackagingDrafts/OCaml > about this? I've updated that page, and built 8 libraries in that style. 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 a.badger at gmail.com Sat May 26 16:15:44 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sat, 26 May 2007 09:15:44 -0700 Subject: OCaml and static linking (was old thread: Re: [Fedora-packaging] Issues with Ocaml and Static Linking) In-Reply-To: <46584157.2010100@redhat.com> References: <464F2791.1060309@redhat.com> <1179806148.5161.72.camel@localhost.localdomain> <46584157.2010100@redhat.com> Message-ID: <1180196144.22279.92.camel@localhost.localdomain> On Sat, 2007-05-26 at 15:16 +0100, Richard W.M. Jones wrote: > Toshio Kuratomi wrote: > > Could you add something to > > http://fedoraproject.org/wiki/PackagingDrafts/OCaml > > about this? > > I've updated that page, and built 8 libraries in that style. > Thanks! To my un-OCaml eyes, that looks pretty good. I have one question: ''' There are two scripts in the base ocaml package which automatically calculate the right Requires and Provides for a library. To use them, just add the following to the spec file: %define _use_internal_dependency_generator 0 %define __find_requires /usr/lib/rpm/ocaml-find-requires.sh %define __find_provides /usr/lib/rpm/ocaml-find-provides.sh ''' The version of ocaml-find-* scripts that were posted to the list only appeared to find ocaml requires and provides. But OCaml can link to C code as well. Do we want to turn off the internal_dependency_generator or do we want to supplement it? -Toshio -------------- 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 Sun May 27 06:33:24 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sun, 27 May 2007 08:33:24 +0200 Subject: [Fedora-packaging] paragraph on shipping static numerical libs In-Reply-To: <20070526104156.GB3105@free.fr> References: <20070526104156.GB3105@free.fr> Message-ID: <1180247606.4735.1697.camel@mccallum.corsepiu.local> On Sat, 2007-05-26 at 12:41 +0200, Patrice Dumas wrote: > Hello, > > Here is a paragraph explaining why some libs may be usefull in their > static version: > > * in the case of user compiled programs doing numerical computations or > data analysis, using static libraries may be useful. Indeed it allows > to build static executables that have more chance to be run on other > platforms than the box they were compiled in, that have different > dynamic library versions or even that don't have the library installed > at all. At the same time those applications, in general, don't need > the features brought in by shared libraries (no need for nss, no > security issue, no need for iconv...). Therefore it may be acceptable > or even desirable to ship static libraries for numerical and data > processing libraries to help users needing to link statically their > locally compiled executables. The static libraries still need to be > in separate sub-packages. This all can be summarized into: Some people try to achieve cross-distro packaging by linking their applications statically. In cases, the target distros are similar enough, there are chances this will work in trivial cases (such as some subclass of numerical applications). IMO, a) technically: * static linkage between Fedora packages are a maintenance nightmare (version tracking etc.) and a security risk to fedora. As such static linkage in Fedora shall be avoided whenever possible. * packaging static libs bloats the distro. * if distros are similar enough, similar portability between distros can be achieved by dynamical linkage. * static linkage does not achieve portability, except in very trivial cases. b) politically: * cross-distro packaging is not an objective of the Fedora project. I don't know what you try to achieve with this posting, whether this was meant to be a proposal for an addition to the FPG or if you were just agitating your position for the n-th time. Ralf From pertusus at free.fr Sun May 27 08:15:36 2007 From: pertusus at free.fr (Patrice Dumas) Date: Sun, 27 May 2007 10:15:36 +0200 Subject: [Fedora-packaging] paragraph on shipping static numerical libs In-Reply-To: <1180247606.4735.1697.camel@mccallum.corsepiu.local> References: <20070526104156.GB3105@free.fr> <1180247606.4735.1697.camel@mccallum.corsepiu.local> Message-ID: <20070527081536.GA2841@free.fr> On Sun, May 27, 2007 at 08:33:24AM +0200, Ralf Corsepius wrote: > This all can be summarized into: > > Some people try to achieve cross-distro packaging by linking their > applications statically. In cases, the target distros are similar > enough, there are chances this will work in trivial cases (such as some > subclass of numerical applications). The other point is that shared linking is not needed for those apps. > IMO, > a) technically: > * static linkage between Fedora packages are a maintenance nightmare I only advocate shipping static libraries, no statically linked packages against those libraries. These libs are for use for locally compiled programs, not for packages shipped with fedora. So no maintainance issue. > (version tracking etc.) and a security risk to fedora. As such static > linkage in Fedora shall be avoided whenever possible. Maybe I was not clear but I didn't advocated static linkage in fedora. Only shipping some static libraries. > * packaging static libs bloats the distro. Sure, but they are in separate -static subpackages, so they bloat only the mirrors and repos not users computers -- except if they want static libs. > * if distros are similar enough, similar portability between distros can > be achieved by dynamical linkage. My experience is that it is not true, even between Centos and fedora. Static linkage doesn't resolve everything since today the limit of portability is imposed by needing a 2.6.9 kernel, but it is already a big improvement. > * static linkage does not achieve portability, except in very trivial > cases. This is important in my opinion for scientists doing numerical models. This may not be a large part of the fedora userbase, but in my opinion they are users of community contributors. I won't develop extensively here, but in general scientists (contrary to sysadmins) tend to avoid participating into the free software community and complain afterward that everything they need is broken -- at least that's what my colleagues do ;-) and they are in general under-represented (and free riding). Another symptom of this issue is that they do fine codes but very bad packaging in general. > b) politically: > * cross-distro packaging is not an objective of the Fedora project. Even between different fedora versions and fedora and Centos? > I don't know what you try to achieve with this posting, whether this was > meant to be a proposal for an addition to the FPG or if you were just > agitating your position for the n-th time. Onr thing is certain, I am agitating my position once again because I promised to try to state it as clearly as possible ni a way that could be submitted for ratification in a response to Toshio. So I would like to have it somewhere, it seems to me that it would fit in http://fedoraproject.org/wiki/PackagingDrafts/StaticLibraryChanges at the end of 'Packaging Static Libraries'. -- Pat From nicolas.mailhot at laposte.net Sun May 27 09:22:21 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 27 May 2007 11:22:21 +0200 Subject: [Fedora-packaging] paragraph on shipping static numerical libs In-Reply-To: <20070527081536.GA2841@free.fr> References: <20070526104156.GB3105@free.fr> <1180247606.4735.1697.camel@mccallum.corsepiu.local> <20070527081536.GA2841@free.fr> Message-ID: <1180257741.3423.2.camel@rousalka.dyndns.org> Le dimanche 27 mai 2007 ? 10:15 +0200, Patrice Dumas a ?crit : > > b) politically: > > * cross-distro packaging is not an objective of the Fedora project. > > Even between different fedora versions and fedora and Centos? They all get their own branch in Fedora. We don't build one package to fit all releases. We don't even use one source package to fit all releases. So yes cross-distro packaging is not an objective of the Fedora project, even for distributions we support directly. -- 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 dominik at greysector.net Sun May 27 11:46:37 2007 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Sun, 27 May 2007 13:46:37 +0200 Subject: [Fedora-packaging] tricks for multilib proposal In-Reply-To: <20070526130543.GD3105@free.fr> References: <20070526130543.GD3105@free.fr> Message-ID: <20070527114637.GB3443@ryvius.pekin.waw.pl> On Saturday, 26 May 2007 at 15:05, Patrice Dumas wrote: > Hello, > > I propose the following with tricks for packaging multilibs. It tries to > be a summary of a thread about multilibs. There may be mistakes, or > statements everybody doesn't agree with, so please comment. > This is pseudo wiki and I don't know where it should be put in the > wiki. How about http://fedoraproject.org/wiki/PackagingDrafts/Multilib ? Looks good to me. Regards, R. -- Fedora Extras 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 ville.skytta at iki.fi Sun May 27 12:45:10 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Sun, 27 May 2007 15:45:10 +0300 Subject: [Fedora-packaging] Packaging guidelines for Emacsen add-on packages In-Reply-To: <645d17210705170306j3eb78fd1pd638e87513798d64@mail.gmail.com> References: <645d17210705070855j1c76a34eoc4f9f65cae2766ec@mail.gmail.com> <464BD29B.60609@redhat.com> <645d17210705170306j3eb78fd1pd638e87513798d64@mail.gmail.com> Message-ID: <200705271545.11027.ville.skytta@iki.fi> Regarding the current Emacsen add-on draft, * Added some more info about requiring a version of (X)Emacs newer than or equal to the one used to compile the *.elcs, and how to find that version out dynamically during package build. * I'd like to see something mentioned about packaging *.el snippets that aren't full blown packages of their own, see for example rpmdevtools. From jonathan.underwood at gmail.com Sun May 27 14:04:27 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Sun, 27 May 2007 15:04:27 +0100 Subject: [Fedora-packaging] Packaging guidelines for Emacsen add-on packages In-Reply-To: <200705271545.11027.ville.skytta@iki.fi> References: <645d17210705070855j1c76a34eoc4f9f65cae2766ec@mail.gmail.com> <464BD29B.60609@redhat.com> <645d17210705170306j3eb78fd1pd638e87513798d64@mail.gmail.com> <200705271545.11027.ville.skytta@iki.fi> Message-ID: <645d17210705270704n29773165hfb2e4780048f537f@mail.gmail.com> On 27/05/07, Ville Skytt? wrote: > Regarding the current Emacsen add-on draft, > > * Added some more info about requiring a version of (X)Emacs newer than or > equal to the one used to compile the *.elcs, and how to find that version out > dynamically during package build. > Thanks very much, Ville. > * I'd like to see something mentioned about packaging *.el snippets that > aren't full blown packages of their own, see for example rpmdevtools. > Yes, actually Tom Tromey had also mentioned this to me privately, and you're both right - we do need to mention this. There are actually a lot of cases where a piece of software has a mode for eg. editing input files for that software. Another example that springs to mind is gnuplot, which has a subpackage called gnuplot-emacs which installs gnuplot.el gnuplot.elc gnuplot-gui.el gnuplot-gui.elc info-look.20.2.el info-look.20.3.el for GNU Emacs in /usr/share/emacs/site-lisp. There are a couple of things with this which I suppose are inconsistent with the guidelines for full blown emacs add-on packages: 1) The source .el files aren't in a separate sub-package called gnuplot-emacs-el 2) The files aren't installed in their own sub-directory /usr/share/emacs/site-lisp/gnuplot 3) The info-look.20.[2,3].el files aren't byte compiled (there may be good reasons for this. Similarly on my system currently I see the same issues for: 1) rpmdevtools (rpm-spec-mode.el[c], 2) desktop-file-utils (desktop-entry-mode.el[c]) 3) libidn (idna.el and no idna.elc) 4) emacs-common (has extra files like php-mode.el, po-mode.el, python-mode.el, ssl.el not in emacs-common-el and also not in their own directories) I would propose guidelines such as these: 1) Packages which include add on modes for (X)Emacs should package the byte compiled lisp files for these modes in a sub-package named foo-emacs and/or foo-xemacs. 2) Packages which include add on modes for (X)Emacs should package the source elisp files in separate subpackges called foo-emacs-el and foo-xemacs-el. 3) Elisp add on subpackages should install their files in an appropriately named subdirectory of /usr/share/emacs/site-lisp and /usr/share/xemacs/site-packages/lisp. These directories should be owned by the foo-emacs and foo-xemacs packages respectively. 4) foo-emacs-el should have Requires: foo-emacs and foo-xemacs-el should have Requires: foo-xemacs. These seem logically consistent with the guidelines formain (X)Emacs add-on packages, but don't fit with current packaging of some packages. The current situation is rather inconsistent. I agree with Ville, I think it's important that the draft include something on this matter. Best wishes, Jonathan. From mclasen at redhat.com Sun May 27 15:10:22 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Sun, 27 May 2007 11:10:22 -0400 Subject: [Fedora-packaging] paragraph on shipping static numerical libs In-Reply-To: <20070527081536.GA2841@free.fr> References: <20070526104156.GB3105@free.fr> <1180247606.4735.1697.camel@mccallum.corsepiu.local> <20070527081536.GA2841@free.fr> Message-ID: <1180278622.3408.4.camel@localhost.localdomain> On Sun, 2007-05-27 at 10:15 +0200, Patrice Dumas wrote: > I only advocate shipping static libraries, no statically linked packages > against those libraries. These libs are for use for locally compiled > programs, not for packages shipped with fedora. So no maintainance > issue. > The obvious question is, if this is only for locally compiled programs, why not compile the necessary static libraries locally as well ? Why should we carry that burden ? From jonathan.underwood at gmail.com Sun May 27 15:27:02 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Sun, 27 May 2007 16:27:02 +0100 Subject: [Fedora-packaging] paragraph on shipping static numerical libs In-Reply-To: <1180278622.3408.4.camel@localhost.localdomain> References: <20070526104156.GB3105@free.fr> <1180247606.4735.1697.camel@mccallum.corsepiu.local> <20070527081536.GA2841@free.fr> <1180278622.3408.4.camel@localhost.localdomain> Message-ID: <645d17210705270827p65699c32ic9cbb8efdf81d124@mail.gmail.com> On 27/05/07, Matthias Clasen wrote: > On Sun, 2007-05-27 at 10:15 +0200, Patrice Dumas wrote: > > > I only advocate shipping static libraries, no statically linked packages > > against those libraries. These libs are for use for locally compiled > > programs, not for packages shipped with fedora. So no maintainance > > issue. > > > > The obvious question is, if this is only for locally compiled programs, > why not compile the necessary static libraries locally as well ? Why > should we carry that burden ? +10,0000. I regard myself as falling into the niche of scientic/numerical programming. However, I see no advantage to myself being able to compile staticly linked binaries in the name of portability. It doesn't really gain much, and actually I have seen doing such things give rather bizarre results. Besides which, if you were to want to statically link a binary and send it to run elsewhere, Fedora isn't the platform to be doing it on. If you're looking for that sort of portability, you should be using a consistent and reliable platform for the calculations, like RHEL. The right fix here is to educate scientific programmers as to why statically linking in libraries doesn't actually get them what they want, and that it is broken. Jonathan. From ville.skytta at iki.fi Sun May 27 16:28:15 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Sun, 27 May 2007 19:28:15 +0300 Subject: [Fedora-packaging] Packaging guidelines for Emacsen add-on packages In-Reply-To: <645d17210705270704n29773165hfb2e4780048f537f@mail.gmail.com> References: <645d17210705070855j1c76a34eoc4f9f65cae2766ec@mail.gmail.com> <200705271545.11027.ville.skytta@iki.fi> <645d17210705270704n29773165hfb2e4780048f537f@mail.gmail.com> Message-ID: <200705271928.16237.ville.skytta@iki.fi> On Sunday 27 May 2007, Jonathan Underwood wrote: > I would propose guidelines such as these: > 1) Packages which include add on modes for (X)Emacs should package the > byte compiled lisp files for these modes in a sub-package named > foo-emacs and/or foo-xemacs. I don't agree with that naming - it doesn't follow the "if it's bar for foo, call it foo-bar" naming strategy applied to just about everything else. emacs-foo and xemacs-foo would be better. Ditto emacs-foo-el, xemacs-foo-el. Otherwise, looks good to me. From jonathan.underwood at gmail.com Sun May 27 16:42:45 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Sun, 27 May 2007 17:42:45 +0100 Subject: [Fedora-packaging] Packaging guidelines for Emacsen add-on packages In-Reply-To: <200705271928.16237.ville.skytta@iki.fi> References: <645d17210705070855j1c76a34eoc4f9f65cae2766ec@mail.gmail.com> <200705271545.11027.ville.skytta@iki.fi> <645d17210705270704n29773165hfb2e4780048f537f@mail.gmail.com> <200705271928.16237.ville.skytta@iki.fi> Message-ID: <645d17210705270942g57ed6f0br1059ba36e2c80183@mail.gmail.com> On 27/05/07, Ville Skytt? wrote: > On Sunday 27 May 2007, Jonathan Underwood wrote: > > > I would propose guidelines such as these: > > 1) Packages which include add on modes for (X)Emacs should package the > > byte compiled lisp files for these modes in a sub-package named > > foo-emacs and/or foo-xemacs. > > I don't agree with that naming - it doesn't follow the "if it's bar for foo, > call it foo-bar" naming strategy applied to just about everything else. > emacs-foo and xemacs-foo would be better. Ditto emacs-foo-el, xemacs-foo-el. > > Otherwise, looks good to me. Yes - I had that thought initially too. But it becomes a question of is the mode an add on for Emacs or an add-on for gnuplot (in the example given). In the end, I couldn't decide either way. Thing is, current precedent is foo-emacs, so if we're more infavour of emacs-foo, which is much more consistent, I agree, then a fair few packages will need to be renamed. OTOH, whatever guideline we introduce here will mean some packaging work will need to be done on existing packages. So perhaps we should just get it right once and for all. I'll wait a while, and if there are no more comments I'll add these guidelines along with your namingporeference to the wiki page. J. From pertusus at free.fr Sun May 27 17:03:13 2007 From: pertusus at free.fr (Patrice Dumas) Date: Sun, 27 May 2007 19:03:13 +0200 Subject: [Fedora-packaging] paragraph on shipping static numerical libs In-Reply-To: <1180278622.3408.4.camel@localhost.localdomain> References: <20070526104156.GB3105@free.fr> <1180247606.4735.1697.camel@mccallum.corsepiu.local> <20070527081536.GA2841@free.fr> <1180278622.3408.4.camel@localhost.localdomain> Message-ID: <20070527170312.GC2841@free.fr> On Sun, May 27, 2007 at 11:10:22AM -0400, Matthias Clasen wrote: > On Sun, 2007-05-27 at 10:15 +0200, Patrice Dumas wrote: > > > I only advocate shipping static libraries, no statically linked packages > > against those libraries. These libs are for use for locally compiled > > programs, not for packages shipped with fedora. So no maintainance > > issue. > > > > The obvious question is, if this is only for locally compiled programs, > why not compile the necessary static libraries locally as well ? Why > should we carry that burden ? Because we care about users? -- Pat From pertusus at free.fr Sun May 27 17:06:38 2007 From: pertusus at free.fr (Patrice Dumas) Date: Sun, 27 May 2007 19:06:38 +0200 Subject: [Fedora-packaging] paragraph on shipping static numerical libs In-Reply-To: <1180257741.3423.2.camel@rousalka.dyndns.org> References: <20070526104156.GB3105@free.fr> <1180247606.4735.1697.camel@mccallum.corsepiu.local> <20070527081536.GA2841@free.fr> <1180257741.3423.2.camel@rousalka.dyndns.org> Message-ID: <20070527170638.GD2841@free.fr> On Sun, May 27, 2007 at 11:22:21AM +0200, Nicolas Mailhot wrote: > Le dimanche 27 mai 2007 ? 10:15 +0200, Patrice Dumas a ?crit : > > > > b) politically: > > > * cross-distro packaging is not an objective of the Fedora project. > > > > Even between different fedora versions and fedora and Centos? > > They all get their own branch in Fedora. We don't build one package to That's not for packaged softwares, but for locally compiled executables. > fit all releases. We don't even use one source package to fit all > releases. So yes cross-distro packaging is not an objective of the > Fedora project, even for distributions we support directly. It is not for fedora packages but for locally built executables. Say you build a program on a fedora distro and want to run it on a centos box. (My use case is a numerical model that use some libraries shipped in fedora, gsl, lapack or cernlib for example). -- Pat From pertusus at free.fr Sun May 27 17:14:31 2007 From: pertusus at free.fr (Patrice Dumas) Date: Sun, 27 May 2007 19:14:31 +0200 Subject: [Fedora-packaging] paragraph on shipping static numerical libs In-Reply-To: <645d17210705270827p65699c32ic9cbb8efdf81d124@mail.gmail.com> References: <20070526104156.GB3105@free.fr> <1180247606.4735.1697.camel@mccallum.corsepiu.local> <20070527081536.GA2841@free.fr> <1180278622.3408.4.camel@localhost.localdomain> <645d17210705270827p65699c32ic9cbb8efdf81d124@mail.gmail.com> Message-ID: <20070527171431.GE2841@free.fr> On Sun, May 27, 2007 at 04:27:02PM +0100, Jonathan Underwood wrote: > > I regard myself as falling into the niche of scientic/numerical > programming. However, I see no advantage to myself being able to > compile staticly linked binaries in the name of portability. It > doesn't really gain much, and actually I have seen doing such things > give rather bizarre results. I have exactly the opposite experience. I have issues with g77/gfortran incompatibilities, for example. Or missing libraries on platform I am not administrator. Or libraries with different sonames. In what case did you have bizarre results? > Besides which, if you were to want to statically link a binary and > send it to run elsewhere, Fedora isn't the platform to be doing it on. Why not? > If you're looking for that sort of portability, you should be using a > consistent and reliable platform for the calculations, like RHEL. What a bizarre suggestion. Fedora should be good for numerical models. If fedora isn't good for that RHEL wont be either. > The right fix here is to educate scientific programmers as to why > statically linking in libraries doesn't actually get them what they > want, and that it is broken. I don't want to give false ideas, in many real life cases statically linking numerical models gave a binary that gave a similar result on all the platforms. I prefer educating people that believe that static linking doesn't bring in portability. -- Pat From jonathan.underwood at gmail.com Sun May 27 18:59:44 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Sun, 27 May 2007 19:59:44 +0100 Subject: [Fedora-packaging] paragraph on shipping static numerical libs In-Reply-To: <20070527171431.GE2841@free.fr> References: <20070526104156.GB3105@free.fr> <1180247606.4735.1697.camel@mccallum.corsepiu.local> <20070527081536.GA2841@free.fr> <1180278622.3408.4.camel@localhost.localdomain> <645d17210705270827p65699c32ic9cbb8efdf81d124@mail.gmail.com> <20070527171431.GE2841@free.fr> Message-ID: <645d17210705271159k652f35f1v9a4ef31bd8d9cf5d@mail.gmail.com> On 27/05/07, Patrice Dumas wrote: > I have exactly the opposite experience. I have issues with g77/gfortran > incompatibilities, for example. Or missing libraries on platform I am > not administrator. Or libraries with different sonames. In what case did > you have bizarre results? > A program statically linked with GMP running on two different platforms giving different answers. > > Besides which, if you were to want to statically link a binary and > > send it to run elsewhere, Fedora isn't the platform to be doing it on. > > Why not? Fedora is usually based on the latest glibc. Segfaults seem to ensue when running a statically linked binary compiled on Fedora with a system with an earlier glibc. > > > If you're looking for that sort of portability, you should be using a > > consistent and reliable platform for the calculations, like RHEL. > > What a bizarre suggestion. Fedora should be good for numerical models. > If fedora isn't good for that RHEL wont be either. > Yeah, I phrased the poorly. I use Fedora daily for numerical work. What i meant was, if you're really loking for a reliable and reproducible setup for running numerical calcs based on static linking and distributing binaries, you wouldn't want to use a distro with rapid ABI turnover. > > The right fix here is to educate scientific programmers as to why > > statically linking in libraries doesn't actually get them what they > > want, and that it is broken. > > I don't want to give false ideas, in many real life cases statically > linking numerical models gave a binary that gave a similar result on all > the platforms. I prefer educating people that believe that static > linking doesn't bring in portability. Right - that's what I meant the last sentence - so why go to the bother of making statically linkable libraries available if it doesn't actually achieve the goal of producing portable binaries, but rather gives people false hope. That's what I'd call wasting people's time, or giving them a noose to hang themselves with. It seems to me that the use case doesn't justify what you're asking for though. The solution you're proposing (allowing users to link statically to system wide libraries) doesn't achieve the goal (producing "run anywhere" binaries). As Matthias pointed out, if someone is hell bent on producing statically linked binaries, then they can download the source for the libraries they need and build and link statically against them. J. From jonathan.underwood at gmail.com Sun May 27 19:06:31 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Sun, 27 May 2007 20:06:31 +0100 Subject: [Fedora-packaging] paragraph on shipping static numerical libs In-Reply-To: <645d17210705271159k652f35f1v9a4ef31bd8d9cf5d@mail.gmail.com> References: <20070526104156.GB3105@free.fr> <1180247606.4735.1697.camel@mccallum.corsepiu.local> <20070527081536.GA2841@free.fr> <1180278622.3408.4.camel@localhost.localdomain> <645d17210705270827p65699c32ic9cbb8efdf81d124@mail.gmail.com> <20070527171431.GE2841@free.fr> <645d17210705271159k652f35f1v9a4ef31bd8d9cf5d@mail.gmail.com> Message-ID: <645d17210705271206r16d4c915qe8ffcd20095f04f@mail.gmail.com> What I should add though is that, what you're proposing for statically linkable library subpackages seems entirely sensible if you leave all of the questions about the utility to end users of doing so to one side. From Axel.Thimm at ATrpms.net Sun May 27 20:01:36 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 27 May 2007 22:01:36 +0200 Subject: [Fedora-packaging] Re: paragraph on shipping static numerical libs In-Reply-To: <645d17210705270827p65699c32ic9cbb8efdf81d124@mail.gmail.com> References: <20070526104156.GB3105@free.fr> <1180247606.4735.1697.camel@mccallum.corsepiu.local> <20070527081536.GA2841@free.fr> <1180278622.3408.4.camel@localhost.localdomain> <645d17210705270827p65699c32ic9cbb8efdf81d124@mail.gmail.com> Message-ID: <20070527200136.GO11952@neu.nirvana> On Sun, May 27, 2007 at 04:27:02PM +0100, Jonathan Underwood wrote: > On 27/05/07, Matthias Clasen wrote: > >On Sun, 2007-05-27 at 10:15 +0200, Patrice Dumas wrote: > > > >> I only advocate shipping static libraries, no statically linked packages > >> against those libraries. These libs are for use for locally compiled > >> programs, not for packages shipped with fedora. So no maintainance > >> issue. > Besides which, if you were to want to statically link a binary and > send it to run elsewhere, Fedora isn't the platform to be doing it on. > If you're looking for that sort of portability, you should be using a > consistent and reliable platform for the calculations, like RHEL. Whatever policies Fedora follows here, RHEL will not be different, so if static libs don't exist on Fedora, they will unlikely do so on a RHEL release of the same timeframe. > The right fix here is to educate scientific programmers as to why > statically linking in libraries doesn't actually get them what they > want, and that it is broken. Actually the situation in scientific camps is not that easy. There are tons of situations where having a statically linked binary saves the day. You typically have a complete mix of very heterogeneous Linux distributions and releases thereof with semi-bogus libs under /usr/local as a bonus. At least that's what larger phys/chem institutions and educational facilities look like in de/uk/fr/ru. Institutions that have enough budget to hire a large IT staff look a bit different and are located in the US and Japan. :) And you also have aged distros, for example a project I was working on until lately is Fedora loyal, but is still running FC4. But I need gfortran of at least FC5 to build my code. It is also quite common for scientific networks (networks as in networked institutions, not as in byte traffic ones) to share binaries for 100% reproducablity as well. Sometimes even the slightest optimization in normal operations or slight ieee754 violations in libs will change the result in the range of 10^-16 and validation will fail. Just feed some Lanczos code with it and see *every* Fedora release giving you a different result. It's a situation where you either demand from the user to adapt to your distro or your distro adapts to the users. And believe me the users in scientific camps take the line of least resistance, if Fedora doesn't deliver they will look around what does. I've lost many former academic RHL "customers" to Gentoo and Ubuntu (not sure how they deal with static libs, though). -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From pertusus at free.fr Sun May 27 19:52:56 2007 From: pertusus at free.fr (Patrice Dumas) Date: Sun, 27 May 2007 21:52:56 +0200 Subject: [Fedora-packaging] paragraph on shipping static numerical libs In-Reply-To: <645d17210705271159k652f35f1v9a4ef31bd8d9cf5d@mail.gmail.com> References: <20070526104156.GB3105@free.fr> <1180247606.4735.1697.camel@mccallum.corsepiu.local> <20070527081536.GA2841@free.fr> <1180278622.3408.4.camel@localhost.localdomain> <645d17210705270827p65699c32ic9cbb8efdf81d124@mail.gmail.com> <20070527171431.GE2841@free.fr> <645d17210705271159k652f35f1v9a4ef31bd8d9cf5d@mail.gmail.com> Message-ID: <20070527195255.GF2841@free.fr> On Sun, May 27, 2007 at 07:59:44PM +0100, Jonathan Underwood wrote: > > A program statically linked with GMP running on two different > platforms giving different answers. That's not surprising. I never made the assumption that the results of the binaries would be exactly the same. > Fedora is usually based on the latest glibc. Segfaults seem to ensue > when running a statically linked binary compiled on Fedora with a > system with an earlier glibc. I never experienced that. > Yeah, I phrased the poorly. I use Fedora daily for numerical work. > What i meant was, if you're really loking for a reliable and > reproducible setup for running numerical calcs based on static linking I am not wanting that, not at all. I just want to be able to run the numerical model on the other platform, not to have the same results. For some models I also expect the results to be the same, but not in all cases. > and distributing binaries, you wouldn't want to use a distro with > rapid ABI turnover. Certainly more important is the hardware. > Right - that's what I meant the last sentence - so why go to the > bother of making statically linkable libraries available if it doesn't > actually achieve the goal of producing portable binaries, but rather > gives people false hope. That's what I'd call wasting people's time, > or giving them a noose to hang themselves with. I am not saying that the results will be the same. I don't want to achieve reproducability, I just want a binary that runs on that platform. I don't expect a chaotic model to give the same results, for example. > It seems to me that the use case doesn't justify what you're asking > for though. The solution you're proposing (allowing users to link > statically to system wide libraries) doesn't achieve the goal > (producing "run anywhere" binaries). As Matthias pointed out, if It does so. At least for me binaries linked on fedora may be run on centos4 with a different set of libraries/compilers. > someone is hell bent on producing statically linked binaries, then > they can download the source for the libraries they need and build and > link statically against them. Of course, but it would be way better for them if we could help them. -- Pat From jonathan.underwood at gmail.com Sun May 27 20:55:18 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Sun, 27 May 2007 21:55:18 +0100 Subject: [Fedora-packaging] paragraph on shipping static numerical libs In-Reply-To: <20070527195255.GF2841@free.fr> References: <20070526104156.GB3105@free.fr> <1180247606.4735.1697.camel@mccallum.corsepiu.local> <20070527081536.GA2841@free.fr> <1180278622.3408.4.camel@localhost.localdomain> <645d17210705270827p65699c32ic9cbb8efdf81d124@mail.gmail.com> <20070527171431.GE2841@free.fr> <645d17210705271159k652f35f1v9a4ef31bd8d9cf5d@mail.gmail.com> <20070527195255.GF2841@free.fr> Message-ID: <645d17210705271355m75573c7ek516cb9b1c26774d4@mail.gmail.com> On 27/05/07, Patrice Dumas wrote: > > someone is hell bent on producing statically linked binaries, then > > they can download the source for the libraries they need and build and > > link statically against them. > > Of course, but it would be way better for them if we could help them. Actually, having read through your and Axel's emails I can see why you're so keen to see static library packages available. Actually, another use case is when you have a cluster of Fedora machines set up with a front end node where users do their work, and a load of back end compute nodes with a heavily stripped down installation, you may want statically linked binaries for executing under MPI on those nodes - this is a situation I have come across and used, and has nothing to do with the portability to different platforms thing. So, yeah, I can see why you might want static libs packages, even though more often than not, they're abused by users. J. From jkeating at redhat.com Sun May 27 23:56:50 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 27 May 2007 19:56:50 -0400 Subject: [Fedora-packaging] Re: paragraph on shipping static numerical libs In-Reply-To: <20070527200136.GO11952@neu.nirvana> References: <20070526104156.GB3105@free.fr> <645d17210705270827p65699c32ic9cbb8efdf81d124@mail.gmail.com> <20070527200136.GO11952@neu.nirvana> Message-ID: <200705271956.53739.jkeating@redhat.com> On Sunday 27 May 2007 16:01:36 Axel Thimm wrote: > Whatever policies Fedora follows here, RHEL will not be different, so > if static libs don't exist on Fedora, they will unlikely do so on a > RHEL release of the same timeframe. Or more to the point, RHEL may not build the static libs at all as RHEL may not want to support having static libs on the system. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From notting at redhat.com Mon May 28 04:41:04 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 28 May 2007 00:41:04 -0400 Subject: [Fedora-packaging] Re: paragraph on shipping static numerical libs In-Reply-To: <20070527200136.GO11952@neu.nirvana> References: <20070526104156.GB3105@free.fr> <1180247606.4735.1697.camel@mccallum.corsepiu.local> <20070527081536.GA2841@free.fr> <1180278622.3408.4.camel@localhost.localdomain> <645d17210705270827p65699c32ic9cbb8efdf81d124@mail.gmail.com> <20070527200136.GO11952@neu.nirvana> Message-ID: <20070528044104.GB8995@nostromo.devel.redhat.com> Axel Thimm (Axel.Thimm at ATrpms.net) said: > > The right fix here is to educate scientific programmers as to why > > statically linking in libraries doesn't actually get them what they > > want, and that it is broken. > > Actually the situation in scientific camps is not that easy. There are > tons of situations where having a statically linked binary saves the > day. You typically have a complete mix of very heterogeneous Linux > distributions and releases thereof with semi-bogus libs under > /usr/local as a bonus. At least that's what larger phys/chem > institutions and educational facilities look like in > de/uk/fr/ru. So, my reading of this is 'larger phys/chem institutions are crazy and don't understand sane systems management'. Am I reading this wrong? If you want consistent results, run a consistent platform. Bill From jamatos at fc.up.pt Mon May 28 07:15:20 2007 From: jamatos at fc.up.pt (=?iso-8859-1?q?Jos=E9_Matos?=) Date: Mon, 28 May 2007 08:15:20 +0100 Subject: [Fedora-packaging] Re: paragraph on shipping static numerical libs In-Reply-To: <20070528044104.GB8995@nostromo.devel.redhat.com> References: <20070526104156.GB3105@free.fr> <20070527200136.GO11952@neu.nirvana> <20070528044104.GB8995@nostromo.devel.redhat.com> Message-ID: <200705280815.20534.jamatos@fc.up.pt> On Monday 28 May 2007 05:41:04 Bill Nottingham wrote: > So, my reading of this is 'larger phys/chem institutions are > crazy and don't understand sane systems management'. Am I reading > this wrong? Don't downplay their efforts, most of their problems run for months and they are very carefull about the results, after all is their reputation that is at stake. :-) Since the computational environment can so heterogeneous people follows the path of least resistance and use tricks/techniques like this. > If you want consistent results, run a consistent platform. Come on, that is not always practical or even possible. It really helps that we have linux now, because the different proprietary unices before made this even worse and a nightmare. :-) > Bill -- Jos? Ab?lio From pertusus at free.fr Mon May 28 07:21:21 2007 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 28 May 2007 09:21:21 +0200 Subject: [Fedora-packaging] Re: paragraph on shipping static numerical libs In-Reply-To: <20070528044104.GB8995@nostromo.devel.redhat.com> References: <20070526104156.GB3105@free.fr> <1180247606.4735.1697.camel@mccallum.corsepiu.local> <20070527081536.GA2841@free.fr> <1180278622.3408.4.camel@localhost.localdomain> <645d17210705270827p65699c32ic9cbb8efdf81d124@mail.gmail.com> <20070527200136.GO11952@neu.nirvana> <20070528044104.GB8995@nostromo.devel.redhat.com> Message-ID: <20070528072121.GB2854@free.fr> On Mon, May 28, 2007 at 12:41:04AM -0400, Bill Nottingham wrote: > > So, my reading of this is 'larger phys/chem institutions are > crazy and don't understand sane systems management'. Am I reading > this wrong? different levels of funding leads to different management strategies. Besides, why don't use this kind of solutions when they work fine? > If you want consistent results, run a consistent platform. Right, results may not be 100% consistent on different platforms even with statically linked executables, but, given that there are different platforms it helps a lot and even though results are not exactly the same they may be close enough -- just like if the same program was run on 2 different computers. -- Pat From pertusus at free.fr Mon May 28 07:26:39 2007 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 28 May 2007 09:26:39 +0200 Subject: [Fedora-packaging] Re: paragraph on shipping static numerical libs In-Reply-To: <200705271956.53739.jkeating@redhat.com> References: <20070526104156.GB3105@free.fr> <645d17210705270827p65699c32ic9cbb8efdf81d124@mail.gmail.com> <20070527200136.GO11952@neu.nirvana> <200705271956.53739.jkeating@redhat.com> Message-ID: <20070528072639.GC2854@free.fr> On Sun, May 27, 2007 at 07:56:50PM -0400, Jesse Keating wrote: > On Sunday 27 May 2007 16:01:36 Axel Thimm wrote: > > Whatever policies Fedora follows here, RHEL will not be different, so > > if static libs don't exist on Fedora, they will unlikely do so on a > > RHEL release of the same timeframe. > > Or more to the point, RHEL may not build the static libs at all as RHEL may > not want to support having static libs on the system. You'd want to do that even if they are useful for some users? In any case the point wasn't about choices you may make in RHEL, but that one cannot say something don't work on Fedora and will on RHEL. Of course you may chose the reverse (that is something that works on fedora doesn't work on RHEL) -- even for good reasons (I don't think removing static libs that are in Fedora is a good thing given that they should be carefully chosen such as to be only the static libs that may have a use). -- Pat From rc040203 at freenet.de Mon May 28 07:34:20 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 28 May 2007 09:34:20 +0200 Subject: [Fedora-packaging] Re: paragraph on shipping static numerical libs In-Reply-To: <20070528044104.GB8995@nostromo.devel.redhat.com> References: <20070526104156.GB3105@free.fr> <1180247606.4735.1697.camel@mccallum.corsepiu.local> <20070527081536.GA2841@free.fr> <1180278622.3408.4.camel@localhost.localdomain> <645d17210705270827p65699c32ic9cbb8efdf81d124@mail.gmail.com> <20070527200136.GO11952@neu.nirvana> <20070528044104.GB8995@nostromo.devel.redhat.com> Message-ID: <1180337660.4735.1723.camel@mccallum.corsepiu.local> On Mon, 2007-05-28 at 00:41 -0400, Bill Nottingham wrote: > Axel Thimm (Axel.Thimm at ATrpms.net) said: > > > The right fix here is to educate scientific programmers as to why > > > statically linking in libraries doesn't actually get them what they > > > want, and that it is broken. > > > > Actually the situation in scientific camps is not that easy. There are > > tons of situations where having a statically linked binary saves the > > day. You typically have a complete mix of very heterogeneous Linux > > distributions and releases thereof with semi-bogus libs under > > /usr/local as a bonus. At least that's what larger phys/chem > > institutions and educational facilities look like in > > de/uk/fr/ru. > > So, my reading of this is 'larger phys/chem institutions are > crazy and don't understand sane systems management'. Am I reading > this wrong? Yes. In most cases, these people are non-IT people with little to no skills in program development nor interest in program development. To them, programming (and IT in general) is an unloved, unavoidable duty, they actually are not interested in nor are they interested in getting deeper into it. They use Linux/Unix because "somebody told them so", they program in Fortran, Cobol, Algol or Modula, because "somebody told them so", they do something "this way" because they don't know better and don't "want to know better". Ralf From notting at redhat.com Mon May 28 07:34:22 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 28 May 2007 03:34:22 -0400 Subject: [Fedora-packaging] Re: paragraph on shipping static numerical libs In-Reply-To: <200705280815.20534.jamatos@fc.up.pt> References: <20070526104156.GB3105@free.fr> <20070527200136.GO11952@neu.nirvana> <20070528044104.GB8995@nostromo.devel.redhat.com> <200705280815.20534.jamatos@fc.up.pt> Message-ID: <20070528073422.GA11158@nostromo.devel.redhat.com> Jos? Matos (jamatos at fc.up.pt) said: > On Monday 28 May 2007 05:41:04 Bill Nottingham wrote: > > So, my reading of this is 'larger phys/chem institutions are > > crazy and don't understand sane systems management'. Am I reading > > this wrong? > > Don't downplay their efforts, most of their problems run for months and they > are very carefull about the results, after all is their reputation that is at > stake. :-) Yes, but... describing a situation where results are run on whatever machine of whatever OS, with whatever random libs happen to be in /usr/local? Doesnt sound like an environment that intends to be replicable, or easily managed. What happens when a disk goes out? Or someone replaces one of those libraries? Bill From pertusus at free.fr Mon May 28 07:44:34 2007 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 28 May 2007 09:44:34 +0200 Subject: [Fedora-packaging] Re: paragraph on shipping static numerical libs In-Reply-To: <1180337660.4735.1723.camel@mccallum.corsepiu.local> References: <20070526104156.GB3105@free.fr> <1180247606.4735.1697.camel@mccallum.corsepiu.local> <20070527081536.GA2841@free.fr> <1180278622.3408.4.camel@localhost.localdomain> <645d17210705270827p65699c32ic9cbb8efdf81d124@mail.gmail.com> <20070527200136.GO11952@neu.nirvana> <20070528044104.GB8995@nostromo.devel.redhat.com> <1180337660.4735.1723.camel@mccallum.corsepiu.local> Message-ID: <20070528074434.GD2854@free.fr> On Mon, May 28, 2007 at 09:34:20AM +0200, Ralf Corsepius wrote: > > They use Linux/Unix because "somebody told them so", they program in > Fortran, Cobol, Algol or Modula, because "somebody told them so", they > do something "this way" because they don't know better and don't "want > to know better". That's a bit of oversimplification. In general scientists do coding just fine but don't want to do more nor even think about it (no packaging, no thoughts on system administration...). However there are IT people working together with scientists who do system administration well. Still the needs are specific and very different from other environments. -- Pat From rc040203 at freenet.de Mon May 28 08:15:01 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 28 May 2007 10:15:01 +0200 Subject: [Fedora-packaging] Re: paragraph on shipping static numerical libs In-Reply-To: <20070528074434.GD2854@free.fr> References: <20070526104156.GB3105@free.fr> <1180247606.4735.1697.camel@mccallum.corsepiu.local> <20070527081536.GA2841@free.fr> <1180278622.3408.4.camel@localhost.localdomain> <645d17210705270827p65699c32ic9cbb8efdf81d124@mail.gmail.com> <20070527200136.GO11952@neu.nirvana> <20070528044104.GB8995@nostromo.devel.redhat.com> <1180337660.4735.1723.camel@mccallum.corsepiu.local> <20070528074434.GD2854@free.fr> Message-ID: <1180340102.4735.1750.camel@mccallum.corsepiu.local> On Mon, 2007-05-28 at 09:44 +0200, Patrice Dumas wrote: > On Mon, May 28, 2007 at 09:34:20AM +0200, Ralf Corsepius wrote: > > > > They use Linux/Unix because "somebody told them so", they program in > > Fortran, Cobol, Algol or Modula, because "somebody told them so", they > > do something "this way" because they don't know better and don't "want > > to know better". > > That's a bit of oversimplification. I've worked in such an environment for many years, I know what I am talking about. An anecdote: I once met an EE-professor, who, when being asked why they were using Fortran answered: "Because our simulations are based on the Fortran punch cards I wrote during my PhD thesis 25 years ago". Consequently, his students and employees were programming Fortran. > In general scientists do coding > just fine but don't want to do more nor even think about it (no > packaging, no thoughts on system administration...). Well, in 90% of all such cases, "their coding" goes into implementing complex algorithms, while their programs complexity is not much different from "hello world". > However there > are IT people working together with scientists who do system > administration well. > Still the needs are specific and very different from other environments. I can not disagree more. These guys relation to programming / sys-administration is not much different from that of a 14-year old kid, whose IT skills are "browsing the web, running games, playing mp3s and using word processors", when it had a course in "programming in C" at school, and then starts to discover the subtleties of programming afterwards. Ralf From Axel.Thimm at ATrpms.net Mon May 28 09:34:38 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 28 May 2007 11:34:38 +0200 Subject: [Fedora-packaging] Re: paragraph on shipping static numerical libs In-Reply-To: <20070528044104.GB8995@nostromo.devel.redhat.com> References: <20070526104156.GB3105@free.fr> <1180247606.4735.1697.camel@mccallum.corsepiu.local> <20070527081536.GA2841@free.fr> <1180278622.3408.4.camel@localhost.localdomain> <645d17210705270827p65699c32ic9cbb8efdf81d124@mail.gmail.com> <20070527200136.GO11952@neu.nirvana> <20070528044104.GB8995@nostromo.devel.redhat.com> Message-ID: <20070528093438.GA19989@neu.nirvana> On Mon, May 28, 2007 at 12:41:04AM -0400, Bill Nottingham wrote: > Axel Thimm (Axel.Thimm at ATrpms.net) said: > > > The right fix here is to educate scientific programmers as to why > > > statically linking in libraries doesn't actually get them what they > > > want, and that it is broken. > > > > Actually the situation in scientific camps is not that easy. There are > > tons of situations where having a statically linked binary saves the > > day. You typically have a complete mix of very heterogeneous Linux > > distributions and releases thereof with semi-bogus libs under > > /usr/local as a bonus. At least that's what larger phys/chem > > institutions and educational facilities look like in > > de/uk/fr/ru. > > So, my reading of this is 'larger phys/chem institutions are > crazy and don't understand sane systems management'. Am I reading > this wrong? Yes, it's very wrong. Read it as "Real life". If you got enough cash to pay a large IT staff to do your system deployment *and* evaluation of system requirements of the given numerical problem to solve, then you can talk about "system's management". Even the very big players like Fermi or DESY that do have large IT staffs to deploy many-year scenarios can only go as far as providing a RHEL clone with some additional IT infrastructural elements like openafs, but not really providing all necessary numerical and scientific libraries (a lot of them are non open source). And I only mentioned that the Linux part is homogeneous. Ever wondered why the majority of Unix admins that have skills in managing heterogeneous Unix system have a physicist's background? It is far more important to have a good mips/$ and some scientists on salary, than to spend all budget for the IT staff's system management. > If you want consistent results, run a consistent platform. So you outrule Fedora? Because consistent means even more than a stable API/ABI, RHEL comes close to that, but switching to RHEL because a distro does not want to offer static libs is not reason enough, especially in light of development of key components like gfortran that is reflected in RHEL only a couple years after it makes it into the non-enterprise platforms. Loss of static libs and similar issues moves this share of users to Ubuntu/Gentoo these days. It's not speculation, it's what I see. -- 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 May 28 09:45:24 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 28 May 2007 11:45:24 +0200 Subject: [Fedora-packaging] Re: paragraph on shipping static numerical libs In-Reply-To: <1180337660.4735.1723.camel@mccallum.corsepiu.local> References: <20070526104156.GB3105@free.fr> <1180247606.4735.1697.camel@mccallum.corsepiu.local> <20070527081536.GA2841@free.fr> <1180278622.3408.4.camel@localhost.localdomain> <645d17210705270827p65699c32ic9cbb8efdf81d124@mail.gmail.com> <20070527200136.GO11952@neu.nirvana> <20070528044104.GB8995@nostromo.devel.redhat.com> <1180337660.4735.1723.camel@mccallum.corsepiu.local> Message-ID: <20070528094524.GB19989@neu.nirvana> On Mon, May 28, 2007 at 09:34:20AM +0200, Ralf Corsepius wrote: > On Mon, 2007-05-28 at 00:41 -0400, Bill Nottingham wrote: > > Axel Thimm (Axel.Thimm at ATrpms.net) said: > > > > The right fix here is to educate scientific programmers as to why > > > > statically linking in libraries doesn't actually get them what they > > > > want, and that it is broken. > > > > > > Actually the situation in scientific camps is not that easy. There are > > > tons of situations where having a statically linked binary saves the > > > day. You typically have a complete mix of very heterogeneous Linux > > > distributions and releases thereof with semi-bogus libs under > > > /usr/local as a bonus. At least that's what larger phys/chem > > > institutions and educational facilities look like in > > > de/uk/fr/ru. > > > > So, my reading of this is 'larger phys/chem institutions are > > crazy and don't understand sane systems management'. Am I reading > > this wrong? > Yes. > > In most cases, these people are non-IT people with little to no skills > in program development nor interest in program development. Well, they are not really idiots. Some of them produce great code. But they don't care to autoconf it, or to spend more time on polishing it. If it runs with good performance (which is the key element in numerical code) and they can easily deploy it on the available hardware, then they can turn to solving actual problems from their field with this tool. > To them, programming (and IT in general) is an unloved, unavoidable > duty, they actually are not interested in nor are they interested in > getting deeper into it. IT yes, programming I disagree. > They use Linux/Unix because "somebody told them so", they program in > Fortran, Cobol, Algol or Modula, because "somebody told them so", they > do something "this way" because they don't know better and don't "want > to know better". Nah, that's not the case, and you will not really find phys/chem doing Cobol, Algol or Modula, that's reserved for cs/eco - Phys/chem does 90% Fortran, 10% C/C++ (with emphasis on C). The reason is not "somebody told them so", but that Fortran has a very simple language interface which still offered language elements like complex numbers ages before C/C++ did, as well as advanced libraries to do the number crunching. Furthermore there is vast knowledge of Fortran in these camps, if a rookie starts doing his work in C++ he's rather isolated and needs to work through it by himself. Yes, I did C++. Anyway, we're getting off-topic, the facts are that there are camps that rightfully use static libs a lot. Either Fedora cares about these camps, or they are considered a minority to not really cater for their needs. -- 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 May 28 09:47:39 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 28 May 2007 11:47:39 +0200 Subject: [Fedora-packaging] Re: paragraph on shipping static numerical libs In-Reply-To: <1180340102.4735.1750.camel@mccallum.corsepiu.local> References: <20070526104156.GB3105@free.fr> <1180247606.4735.1697.camel@mccallum.corsepiu.local> <20070527081536.GA2841@free.fr> <1180278622.3408.4.camel@localhost.localdomain> <645d17210705270827p65699c32ic9cbb8efdf81d124@mail.gmail.com> <20070527200136.GO11952@neu.nirvana> <20070528044104.GB8995@nostromo.devel.redhat.com> <1180337660.4735.1723.camel@mccallum.corsepiu.local> <20070528074434.GD2854@free.fr> <1180340102.4735.1750.camel@mccallum.corsepiu.local> Message-ID: <20070528094739.GC19989@neu.nirvana> On Mon, May 28, 2007 at 10:15:01AM +0200, Ralf Corsepius wrote: > On Mon, 2007-05-28 at 09:44 +0200, Patrice Dumas wrote: > > On Mon, May 28, 2007 at 09:34:20AM +0200, Ralf Corsepius wrote: > > > > > > They use Linux/Unix because "somebody told them so", they program in > > > Fortran, Cobol, Algol or Modula, because "somebody told them so", they > > > do something "this way" because they don't know better and don't "want > > > to know better". > > > > That's a bit of oversimplification. > I've worked in such an environment for many years, I know what I am > talking about. > > An anecdote: I once met an EE-professor, who, when being asked why they > were using Fortran answered: "Because our simulations are based on the > Fortran punch cards I wrote during my PhD thesis 25 years ago". > Consequently, his students and employees were programming Fortran. > > > In general scientists do coding > > just fine but don't want to do more nor even think about it (no > > packaging, no thoughts on system administration...). > Well, in 90% of all such cases, "their coding" goes into implementing > complex algorithms, while their programs complexity is not much > different from "hello world". This sounds quite arrogant. > > However there > > are IT people working together with scientists who do system > > administration well. > > > Still the needs are specific and very different from other environments. > I can not disagree more. > > These guys relation to programming / sys-administration is not much > different from that of a 14-year old kid, whose IT skills are "browsing > the web, running games, playing mp3s and using word processors", when it > had a course in "programming in C" at school, and then starts to > discover the subtleties of programming afterwards. And in their spare time they invented the web including the first implementation of web servers and clients. -- 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 May 28 09:59:47 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 28 May 2007 11:59:47 +0200 Subject: [Fedora-packaging] Re: paragraph on shipping static numerical libs In-Reply-To: <20070528073422.GA11158@nostromo.devel.redhat.com> References: <20070526104156.GB3105@free.fr> <20070527200136.GO11952@neu.nirvana> <20070528044104.GB8995@nostromo.devel.redhat.com> <200705280815.20534.jamatos@fc.up.pt> <20070528073422.GA11158@nostromo.devel.redhat.com> Message-ID: <20070528095947.GD19989@neu.nirvana> On Mon, May 28, 2007 at 03:34:22AM -0400, Bill Nottingham wrote: > Jos? Matos (jamatos at fc.up.pt) said: > > On Monday 28 May 2007 05:41:04 Bill Nottingham wrote: > > > So, my reading of this is 'larger phys/chem institutions are > > > crazy and don't understand sane systems management'. Am I reading > > > this wrong? > > > > Don't downplay their efforts, most of their problems run for months and they > > are very carefull about the results, after all is their reputation that is at > > stake. :-) > > Yes, but... describing a situation where results are run on whatever > machine of whatever OS, with whatever random libs happen to be in > /usr/local? Doesnt sound like an environment that intends to be replicable, > or easily managed. What happens when a disk goes out? Or someone replaces > one of those libraries? Nothing, because the code was statically linked. That's where you get deterministic, non-environment dependent results from, no matter what the environment looks like (in sensible limits, of course): Either a too old distro (running FC6 builds on FC5), a cross-distro build (running FC6 builds on SLES clusters), or in general missing libs, old libs, old compilers, broken parts under /usr/local and so on. With a static build, you don't care and have the same results as in your local tests. To be completely fair, the real number crunchers like clustered systems or mpp systems do have more careful setups with no self-built debris lying in /usr/local (but old or missing libs nonetheless). But the users developing the code do need to build/install bits under their /usr/local. Therefore submitting a job sometimes means you have to statically link your code, do a final test on your system, upload it and queue it into whatever queueing system is supported. Or you apply for a sysadmin to build the required libs for you, so you don't have to statically link and you find out that your contract expires before all parts are in place. Not to speak about asking the admin a year later to upgrade the libs. -- 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 Mon May 28 10:00:42 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 28 May 2007 12:00:42 +0200 Subject: [Fedora-packaging] Re: paragraph on shipping static numerical libs In-Reply-To: <20070528094524.GB19989@neu.nirvana> References: <20070526104156.GB3105@free.fr> <1180247606.4735.1697.camel@mccallum.corsepiu.local> <20070527081536.GA2841@free.fr> <1180278622.3408.4.camel@localhost.localdomain> <645d17210705270827p65699c32ic9cbb8efdf81d124@mail.gmail.com> <20070527200136.GO11952@neu.nirvana> <20070528044104.GB8995@nostromo.devel.redhat.com> <1180337660.4735.1723.camel@mccallum.corsepiu.local> <20070528094524.GB19989@neu.nirvana> Message-ID: <1180346442.7810.4.camel@rousalka.dyndns.org> Le lundi 28 mai 2007 ? 11:45 +0200, Axel Thimm a ?crit : > Well, they are not really idiots. Some of them produce great code. But > they don't care to autoconf it, or to spend more time on polishing > it. If it runs with good performance (which is the key element in > numerical code) and they can easily deploy it on the available > hardware, then they can turn to solving actual problems from their > field with this tool. Which sort-of hints shipping static libs is a short-term workaround and energy would be better spend making tools like eclipse integrate our best-of-breed infrastructure (autoconf, rpm, yum, mock whatever) transparently so these people don't have to spend time on plumbing to produce modern sofwtare. That would help adoption with the huge Visual Basic & Java crowd too BTW. -- 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 pertusus at free.fr Mon May 28 11:16:16 2007 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 28 May 2007 13:16:16 +0200 Subject: [Fedora-packaging] Re: paragraph on shipping static numerical libs In-Reply-To: <1180346442.7810.4.camel@rousalka.dyndns.org> References: <20070526104156.GB3105@free.fr> <1180247606.4735.1697.camel@mccallum.corsepiu.local> <20070527081536.GA2841@free.fr> <1180278622.3408.4.camel@localhost.localdomain> <645d17210705270827p65699c32ic9cbb8efdf81d124@mail.gmail.com> <20070527200136.GO11952@neu.nirvana> <20070528044104.GB8995@nostromo.devel.redhat.com> <1180337660.4735.1723.camel@mccallum.corsepiu.local> <20070528094524.GB19989@neu.nirvana> <1180346442.7810.4.camel@rousalka.dyndns.org> Message-ID: <20070528111616.GF2854@free.fr> On Mon, May 28, 2007 at 12:00:42PM +0200, Nicolas Mailhot wrote: > > Which sort-of hints shipping static libs is a short-term workaround and > energy would be better spend making tools like eclipse integrate our > best-of-breed infrastructure (autoconf, rpm, yum, mock whatever) > transparently so these people don't have to spend time on plumbing to > produce modern sofwtare. I can't see the connection between eclipse and the issues at stake here... Shipping static libs is not necessarily a short term workaround, dynamic libs keep changing ABI and one cannot necesarily install everytime the libs on all the computers he may want to run a program. How is it related with eclipse??? -- Pat From rjones at redhat.com Mon May 28 11:27:57 2007 From: rjones at redhat.com (Richard W.M. Jones) Date: Mon, 28 May 2007 12:27:57 +0100 Subject: OCaml and static linking (was old thread: Re: [Fedora-packaging] Issues with Ocaml and Static Linking) In-Reply-To: <1180196144.22279.92.camel@localhost.localdomain> References: <464F2791.1060309@redhat.com> <1179806148.5161.72.camel@localhost.localdomain> <46584157.2010100@redhat.com> <1180196144.22279.92.camel@localhost.localdomain> Message-ID: <465ABCBD.3060701@redhat.com> Toshio Kuratomi wrote: > On Sat, 2007-05-26 at 15:16 +0100, Richard W.M. Jones wrote: >> Toshio Kuratomi wrote: >>> Could you add something to >>> http://fedoraproject.org/wiki/PackagingDrafts/OCaml >>> about this? >> I've updated that page, and built 8 libraries in that style. >> > > Thanks! To my un-OCaml eyes, that looks pretty good. I have one > question: > ''' > There are two scripts in the base ocaml package which automatically > calculate the right Requires and Provides for a library. To use them, > just add the following to the spec file: > > %define _use_internal_dependency_generator 0 > %define __find_requires /usr/lib/rpm/ocaml-find-requires.sh > %define __find_provides /usr/lib/rpm/ocaml-find-provides.sh > ''' > > The version of ocaml-find-* scripts that were posted to the list only > appeared to find ocaml requires and provides. But OCaml can link to C > code as well. Do we want to turn off the internal_dependency_generator > or do we want to supplement it? I've attached the latest versions to this bug: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=239004 These versions call the ordinary find-requires and find-provides first, before going on to look at OCaml-specific files. And they appear to find C dependencies (.so files and the like). For example, here is my ocaml-pcre package[1], which is a library which links to the C PCRE lib: $ rpm -q --requires ocaml-pcre rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(CompressedFileNames) <= 3.0.4-1 libc.so.6()(64bit) libc.so.6(GLIBC_2.2.5)(64bit) libc.so.6(GLIBC_2.3)(64bit) libpcre.so.0()(64bit) ocaml-Array-a904b798dd9665c2d3635636d293403c ocaml-Callback-0ee2712bb82e3d81660a3132766fcb9b ocaml-Char-0d0f20d5854680b694159a2fb0ca4e61 ocaml-List-5a0e3217fc356bd18f60bff31861dfd3 ocaml-Pervasives-71f888453b0f26895819460a72f07493 ocaml-String-fec8292bb1a02d2c7b8b4ba7b83a7d8b ocaml-Sys-8cce770a42b7d0e4d85569c15d7841d6 ocaml = 3.09.3-2.fc6 $ rpm -q --provides ocaml-pcre dllpcre_stubs.so()(64bit) ocaml-Pcre-0ad0922a407866904c71fd615f05b414 ocaml-pcre = 5.11.4-3 So that's correct, I think? Rich. [1] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=240652 -- 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 rjones at redhat.com Mon May 28 11:31:43 2007 From: rjones at redhat.com (Richard W.M. Jones) Date: Mon, 28 May 2007 12:31:43 +0100 Subject: OCaml and static linking (was old thread: Re: [Fedora-packaging] Issues with Ocaml and Static Linking) In-Reply-To: <465ABCBD.3060701@redhat.com> References: <464F2791.1060309@redhat.com> <1179806148.5161.72.camel@localhost.localdomain> <46584157.2010100@redhat.com> <1180196144.22279.92.camel@localhost.localdomain> <465ABCBD.3060701@redhat.com> Message-ID: <465ABD9F.3080509@redhat.com> BTW, in case it wasn't clear with all this talk about static linking. OCaml links OCaml libraries statically, but C libraries dynamically. For example here is cduce, an OCaml program which uses many different libraries: $ ldd `which cduce` libexpat.so.0 => /lib64/libexpat.so.0 (0x0000003c76e00000) libcurl.so.3 => /usr/lib64/libcurl.so.3 (0x0000003fb7000000) libgssapi_krb5.so.2 => /usr/lib64/libgssapi_krb5.so.2 (0x0000003fbaa00000) libkrb5.so.3 => /usr/lib64/libkrb5.so.3 (0x0000003fbb200000) libk5crypto.so.3 => /usr/lib64/libk5crypto.so.3 (0x0000003fbae00000) libcom_err.so.2 => /lib64/libcom_err.so.2 (0x0000003c79600000) libresolv.so.2 => /lib64/libresolv.so.2 (0x0000003c78600000) libdl.so.2 => /lib64/libdl.so.2 (0x0000003c73600000) libidn.so.11 => /usr/lib64/libidn.so.11 (0x0000003297800000) libssl.so.6 => /lib64/libssl.so.6 (0x0000003fbb600000) libcrypto.so.6 => /lib64/libcrypto.so.6 (0x0000003c79200000) libz.so.1 => /usr/lib64/libz.so.1 (0x0000003c74200000) librt.so.1 => /lib64/librt.so.1 (0x00000038b2200000) libpcre.so.0 => /lib64/libpcre.so.0 (0x0000003682000000) libm.so.6 => /lib64/libm.so.6 (0x0000003c73a00000) libc.so.6 => /lib64/libc.so.6 (0x0000003c73200000) libkrb5support.so.0 => /usr/lib64/libkrb5support.so.0 (0x0000003fba600000) /lib64/ld-linux-x86-64.so.2 (0x0000003c72e00000) libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003ff2400000) $ file `which cduce` /usr/bin/cduce: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, stripped 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 rc040203 at freenet.de Mon May 28 11:46:03 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 28 May 2007 13:46:03 +0200 Subject: [Fedora-packaging] Re: paragraph on shipping static numerical libs In-Reply-To: <20070528094739.GC19989@neu.nirvana> References: <20070526104156.GB3105@free.fr> <1180247606.4735.1697.camel@mccallum.corsepiu.local> <20070527081536.GA2841@free.fr> <1180278622.3408.4.camel@localhost.localdomain> <645d17210705270827p65699c32ic9cbb8efdf81d124@mail.gmail.com> <20070527200136.GO11952@neu.nirvana> <20070528044104.GB8995@nostromo.devel.redhat.com> <1180337660.4735.1723.camel@mccallum.corsepiu.local> <20070528074434.GD2854@free.fr> <1180340102.4735.1750.camel@mccallum.corsepiu.local> <20070528094739.GC19989@neu.nirvana> Message-ID: <1180352763.4735.1756.camel@mccallum.corsepiu.local> On Mon, 2007-05-28 at 11:47 +0200, Axel Thimm wrote: > On Mon, May 28, 2007 at 10:15:01AM +0200, Ralf Corsepius wrote: > > On Mon, 2007-05-28 at 09:44 +0200, Patrice Dumas wrote: > > > On Mon, May 28, 2007 at 09:34:20AM +0200, Ralf Corsepius wrote: > > > > > > > > They use Linux/Unix because "somebody told them so", they program in > > > > Fortran, Cobol, Algol or Modula, because "somebody told them so", they > > > > do something "this way" because they don't know better and don't "want > > > > to know better". > > > > > > That's a bit of oversimplification. > > I've worked in such an environment for many years, I know what I am > > talking about. > > > > An anecdote: I once met an EE-professor, who, when being asked why they > > were using Fortran answered: "Because our simulations are based on the > > Fortran punch cards I wrote during my PhD thesis 25 years ago". > > Consequently, his students and employees were programming Fortran. > > > > > In general scientists do coding > > > just fine but don't want to do more nor even think about it (no > > > packaging, no thoughts on system administration...). > > Well, in 90% of all such cases, "their coding" goes into implementing > > complex algorithms, while their programs complexity is not much > > different from "hello world". > > This sounds quite arrogant. Feel free to think what you want - These number cruncher guys apps condense down to a READ STDIN CALL ALGORITHM PRINT STDOUT Their typical usage: ./myapp < inputdata >output ... wait ... lpr output > > > However there > > > are IT people working together with scientists who do system > > > administration well. > > > > > Still the needs are specific and very different from other environments. > > I can not disagree more. > > > > These guys relation to programming / sys-administration is not much > > different from that of a 14-year old kid, whose IT skills are "browsing > > the web, running games, playing mp3s and using word processors", when it > > had a course in "programming in C" at school, and then starts to > > discover the subtleties of programming afterwards. > > And in their spare time they invented the web including the first > implementation of web servers and clients. May-be some of them ... The others were busy keeping their machines hot. Ralf From rc040203 at freenet.de Mon May 28 11:54:33 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 28 May 2007 13:54:33 +0200 Subject: [Fedora-packaging] Re: paragraph on shipping static numerical libs In-Reply-To: <20070528094524.GB19989@neu.nirvana> References: <20070526104156.GB3105@free.fr> <1180247606.4735.1697.camel@mccallum.corsepiu.local> <20070527081536.GA2841@free.fr> <1180278622.3408.4.camel@localhost.localdomain> <645d17210705270827p65699c32ic9cbb8efdf81d124@mail.gmail.com> <20070527200136.GO11952@neu.nirvana> <20070528044104.GB8995@nostromo.devel.redhat.com> <1180337660.4735.1723.camel@mccallum.corsepiu.local> <20070528094524.GB19989@neu.nirvana> Message-ID: <1180353273.4735.1766.camel@mccallum.corsepiu.local> On Mon, 2007-05-28 at 11:45 +0200, Axel Thimm wrote: > On Mon, May 28, 2007 at 09:34:20AM +0200, Ralf Corsepius wrote: > > On Mon, 2007-05-28 at 00:41 -0400, Bill Nottingham wrote: > > > Axel Thimm (Axel.Thimm at ATrpms.net) said: > > > > > The right fix here is to educate scientific programmers as to why > > > > > statically linking in libraries doesn't actually get them what they > > > > > want, and that it is broken. > > > > > > > > Actually the situation in scientific camps is not that easy. There are > > > > tons of situations where having a statically linked binary saves the > > > > day. You typically have a complete mix of very heterogeneous Linux > > > > distributions and releases thereof with semi-bogus libs under > > > > /usr/local as a bonus. At least that's what larger phys/chem > > > > institutions and educational facilities look like in > > > > de/uk/fr/ru. > > > > > > So, my reading of this is 'larger phys/chem institutions are > > > crazy and don't understand sane systems management'. Am I reading > > > this wrong? > > Yes. > > > > In most cases, these people are non-IT people with little to no skills > > in program development nor interest in program development. > > Well, they are not really idiots. Nobody said that. Most of these guys are just beginners to everything but "algorithms", which to them means "math". They never heard nor thought about "sockets", "ipc", i18n, threading, ABIs/APIs, system-integration, ... etc. > Anyway, we're getting off-topic, the facts are that there are camps > that rightfully use static libs a lot. Either Fedora cares about these > camps, or they are considered a minority to not really cater for their > needs. IMO, this is not a matter of "minorities" nor of demands. I feel this to be a matter of "limitation of knowledge" trying to push their mistakes into the distro. Ralf From Axel.Thimm at ATrpms.net Mon May 28 12:01:10 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 28 May 2007 14:01:10 +0200 Subject: [Fedora-packaging] Re: paragraph on shipping static numerical libs In-Reply-To: <1180352763.4735.1756.camel@mccallum.corsepiu.local> References: <20070527081536.GA2841@free.fr> <1180278622.3408.4.camel@localhost.localdomain> <645d17210705270827p65699c32ic9cbb8efdf81d124@mail.gmail.com> <20070527200136.GO11952@neu.nirvana> <20070528044104.GB8995@nostromo.devel.redhat.com> <1180337660.4735.1723.camel@mccallum.corsepiu.local> <20070528074434.GD2854@free.fr> <1180340102.4735.1750.camel@mccallum.corsepiu.local> <20070528094739.GC19989@neu.nirvana> <1180352763.4735.1756.camel@mccallum.corsepiu.local> Message-ID: <20070528120110.GA24966@neu.nirvana> On Mon, May 28, 2007 at 01:46:03PM +0200, Ralf Corsepius wrote: > > > Well, in 90% of all such cases, "their coding" goes into implementing > > > complex algorithms, while their programs complexity is not much > > > different from "hello world". > > > > This sounds quite arrogant. > > Feel free to think what you want - These number cruncher guys apps > condense down to a > > READ STDIN > CALL ALGORITHM > PRINT STDOUT > > Their typical usage: > > ./myapp < inputdata >output > ... wait ... > lpr output Hm, you have never seen any mpp code. I/O is the most complex part of large scale numerics. -- 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 May 28 12:10:38 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 28 May 2007 14:10:38 +0200 Subject: [Fedora-packaging] Re: paragraph on shipping static numerical libs In-Reply-To: <1180353273.4735.1766.camel@mccallum.corsepiu.local> References: <20070526104156.GB3105@free.fr> <1180247606.4735.1697.camel@mccallum.corsepiu.local> <20070527081536.GA2841@free.fr> <1180278622.3408.4.camel@localhost.localdomain> <645d17210705270827p65699c32ic9cbb8efdf81d124@mail.gmail.com> <20070527200136.GO11952@neu.nirvana> <20070528044104.GB8995@nostromo.devel.redhat.com> <1180337660.4735.1723.camel@mccallum.corsepiu.local> <20070528094524.GB19989@neu.nirvana> <1180353273.4735.1766.camel@mccallum.corsepiu.local> Message-ID: <20070528121038.GB24966@neu.nirvana> On Mon, May 28, 2007 at 01:54:33PM +0200, Ralf Corsepius wrote: > Most of these guys are just beginners to everything but > "algorithms", which to them means "math". > > They never heard nor thought about "sockets", "ipc", i18n, threading, > ABIs/APIs, system-integration, ... etc. Ehm, I'm not sure what you are describing, ipc is a very big deal especially cross-processor-wise. Threading? mpi/openmp was developed out of these group's needs. > > Anyway, we're getting off-topic, the facts are that there are camps > > that rightfully use static libs a lot. Either Fedora cares about these > > camps, or they are considered a minority to not really cater for their > > needs. > IMO, this is not a matter of "minorities" nor of demands. I feel this to > be a matter of "limitation of knowledge" trying to push their mistakes > into the distro. I think the lack of knowledge is perhaps on the other side of the fence. -- 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 rc040203 at freenet.de Mon May 28 12:11:40 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 28 May 2007 14:11:40 +0200 Subject: [Fedora-packaging] Re: paragraph on shipping static numerical libs In-Reply-To: <20070528120110.GA24966@neu.nirvana> References: <20070527081536.GA2841@free.fr> <1180278622.3408.4.camel@localhost.localdomain> <645d17210705270827p65699c32ic9cbb8efdf81d124@mail.gmail.com> <20070527200136.GO11952@neu.nirvana> <20070528044104.GB8995@nostromo.devel.redhat.com> <1180337660.4735.1723.camel@mccallum.corsepiu.local> <20070528074434.GD2854@free.fr> <1180340102.4735.1750.camel@mccallum.corsepiu.local> <20070528094739.GC19989@neu.nirvana> <1180352763.4735.1756.camel@mccallum.corsepiu.local> <20070528120110.GA24966@neu.nirvana> Message-ID: <1180354300.4735.1770.camel@mccallum.corsepiu.local> On Mon, 2007-05-28 at 14:01 +0200, Axel Thimm wrote: > On Mon, May 28, 2007 at 01:46:03PM +0200, Ralf Corsepius wrote: > > > > Well, in 90% of all such cases, "their coding" goes into implementing > > > > complex algorithms, while their programs complexity is not much > > > > different from "hello world". > > > > > > This sounds quite arrogant. > > > > Feel free to think what you want - These number cruncher guys apps > > condense down to a > > > > READ STDIN > > CALL ALGORITHM > > PRINT STDOUT > > > > Their typical usage: > > > > ./myapp < inputdata >output > > ... wait ... > > lpr output > > Hm, you have never seen any mpp code. No I haven't, but I have seen many matlab, lapack, octave and reduce users. > I/O is the most complex part of large scale numerics. May be in your case, but not in the cases I am familiar with (Optimization theory) Ralf From rc040203 at freenet.de Mon May 28 12:12:38 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 28 May 2007 14:12:38 +0200 Subject: [Fedora-packaging] Re: paragraph on shipping static numerical libs In-Reply-To: <20070528121038.GB24966@neu.nirvana> References: <20070526104156.GB3105@free.fr> <1180247606.4735.1697.camel@mccallum.corsepiu.local> <20070527081536.GA2841@free.fr> <1180278622.3408.4.camel@localhost.localdomain> <645d17210705270827p65699c32ic9cbb8efdf81d124@mail.gmail.com> <20070527200136.GO11952@neu.nirvana> <20070528044104.GB8995@nostromo.devel.redhat.com> <1180337660.4735.1723.camel@mccallum.corsepiu.local> <20070528094524.GB19989@neu.nirvana> <1180353273.4735.1766.camel@mccallum.corsepiu.local> <20070528121038.GB24966@neu.nirvana> Message-ID: <1180354358.4735.1772.camel@mccallum.corsepiu.local> On Mon, 2007-05-28 at 14:10 +0200, Axel Thimm wrote: > On Mon, May 28, 2007 at 01:54:33PM +0200, Ralf Corsepius wrote: > > Most of these guys are just beginners to everything but > > "algorithms", which to them means "math". > > > > They never heard nor thought about "sockets", "ipc", i18n, threading, > > ABIs/APIs, system-integration, ... etc. > > Ehm, I'm not sure what you are describing, ipc is a very big deal > especially cross-processor-wise. Threading? mpi/openmp was developed > out of these group's needs. > > > > Anyway, we're getting off-topic, the facts are that there are camps > > > that rightfully use static libs a lot. Either Fedora cares about these > > > camps, or they are considered a minority to not really cater for their > > > needs. > > IMO, this is not a matter of "minorities" nor of demands. I feel this to > > be a matter of "limitation of knowledge" trying to push their mistakes > > into the distro. > > I think the lack of knowledge is perhaps on the other side of the > fence. Now that's arrogant - PLONK. Ralf From ed at eh3.com Mon May 28 13:49:34 2007 From: ed at eh3.com (Ed Hill) Date: Mon, 28 May 2007 09:49:34 -0400 Subject: [Fedora-packaging] Re: paragraph on shipping static numerical libs In-Reply-To: <1180352763.4735.1756.camel@mccallum.corsepiu.local> References: <20070526104156.GB3105@free.fr> <1180247606.4735.1697.camel@mccallum.corsepiu.local> <20070527081536.GA2841@free.fr> <1180278622.3408.4.camel@localhost.localdomain> <645d17210705270827p65699c32ic9cbb8efdf81d124@mail.gmail.com> <20070527200136.GO11952@neu.nirvana> <20070528044104.GB8995@nostromo.devel.redhat.com> <1180337660.4735.1723.camel@mccallum.corsepiu.local> <20070528074434.GD2854@free.fr> <1180340102.4735.1750.camel@mccallum.corsepiu.local> <20070528094739.GC19989@neu.nirvana> <1180352763.4735.1756.camel@mccallum.corsepiu.local> Message-ID: <20070528094934.2f32b2e5@daggett> On Mon, 28 May 2007 13:46:03 +0200 Ralf Corsepius wrote: > On Mon, 2007-05-28 at 11:47 +0200, Axel Thimm wrote: > > On Mon, May 28, 2007 at 10:15:01AM +0200, Ralf Corsepius wrote: > > > On Mon, 2007-05-28 at 09:44 +0200, Patrice Dumas wrote: > > > > On Mon, May 28, 2007 at 09:34:20AM +0200, Ralf Corsepius wrote: > > > > > > > In general scientists do coding > > > > just fine but don't want to do more nor even think about it (no > > > > packaging, no thoughts on system administration...). > > > Well, in 90% of all such cases, "their coding" goes into > > > implementing complex algorithms, while their programs complexity > > > is not much different from "hello world". > > > > This sounds quite arrogant. > > Feel free to think what you want - These number cruncher guys apps > condense down to a > > READ STDIN > CALL ALGORITHM > PRINT STDOUT > > Their typical usage: > > ./myapp < inputdata >output > ... wait ... > lpr output Oh Ralf, you're such a sweetheart! Bursting with optimism about all of human-kind! :-) Yes, some scientists/engineers are dreadful coders and should never be allowed to admin any systems, not even small one-button toaster ovens. Some are brilliant coders and/or admins who develop novel algorithms/ approaches and build/manage their own clusters. Many fall somewhere between those two extremes. Your "condense down" comments are just silly. Really... silly... 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 rc040203 at freenet.de Mon May 28 14:17:39 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 28 May 2007 16:17:39 +0200 Subject: [Fedora-packaging] Re: paragraph on shipping static numerical libs In-Reply-To: <20070528094934.2f32b2e5@daggett> References: <20070526104156.GB3105@free.fr> <1180247606.4735.1697.camel@mccallum.corsepiu.local> <20070527081536.GA2841@free.fr> <1180278622.3408.4.camel@localhost.localdomain> <645d17210705270827p65699c32ic9cbb8efdf81d124@mail.gmail.com> <20070527200136.GO11952@neu.nirvana> <20070528044104.GB8995@nostromo.devel.redhat.com> <1180337660.4735.1723.camel@mccallum.corsepiu.local> <20070528074434.GD2854@free.fr> <1180340102.4735.1750.camel@mccallum.corsepiu.local> <20070528094739.GC19989@neu.nirvana> <1180352763.4735.1756.camel@mccallum.corsepiu.local> <20070528094934.2f32b2e5@daggett> Message-ID: <1180361859.4735.1778.camel@mccallum.corsepiu.local> On Mon, 2007-05-28 at 09:49 -0400, Ed Hill wrote: > On Mon, 28 May 2007 13:46:03 +0200 Ralf Corsepius wrote: > > On Mon, 2007-05-28 at 11:47 +0200, Axel Thimm wrote: > > > On Mon, May 28, 2007 at 10:15:01AM +0200, Ralf Corsepius wrote: > > > > On Mon, 2007-05-28 at 09:44 +0200, Patrice Dumas wrote: > > > > > On Mon, May 28, 2007 at 09:34:20AM +0200, Ralf Corsepius wrote: > > > > > > > > > In general scientists do coding > > > > > just fine but don't want to do more nor even think about it (no > > > > > packaging, no thoughts on system administration...). > > > > Well, in 90% of all such cases, "their coding" goes into > > > > implementing complex algorithms, while their programs complexity > > > > is not much different from "hello world". > > > > > > This sounds quite arrogant. > > > > Feel free to think what you want - These number cruncher guys apps > > condense down to a > > > > READ STDIN > > CALL ALGORITHM > > PRINT STDOUT > > > > Their typical usage: > > > > ./myapp < inputdata >output > > ... wait ... > > lpr output > > > Oh Ralf, you're such a sweetheart! Bursting with optimism about > all of human-kind! :-) > > Yes, some scientists/engineers are dreadful coders and should never be > allowed to admin any systems, not even small one-button toaster ovens. > Some are brilliant coders and/or admins who develop novel algorithms/ > approaches and build/manage their own clusters. Many fall somewhere > between those two extremes. > > Your "condense down" comments are just silly. Really... silly... Thank you, very much - I must have been living on a different planet than you for the last 15 years. I must have been watching a different kind of scientists, blocking networks and machines with their number crunching jobs over all these years ... Ralf From Axel.Thimm at ATrpms.net Mon May 28 14:44:17 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 28 May 2007 16:44:17 +0200 Subject: [Fedora-packaging] Re: paragraph on shipping static numerical libs In-Reply-To: <1180361859.4735.1778.camel@mccallum.corsepiu.local> References: <645d17210705270827p65699c32ic9cbb8efdf81d124@mail.gmail.com> <20070527200136.GO11952@neu.nirvana> <20070528044104.GB8995@nostromo.devel.redhat.com> <1180337660.4735.1723.camel@mccallum.corsepiu.local> <20070528074434.GD2854@free.fr> <1180340102.4735.1750.camel@mccallum.corsepiu.local> <20070528094739.GC19989@neu.nirvana> <1180352763.4735.1756.camel@mccallum.corsepiu.local> <20070528094934.2f32b2e5@daggett> <1180361859.4735.1778.camel@mccallum.corsepiu.local> Message-ID: <20070528144417.GD24966@neu.nirvana> On Mon, May 28, 2007 at 04:17:39PM +0200, Ralf Corsepius wrote: > On Mon, 2007-05-28 at 09:49 -0400, Ed Hill wrote: > > On Mon, 28 May 2007 13:46:03 +0200 Ralf Corsepius wrote: > > > On Mon, 2007-05-28 at 11:47 +0200, Axel Thimm wrote: > > > > On Mon, May 28, 2007 at 10:15:01AM +0200, Ralf Corsepius wrote: > > > > > On Mon, 2007-05-28 at 09:44 +0200, Patrice Dumas wrote: > > > > > > On Mon, May 28, 2007 at 09:34:20AM +0200, Ralf Corsepius wrote: > > > > > > > > > > > In general scientists do coding > > > > > > just fine but don't want to do more nor even think about it (no > > > > > > packaging, no thoughts on system administration...). > > > > > Well, in 90% of all such cases, "their coding" goes into > > > > > implementing complex algorithms, while their programs complexity > > > > > is not much different from "hello world". > > > > > > > > This sounds quite arrogant. > > > > > > Feel free to think what you want - These number cruncher guys apps > > > condense down to a > > > > > > READ STDIN > > > CALL ALGORITHM > > > PRINT STDOUT > > > > > > Their typical usage: > > > > > > ./myapp < inputdata >output > > > ... wait ... > > > lpr output > > > > > > Oh Ralf, you're such a sweetheart! Bursting with optimism about > > all of human-kind! :-) > > > > Yes, some scientists/engineers are dreadful coders and should never be > > allowed to admin any systems, not even small one-button toaster ovens. > > Some are brilliant coders and/or admins who develop novel algorithms/ > > approaches and build/manage their own clusters. Many fall somewhere > > between those two extremes. > > > > Your "condense down" comments are just silly. Really... silly... > > Thank you, very much - I must have been living on a different planet > than you for the last 15 years. From the way you describe the scientific community this seems quite possible. > I must have been watching a different kind of scientists, blocking > networks and machines with their number crunching jobs over all > these years ... Well ... the networks and machines are there for doing number crunching and not mp3, games, i18n and whatnot. -- 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 rc040203 at freenet.de Mon May 28 15:05:24 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 28 May 2007 17:05:24 +0200 Subject: [Fedora-packaging] Re: paragraph on shipping static numerical libs In-Reply-To: <20070528144417.GD24966@neu.nirvana> References: <645d17210705270827p65699c32ic9cbb8efdf81d124@mail.gmail.com> <20070527200136.GO11952@neu.nirvana> <20070528044104.GB8995@nostromo.devel.redhat.com> <1180337660.4735.1723.camel@mccallum.corsepiu.local> <20070528074434.GD2854@free.fr> <1180340102.4735.1750.camel@mccallum.corsepiu.local> <20070528094739.GC19989@neu.nirvana> <1180352763.4735.1756.camel@mccallum.corsepiu.local> <20070528094934.2f32b2e5@daggett> <1180361859.4735.1778.camel@mccallum.corsepiu.local> <20070528144417.GD24966@neu.nirvana> Message-ID: <1180364724.4735.1796.camel@mccallum.corsepiu.local> On Mon, 2007-05-28 at 16:44 +0200, Axel Thimm wrote: > On Mon, May 28, 2007 at 04:17:39PM +0200, Ralf Corsepius wrote: > > On Mon, 2007-05-28 at 09:49 -0400, Ed Hill wrote: > > > On Mon, 28 May 2007 13:46:03 +0200 Ralf Corsepius wrote: > > > > On Mon, 2007-05-28 at 11:47 +0200, Axel Thimm wrote: > > > > > On Mon, May 28, 2007 at 10:15:01AM +0200, Ralf Corsepius wrote: > > > > > > On Mon, 2007-05-28 at 09:44 +0200, Patrice Dumas wrote: > > > > > > > On Mon, May 28, 2007 at 09:34:20AM +0200, Ralf Corsepius wrote: > > > > > > > > > > > > > In general scientists do coding > > > > > > > just fine but don't want to do more nor even think about it (no > > > > > > > packaging, no thoughts on system administration...). > > > > > > Well, in 90% of all such cases, "their coding" goes into > > > > > > implementing complex algorithms, while their programs complexity > > > > > > is not much different from "hello world". > > > > > > > > > > This sounds quite arrogant. > > > > > > > > Feel free to think what you want - These number cruncher guys apps > > > > condense down to a > > > > > > > > READ STDIN > > > > CALL ALGORITHM > > > > PRINT STDOUT > > > > > > > > Their typical usage: > > > > > > > > ./myapp < inputdata >output > > > > ... wait ... > > > > lpr output > > > > > > > > > Oh Ralf, you're such a sweetheart! Bursting with optimism about > > > all of human-kind! :-) > > > > > > Yes, some scientists/engineers are dreadful coders and should never be > > > allowed to admin any systems, not even small one-button toaster ovens. > > > Some are brilliant coders and/or admins who develop novel algorithms/ > > > approaches and build/manage their own clusters. Many fall somewhere > > > between those two extremes. > > > > > > Your "condense down" comments are just silly. Really... silly... > > > > Thank you, very much - I must have been living on a different planet > > than you for the last 15 years. > > From the way you describe the scientific community this seems quite > possible. I am talking about non-IT/CS scientists: biologists, medics, mathematicians, physicists, electrical/mechanical/construction engineers, etc. at all levels, from 1st semester students to professors. Many of them were brilliant scientists, but more or less illiterate on programming and system adminstration. Some of them just knew enough to be able to launch a shell, use an editor and run the scripts/makefiles and similar others wrote for them. Of cause there were others, who actively "learned by doing" got deeper "into the matters". > > I must have been watching a different kind of scientists, blocking > > networks and machines with their number crunching jobs over all > > these years ... > > Well ... the networks and machines are there for doing number crunching > and not mp3, games, i18n and whatnot. Right, but these persons skills stemmed from "using PCs" at home and from courses at school. A prototypical situation had been: A math student writing his Diploma thesis on "Comparison of different algorithms on application xyz using matlab". Ralf From nicolas.mailhot at laposte.net Mon May 28 15:12:55 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 28 May 2007 17:12:55 +0200 Subject: [Fedora-packaging] Re: paragraph on shipping static numerical libs In-Reply-To: <20070528111616.GF2854@free.fr> References: <20070526104156.GB3105@free.fr> <1180247606.4735.1697.camel@mccallum.corsepiu.local> <20070527081536.GA2841@free.fr> <1180278622.3408.4.camel@localhost.localdomain> <645d17210705270827p65699c32ic9cbb8efdf81d124@mail.gmail.com> <20070527200136.GO11952@neu.nirvana> <20070528044104.GB8995@nostromo.devel.redhat.com> <1180337660.4735.1723.camel@mccallum.corsepiu.local> <20070528094524.GB19989@neu.nirvana> <1180346442.7810.4.camel@rousalka.dyndns.org> <20070528111616.GF2854@free.fr> Message-ID: <1180365175.4191.2.camel@rousalka.dyndns.org> Le lundi 28 mai 2007 ? 13:16 +0200, Patrice Dumas a ?crit : > On Mon, May 28, 2007 at 12:00:42PM +0200, Nicolas Mailhot wrote: > > > > Which sort-of hints shipping static libs is a short-term workaround and > > energy would be better spend making tools like eclipse integrate our > > best-of-breed infrastructure (autoconf, rpm, yum, mock whatever) > > transparently so these people don't have to spend time on plumbing to > > produce modern sofwtare. > > I can't see the connection between eclipse and the issues at stake > here... Shipping static libs is not necessarily a short term workaround, > dynamic libs keep changing ABI and one cannot necesarily install > everytime the libs on all the computers he may want to run a program. > How is it related with eclipse??? Replace one can not with it's too much hassle to and you'll see where I was going. Reduce the hassle factor doing things right and suddenly static libs will get less attractive. -- 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 pertusus at free.fr Mon May 28 15:24:48 2007 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 28 May 2007 17:24:48 +0200 Subject: [Fedora-packaging] Re: paragraph on shipping static numerical libs In-Reply-To: <1180365175.4191.2.camel@rousalka.dyndns.org> References: <20070527081536.GA2841@free.fr> <1180278622.3408.4.camel@localhost.localdomain> <645d17210705270827p65699c32ic9cbb8efdf81d124@mail.gmail.com> <20070527200136.GO11952@neu.nirvana> <20070528044104.GB8995@nostromo.devel.redhat.com> <1180337660.4735.1723.camel@mccallum.corsepiu.local> <20070528094524.GB19989@neu.nirvana> <1180346442.7810.4.camel@rousalka.dyndns.org> <20070528111616.GF2854@free.fr> <1180365175.4191.2.camel@rousalka.dyndns.org> Message-ID: <20070528152448.GA5540@free.fr> On Mon, May 28, 2007 at 05:12:55PM +0200, Nicolas Mailhot wrote: > > Replace one can not with it's too much hassle to and you'll see where I > was going. Reduce the hassle factor doing things right and suddenly > static libs will get less attractive. Ok. What will be replacing them? Adding automatically shared libs and a wrapper to use added libs or system libs based on sonames? It could inded help some users, especially if it is also attractive to those (like me) who write themselves their Makefile and shell scripts (I would never ever use a GUI to develop, but I guess eclipse can do portability stuff on the command line). In any case I doubt it may be as simple as what we have with static libs, with statically linked executables created by adding -static to the link command line... -- Pat From jonathan.underwood at gmail.com Mon May 28 15:35:13 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Mon, 28 May 2007 16:35:13 +0100 Subject: [Fedora-packaging] Packaging guidelines for Emacsen add-on packages In-Reply-To: <645d17210705270942g57ed6f0br1059ba36e2c80183@mail.gmail.com> References: <645d17210705070855j1c76a34eoc4f9f65cae2766ec@mail.gmail.com> <200705271545.11027.ville.skytta@iki.fi> <645d17210705270704n29773165hfb2e4780048f537f@mail.gmail.com> <200705271928.16237.ville.skytta@iki.fi> <645d17210705270942g57ed6f0br1059ba36e2c80183@mail.gmail.com> Message-ID: <645d17210705280835x3f3d22b0k2c1482222d6eff31@mail.gmail.com> On 27/05/07, Jonathan Underwood wrote: > On 27/05/07, Ville Skytt? wrote: > > On Sunday 27 May 2007, Jonathan Underwood wrote: > > > > > I would propose guidelines such as these: > > > 1) Packages which include add on modes for (X)Emacs should package the > > > byte compiled lisp files for these modes in a sub-package named > > > foo-emacs and/or foo-xemacs. > > > > I don't agree with that naming - it doesn't follow the "if it's bar for foo, > > call it foo-bar" naming strategy applied to just about everything else. > > emacs-foo and xemacs-foo would be better. Ditto emacs-foo-el, xemacs-foo-el. > > > > Otherwise, looks good to me. > > Yes - I had that thought initially too. But it becomes a question of > is the mode an add on for Emacs or an add-on for gnuplot (in the > example given). In the end, I couldn't decide either way. Thing is, > current precedent is foo-emacs, so if we're more infavour of > emacs-foo, which is much more consistent, I agree, then a fair few > packages will need to be renamed. > > OTOH, whatever guideline we introduce here will mean some packaging > work will need to be done on existing packages. So perhaps we should > just get it right once and for all. > > I'll wait a while, and if there are no more comments I'll add these > guidelines along with your namingporeference to the wiki page. I have now updated the Guidelines to reflect this issue. Actually, the approach I have taken is to add an executive summary at the top of the page which encompasses this. See what you think. J. From a.badger at gmail.com Mon May 28 17:17:14 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 28 May 2007 10:17:14 -0700 Subject: OCaml and static linking (was old thread: Re: [Fedora-packaging] Issues with Ocaml and Static Linking) In-Reply-To: <465ABCBD.3060701@redhat.com> References: <464F2791.1060309@redhat.com> <1179806148.5161.72.camel@localhost.localdomain> <46584157.2010100@redhat.com> <1180196144.22279.92.camel@localhost.localdomain> <465ABCBD.3060701@redhat.com> Message-ID: On 5/28/07, Richard W.M. Jones wrote: > Toshio Kuratomi wrote: > > Thanks! To my un-OCaml eyes, that looks pretty good. I have one > > question: > > ''' > > There are two scripts in the base ocaml package which automatically > > calculate the right Requires and Provides for a library. To use them, > > just add the following to the spec file: > > > > %define _use_internal_dependency_generator 0 > > %define __find_requires /usr/lib/rpm/ocaml-find-requires.sh > > %define __find_provides /usr/lib/rpm/ocaml-find-provides.sh > > ''' > > > > The version of ocaml-find-* scripts that were posted to the list only > > appeared to find ocaml requires and provides. But OCaml can link to C > > code as well. Do we want to turn off the internal_dependency_generator > > or do we want to supplement it? > > I've attached the latest versions to this bug: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=239004 > > These versions call the ordinary find-requires and find-provides first, > before going on to look at OCaml-specific files. And they appear to > find C dependencies (.so files and the like). For example, here is my > ocaml-pcre package[1], which is a library which links to the C PCRE lib: > Thanks, those scripts look good. -Toshio -Toshio From nicolas.mailhot at laposte.net Mon May 28 16:10:36 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 28 May 2007 18:10:36 +0200 Subject: [Fedora-packaging] Re: paragraph on shipping static numerical libs In-Reply-To: <20070528152448.GA5540@free.fr> References: <20070527081536.GA2841@free.fr> <1180278622.3408.4.camel@localhost.localdomain> <645d17210705270827p65699c32ic9cbb8efdf81d124@mail.gmail.com> <20070527200136.GO11952@neu.nirvana> <20070528044104.GB8995@nostromo.devel.redhat.com> <1180337660.4735.1723.camel@mccallum.corsepiu.local> <20070528094524.GB19989@neu.nirvana> <1180346442.7810.4.camel@rousalka.dyndns.org> <20070528111616.GF2854@free.fr> <1180365175.4191.2.camel@rousalka.dyndns.org> <20070528152448.GA5540@free.fr> Message-ID: <1180368636.4191.33.camel@rousalka.dyndns.org> Le lundi 28 mai 2007 ? 17:24 +0200, Patrice Dumas a ?crit : > On Mon, May 28, 2007 at 05:12:55PM +0200, Nicolas Mailhot wrote: > > > > Replace one can not with it's too much hassle to and you'll see where I > > was going. Reduce the hassle factor doing things right and suddenly > > static libs will get less attractive. > > Ok. What will be replacing them? Help create properly autotooled rpm transparently for people that don't care about infrastructure stuff. You already have cluster managers that use rpm as a payload. That takes care of the deployment, of the interfering stuff in /usr/local, etc > In any case I doubt it may be as simple as what we have with static > libs, with statically linked executables created by adding -static to > the link command line... You focus too much on the current technical solution and not enough on user needs. The problem is not to replicate the same old & broken solution ad vitam eternam but to make the correct technical solution attractive enough for users to switch. I won't share nuggets of ass-backwards common wisdom here, that would strike to close to my employer systems, but sometimes you need to re-asses why a particular solution was chosen at a time and if you can not achieve the original goals better now with stuff that was not available a decade ago. -- 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 pertusus at free.fr Mon May 28 18:04:56 2007 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 28 May 2007 20:04:56 +0200 Subject: [Fedora-packaging] Re: paragraph on shipping static numerical libs In-Reply-To: <1180368636.4191.33.camel@rousalka.dyndns.org> References: <645d17210705270827p65699c32ic9cbb8efdf81d124@mail.gmail.com> <20070527200136.GO11952@neu.nirvana> <20070528044104.GB8995@nostromo.devel.redhat.com> <1180337660.4735.1723.camel@mccallum.corsepiu.local> <20070528094524.GB19989@neu.nirvana> <1180346442.7810.4.camel@rousalka.dyndns.org> <20070528111616.GF2854@free.fr> <1180365175.4191.2.camel@rousalka.dyndns.org> <20070528152448.GA5540@free.fr> <1180368636.4191.33.camel@rousalka.dyndns.org> Message-ID: <20070528180456.GA2904@free.fr> On Mon, May 28, 2007 at 06:10:36PM +0200, Nicolas Mailhot wrote: > > Help create properly autotooled rpm transparently for people that don't > care about infrastructure stuff. You already have cluster managers that > use rpm as a payload. That takes care of the deployment, of the > interfering stuff in /usr/local, etc Ok, I am not really knowledgable on that matters. Is there something viewable, usable? > You focus too much on the current technical solution and not enough on > user needs. The problem is not to replicate the same old & broken > solution ad vitam eternam but to make the correct technical solution > attractive enough for users to switch. I am very open to new solutions, but the use of static libs is not necessarily broken in all cases. > I won't share nuggets of ass-backwards common wisdom here, I don't understand that sentence, ca donne quoi en francais ? > that would > strike to close to my employer systems, but sometimes you need to > re-asses why a particular solution was chosen at a time and if you can > not achieve the original goals better now with stuff that was not > available a decade ago. Once again I am open to new stuff, but I haven't seen anything that would be as simple and effective as building statically (in the case of specific scientific apps I am referring to, of course). And the long thread on fedora-devel only comfort that view since people complained about dstatically compiling but only proposed very complicated alternatives. If those alternatives can be automated and give the same advantages, it could become usable, but currently this is not the case (or nobody pointed to the right solution). -- Pat From nicolas.mailhot at laposte.net Mon May 28 18:53:58 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 28 May 2007 20:53:58 +0200 Subject: [Fedora-packaging] Re: paragraph on shipping static numerical libs In-Reply-To: <20070528180456.GA2904@free.fr> References: <645d17210705270827p65699c32ic9cbb8efdf81d124@mail.gmail.com> <20070527200136.GO11952@neu.nirvana> <20070528044104.GB8995@nostromo.devel.redhat.com> <1180337660.4735.1723.camel@mccallum.corsepiu.local> <20070528094524.GB19989@neu.nirvana> <1180346442.7810.4.camel@rousalka.dyndns.org> <20070528111616.GF2854@free.fr> <1180365175.4191.2.camel@rousalka.dyndns.org> <20070528152448.GA5540@free.fr> <1180368636.4191.33.camel@rousalka.dyndns.org> <20070528180456.GA2904@free.fr> Message-ID: <1180378438.5196.23.camel@rousalka.dyndns.org> Le lundi 28 mai 2007 ? 20:04 +0200, Patrice Dumas a ?crit : > On Mon, May 28, 2007 at 06:10:36PM +0200, Nicolas Mailhot wrote: > > > > Help create properly autotooled rpm transparently for people that don't > > care about infrastructure stuff. You already have cluster managers that > > use rpm as a payload. That takes care of the deployment, of the > > interfering stuff in /usr/local, etc > > Ok, I am not really knowledgable on that matters. Is there something > viewable, usable? I'm sorry, I haven't kept the bookmark, and I can't find it with 30s of googling > > You focus too much on the current technical solution and not enough on > > user needs. The problem is not to replicate the same old & broken > > solution ad vitam eternam but to make the correct technical solution > > attractive enough for users to switch. > > I am very open to new solutions, but the use of static libs is not > necessarily broken in all cases. > > > I won't share nuggets of ass-backwards common wisdom here, > > I don't understand that sentence, ca donne quoi en francais ? Une traduction extr?mement approximative qui sonne moins bien "p?pites d'absurdit?s consid?r?es comme des ?vidences" > Once again I am open to new stuff, but I haven't seen anything that > would be as simple and effective as building statically (in the case of > specific scientific apps I am referring to, of course). You have two missing bits: 1. a nice create-autotooled-rpm-for-dummies environment 2. a deployment framework You have only to look at koji to realise the technical basis for 2. is already there, and IIRC there are products on the market that do the package as payload thing. 1. is harder and is in its infancy today. That's why package systems with broken dependency engines sell and rpm/deb don't. But if you don't get a package feed up people do manual deployments, slowly rot the cluster and make OS upgrades impossible. static is just a way to partially hide the rot. -- 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 pertusus at free.fr Mon May 28 19:39:44 2007 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 28 May 2007 21:39:44 +0200 Subject: [Fedora-packaging] Re: paragraph on shipping static numerical libs In-Reply-To: <1180378438.5196.23.camel@rousalka.dyndns.org> References: <20070528044104.GB8995@nostromo.devel.redhat.com> <1180337660.4735.1723.camel@mccallum.corsepiu.local> <20070528094524.GB19989@neu.nirvana> <1180346442.7810.4.camel@rousalka.dyndns.org> <20070528111616.GF2854@free.fr> <1180365175.4191.2.camel@rousalka.dyndns.org> <20070528152448.GA5540@free.fr> <1180368636.4191.33.camel@rousalka.dyndns.org> <20070528180456.GA2904@free.fr> <1180378438.5196.23.camel@rousalka.dyndns.org> Message-ID: <20070528193944.GF2904@free.fr> On Mon, May 28, 2007 at 08:53:58PM +0200, Nicolas Mailhot wrote: > > Une traduction extr?mement approximative qui sonne moins bien "p?pites > d'absurdit?s consid?r?es comme des ?vidences" C'est joli en tout cas ;-). Pas forcement au niveau du fond, mais au moins de la forme ;-) > > Once again I am open to new stuff, but I haven't seen anything that > > would be as simple and effective as building statically (in the case of > > specific scientific apps I am referring to, of course). > > You have two missing bits: > 1. a nice create-autotooled-rpm-for-dummies environment > 2. a deployment framework > > You have only to look at koji to realise the technical basis for 2. is It is not what koji looks like from the perspective of a fedora contributor, but maybe once there is more doc it will appear more clearly... > already there, and IIRC there are products on the market that do the > package as payload thing. > > 1. is harder and is in its infancy today. That's why package systems > with broken dependency engines sell and rpm/deb don't. It is certainly something different from rpm/deb since it should be doable as a user. > But if you don't get a package feed up people do manual deployments, > slowly rot the cluster and make OS upgrades impossible. static is just a > way to partially hide the rot. That is not the way I see the usefulness of static linked apps. They are for immediate consumption in my use case. -- Pat From nicolas.mailhot at laposte.net Mon May 28 20:35:01 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 28 May 2007 22:35:01 +0200 Subject: [Fedora-packaging] Re: paragraph on shipping static numerical libs In-Reply-To: <20070528193944.GF2904@free.fr> References: <20070528044104.GB8995@nostromo.devel.redhat.com> <1180337660.4735.1723.camel@mccallum.corsepiu.local> <20070528094524.GB19989@neu.nirvana> <1180346442.7810.4.camel@rousalka.dyndns.org> <20070528111616.GF2854@free.fr> <1180365175.4191.2.camel@rousalka.dyndns.org> <20070528152448.GA5540@free.fr> <1180368636.4191.33.camel@rousalka.dyndns.org> <20070528180456.GA2904@free.fr> <1180378438.5196.23.camel@rousalka.dyndns.org> <20070528193944.GF2904@free.fr> Message-ID: <1180384501.11228.11.camel@rousalka.dyndns.org> Le lundi 28 mai 2007 ? 21:39 +0200, Patrice Dumas a ?crit : > > But if you don't get a package feed up people do manual deployments, > > slowly rot the cluster and make OS upgrades impossible. static is just a > > way to partially hide the rot. > > That is not the way I see the usefulness of static linked apps. They are > for immediate consumption in my use case. This is not the only use case. Sometimes the funding used to write numeric models is dependant on the result being runable on the clusters of the BU that earns the money. -- 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 notting at redhat.com Mon May 28 21:22:48 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 28 May 2007 17:22:48 -0400 Subject: [Fedora-packaging] Re: paragraph on shipping static numerical libs In-Reply-To: <20070528093438.GA19989@neu.nirvana> References: <20070526104156.GB3105@free.fr> <1180247606.4735.1697.camel@mccallum.corsepiu.local> <20070527081536.GA2841@free.fr> <1180278622.3408.4.camel@localhost.localdomain> <645d17210705270827p65699c32ic9cbb8efdf81d124@mail.gmail.com> <20070527200136.GO11952@neu.nirvana> <20070528044104.GB8995@nostromo.devel.redhat.com> <20070528093438.GA19989@neu.nirvana> Message-ID: <20070528212248.GB17342@nostromo.devel.redhat.com> Axel Thimm (Axel.Thimm at ATrpms.net) said: > And I only mentioned that the Linux part is homogeneous. Ever wondered > why the majority of Unix admins that have skills in managing > heterogeneous Unix system have a physicist's background? It is far > more important to have a good mips/$ and some scientists on salary, > than to spend all budget for the IT staff's system management. If you are spending all the budget for IT staff to do system management, you're doing it wrong; there's no reason that systems management should be on the par you're talking about. There are places that run hundreds to thousands of machines with a single administrator. Honestly? It sounds like a vicious cycle of "we don't think we have the time to set up a consistent platform, so we don't, so we have to spend too much time managing it, so we don't have the time to set up a new platform..." > > If you want consistent results, run a consistent platform. > > So you outrule Fedora? Because consistent means even more than a > stable API/ABI, RHEL comes close to that, but switching to RHEL > because a distro does not want to offer static libs is not reason > enough, especially in light of development of key components like > gfortran that is reflected in RHEL only a couple years after it makes > it into the non-enterprise platforms. RHEL doesn't even *ship* this scientific stuff, for a large part. All I'm saying is that we shouldn't continue to support this sort of fundamentally-unsupportable setup ad nauseam - it's time to think about how to solve this in a sane manner, rather than continuing to paper over the problem. I don't see how, at a minium, moving the static libraries to -static packages changes things - if, as you say, everyone just chucks libraries manually in /usr/local, then how is this making anything worse for them? Bill From Axel.Thimm at ATrpms.net Mon May 28 21:32:49 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 28 May 2007 23:32:49 +0200 Subject: [Fedora-packaging] Re: paragraph on shipping static numerical libs In-Reply-To: <20070528212248.GB17342@nostromo.devel.redhat.com> References: <20070526104156.GB3105@free.fr> <1180247606.4735.1697.camel@mccallum.corsepiu.local> <20070527081536.GA2841@free.fr> <1180278622.3408.4.camel@localhost.localdomain> <645d17210705270827p65699c32ic9cbb8efdf81d124@mail.gmail.com> <20070527200136.GO11952@neu.nirvana> <20070528044104.GB8995@nostromo.devel.redhat.com> <20070528093438.GA19989@neu.nirvana> <20070528212248.GB17342@nostromo.devel.redhat.com> Message-ID: <20070528213249.GD5211@neu.nirvana> On Mon, May 28, 2007 at 05:22:48PM -0400, Bill Nottingham wrote: > Axel Thimm (Axel.Thimm at ATrpms.net) said: > > And I only mentioned that the Linux part is homogeneous. Ever wondered > > why the majority of Unix admins that have skills in managing > > heterogeneous Unix system have a physicist's background? It is far > > more important to have a good mips/$ and some scientists on salary, > > than to spend all budget for the IT staff's system management. > > If you are spending all the budget for IT staff to do system management, > you're doing it wrong; there's no reason that systems management should > be on the par you're talking about. There are places that run hundreds > to thousands of machines with a single administrator. Honestly? It sounds > like a vicious cycle of "we don't think we have the time to set up > a consistent platform, so we don't, so we have to spend too much time > managing it, so we don't have the time to set up a new platform..." And how did that single admin get 1000 systems that are obviously similar enough to be managed by a single person? Maybe because the budget allowed to buy a rather homegeneous pile of hardware? You have large hardware histories in large institutions, partly due to vendor availability at a given time. It's not a school, where you can throw out a couple hundred 500$ PC and replace them with the same every 2-3 years, so you can keep a sane hardware status. > > > If you want consistent results, run a consistent platform. > > > > So you outrule Fedora? Because consistent means even more than a > > stable API/ABI, RHEL comes close to that, but switching to RHEL > > because a distro does not want to offer static libs is not reason > > enough, especially in light of development of key components like > > gfortran that is reflected in RHEL only a couple years after it makes > > it into the non-enterprise platforms. > > RHEL doesn't even *ship* this scientific stuff, for a large part. It's not about shipping scientific applications but allowing the base OS to build/use them on your own. > All I'm saying is that we shouldn't continue to support this sort of > fundamentally-unsupportable setup ad nauseam - it's time to think about > how to solve this in a sane manner, rather than continuing to paper > over the problem. I don't see how, at a minium, moving the static > libraries to -static packages changes things - if, as you say, everyone > just chucks libraries manually in /usr/local, then how is this making > anything worse for them? No problem at all with moving away static libs into their subpackage! But the thread went on to claim that static libs are not useful in general, and some people including myself just showed the typical use cases where it makes very much sense to have static libs around. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From pertusus at free.fr Mon May 28 21:35:53 2007 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 28 May 2007 23:35:53 +0200 Subject: [Fedora-packaging] Re: paragraph on shipping static numerical libs In-Reply-To: <20070528212248.GB17342@nostromo.devel.redhat.com> References: <20070526104156.GB3105@free.fr> <1180247606.4735.1697.camel@mccallum.corsepiu.local> <20070527081536.GA2841@free.fr> <1180278622.3408.4.camel@localhost.localdomain> <645d17210705270827p65699c32ic9cbb8efdf81d124@mail.gmail.com> <20070527200136.GO11952@neu.nirvana> <20070528044104.GB8995@nostromo.devel.redhat.com> <20070528093438.GA19989@neu.nirvana> <20070528212248.GB17342@nostromo.devel.redhat.com> Message-ID: <20070528213553.GH2904@free.fr> On Mon, May 28, 2007 at 05:22:48PM -0400, Bill Nottingham wrote: > > RHEL doesn't even *ship* this scientific stuff, for a large part. > > All I'm saying is that we shouldn't continue to support this sort of > fundamentally-unsupportable setup ad nauseam - it's time to think about > how to solve this in a sane manner, rather than continuing to paper > over the problem. I don't see how, at a minium, moving the static > libraries to -static packages changes things - if, as you say, everyone > just chucks libraries manually in /usr/local, then how is this making > anything worse for them? The static libs are needed on the fedora box to be able to link statically on that platform and use it where there are libraries installed in /usr/local without needing to relink. -- Pat From skvidal at linux.duke.edu Tue May 29 02:14:21 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Mon, 28 May 2007 22:14:21 -0400 Subject: [Fedora-packaging] Re: paragraph on shipping static numerical libs In-Reply-To: <20070528213249.GD5211@neu.nirvana> References: <20070526104156.GB3105@free.fr> <1180247606.4735.1697.camel@mccallum.corsepiu.local> <20070527081536.GA2841@free.fr> <1180278622.3408.4.camel@localhost.localdomain> <645d17210705270827p65699c32ic9cbb8efdf81d124@mail.gmail.com> <20070527200136.GO11952@neu.nirvana> <20070528044104.GB8995@nostromo.devel.redhat.com> <20070528093438.GA19989@neu.nirvana> <20070528212248.GB17342@nostromo.devel.redhat.com> <20070528213249.GD5211@neu.nirvana> Message-ID: <1180404861.2477.3.camel@rivendell> On Mon, 2007-05-28 at 23:32 +0200, Axel Thimm wrote: > And how did that single admin get 1000 systems that are obviously > similar enough to be managed by a single person? Maybe because the > budget allowed to buy a rather homegeneous pile of hardware? > I call crap on that. I was a single systems person for a bunch of systems for a long time. You keep your sanity by enforcing policy and you can do that by using the tools available to you to simplify the tasks. You don't need homogeneous hw, you need LARGELY homogeneous hw. So you limit the processor archs and you try to focus things down as much as possible. It took me 2 years to get rid of all the sun crap in the physics department but I did. I still had wacky AXP crap after that but then another few years and that was gone, too. My point is it didn't have much to do with the distro, it had more to do with me finding and working policy in place where it needed to happen. and THAT is how a sysadmin survives and thrives. By learning where they can engineer around a solution and where they need to use policy to help themselves. In this case Bill is right, this is where we realize that we can make the engineering help get rid of years of bad policy. -sv From notting at redhat.com Tue May 29 03:18:43 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 28 May 2007 23:18:43 -0400 Subject: [Fedora-packaging] Re: paragraph on shipping static numerical libs In-Reply-To: <20070528213249.GD5211@neu.nirvana> References: <20070526104156.GB3105@free.fr> <1180247606.4735.1697.camel@mccallum.corsepiu.local> <20070527081536.GA2841@free.fr> <1180278622.3408.4.camel@localhost.localdomain> <645d17210705270827p65699c32ic9cbb8efdf81d124@mail.gmail.com> <20070527200136.GO11952@neu.nirvana> <20070528044104.GB8995@nostromo.devel.redhat.com> <20070528093438.GA19989@neu.nirvana> <20070528212248.GB17342@nostromo.devel.redhat.com> <20070528213249.GD5211@neu.nirvana> Message-ID: <20070529031843.GC19938@nostromo.devel.redhat.com> Axel Thimm (Axel.Thimm at ATrpms.net) said: > > All I'm saying is that we shouldn't continue to support this sort of > > fundamentally-unsupportable setup ad nauseam - it's time to think about > > how to solve this in a sane manner, rather than continuing to paper > > over the problem. I don't see how, at a minium, moving the static > > libraries to -static packages changes things - if, as you say, everyone > > just chucks libraries manually in /usr/local, then how is this making > > anything worse for them? > > No problem at all with moving away static libs into their subpackage! > But the thread went on to claim that static libs are not useful in > general, and some people including myself just showed the typical use > cases where it makes very much sense to have static libs around. They aren't useful *in general*. It's supporting an outmoded, inefficient mode of use (shuffling libraries and binaries around between machines and OSes), and it's no different than various other outmoded, inefficient, past UNIX-isms. We don't support every app parsing the password file (or more) - we support authenticating via PAM. We don't support making cdrecord setuid - we support fixing the kernel to DTRT. We don't encourage logging in as root to do all tasks - we support consolehelper, and moving to things like consolekit and separated helpers from their UI frontends. We don't support creating specific groups to own devices - we support pam_console and then ACLs added via ConsoleKit. We don't support every single usage case that people want in Fedora - it's about trying to solve the problems in the right ways that scale going forward. Bill From pertusus at free.fr Tue May 29 06:38:31 2007 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 29 May 2007 08:38:31 +0200 Subject: [Fedora-packaging] Re: paragraph on shipping static numerical libs In-Reply-To: <20070529031843.GC19938@nostromo.devel.redhat.com> References: <1180247606.4735.1697.camel@mccallum.corsepiu.local> <20070527081536.GA2841@free.fr> <1180278622.3408.4.camel@localhost.localdomain> <645d17210705270827p65699c32ic9cbb8efdf81d124@mail.gmail.com> <20070527200136.GO11952@neu.nirvana> <20070528044104.GB8995@nostromo.devel.redhat.com> <20070528093438.GA19989@neu.nirvana> <20070528212248.GB17342@nostromo.devel.redhat.com> <20070528213249.GD5211@neu.nirvana> <20070529031843.GC19938@nostromo.devel.redhat.com> Message-ID: <20070529063831.GA2844@free.fr> On Mon, May 28, 2007 at 11:18:43PM -0400, Bill Nottingham wrote: > > They aren't useful *in general*. It's supporting an outmoded, inefficient > mode of use (shuffling libraries and binaries around between machines and > OSes), and it's no different than various other outmoded, inefficient, > past UNIX-isms. It is efficient, but not general. What we are asking is to let the possibility to the user to do this use when it makes sense. > We don't support every app parsing the password file > (or more) - we support authenticating via PAM. We don't support making But you still havent replaced /etc/passwd with something that couldn't be parsed by the user. > cdrecord setuid - we support fixing the kernel to DTRT. We don't But people can still set the setuid bit. > encourage logging in as root to do all tasks - we support consolehelper, Still it is possible to log in as root if one wants. > and moving to things like consolekit and separated helpers from their > UI frontends. We don't support creating specific groups to own devices - > we support pam_console and then ACLs added via ConsoleKit. Once again a user can use groups to own devices by changing configuration (at least I hope so...). Regarding the use of Consolekit it is too new to me to have an advice. The fact that it isn't supported doesn't mean that it should be prevented. At least I hope that's not what you do with RHEL customers (and I guess that you cannot legally). Of course the support could be void in those cases. > We don't support every single usage case that people want in Fedora - > it's about trying to solve the problems in the right ways that scale > going forward. So what is 'the right ways that scale going forward' for that issue? Once again it is not about linking statically in fedora, but about letting this possibility to the user, especially in cases when it could be usefull -- you don't have to support the user doing this. I hope that shipping something in RHEL doesn't mean that you support every use of that piece of code. -- Pat From Axel.Thimm at ATrpms.net Tue May 29 07:35:00 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 29 May 2007 09:35:00 +0200 Subject: [Fedora-packaging] Re: paragraph on shipping static numerical libs In-Reply-To: <1180404861.2477.3.camel@rivendell> References: <1180247606.4735.1697.camel@mccallum.corsepiu.local> <20070527081536.GA2841@free.fr> <1180278622.3408.4.camel@localhost.localdomain> <645d17210705270827p65699c32ic9cbb8efdf81d124@mail.gmail.com> <20070527200136.GO11952@neu.nirvana> <20070528044104.GB8995@nostromo.devel.redhat.com> <20070528093438.GA19989@neu.nirvana> <20070528212248.GB17342@nostromo.devel.redhat.com> <20070528213249.GD5211@neu.nirvana> <1180404861.2477.3.camel@rivendell> Message-ID: <20070529073500.GA3821@neu.nirvana> On Mon, May 28, 2007 at 10:14:21PM -0400, seth vidal wrote: > On Mon, 2007-05-28 at 23:32 +0200, Axel Thimm wrote: > > > And how did that single admin get 1000 systems that are obviously > > similar enough to be managed by a single person? Maybe because the > > budget allowed to buy a rather homegeneous pile of hardware? > > > > I call crap on that. I was a single systems person for a bunch of > systems for a long time. You keep your sanity by enforcing policy and > you can do that by using the tools available to you to simplify the > tasks. You don't need homogeneous hw, you need LARGELY homogeneous hw. Well, I used the phrase RATHER homogeneous hw, so we're not that far apart. > So you limit the processor archs and you try to focus things down as > much as possible. > > It took me 2 years to get rid of all the sun crap in the physics > department but I did. Which implies that you had enough resources (or cheap enough hardware) to replace these machines in a two year turnaround. That's what I call a high budget. Any mpp system I have used had a turnaround of at least 5-7 years, they do have 8 digit $/? costs after all. > I still had wacky AXP crap after that but then another few years and > that was gone, too. > > My point is it didn't have much to do with the distro, No, the discussion is not about the distro at all: It is about acknowledging that phys/chem institutions and academia do not have the luxury of a flat same-hw-same-os infrastructure for various reasons, be that due to the project's constraints (at DESY we've been developing our own set of VLIW processors), separation of development and number crunch systems/clusters, exchange across the institutional border in scientific networks, different ages of the distro, and what else has been said in this thread. US/Japan have a better budgeting in IT infrastucture, that's an ongoing joke among European/Russian physicists. So Duke may have given you a different impression. > it had more to do with me finding and working policy in place where > it needed to happen. and THAT is how a sysadmin survives and > thrives. By learning where they can engineer around a solution and > where they need to use policy to help themselves. > > In this case Bill is right, this is where we realize that we can > make the engineering help get rid of years of bad policy. The reality is that you will not chnage these structures and that these users will pick what distro suits them. If it becomes harder and harder to run their codes on Fedora and RHEL then they will check for alternatives, and not wait for the next generation solution to show up. -- 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 May 29 07:41:37 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 29 May 2007 09:41:37 +0200 Subject: [Fedora-packaging] Re: paragraph on shipping static numerical libs In-Reply-To: <20070529031843.GC19938@nostromo.devel.redhat.com> References: <1180247606.4735.1697.camel@mccallum.corsepiu.local> <20070527081536.GA2841@free.fr> <1180278622.3408.4.camel@localhost.localdomain> <645d17210705270827p65699c32ic9cbb8efdf81d124@mail.gmail.com> <20070527200136.GO11952@neu.nirvana> <20070528044104.GB8995@nostromo.devel.redhat.com> <20070528093438.GA19989@neu.nirvana> <20070528212248.GB17342@nostromo.devel.redhat.com> <20070528213249.GD5211@neu.nirvana> <20070529031843.GC19938@nostromo.devel.redhat.com> Message-ID: <20070529074137.GB3821@neu.nirvana> On Mon, May 28, 2007 at 11:18:43PM -0400, Bill Nottingham wrote: > Axel Thimm (Axel.Thimm at ATrpms.net) said: > > > All I'm saying is that we shouldn't continue to support this sort of > > > fundamentally-unsupportable setup ad nauseam - it's time to think about > > > how to solve this in a sane manner, rather than continuing to paper > > > over the problem. I don't see how, at a minium, moving the static > > > libraries to -static packages changes things - if, as you say, everyone > > > just chucks libraries manually in /usr/local, then how is this making > > > anything worse for them? > > > > No problem at all with moving away static libs into their subpackage! > > But the thread went on to claim that static libs are not useful in > > general, and some people including myself just showed the typical use > > cases where it makes very much sense to have static libs around. > > They aren't useful *in general*. When I wrote that the claim is false that they are not useful in general, I didn't mean that "they are always useful", the opposite is that "there are many cases where statically linking makes very much sense". > It's supporting an outmoded, inefficient mode of use (shuffling > libraries and binaries around between machines and OSes), and it's > no different than various other outmoded, inefficient, past > UNIX-isms. We don't support every app parsing the password file (or > more) - we support authenticating via PAM. We don't support making > cdrecord setuid - we support fixing the kernel to DTRT. We don't > encourage logging in as root to do all tasks - we support > consolehelper, and moving to things like consolekit and separated > helpers from their UI frontends. We don't support creating specific > groups to own devices - we support pam_console and then ACLs added > via ConsoleKit. IMHO you're comapring apples and organges. Statically linking has nothing to do with being modern or outmoded, we're not in the fashion business ;) Statically linking means to closely (and efficiently!) bundle all bits that are needed to run together at a given time. No worries if your update of the gsl of lapack will influence the numerical precision duo to ieee746 shortcuts, no worries if the other machine has a different set of runtime libs (like missing some). That has nothing to do with modernism. > We don't support every single usage case that people want in Fedora Sure, that's why I asked previously in this thread whether the scientifc gorups are considered worth supporting or not. > - it's about trying to solve the problems in the right ways that > scale going forward. The moment you present a better alternative than statically linking people will listen. -- 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 May 29 07:58:03 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 29 May 2007 09:58:03 +0200 (CEST) Subject: [Fedora-packaging] Re: paragraph on shipping static numerical libs In-Reply-To: <20070528212248.GB17342@nostromo.devel.redhat.com> References: <20070526104156.GB3105@free.fr> <1180247606.4735.1697.camel@mccallum.corsepiu.local> <20070527081536.GA2841@free.fr> <1180278622.3408.4.camel@localhost.localdomain> <645d17210705270827p65699c32ic9cbb8efdf81d124@mail.gmail.com> <20070527200136.GO11952@neu.nirvana> <20070528044104.GB8995@nostromo.devel.redhat.com> <20070528093438.GA19989@neu.nirvana> <20070528212248.GB17342@nostromo.devel.redhat.com> Message-ID: <58229.192.54.193.51.1180425483.squirrel@rousalka.dyndns.org> Le Lun 28 mai 2007 23:22, Bill Nottingham a ?crit : > Honestly? It sounds > like a vicious cycle of "we don't think we have the time to set up > a consistent platform, so we don't, so we have to spend too much time > managing it, so we don't have the time to set up a new platform..." +10 Letting platforms lag & diverge is the quickest path to IT maintenance overspending. You win some short term and lose a lot mid-term. -- Nicolas Mailhot From nicolas.mailhot at laposte.net Tue May 29 08:05:20 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 29 May 2007 10:05:20 +0200 (CEST) Subject: [Fedora-packaging] Re: paragraph on shipping static numerical libs In-Reply-To: <20070528213249.GD5211@neu.nirvana> References: <20070526104156.GB3105@free.fr> <1180247606.4735.1697.camel@mccallum.corsepiu.local> <20070527081536.GA2841@free.fr> <1180278622.3408.4.camel@localhost.localdomain> <645d17210705270827p65699c32ic9cbb8efdf81d124@mail.gmail.com> <20070527200136.GO11952@neu.nirvana> <20070528044104.GB8995@nostromo.devel.redhat.com> <20070528093438.GA19989@neu.nirvana> <20070528212248.GB17342@nostromo.devel.redhat.com> <20070528213249.GD5211@neu.nirvana> Message-ID: <32394.192.54.193.51.1180425920.squirrel@rousalka.dyndns.org> Le Lun 28 mai 2007 23:32, Axel Thimm a ?crit : > And how did that single admin get 1000 systems that are obviously > similar enough to be managed by a single person? Maybe because the > budget allowed to buy a rather homegeneous pile of hardware? Planning. You only buy systems from the same shortlist several years on a row because you know the maintenance burden associated with new configs overweights their short-term advantages (that also gives you volumes to negociate prices with hardware vendors). -- Nicolas Mailhot From Axel.Thimm at ATrpms.net Tue May 29 08:40:31 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 29 May 2007 10:40:31 +0200 Subject: [Fedora-packaging] Re: paragraph on shipping static numerical libs In-Reply-To: <32394.192.54.193.51.1180425920.squirrel@rousalka.dyndns.org> References: <1180247606.4735.1697.camel@mccallum.corsepiu.local> <20070527081536.GA2841@free.fr> <1180278622.3408.4.camel@localhost.localdomain> <645d17210705270827p65699c32ic9cbb8efdf81d124@mail.gmail.com> <20070527200136.GO11952@neu.nirvana> <20070528044104.GB8995@nostromo.devel.redhat.com> <20070528093438.GA19989@neu.nirvana> <20070528212248.GB17342@nostromo.devel.redhat.com> <20070528213249.GD5211@neu.nirvana> <32394.192.54.193.51.1180425920.squirrel@rousalka.dyndns.org> Message-ID: <20070529084031.GC3821@neu.nirvana> On Tue, May 29, 2007 at 10:05:20AM +0200, Nicolas Mailhot wrote: > Le Lun 28 mai 2007 23:32, Axel Thimm a ?crit : > > And how did that single admin get 1000 systems that are obviously > > similar enough to be managed by a single person? Maybe because the > > budget allowed to buy a rather homegeneous pile of hardware? > > Planning. You only buy systems from the same shortlist several years > on a row because you know the maintenance burden associated with new > configs overweights their short-term advantages (that also gives you > volumes to negociate prices with hardware vendors). But in serious number crunching the decision of hardware planning is not left to the IT staff, but the project managers themselves. We're talking two kind of hw here, simple desktops, where you can recycle them every second or third year and clusters/mpp systems that do the hard work. -- 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 May 29 08:58:54 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 29 May 2007 10:58:54 +0200 (CEST) Subject: [Fedora-packaging] Re: paragraph on shipping static numerical libs In-Reply-To: <20070529084031.GC3821@neu.nirvana> References: <1180247606.4735.1697.camel@mccallum.corsepiu.local> <20070527081536.GA2841@free.fr> <1180278622.3408.4.camel@localhost.localdomain> <645d17210705270827p65699c32ic9cbb8efdf81d124@mail.gmail.com> <20070527200136.GO11952@neu.nirvana> <20070528044104.GB8995@nostromo.devel.redhat.com> <20070528093438.GA19989@neu.nirvana> <20070528212248.GB17342@nostromo.devel.redhat.com> <20070528213249.GD5211@neu.nirvana> <32394.192.54.193.51.1180425920.squirrel@rousalka.dyndns.org> <20070529084031.GC3821@neu.nirvana> Message-ID: <6034.192.54.193.51.1180429134.squirrel@rousalka.dyndns.org> Le Mar 29 mai 2007 10:40, Axel Thimm a ?crit : > On Tue, May 29, 2007 at 10:05:20AM +0200, Nicolas Mailhot wrote: >> Le Lun 28 mai 2007 23:32, Axel Thimm a ?crit : >> > And how did that single admin get 1000 systems that are obviously >> > similar enough to be managed by a single person? Maybe because the >> > budget allowed to buy a rather homegeneous pile of hardware? >> >> Planning. You only buy systems from the same shortlist several years >> on a row because you know the maintenance burden associated with new >> configs overweights their short-term advantages (that also gives you >> volumes to negociate prices with hardware vendors). > > But in serious number crunching the decision of hardware planning is > not left to the IT staff, but the project managers themselves. So what? You complain about overly small IT budgets, and then you say the people who choose the hardware don't consult the people that know how much it'll cost to run it? Do I need to draw you a picture? -- Nicolas Mailhot From Axel.Thimm at ATrpms.net Tue May 29 09:28:08 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 29 May 2007 11:28:08 +0200 Subject: [Fedora-packaging] Re: paragraph on shipping static numerical libs In-Reply-To: <6034.192.54.193.51.1180429134.squirrel@rousalka.dyndns.org> References: <1180278622.3408.4.camel@localhost.localdomain> <645d17210705270827p65699c32ic9cbb8efdf81d124@mail.gmail.com> <20070527200136.GO11952@neu.nirvana> <20070528044104.GB8995@nostromo.devel.redhat.com> <20070528093438.GA19989@neu.nirvana> <20070528212248.GB17342@nostromo.devel.redhat.com> <20070528213249.GD5211@neu.nirvana> <32394.192.54.193.51.1180425920.squirrel@rousalka.dyndns.org> <20070529084031.GC3821@neu.nirvana> <6034.192.54.193.51.1180429134.squirrel@rousalka.dyndns.org> Message-ID: <20070529092808.GD3821@neu.nirvana> On Tue, May 29, 2007 at 10:58:54AM +0200, Nicolas Mailhot wrote: > Le Mar 29 mai 2007 10:40, Axel Thimm a ?crit : > > On Tue, May 29, 2007 at 10:05:20AM +0200, Nicolas Mailhot wrote: > >> Le Lun 28 mai 2007 23:32, Axel Thimm a ?crit : > >> > And how did that single admin get 1000 systems that are obviously > >> > similar enough to be managed by a single person? Maybe because the > >> > budget allowed to buy a rather homegeneous pile of hardware? > >> > >> Planning. You only buy systems from the same shortlist several years > >> on a row because you know the maintenance burden associated with new > >> configs overweights their short-term advantages (that also gives you > >> volumes to negociate prices with hardware vendors). > > > > But in serious number crunching the decision of hardware planning is > > not left to the IT staff, but the project managers themselves. > > So what? You complain about overly small IT budgets, and then you say > the people who choose the hardware don't consult the people that know > how much it'll cost to run it? Do I need to draw you a picture? Well, for one I'm just quoting facts, no more, no less. And yes, the people evaluating mips/$ are not the IT staff (because they usually don't even understand what the code does and how to find out where the mips could be improved). You get scientists benchmarking the systems with tuned gcc or assembly to see how the platfomr fits their numerical calculus. And once the system is found that will provide the nuerics for the next 5-7 years the IT staff has to support it. AT that point it time it doesn't matter if it will be running FC4, RHEL, SLES, Altrix or a non-Linux environment. So, sitting as the IT staff manager on the other side and planning to deploy F7 everywhere is not going to work. You only get to choose the desktops and perhaps a smallish cluster. It's different in experimental groups - there you get more power as an IT admin. I'm not making this up, that's what I'm seeing in the last 18 years in phys/chem (and it certainly wasn't better before that). The question is will Fedora just say "we don't care, your IT management model sucks", or will it try to keep this group happy? I think it sounds more like the former, but whatever it is, we don't really have to fight over their IT management system: Whether it actually fits the surroundings or could be improved, we're not going to change it, we're just either supporting it or not. -- 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 May 29 10:55:17 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 29 May 2007 12:55:17 +0200 (CEST) Subject: [Fedora-packaging] Re: paragraph on shipping static numerical libs In-Reply-To: <20070529092808.GD3821@neu.nirvana> References: <1180278622.3408.4.camel@localhost.localdomain> <645d17210705270827p65699c32ic9cbb8efdf81d124@mail.gmail.com> <20070527200136.GO11952@neu.nirvana> <20070528044104.GB8995@nostromo.devel.redhat.com> <20070528093438.GA19989@neu.nirvana> <20070528212248.GB17342@nostromo.devel.redhat.com> <20070528213249.GD5211@neu.nirvana> <32394.192.54.193.51.1180425920.squirrel@rousalka.dyndns.org> <20070529084031.GC3821@neu.nirvana> <6034.192.54.193.51.1180429134.squirrel@rousalka.dyndns.org> <20070529092808.GD3821@neu.nirvana> Message-ID: <27679.192.54.193.51.1180436117.squirrel@rousalka.dyndns.org> Le Mar 29 mai 2007 11:28, Axel Thimm a ?crit : > On Tue, May 29, 2007 at 10:58:54AM +0200, Nicolas Mailhot wrote: >> Le Mar 29 mai 2007 10:40, Axel Thimm a ?crit : >> > But in serious number crunching the decision of hardware planning >> is >> > not left to the IT staff, but the project managers themselves. >> >> So what? You complain about overly small IT budgets, and then you >> say >> the people who choose the hardware don't consult the people that >> know >> how much it'll cost to run it? Do I need to draw you a picture? > > Well, for one I'm just quoting facts, no more, no less. And yes, the > people evaluating mips/$ are not the IT staff (because they usually > don't even understand what the code does and how to find out where the > mips could be improved). > It's different in > experimental groups - there you get more power as an IT admin. Well here projects get to evaluate/choose the hardware/software they want, but they need IT entities sign-in before any purchase is un-blocked, so if their choice is not on the existing shortlist they have the choice between gowing back to the drawing board or agree to cough up the associated maintenance budget extension. Does wonders to avoid gratuituous platform inflation. And no this is not an experimental group context - quite the contrary. -- Nicolas Mailhot From jonathan.underwood at gmail.com Tue May 29 23:26:30 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Wed, 30 May 2007 00:26:30 +0100 Subject: [Fedora-packaging] Packaging guidelines for Emacsen add-on packages In-Reply-To: <200705271545.11027.ville.skytta@iki.fi> References: <645d17210705070855j1c76a34eoc4f9f65cae2766ec@mail.gmail.com> <464BD29B.60609@redhat.com> <645d17210705170306j3eb78fd1pd638e87513798d64@mail.gmail.com> <200705271545.11027.ville.skytta@iki.fi> Message-ID: <645d17210705291626u23fd71aaoe3f9652f33e0f4c@mail.gmail.com> On 27/05/07, Ville Skytt? wrote: > Regarding the current Emacsen add-on draft, > > * Added some more info about requiring a version of (X)Emacs newer than or > equal to the one used to compile the *.elcs, and how to find that version out > dynamically during package build. > Actually, I was just testing this, and it doesn't work. You added these macros: %define emacsversion v=$(rpm -q --qf=%%{VERSION} emacs) ; case $v in 2*) echo $v ;; *) echo 0 ;; esac %define xemacsversion v=$(rpm -q --qf=%%{VERSION} xemacs) ; case $v in 2*) echo $v ;; *) echo 0 ;; esac And so whenthere is a Requires: emacs-common >= %{emacsversion} you get an error like this: error: line 21: Dependency tokens must begin with alpha-numeric, '_' or '/': Requires: emacs-common >= v=$(rpm -q --qf=%{VERSION} emacs) ; case $v in 2*) echo $v ;; *) echo 0 ;; esac J. From jonathan.underwood at gmail.com Tue May 29 23:40:57 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Wed, 30 May 2007 00:40:57 +0100 Subject: [Fedora-packaging] Packaging guidelines for Emacsen add-on packages In-Reply-To: <645d17210705291626u23fd71aaoe3f9652f33e0f4c@mail.gmail.com> References: <645d17210705070855j1c76a34eoc4f9f65cae2766ec@mail.gmail.com> <464BD29B.60609@redhat.com> <645d17210705170306j3eb78fd1pd638e87513798d64@mail.gmail.com> <200705271545.11027.ville.skytta@iki.fi> <645d17210705291626u23fd71aaoe3f9652f33e0f4c@mail.gmail.com> Message-ID: <645d17210705291640m6e4f24d4ic911bc20f1f0140b@mail.gmail.com> On 30/05/07, Jonathan Underwood wrote: > On 27/05/07, Ville Skytt? wrote: > > Regarding the current Emacsen add-on draft, > > > > * Added some more info about requiring a version of (X)Emacs newer than or > > equal to the one used to compile the *.elcs, and how to find that version out > > dynamically during package build. > > > > Actually, I was just testing this, and it doesn't work. > > You added these macros: > %define emacsversion v=$(rpm -q --qf=%%{VERSION} emacs) ; case $v in > 2*) echo $v ;; *) echo 0 ;; esac > > %define xemacsversion v=$(rpm -q --qf=%%{VERSION} xemacs) ; case $v in > 2*) echo $v ;; *) echo 0 ;; esac > > And so whenthere is a Requires: emacs-common >= %{emacsversion} you > get an error like this: > > error: line 21: Dependency tokens must begin with alpha-numeric, '_' > or '/': Requires: emacs-common >= v=$(rpm -q --qf=%{VERSION} emacs) ; > case $v in 2*) echo $v ;; *) echo 0 ;; esac Also, this wouldn't work as intended on a system where more than one arch of the emacs package is installed - eg. on my system i seem to have emacs.x86_64 and emacs.i386 installed, and so rpm -q --qf=%{VERSION} emacs gives 22.0.9922.0.99. Granted, that wouldn't happen in a mock chroot buildroot, but still, I think we should do a bit better than that :) Can't see how though :( J. > > J. > From tcallawa at redhat.com Tue May 29 23:58:50 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 29 May 2007 18:58:50 -0500 Subject: [Fedora-packaging] Packaging guidelines for Emacsen add-on packages In-Reply-To: <645d17210705291626u23fd71aaoe3f9652f33e0f4c@mail.gmail.com> References: <645d17210705070855j1c76a34eoc4f9f65cae2766ec@mail.gmail.com> <464BD29B.60609@redhat.com> <645d17210705170306j3eb78fd1pd638e87513798d64@mail.gmail.com> <200705271545.11027.ville.skytta@iki.fi> <645d17210705291626u23fd71aaoe3f9652f33e0f4c@mail.gmail.com> Message-ID: <1180483130.6254.463.camel@localhost.localdomain> On Wed, 2007-05-30 at 00:26 +0100, Jonathan Underwood wrote: > On 27/05/07, Ville Skytt? wrote: > > Regarding the current Emacsen add-on draft, > > > > * Added some more info about requiring a version of (X)Emacs newer than or > > equal to the one used to compile the *.elcs, and how to find that version out > > dynamically during package build. > > > > Actually, I was just testing this, and it doesn't work. > > You added these macros: > %define emacsversion v=$(rpm -q --qf=%%{VERSION} emacs) ; case $v in > 2*) echo $v ;; *) echo 0 ;; esac > > %define xemacsversion v=$(rpm -q --qf=%%{VERSION} xemacs) ; case $v in > 2*) echo $v ;; *) echo 0 ;; esac Good lord. No. Thou shalt not query rpm inside rpm. Ask emacs/xemacs what version it is. ~spot From ville.skytta at iki.fi Wed May 30 06:42:16 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Wed, 30 May 2007 09:42:16 +0300 Subject: [Fedora-packaging] Packaging guidelines for Emacsen add-on packages In-Reply-To: <645d17210705291626u23fd71aaoe3f9652f33e0f4c@mail.gmail.com> References: <645d17210705070855j1c76a34eoc4f9f65cae2766ec@mail.gmail.com> <200705271545.11027.ville.skytta@iki.fi> <645d17210705291626u23fd71aaoe3f9652f33e0f4c@mail.gmail.com> Message-ID: <200705300942.17100.ville.skytta@iki.fi> On Wednesday 30 May 2007, Jonathan Underwood wrote: > Actually, I was just testing this, and it doesn't work. > > You added these macros: > %define emacsversion v=$(rpm -q --qf=%%{VERSION} emacs) ; case $v in > 2*) echo $v ;; *) echo 0 ;; esac > > %define xemacsversion v=$(rpm -q --qf=%%{VERSION} xemacs) ; case $v in > 2*) echo $v ;; *) echo 0 ;; esac > > And so whenthere is a Requires: emacs-common >= %{emacsversion} you > get an error like this: > > error: line 21: Dependency tokens must begin with alpha-numeric, '_' > or '/': Requires: emacs-common >= v=$(rpm -q --qf=%{VERSION} emacs) ; > case $v in 2*) echo $v ;; *) echo 0 ;; esac Oops, that's right. Forgot that those macros need to be referred to like %(%{emacsversion}), not plain %{emacsversion}. Fixed. From ville.skytta at iki.fi Wed May 30 06:47:35 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Wed, 30 May 2007 09:47:35 +0300 Subject: [Fedora-packaging] Packaging guidelines for Emacsen add-on packages In-Reply-To: <1180483130.6254.463.camel@localhost.localdomain> References: <645d17210705070855j1c76a34eoc4f9f65cae2766ec@mail.gmail.com> <645d17210705291626u23fd71aaoe3f9652f33e0f4c@mail.gmail.com> <1180483130.6254.463.camel@localhost.localdomain> Message-ID: <200705300947.35999.ville.skytta@iki.fi> On Wednesday 30 May 2007, Tom "spot" Callaway wrote: > On Wed, 2007-05-30 at 00:26 +0100, Jonathan Underwood wrote: > > On 27/05/07, Ville Skytt? wrote: > > > Regarding the current Emacsen add-on draft, > > > > > > * Added some more info about requiring a version of (X)Emacs newer than > > > or equal to the one used to compile the *.elcs, and how to find that > > > version out dynamically during package build. > > > > Actually, I was just testing this, and it doesn't work. > > > > You added these macros: > > %define emacsversion v=$(rpm -q --qf=%%{VERSION} emacs) ; case $v in > > 2*) echo $v ;; *) echo 0 ;; esac > > > > %define xemacsversion v=$(rpm -q --qf=%%{VERSION} xemacs) ; case $v in > > 2*) echo $v ;; *) echo 0 ;; esac > > Good lord. No. Thou shalt not query rpm inside rpm. Disagreed, when done carefully. > Ask emacs/xemacs what version it is. $ emacs --version GNU Emacs 22.0.95.1 Copyright (C) 2007 Free Software Foundation, Inc. GNU Emacs comes with ABSOLUTELY NO WARRANTY. You may redistribute copies of Emacs under the terms of the GNU General Public License. For more information about these matters, see the file named COPYING. $ xemacs --version XEmacs 21.5 (beta28) "fuki" [Lucid] (x86_64-redhat-linux, Mule) of Sat May 26 2007 on viper.bobcat.mine.nu Very much fun parsing those and creating a string that matches what the corresponding emacs/xemacs package's version is, when we can just simply ask rpm. From ville.skytta at iki.fi Wed May 30 06:49:49 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Wed, 30 May 2007 09:49:49 +0300 Subject: [Fedora-packaging] Packaging guidelines for Emacsen add-on packages In-Reply-To: <645d17210705291640m6e4f24d4ic911bc20f1f0140b@mail.gmail.com> References: <645d17210705070855j1c76a34eoc4f9f65cae2766ec@mail.gmail.com> <645d17210705291626u23fd71aaoe3f9652f33e0f4c@mail.gmail.com> <645d17210705291640m6e4f24d4ic911bc20f1f0140b@mail.gmail.com> Message-ID: <200705300949.49378.ville.skytta@iki.fi> On Wednesday 30 May 2007, Jonathan Underwood wrote: > On 30/05/07, Jonathan Underwood wrote: > > Also, this wouldn't work as intended on a system where more than one > arch of the emacs package is installed - eg. on my system i seem to > have emacs.x86_64 and emacs.i386 installed, and so > > rpm -q --qf=%{VERSION} emacs > > gives 22.0.9922.0.99. > > Granted, that wouldn't happen in a mock chroot buildroot, but still, I > think we should do a bit better than that :) Can't see how though :( Perhaps something like this (untested): rpm -qf --qf="%{VERSION}\n" /usr/bin/emacs | head -n 1 I'm sure there's a limit somewhere how far we're willing to take these tweaks though. From pertusus at free.fr Wed May 30 07:09:38 2007 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 30 May 2007 09:09:38 +0200 Subject: [Fedora-packaging] Re: paragraph on shipping static numerical libs In-Reply-To: <1180404861.2477.3.camel@rivendell> References: <1180247606.4735.1697.camel@mccallum.corsepiu.local> <20070527081536.GA2841@free.fr> <1180278622.3408.4.camel@localhost.localdomain> <645d17210705270827p65699c32ic9cbb8efdf81d124@mail.gmail.com> <20070527200136.GO11952@neu.nirvana> <20070528044104.GB8995@nostromo.devel.redhat.com> <20070528093438.GA19989@neu.nirvana> <20070528212248.GB17342@nostromo.devel.redhat.com> <20070528213249.GD5211@neu.nirvana> <1180404861.2477.3.camel@rivendell> Message-ID: <20070530070938.GB2905@free.fr> On Mon, May 28, 2007 at 10:14:21PM -0400, seth vidal wrote: > > I call crap on that. I was a single systems person for a bunch of > systems for a long time. You keep your sanity by enforcing policy and > you can do that by using the tools available to you to simplify the > tasks. You don't need homogeneous hw, you need LARGELY homogeneous hw. > So you limit the processor archs and you try to focus things down as > much as possible. It isn't necessarily enough. Do you consider a mix of centos4 and fedora to be homogeneous? This is what I use and, mainly due to gfortran/g77 differences, I have to statically build on fedora to run on centos4. -- Pat From rc040203 at freenet.de Wed May 30 07:19:30 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 30 May 2007 09:19:30 +0200 Subject: [Fedora-packaging] Re: paragraph on shipping static numerical libs In-Reply-To: <20070530070938.GB2905@free.fr> References: <1180247606.4735.1697.camel@mccallum.corsepiu.local> <20070527081536.GA2841@free.fr> <1180278622.3408.4.camel@localhost.localdomain> <645d17210705270827p65699c32ic9cbb8efdf81d124@mail.gmail.com> <20070527200136.GO11952@neu.nirvana> <20070528044104.GB8995@nostromo.devel.redhat.com> <20070528093438.GA19989@neu.nirvana> <20070528212248.GB17342@nostromo.devel.redhat.com> <20070528213249.GD5211@neu.nirvana> <1180404861.2477.3.camel@rivendell> <20070530070938.GB2905@free.fr> Message-ID: <1180509570.12595.90.camel@mccallum.corsepiu.local> On Wed, 2007-05-30 at 09:09 +0200, Patrice Dumas wrote: > On Mon, May 28, 2007 at 10:14:21PM -0400, seth vidal wrote: > > > > I call crap on that. I was a single systems person for a bunch of > > systems for a long time. You keep your sanity by enforcing policy and > > you can do that by using the tools available to you to simplify the > > tasks. You don't need homogeneous hw, you need LARGELY homogeneous hw. > > So you limit the processor archs and you try to focus things down as > > much as possible. > > It isn't necessarily enough. Do you consider a mix of centos4 and fedora > to be homogeneous? No ... > This is what I use and, mainly due to gfortran/g77 > differences, I have to statically build on fedora to run on centos4. ... and this is the proof. Ralf From nicolas.mailhot at laposte.net Wed May 30 08:03:55 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 30 May 2007 10:03:55 +0200 (CEST) Subject: [Fedora-packaging] Re: paragraph on shipping static numerical libs In-Reply-To: <20070530070938.GB2905@free.fr> References: <1180247606.4735.1697.camel@mccallum.corsepiu.local> <20070527081536.GA2841@free.fr> <1180278622.3408.4.camel@localhost.localdomain> <645d17210705270827p65699c32ic9cbb8efdf81d124@mail.gmail.com> <20070527200136.GO11952@neu.nirvana> <20070528044104.GB8995@nostromo.devel.redhat.com> <20070528093438.GA19989@neu.nirvana> <20070528212248.GB17342@nostromo.devel.redhat.com> <20070528213249.GD5211@neu.nirvana> <1180404861.2477.3.camel@rivendell> <20070530070938.GB2905@free.fr> Message-ID: <31540.192.54.193.51.1180512235.squirrel@rousalka.dyndns.org> Le Mer 30 mai 2007 09:09, Patrice Dumas a ?crit : > On Mon, May 28, 2007 at 10:14:21PM -0400, seth vidal wrote: >> >> I call crap on that. I was a single systems person for a bunch of >> systems for a long time. You keep your sanity by enforcing policy >> and >> you can do that by using the tools available to you to simplify the >> tasks. You don't need homogeneous hw, you need LARGELY homogeneous >> hw. >> So you limit the processor archs and you try to focus things down as >> much as possible. > > It isn't necessarily enough. Do you consider a mix of centos4 and > fedora to be homogeneous? Once you have a largely homegeneous hw parc you can deploy homogenous sw platform. That's the main point of having homegeneous hw. If one could sanely deploy the same sw platform on heterogeneous hw having homogenous hw would not matter as much. -- Nicolas Mailhot From jonathan.underwood at gmail.com Wed May 30 09:33:17 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Wed, 30 May 2007 10:33:17 +0100 Subject: [Fedora-packaging] Re: paragraph on shipping static numerical libs In-Reply-To: <20070530070938.GB2905@free.fr> References: <1180247606.4735.1697.camel@mccallum.corsepiu.local> <1180278622.3408.4.camel@localhost.localdomain> <645d17210705270827p65699c32ic9cbb8efdf81d124@mail.gmail.com> <20070527200136.GO11952@neu.nirvana> <20070528044104.GB8995@nostromo.devel.redhat.com> <20070528093438.GA19989@neu.nirvana> <20070528212248.GB17342@nostromo.devel.redhat.com> <20070528213249.GD5211@neu.nirvana> <1180404861.2477.3.camel@rivendell> <20070530070938.GB2905@free.fr> Message-ID: <645d17210705300233w6b649c5fv1f4f66bb4e511f3b@mail.gmail.com> On 30/05/07, Patrice Dumas wrote: > On Mon, May 28, 2007 at 10:14:21PM -0400, seth vidal wrote: > > > > I call crap on that. I was a single systems person for a bunch of > > systems for a long time. You keep your sanity by enforcing policy and > > you can do that by using the tools available to you to simplify the > > tasks. You don't need homogeneous hw, you need LARGELY homogeneous hw. > > So you limit the processor archs and you try to focus things down as > > much as possible. > > It isn't necessarily enough. Do you consider a mix of centos4 and fedora > to be homogeneous? This is what I use and, mainly due to gfortran/g77 > differences, I have to statically build on fedora to run on centos4. Sounds like an argument for packaging a later, parallel installable gcc for EPEL to me. From tcallawa at redhat.com Wed May 30 13:09:35 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 30 May 2007 08:09:35 -0500 Subject: [Fedora-packaging] Packaging guidelines for Emacsen add-on packages In-Reply-To: <200705300947.35999.ville.skytta@iki.fi> References: <645d17210705070855j1c76a34eoc4f9f65cae2766ec@mail.gmail.com> <645d17210705291626u23fd71aaoe3f9652f33e0f4c@mail.gmail.com> <1180483130.6254.463.camel@localhost.localdomain> <200705300947.35999.ville.skytta@iki.fi> Message-ID: <1180530575.6254.477.camel@localhost.localdomain> On Wed, 2007-05-30 at 09:47 +0300, Ville Skytt? wrote: > On Wednesday 30 May 2007, Tom "spot" Callaway wrote: > > On Wed, 2007-05-30 at 00:26 +0100, Jonathan Underwood wrote: > > > On 27/05/07, Ville Skytt? wrote: > > > > Regarding the current Emacsen add-on draft, > > > > > > > > * Added some more info about requiring a version of (X)Emacs newer than > > > > or equal to the one used to compile the *.elcs, and how to find that > > > > version out dynamically during package build. > > > > > > Actually, I was just testing this, and it doesn't work. > > > > > > You added these macros: > > > %define emacsversion v=$(rpm -q --qf=%%{VERSION} emacs) ; case $v in > > > 2*) echo $v ;; *) echo 0 ;; esac > > > > > > %define xemacsversion v=$(rpm -q --qf=%%{VERSION} xemacs) ; case $v in > > > 2*) echo $v ;; *) echo 0 ;; esac > > > > Good lord. No. Thou shalt not query rpm inside rpm. > > Disagreed, when done carefully. There is no careful way to do it. It is not safe, it is not predictable, it is not reproducable. emacs --version | head -n1 | sed -e 's/[^0-9.]//g' xemacs -V -no-site-file | cut -d " " -f 2 Not that hard. ~spot From rjones at redhat.com Wed May 30 14:14:54 2007 From: rjones at redhat.com (Richard W.M. Jones) Date: Wed, 30 May 2007 15:14:54 +0100 Subject: OCaml and static linking (was old thread: Re: [Fedora-packaging] Issues with Ocaml and Static Linking) In-Reply-To: References: <464F2791.1060309@redhat.com> <1179806148.5161.72.camel@localhost.localdomain> <46584157.2010100@redhat.com> <1180196144.22279.92.camel@localhost.localdomain> <465ABCBD.3060701@redhat.com> Message-ID: <465D86DE.8080505@redhat.com> Toshio Kuratomi wrote: > Thanks, those scripts look good. So what's the next step? I've added (or in two cases, changed) 14 OCaml packages which are waiting for another person to review them. You can get the full list of Bugzillas through this link: http://tinyurl.com/2rl4w6 I understand that everyone's really busy getting F7 out of the door, and also that OCaml doesn't interest many people. But anyway to kick things off, here are some of the things which I think could be problems: (1) Because of the strict dependencies, users could only upgrade ocaml + all OCaml libraries they are using in one go. (2) Also as a consequence of (1), if a major release of OCaml comes out, all OCaml libraries have to be upgraded at the same time. If, for example, we move to 3.10, then all libraries upstream must support 3.10. --> Possible solution to (1) & (2): Put the version number in the library path, as Debian does. This may allow multiple versions to coexist. --> Upstream support (2) is not much of a problem in reality. (3) OCaml contains a native code compiler, but that compiler hasn't been ported to all architectures that Fedora supports. It has a bytecode compiler which works everywhere (but is interpreted and hence slow). I haven't been very careful about detecting if native code is supported on the current architecture. --> ExcludeArch and/or lots of nasty %ifarch sections in %files. --> I don't have a non-native arch to test on. (4) rpmlint gives a few familiar warnings: devel-file-in-non-devel-package (about *.cmi files) --> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=241471 only-non-binary-in-usr-lib --> A consequence of the above. unstripped-binary-or-object --> You can't strip OCaml bytecode binaries because the bytecode gets stripped too. Arguably that's an upstream bug. no-binary --> Packages which contain no binaries should be in noarch - fair enough, but I don't know how to do this in the spec file and keep the subpackages arch-specific. configure-without-libdir-spec --> The ./configure scripts are often written in OCaml and don't use the standard autoconf options. (5) How does the Fedora build system work? To build a library you need to have the OCaml compiler and all dependent libraries installed (enforced through BuildRequires) and you'll get out an RPM which only installs with the precise compiler and library which were installed when it was compiled. So the only sequence that works is: # remove all ocaml RPMs $ rpmbuild -ba ocaml.spec # install ocaml RPM $ rpmbuild -ba ocaml-lib1.spec # install ocaml lib1 RPM $ rpmbuild -ba ocaml-lib2.spec # install ocaml lib2 RPM etc. 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 ville.skytta at iki.fi Wed May 30 17:20:55 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Wed, 30 May 2007 20:20:55 +0300 Subject: [Fedora-packaging] Packaging guidelines for Emacsen add-on packages In-Reply-To: <1180530575.6254.477.camel@localhost.localdomain> References: <645d17210705070855j1c76a34eoc4f9f65cae2766ec@mail.gmail.com> <200705300947.35999.ville.skytta@iki.fi> <1180530575.6254.477.camel@localhost.localdomain> Message-ID: <200705302020.56270.ville.skytta@iki.fi> On Wednesday 30 May 2007, Tom "spot" Callaway wrote: > On Wed, 2007-05-30 at 09:47 +0300, Ville Skytt? wrote: > > On Wednesday 30 May 2007, Tom "spot" Callaway wrote: > > > > Good lord. No. Thou shalt not query rpm inside rpm. > > > > Disagreed, when done carefully. > > There is no careful way to do it. It is not safe, it is not predictable, > it is not reproducable. My experience says otherwise, so would you care to elaborate and back each of those claims up with some concrete examples, in particular explaining in which way querying rpm is less $something than querying emacs or xemacs in that case? > emacs --version | head -n1 | sed -e 's/[^0-9.]//g' > xemacs -V -no-site-file | cut -d " " -f 2 > > Not that hard. And both of those have a fundamental issue that they're disconnect with what we need - the rpm *package* version; unless of course emacs/xemacs add a versioned Provides or something like the httpd-mmn mechanism in the httpd package that aligns better with what can be retrieved from querying them or something non-rpm. They also lack the possibility of querying Epochs (not needed currently in the *emacs case, just mentioning because you generalized all rpm querying as bad), and the output of those commands need to be watched and verified between upstream revisions (which sooner or later results in a mess of tweaks or inability to support all versions which would be useful), and user init files possibly suppressed more than in the above, etc. BTW, the xemacs version above produces wrong results; we want eg. 21.5.27, not 21.5. From rdieter at math.unl.edu Wed May 30 17:25:41 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 30 May 2007 12:25:41 -0500 Subject: [Fedora-packaging] Packaging guidelines for Emacsen add-on packages In-Reply-To: <200705302020.56270.ville.skytta@iki.fi> References: <645d17210705070855j1c76a34eoc4f9f65cae2766ec@mail.gmail.com> <200705300947.35999.ville.skytta@iki.fi> <1180530575.6254.477.camel@localhost.localdomain> <200705302020.56270.ville.skytta@iki.fi> Message-ID: <465DB395.1040303@math.unl.edu> Ville Skytt? wrote: > On Wednesday 30 May 2007, Tom "spot" Callaway wrote: >> On Wed, 2007-05-30 at 09:47 +0300, Ville Skytt? wrote: >>> On Wednesday 30 May 2007, Tom "spot" Callaway wrote: >>>> Good lord. No. Thou shalt not query rpm inside rpm. >>> Disagreed, when done carefully. >> There is no careful way to do it. It is not safe, it is not predictable, >> it is not reproducable. > > My experience says otherwise, so would you care to elaborate and back each of > those claims up with some concrete examples Been there, done that. Echo'ing what spot said, don't. One concrete example: chroot'd buildroots (like mock). The rpm version used to create the buildroot (oftentimes) != rpm version used inside the root for the query, leads to wierd behavior, failures. -- Rex From tcallawa at redhat.com Wed May 30 18:31:16 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 30 May 2007 13:31:16 -0500 Subject: [Fedora-packaging] Packaging guidelines for Emacsen add-on packages In-Reply-To: <200705302020.56270.ville.skytta@iki.fi> References: <645d17210705070855j1c76a34eoc4f9f65cae2766ec@mail.gmail.com> <200705300947.35999.ville.skytta@iki.fi> <1180530575.6254.477.camel@localhost.localdomain> <200705302020.56270.ville.skytta@iki.fi> Message-ID: <1180549876.6254.497.camel@localhost.localdomain> On Wed, 2007-05-30 at 20:20 +0300, Ville Skytt? wrote: > And both of those have a fundamental issue that they're disconnect > with what > we need - the rpm *package* version; unless of course emacs/xemacs add > a versioned Provides or something like the httpd-mmn mechanism in the > httpd package that aligns better with what can be retrieved from > querying them or something non-rpm. Do you really need that fine grained of a version? Is emacs/xemacs that picky, that the API/ABI breaks on releases? That you have to match to the exact package? ~spot From ville.skytta at iki.fi Wed May 30 19:24:29 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Wed, 30 May 2007 22:24:29 +0300 Subject: [Fedora-packaging] Packaging guidelines for Emacsen add-on packages In-Reply-To: <1180549876.6254.497.camel@localhost.localdomain> References: <645d17210705070855j1c76a34eoc4f9f65cae2766ec@mail.gmail.com> <200705302020.56270.ville.skytta@iki.fi> <1180549876.6254.497.camel@localhost.localdomain> Message-ID: <200705302224.30466.ville.skytta@iki.fi> On Wednesday 30 May 2007, Tom "spot" Callaway wrote: > On Wed, 2007-05-30 at 20:20 +0300, Ville Skytt? wrote: > > And both of those have a fundamental issue that they're disconnect > > with what > > we need - the rpm *package* version; unless of course emacs/xemacs add > > a versioned Provides or something like the httpd-mmn mechanism in the > > httpd package that aligns better with what can be retrieved from > > querying them or something non-rpm. > > Do you really need that fine grained of a version? Is emacs/xemacs that > picky, that the API/ABI breaks on releases? That you have to match to > the exact package? I can't speak for GNU Emacs, however I have some years of past experience as the upstream XEmacs packages release manager, and I guess things aren't that different with GNU Emacs. (Note: in this context, "package" has nothing to do with rpm - think more like a CPAN module distribution tarball.) The issue is not API/ABI breakage within XEmacs per se, but that a lot of elisp packages (especially ones that aren't part of upstream XEmacs packages collection and are thus likely candidates for being rpm-packaged separately) aim for backwards source level compatibility by checking whether some features exist in the XEmacs in use when the package is being run or byte-compiled. If yes, they use what's available. If no, they provide their own versions of missing functions, macros etc. This propagates into *.elc, and quite a few functions do get added between upstream releases, especially in the current beta branch of XEmacs that is being shipped in Fedora. So let's say I byte-compile a package into *.elc with XEmacs 21.5.28. Elisp package quux checks if the foo-bar function is available in the XEmacs being used to byte-compile it. Yes, it is, so the internal backwards compat version of foo-bar included in quux does not end up in the *.elc. Now, let's assume foo-bar was added in XEmacs 21.5.28 and didn't exist in 21.5.27 and we're trying to run the *.elc with 21.5.27 -> boom, foo-bar is not available. Note: this wouldn't happen if only *.el were shipped - *.elc are the potential and likely problem. Requiring >= version of the XEmacs used to byte-compile the *.elc is not the only solution (nor enough for all corner cases), but I can't think of a better generic way out that would be appropriate for the vast majority of cases. From ville.skytta at iki.fi Wed May 30 19:47:21 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Wed, 30 May 2007 22:47:21 +0300 Subject: [Fedora-packaging] Packaging guidelines for Emacsen =?utf-8?q?add-on=09packages?= In-Reply-To: <465DB395.1040303@math.unl.edu> References: <645d17210705070855j1c76a34eoc4f9f65cae2766ec@mail.gmail.com> <200705302020.56270.ville.skytta@iki.fi> <465DB395.1040303@math.unl.edu> Message-ID: <200705302247.21872.ville.skytta@iki.fi> On Wednesday 30 May 2007, Rex Dieter wrote: > One concrete example: chroot'd buildroots (like mock). > The rpm version used to create the buildroot (oftentimes) != rpm version > used inside the root for the query, leads to wierd behavior, failures. If I understand correctly, this is an orthogonal issue which isn't limited to querying rpm. For example, different *emacs versions inside and outside the buildroot is just as likely as different rpm versions. What makes querying them for versions instead of rpm safer, more predictable, and more reproducible? From jkeating at redhat.com Wed May 30 19:54:28 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 30 May 2007 15:54:28 -0400 Subject: [Fedora-packaging] Packaging guidelines for Emacsen =?utf-8?q?add-on=09packages?= In-Reply-To: <200705302247.21872.ville.skytta@iki.fi> References: <645d17210705070855j1c76a34eoc4f9f65cae2766ec@mail.gmail.com> <465DB395.1040303@math.unl.edu> <200705302247.21872.ville.skytta@iki.fi> Message-ID: <200705301554.28461.jkeating@redhat.com> On Wednesday 30 May 2007 15:47:21 Ville Skytt? wrote: > If I understand correctly, this is an orthogonal issue which isn't limited > to querying rpm. ?For example, different *emacs versions inside and outside > the buildroot is just as likely as different rpm versions. ?What makes > querying them for versions instead of rpm safer, more predictable, and more > reproducible? Because you're querying the emacs in the chroot not outside the chroot. In the case of rpm, the rpm _outside_ the chroot was used to populate the chroot, and the rpm database version that winds up in said chroot does not match the version of rpm that gets installed inside the chroot. emacs won't have this problem. -- Jesse Keating Release Engineer: Fedora -------------- 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 Wed May 30 20:27:40 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Wed, 30 May 2007 23:27:40 +0300 Subject: [Fedora-packaging] Packaging guidelines for Emacsen =?utf-8?q?add-on=09packages?= In-Reply-To: <200705301554.28461.jkeating@redhat.com> References: <645d17210705070855j1c76a34eoc4f9f65cae2766ec@mail.gmail.com> <200705302247.21872.ville.skytta@iki.fi> <200705301554.28461.jkeating@redhat.com> Message-ID: <200705302327.40805.ville.skytta@iki.fi> On Wednesday 30 May 2007, Jesse Keating wrote: > On Wednesday 30 May 2007 15:47:21 Ville Skytt? wrote: > > If I understand correctly, this is an orthogonal issue which isn't > > limited to querying rpm. ?For example, different *emacs versions inside > > and outside the buildroot is just as likely as different rpm versions. > > ?What makes querying them for versions instead of rpm safer, more > > predictable, and more reproducible? > > Because you're querying the emacs in the chroot not outside the chroot. In > the case of rpm, the rpm _outside_ the chroot was used to populate the > chroot, and the rpm database version that winds up in said chroot does not > match the version of rpm that gets installed inside the chroot. mock runs rpmbuild inside the chroot. Why doesn't it break? --nodeps? From jkeating at redhat.com Wed May 30 20:42:34 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 30 May 2007 16:42:34 -0400 Subject: [Fedora-packaging] Packaging guidelines for Emacsen =?utf-8?q?add-on=09packages?= In-Reply-To: <200705302327.40805.ville.skytta@iki.fi> References: <645d17210705070855j1c76a34eoc4f9f65cae2766ec@mail.gmail.com> <200705301554.28461.jkeating@redhat.com> <200705302327.40805.ville.skytta@iki.fi> Message-ID: <200705301642.34625.jkeating@redhat.com> On Wednesday 30 May 2007 16:27:40 Ville Skytt? wrote: > mock runs rpmbuild inside the chroot. ?Why doesn't it break? ?--nodeps? Probably. All the deps are resolved before the build begins. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From skvidal at linux.duke.edu Wed May 30 21:25:29 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Wed, 30 May 2007 17:25:29 -0400 Subject: [Fedora-packaging] Packaging guidelines for Emacsen add-on packages In-Reply-To: <200705302327.40805.ville.skytta@iki.fi> References: <645d17210705070855j1c76a34eoc4f9f65cae2766ec@mail.gmail.com> <200705302247.21872.ville.skytta@iki.fi> <200705301554.28461.jkeating@redhat.com> <200705302327.40805.ville.skytta@iki.fi> Message-ID: <1180560329.14616.0.camel@rivendell> On Wed, 2007-05-30 at 23:27 +0300, Ville Skytt? wrote: > On Wednesday 30 May 2007, Jesse Keating wrote: > > On Wednesday 30 May 2007 15:47:21 Ville Skytt? wrote: > > > If I understand correctly, this is an orthogonal issue which isn't > > > limited to querying rpm. For example, different *emacs versions inside > > > and outside the buildroot is just as likely as different rpm versions. > > > What makes querying them for versions instead of rpm safer, more > > > predictable, and more reproducible? > > > > Because you're querying the emacs in the chroot not outside the chroot. In > > the case of rpm, the rpm _outside_ the chroot was used to populate the > > chroot, and the rpm database version that winds up in said chroot does not > > match the version of rpm that gets installed inside the chroot. > > mock runs rpmbuild inside the chroot. Why doesn't it break? --nodeps? all the operations performed on the rpmdb in the chroot are done from outside the chroot, not inside. -sv From Axel.Thimm at ATrpms.net Wed May 30 22:02:34 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 31 May 2007 00:02:34 +0200 Subject: [Fedora-packaging] Re: paragraph on shipping static numerical libs In-Reply-To: <31540.192.54.193.51.1180512235.squirrel@rousalka.dyndns.org> References: <1180278622.3408.4.camel@localhost.localdomain> <645d17210705270827p65699c32ic9cbb8efdf81d124@mail.gmail.com> <20070527200136.GO11952@neu.nirvana> <20070528044104.GB8995@nostromo.devel.redhat.com> <20070528093438.GA19989@neu.nirvana> <20070528212248.GB17342@nostromo.devel.redhat.com> <20070528213249.GD5211@neu.nirvana> <1180404861.2477.3.camel@rivendell> <20070530070938.GB2905@free.fr> <31540.192.54.193.51.1180512235.squirrel@rousalka.dyndns.org> Message-ID: <20070530220234.GH4054@neu.nirvana> On Wed, May 30, 2007 at 10:03:55AM +0200, Nicolas Mailhot wrote: > > Le Mer 30 mai 2007 09:09, Patrice Dumas a ?crit : > > On Mon, May 28, 2007 at 10:14:21PM -0400, seth vidal wrote: > >> > >> I call crap on that. I was a single systems person for a bunch of > >> systems for a long time. You keep your sanity by enforcing policy > >> and > >> you can do that by using the tools available to you to simplify the > >> tasks. You don't need homogeneous hw, you need LARGELY homogeneous > >> hw. > >> So you limit the processor archs and you try to focus things down as > >> much as possible. > > > > It isn't necessarily enough. Do you consider a mix of centos4 and > > fedora to be homogeneous? > > Once you have a largely homegeneous hw parc you can deploy homogenous > sw platform. But the systems may serve different purposes like number crunchers (stable and secure, long-lived and low maintenance components aka RHEL/CentOS/SL) vs desktops (bigger choice, fresher content aka Fedora). Is strongly assume this is Patrice's need for separation. > That's the main point of having homegeneous hw. If one > could sanely deploy the same sw platform on heterogeneous hw having > homogenous hw would not matter as much. -- 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 Thu May 31 01:40:44 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 30 May 2007 18:40:44 -0700 Subject: OCaml and static linking (was old thread: Re: [Fedora-packaging] Issues with Ocaml and Static Linking) In-Reply-To: <465D86DE.8080505@redhat.com> References: <464F2791.1060309@redhat.com> <1179806148.5161.72.camel@localhost.localdomain> <46584157.2010100@redhat.com> <1180196144.22279.92.camel@localhost.localdomain> <465ABCBD.3060701@redhat.com> <465D86DE.8080505@redhat.com> Message-ID: <1180575644.20096.105.camel@localhost.localdomain> On Wed, 2007-05-30 at 15:14 +0100, Richard W.M. Jones wrote: > Toshio Kuratomi wrote: > > Thanks, those scripts look good. > > So what's the next step? I've added (or in two cases, changed) 14 OCaml > packages which are waiting for another person to review them. You can > get the full list of Bugzillas through this link: > > http://tinyurl.com/2rl4w6 > If you, G?rard, Hans, and the other people working on OCaml think the guidelines are ready we can discuss and vote to include them at next week's packaging meeting. The committee is meeting at Tuesday at 17:00 UTC for about an hour in #fedora-meeting on freenode IRC. If any of you can make it to the meeting that would be great as it helps to have someone familiar with the language there to field any questions that may come up. > I understand that everyone's really busy getting F7 out of the door, and > also that OCaml doesn't interest many people. But anyway to kick things > off, here are some of the things which I think could be problems: > > (1) Because of the strict dependencies, users could only upgrade ocaml + > all OCaml libraries they are using in one go. > > (2) Also as a consequence of (1), if a major release of OCaml comes out, > all OCaml libraries have to be upgraded at the same time. If, for > example, we move to 3.10, then all libraries upstream must support 3.10. > > --> Possible solution to (1) & (2): Put the version number in > the library path, as Debian does. This may allow multiple versions > to coexist. > > --> Upstream support (2) is not much of a problem in reality. > Other packages like this (python, perl, ruby) do have versioned subdirectories so that might be the best way to go. Do upstream build scripts generally make this easy to do? > (3) OCaml contains a native code compiler, but that compiler hasn't been > ported to all architectures that Fedora supports. It has a bytecode > compiler which works everywhere (but is interpreted and hence slow). I > haven't been very careful about detecting if native code is supported on > the current architecture. > > --> ExcludeArch and/or lots of nasty %ifarch sections in %files. > > --> I don't have a non-native arch to test on. > What's missing? ppc64? Is there a possibility of support being added upstream? I can't think of any other packages/languages that have this problem offhand. We may need to do something nasty with subpackages and %ifarch but I'd rather avoid that if possible. I don't know how possible that is, though. > (4) rpmlint gives a few familiar warnings: > > devel-file-in-non-devel-package (about *.cmi files) > > --> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=241471 > Looks like this one is being worked on. > only-non-binary-in-usr-lib > > --> A consequence of the above. > > unstripped-binary-or-object > > --> You can't strip OCaml bytecode binaries because the bytecode > gets stripped too. Arguably that's an upstream bug. > > no-binary > > --> Packages which contain no binaries should be in noarch - > fair enough, but I don't know how to do this in the spec file > and keep the subpackages arch-specific. > Yeah -- if one package/subpackage is arch specific then all of the pieces built from it have to be. > configure-without-libdir-spec > > --> The ./configure scripts are often written in OCaml and don't > use the standard autoconf options. > Okay. So this looks like rpmlint sees ./configure as an autoconf configure script when it really is not. > (5) How does the Fedora build system work? To build a library you need > to have the OCaml compiler and all dependent libraries installed > (enforced through BuildRequires) and you'll get out an RPM which only > installs with the precise compiler and library which were installed when > it was compiled. So the only sequence that works is: > # remove all ocaml RPMs > $ rpmbuild -ba ocaml.spec > # install ocaml RPM > $ rpmbuild -ba ocaml-lib1.spec > # install ocaml lib1 RPM > $ rpmbuild -ba ocaml-lib2.spec > # install ocaml lib2 RPM > etc. > Every build is a fresh mock buildroot. It includes the packages in the minimal install plus BuildRequires and their dependencies. The packages are drawn from the current download repository plus the packages that have been built recently but not yet made it to the repository. With the new koji builders (for F7) you have to tell it to do a chainbuild to guarantee that the recently built package is included in the new build. Until a better UI is worked out, here's a post on how to do that: http://www.redhat.com/archives/fedora-devel-list/2007-May/msg01850.html I think that will take care of getting new versions of OCaml through the build system. -Toshio -------------- 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 nicolas.mailhot at laposte.net Thu May 31 07:51:31 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 31 May 2007 09:51:31 +0200 (CEST) Subject: [Fedora-packaging] Re: paragraph on shipping static numerical libs In-Reply-To: <20070530220234.GH4054@neu.nirvana> References: <1180278622.3408.4.camel@localhost.localdomain> <645d17210705270827p65699c32ic9cbb8efdf81d124@mail.gmail.com> <20070527200136.GO11952@neu.nirvana> <20070528044104.GB8995@nostromo.devel.redhat.com> <20070528093438.GA19989@neu.nirvana> <20070528212248.GB17342@nostromo.devel.redhat.com> <20070528213249.GD5211@neu.nirvana> <1180404861.2477.3.camel@rivendell> <20070530070938.GB2905@free.fr> <31540.192.54.193.51.1180512235.squirrel@rousalka.dyndns.org> <20070530220234.GH4054@neu.nirvana> Message-ID: <11001.192.54.193.51.1180597891.squirrel@rousalka.dyndns.org> Le Jeu 31 mai 2007 00:02, Axel Thimm a ?crit : > On Wed, May 30, 2007 at 10:03:55AM +0200, Nicolas Mailhot wrote: >> >> Le Mer 30 mai 2007 09:09, Patrice Dumas a ?crit : >> > On Mon, May 28, 2007 at 10:14:21PM -0400, seth vidal wrote: >> >> >> >> I call crap on that. I was a single systems person for a bunch of >> >> systems for a long time. You keep your sanity by enforcing policy >> >> and >> >> you can do that by using the tools available to you to simplify >> the >> >> tasks. You don't need homogeneous hw, you need LARGELY >> homogeneous >> >> hw. >> >> So you limit the processor archs and you try to focus things down >> as >> >> much as possible. >> > >> > It isn't necessarily enough. Do you consider a mix of centos4 and >> > fedora to be homogeneous? >> >> Once you have a largely homegeneous hw parc you can deploy >> homogenous >> sw platform. > > But the systems may serve different purposes like number crunchers > (stable and secure, long-lived and low maintenance components aka > RHEL/CentOS/SL) vs desktops (bigger choice, fresher content aka > Fedora). Is strongly assume this is Patrice's need for separation. Well either they have different purposes and you don't have the problem of deploying the same fortran modules on them, or they don't and the whole argument fails. -- Nicolas Mailhot From Axel.Thimm at ATrpms.net Thu May 31 08:10:43 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 31 May 2007 10:10:43 +0200 Subject: [Fedora-packaging] Re: paragraph on shipping static numerical libs In-Reply-To: <11001.192.54.193.51.1180597891.squirrel@rousalka.dyndns.org> References: <20070527200136.GO11952@neu.nirvana> <20070528044104.GB8995@nostromo.devel.redhat.com> <20070528093438.GA19989@neu.nirvana> <20070528212248.GB17342@nostromo.devel.redhat.com> <20070528213249.GD5211@neu.nirvana> <1180404861.2477.3.camel@rivendell> <20070530070938.GB2905@free.fr> <31540.192.54.193.51.1180512235.squirrel@rousalka.dyndns.org> <20070530220234.GH4054@neu.nirvana> <11001.192.54.193.51.1180597891.squirrel@rousalka.dyndns.org> Message-ID: <20070531081043.GA2007@neu.nirvana> On Thu, May 31, 2007 at 09:51:31AM +0200, Nicolas Mailhot wrote: > > Le Jeu 31 mai 2007 00:02, Axel Thimm a ?crit : > > On Wed, May 30, 2007 at 10:03:55AM +0200, Nicolas Mailhot wrote: > >> > >> Le Mer 30 mai 2007 09:09, Patrice Dumas a ?crit : > >> > On Mon, May 28, 2007 at 10:14:21PM -0400, seth vidal wrote: > >> >> > >> >> I call crap on that. I was a single systems person for a bunch of > >> >> systems for a long time. You keep your sanity by enforcing policy > >> >> and > >> >> you can do that by using the tools available to you to simplify > >> the > >> >> tasks. You don't need homogeneous hw, you need LARGELY > >> homogeneous > >> >> hw. > >> >> So you limit the processor archs and you try to focus things down > >> as > >> >> much as possible. > >> > > >> > It isn't necessarily enough. Do you consider a mix of centos4 and > >> > fedora to be homogeneous? > >> > >> Once you have a largely homegeneous hw parc you can deploy > >> homogenous > >> sw platform. > > > > But the systems may serve different purposes like number crunchers > > (stable and secure, long-lived and low maintenance components aka > > RHEL/CentOS/SL) vs desktops (bigger choice, fresher content aka > > Fedora). Is strongly assume this is Patrice's need for separation. > > Well either they have different purposes and you don't have the > problem of deploying the same fortran modules on them, Why not? The scientists develop on their desktop PC, test whether the code actually gives numbers that make sense for their model, and once the bits and bolts are in places run the large jobs on the real rack-mounted X-less number crunchers. That's the most typical work model of theoretical physicists. Sometimes the number crunches is cross-institution or even cross-country. European science networks sharing common access to large mpp resources are more and more common these days. > or they don't and the whole argument fails. It's not a theoretical argument, it's real life. I've been on both sides of the equation, being a physicist doing numerics and as an admin catering for others doing so (with even an overlap of duties). So please believe me that I'm talking about real situations, not any academic example. The question is just whether we care or not. From a market share we should, because if these institutions move further away from Fedora/RHEL, students that go through this process end up being Linux consultants and want to deploy what they are familiar with. The predominance of Debian in German universities leads to more German Linux consultants doing Debian/Ubuntu later on. -- 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 Thu May 31 08:32:34 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 31 May 2007 10:32:34 +0200 (CEST) Subject: [Fedora-packaging] Re: paragraph on shipping static numerical libs In-Reply-To: <20070531081043.GA2007@neu.nirvana> References: <20070527200136.GO11952@neu.nirvana> <20070528044104.GB8995@nostromo.devel.redhat.com> <20070528093438.GA19989@neu.nirvana> <20070528212248.GB17342@nostromo.devel.redhat.com> <20070528213249.GD5211@neu.nirvana> <1180404861.2477.3.camel@rivendell> <20070530070938.GB2905@free.fr> <31540.192.54.193.51.1180512235.squirrel@rousalka.dyndns.org> <20070530220234.GH4054@neu.nirvana> <11001.192.54.193.51.1180597891.squirrel@rousalka.dyndns.org> <20070531081043.GA2007@neu.nirvana> Message-ID: <27060.192.54.193.51.1180600354.squirrel@rousalka.dyndns.org> Le Jeu 31 mai 2007 10:10, Axel Thimm a ?crit : > On Thu, May 31, 2007 at 09:51:31AM +0200, Nicolas Mailhot wrote: >> Well either they have different purposes and you don't have the >> problem of deploying the same fortran modules on them, > > Why not? The scientists develop on their desktop PC, test whether the > code actually gives numbers that make sense for their model, and once > the bits and bolts are in places run the large jobs on the real > rack-mounted X-less number crunchers. At that point they can and should take the time to rebuild it for the large number cruncher. Just dump the developper/scientist local builds on the expensive production systems is a very bad idea (and that's not a problem limited to numeric stuff) -- Nicolas Mailhot From Axel.Thimm at ATrpms.net Thu May 31 08:57:42 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 31 May 2007 10:57:42 +0200 Subject: [Fedora-packaging] Re: paragraph on shipping static numerical libs In-Reply-To: <27060.192.54.193.51.1180600354.squirrel@rousalka.dyndns.org> References: <20070528093438.GA19989@neu.nirvana> <20070528212248.GB17342@nostromo.devel.redhat.com> <20070528213249.GD5211@neu.nirvana> <1180404861.2477.3.camel@rivendell> <20070530070938.GB2905@free.fr> <31540.192.54.193.51.1180512235.squirrel@rousalka.dyndns.org> <20070530220234.GH4054@neu.nirvana> <11001.192.54.193.51.1180597891.squirrel@rousalka.dyndns.org> <20070531081043.GA2007@neu.nirvana> <27060.192.54.193.51.1180600354.squirrel@rousalka.dyndns.org> Message-ID: <20070531085742.GD2007@neu.nirvana> On Thu, May 31, 2007 at 10:32:34AM +0200, Nicolas Mailhot wrote: > > Le Jeu 31 mai 2007 10:10, Axel Thimm a ?crit : > > On Thu, May 31, 2007 at 09:51:31AM +0200, Nicolas Mailhot wrote: > > >> Well either they have different purposes and you don't have the > >> problem of deploying the same fortran modules on them, > > > > Why not? The scientists develop on their desktop PC, test whether the > > code actually gives numbers that make sense for their model, and once > > the bits and bolts are in places run the large jobs on the real > > rack-mounted X-less number crunchers. > > At that point they can and should take the time to rebuild it for the > large number cruncher. Just dump the developper/scientist local builds > on the expensive production systems is a very bad idea (and that's not > a problem limited to numeric stuff) Well, climb up the thread and see that the centos running cluster at Patrice's site is not carrying the proper Fortran. Even further up the thread you'll find references that you don't even have all libraries on the target system, or not the ones you really need. FWIW even w/o neededing any other special fortran features building with FC6's fortran and running on RHEL4 or FC4 was improving some code performance by a factor of the range of 30%. So instead of publishing your paper in 3 months you can save a month of numerics, produce more papers, get a higher budget (where budgets depend on the amount and quality of publications, e.g. almost everywhere), use the budget to hire more physicists. That's an unbeatable argument. (well, it's simpliyfied as the above could imply that all numerical physicists do is to fire up number crunchers, although some bad mouthed people will say they always knew 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 pertusus at free.fr Thu May 31 09:57:18 2007 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 31 May 2007 11:57:18 +0200 Subject: [Fedora-packaging] Re: paragraph on shipping static numerical libs In-Reply-To: <645d17210705300233w6b649c5fv1f4f66bb4e511f3b@mail.gmail.com> References: <1180278622.3408.4.camel@localhost.localdomain> <645d17210705270827p65699c32ic9cbb8efdf81d124@mail.gmail.com> <20070527200136.GO11952@neu.nirvana> <20070528044104.GB8995@nostromo.devel.redhat.com> <20070528093438.GA19989@neu.nirvana> <20070528212248.GB17342@nostromo.devel.redhat.com> <20070528213249.GD5211@neu.nirvana> <1180404861.2477.3.camel@rivendell> <20070530070938.GB2905@free.fr> <645d17210705300233w6b649c5fv1f4f66bb4e511f3b@mail.gmail.com> Message-ID: <20070531095718.GA2844@free.fr> On Wed, May 30, 2007 at 10:33:17AM +0100, Jonathan Underwood wrote: > > Sounds like an argument for packaging a later, parallel installable > gcc for EPEL to me. It is more or less done (although I am not sure that the version isn't lagging in which case it may not be so usefull) but then you also need to have the libraries compiled for both compilers, it becomes unmanageable and I don't think people at redhat would accept doing that. I can repackage it in private repos (I already do that sort of things) but all in all it is much more complicated. (As a side note I have submitted a review for the cernlib compiled with g77 now that the main cern lib is compiled with gfortran, but I dont' think I will maintain a gfortran compiled cernlib on centos4). -- Pat From jonathan.underwood at gmail.com Thu May 31 10:56:58 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Thu, 31 May 2007 11:56:58 +0100 Subject: [Fedora-packaging] Packaging guidelines for Emacsen add-on packages In-Reply-To: <1180560329.14616.0.camel@rivendell> References: <645d17210705070855j1c76a34eoc4f9f65cae2766ec@mail.gmail.com> <200705302247.21872.ville.skytta@iki.fi> <200705301554.28461.jkeating@redhat.com> <200705302327.40805.ville.skytta@iki.fi> <1180560329.14616.0.camel@rivendell> Message-ID: <645d17210705310356s46fb7066ye3f6dd720aef8368@mail.gmail.com> OK, interesting as all that was, I don't think we reached a conclusion: a) can we query rpm inside a spec or not? b) If no to (a) can we go about ascertaining the build time emacs version reliably some other way. c) If no to (b), is it acceptable to have packagers putting the Requires: emacs >= N.n.nn in themselves? [In the past, I've always done c]. J. From tcallawa at redhat.com Thu May 31 13:59:10 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Thu, 31 May 2007 08:59:10 -0500 Subject: [Fedora-packaging] Packaging guidelines for Emacsen add-on packages In-Reply-To: <645d17210705310356s46fb7066ye3f6dd720aef8368@mail.gmail.com> References: <645d17210705070855j1c76a34eoc4f9f65cae2766ec@mail.gmail.com> <200705302247.21872.ville.skytta@iki.fi> <200705301554.28461.jkeating@redhat.com> <200705302327.40805.ville.skytta@iki.fi> <1180560329.14616.0.camel@rivendell> <645d17210705310356s46fb7066ye3f6dd720aef8368@mail.gmail.com> Message-ID: <1180619950.6254.552.camel@localhost.localdomain> On Thu, 2007-05-31 at 11:56 +0100, Jonathan Underwood wrote: > OK, interesting as all that was, I don't think we reached a conclusion: > > a) can we query rpm inside a spec or not? I'm standing on a firm NO here. ~spot From jonathan.underwood at gmail.com Thu May 31 14:21:26 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Thu, 31 May 2007 15:21:26 +0100 Subject: [Fedora-packaging] Packaging guidelines for Emacsen add-on packages In-Reply-To: <1180619950.6254.552.camel@localhost.localdomain> References: <645d17210705070855j1c76a34eoc4f9f65cae2766ec@mail.gmail.com> <200705302247.21872.ville.skytta@iki.fi> <200705301554.28461.jkeating@redhat.com> <200705302327.40805.ville.skytta@iki.fi> <1180560329.14616.0.camel@rivendell> <645d17210705310356s46fb7066ye3f6dd720aef8368@mail.gmail.com> <1180619950.6254.552.camel@localhost.localdomain> Message-ID: <645d17210705310721rea57446o344360b376e73837@mail.gmail.com> On 31/05/07, Tom spot Callaway wrote: > On Thu, 2007-05-31 at 11:56 +0100, Jonathan Underwood wrote: > > OK, interesting as all that was, I don't think we reached a conclusion: > > > > a) can we query rpm inside a spec or not? > > I'm standing on a firm NO here. OK. So how do we feel about emacs --no-site-file --version | head -n1 | awk '{print $3}' and xemacs --no-site-file --version | head -n1 | awk '{print $2}' (not guaranteed that it will work in future emacs versions which may change their formatting of --version info.) > > ~spot > > -- > Fedora-packaging mailing list > Fedora-packaging at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-packaging > From ville.skytta at iki.fi Thu May 31 18:17:48 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Thu, 31 May 2007 21:17:48 +0300 Subject: [Fedora-packaging] Packaging guidelines for Emacsen add-on packages In-Reply-To: <645d17210705310721rea57446o344360b376e73837@mail.gmail.com> References: <645d17210705070855j1c76a34eoc4f9f65cae2766ec@mail.gmail.com> <1180619950.6254.552.camel@localhost.localdomain> <645d17210705310721rea57446o344360b376e73837@mail.gmail.com> Message-ID: <200705312117.48993.ville.skytta@iki.fi> On Thursday 31 May 2007, Jonathan Underwood wrote: > So how do we feel about > > emacs --no-site-file --version | head -n1 | awk '{print $3}' > > and > > xemacs --no-site-file --version | head -n1 | awk '{print $2}' > > (not guaranteed that it will work in future emacs versions which may > change their formatting of --version info.) Bad, as explained before. Instead, how about adding some pkgconfig files which are generated during build and thus we have complete control over their contents? Eg. the attached one to xemacs-devel: $ pkg-config xemacs --modversion 21.5.28 $ pkg-config xemacs --variable=sitestartdir /usr/share/xemacs/site-packages/lisp/site-start.d $ pkg-config xemacs --variable=sitepkglispdir /usr/share/xemacs/site-packages/lisp $ pkg-config xemacs --variable=sitemoduledir /usr/lib64/xemacs/site-modules $ pkg-config xemacs --cflags -I/usr/lib64/xemacs-21.5-b28/x86_64-redhat-linux/include -------------- next part -------------- prefix=/usr includedir=/usr/lib64/xemacs-21.5-b28/x86_64-redhat-linux/include sitestartdir=/usr/share/xemacs/site-packages/lisp/site-start.d sitepkglispdir=/usr/share/xemacs/site-packages/lisp sitemoduledir=/usr/lib64/xemacs/site-modules Name: xemacs Description: Different version of Emacs Version: 21.5.28 Cflags: -I${includedir} From jonathan.underwood at gmail.com Thu May 31 18:20:57 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Thu, 31 May 2007 19:20:57 +0100 Subject: [Fedora-packaging] Packaging guidelines for Emacsen add-on packages In-Reply-To: <200705312117.48993.ville.skytta@iki.fi> References: <645d17210705070855j1c76a34eoc4f9f65cae2766ec@mail.gmail.com> <1180619950.6254.552.camel@localhost.localdomain> <645d17210705310721rea57446o344360b376e73837@mail.gmail.com> <200705312117.48993.ville.skytta@iki.fi> Message-ID: <645d17210705311120v599f0170h669ed8e830ff3d31@mail.gmail.com> On 31/05/07, Ville Skytt? wrote: > Bad, as explained before. Instead, how about adding some pkgconfig files > which are generated during build and thus we have complete control over their > contents? Eg. the attached one to xemacs-devel: > > $ pkg-config xemacs --modversion > 21.5.28 > $ pkg-config xemacs --variable=sitestartdir > /usr/share/xemacs/site-packages/lisp/site-start.d > $ pkg-config xemacs --variable=sitepkglispdir > /usr/share/xemacs/site-packages/lisp > $ pkg-config xemacs --variable=sitemoduledir > /usr/lib64/xemacs/site-modules > $ pkg-config xemacs --cflags > -I/usr/lib64/xemacs-21.5-b28/x86_64-redhat-linux/include Perfect! That also allows package build time discovery of the site-lisp directories etc. I wonder if Chip would be willing to add such a thing to GNU Emacs package. J. From rdieter at math.unl.edu Thu May 31 18:21:24 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 31 May 2007 13:21:24 -0500 Subject: [Fedora-packaging] Packaging guidelines for Emacsen add-on packages In-Reply-To: <200705312117.48993.ville.skytta@iki.fi> References: <645d17210705070855j1c76a34eoc4f9f65cae2766ec@mail.gmail.com> <1180619950.6254.552.camel@localhost.localdomain> <645d17210705310721rea57446o344360b376e73837@mail.gmail.com> <200705312117.48993.ville.skytta@iki.fi> Message-ID: <465F1224.5090203@math.unl.edu> Ville Skytt? wrote: > Instead, how about adding some pkgconfig files > which are generated during build and thus we have complete control over their > contents? Much better (or some other equivalent mechanism not involving rpm queries). -- Rex