I am trying to have get this into portage through a proxy dev (not 100% sure on dirtyepic). I will be attaching an ebuild in a couple of hours. This bug should effectively fix the bugs I will labels as dependencies later (hence the blocker label). Reproducible: Always Steps to Reproduce:
i'll try to do general review if time permits, but would appreciate help from someone more familiar with rpm for the specific bits. :)
Created attachment 129112 [details] rpm-4.4.9.ebuild Ebuild posted for any comments. Don't commit it, as I haven't fixed src_install() yet. Never imagined how nasty rpm's builds scripts were. Finally got it to compile with use flags and stuff. I stuck with simplicity for this ebuild. I still haven't gotten to src_install()...I thought I fixed everything with my locations variable, but rpm scripts are extremely stubborn. I have a few general questions: How is selinux supposed to be handled? Is making an selinux use flag appropriate? The old rpm ebuild have selinux disabled under all circumstances. How lenient are we allowed to be with forcing packages to use the libraries in portage? From what it looks, the rpm maintainers have tweaked popt and zlib, in-house to the point where Gentoo's popt and zlib are no good for rpm.
Created attachment 129165 [details] rpm-4.4.9.ebuild Here is a working ebuild. rpm compiles, runs, documentation got generated. I think this ebuild can safely be put on ~arch. Am I right to assume that ebuild is with QA warning problems cannot make it to stable until the QA warnings are fixed? Also if I have cases where some use flags are incompatible with other and I handle these cases my ewarning then die, can such a package make it to stable?
Created attachment 129167 [details] rpm-4.4.9.ebuild Did away with the --with-dmalloc and --with-efence for debug use flag...the rpm package only works with these for very minimal builds.
So, at this point, the latest ebuild should fix 153292 and 187740. I played around with rpmbuild (by rebuilding some spec files lying around); looks good. 162447 is somewhat non-critical, I'll probably end up talking to the rpm5.org devs about it. This ebuild can go ~x86 and ~amd64, but should be masked on ppc, ppc64, sparc, and s390 because I don't have the hardware to test those.
Created attachment 129266 [details] rpm-5.0.20070825.ebuild Development of rpm-5.0 is underway. There is no point in opening a new for it yet. The 5.0 ebuild is very experimental.
Created attachment 130010 [details] rpm-5.0.20070904.ebuild
hey andrey, sorry for the wait. i'll make time to look at these this weekend. i did a quick run-through and it looks good though. :) i don't know anything about selinux. i pinged the hardened team but got no response. i believe pebenito is the best person to talk to. it'd be nice if we could use the system's libs whenever possible, but i know that sometimes you can't. do you know what in-house changes have they made to zlib, db, and etc? qa warnings based on code warnings (like the warnings gcc spits out that get summarized at the end) are allowed in stable packages. usually they're harmless and in any case should be handled by upstream. incompatible USE flags are probably best handled by an ewarn and defaulting to the best option, but in some cases there really isn't a "best". Either way, i don't think there's any rule about it and many ebuilds will die on incompatible flags, so it's up to you.
(In reply to comment #8) > it'd be nice if we could use the system's libs whenever possible, but i know > that sometimes you can't. do you know what in-house changes have they made to > zlib, db, and etc? > They haven't been consistent in terms of the amount of changes they make to each of the libraries (this is before rpm-4.5/5.0 development). i.e. they've been putting all external things for rpm together, making sparse modifications for .h files, and patching and syncing the external things to new version, relevant bug fixes, etc. I can make a stronger effort in "un-hard-coding" most of their stuff, but I think it would result in unexpected bugs, and increase "maintenance cost". rpm-5.0 will be *much* nicer, as they are finally strict about defining that only things they modify significantly will be included in the rpm sources. Thanks for the feedback.
(In reply to comment #4) > Created an attachment (id=129167) [edit] > rpm-4.4.9.ebuild use debug && append-flags -g2 -ggdb && filter-flags -fomit-frame-pointer debug USE flag shouldn't control CFLAGS. # we use arch-gentoo-linux-{gnu,uclibc} tuple export CHOST="${CHOST//-pc-/-gentoo-}" export CHOST="${CHOST//-unknown-/-gentoo-}" i don't know what this is. i know it comes from the ebuild in the tree, but it doesn't seem right at all. locations="--bindir=/usr/bin \ --sbindir=/usr/sbin \ --sysconfdir=/etc \ --mandir=/usr/share/man \ --infodir=/usr/share/info \ --datadir=/usr/share \ --localstatedir=/var/lib" #--libexecdir= #--sharedstatedir= #--libdir= #--includedir= #--oldincludedir= #--datarootdir= #--localedir= #--docdir= #--htmldir= #--dvidir= #--pdfdir= #--psdir= shouldn't need any of this. it's handled by econf. emake -j1 || die "emake failed" parallel is broken? i'll see if i can patch it. chown -R rpm:rpm ${ROOT}/usr/lib/rpm chown -R rpm:rpm ${ROOT}/var/lib/rpm quote ${ROOT} otherwise looks okay.
(In reply to comment #7) > Created an attachment (id=130010) [edit] > rpm-5.0.20070904.ebuild should've looked at this one first ;) RDEPEND="gzip? (app-arch/gzip) bzip2? (app-arch/bzip2) crypt? (app-crypt/gnupg)" since gzip, bzip2, and file are in the system set we don't need to specify them as dependencies. we won't have them as USE flags either as they're always installed. everything else looks better.
> > # we use arch-gentoo-linux-{gnu,uclibc} tuple > export CHOST="${CHOST//-pc-/-gentoo-}" > export CHOST="${CHOST//-unknown-/-gentoo-}" > > i don't know what this is. i know it comes from the ebuild in the tree, but > it doesn't seem right at all. > It did not seem to hurt, so I left it there. > > emake -j1 || die "emake failed" > > parallel is broken? i'll see if i can patch it. > > Yeh, there will be a compile failure without -j1. Thanks for the feedback...posting updated ebuild in a few minutes.
Created attachment 132967 [details] rpm-4.4.9.ebuild Is the following a problem: lua package is intalled and lua USE flag is disabled. rpm's configure script notices that lua is intalled, and generates docs for it, when though it appears that --without-lua is passed to ./configure. If lua package is not installed, then there is no such issue. I will have an updated rpm5 ebuild by the end of this week.
Created attachment 132969 [details] rpm-4.4.9.ebuild Sorry for the noise. Forgot to put *all* ${ROOT}s into quotes.
(In reply to comment #13) > > Is the following a problem: > > lua package is intalled and lua USE flag is disabled. > rpm's configure script notices that lua is intalled, and generates docs for it, > when though it appears that --without-lua is passed to ./configure. > > If lua package is not installed, then there is no such issue. We call that an automagic dependency. We have a doc about it here: http://www.gentoo.org/proj/en/qa/automagic.xml I can take a look. I've been reading a bit about autotools recently so i'll see if i can come up with something.
Created attachment 133038 [details] rpm-5.0.20071008.ebuild
Created attachment 135936 [details] rpm-5.0_alpha1.ebuild First alpha version is out, ebuild attached. 5.0 final will come out in January. In the meantime there will be four weekly alpha versions followed by four weekly beta versions. I'll try to follow all of these releases and test as they mature. I've also been active on their mailing lists by notifying them of any build problems (better do this now than have to patch things later on).
Created attachment 136427 [details] rpm-5.0_alpha1.ebuild Latest alpha version.
Created attachment 136903 [details] rpm-5.0_alpha3.ebuild
Created attachment 137622 [details] rpm-5.0_alpha4.ebuild Newest alpha release.
rpm-5.0_alpha4 now in the tree
Thanks SpanKY! Should I continue dumping to new versions here?
Created attachment 138106 [details] rpm-5.0_beta1.ebuild Beta 1 just came out. I made a very slight change to the ebuild from the alpha4 version in pkg_install.
Reopening for new version bump.
that isnt how it works. file new bugs without baggage.
