On Jun 17, 2011, at 9:42 AM, Wes Hardaker wrote: >>>>>> On Fri, 17 Jun 2011 09:31:29 -0400, Jeff Johnson <[email protected]> said: > > JJ> Again and again and again: > > Jeff, > > I looked at your patches the other day (and haven't had the time to > respond; sorry about that... it was on my todo list for today). The > problem is that both engineering approaches have problems. You're right > that linking to libraries should be avoided when possible and if it was > easy to do so, we definitely wouldn't. >
The problem here is that there's *TWO* changes needed and a legacy retrofit.
That (imho) is why the change continues to deadlock because it requires
coordinated change.
AFAICT theat coordination MUST start from net-snmp, where there is clear
benefit to _NOT_ linking -lrpm. Until net-snmp changes, well, RPM changes
glacially slowly on 4-5 year time scales and only for MUSTHAVE reasons.
> I think applying your patch to a distribution makes a lot of sense. It
> has control over cron, and can do things like add the routine cron-job
> on a regular basis and exec rpm and ... without issue. The problem is
> that we don't have control over the user's environment and system and
> can't make assumptions about /etc/cron.d being in existence, etc.
>
> JJ> The better engineering approach is to do what most other non-RPM
> JJ> platforms are doing, which is to use simpler system calls like
> JJ> stat(2) and opendir(3) and readdir(3) to populate the elements of a
> JJ> HRMIB.
>
> IE, this is the part that is problematic. How do we have a file-based
> hierarchy everywhere and works for every rpm based system from Fedora to
> embedded systems to Meego to ... How do you get 'make install' on those
> systems to do the complete setup so the HR mib works out of the box?
> From what i could tell from looking (admittedly quickly) at your other
> patch, there are assumptions made that means it won't work without user
> intervention.
>
There are _TWO_ solutions. You are asking the "portable legacy retrofit"
solution to deploy a directory and to add a cron script to populate that
directory from existing rpm query commands. I will speak to the "portable"
solution first:
Specific answers:
How do we have a file-base hierarchy everywhere ...
You choose a path (I've chosen the path /var/cache/hrmib, but ymmv)
You write a script that does (lazily)
[ ! -d /var/cache/hrmib ] && mkdir /var/cache/hrmib
You then populate (using a rpm --query and a touch) 0b files in the
directory.
Note: the only "trick" there is to get the package install time stamped
into stat(2).
You run the script under cron.
There's *lots* of ways to install a script and add a cron entry and
address all the other details such as raciness and pre-populating
so that the HR-MIB Just Works. E.g. it isn't hard to run the script
when the daemon starts.
Unless you specify what "assumptions" you see I cannot respond. I don't
see any "user intervention" on the "portable" solution path that are
insoluble. Yes you will need to add to packaging, and its likely the
net-snmp packaging that would be the best place to change (which one
would be changing anyways, the "portable" solution is necessary off
one is upgrading net-snmp but not upgrading rpm).
The other -- and better than "portable", cron scripts are always messy --
is to do exactly what the "portable" script does internally to RPM.
In RPM code there are two methods to register/unregister a package
in an rpmdb. All that's needed is to create/unlink a file and stamp
the install time onto the file. This is _NOT_ hard code to write,
nor is it risky. Yes there's details like chroot(2) in RPM that
need worrying about. All those chroot(2) issues already apply
to the path on which the rpmdb to use, the same overrides/disablers
used for an rpmdb path would also be needed for the (nominal) /var/cache/hrmib/
path.
> So, I'd even encourage platforms to apply your patch on top of our
> existing code if it would make the existing system better.
>
Then encourage please. I've been saying exactly what I'm saying
today for almost a decade now:
Its the wrong engineering to link an rpmdb (and Berkeley DB)
into net-snmp.
> But in order to apply it to the base, we need a distribution mechanism
> that works. Otherwise it's like setting up a good radio and a good
> antenna and expecting people to bring their own feed line.
I'd say differently: net-snmp does _NOT_ control its own
distribution mechanism. Look at "MeeGo" in your example above:
that's a distro vendor, not you (as a net-snmp devel), controlling
the distribution.
What is needed is a direction and a decision to change. That (imho)
must come from net-snmp, not from RPM, or from distro vendors, who
are entirely free to rematch and do whatever they wish (and vendors
WILL do whatever they choose to do …)
> JJ> Do you want a patch to simplify the net-snmp code, remove the linkage
> JJ> to rpm libraries, or not?
>
> Sure. But one that works on every system, or can be safely made to work
> on every system via configure/make-install.
>
I've sent this patch 3 times now. I'd like a clear call that
you WILL integrate the patch, and then I can/will generate
the patch and the "portable" script and even take on the
tedious explaining of a deep dark innocuous change as
needed.
> JJ> Otherwise I cease to care about
>
> Sorry if you're ticked off. But right now both engineering solutions
> suffer from problems.
>
I'm not ticked off. Just this is "Ground Hogs Day" all over again again again.
I have a duty and obligation (in my personal ethic) to try to "fix"
a software flaw that I created. My comment "cease to care" is solely that
I've tried to "fix" the problem sufficiently often to satisfy
my own personal duty/obligation ethic at this point.
If net-snmp users wishes to do -lrpm forevermore, then do so.
73 de Jeff
smime.p7s
Description: S/MIME cryptographic signature
------------------------------------------------------------------------------ EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev
_______________________________________________ Net-snmp-coders mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
