Re: [Cooker] Questions and comments about Mandrake RPM-building practices
I don't work for Mandrake, this is just my $0.02... On Fri, 16 Jun 2000, Matthew Campbell wrote: 1. Why do all Mandrake RPM's have "mdk" in the release number? Why not? It certainly helps when using rpmfind.net to see which packages are "Mandrake native", so to speak. Since there's absolutely no harm in this and it in no way conflicts with the practices of other RPM-based distributions, why not do it? 2. I know that the files in source RPM's are recompressed using bzip2 in order to save space. However, I've read that one of the main concepts of RPM is "pristine source"; that is, in the source RPM we include the source exactly as we downloaded it, along with any patches necessary to make it work. Also, it's helpful if the "Source:" field in a spec file contains a valid URL for the source file, so people know where the source came from. If you recompress the source file with bzip2, then either you have to take out the URL, or the URL becomes invalid, unless the original source is actually available in bzip2-compressed format. Perhaps this is more of a philosophical issue than anything else. Well, since it actually affects the amount of free space on your HD, it's more than a philosophical issue, it has practical impact. Changing this would cost us more HD space, so what would be the practical benefit and does this benefit outweigh the loss? 3. Why is spec-helper run automatically by rpm during the package building process? Why is spec-helper needed at all? It seems redundant in light of the brp-* scripts stored under /usr/lib/rpm, though I guess one difference is that spec-helper uses bzip2 and brp-compress uses gzip. My main concern is that spec-helper could cause compatibility problems when building non-Mandrake packages on a Mandrake system, since spec-helper compresses the man pages automatically and non-Mandrake packages may not be expecting this. I can't imagine why any package (other than "man") would be affected by this, it would be helpful if you could supply a list of packages that this does in fact cause compatibility problems for. 4. I notice that in Mandrake change log entries, the package version number is at the end of the entry's header. Does this cause any trouble when building Mandrake source packages on a non-Mandrake system, or when installing Mandrake binary packages on a non-Mandrake system? Not that I know of. What problems have you had? I guess what I don't like about these things is that they're deviations from standard package building practices Could you provide a URL for the established standard? and the standard version of RPM. That's simply untrue: none of these are in any way a deviation from the standard version of RPM. All of these are completely and fully compatible with RPM, and wouldn't be possible if RPM were not in fact designed to allow exactly these very things. Mandrake and Red Hat can compete in areas like installation and the user interface, but I think cooperation is important in the area of software packaging. What specific problems have you had that are caused by the problems you mentioned that would be solved by either RedHat or Mandrake doing things differently? I've never had a single problem using Mandrake packages on RedHat or RedHat packages on Mandrake, and I've done both frequently. So as far as I can tell, they're cooperating just fine. I'd rather both companies concentrate on solving existing problems instead of nonexistent ones.
Re: [Cooker] Questions and comments about Mandrake RPM-building practices
Forget about that message I sent. I'm sorry for the wasted time and bandwidth. I'll get to work on contributing RPM's to Mandrake (actually, I have already). -- Matt Campbell [EMAIL PROTECTED] Web site: http://www.crosswinds.net/~mattcamp/ ICQ #: 33005941
Re: [Cooker] Questions and comments about Mandrake RPM-building practices
I guess what I don't like about these things is that they're deviations from standard package building practices and the standard version of RPM. Mandrake and Red Hat can compete in areas like installation and the user interface, but I think cooperation is important in the area of software packaging. When I ran Red Hat, I occasionally used Mandrake SRPMS to compile something that wasn't readily on RHAT or was an older version, and I rarely ran into problems. They're compatible as far as I've seen. 'course the point is moot now, since I run Mandrake. ;) -- Ben Reed a.k.a. Ranger Rick ([EMAIL PROTECTED]) http://defiance.dyndns.org / http://radio.scenespot.org/ Now playing on Defiance Radio: Black Light by Material
RE: [Cooker] Questions and comments about Mandrake RPM-building practices
practices 1. Why do all Mandrake RPM's have "mdk" in the release number? to make it known that it is a Mandrake RPM i guess ;) actually this does not cause problems RH will happily accept them. 2. I know that the files in source RPM's are recompressed using bzip2 in order to save space. However, I've read that one of the main concepts of RPM is "pristine source"; that is, in the source RPM we include the source exactly as we downloaded it, along with any patches necessary to make it work. Also, it's helpful if the "Source:" field in a spec file contains a valid URL for the source file, so people know where the source came from. If you recompress the source file with bzip2, then either you have to take out the URL, or the URL becomes invalid, unless the original source is actually available in bzip2-compressed format. Perhaps this is more of a philosophical issue than anything else. yes the url will become invalid, but i guess most users are smart enugh to figure that out.. i.e. if the program is called foo.tar.gz but because of mandarke it has been bzipped, then just do ls foo.tar* 3. Why is spec-helper run automatically by rpm during the package building process? Why is spec-helper needed at all? It seems redundant in light of the brp-* scripts stored under /usr/lib/rpm, though I guess one difference is that spec-helper uses bzip2 and brp-compress uses gzip. My main concern is that spec-helper could cause compatibility problems when building non-Mandrake packages on a Mandrake system, since spec-helper compresses the man pages automatically and non-Mandrake packages may not be expecting this. makes the links relative, strip files, and zips up the doc files. this means that you will no longer have to strip and zip the doc iles in the spec code. 4. I notice that in Mandrake change log entries, the package version number is at the end of the entry's header. Does this cause any trouble when building Mandrake source packages on a non-Mandrake system, or when installing Mandrake binary packages on a non-Mandrake system? shouldn't cause a problem. I guess what I don't like about these things is that they're deviations from standard package building practices and the standard version of RPM. Mandrake and Red Hat can compete in areas like installation and the user interface, but I think cooperation is important in the area of software packaging. as far as i know, they're compatible. ;) -- Matt Campbell [EMAIL PROTECTED] Web site: http://www.crosswinds.net/~mattcamp/ ICQ #: 33005941
