On Wednesday, October 19, 2016 12:38:06 PM CEST Jason L Tibbitts III wrote: > >>>>> "MM" == Matthew Miller <mattdm@xxxxxxxxxxxxxxxxx> writes: > > MM> Ha. I've looked at the regular redhat-rpm-config macros so I'm > MM> partially-innoculated. But generally, doing... creative... things > MM> there is better than putting more complication in each spec file. > > I've been spending a lot of time in there and in RPM macro stuff in > general, doing things far worse than this. So if there are specific > needs, we can try to come up with something. I note with trepidation > that Red Hat already did something a bit like this with SCLs, but I > wouldn't recommend using those macros as any kind of an example. Sorry, ad "SCLs is not any kind of an example" ... it is easy to say this. There's no need for trepidation here, there are good reasons to have (something like) SCLs. The long term ugly fact is that we in community say that "SCL guys must _stop_ and wait (forever...) till somebody else satisfies this demand", we should rather try to iterate towards correct and acceptable solution for everybody. To the point, if there's something wrong with the design, one should point out how that /opt solution will be fixed, how to comply with FHS rules, etc.. because there are non-trivial problems. > And, you know, maybe someone (who knows or cares a lot more than I do) > could look back at relocatable RPMs and what the issues were there. > That was all a big "do not use" by the time I got involved so I can't > really say anything about them. Good point here with relocable RPMs, I'm not here that long to remember the worries ... but I can imagine there were similar issues as with SCLs. A bit unrelated: We fight against "rpath" all the time in Fedora (for good reasons!), but once you start doing something like non-default --prefix/--libdir installation, (something like) rpath makes sense. Pavel _______________________________________________ packaging mailing list -- packaging@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to packaging-leave@xxxxxxxxxxxxxxxxxxxxxxx
