On Wed, Oct 19, 2016 at 05:08:15PM +0200, Alexander Larsson wrote:
I actually had had a copr setup with a custom redhat-rpm-config that automatically built things in a different prefix. Most things built just fine with zero specfile changes.
Well, that's encouraging, at least. It still means some degree of doing everything twice, but at least it's mostly computers doing it. :)
Just don't look at the macros, or you'll go blind! :)
Ha. I've looked at the regular redhat-rpm-config macros so I'm partially-innoculated. But generally, doing... creative... things there is better than putting more complication in each spec file.
"MM" == Matthew Miller mattdm@fedoraproject.org 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.
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.
- J<
On 10/19/2016 11:38 AM, Jason L Tibbitts III wrote:
"MM" == Matthew Miller mattdm@fedoraproject.org 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.
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.
This isn't really directly applicable, but I've been playing around with building RPMs into /opt and creating a system of stackable dependencies among them. Some more info is here:
https://github.com/altccrpms/info/wiki https://github.com/altccrpms/altcc-rpm-macros
One challenge is that once you move out of /usr, you can no longer rely on the filesystem package to own the top level directories so I've had to add things like:
%files %{?altcc:%altcc_files %{_bindir} %{_libdir} %{_mandir}/man1}
to own the appropriate directories.
But I have been pretty happy with being able to build parallel installable rpms of different versions of packages while maintaining some automatic dependencies as well. Packages provide/require are prefixed with their install location so they have a separate namespace.
It also has been fairly straightforward to redefine _prefix and _sysconfdir and that works for most packages.
- Orion
On Wed, Oct 19, 2016 at 09:01:29PM -0600, Orion Poplawski wrote:
One challenge is that once you move out of /usr, you can no longer rely on the filesystem package to own the top level directories so
Hmmm, yeah, also not necessarily relevant to $subject, but should we have either filesystem or filesystem-opt own /opt/fedora and maybe /opt/fedora/lib and /opt/fedora/bin (as per FHS)?
On Wednesday, October 19, 2016 12:38:06 PM CEST Jason L Tibbitts III wrote:
"MM" == Matthew Miller mattdm@fedoraproject.org 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@lists.fedoraproject.org
-
Jason L Tibbitts III -
Matthew Miller -
Orion Poplawski -
Pavel Raiskup