In regard to: No Neon patch..., Mark Hatle said (at 1:22pm on Jun 29, 2007):

> Taken from rpm.org rpm-4.4.2.1 tree.
>
> Any comments or may I commit.  (I didn't just hit go, since I figured
> there might be some "discussion" on this issue.)  :)

neon can be a PITA, especially because it defaults to static lib only
and has non-obvious dependencies so linking with it can be challenging,
but I'm concerned about the proliferation of rpm "flavors".  Your flavor
might be built without neon at all so it won't support certain
functionality, someone else's rpm might have neon support but no lua, etc.

Sure, it's possible to have rpm's internal dependencies such that when
someone tries to install a package that "Requires(interp): lua" (or
whatever) the install aborts immediately if the rpm on the box doesn't
provide that, but that's not the point.

People writing spec files, or whatever packaging recipe format
eventually evolves, will write their recipes to use the functionality
that they know is guaranteed to be available in the rpm command that
users have available on their systems -- the minimal subset of features
that every rpm command supports.

Pretty soon, people won't try make use of lua or neon or anything else
that falls outside of that minimal subset, and those features in rpm
will become the software equivalent of my appendix -- evolutionary
leftovers that have ceased to serve a useful purpose.

I know I'm frequently in left field WRT rpm, but I think if you make
stuff like neon or lua too easily "optional", those things will fall
outside of the minimal subset, and at that point one needs to decide if
it wouldn't be better to just remove the evolutionary leftovers
completely.

Just MHO,

Tim (who still has his appendix, thank you very much)
-- 
Tim Mooney                                        Tim.Mooney@ndsu.edu
Information Technology Services                   (701) 231-1076 (Voice)
Room 242-J6, IACC Building                        (701) 231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164