Re: Requires/Provides issue with re-packaging a complex product (endeca)
Just to clarify, this package is NOT for public consumption. The software is distributed via installer, to be run by humans. Since we're doing automation using puppet, an RPM of the code reduces the complexity of the installation substantially and generates a repeatably installable artifact into an existing artifact repository (RH Satellite, in this case). There actually IS a reason to believe that the ELF data can is, while not wrong, producing undesirable output. The problem isn't that the dependencies aren't correct. It's that the package itself supplies those dependencies internally and very specifically doesn't want to external system to interfere with its deployment of the shared libraries. The package builds very well without turning off the internal dependency generator. The issue arises when I try to install it and rpm looks at it's huge list of requirements and notes that apparently not all of them are satisfied internally or it would rather I use the packages that it purports work best. The problem is that they ARE supplied internally and that rpm, during the packaging step, didn't understand that. I'm not terrible at writing spec files, at least for private consumption, but this seems like it might be something that the rpm developers didn't expect to have to handle as often as I seem to. The quantity of software that I've had to install using the various shell/executable installer systems is growing, not shrinking. I attribute this to laziness on the part of the distributor/developer. They don't take the time to ensure compatibility with various distributions. In all fairness, there are an awfully large number of distros to deal with and many/most of them don't take wider-ranging compatibility into account, at least not as a primary element, when getting their (frequently volunteer) packagers to produce their native-level packaging. Thus, in this case, this solution is (probably) the only viable one short of writing more code to filter more packages, essentially by hand. I can't have compatibility with this package because if I stripped out all the perl binaries and used the native perl executables, I might not get what I expected. Perl has a way of changing across versions and this is a pretty complicated piece of code. Because the developers saw fit to package a modified version of code that exists generally in the wild (JDK, perl, probably something that I'm missing), this entire piece of software can either be viewed as a black box (install it all and let it sort itself out) or it would have to be hand-engineered to extract all the pieces that are different and use those as alternates to the ones supplied by standard OS packaging. I don't have the insight into the product to do the latter, so the former has to suffice. Thus, I package it like it was a Big Pile of Obfuscated Code(tm), and it works like a champ. Scripts inside the code modify library paths to point ot specific versions of specific things and I get a running server. Woot! Do I think this is a good idea? No. Do I think that packaging frankenserver versions of perl and the JDK are good ideas? Definitely not. Do I think that software should be written towards wider compatibility with existing packages? Definitely yes. Do most enterprise software developers seem to agree with me/us? It doesn't look that way. I'm actually speaking at a conference in a few weeks about this specific issue (not the rpm problem, but the stop writing stuff that's hard to deliver problem). Thanks again to you both. You have saved me days of frustration and I owe you both a beverage of your choice. Mykel On Sat, Jan 5, 2013 at 4:01 PM, devzero2000 pinto.e...@gmail.com wrote: On Sat, Jan 5, 2013 at 10:15 PM, Jeffrey Johnson n3...@me.com wrote: On Jan 5, 2013, at 4:02 PM, Mykel Alvis wrote: devzero2000 over on the rpm-users list suggested %define _use_internal_dependency_generator 0 This did exactly what I needed. Yes but … there are profound changes to the *.rpm package format that are coupled to setting %_use_internal_dependency_generator to 0. That macro was _NEVER_ designed to be flipped around on a per-package basis by package monkeys. Yes, but apparently autoreq to 0 doesn't work on the sharelib deps on rpm 4.8 (@rpm.org). I have seen ocaml package setting %_use_internal_dependency_generator to 0 before ocaml deps was included in rpm. http://markmail.org/message/hdwyn3ys675psmcz But perhaps i am missing something, probably. Best regards __ RPM Package Managerhttp://rpm5.org User Communication List rpm-users@rpm5.org
Re: Requires/Provides issue with re-packaging a complex product (endeca)
On Jan 6, 2013, at 12:52 PM, Mykel Alvis wrote: Just to clarify, this package is NOT for public consumption. The software is distributed via installer, to be run by humans. Since we're doing automation using puppet, an RPM of the code reduces the complexity of the installation substantially and generates a repeatably installable artifact into an existing artifact repository (RH Satellite, in this case). Most linux distros are development dog food aimed at enthusiasts. Whether one wishes to call that piublic is a matter of taste and de facto. There actually IS a reason to believe that the ELF data can is, while not wrong, producing undesirable output. The problem isn't that the dependencies aren't correct. It's that the package itself supplies those dependencies internally and very specifically doesn't want to external system to interfere with its deployment of the shared libraries. There is no reason that you have pointed out to suspect that ELF data is wrong. There are reasosn to suspect that you aren't adding -Wl,soname,YOUR_SONAME_HERE when building and I asked whether the libraries had DT_SONAME (and give you the readelf command to verify. The package builds very well without turning off the internal dependency generator. The issue arises when I try to install it and rpm looks at it's huge list of requirements and notes that apparently not all of them are satisfied internally or it would rather I use the packages that it purports work best. The problem is that they ARE supplied internally and that rpm, during the packaging step, didn't understand that. I'm not terrible at writing spec files, at least for private consumption, but this seems like it might be something that the rpm developers didn't expect to have to handle as often as I seem to. THe buils is entirely in the eye of the beholder. RPM extracts info from ELF files: if the build doesn't put the correct data into the ELF header, you can blame RPM all you wish, but its the buikld that needs to be fixed. The quantity of software that I've had to install using the various shell/executable installer systems is growing, not shrinking. I attribute this to laziness on the part of the distributor/developer. They don't take the time to ensure compatibility with various distributions. In all fairness, there are an awfully large number of distros to deal with and many/most of them don't take wider-ranging compatibility into account, at least not as a primary element, when getting their (frequently volunteer) packagers to produce their native-level packaging. Life's tough ... have a kleenex and my sympathies. Thus, in this case, this solution is (probably) the only viable one short of writing more code to filter more packages, essentially by hand. I can't have compatibility with this package because if I stripped out all the perl binaries and used the native perl executables, I might not get what I expected. Perl has a way of changing across versions and this is a pretty complicated piece of code. You may supply whatever reasoning you wish for how you choose to solve your problem. That won't solve my problem: supply reasonable support for unknown RPM problems. Because the developers saw fit to package a modified version of code that exists generally in the wild (JDK, perl, probably something that I'm missing), this entire piece of software can either be viewed as a black box (install it all and let it sort itself out) or it would have to be hand-engineered to extract all the pieces that are different and use those as alternates to the ones supplied by standard OS packaging. I don't have the insight into the product to do the latter, so the former has to suffice. Thus, I package it like it was a Big Pile of Obfuscated Code(tm), and it works like a champ. Scripts inside the code modify library paths to point ot specific versions of specific things and I get a running server. Woot! So Ship It! Do I think this is a good idea? No. Do I think that packaging frankenserver versions of perl and the JDK are good ideas? Definitely not. Do I think that software should be written towards wider compatibility with existing packages? Definitely yes. Do most enterprise software developers seem to agree with me/us? It doesn't look that way. I'm actually speaking at a conference in a few weeks about this specific issue (not the rpm problem, but the stop writing stuff that's hard to deliver problem). Good for you! Now can you tell me whether your libraries have a DT_SONAME using readelf -a /path/to/some/lib/libfoo*.so | grep SONAME please? 73 de Jeff __ RPM Package Managerhttp://rpm5.org User Communication List rpm-users@rpm5.org
Re: Requires/Provides issue with re-packaging a complex product (endeca)
On Jan 6, 2013, at 3:34 PM, Mykel Alvis wrote: I think it's OK to do this, but I'm going to do so directly to your personal email so that I don't display piles of potentially litigious data in a public forum. Please reply with readelf output publically: the output is not that large if you grep out only the SONAME (i.e. the Provides:) and the NEEDED (i.e the Requires:) for a couple of libraries and executables. There are also specific options to display exactly DT_SONAME/DT_NEEDED if you wish to read man readelf: I deliberately gave you the easier to understand readelf -a ... | grep SONAME as something that an average RPM packager faced with a similar problem using Google search might find useful, comprehensible, and perhaps easier to remember. YMMV. Most users with RPM problems now use Google search first, you included. This leads to a preponderance of problem (but not solution) reports. For something like RPM w 15y of serachable information, searching can and will find just about every answer you want to hear, with many answers that implictly/contextually appropriate and generally foolish. If one is smart enough, one can sometimes find the best solution. But generally, the deluge of possibile answers and No time! precludes best or even thoughtful. Yes I respond to requests out of good will, formerly out of some misplaced sense of duty and obligation to assist with information on software I wrote and happen to know quite well. The specific parts of your problem that have only to do with RPM are the metadata in *.rpm package headers. The parts of this problem that I cannot help directly with are what the packages are used for, how the software is to be built, how to setup yum repositories, and why yum on RHEL (more likely CentOS) is reporting a dependency failure. The other issues are implicitly related to the (non-)existence of metadata, as well as coupled into the root causes for your specific issue, and cannot be ignored (or solved by RPM). 73 de Jeff __ RPM Package Managerhttp://rpm5.org User Communication List rpm-users@rpm5.org
Re: Requires/Provides issue with re-packaging a complex product (endeca)
I certainly understand the frustration in that I experience it identically in other areas. From your other email, I read I'm looking for libraries with _MISSING_ SONAME's. The solution there is to add DT_SONAME with -Wl,soname,YOUR_SONAME It's been decades, literally, since I handled C linking on a daily basis. So, assuming that we did locate such missing entries, is this something that would need to be done at compile/link time or are those switches that can be applied via a spec file/rpmbuild? Are there existing mechanism for re-building a compiled .so without access to the source? On Sun, Jan 6, 2013 at 2:48 PM, Jeffrey Johnson n3...@me.com wrote: On Jan 6, 2013, at 3:34 PM, Mykel Alvis wrote: I think it's OK to do this, but I'm going to do so directly to your personal email so that I don't display piles of potentially litigious data in a public forum. Please reply with readelf output publically: the output is not that large if you grep out only the SONAME (i.e. the Provides:) and the NEEDED (i.e the Requires:) for a couple of libraries and executables. There are also specific options to display exactly DT_SONAME/DT_NEEDED if you wish to read man readelf: I deliberately gave you the easier to understand readelf -a ... | grep SONAME as something that an average RPM packager faced with a similar problem using Google search might find useful, comprehensible, and perhaps easier to remember. YMMV. Most users with RPM problems now use Google search first, you included. This leads to a preponderance of problem (but not solution) reports. For something like RPM w 15y of serachable information, searching can and will find just about every answer you want to hear, with many answers that implictly/contextually appropriate and generally foolish. If one is smart enough, one can sometimes find the best solution. But generally, the deluge of possibile answers and No time! precludes best or even thoughtful. Yes I respond to requests out of good will, formerly out of some misplaced sense of duty and obligation to assist with information on software I wrote and happen to know quite well. The specific parts of your problem that have only to do with RPM are the metadata in *.rpm package headers. The parts of this problem that I cannot help directly with are what the packages are used for, how the software is to be built, how to setup yum repositories, and why yum on RHEL (more likely CentOS) is reporting a dependency failure. The other issues are implicitly related to the (non-)existence of metadata, as well as coupled into the root causes for your specific issue, and cannot be ignored (or solved by RPM). 73 de Jeff __ RPM Package Managerhttp://rpm5.org User Communication List rpm-users@rpm5.org
Re: Requires/Provides issue with re-packaging a complex product (endeca)
Responses inline below:
On Sat, Jan 5, 2013 at 11:10 AM, Jeffrey Johnson n3...@me.com wrote:
Second, you're right, I'm using rpm 4.8 from RHEL. It's the only choice I
have.
OK.
FYI: there's not enough difference to worry about between @rpm.org - @
rpm5.org.
The goals are more different than the code is: RHEL support is a deadly
sea-anchor
to change. So @rpm5.org has more -- and more aggresive -- features.
Unfortunately, enterprise customers generally have artificial requirements
that force them to use tools that have support. Without RHEL, they almost
certainly would have gone Microsoft.
Next, at least in my case, setting the -x flag doesn't change anything.
I have the following line in the %install section
find $RPM_BUILD_ROOT -name \*.so\* -exec chmod -x {} \;
prior to packaging, no shared libraries have the executable bit set. I
think this is what you meant.
As for the dependencies, you're correct in that there is no reason to
suspect that they aren't required. The problem I'm experiencing is that
all the dependencies that are required are being supplied by the local
package, but RPM is generating external dependencies because it sees the
need for a Requires and isn't noticing that it was supplied as a Provides.
Note that there may be a typo: note the extra '/' character within
parentheses:
Error: Package: endeca-toolsandframeworks-3.1.1-1.el6.x86_64
(/endeca-toolsandframeworks-3.1.1-1.el6.x86_64)
Requires: endeca-mdex=6.4.0
See if that is in the package requirements
rpm -qp --requires endeca-toolsandframeworks-3.1.1-1.el6.x86_64.rpm
That is interesting. I'm building a multi-subpackage RPM, and endeca-mdex
is a requirement for endeca-toolsandframeworks.
Here is the relevant package section from my spec
--- snip ---
%package mdex
Version:%{mdex_version}
Group: Servers/Indexing
Summary:Endeca MDex %{version}
%description mdex
Endeca is an index engine
This is the MDex portion
%package presentationapi
Version:%{mdex_version}
Group: Servers/Indexing
Summary:Endeca MDex Presentation API %{version}
Requires: endeca-mdex=%{version}
%description presentationapi
Endeca is an index engine
This is the Presentation API found in the MDex installer
%package platformservices
Version:%{pfs_version}
Group: Servers/Indexing
Summary:Endeca PlatformServices %{version}
Requires: endeca-mdex=%{mdex_version}
%description platformservices
Endeca is an index engine
This is the Platform Services
%package toolsandframeworks
Version:%{tfw_version}
Group: Servers/Indexing
Summary:Endeca Tools and Frameworks %{version}
Requires: endeca-mdex=%{mdex_version}
endeca-platformservices=%{pfs_version}
%description toolsandframeworks
Endeca is an index engine
This is Tools and Frameworks for Endeca
--- snip ---
I have all versions set with %defines because they'll keep moving forward
and need to be rebuilt each time.
If you have any information about how I could filter using rpm 4.8 I'd
appreciate it.
Filtering in rpm-4.8 is fairly complex (compared to rpm5).
But filtering basically involves writing a 1 line wrapper script
to a helper to post-process stdout to remove a token using sed(1).
(rpm5 implements the same token removal by applying patterns
to tokens, and excluding, w/o the need for scripts helpers).
There's a bunch of macros in rpm-4.8 (and conventions) that are supposed to
assist
with the filtering, but add complexity from the conventional choices/names
of parameters
used in wrappers etc.
According to the data I could glean initially, that's what all the %globals
were in my original post. I spent about an hour trying to get them
stabilized.
I think filtering changed dramatically from 4.8 to 4.9. Since I don't yet
have 4.9, I believe I'm stuck with the way you were describing. I found a
few articles describing how people did it (the new way) so I'll probably be
able to glean enough data from them (and from pending requests to RH
support) to make this work.
Re: Requires/Provides issue with re-packaging a complex product (endeca)
On Jan 5, 2013, at 4:02 PM, Mykel Alvis wrote:
devzero2000 over on the rpm-users list suggested
%define _use_internal_dependency_generator 0
This did exactly what I needed.
Yes but … there are profound changes to the *.rpm package
format that are coupled to setting %_use_internal_dependency_generator to 0.
That macro was _NEVER_ designed to be flipped around on a per-package basis
by package monkeys.
For starter, your package is not multilib ready (which will cause issues on
path collisions,
particularly for ELF libraries), and is generally
The Wrong Fix
You also cannot use --filerequire to see which files generated which
dependencies.
The better fix examines the dependencies and finds out why they
dependencies don't match.
There is no reason at all -- EIGHT YEARS LATER -- to believe that
the dependency extraction based on ELF data is incorrect. In gafact it
is both correct and well tested, just5 that packagers have lost whatever
knowledge about how to compile programs they might once have had
because of the insane complexity of GNU tools like autoconf/automake.
Hint: Run
readelf -a libfoo.so | grep SONAME
I'll bet your libraries do not have an soname. the string SONAME aka DT_SONAME
is mapped into a Provides, the NEEDED string aka DT_NEEDED is mapped into a
Requires:.
Including a DT_SONAME in the library is now harder than passing a
singlr option to the linker like
-WL,so name,THIS_IS_MY_SONAME
73 de Jeff
On Sat, Jan 5, 2013 at 12:26 PM, Jeffrey Johnson n3...@me.com wrote:
On Jan 5, 2013, at 1:07 PM, Mykel Alvis mal...@restorationhardware.com
wrote:
Responses inline below:
On Sat, Jan 5, 2013 at 11:10 AM, Jeffrey Johnson n3...@me.com wrote:
Second, you're right, I'm using rpm 4.8 from RHEL. It's the only choice I
have.
OK.
FYI: there's not enough difference to worry about between @rpm.org -
@rpm5.org.
The goals are more different than the code is: RHEL support is a deadly
sea-anchor
to change. So @rpm5.org has more -- and more aggresive -- features.
Unfortunately, enterprise customers generally have artificial requirements
that force them to use tools that have support. Without RHEL, they almost
certainly would have gone Microsoft.
(aside)
If enterprise customers used microsoft instead of RHEL, they would have
saved oodles of money: RHEL pricing is obscenely expensive. *shrug*
Note that I've used M$ Windows for perhaps 3 months over 30 years of uglix:
just saying.
Next, at least in my case, setting the -x flag doesn't change anything.
I have the following line in the %install section
find $RPM_BUILD_ROOT -name \*.so\* -exec chmod -x {} \;
prior to packaging, no shared libraries have the executable bit set. I
think this is what you meant.
Best is to verify the end result that is actually in the *.rpm package.
Using --xml is WYSIWYG for everything: there are also query formats for
a tag displayed in octal that can be substituted (untested, from memory):
rpm -qp --qf '[%{FILENAMES}: %{FILEMODES:oct}\n]' foo*.rpm
As for the dependencies, you're correct in that there is no reason to
suspect that they aren't required. The problem I'm experiencing is that
all the dependencies that are required are being supplied by the local
package, but RPM is generating external dependencies because it sees the
need for a Requires and isn't noticing that it was supplied as a Provides.
Note that there may be a typo: note the extra '/' character within
parentheses:
Error: Package: endeca-toolsandframeworks-3.1.1-1.el6.x86_64
(/endeca-toolsandframeworks-3.1.1-1.el6.x86_64)
Requires: endeca-mdex=6.4.0
See if that is in the package requirements
rpm -qp --requires endeca-toolsandframeworks-3.1.1-1.el6.x86_64.rpm
That is interesting. I'm building a multi-subpackage RPM, and endeca-mdex
is a requirement for endeca-toolsandframeworks.
If a replacement, then you need a Provides: with the other name as well.
Here is the relevant package section from my spec
--- snip ---
%package mdex
Version:%{mdex_version}
Group: Servers/Indexing
Summary:Endeca MDex %{version}
%description mdex
Endeca is an index engine
This is the MDex portion
%package presentationapi
Version:%{mdex_version}
Group: Servers/Indexing
Summary:Endeca MDex Presentation API %{version}
Requires: endeca-mdex=%{version}
%description presentationapi
Endeca is an index engine
This is the Presentation API found in the MDex installer
%package platformservices
Version:%{pfs_version}
Group: Servers/Indexing
Summary:Endeca PlatformServices %{version}
Requires: endeca-mdex=%{mdex_version}
%description platformservices
Endeca is an index engine
This is the Platform Services
%package toolsandframeworks
Version:%{tfw_version}
Group:
Re: Requires/Provides issue with re-packaging a complex product (endeca)
On Sat, Jan 5, 2013 at 10:02 PM, Mykel Alvis mal...@restorationhardware.com wrote: devzero2000 over on the rpm-users list suggested %define _use_internal_dependency_generator 0 My self, devzero2000 (Elia Pinto) is part of the rpm5 team, thanks to jeff. Since the request was for rpm 4.8 I preferred answer you on the rpm mailing list. Best __ RPM Package Managerhttp://rpm5.org User Communication List rpm-users@rpm5.org
Re: Requires/Provides issue with re-packaging a complex product (endeca)
On Sat, Jan 5, 2013 at 10:15 PM, Jeffrey Johnson n3...@me.com wrote: On Jan 5, 2013, at 4:02 PM, Mykel Alvis wrote: devzero2000 over on the rpm-users list suggested %define _use_internal_dependency_generator 0 This did exactly what I needed. Yes but … there are profound changes to the *.rpm package format that are coupled to setting %_use_internal_dependency_generator to 0. That macro was _NEVER_ designed to be flipped around on a per-package basis by package monkeys. Yes, but apparently autoreq to 0 doesn't work on the sharelib deps on rpm 4.8 (@rpm.org). I have seen ocaml package setting %_use_internal_dependency_generator to 0 before ocaml deps was included in rpm. http://markmail.org/message/hdwyn3ys675psmcz But perhaps i am missing something, probably. Best regards __ RPM Package Managerhttp://rpm5.org User Communication List rpm-users@rpm5.org
Re: Requires/Provides
Rick Miller wrote: But even with all the patching, the only yum use is for handling RPM packages for Linux on FreeBSD (like for the linux emulator). It has too many hardcoded assumptions to work for native packages. There is no real interest in having it portable to other systems. I left something out when I explained that we were trying to build Yum. We are looking to install RPM and Yum and use those to manage our homegrown software and packages on FreeBSD. We're not looking to manage anything other than our own software and applicable dependancies. That is a perfectly reasonable usage scenario, just not sure about yum. But just because it isn't supported doesn't mean that it won't work. Having said that, do you believe that portability will continue to be an issue under these circumstances? I haven't looked at the later versions, than rpm-5.2.1 and yum-3.2.29. But yum used to have all kinds of assumptions coded in, like the use of /usr/bin/python and not allowing prefix. Or using redhat-release. And as far as I know, yum still declares conflicts on rpm5 and zif... Should take a look at the later yum code, see how much it would take ? A slight problem is that nobody is maintaining the python at rpm5.org. --anders __ RPM Package Managerhttp://rpm5.org User Communication List rpm-users@rpm5.org
Re: Requires/Provides
On Apr 4, 2012, at 3:29 PM, Anders F Björklund wrote: A slight problem is that nobody is maintaining the python at rpm5.org. Yet. 73 de Jeff __ RPM Package Managerhttp://rpm5.org User Communication List rpm-users@rpm5.org
Re: Requires/Provides
What are the Requires: needed? My mistake, they are BuildRequires: and are as follows: python gettext intltool What version of RPM? I *think* its 5.2.x, but not 100% sure. I don't have access to the host today and can let you know tomorrow. It was installed from the FreeBSD ports collection for 8.2-RELEASE. All (at least that I can think of) Requires can be stubbed out in (normally: dunno what paths FreeBSD uses) in /etc/rpm/sysinfo/Providename I thought the same. The path in FreeBSD is /usr/local/etc/rpm/sysinfo/Providename However, might it be different since they are BuildRequires: and not Requires: ? Alternatively, you can stub out by building a package with a Provides: I had considered this and may try it tomorrow. (aside) The RPM I am trying to build is yum. I suspect that I may hit a number of snags with the yum.spec as I try to get an RPM built for FreeBSD. This happens to be the first. -- Take care Rick Miller __ RPM Package Managerhttp://rpm5.org User Communication List rpm-users@rpm5.org
Re: Requires/Provides
Rick Miller wrote: What version of RPM? I *think* its 5.2.x, but not 100% sure. I don't have access to the host today and can let you know tomorrow. It was installed from the FreeBSD ports collection for 8.2-RELEASE. That would be 5.2.1. http://www.freebsd.org/cgi/cvsweb.cgi/ports/archivers/rpm5/ (aside) The RPM I am trying to build is yum. I suspect that I may hit a number of snags with the yum.spec as I try to get an RPM built for FreeBSD. This happens to be the first. Using the yum.spec from Fedora on FreeBSD won't work, and is probably the least of your problems compared with portability. A yum port is available, and it required *lots* of patching: http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/150541 But even with all the patching, the only yum use is for handling RPM packages for Linux on FreeBSD (like for the linux emulator). It has too many hardcoded assumptions to work for native packages. There is no real interest in having it portable to other systems. It was mistakenly submitted* as a dependency of createrepo-0.9.8, but it would have been better to use createrepo-0.4.11 instead... (* as per http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/150542) At one point, there was even a port of mock for use in linux-base: http://www.freebsd.org/cgi/cvsweb.cgi/ports/emulators/linux_base-f10/ (currently it has a long hardcoded list of rpms, and uses rpm2cpio) --anders __ RPM Package Managerhttp://rpm5.org User Communication List rpm-users@rpm5.org
Re: Requires/Provides
Thanks for the info, Anders! I had wondered if anyone had done this already and was unable to locate the port using my google-foo. Thank you for the URLs. I guess we will evaluate how important yum would be for us in our environment and compare the benefits vs. the LOE to implement. On Tue, Apr 3, 2012 at 12:30 PM, Anders F Björklund a...@rpm5.org wrote: Rick Miller wrote: What version of RPM? I *think* its 5.2.x, but not 100% sure. I don't have access to the host today and can let you know tomorrow. It was installed from the FreeBSD ports collection for 8.2-RELEASE. That would be 5.2.1. http://www.freebsd.org/cgi/cvsweb.cgi/ports/archivers/rpm5/ (aside) The RPM I am trying to build is yum. I suspect that I may hit a number of snags with the yum.spec as I try to get an RPM built for FreeBSD. This happens to be the first. Using the yum.spec from Fedora on FreeBSD won't work, and is probably the least of your problems compared with portability. A yum port is available, and it required *lots* of patching: http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/150541 But even with all the patching, the only yum use is for handling RPM packages for Linux on FreeBSD (like for the linux emulator). It has too many hardcoded assumptions to work for native packages. There is no real interest in having it portable to other systems. It was mistakenly submitted* as a dependency of createrepo-0.9.8, but it would have been better to use createrepo-0.4.11 instead... (* as per http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/150542) At one point, there was even a port of mock for use in linux-base: http://www.freebsd.org/cgi/cvsweb.cgi/ports/emulators/linux_base-f10/ (currently it has a long hardcoded list of rpms, and uses rpm2cpio) --anders -- Take care Rick Miller __ RPM Package Managerhttp://rpm5.org User Communication List rpm-users@rpm5.org
