Re: [gentoo-portage-dev] --nodeps faulty behaviour?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Markus Duft wrote: > Hi! > > I have a quick question: is --nodeps supposed to still merge packages in > the right order? Yes. The attached patch should fix it. Thanks for reporting. - -- Thanks, Zac -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) iEYEARECAAYFAknsPNIACgkQ/ejvha5XGaN6EQCfUWVR2U+gCrqv60uMzAssbzm0 VxUAnjsah7byJwKRO/FVoZWwr0i4kBmE =X0E7 -END PGP SIGNATURE- Index: pym/_emerge/__init__.py === --- pym/_emerge/__init__.py (revision 13376) +++ pym/_emerge/__init__.py (revision 13377) @@ -7039,6 +7039,13 @@ writemsg("\n", noiselevel=-1) scheduler_graph = self.digraph.copy() + + if '--nodeps' in self.myopts: + # Preserve the package order given on the command line. + return ([node for node in scheduler_graph \ + if isinstance(node, Package) \ + and node.operation == 'merge'], scheduler_graph) + mygraph=self.digraph.copy() # Prune "nomerge" root nodes if nothing depends on them, since # otherwise they slow down merge order calculation. Don't remove nodeps_order.patch.sig Description: Binary data
Re: [gentoo-portage-dev] --nodeps faulty behaviour?
On Mon, 2009-04-20 at 08:35 +0200, Markus Duft wrote: > Hi! > > I have a quick question: is --nodeps supposed to still merge packages in > the right order? > > my specific problem is, that when i do this: > > emerge -pv --noreplace --oneshot --nodeps \ > sys-devel/gcc-config \ > sys-devel/gcc \ > libperl perl help2man texinfo \ > "=autoconf-2.1*" "=autoconf-2.6*" "autoconf-wrapper" \ > "=automake-1.4*" "=automake-1.5*" "=automake-1.6*" \ > "=automake-1.7*" "=automake-1.8*" "automake-wrapper" \ > wget > > i get this: > > These are the packages that would be merged, in order: > > [ebuild N] sys-apps/texinfo-4.12 USE="-nls -static" 0 kB > [ebuild N] sys-devel/autoconf-2.13 0 kB > [ebuild N] sys-devel/autoconf-2.63-r1 USE="(-emacs)" 0 kB > [ebuild N] sys-devel/automake-1.4_p6 0 kB > [ebuild N] sys-devel/automake-1.5 0 kB > [ebuild N] sys-devel/automake-1.6.3 0 kB > [ebuild N] sys-devel/automake-1.7.9-r1 0 kB > [ebuild N] sys-devel/automake-1.8.5-r3 0 kB > [ebuild N] net-misc/wget-1.11.4 USE="-debug (-ipv6) -nls -socks5 > -ssl -static" 0 kB > [ebuild N] sys-devel/gcc-config-1.4.1-r00.1 0 kB > [ebuild N] sys-devel/libperl-5.8.8-r2 USE="-berkdb -debug -gdbm > -ithreads" 0 kB > [ebuild N] dev-lang/perl-5.8.8-r5 USE="-berkdb -build -debug -doc > -gdbm -ithreads -perlsuid" 0 kB > [ebuild N] sys-apps/help2man-1.36.4 USE="-nls" 0 kB > [ebuild N] sys-devel/autoconf-wrapper-6-r00.1 0 kB > [ebuild N] sys-devel/automake-wrapper-3-r1 0 kB > > > but texinfo DEPENDs on help2man - thus it fails to build. as a workaroun > i split the merges into several ones which preserve dependency order, > but i feel that portage should do it.. what do you think? > oh, damn, sorry; this is not the right portage, was in the wrong shell :) this is the right one: Portage 2.2.00.13286-prefix (!/opt/gentoo/usr/portage/profiles/prefix/windows/interix/5.2/x86, gcc-4.2.4, unavailable, 5.2 x86) = System uname: Interix-5.2-x86-32bit Timestamp of tree: Thu, 16 Apr 2009 22:02:48 + app-shells/bash: 3.2_p48-r1 dev-lang/python: 2.5.4-r2, 2.6.1-r1 sys-devel/autoconf: 2.63-r1 sys-devel/automake: 1.9.6-r2, 1.10.2-r00.1 sys-devel/binutils: 2.18-r4 sys-devel/gcc-config: 1.4.1-r00.1 sys-devel/libtool: 2.2.6a ACCEPT_KEYWORDS="~x86-interix" ... > Administrator opt $ emerge --info > Portage 2.2.00.13346-prefix (prefix/windows/interix/5.2/x86, gcc-4.2.4, > unavailable, 5.2 x86) > = > System uname: Interix-5.2-x86-32bit > Timestamp of tree: Thu, 16 Apr 2009 07:36:49 + > app-shells/bash: 3.2_p48-r1 > dev-lang/python: 2.5.4-r2, 2.6.1-r1 > sys-devel/autoconf: 2.63-r1 > sys-devel/automake: 1.9.6-r2, 1.10.2-r00.1 > sys-devel/binutils: 2.18-r4 > sys-devel/gcc-config: 1.4.1-r00.1 > sys-devel/libtool: 2.2.6a > ACCEPT_KEYWORDS="~x86-interix" > > > Cheers, Markus > >
Re: [gentoo-portage-dev] Re: does emerge verify arch compatibility when merging a binary package?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Amit Dor-Shifer wrote: > When you say ut checks CHOST/keywording, where are those definitions > stored for the binary pkg? It's appended to the tail end of the tbz2, in xpak format (see `man 5 xpak`). > I see one instance of CHOST in the 'Packages' index on the BINHOST. Is > that the variable emerge is comparing against? If not, where is it? the > tbz itself holds just the binaries. Yes, for remote packages, the Package index contains equivalent data to the actual xpak segments from the remote packages. The CHOST for individual packages is only shown in cases when it differs from the CHOST in the header of the Packages file. > Manually modifying a/m CHOST to 'ppc' didn't stop emerge from > successfully merging a package on an amd64 target (I've removed > /usr/portage/packages from target before emerging). The CHOST from your local configuration (typically from make.conf or inherited from your profile) is compared to the CHOST of the binary package. You can also use ACCEPT_CHOSTS if you want to accept more than one CHOST (see `man 5 make.conf`). - -- Thanks, Zac -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) iEYEARECAAYFAknsPqIACgkQ/ejvha5XGaNnEgCfVB8ricVhKBQY/S2g1aYLvpkT L2wAn3CtsAnFwJ0h/mArfdDJk4hMvNBD =AH2B -END PGP SIGNATURE-
Re: [gentoo-portage-dev] --nodeps faulty behaviour?
On Mon, 2009-04-20 at 02:14 -0700, Zac Medico wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Markus Duft wrote: > > Hi! > > > > I have a quick question: is --nodeps supposed to still merge packages in > > the right order? > > Yes. The attached patch should fix it. Thanks for reporting. cool thanks :) so this patch makes portage merge in the order given on the command line? this means it's the users fault if packages are in the wrong order? shouldn't portage do the same thing as with --nodeps, except that it doesn't add new packages to the merge list? don't get me wrong - i'm quite happy with beeing responsible for the order, i just imageined passing (to stay with the same example) "--nodeps texinfo help2man" which should reorder to help2man beeing before texinfo, i would guess... thoughts? Cheers, Markus > > - -- > Thanks, > Zac > -BEGIN PGP SIGNATURE- > Version: GnuPG v2.0.11 (GNU/Linux) > > iEYEARECAAYFAknsPNIACgkQ/ejvha5XGaN6EQCfUWVR2U+gCrqv60uMzAssbzm0 > VxUAnjsah7byJwKRO/FVoZWwr0i4kBmE > =X0E7 > -END PGP SIGNATURE- > plain text document attachment (nodeps_order.patch) > Index: pym/_emerge/__init__.py > === > --- pym/_emerge/__init__.py (revision 13376) > +++ pym/_emerge/__init__.py (revision 13377) > @@ -7039,6 +7039,13 @@ > writemsg("\n", noiselevel=-1) > > scheduler_graph = self.digraph.copy() > + > + if '--nodeps' in self.myopts: > + # Preserve the package order given on the command line. > + return ([node for node in scheduler_graph \ > + if isinstance(node, Package) \ > + and node.operation == 'merge'], scheduler_graph) > + > mygraph=self.digraph.copy() > # Prune "nomerge" root nodes if nothing depends on them, since > # otherwise they slow down merge order calculation. Don't remove
Re: [gentoo-portage-dev] --nodeps faulty behaviour?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Markus Duft wrote: >> cool thanks :) so this patch makes portage merge in the order given on >> the command line? this means it's the users fault if packages are in the >> wrong order? Right. >> shouldn't portage do the same thing as with --nodeps, >> except that it doesn't add new packages to the merge list? don't get me >> wrong - i'm quite happy with beeing responsible for the order, i just >> imageined passing (to stay with the same example) "--nodeps texinfo >> help2man" which should reorder to help2man beeing before texinfo, i >> would guess... thoughts? Well, what you are describing is something different from what - --nodeps is supposed to mean. The intention for --nodeps is to not account for any dependencies whatsoever. We can add a new option if you need some different behavior. - -- Thanks, Zac -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) iEYEARECAAYFAknsuVgACgkQ/ejvha5XGaO9HQCg3zIhUqMrL2pffqft/kOQdrLu z8gAoJ+ZGkWRoQ19mRnc4WTlZ0hbMNmf =STIm -END PGP SIGNATURE-