|
On 11/08/2013 02:58 PM, Michael Gettes
wrote:
On Nov 8, 2013, at 4:50 PM, Rich Megginson <rmeggins@xxxxxxxxxx>
wrote:
On 11/08/2013 02:10 PM, Michael Gettes
wrote:
As I currently understand things, 389
1.2 is available via RPM dist channels (including epel test
using rmeggins people repo)
. . . and really isn't fully supported. My main intention for
providing EL6 binaries was to give a preview of upcoming
features that were going in to RHEL6. There isn't much
difference between my personal epel repo and the version in
RHEL6.
and 1.3 is available by source
tarball.
Binary packages are available for Fedora . . .
i should have mentioned - i need for RHEL6.
Understood
due to how my organization handles firewall access, it is
quite the PITA to build network source based software which
makes it rather difficult for me to deploy 1.3 in test or
prod.
What exactly is the issue?
If there was any chance of getting 1.3
(and beyond) via a standard RPM dist channel,
I don't know what that would be. I don't know if there is a
"forward" looking EPEL6 category - most users using EPEL6 want
older, more stable software - I suppose you would need some
sort of "bleeding edge yet fully supported and supportable"
software channel.
My fedorapeople repo is not really a "standard RPM dist
channel".
I would be willing to run it, maybe
even in production! as i attempted to build 1.3 it had
requirements which would have necessitated building via git
or something similar and i got stuck cuz of how we do things
here (no comment on how we do things, please).
No comment, just want to understand what exactly the problem
is.
What problems did you have building 1.3? Was it 1.3.1?
1.3.2?
1.3.2 - the one with the SASL init hang. i went to build
the LDAPSDK and it recommends getting source via (need to go
find it…)
I guess you are using the instructions here -
http://port389.org/wiki/Building - which are very out-of-date - I
would be willing to work with you to come up with a simpler,
up-to-date build procedure.
Or even just taking the epel6 389-ds-base.spec file, changing the
version, and using rpmbuild to build rpms.
As for mozldap, starting with 1.2.6 or so, 389 uses openldap c sdk
not mozldap.
In fact, all of the build dependencies are available on RHEL6
(usually from the optional repos, where the -devel packages live),
so you shouldn't have to do anything.
my org blocks outbound access and it is a real PITA to work
with the security team to get things opened up.
You need outbound access to build from source?
on the plus side - i know other similar orgs to mine who
have gotten bit and we haven’t so i guess our strong firewall
approach “appears” to work for now.
does this help? i could just be doing something stupid in
not realizing how to build the software…. but, again, i would
most prefer not to build.
We need to make it easier to build from source, and to build rpms.
There will be situations where it will not be possible to provide
binary packages for all versions with all possible combinations of
options (e.g. build without systemd on rhel7).
i understand running “bleeding edge” in prod can be risky.
but if probs are being fixed out in the bleeding edge, i can
make a case for it. the support via this mailing list has
been, frankly, better than most vended software i have dealt
with in my career. THANK YOU! so the risk seems to be quite
low at this point given the quality of the people involved.
/mrg
if i have any of this wrong, i’d greatly appreciate being
corrected. pointers welcome.
like i said, something to consider.
have a great weekend all!
/mrg
--
389 users mailing list
389-users@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-users
|
