Bug 190132 - app-arch/rpm-5.0 version bump
|
Bug#:
190132
|
Product: Gentoo Linux
|
Version: unspecified
|
Platform: All
|
|
OS/Version: Linux
|
Status: RESOLVED
|
Severity: normal
|
Priority: P2
|
|
Resolution: FIXED
|
Assigned To: maintainer-needed@gentoo.org
|
Reported By: Ma3oxuct@gmail.com
|
|
Component: Ebuilds
|
|
|
URL:
|
|
Summary: app-arch/rpm-5.0 version bump
|
|
Keywords: Tracker
|
|
Status Whiteboard:
|
|
Opened: 2007-08-25 04:26 0000
|
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 an attachment (id=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 an attachment (id=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?
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.
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] [details]
> 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] [details]
> 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 an attachment (id=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.
(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 an attachment (id=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).
rpm-5.0_alpha4 now in the tree
Thanks SpanKY!
Should I continue dumping to new versions here?
Reopening for new version bump.
that isnt how it works. file new bugs without baggage.
