In message <[EMAIL PROTECTED]>, [EMAIL PROTECTED] writes > Date: Fri, 14 Jul 2000 23:44:12 +0100 > From: "Anthony W. Youngman" <[EMAIL PROTECTED]> > > Having been advised (by private email) that the rpm thing was a FAQ, > I've skimmed the archives, and the only thing I could find near what I > was bothered about was "standardising the install package", a two-mail > thread in September 1998. (The easily accessible archives don't go much > further back.) > >Sigh, OK. So let's go over this, one more time..... > >2) There has been some talk about a RPM/dpkg format merger that has > been underway for many months now. I don't know what it's current > status, but we can only hope. However that turns out, the LSB is > *not* the place to invent a new packaging format. If we did, it's > likely that the rest of the world would probably ignore us.
And this has WHAT relevance to what I wrote? NONE AT ALL. I'm sorry, but I took the criticism about my first post on board, and this is now a straw man argument. > >5) Yes, we know that RPM's aren't necessarily compatible across > distributions. The way that we will address this is by strictly > limiting what dependencies a RPM can have. The only dependency that > it can assume the system will have will be something like > "LSB-1.0". (i.e., no libext2fs, or libc6.0, or other dependencies > which unfortunately arne't standardized across distributions.) > For compatibility reasons with Debian dpkg systems using aliens, we > will also sharply restrict what kind of trigger scripts can be > included with such RPM's. > This is what I was trying to address. Because you can't guarantee what will be there, you are guaranteeing a minimal subset of out-of-date libraries. If the LSB had been released 6 months ago, it would require libc5, but most distros are now glibc2.1 based. If it was released today it would require Xfree3, but in 6 months distros will HAVE to be Xfree4 based - new hardware and drivers will force their hand ... (that's probably a slight exaggeration, but you get my drift). In other words, as it now stands, the LSB will either act as a major brake on innovation, or be widely ignored. I suspect it will be the latter :-( > >7) Application vendors are not *obligated* to ship RPM format files. > If they like, they can use their own tar.gz or cpio, or some other > wrapped executable format if they like. However, given that even > Windows 2000 has a package technology, it would be a shame if we > were to forbid application writers from using a modern package > management system. This approach seems to be the best, most > pragmatic approach that is most likely to win acceptance from the > distributions, the independent software vendors, and the users. > Yes. Fine. No problems there. But if I want to ship my product wrapped up in its own installer (like Corel/WP do - they don't follow the InstallShield herd), then as far I can see, I am hosed if I need anything over and above what the LSB guarantees. Let's assume for whatever reason my package *needs* glibc 2.3, and the LSB only guarantees 2.1. As I read the LSB, *I'M*STUFFED*! If I want to guarantee a clean install, then I have no choice but to use rpm as my package format, and instruct the user to use their distro's default package manager. Writing my own flashy front end to manage installing just those components the user wants from my 3-CD package is impossible. It may be possible to install Perfect Office 2000 from rpms using the rpm program (or whatever), but I would be very pleasantly surprised if such an experience was NOT unpleasant. May I quote you on two points... "The only dependency that it can assume the system will have will be something like "LSB-1.0". (i.e., no libext2fs, or libc6.0, or other dependencies which unfortunately arne't standardized across distributions.) For compatibility reasons with Debian dpkg systems using aliens, we will also sharply restrict what kind of trigger scripts can be included with such RPM's." "However, given that even Windows 2000 has a package technology, it would be a shame if we were to forbid application writers from using a modern package management system." I find those two statements somewhat contradictory. I presume you don't mean that different libc6's and libext2fs's (same rev, different distro) are incompatible, but rather that they are not guaranteed to be present. While I may not be going about it the right way, the problem I am trying to address is "I need XFree4 and I need it NOW. Is it there?" If I need technology that post-dates the most recent LSB, then I'm stuffed as things currently stand :-( I HAVE to provide rpms, and I HAVE to trust that the distro's default package manager will "do the right thing". It's all very well putting "requires LSB 1.2 *and* libs x, y and z" on the box, but firstly how many people read the documentation, and secondly how many people would understand what it meant. You may disagree with me, but I don't think a "guaranteed minimum system" is that important. What I think should be addressed (and is being completely ignored as far as I can see) is "what does this system ACTUALLY HAVE". That latter is certainly the be-all and end-all for bleeding edge gamers, and probably many others too. Cater for them, and we also (at least partially) solve the problem of the LSB being obsolete before it's finished :-) witness the recent arrival of Xfree4. We need some way of making an installer die gracefully if dependencies aren't satisfied, and not forcing an ISV to install "everything but the kitchen sink" on top of an LSB base. I'm looking at it from an "experienced user" position. I've been bitten by a custom install prog assuming libc5 (my distro only had glibc2). I've been bitten by a standard package manager *insisting* on installing loads of stuff I had no use for on a relatively tiny hard drive. And I just CANNOT see the current version of the LSB successfully negotiating the balancing act of keeping ISVs happy, while both permitting leading edge distros and encouraging package manager competition. Consider the following scenario - I have a 1Gb program I'm selling. The most recent LSB is a year old, and has been invalidated by bleeding-edge distros :-( I want to be able do a 100Mb minimum install, and it's a pretty safe bet a large proportion of my customers are lusers. If I can't write a custom installer with the ability to interrogate the system then I'm hosed :-( Thanks to the person who told me my file layout would be slow :-) Thanks to the person who pointed me at various threads in the archive (unfortunately web access is a pain for me - I will hunt them up). And I promise I WILL go away if my concerns are addressed. But at the moment I seem to be getting knee-jerk off-target flamage :-) Cheers, Wol. -- Anthony W. Youngman - wol at thewolery dot demon dot co dot uk HEX wondered how much he should tell the Wizards. He felt it would not be a good idea to burden them with too much input. Hex always thought of his reports as Lies-to-People. The Science of Discworld : (c) Terry Pratchett 1999
