Re: [gentoo-dev] PMS EAPI 3 more or less ready
Am Sonntag, den 12.04.2009, 20:59 +0100 schrieb Ciaran McCreesh: I've got the EAPI 3 branch for PMS more or less ready: http://github.com/ciaranm/pms/tree/eapi-3 The provisional included feature list is everything that was ready before the deadline. Thanks a lot for your work. Sorry, I was quiet busy the last week with real life. Before the next Council meeting (ideally a week before, so we've got time to get the questions worked out), I'd appreciate it if every Council member could go through each item on the list below, check its description in PMS (Appendix E has a handy list of links to the relevant text, or look for the boxed labels in the margin) and provisionally mark it as one of: * critical: EAPI 3 needs to be held up until this feature is in Portage. * yes: This feature should be in EAPI 3, but can be dropped if it turns out it's going to take ages to get into Portage. * no: This feature shouldn't be in EAPI 3. * whatever: You have no strong opinion on whether this feature should be in EAPI 3. * query: You have questions about this feature, or you think parts of it need discussion, or you've found a mistake in the PMS draft. I'll try to address any queries as they come so people can update their opinions. I'd also appreciate any review of wording features from anyone else. There are probably still a few holes. Hopefully we can get a final list decided upon and provisionally approved by the next Council meeting, and then as soon as Portage is ready to go we can merge everything into PMS proper and get a signed approval tag as we did for EAPI 2. Here's the list: * PKG-PRETEND critical. * SLOT-OPERATOR-DEPS critical. * USE-DEP-DEFAULTS critical. * DEFINED-PHASES critical. * PROPERTIES critical. * SRC-INSTALL critical. * CONTROLLABLE-COMPRESS no. * DODOC critical. * DOINS critical. * ANY-USE yes. * BANNED-COMMANDS yes. * DOEXAMPLE whatever. ... with dodoc getting recursive behaviour I guess this is not really critical. If portage penalizes it's users by compressing those examples, that's their problem. * DOINCLUDE yes. * UNPACK-EXTENSIONS yes. * ECONF-OPTIONS yes. * PKG-INFO critical. * PROFILE-IUSE-INJECTION yes, but *_IMPLICIT has to be discussed. * AA yes. * KV yes. * REPLACE-VERSION-VARS critical. * S-WORKDIR-FALLBACK yes. * UNPACK-IF-COMPRESSED yes. * RDEPEND-DEPEND critical. * DIE-ON-FAILURE yes. * NONFATAL yes. Some answers to existing queries that I can remember: * DEFINED-PHASES and PROPERTIES have to be EAPI linked because of the metadata cache. * ANY-USE is already special cased in the package manager and specification. Everywhere that's using it is doing it wrong. It's possible to rewrite the dep to mean same thing using an expanded form, although it'll still be impossible to use it correctly if you do that. * ECONF-OPTIONS is very unlikely to break custom configure scripts. We already pass various weird things through econf, so any configure script that dies on unrecognised options is probably going to break anyway. No-one's managed to name a configure script that would be broken by this change that isn't already not using econf anyway. ... or using econf even if it shouldn't. signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] PMS EAPI 3 more or less ready
On Mon, 20 Apr 2009, Tiziano Müller wrote: * CONTROLLABLE-COMPRESS no. Without this we cannot get rid of the prepalldocs calls in the tree. Ulrich
Re: [gentoo-dev] PROFILE-IUSE-INJECTION implicit things (Was: PMS EAPI 3 more or less ready)
Let's see if we can keep to one thread per item here. On Mon, 20 Apr 2009 07:14:00 +0200 Tiziano Müller dev-z...@gentoo.org wrote: * PROFILE-IUSE-INJECTION yes, but *_IMPLICIT has to be discussed. There are a few suggested use cases for these: * Avoiding the need for developers to have to explicitly list ARCH in IUSE. Without implicits, ARCH will be empty and USE won't contain the arch flag name unless IUSE explicitly lists it. Some developers would rather not list arch flags explicitly. * Ditto for things like USERLAND. * People want to be able to carry on using flags like 'build' that wouldn't otherwise work. And a few related points that people might otherwise miss: * Listing something in IUSE does not have to mean it will show up in package manager output. There are special HIDDEN variables for those. * Without this whole stricter USE mess, [use(+)] dependencies are rather crippled. You can't do [linguas_en(+)] against any existing EAPI, for example. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] PROFILE-IUSE-INJECTION implicit things (Was: PMS EAPI 3 more or less ready)
Am Montag, den 20.04.2009, 13:41 +0100 schrieb Ciaran McCreesh: Let's see if we can keep to one thread per item here. On Mon, 20 Apr 2009 07:14:00 +0200 Tiziano Müller dev-z...@gentoo.org wrote: * PROFILE-IUSE-INJECTION yes, but *_IMPLICIT has to be discussed. There are a few suggested use cases for these: * Avoiding the need for developers to have to explicitly list ARCH in IUSE. Without implicits, ARCH will be empty and USE won't contain the arch flag name unless IUSE explicitly lists it. Some developers would rather not list arch flags explicitly. * Ditto for things like USERLAND. * People want to be able to carry on using flags like 'build' that wouldn't otherwise work. Why should those USE flags be different than others? The user should anyway not check the ebuild if he wants to figure out what USE flags a package supports but rather consult the PM's output (because USE flags may also come from an eclass), so the argument of hiding that info from the user is nil (and with USE_EXPAND_HIDDEN userland and arch USE flags get hidden anyway as pointed out below). So, with _IMPLICIT we would have some USE flags which don't have to be added while some will have to be added and in the end devs who use those vars only occasionally will always have to consult the specs. Instead I'd prefer to be implicit about it: the use flags you use have to be given in IUSE. One simple rule to remember... And a few related points that people might otherwise miss: * Listing something in IUSE does not have to mean it will show up in package manager output. There are special HIDDEN variables for those. * Without this whole stricter USE mess, [use(+)] dependencies are rather crippled. You can't do [linguas_en(+)] against any existing EAPI, for example. signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] PMS EAPI 3 more or less ready
On P, 2009-04-12 at 20:59 +0100, Ciaran McCreesh wrote: I've got the EAPI 3 branch for PMS more or less ready: http://github.com/ciaranm/pms/tree/eapi-3 The provisional included feature list is everything that was ready before the deadline. Before the next Council meeting (ideally a week before, so we've got time to get the questions worked out), I'd appreciate it if every Council member could go through each item on the list below, check its description in PMS (Appendix E has a handy list of links to the relevant text, or look for the boxed labels in the margin) and provisionally mark it as one of: * critical: EAPI 3 needs to be held up until this feature is in Portage. * yes: This feature should be in EAPI 3, but can be dropped if it turns out it's going to take ages to get into Portage. * no: This feature shouldn't be in EAPI 3. * whatever: You have no strong opinion on whether this feature should be in EAPI 3. * query: You have questions about this feature, or you think parts of it need discussion, or you've found a mistake in the PMS draft. I'll try to address any queries as they come so people can update their opinions. I'd also appreciate any review of wording features from anyone else. There are probably still a few holes. Hopefully we can get a final list decided upon and provisionally approved by the next Council meeting, and then as soon as Portage is ready to go we can merge everything into PMS proper and get a signed approval tag as we did for EAPI 2. Here's the list: * PKG-PRETEND critical * SLOT-OPERATOR-DEPS query. Needs discussion I can't conduct on-list today anymore (middle of night already) as I need to sit down and think this through more heavily, also in light of some recent discussion with dev-zero. Will bring to list ASAP. Mostly relates to syntax considerations. An outstanding problem to me as a package maintainer is the lack of means to know which slot the PM actually picked for the package, as some of my co-maintained packages have no use of := if it can't know which version was picked to act accordingly in src_configure. * USE-DEP-DEFAULTS critical * DEFINED-PHASES yes. critical for PKG-PRETEND * PROPERTIES yes * SRC-INSTALL query/yes; but the default src_install maybe shouldn't be doing the file exists and is greater than zero check, because dodoc in portage already does that. Maybe formalize that and leave that check for dodoc responsibility and don't bother checking twice? * CONTROLLABLE-COMPRESS yes * DODOC yes * DOINS query. Lacks specification of what correct is in must correctly handle symlinks when installing recursively, so can't judge. Yes, I know a mail thread addressed it, but that doesn't count in what goes into an approved PMS. I suppose it's mostly understood what it means, but it wouldn't hurt for a specification to be explicit. Also, would be interesting to know what sanity checks one would want to apply in the future for absolute path symlinks in case they do not start with $EPREFIX (don't honor --prefix)? Just curious for the future on this one. * ANY-USE no * BANNED-COMMANDS no for dohard whatever for dosed dohard works fine now in portage when it technically can. The wording in section 12.3.3 for dohard should be changed however to not give a guarantee but a best effort, as if when installed on the _live system_ they end up on a separate partition it is not technically possible. However a common use case can be to do it in the same directory and it should work fine then, if PM makes sure the hard link is not lost when they get potentially copied/moved around between various partition in $PORTAGE_TMPDIR, $D and $ROOT, which portage does since a few months now. This best effort support already needs to exist to handle cases like dev-util/git provided hard links in $libexec/git-core, so this is just a function to do the same in ebuilds. I already wrote about this on 9th April in the Ideas for a (fast) EAPI=3 thread, but got no replies. * DOEXAMPLE no. perhaps after a query phase might lean more towards whatever Additionally the PMS draft has a typo: newinclude As above, for doexample. Only in EAPIs listed in table 12.7 newinclude is listed twice; that one should be titled newexample * DOINCLUDE no * UNPACK-EXTENSIONS yes (query), if we are sure we can rely on the xzdec arguments and such to remain the same once released. * ECONF-OPTIONS query --disable-dependency-tracking has other implications than it being allowed to be passed to ./configure or not - such as dependency tracking being, well, disabled and the affects of that in face of any outside influences to headers used by it from the system, when compared to the case when dependency tracking is enabled. Such as when a separate (possibly parallel) install step kicks in. Olivier Crête also has an outstanding comment about a maintainer possibly not wanting that disabled in case of
Re: [gentoo-portage-dev] Re: does emerge verify arch compatibility when merging a binary package?
When you say ut checks CHOST/keywording, where are those definitions stored for the binary pkg? 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. 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). Amit Duncan wrote: Andrew Gaffney agaff...@gentoo.org posted 49eb3b9f.1050...@gentoo.org, excerpted below, on Sun, 19 Apr 2009 09:56:31 -0500: Amit Dor-Shifer wrote: E.G: would portage block an attempt to install a ppc binary on an amd64? I believe it checks the CHOST in the binpkg and compares it against the configured CHOST for the system. Doesn't it also still check keywording, at least on newer portage (I guess it was hard-masking that it didn't used to check for binpkgs, I'm not sure about keywording)? Of course it is possible to deliberately confound the keywording check by setting an incorrect ACCEPT_KEYWORDS globally or using package.keywords to do so by package.
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-
