Egmont Koblinger wrote:
> I perfectly understand your problem. We're building a distro in our own
> package build system (not rpm) and we have fully integrated it with a
> solution similar to fakeroot. (I couldn't get fakeroot work at that time,
Were you trying to use fakeroot on a Linux kernel or a different
kernel? It could very well be that fakeroot is Linux specific. But
it works fine for me.
> so I wrote my own one called "pretendroot", you can find it on
> freshmeat.net. It has a much simpler design while it still works
> perfectly for us).
Of course your own software will always be more familiar to the person
who wrote it. And if you are producing your own distro then you might
have good reason for choosing a custom solution. But because fakeroot
has been around for a long time and seems not to have any reason not
to use it then I suggest sticking to using it if possible. If it has
issues then reporting them upstream would be good. It is better to
avoid needless feature and program forks when possible.
> There are really plenty of stupid Makefiles out there in the world, e.g.
> ones with "install -o root -g root ..." which makes really no sense at all,
> since if you're root then it's the default to install as root, but if you're
> not, then why not let it work and install under your ID...? It definitely
> sucks if you have to patch all these Makefiles.
Yes. But I consider all of those bugs. It can be draining but please
report those upstream as bugs. If everyone does that then it is
easier to peer pressure inexperienced maintainers into improving their
processes.
> To simply make the installation succeed, you don't have to do much. You can
> even set up pretendroot stuff (by setting two env variables PRETENDROOTDIR
> and LD_PRELOAD, see the example "pretendroot" script in the tarball) in the
> spec file's %install section, so in this case you don't have to modify your
> rpm macros (hence the .spec file will be much more portable).
>
> For better integration, you can set these variables in macros files by
> altering %{___build_pre} or something like that.
Hmm... As I read that the unfortuante thing is that spec files for
your distribution are uniquely different from others. (Of course in
many ways that is already true for most distros for other reasons.)
> We also had some more magic for full integration, so that the %files list is
> always auto-generated, taking the fake user into account, e.g. if the
> install script had an "install -o foo" then this file would automagically
> appear in the final rpm package as being owned by foo. But this was a rather
> ugly hack and probably it's not what you need. Even without this step you
> can silently ignore the fake ownership of the files and use the %attr flag
> in a normal %files section.
>
> IMHO integrating RPM with fakeroot or a similar solution could be a nice
> idea from distribution makers, but I don't think it should be solved in
> mainstream RPM. YMMV.
If you are codifying this into process for your distro then it would
be easy to set policy that rpmbuild always uses fakeroot too. Such as
for automated build daemons and other robots.
fakeroot rpmbuild ${options} ${specfile}
Then there is no need to modify rpm at all. I much prefer the modular
approach to building application frameworks.
Just my opinion...
Bob
_______________________________________________
Rpm-list mailing list
Rpm-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/rpm-list
