On Jun 27, 2011, at 2:39 PM, Miller, Vincent (Rick) wrote:
> On 6/27/11 2:18 PM, "Jeff Johnson" <n3...@mac.com> wrote:
>
>
>>
>> On Jun 27, 2011, at 1:59 PM, Miller, Vincent (Rick) wrote:
>>
>>> On 6/25/11 4:39 AM, "Anders F Björklund" <a...@rpm5.org> wrote:
>>>
>>>
>>>
>>>>
>>>> The BSD and Mac ports are currently using 5.2.1, that is the pre-ACID
>>>> RPM:
>>>> http://www.freebsd.org/cgi/cvsweb.cgi/ports/archivers/rpm5/
>>>> https://trac.macports.org/browser/trunk/dports/sysutils/rpm52/
>>>
>>>
>>> I would be happy with the FreeBSD port of RPM. I did do an install of
>>> it
>>> and it did not install the rpmbuild binary. This was one of the main
>>> reasons for downloading and installing from sourceŠ
>>>
>>
>> Are you trying to build *.rpm's on FreeBSD? That is
>> doable, but the binary *.rpm's produced are likely
>> not going to usable anywhere except on FreeBSD (which
>> doesn't use rpmbuild) without a fair amount of work.
>>
>> What problem are you trying to solve?
>
> The problem being solved is not really a problem. A decision was made
> that ops should employ a unified approach to managing software on a
> system. By unified approach, I mean issuing the same command to install
> something, despite the platform. The task to integrate RPM into FreeBSD
> was handed to me.
>
Ah, k. Your easiest path by far is going to
be to use Anders build of rpm-5.2.1 in FreeBSD
ports. That SHOULD just drop-in without the
issues you are reporting, and is likely all
you need (and likely prefer) for unified management.
The harder issue with "management" will be to teach
rpm about what F*BSD provides in ports and natively.
Your "unified approach to managing software" likely
has reasonably sane exclusions for "native" software.
There are 2 approaches to teaching rpm about what rpm "provides".
1) build a stub pkg automatically that "provides" all
the usual libraries in an empty (i.e. no files) package.
2) add provides as needed to /etc/rpm/sysinfo/Providename.
E.g. you are almost certainly going to have to do
mkdir -p /etc/rpm/sysinfo
echo "/bin/sh" >> /etc/rpm/sysinfo/Providename
in order to install any package that includes a shell script let.
The approach in 1) is a little bit (but only a little bit) harder
to get into place than the drudgery of stubbing out every provides
encountered.
See scripts/vpkg_provides.sh for the script that automates
generation of the the empty package that provides all the
usual "native" FreeBSD libraries. The script will generate
a *.spec file that needs
Name:
Version:
Release:
added in order to be built and installed. You need to choose
what you want to call the package.
>
> RPMs that get built on FreeBSD will only be installed in FreeBSD and vice
> versa.
>
That works. If you were interested in build *.rpm packages for
linux from FreeBSD hosting, well, that too is doable just trickier.
>
>>
>>> Perhaps I'll setup another VM and give the FreeBSD port another tryŠ
>>>
>>
>> I can turn on my FreeBSD VM which worked with the "%fbsd8x"
>> build options in devtool.conf under buildbot's for several
>> weeks running "make check if there's really a need.
>>
>> You can have the whole VM if you prepared for a 20+ GB VMFusion download.
>>
>> I likely can reinstall and redo the entire VM and build RPM from
>> a cvs checkout in less time than the download takes.
>
> Don't worry about your FreeBSD VM at the moment. I'm just interested in
> the simplest way to get rpm and rpmbuild to function on FreeBSD. If I can
> accomplish this with the BSD port, that will likely be the method I use to
> integrate.
>
Again rpm-5.2.1 from ports is likely the minimal effort path.
rpm-5.3.x is better code and higher performing, but trickier to get built.
I'd choose the path of least resistance initially to achieve your goal.
I can/will deliver you a rpm-5.3.x package built on FreeBSD if you can
state how you want that package built. It is in fact harder to walk
through the entire set of build options than it is to do the build.
See the %fbsd8x stanza in devtool.conf for what I last used. Note
that as a developer I'm forced to maximally featured (like 4-5 crypto
stacks and 4-5 embeddings and 3+ compressions all on "best effort"
in order to achieve code coverage and to find flaws. A "production"
choice of build options could/should be simpler than what is in %fbsd8x.
> I must admit, I am unfamiliar with devtool and devtool.conf. Google
> returns lots of results. Is there an official project page for this?
>
Yes devtool is rather unique.
The issue that had to be solved is splitting trees (like Berkeley DB)
out from rpm code in cvs.
So devtool is mostly about reforming a tree from multiple checkouts:
./devtool checkout
The other main aspect of devtool is building with options enumerated
in devtool.conf like this (for a build on FreeBSD from cvs)
./devtool fbsd8x
starting from a bare checkout.
There's also functionality to bootstrap an entire rpm build, also
downloading and building most of the essential build prereqs, that
is *very* nicely done: bootstrapping is a problem that almost
noone worries about these days.
All of the above was implemented by Ralf Engelschall in OpenPKG based on
some simple tweaks to his shtool package. WHich is also an elegant
approach to reusing shell code as if it were a Makefile instead
of using shell functions (which are not "portably" supported on all
Bourne shells).
There's another RPM_CHECK_LIB() set of M4 macros that automates
much of the AutoFu detecting build prerequisites of rpm, handling
internal or external copies of libraries, and also handling
foo.pc or fooconfig or libfoo.la means of gathering various
build parameters.
Highly recommended if you get into seriously complex building.
E.g. on a good day with a stiff wind on a familiar platform, rpm
links >80 libraries. WHich simply would not have been possible
w/o RPM_CHECK_LIB() simplicity.
hth
73 de Jeff______________________________________________________________________
RPM Package Manager http://rpm5.org
User Communication List rpm-users@rpm5.org
