Re: Best Practices for zSeries linux ISVs?
Can you provide a citation, or is this simply your experience? I'll take source over binaries every time. -- David Andrews Simply my experience working in a large mainframe outsourcing shop who looks after a whole lot of large customers :-) The typical mainframe support organisation tends towards a policy that minimises home grown custom code, simply for cost reduction in maintenance. The general attitude is that such support should be done by software vendors as that's what they get paid for. If such organisations were to compile their own code then they would have to maintain it with security/integrity fixes, etc by applying their own patches. This is typically more effort and therefore higher cost than getting for instance, a distributor, to do it. Cheers - Tex Brendan Kelly Senior z/OS Linux IT Specialist Open Source Community of Practice Co-Leader IBM Global Technology Services 348 Edward St, Brisbane, QLD 4000 +61-7-3213-2133 +61-419-394-143 [EMAIL PROTECTED] -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Best Practices for zSeries linux ISVs?
Jeez, I thought my wife's PC (a Celeron at 1.4GHz) was slow when I got rid of it a year ago. I didn't know that people still used 350MHz PCs g. K -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of David Andrews Sent: Thursday, December 07, 2006 4:33 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: Best Practices for zSeries linux ISVs? On Fri, 2006-12-08 at 06:20 +0900, John Summerfield wrote: I didn't know Gentoo was available for z:-) Guess it was at one time (see http://dev.gentoo.org/~vapier/s390/ ) but I don't think it was anything but experimental, and it hasn't been looked at in awhile. Think Matt Zimmerman was involved, if I'm not mistaken. It takes 45 hours to emerge OpenOffice on my little 350MHz intelbox at home. Can't imagine what it would take in a 7060 LPAR in competition with z/OS. Some things are best left installed from binaries! -- David Andrews A. Duda and Sons, Inc. [EMAIL PROTECTED] -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Best Practices for zSeries linux ISVs?
-Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Evans, Kevin R Sent: Friday, December 08, 2006 6:04 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: Best Practices for zSeries linux ISVs? Jeez, I thought my wife's PC (a Celeron at 1.4GHz) was slow when I got rid of it a year ago. I didn't know that people still used 350MHz PCs g. K Gee, you just heaped scorn upon most of my company's desktops! -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology This message (including any attachments) contains confidential information intended for a specific individual and purpose, and its content is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this transmission, or taking any action based on it, is strictly prohibited. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Best Practices for zSeries linux ISVs?
John, I'm sorry for you g. Although, even Lockheed has some pretty underpowered desktop PCs here...just not as bad as 350MHz. K -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of McKown, John Sent: Friday, December 08, 2006 8:35 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: Best Practices for zSeries linux ISVs? -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Evans, Kevin R Sent: Friday, December 08, 2006 6:04 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: Best Practices for zSeries linux ISVs? Jeez, I thought my wife's PC (a Celeron at 1.4GHz) was slow when I got rid of it a year ago. I didn't know that people still used 350MHz PCs g. K Gee, you just heaped scorn upon most of my company's desktops! -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology This message (including any attachments) contains confidential information intended for a specific individual and purpose, and its content is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this transmission, or taking any action based on it, is strictly prohibited. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Best Practices for zSeries linux ISVs?
Heh. Sent this to the wrong list on my first try. Take two: This may not be the correct place to ask this question, but Google isn't helping a ton and I can't bear the thought of posting into most other Linux fora, so I'm going to run this past you folks first. To cut to the chase, as part of an effort to figur out why we had trouble with a prof-of-concept application that ate every CPU cycle our IFL could give it, I have written a couple of small Ruby scripts as a stress-testing mechanism. The basic idea is: * Create a small test database on our problematic MySQL image. (Database = 100,000 rows, each of which has a numeric key and one field consisting of 30 random alphabetic characters.) this part is fine. * On another guest, fork a bunch of processes, each of which will read a random row from the database, generate another random 30-character string, and update the record. This procedure goes fine as long as I fork a few thousand processes. Once I reach 8500 or so, however, I start receiving this: Resource temporarily unavailable - fork(2) (Errno::EAGAIN) According to everything I can find, EAGAIN on fork(2) indicates that the system can not allocate sufficient memory to create the child process, but if I issue free -m while my stress test script is running I show plenty of available memory. Am I hitting a per-user process limit or some such? Any ideas? TIA, Jon -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Best Practices for zSeries linux ISVs?
A ulimit -a command will tell you what your limits are. On my Slackware systems, the default is 512 processes. It may be different on your distribution. You may also want to look at what is shown for open files, max memory size, and virtual memory, etc. Mark Post -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] Behalf Of Jon Brock Sent: Friday, December 08, 2006 2:23 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: Best Practices for zSeries linux ISVs? Heh. Sent this to the wrong list on my first try. Take two: This may not be the correct place to ask this question, but Google isn't helping a ton and I can't bear the thought of posting into most other Linux fora, so I'm going to run this past you folks first. To cut to the chase, as part of an effort to figur out why we had trouble with a prof-of-concept application that ate every CPU cycle our IFL could give it, I have written a couple of small Ruby scripts as a stress-testing mechanism. The basic idea is: * Create a small test database on our problematic MySQL image. (Database = 100,000 rows, each of which has a numeric key and one field consisting of 30 random alphabetic characters.) this part is fine. * On another guest, fork a bunch of processes, each of which will read a random row from the database, generate another random 30-character string, and update the record. This procedure goes fine as long as I fork a few thousand processes. Once I reach 8500 or so, however, I start receiving this: Resource temporarily unavailable - fork(2) (Errno::EAGAIN) According to everything I can find, EAGAIN on fork(2) indicates that the system can not allocate sufficient memory to create the child process, but if I issue free -m while my stress test script is running I show plenty of available memory. Am I hitting a per-user process limit or some such? Any ideas? TIA, Jon -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Best Practices for zSeries linux ISVs?
On Thu, 2006-12-07 at 08:39 +1000, Brendan Kelly wrote: Most large shops will shy away from compiling from source Can you provide a citation, or is this simply your experience? I'll take source over binaries every time. -- David Andrews A. Duda and Sons, Inc. [EMAIL PROTECTED] -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Best Practices for zSeries linux ISVs?
The issue is one of support. If you have a support contract with IBM, Novell, or Redhat, it is for the code that they deliver, basically the binary RPMs, and it is on a very tight turnaround timeframe. Compiling the code outside of their model is not supported, in other words, if it breaks, you are left with the support of the open-source community for that code and in their timeframes. In large shops that level of support is not enough, which is why they buy support contracts from IBM, Novell, or Redhat. Paul Giordano Technical Sales Specialist - Linux zSeries e-business Solutions Technical Sales, Americas (312) 529-1347 (630) 207-9435 (cell) email: [EMAIL PROTECTED] Check http://www.ibm.com/linux for the latest in Linux news and information David Andrews [EMAIL PROTECTED] Sent by: Linux on 390 Port LINUX-390@VM.MARIST.EDU 12/07/2006 08:49 AM Please respond to Linux on 390 Port LINUX-390@VM.MARIST.EDU To LINUX-390@VM.MARIST.EDU cc Subject Re: Best Practices for zSeries linux ISVs? On Thu, 2006-12-07 at 08:39 +1000, Brendan Kelly wrote: Most large shops will shy away from compiling from source Can you provide a citation, or is this simply your experience? I'll take source over binaries every time. -- David Andrews A. Duda and Sons, Inc. [EMAIL PROTECTED] -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Best Practices for zSeries linux ISVs?
On Thu, 2006-12-07 at 09:11 -0500, Paul Giordano wrote: The issue is one of support. If you have a support contract with IBM, Novell, or Redhat, it is for the code that they deliver, basically the binary RPMs, and it is on a very tight turnaround timeframe. Compiling the code outside of their model is not supported, Perhaps not. Whether something is supported, and the degree to which the vendor will assist in diagnosing a problem varies. I haven't met many vendors that take a hard line; when you're down, you're down, and reputable support organizations will do what they can and let the accountants sort it out later. That much said, you should be able to justify a mod, and better have the wherewithal to fix whatever you break, or be able to reproduce the problem on an unsullied system. If you don't have the chops, you shouldn't play. Support issues aside, the most important use for source is read-only: as a documentation supplement. You want to know what happens when you do *this*, you can always consult the source. This is especially important in a world where messages and codes books are unknown. -- David Andrews A. Duda and Sons, Inc. [EMAIL PROTECTED] -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Best Practices for zSeries linux ISVs?
On Thu, 2006-12-07 at 09:11 -0500, Paul Giordano wrote: The issue is one of support. If you have a support contract with IBM, Novell, or Redhat, it is for the code that they deliver, basically the binary RPMs, and it is on a very tight turnaround timeframe. Compiling the code outside of their model is not supported, Perhaps not. Whether something is supported, and the degree to which the vendor will assist in diagnosing a problem varies. I haven't met many vendors that take a hard line; when you're down, you're down, and reputable support organizations will do what they can and let the accountants sort it out later. I understand, but that said, once you get into things like middleware stacks, vendors absolutely do take a very hard line. Vendors test their with exact distributions, things like WebSphere, DB2, etc, as do the Oracle folks, and many other ISVs. You start compiling your own source underneath their middleware code, and I can tell you from experience they will instantly tell you to put it back to the supported distribution binary RPMs they tested and approved their code under. It's too expensive for them to try to support moving targets. That much said, you should be able to justify a mod, and better have the wherewithal to fix whatever you break, or be able to reproduce the problem on an unsullied system. If you don't have the chops, you shouldn't play. Support issues aside, the most important use for source is read-only: as a documentation supplement. You want to know what happens when you do *this*, you can always consult the source. This is especially important in a world where messages and codes books are unknown. Agreed - on both points - and, if you want to use things that are newer, for example PHP5, or newer LDAP support, newer compiler levels, even newer kernels, by all means you should bring them in and use them, and, as I mentioned, you can get support from IBM's kernel group for the kernel levels, for example, or from Zend for PHP. Using them for production, well, as you say, if you don't have the chops... I also would believe that in a non-middleware stack standpoint you could get some support help from your vendor of contract - but I do not think it would be the my server's down kind you're alluding to - again, it's not in IBM, Novell, or Redhat's best interest to shoot at moving targets - if their entire user community was just compiling whatever they wanted to and when it broke calling up their contract support and saying we're down, fix it - well, contracts would be a lot more expensive than they are now. You can get contracts from other vendors, Zend, JBoss, Oracle, etc. But the IBM/Novell/Redhat contracts that I'm aware of are very specific - it's only the RPM code that's in the distribution, and that's it - I suppose you can negotiate something more, though I've never heard of anyone doing so - everything's negotiable, right? Regards, Paul Giordano IBM IT Specialist - Linux on System z -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Best Practices for zSeries linux ISVs?
The instance at hand is not a question of whether it is source only or binaries only. The OP was saying that they would prefer to ship source, as opposed to binaries _and_ source. In that situation, I'll take binaries and source, every time. Every IT shop I've run into in the last 10 years or so is too busy keeping their head above water to want their highly paid systems programmers and systems administrators building things from source when binaries are available from their suppliers. We even went through a huge effort to remove a lot of our usermods from MVS and JES2 a good number of years ago because we didn't want to be in the business of supporting home-written code that wasn't 100% absolutely necessary. (I was in charge of the JES2 project. It was successful, but painful.) In the last few years, it's gotten even tighter, all around the industry. Heck, our MVS folks don't even look at dumps any more. That's why we're paying IBM is the thinking, and I tend to agree with it. Mark Post -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] Behalf Of David Andrews Sent: Thursday, December 07, 2006 8:50 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: Best Practices for zSeries linux ISVs? On Thu, 2006-12-07 at 08:39 +1000, Brendan Kelly wrote: Most large shops will shy away from compiling from source Can you provide a citation, or is this simply your experience? I'll take source over binaries every time. -- David Andrews A. Duda and Sons, Inc. [EMAIL PROTECTED] -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Best Practices for zSeries linux ISVs?
OK, I'll be a citation :) We want them in RPM format - silent install. There's no way we want to be compiling everything everywhere. We are not even allowed to install compilers on prod servers. Marcy (like Mark said, trying to keep my head above water, and ...opinions are my own and not necessarily those of Wells Fargo Bank - but they should be :) This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Mark Post Sent: Thursday, December 07, 2006 9:34 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: [LINUX-390] Best Practices for zSeries linux ISVs? The instance at hand is not a question of whether it is source only or binaries only. The OP was saying that they would prefer to ship source, as opposed to binaries _and_ source. In that situation, I'll take binaries and source, every time. Every IT shop I've run into in the last 10 years or so is too busy keeping their head above water to want their highly paid systems programmers and systems administrators building things from source when binaries are available from their suppliers. We even went through a huge effort to remove a lot of our usermods from MVS and JES2 a good number of years ago because we didn't want to be in the business of supporting home-written code that wasn't 100% absolutely necessary. (I was in charge of the JES2 project. It was successful, but painful.) In the last few years, it's gotten even tighter, all around the industry. Heck, our MVS folks don't even look at dumps any more. That's why we're paying IBM is the thinking, and I tend to agree with it. Mark Post -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] Behalf Of David Andrews Sent: Thursday, December 07, 2006 8:50 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: Best Practices for zSeries linux ISVs? On Thu, 2006-12-07 at 08:39 +1000, Brendan Kelly wrote: Most large shops will shy away from compiling from source Can you provide a citation, or is this simply your experience? I'll take source over binaries every time. -- David Andrews A. Duda and Sons, Inc. [EMAIL PROTECTED] -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Best Practices for zSeries linux ISVs?
Brendan Kelly wrote: I suspect that's regional: in Europe I think SUSE has most, US (let's say North America) and Oz, it would be Red Hat. Oz is actually mostly SLES on z -in my experience. As Nino Culotta said, They're a weird mob. -- Cheers John -- spambait [EMAIL PROTECTED] [EMAIL PROTECTED] Please do not reply off-list -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Best Practices for zSeries linux ISVs?
David Andrews wrote: On Thu, 2006-12-07 at 08:39 +1000, Brendan Kelly wrote: Most large shops will shy away from compiling from source Can you provide a citation, or is this simply your experience? I'll take source over binaries every time. I didn't know Gentoo was available for z:-) -- Cheers John -- spambait [EMAIL PROTECTED] [EMAIL PROTECTED] Please do not reply off-list -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Best Practices for zSeries linux ISVs?
On Fri, 2006-12-08 at 06:20 +0900, John Summerfield wrote: I didn't know Gentoo was available for z:-) Guess it was at one time (see http://dev.gentoo.org/~vapier/s390/ ) but I don't think it was anything but experimental, and it hasn't been looked at in awhile. Think Matt Zimmerman was involved, if I'm not mistaken. It takes 45 hours to emerge OpenOffice on my little 350MHz intelbox at home. Can't imagine what it would take in a 7060 LPAR in competition with z/OS. Some things are best left installed from binaries! -- David Andrews A. Duda and Sons, Inc. [EMAIL PROTECTED] -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Best Practices for zSeries linux ISVs?
On Thu, Dec 07, 2006 at 04:32:44PM -0500, David Andrews wrote: On Fri, 2006-12-08 at 06:20 +0900, John Summerfield wrote: I didn't know Gentoo was available for z:-) Guess it was at one time (see http://dev.gentoo.org/~vapier/s390/ ) but I don't think it was anything but experimental, and it hasn't been looked at in awhile. However, it does work...I successfully got it together last week on Hercules. It takes 45 hours to emerge OpenOffice on my little 350MHz intelbox at home. Can't imagine what it would take in a 7060 LPAR in competition with z/OS. Some things are best left installed from binaries! Indeed. OTOH, some things are best custom installed...why, for example, does SLES 10 install audio software and the gpm console mouse driver on z/Series?! -- Jay Maynard, K5ZChttp://www.conmicro.cx http://jmaynard.livejournal.com http://www.tronguy.net http://www.hercules-390.org (Yes, that's me!) Buy Hercules stuff at http://www.cafepress.com/hercules-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Best Practices for zSeries linux ISVs?
David Andrews wrote: On Fri, 2006-12-08 at 06:20 +0900, John Summerfield wrote: I didn't know Gentoo was available for z:-) Guess it was at one time (see http://dev.gentoo.org/~vapier/s390/ ) but I don't think it was anything but experimental, and it hasn't been looked at in awhile. Think Matt Zimmerman was involved, if I'm not mistaken. Matt? I can see why it might have languished:-) He's a dd and Technical Director at Canonical/Ubuntu. Surely he'd not have enough time to push Gentoo as well. It takes 45 hours to emerge OpenOffice on my little 350MHz intelbox at home. Can't imagine what it would take in a 7060 LPAR in competition with z/OS. Some things are best left installed from binaries! My feeling when I tried it out on the wrong side of a 56k modem. That plus bug http://bugs.gentoo.org/show_bug.cgi?id=144527 -- Cheers John -- spambait [EMAIL PROTECTED] [EMAIL PROTECTED] Please do not reply off-list -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Best Practices for zSeries linux ISVs?
On Fri, 2006-12-08 at 06:42 +0900, John Summerfield wrote: David Andrews wrote: Think Matt Zimmerman was involved, if I'm not mistaken. Matt? I can see why it might have languished:-) He's a dd and Technical Director at Canonical/Ubuntu. Surely he'd not have enough time to push Gentoo as well. Probably not! Guess I confused Debian and Gentoo for a moment there. 40 lashes for me. -- David Andrews A. Duda and Sons, Inc. [EMAIL PROTECTED] -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Best Practices for zSeries linux ISVs?
Rick Troth wrote: I said: Build the package outside of RPM control. That is, DO NOT ship it as built from the SRPM. You can and should still ship an SRPM. Do an 'rpmbuild -bb' against a built and installed package. John then said: I _hate_ packages built this way. I fully expect that, should I rebuild, I can do so from the source rpm, and that the result will be equivalent to the binary rpm. Please understand, I did not say that Kirk's CUSTOMES could not rebuild, nor that they should not use SRPM to do so, nor that Kirk's team should not use the SRPM in various ways during development. I only said that the RPM(s) delivered should be built outside of the too-smart-for-itself logic of SRPM based builds. The source rpm is the source from which a user ought be able to build binaries the supplier supports in the same way the supplier supports the actual rpm it shipped. Where source is provided, as in this case, then it should include all the actual source and build procedures needed in order to produce the binaries. Given that, the customers can in principle fix problems themselves. An example where this was important: a bloke I was talking to a few years ago had a contractor provide some software. The contractor retained the source; the contractor died and either the user's requirements changed, or there was a problem. Either way, the bloke was stuffed. RPM as a whole gets wyyy to intimate with the loader. For payload delivery, RPM is fine. (And proper registration, and for audit, and a host of things I can hear Mark Post saying must have!.) It's the all to often flawed BUILD automation in the RPM suite that produces executables with distro-specific and release-specific bondage that _I_ hate. I don't like any Sun or IBM java rpm I've seen (IBM's are better) because they play tricks building them. Dunno what tricks they play, Is this an rpm, or is it not an rpm: downloads/jre-1_5_0_01-linux-i586-rpm.bin It's an rpm imbedded into a shell script - think shar - and it does all sorts of stupid things. An rpm I can examine with various incantations of the rpm command; I can view a list of its contents, I can see what the vendor thinks it does, I can view the changelog to see if it's got the recent WA TZ changes in it, and I really want I can convert it to a CPIO archive and unpack it without installing it. About the only thing I want to do that to is this stupid package; because it's unusual, I wonder about it. but don't write off the whole -bb lot based on that, John! As a vendor, Kirk surely does not want to have to produce a separate RPM for each distro/release combination. Kirk's choice of course, but he absolutely needs builds for RHEL 4, 5 and SLES 9, 10 for zSeries. The RHEL ones will do fine for CentOS (a major point of CentOS is binary-compatibiity with RHEL) Earlier releases could maybe be done when demanded. If the rpms are relocatable and the package is built to be configurable around the differences between SUSE, RH, Debian etc, then one rpm might well do for equivalent releases of SLES and RHEL. -- Cheers John -- spambait [EMAIL PROTECTED] [EMAIL PROTECTED] Tourist pics http://portgeographe.environmentaldisasters.cds.merseine.nu/ Please do not reply off-list -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Best Practices for zSeries linux ISVs?
snip It would be *ideal* for us to just ship source packages, but our intuition is that no matter how simple the build process, some customers will only want binaries (the opposite of my preference :-) You need to consider ease of ongoing support for the product. Most large shops will shy away from compiling from source due to the implication that they would then need to apply patches manually for ongoing maintenance. They will want a rpm (or some form of package) that can be easily and silently installed remotely from a central repository. Fixes can then be managed by supplying a new maintenance level of the rpm to the repos and let normal procedures pick it up and install it (with all the concomitant change control). Cheers - Tex Brendan Kelly Senior z/OS Linux IT Specialist Open Source Community of Practice Co-Leader IBM Global Technology Services (Embedded image moved to file: pic05643.gif)348 Edward St, Brisbane, QLD 4000 (Embedded image moved to file: pic16314.gif) +61-7-3213-2133 (Embedded image moved to file: pic09783.gif)+61-419-394-143 (Embedded image moved to file: pic03577.gif) [EMAIL PROTECTED] -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 pic05643.gif Description: GIF image pic16314.gif Description: GIF image pic09783.gif Description: GIF image pic03577.gif Description: GIF image
Re: Best Practices for zSeries linux ISVs?
I suspect that's regional: in Europe I think SUSE has most, US (let's say North America) and Oz, it would be Red Hat. Oz is actually mostly SLES on z -in my experience. Cheers - Tex (Embedded (Embedded image moved to file: image moved pic03944.jpg) to file: Brendan Kelly pic30066.jpg Senior z/OS Linux IT )Specialist Open Source Community of Practice Co-Leader IBM Global Technology Services (Embedded image moved to file: pic09928.gif)348 Edward St, Brisbane, QLD 4000 (Embedded image moved to file: pic15678.gif) +61-7-3213-2133 (Embedded image moved to file: pic10404.gif)+61-419-394-143 (Embedded image moved to file: pic03659.gif) [EMAIL PROTECTED] -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 attachment: pic30066.jpg pic09928.gif Description: GIF image pic15678.gif Description: GIF image pic10404.gif Description: GIF image pic03659.gif Description: GIF image attachment: pic03944.jpg
Re: Best Practices for zSeries linux ISVs?
I said: Build the package outside of RPM control. That is, DO NOT ship it as built from the SRPM. You can and should still ship an SRPM. Do an 'rpmbuild -bb' against a built and installed package. John then said: I _hate_ packages built this way. I fully expect that, should I rebuild, I can do so from the source rpm, and that the result will be equivalent to the binary rpm. Please understand, I did not say that Kirk's CUSTOMES could not rebuild, nor that they should not use SRPM to do so, nor that Kirk's team should not use the SRPM in various ways during development. I only said that the RPM(s) delivered should be built outside of the too-smart-for-itself logic of SRPM based builds. RPM as a whole gets wyyy to intimate with the loader. For payload delivery, RPM is fine. (And proper registration, and for audit, and a host of things I can hear Mark Post saying must have!.) It's the all to often flawed BUILD automation in the RPM suite that produces executables with distro-specific and release-specific bondage that _I_ hate. I don't like any Sun or IBM java rpm I've seen (IBM's are better) because they play tricks building them. Dunno what tricks they play, but don't write off the whole -bb lot based on that, John! As a vendor, Kirk surely does not want to have to produce a separate RPM for each distro/release combination. [rest deleted for brevity] -- R; -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Best Practices for zSeries linux ISVs?
Yu Safin wrote: My first reaction is that on the Mainframe, SLES is probably more predominant in terms of installed base. I can't tell if 31 or 64 bits. On the Intel servers, it is probably RedHat, but I can't tell if RHEL I suspect that's regional: in Europe I think SUSE has most, US (let's say North America) and Oz, it would be Red Hat. or Fedora. I suspect Fedora on the desktop but can't back it up. I regularly describe Fedora Core as a rolling beta (and yes, I do use it), and reckon that if anyone uses it for serious work they better know what they're letting themselves in for. It's fine for many uses, including tracking where Red Hat might go next, but you are almost certain to get broken systems from time to time. Debian has a pretty fair presence on servers (I have some, for example) (one of the things I like about Debian is you can run it on almost any hardware), and there's a fair body of folk running it on desktops too (I did that for a while). The Ubuntu family has much to recommend it; one can get a good working set of software (all supported) on a single CD, backed by the enormous volume of Debian's packages. I can't tell how many users it has or where it fits in the market, but it could be the leader. Then there's SimplyMepis 6.0 which has appeared on three different magzine DVDs chez Summerfield. SUSE has much to recommend it, as folk here will agree, but then my SYSE OpenOffice.org on my (just deleted) SUSE 10.1 system couldn't find my CUPS printers whereas on Kubuntu 6.10 and it FC6 can. I'd have thought that BigCorp would be using RHEL (or maybe a clone) SLED or other commercial offerings on their standard desktops. -- Cheers John -- spambait [EMAIL PROTECTED] [EMAIL PROTECTED] Tourist pics http://portgeographe.environmentaldisasters.cds.merseine.nu/ Please do not reply off-list -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Best Practices for zSeries linux ISVs?
I regularly describe Fedora Core as a rolling beta (and yes, I do use it), and reckon that if anyone uses it for serious work they better know what they're letting themselves in for. Fedora isn't a rolling beta by any means. It's a distribution proper and has betas and finals for each release. It does however track the current versions of software. That can be great on the desktop because you get the latest and greatest stuff and new is good, it's not neccessarily ideal on your critical business server. Not wearing my employers hat for a moment I'd strongly suggest looking at what others you know use, especially if you plan to ask them questions when setting up 8) -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Best Practices for zSeries linux ISVs?
Alan wrote: I regularly describe Fedora Core as a rolling beta (and yes, I do use it), and reckon that if anyone uses it for serious work they better know what they're letting themselves in for. Fedora isn't a rolling beta by any means. It's a distribution proper and has betas and finals for each release. It does however track the current I've been in fights saying Fedora has betas:-) It's fine for you, Alan, because you must hack on the latest kernels, and it's fine for me because I like to see which way the wind's blowing. Both you and I have the skills to fix the system when it breaks, and I've had Fedora systems that would not boot following a kernel upgrade. Should the teachers at the school decide to adopt Linux, Fedora would not be amongst my recommendations, because I don't want an angry hord of teachers bearing down on me when it breaks. versions of software. That can be great on the desktop because you get the latest and greatest stuff and new is good, it's not neccessarily ideal on your critical business server. It can be great on the desktop, yes, but not in the hands of my wife, of lawyers, teachers, bankers, financiers, realestate agents, travel agents or anyone else without decent computer skills. Not wearing my employers hat for a moment I'd strongly suggest looking at what others you know use, especially if you plan to ask them questions when setting up 8) OS X and Windows:-) -- Cheers John -- spambait [EMAIL PROTECTED] [EMAIL PROTECTED] Tourist pics http://portgeographe.environmentaldisasters.cds.merseine.nu/ Please do not reply off-list -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Best Practices for zSeries linux ISVs?
On 12/4/06, Alan Altmark [EMAIL PROTECTED] wrote: On Sunday, 12/03/2006 at 10:51 EST, Yu Safin [EMAIL PROTECTED] wrote: My first reaction is that on the Mainframe, SLES is probably more predominant in terms of installed base. I can't tell if 31 or 64 bits. On the Intel servers, it is probably RedHat, but I can't tell if RHEL or Fedora. I suspect Fedora on the desktop but can't back it up. It really doesn't matter whether SLES or RHEL is the predominant distro in the z space; both are heavily used. They are the ante. Support for other distros is a welcome plus. Alan Altmark z/VM Development IBM Endicott -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 Alan, you will be surprised how picky some technical guys get around here in userland, where I live. A simple statement from Oracle such as testing first in SLES or RHEL can change the distro we use. The Oracle DBA's argument goes along those lines, if Oracle ... But I am with you, it should not matter. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Best Practices for zSeries linux ISVs?
On Fri, 1 Dec 2006, Kirk Wolf wrote: We are preparing to release a new commercial application which will support zSeries linux distros, and are hoping to get some advice and/or suggestions for packaging the product for zSeries. Wow! Thanks for asking! Long response from me. Summary at end of this note. Other comments interleaved. 1) s390 (31 bit) architecture LSB 3.0 compatible RPM 2) s390x (64 bit) architecture LSB 3.0 compatible RPM 3) source rpm 4) source tarball This is an excellent list. There are some additional details not mentioned. See below. Several have responded about the need for an automatic installation. But that is the point behind RPM: automated installation including record of inventory. Dave Boyes mentioned 'autoconf' and the value of the source TAR file. There is some ramp-up on a learning curve there. In any case, be sure that your source tree builds with the standard recipe: # download or copy from your media # unpack the source TAR file, get into that directory ./configure make make install If you can accomplish that will full-blown autoconf, so much the better. 1) RHEL 3.x is not LSB 3.0 compatible, ... You can work around this. You simply have to discard assumptions based on what the distributors do and doc. While I am hugely thankful for SuSE and RedHat, you and your customers are best served by keeping to a constant that they do not define. While SuSE Linux is Linux, Linux is not SuSE. Similarly, while RedHat Linux is Linux, Linux is not RedHat. Biggest problem you'll have with lack of LSB compliance is the location of the start-up script(s) and what is required of them. 2) For non-LSB3.0 environments, we would have instructions on how to do a source RPM install or a source tarball make/make install. ... Customers will have many reasons that they might need source. Lack of LSB compliance is not necessarily one of them. See below. But in this case, build the package outside of RPM control, build it on a lowest common denominator, and then test that build on all target distributions. THEN fall back to the source build. You might need to avoid C++ for this to work. Without starting a flame war over languages, might need to avoid C++ for plenty other reasons. My concern here is the mess imposed by the run-time libraries for C++. If you go with C++, link statically. Even though the build is simple, will this be a issue with some z Linux customers? This will always be and issue with some Linux customers, z or not. Based on feedback, we can really decide to ship the package formats that users seem to want/need, but we would *really* like to keep the binary packages to a small number. We would like to be able to use a single zLinux image to build binary packages. This is the lowest common denominator I mentioned. But you'll have to do rigorous testing. (But you're doing that anyway, right??) In my time, I categorically refused to build multiple RPMs where they were not needed. Customers will appreciate it. It gets tricky when having to use other code that is multiply built, that is re-built on each release of every distro. Source RPM builds lead you into this. This is why I recommend that you build OUTSIDE of the control of RPM. It would be *ideal* for us to just ship source packages, but our intuition is that no matter how simple the build process, some customers will only want binaries (the opposite of my preference :-) I share your sentiment. *** SUMMARY *** Build the package outside of RPM control. That is, DO NOT ship it as built from the SRPM. You can and should still ship an SRPM. Do an 'rpmbuild -bb' against a built and installed package. Build on the lowest common denominator (oldest common distro). Also, RPM is just one packaging tool. See if you can support one or more of the others, at least in the lab, to the extent that you are okay when customers turn out to want to use it on a non-RPM Linux even if you don't document that support. If some source is C++, statically link the C++ libs. Support relocation! For the RPM packages, this is done by specifying a prefix path in the spec file. The customer can then override the prefix and get the whole thing installed in an alternate location. (It's a little tricky if you have to place content under /etc like an INIT script.) The recipe then looks like ./configure --prefix=/customer/specified/place make make install which is supported by most autoconf-based packages. If your package has server or daemon tasks, make your INIT script(s) multi-platform capable. This is really really easy: INIT scripts that are fully LSB compliant and yet also work on such platforms as HP-UX. Should be fine on the pre-LSB Linux systems too. (For that matter, should be okay on z/OS!) Where your INIT scripts run depends on the platforms you support. So if you don't yet run on HP-UX, then you won't yet care
Re: Best Practices for zSeries linux ISVs?
-snip- 1) RHEL 3.x is not LSB 3.0 compatible, whereas RHEL 4.2+ and SLE 9.3+ are. Would this affect a significant portion of the current zLinux installed population? As others have said, no. -snip- 2) For non-LSB3.0 environments, we would have instructions on how to do a source RPM install or a source tarball make/make install. Even though the build is simple, will this be a issue with some z Linux customers? It will be a problem for almost all of them. I.e., those that didn't recruit their midrange Linux folks to do the support on the mainframe. Based on feedback, we can really decide to ship the package formats that users seem to want/need, but we would *really* like to keep the binary packages to a small number. You should ship binary RPM packages for SLES and RHEL, .deb packages for Debian/390, and .tgz packages for Slack/390, should you choose to support them. Doing anything else is going to cause you enormous amounts of support headaches, and hence a lot of added costs and customer dissatisfaction. We would like to be able to use a single zLinux image to build binary packages. Not easy to do, even following Rick Troth's suggestions. You'd be much better off getting z/VM, if you don't already have it, and creating multiple guests. It would be *ideal* for us to just ship source packages, but our intuition is that no matter how simple the build process, some customers will only want binaries (the opposite of my preference :-) I would say that 99.999% of your potential customers will want only binary packages. They're not in the business of being developers, they're converted systems programmers or system administrators. If they're smart (and most of them are) they won't have any unnecessary packages installed on their systems, to keep patching to a minimum. That means no development tools unless it's a development system, etc. Most of the people that wind up supporting Linux/390 systems don't have the background and skills to be at all comfortable building packages from source. Even those that do, don't want to spend the time to have to do it. If it doesn't install and start running (with whatever required configuration is really necessary) they're going to hate it. Mark Post -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Best Practices for zSeries linux ISVs?
Kirk Wolf wrote: Kris Van Hees wrote: that install and run correctly on several LSB3.0 distros (including Debian/Ubuntu via alien). Speaking for myself, I will if I must run an rpm through alien for my use, but I'd be peeved if my software vendor did that. I would, if source is provided, expect 'apt-get source' to get it. Risks I might imagine with running a debianised rpm are similar to those with running a foreign rpm on any rpm-based distro, and if there are associated install/uninstall scripts I would fully imagine them untested on my platform, if they run at all. -- Cheers John -- spambait [EMAIL PROTECTED] [EMAIL PROTECTED] Tourist pics http://portgeographe.environmentaldisasters.cds.merseine.nu/ Please do not reply off-list -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Best Practices for zSeries linux ISVs?
Rick Troth wrote: Build the package outside of RPM control. That is, DO NOT ship it as built from the SRPM. You can and should still ship an SRPM. Do an 'rpmbuild -bb' against a built and installed package. I _hate_ packages built this way. I fully expect that, should I rebuild, I can do so from the source rpm, and that the result will be equivalent to the binary rpm. I don't like any Sun or IBM java rpm I've seen (IBM's are better) because they play tricks building them. I ran into trouble with the Fedora Directory Server project's rpms(!) because the source rpms do not build on _my_ system. Until they do, I won't touch them. You should not need to rebuild for any Enterprise Linux/Architecture release combination, except to fix your own problems, but I think you should do this. In doing so you will also avoid problems with C++ library incompatibilities. If the source rpm builds, and you don't support RHAS 2.1 but I want it on RHAS 2.1, I should be able to build it for myself, subject to having required versions of libraries. Or on Mandrake/Mandriva. Or on any of the other Linux distros mentioned on distrowatch.com (for that matter, I should have a fighting chance of building from source on *BSD* and if you follow the autoconf route it probably will build, even though you don't support it and you especially don't support the packaging). -- Cheers John -- spambait [EMAIL PROTECTED] [EMAIL PROTECTED] Tourist pics http://portgeographe.environmentaldisasters.cds.merseine.nu/ Please do not reply off-list -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Best Practices for zSeries linux ISVs?
I would like to thank everyone for your thoughtful responses to this post. Although the application will target any linux (or Windoze) system, we hope for strong z linux usage. The information you shared will definitely help us package for z distros. Kirk Wolf Dovetailed Technologies -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Best Practices for zSeries linux ISVs?
John, Ubuntu is what we run on our desktops, so I can appreciate your position. We had assumed that enlightened z Debian users would accept source tarballs for a commercial application, but we could be mistaken. I can assure you that we will make .deb binaries available for Debian on z if a customer wants it. Regards, Kirk Wolf Dovetailed Technologies John Summerfield wrote: Kirk Wolf wrote: that install and run correctly on several LSB3.0 distros (including Debian/Ubuntu via alien). Speaking for myself, I will if I must run an rpm through alien for my use, but I'd be peeved if my software vendor did that. I would, if source is provided, expect 'apt-get source' to get it. Risks I might imagine with running a debianised rpm are similar to those with running a foreign rpm on any rpm-based distro, and if there are associated install/uninstall scripts I would fully imagine them untested on my platform, if they run at all. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Best Practices for zSeries linux ISVs?
On 12/1/06, Kirk Wolf [EMAIL PROTECTED] wrote: We are preparing to release a new commercial application which will support zSeries linux distros, and are hoping to get some advice and/or suggestions for packaging the product for zSeries. Our current thinking is to make the following distribution formats available: 1) s390 (31 bit) architecture LSB 3.0 compatible RPM 2) s390x (64 bit) architecture LSB 3.0 compatible RPM 3) source rpm 4) source tarball These are our questions / issues: 1) RHEL 3.x is not LSB 3.0 compatible, whereas RHEL 4.2+ and SLE 9.3+ are. Would this affect a significant portion of the current zLinux installed population? Are there problems with LSB3.0 support on zSeries linux distros that we aren't aware of? 2) For non-LSB3.0 environments, we would have instructions on how to do a source RPM install or a source tarball make/make install. Even though the build is simple, will this be a issue with some z Linux customers? Based on feedback, we can really decide to ship the package formats that users seem to want/need, but we would *really* like to keep the binary packages to a small number. We would like to be able to use a single zLinux image to build binary packages. It would be *ideal* for us to just ship source packages, but our intuition is that no matter how simple the build process, some customers will only want binaries (the opposite of my preference :-) Your comments and suggestions would really be appreciated. Regards, Kirk Wolf Dovetailed Technologies, LLC -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 My first reaction is that on the Mainframe, SLES is probably more predominant in terms of installed base. I can't tell if 31 or 64 bits. On the Intel servers, it is probably RedHat, but I can't tell if RHEL or Fedora. I suspect Fedora on the desktop but can't back it up. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Best Practices for zSeries linux ISVs?
On Sunday, 12/03/2006 at 10:51 EST, Yu Safin [EMAIL PROTECTED] wrote: My first reaction is that on the Mainframe, SLES is probably more predominant in terms of installed base. I can't tell if 31 or 64 bits. On the Intel servers, it is probably RedHat, but I can't tell if RHEL or Fedora. I suspect Fedora on the desktop but can't back it up. It really doesn't matter whether SLES or RHEL is the predominant distro in the z space; both are heavily used. They are the ante. Support for other distros is a welcome plus. Alan Altmark z/VM Development IBM Endicott -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Best Practices for zSeries linux ISVs?
Kris Van Hees wrote:
Actually, more than small and subtle... Dependencies for the binary RPMs are
in part derived from the build environment, so creating a SuSE RPM on a RedHat
system, or the other way around, is never a good idea. It can be made to work
with the right amount of dark magic, but it isn't for the faint of heart, and
it is bound to get you into a lot of misery down the road.
Cheers,
Kris
Kris,
The application itself is quite portable and after some work complies
100% with LSB 3.0.
(http://www.freestandards.org/en/LSB)
Of course we would be testing on as many architectures and distros as
possible,
but we've had success in building LSB3.0 compatible RPMs (for arch=i486,
arch=x86_64, arch=ppc, and arch=ppc64)
that install and run correctly on several LSB3.0 distros (including
Debian/Ubuntu via alien).
We are hoping that LSB 3.0 compatible RPMs for arch=s390 and arch=s390x
will work as well.
If this is never a good idea, can you elaborate on issues that you see?
Following is a snippet from the RPM spec that is used for LSB packaging
that I believe is
designed to address the issues that you mention.The point of LSB is
to have - by architecture -
binary application compatibility across LSB compatible distros. As you
can see below,
a lsb compatible distro is required to have lsb support packages
that wash away distro-specific
dependencies.
Buildroot:/var/tmp/%{name}
Prefix:/opt/dovetail/xxx
AutoReqProv:no
# LSB dependency section
%ifarch i386 i486 i586 i686 athlon
PreReq:lsb-core-ia32 = 3.0
%endif
%ifarch ia64
PreReq:lsb-core-ia64 = 3.0
%endif
%ifarch ppc
PreReq:lsb-core-ppc32 = 3.0
%endif
%ifarch ppc64
PreReq:lsb-core-ppc64 = 3.0
%endif
%ifarch s390
PreReq:lsb-core-s390 = 3.0
%endif
%ifarch s390x
PreReq:lsb-core-s390x = 3.0
%endif
%ifarch x86_64
PreReq:lsb-core-amd64 = 3.0
%endif
--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
Best Practices for zSeries linux ISVs?
We are preparing to release a new commercial application which will support zSeries linux distros, and are hoping to get some advice and/or suggestions for packaging the product for zSeries. Our current thinking is to make the following distribution formats available: 1) s390 (31 bit) architecture LSB 3.0 compatible RPM 2) s390x (64 bit) architecture LSB 3.0 compatible RPM 3) source rpm 4) source tarball These are our questions / issues: 1) RHEL 3.x is not LSB 3.0 compatible, whereas RHEL 4.2+ and SLE 9.3+ are. Would this affect a significant portion of the current zLinux installed population? Are there problems with LSB3.0 support on zSeries linux distros that we aren't aware of? 2) For non-LSB3.0 environments, we would have instructions on how to do a source RPM install or a source tarball make/make install. Even though the build is simple, will this be a issue with some z Linux customers? Based on feedback, we can really decide to ship the package formats that users seem to want/need, but we would *really* like to keep the binary packages to a small number. We would like to be able to use a single zLinux image to build binary packages. It would be *ideal* for us to just ship source packages, but our intuition is that no matter how simple the build process, some customers will only want binaries (the opposite of my preference :-) Your comments and suggestions would really be appreciated. Regards, Kirk Wolf Dovetailed Technologies, LLC -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Best Practices for zSeries linux ISVs?
I work for a large-ish company with a relatively small, but growing, Linux (Lintel and Lin-z) farm. Considering our range of skills, we should have an rpm that will install in hands-off, quiet mode. If it is binary or source it doesn't matter, just so it doesn't require thought or knowledge on the part of the installer. tom - - - - - - - - - - - - Toto, I have a feeling we're not in the mainframe world any more. _/) Tom Shilson ~Unix Team / IT Server Services Aloha Tel: 651-733-7591 tshilson at mmm dot com Fax: 651-736-7689 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Best Practices for zSeries linux ISVs?
Our current thinking is to make the following distribution formats available: 1) s390 (31 bit) architecture LSB 3.0 compatible RPM 2) s390x (64 bit) architecture LSB 3.0 compatible RPM 3) source rpm 4) source tarball Good! Thanks for allowing the tarballs. You should also test on Debian, which has a fair following on Z. 1) RHEL 3.x is not LSB 3.0 compatible, whereas RHEL 4.2+ and SLE 9.3+ are. Would this affect a significant portion of the current zLinux installed population? Unlikely. RH has a much smaller customer footprint on Z than on other platforms. There weren't ever very many RHEL3 customers, and I'd hazard that most of them have a) moved to SuSE or b) moved to RHEL4 long ago. It's probably also fairly safe to prereq SLES9 or higher; there are a fair number of SLES8 systems still circulating, but it's not likely to get a lot of new traffic. Are there problems with LSB3.0 support on zSeries linux distros that we aren't aware of? Not if you prereq the above levels. 2) For non-LSB3.0 environments, we would have instructions on how to do a source RPM install or a source tarball make/make install. Even though the build is simple, will this be a issue with some z Linux customers? Of course it will -- but it would on any platform. No difference here. It is probably worth the effort to do a autoconf configuration script, though. Based on feedback, we can really decide to ship the package formats that users seem to want/need, but we would *really* like to keep the binary packages to a small number. We would like to be able to use a single zLinux image to build binary packages. While you *could* do that, I think you'll find that you'll need at least one RH and one SuSE guest, and you'll need to build the packages independently on both. There are still some small and subtle differences in the way RPMs are built on the different distributions, and you'll need the separate guests to test the installs anyway. It would be *ideal* for us to just ship source packages, but our intuition is that no matter how simple the build process, some customers will only want binaries (the opposite of my preference :-) Good thinking. You're probably correct; most folks here tend to the minimalist installs, which wouldn't have development tool chains. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Best Practices for zSeries linux ISVs?
On Fri, Dec 01, 2006 at 08:53:49PM -0500, David Boyes wrote: Based on feedback, we can really decide to ship the package formats that users seem to want/need, but we would *really* like to keep the binary packages to a small number. We would like to be able to use a single zLinux image to build binary packages. While you *could* do that, I think you'll find that you'll need at least one RH and one SuSE guest, and you'll need to build the packages independently on both. There are still some small and subtle differences in the way RPMs are built on the different distributions, and you'll need the separate guests to test the installs anyway. Actually, more than small and subtle... Dependencies for the binary RPMs are in part derived from the build environment, so creating a SuSE RPM on a RedHat system, or the other way around, is never a good idea. It can be made to work with the right amount of dark magic, but it isn't for the faint of heart, and it is bound to get you into a lot of misery down the road. Cheers, Kris -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Best Practices for zSeries linux ISVs?
We would like to be able to use a single zLinux image to build binary packages. While you *could* do that, I think you'll find that you'll need at least one RH and one SuSE guest, and you'll need to build the packages independently on both. There are still some small and subtle differences in the way RPMs are built on the different distributions, and you'll need the separate guests to test the installs anyway. Actually, more than small and subtle... Dependencies for the binary RPMs are in part derived from the build environment, so creating a SuSE RPM on a RedHat system, or the other way around, is never a good idea. Indeed. It's technically possible, but you won't like the amount of work necessary to make it supportable. It can be made to work with the right amount of dark magic, but it isn't for the faint of heart, Oh, it's all in where you put your Horcruxes and how many you have...8-) -- db -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
