This is a rant and a dear lazyweb (not that lazy, actually) type of post.
I would like to be able to have a few things solved when dealing with RPMs:
- I would like a pbuilder like builder for specs
- I know about mock, but
- it accepts only src.rpm files (I know about rpmbuild -bs, but is broken, read further for the groovy details)
- I have some specs that have %include directives for the maintainer scripts and when rpmbuild -bs is ran, guess what, the extra files are left outside the src.rpm;oh yes, the directives are processed correctly for the binary rpm
- mock relies on bootstrapping a system using fedoralegacy.org, which was recently discontinued
- I have a redhat-9 chroot tarball which I would like to use and tell mock to use that without caring about upgrades (since my packages are not at all that dependent on the build system)
- mock fails to bootstrap even for fedora-devel-i386-core with the message "Cannot find a valid baseurl for repo: extras"
- the older versions fail to bootstrap because, apparently, it "Could not find useradd in chroot, maybe the install failed?"
- plague (how's that for irony?) relies on mock, which is broken
- mach seems to be deprecated
- I would like a simple repo creation and maintainance tool, something in the line of mini-dinstall, which should have apt4rpm and yum support, but it seems that repos are still the "new shiny thing" which has no proper tools
- I would like to be able to know from which version I am upgrading from the current package, not only that I am upgrading (in case you didn't knew, the only way to know that you are upgrading in a post/pre install/remove script, is the wonderful $1 parameter which indicates the number of packages installed after the script finishes or something along that line..
8 comments:
"mach" (which is the base from which mock was forked) can take .spec files as input; it's slightly broken to build RPM in Debian, but it works well under RPM systems.
I think it's hilarious that people and distributions still stubbornly try to keep on using RPM. Sure, it would be painful to switch to something working, but after that, there would be no more pain. Do the math...
Fedora Legacy closed, but many of the mirrors still exist. Just adjust your configuration to point to a mirror.
Check out the build.rpm from the SuSE folks...it gives you what you need for having a pbuilder like infrastructure.
for having repositories for rpm like for .deb, check out apt4rpm...it gives you the same functionality as on debian.
furthermore, check out the opensuse buildservice (http://build.opensuse.org/) which gives you the possibility to build several binary packages from .spec or debian/rules for several different rpm and debian based distros.
have fun,
\sh
"mach" (which is the base from which mock was forked) can take .spec files as input; it's slightly broken to build RPM in Debian, but it works well under RPM systems.
What is the breakage on Debian systems?
My packages do not need that many build deps and are quite simple, so it might enough.
I think it's hilarious that people and distributions still stubbornly try to keep on using RPM.
I said "I have to use", as in "is not my choice, I am forced to do this".
Fedora Legacy closed, but many of the mirrors still exist.
I wonder for how long?
It might make sense to just mirror locally or archive on a disc or something like that.
Check out the build.rpm from the SuSE folks...it gives you what you need for having a pbuilder like infrastructure.
From the man page:
build - build SuSE Linux RPMs in a chroot environment
I forgot to say, I want a generis solution, not only for SuSE. And yes, I have checked, that utility assumes that the build system is a SuSE system.
for having repositories for rpm like for .deb, check out apt4rpm...it gives you the same functionality as on debian.
Thanks. I was under the impression that apt4rpm was only able to provide suport for apt, not for yum.
furthermore, check out the opensuse buildservice
I am not using that for several reasons:
* I wouldn't trust a third party for my package building
* I don't want to depend on an internet connection to build packages
* I don't want to depend on some third party for my package building
* there are some privacy issues involved
Post a Comment