Re: [gentoo-dev] My wishlist for EAPI 5
El mié, 20-06-2012 a las 23:43 +0200, Justin escribió: On 20.06.2012 22:35, Ciaran McCreesh wrote: On Wed, 20 Jun 2012 16:25:30 -0400 Richard Yao r...@gentoo.org wrote: Multilib (and/or multiarch) support The current binaries cause a great deal of pain, particularly when a user does not want to upgrade something. I had this problem with WINE and glibc because I wanted to avoid the reverse memcpy() fiasco on my systems. This situation would have been avoided entirely if the package manager supported multilib. This one's unlikely to happen unless someone's prepared to put in the work. Tommy worked a lot on this and he asked for help to bring his proposal/spec/glep into shape. We are all aware what this is all about and know that anybody who is using multilib would benefit. Can't you simply work with him together to get it into what you expect it to be instead of pointing out that it isn't? Also, if I remember correctly, Tommy asked for this some months ago, you asked for what he sent some days ago and now you require more and more work to delay things to be implemented. I also don't understand why Gentoo is forced to stick with old ways of doing things until new EAPI is approved while Exherbo is free to implement and use things like that special way of handling DEPENDENCIES without waiting for any EAPI to be accepted... or maybe I am wrong and people is able to use any PM manager compliant with EAPI on exherbo without issues? signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] My wishlist for EAPI 5
On Wed, 20 Jun 2012 23:43:36 +0200 Justin j...@gentoo.org wrote: On 20.06.2012 22:35, Ciaran McCreesh wrote: On Wed, 20 Jun 2012 16:25:30 -0400 Richard Yao r...@gentoo.org wrote: Multilib (and/or multiarch) support The current binaries cause a great deal of pain, particularly when a user does not want to upgrade something. I had this problem with WINE and glibc because I wanted to avoid the reverse memcpy() fiasco on my systems. This situation would have been avoided entirely if the package manager supported multilib. This one's unlikely to happen unless someone's prepared to put in the work. Tommy worked a lot on this and he asked for help to bring his proposal/spec/glep into shape. We are all aware what this is all about and know that anybody who is using multilib would benefit. Can't you simply work with him together to get it into what you expect it to be instead of pointing out that it isn't? In order to do that, it would have to get to the stage where I understood exactly what changes are needed and why. I'm not convinced *anyone* understands that yet. Writing PMS patches, at least to the level that we can review them, is only difficult if you don't know what you want changed or why. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] My wishlist for EAPI 5
On Thu, 21 Jun 2012 08:08:55 +0200 Pacho Ramos pa...@gentoo.org wrote: Also, if I remember correctly, Tommy asked for this some months ago, you asked for what he sent some days ago and now you require more and more work to delay things to be implemented. I still haven't seen a clear description of exactly what should be changed and why. I've also not seen a description of exactly what problem is being solved, nor a discussion of the relative merits of implementing a solution to whatever that problem is. All I've seen is a mess of code that gets it working in Portage (which isn't the same as implements it for Portage) and a big wall of text that contains lots that no-one needs to know and little of what's important. This needs to go through the GLEP process, and it needs a PMS diff. In case you're not aware, the first time Gentoo did multilib, it was done as a series of random changes to Portage that no-one really thought through or understood. As you can see, that didn't work... I also don't understand why Gentoo is forced to stick with old ways of doing things until new EAPI is approved That's not what's going on here. The issue is that there might be one person who understands what the new way of doing things, but he hasn't told us what he thinks that is. Once we get a proper explanation, getting an EAPI out doesn't take long. The main problem here isn't even EAPI related. Ebuild developers don't even know what they'll be expected, required or able to do for multilib. while Exherbo is free to implement and use things like that special way of handling DEPENDENCIES without waiting for any EAPI to be accepted... The DEPENDENCIES proposal predates Exherbo. Gentoo originally didn't have it because Portage couldn't implement it. Now it doesn't have it because it's too controversial to get it approved. Exherbo does have it because it was carefully discussed, compared to alternatives, planned out, tested, accepted by the expendable figurehead, and then rolled out. or maybe I am wrong and people is able to use any PM manager compliant with EAPI on exherbo without issues? If anyone ever manages to come up with another package mangler that can get close to implementing what Exherbo needs, then sure. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] My wishlist for EAPI 5
On 21/06/12 08:41, Ciaran McCreesh wrote: On Wed, 20 Jun 2012 23:43:36 +0200 Justin j...@gentoo.org wrote: On 20.06.2012 22:35, Ciaran McCreesh wrote: On Wed, 20 Jun 2012 16:25:30 -0400 Richard Yao r...@gentoo.org wrote: Multilib (and/or multiarch) support The current binaries cause a great deal of pain, particularly when a user does not want to upgrade something. I had this problem with WINE and glibc because I wanted to avoid the reverse memcpy() fiasco on my systems. This situation would have been avoided entirely if the package manager supported multilib. This one's unlikely to happen unless someone's prepared to put in the work. Tommy worked a lot on this and he asked for help to bring his proposal/spec/glep into shape. We are all aware what this is all about and know that anybody who is using multilib would benefit. Can't you simply work with him together to get it into what you expect it to be instead of pointing out that it isn't? In order to do that, it would have to get to the stage where I understood exactly what changes are needed and why. I'm not convinced *anyone* understands that yet. Writing PMS patches, at least to the level that we can review them, is only difficult if you don't know what you want changed or why. He wants to deprecate the app-emulation/emul-linux-x86-* packages and build it if needed directly from normal ebuilds through the package manager. This was stated a couple of times and is not hard to understand, even without PMS patches, GLEPS and so. *anyone* understands that there are cases when the x86 libs are needed and every gentoo package maintainer should understand, that letting the user build their own x86 libs is what we want in ideal case. There is a working implementation as a branch of portage for some time now and people work on it. So two basic things are there, the need and the idea of a working solution. This also means, that people need to have an idea of what is real problem. (And if not, it was asked a couple of times for discussion) Won't it be a good thing, if you instead of showing all of us, that you can tell where people fail to present something in the right way, help and guide them to write the necessary things like PMS patches, GLEPs etc., so that we can proceed in an efficient way? justin signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] My wishlist for EAPI 5
El jue, 21-06-2012 a las 08:00 +0100, Ciaran McCreesh escribió: On Thu, 21 Jun 2012 08:08:55 +0200 Pacho Ramos pa...@gentoo.org wrote: Also, if I remember correctly, Tommy asked for this some months ago, you asked for what he sent some days ago and now you require more and more work to delay things to be implemented. I still haven't seen a clear description of exactly what should be changed and why. I've also not seen a description of exactly what problem is being solved, nor a discussion of the relative merits of implementing a solution to whatever that problem is. All I've seen is a mess of code that gets it working in Portage (which isn't the same as implements it for Portage) and a big wall of text that contains lots that no-one needs to know and little of what's important. This needs to go through the GLEP process, and it needs a PMS diff. In case you're not aware, the first time Gentoo did multilib, it was done as a series of random changes to Portage that no-one really thought through or understood. As you can see, that didn't work... Then, looks clear to me that the way to get things approved in newer EAPIs is not clear enough as looks like a lot of devs (like me) don't know them (for example, when things to be added to EAPI need also a GLEP and a PMS diff, also the needing to get an implementation for any package manager). Is this documented in some place? If not, I think it should be documented and, of course, it should be done by PMS team if possible as they clearly know what they expect to get for approval if needed since, I discussed some days ago, council will simply accept some specific features to be included in next eapi once they are accepted by PMS team. That way, we could save a lot of time, know what steps are pending, try to ask for help for some specific steps and, finally, get it discussed in PMS people providing all what is needed. I also don't understand why Gentoo is forced to stick with old ways of doing things until new EAPI is approved That's not what's going on here. The issue is that there might be one person who understands what the new way of doing things, but he hasn't told us what he thinks that is. Once we get a proper explanation, getting an EAPI out doesn't take long. But you must confess that old problems like multilib support, force package rebuilding or optional dep support are still pending while still needing and, the problem with the way things are discussed now is that some day anybody arises the problem again, other one demands more things to be provided, a discussion starts, the problem gets stalled... one year later the same problem arises again. There is clearly a lack of information to the rest of developers about how to propose anything to get accepted for next EAPI. The main problem here isn't even EAPI related. Ebuild developers don't even know what they'll be expected, required or able to do for multilib. while Exherbo is free to implement and use things like that special way of handling DEPENDENCIES without waiting for any EAPI to be accepted... The DEPENDENCIES proposal predates Exherbo. Gentoo originally didn't have it because Portage couldn't implement it. Now it doesn't have it because it's too controversial to get it approved. It was only a example, but thanks for the info :) Exherbo does have it because it was carefully discussed, compared to alternatives, planned out, tested, accepted by the expendable figurehead, and then rolled out. or maybe I am wrong and people is able to use any PM manager compliant with EAPI on exherbo without issues? If anyone ever manages to come up with another package mangler that can get close to implementing what Exherbo needs, then sure. Then, you accept exherbo is not forced to *only* follow EAPI while you force Gentoo and portage to only support features approved in an EAPI? signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags
On Wed, 20 Jun 2012 18:24:33 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Wed, 20 Jun 2012 19:11:33 +0200 hasufell hasuf...@gentoo.org wrote: On 06/20/2012 07:07 PM, Michał Górny wrote: Please read the rationale. Again. The whole thing. Three times. Please read my suggestions. Again. The whole thing. Three times. Can we all agree to just stop this and just restrict the arguing to being between SDEPEND and DEPENDENCIES? Cheers. You just volunteered to write portage patches. Cheers. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags
On Thu, 21 Jun 2012 09:29:49 +0200 Michał Górny mgo...@gentoo.org wrote: On Wed, 20 Jun 2012 18:24:33 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Wed, 20 Jun 2012 19:11:33 +0200 hasufell hasuf...@gentoo.org wrote: On 06/20/2012 07:07 PM, Michał Górny wrote: Please read the rationale. Again. The whole thing. Three times. Please read my suggestions. Again. The whole thing. Three times. Can we all agree to just stop this and just restrict the arguing to being between SDEPEND and DEPENDENCIES? Cheers. You just volunteered to write portage patches. Cheers. Both were already implemented in Paludis, if you're looking for a reference implementation to try it out. There are also examples of use of SDEPEND in the old kdebuilds, and of DEPENDENCIES in Exherbo. I can give you a small patch to turn SDEPEND on for an EAPI if you like (it's just a one line addition to the EAPI definition file). -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags
On Thu, 21 Jun 2012 08:30:24 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Thu, 21 Jun 2012 09:29:49 +0200 Michał Górny mgo...@gentoo.org wrote: On Wed, 20 Jun 2012 18:24:33 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Wed, 20 Jun 2012 19:11:33 +0200 hasufell hasuf...@gentoo.org wrote: On 06/20/2012 07:07 PM, Michał Górny wrote: Please read the rationale. Again. The whole thing. Three times. Please read my suggestions. Again. The whole thing. Three times. Can we all agree to just stop this and just restrict the arguing to being between SDEPEND and DEPENDENCIES? Cheers. You just volunteered to write portage patches. Cheers. Both were already implemented in Paludis, if you're looking for a reference implementation to try it out. There are also examples of use of SDEPEND in the old kdebuilds, and of DEPENDENCIES in Exherbo. I can give you a small patch to turn SDEPEND on for an EAPI if you like (it's just a one line addition to the EAPI definition file). Wait, did I just write to exherbo ml? No, don't think so. 'Implemented in Paludis' doesn't work here. We're discussing Gentoo features, and official package manager in Gentoo is portage. If you don't believe me, check out the docs. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] My wishlist for EAPI 5
On Thu, 21 Jun 2012 09:25:10 +0200 Pacho Ramos pa...@gentoo.org wrote: Then, looks clear to me that the way to get things approved in newer EAPIs is not clear enough as looks like a lot of devs (like me) don't know them (for example, when things to be added to EAPI need also a GLEP and a PMS diff, also the needing to get an implementation for any package manager). That's very much a judgement call. If a feature is easy, low impact and uncontroversial, you can ask for it on IRC, the mailing lists or bugzilla, and chances are someone will do all the work for you. If it's a big feature with broad impact requiring lots of changes, you need to do however much work is necessary such that a) the people working on PMS understand it well enough to document it, b) developers understand it well enough to know what it involves for them, c) the Council can compare and contrast it with other proposals, and d) it can be implemented. The implement it in a package manager thing is because of what happened with REQUIRED_USE. It hadn't been implemented previously, and as it turns out it has some fairly hefty usability issues. I also don't understand why Gentoo is forced to stick with old ways of doing things until new EAPI is approved That's not what's going on here. The issue is that there might be one person who understands what the new way of doing things, but he hasn't told us what he thinks that is. Once we get a proper explanation, getting an EAPI out doesn't take long. But you must confess that old problems like multilib support, force package rebuilding or optional dep support are still pending while still needing and, the problem with the way things are discussed now is that some day anybody arises the problem again, other one demands more things to be provided, a discussion starts, the problem gets stalled... one year later the same problem arises again. There is clearly a lack of information to the rest of developers about how to propose anything to get accepted for next EAPI. The reason those are still pending is because no-one knows what the *problem* is, let alone the solution. That's not an EAPI issue, it's a developers saying I want a flying unicorn! issue. Then, you accept exherbo is not forced to *only* follow EAPI while you force Gentoo and portage to only support features approved in an EAPI? I think you have a severe misunderstanding of what the EAPI process is about here... It's not about forcing anything. The point of the EAPI process is to allow Gentoo to roll things out without requiring developers to rewrite all their ebuilds every few months (which happens on Exherbo, incidentally), and without breaking user systems. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in x11-misc/lightdm: lightdm-1.2.2-r2.ebuild ChangeLog
On 06/21/2012 10:37 AM, Ben de Groot (yngwin) wrote: yngwin 12/06/21 07:37:15 Modified: lightdm-1.2.2-r2.ebuild ChangeLog Log: Re-tidy. Restore glib slot. Drop unnecessary gobject-introspection minimal version (there is nothing lower in tree). Restore useful comments. There is no glib3 and all the commands are self-explanatory. And users might still have older gobject-introspection installed, with nothing forcing the upgrade now. I consider this a regression (in every regard) and will just do the same changes again with the next fixes (Portage version: 2.2.0_alpha110/cvs/Linux x86_64) Revision ChangesPath 1.2 x11-misc/lightdm/lightdm-1.2.2-r2.ebuild file : http://sources.gentoo.org/viewvc.cgi/gentoo-x86/x11-misc/lightdm/lightdm-1.2.2-r2.ebuild?rev=1.2view=markup plain: http://sources.gentoo.org/viewvc.cgi/gentoo-x86/x11-misc/lightdm/lightdm-1.2.2-r2.ebuild?rev=1.2content-type=text/plain diff : http://sources.gentoo.org/viewvc.cgi/gentoo-x86/x11-misc/lightdm/lightdm-1.2.2-r2.ebuild?r1=1.1r2=1.2 Index: lightdm-1.2.2-r2.ebuild === RCS file: /var/cvsroot/gentoo-x86/x11-misc/lightdm/lightdm-1.2.2-r2.ebuild,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- lightdm-1.2.2-r2.ebuild 20 Jun 2012 04:58:41 - 1.1 +++ lightdm-1.2.2-r2.ebuild 21 Jun 2012 07:37:15 - 1.2 @@ -1,6 +1,6 @@ # Copyright 1999-2012 Gentoo Foundation # Distributed under the terms of the GNU General Public License v2 -# $Header: /var/cvsroot/gentoo-x86/x11-misc/lightdm/lightdm-1.2.2-r2.ebuild,v 1.1 2012/06/20 04:58:41 ssuominen Exp $ +# $Header: /var/cvsroot/gentoo-x86/x11-misc/lightdm/lightdm-1.2.2-r2.ebuild,v 1.2 2012/06/21 07:37:15 yngwin Exp $ EAPI=4 inherit autotools eutils pam @@ -15,18 +15,16 @@ KEYWORDS=~amd64 ~x86 IUSE=+introspection qt4 -COMMON_DEPEND==dev-libs/glib-2 +COMMON_DEPEND=dev-libs/glib:2 dev-libs/libxml2 sys-apps/accountsservice virtual/pam x11-libs/libX11 =x11-libs/libxklavier-5 - introspection? ( =dev-libs/gobject-introspection-1 ) - qt4? ( - x11-libs/qt-core:4 + introspection? ( dev-libs/gobject-introspection ) + qt4? ( x11-libs/qt-core:4 x11-libs/qt-dbus:4 - x11-libs/qt-gui:4 - ) + x11-libs/qt-gui:4 ) RDEPEND=${COMMON_DEPEND} =sys-auth/pambase-20101024-r2 DEPEND=${COMMON_DEPEND} @@ -36,7 +34,7 @@ sys-devel/gettext virtual/pkgconfig -DOCS=NEWS +DOCS=( NEWS ) src_prepare() { sed -i -e 's:getgroups:lightdm_:' tests/src/libsystem.c || die #412369 @@ -54,18 +52,18 @@ } src_configure() { + # Set default values if global vars unset local _greeter _session _user _greeter=${LIGHTDM_GREETER:=lightdm-gtk-greeter} _session=${LIGHTDM_SESSION:=gnome} _user=${LIGHTDM_USER:=root} - + # Let user know how lightdm is configured einfo Gentoo configuration einfo Default greeter: ${_greeter} einfo Default session: ${_session} einfo Greeter user: ${_user} - econf \ - --localstatedir=/var \ + econf --localstatedir=/var \ --disable-static \ $(use_enable introspection) \ $(use_enable qt4 liblightdm-qt) \ @@ -78,15 +76,17 @@ src_install() { default + # Install missing files insinto /etc/${PN} doins data/{${PN},users,keys}.conf - doins ${FILESDIR}/Xsession fperms +x /etc/${PN}/Xsession + # Remove unnecessary files prune_libtool_files --all rm -rf ${ED}/etc/init + # Install proper pam files pamd_mimic system-local-login ${PN} auth account session pamd_mimic system-local-login ${PN}-autologin auth account session } 1.43 x11-misc/lightdm/ChangeLog file : http://sources.gentoo.org/viewvc.cgi/gentoo-x86/x11-misc/lightdm/ChangeLog?rev=1.43view=markup plain: http://sources.gentoo.org/viewvc.cgi/gentoo-x86/x11-misc/lightdm/ChangeLog?rev=1.43content-type=text/plain diff : http://sources.gentoo.org/viewvc.cgi/gentoo-x86/x11-misc/lightdm/ChangeLog?r1=1.42r2=1.43 Index: ChangeLog === RCS file: /var/cvsroot/gentoo-x86/x11-misc/lightdm/ChangeLog,v retrieving revision 1.42 retrieving revision 1.43 diff -u -r1.42 -r1.43 --- ChangeLog 20 Jun 2012 04:58:41 - 1.42 +++ ChangeLog 21 Jun 2012 07:37:15 - 1.43 @@ -1,6 +1,10 @@ # ChangeLog for x11-misc/lightdm # Copyright 1999-2012 Gentoo Foundation; Distributed under the GPL v2 -# $Header: /var/cvsroot/gentoo-x86/x11-misc/lightdm/ChangeLog,v 1.42 2012/06/20 04:58:41 ssuominen Exp $ +# $Header: /var/cvsroot/gentoo-x86/x11-misc/lightdm/ChangeLog,v 1.43 2012/06/21 07:37:15 yngwin Exp $ + + 21
Re: [gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags
On Thu, 21 Jun 2012 09:42:36 +0200 Michał Górny mgo...@gentoo.org wrote: You just volunteered to write portage patches. Cheers. Both were already implemented in Paludis, if you're looking for a reference implementation to try it out. There are also examples of use of SDEPEND in the old kdebuilds, and of DEPENDENCIES in Exherbo. I can give you a small patch to turn SDEPEND on for an EAPI if you like (it's just a one line addition to the EAPI definition file). Wait, did I just write to exherbo ml? No, don't think so. 'Implemented in Paludis' doesn't work here. We're discussing Gentoo features, and official package manager in Gentoo is portage. If you don't believe me, check out the docs. And since when was Implemented in Portage a requirement for an EAPI feature? The implementation requirement is to avoid REQUIRED_USE-like screwups. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Re: Killing UEFI Secure Boot
Richard Yao posted on Wed, 20 Jun 2012 18:16:23 -0400 as excerpted: 3. How does getting a x86 system to boot differ from getting a MIPS system or ARM system to boot? Does it only work because the vendors made it work or is x86 fundamentally harder? I can answer this one. x86 is harder at the bootloader stage, but in turn easier, or perhaps simply different, at the kernel and kernel device interface level. Consider, most MIPS and ARM systems ship with a specific set of basic devices, configured to use specific IO addresses, IRQs, etc, and that's it, at least to get up and running (USB devices, etc, may be able to be plugged in, but they're not normally needed for boot). If you've been keeping up with the kernel (say via LWN, etc), this has been one of the big deals with the ARM tree recently, as until now each board had its own hard-coded kernel config directly in the tree, and it was getting unmanageable. They're switching to device tree, etc, allowing the boot loader to feed the kernel a file with this information at boot time, thus allowing a whole bunch of different boards to boot off the same shipped kernel, while at the same time getting the explosion of individual board files out of the kernel tree. This is a BIG deal on ARM and similar embedded archs, but doesn't affect x86 (either 32-bit or 64-bit) at all. Meanwhile, on x86, the system must be prepared for end-user switch-out of pretty much everything. memory, storage (consider floppy, hard drive, optical disk either direct or el-torito, USB stick, etc, all bootable and all end-user changable!), even quantity and speed of CPUs, and the firmware BIOS (or replacement) must cope with that and be able to boot off it. Even back in the 386 era when everything was jumper-configured, users could still change pretty much everything out, other than the mobo itself. Now days, it's even MORE complex, as most of these devices can be configured in dozens or hundreds of mode combinations via plug-n- pray, and they often don't /have/ a default -- they **MUST** be so configured in ordered to be operable for the intended use. Sure, the BIOS CAN leave some of it for the kernel to do, but other bits, not so much, as otherwise, how does the kernel even get loaded -- the BIOS must pick one of the many boot options, configure it (as well as the CPU and the system between storage and the CPU, storage chipset, memory, etc) at least well enough to read in the boot loader and/or kernel. None of that's necessary on ARM, etc, because (pretty much) everything there's a totally arbitrary-as-shipped config, nothing to dynamically negotiate and get working before the kernel or secondary bootloader (after the BIOS) can even work! -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
[gentoo-dev] Re: My wishlist for EAPI 5
Richard Yao posted on Wed, 20 Jun 2012 16:50:33 -0400 as excerpted: On 06/20/2012 04:35 PM, Ciaran McCreesh wrote: On Wed, 20 Jun 2012 16:25:30 -0400 Richard Yao r...@gentoo.org wrote: POSIX Shell compliance So far as I know, every PM relies heavily upon bash anyway (and can't easily be made not to), so even if developers would accept having to rewrite all their eclasses, it still wouldn't remove the dep. Lets address POSIX compliance in the ebuilds first. Then we can deal with the package managers. Additionally, this is extremely unlikely because a number of developers insist on bash, to the extent that it would likely split gentoo in half if this were to be forced. It wouldn't pass council. It's unlikely to even /get/ to council. Openrc could move to POSIX shell because its primary dev at the time wanted it that way and it's only a single package. However, even then, doing it was controversial enough that said developer ended up leaving gentoo in-part over that, tho he did continue to develop openrc as a gentoo hosted project for quite some years. Now you're talking trying to do it for /every/ (well, almost every) package, thus touching every single gentoo dev. It's just not going to happen in even the medium term (say for argument APIs 5-7ish), let alone be something practical enough to implement, soon enough (even if everyone agreed on the general idea, they don't), to be anything like conceivable for EAPI5. So just let that one be. It's simply not worth tilting at that windmill. (Arguably, multi-arch, while practical and actually working at least with portage in an overlay, fails that last bit as well. If it was pushed, perhaps for EAPI6 or 7, but it's just not practical to consider it for EAPI5... unless you want to wait 3-5 years for EAPI5!) -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in x11-misc/lightdm: lightdm-1.2.2-r2.ebuild ChangeLog
On 21 June 2012 15:39, Samuli Suominen ssuomi...@gentoo.org wrote: On 06/21/2012 10:37 AM, Ben de Groot (yngwin) wrote: yngwin 12/06/21 07:37:15 Modified: lightdm-1.2.2-r2.ebuild ChangeLog Log: Re-tidy. Restore glib slot. Drop unnecessary gobject-introspection minimal version (there is nothing lower in tree). Restore useful comments. There is no glib3 Since glib is slotted, we specified the slot. There was no good reason for you to change that. Besides, it is conceivable there will be a glib-3 in the future. Using the slot is more precise and more likely to be future-proof. and all the commands are self-explanatory. And what's wrong with leaving the comments in place, which the maintainers put there for a reason? In my opinion it is good practice to document why you are doing things, to make sure maintainers after us will understand -- they might not be as experienced. And users might still have older gobject-introspection installed, with nothing forcing the upgrade now. Regular maintenance should take care of that. We are not in the habit of specifying minimal versions for all dependencies. I consider this a regression (in every regard) and will just do the same changes again with the next fixes Please don't fix things that aren't broken. If you think they are broken, then make sure it is documented in the proper places (such as devmanual) before barging in and changing the way the maintainers chose to do things. (Portage version: 2.2.0_alpha110/cvs/Linux x86_64) Revision Changes Path 1.2 x11-misc/lightdm/lightdm-1.2.2-r2.ebuild file : http://sources.gentoo.org/viewvc.cgi/gentoo-x86/x11-misc/lightdm/lightdm-1.2.2-r2.ebuild?rev=1.2view=markup plain: http://sources.gentoo.org/viewvc.cgi/gentoo-x86/x11-misc/lightdm/lightdm-1.2.2-r2.ebuild?rev=1.2content-type=text/plain diff : http://sources.gentoo.org/viewvc.cgi/gentoo-x86/x11-misc/lightdm/lightdm-1.2.2-r2.ebuild?r1=1.1r2=1.2 Index: lightdm-1.2.2-r2.ebuild === RCS file: /var/cvsroot/gentoo-x86/x11-misc/lightdm/lightdm-1.2.2-r2.ebuild,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- lightdm-1.2.2-r2.ebuild 20 Jun 2012 04:58:41 - 1.1 +++ lightdm-1.2.2-r2.ebuild 21 Jun 2012 07:37:15 - 1.2 @@ -1,6 +1,6 @@ # Copyright 1999-2012 Gentoo Foundation # Distributed under the terms of the GNU General Public License v2 -# $Header: /var/cvsroot/gentoo-x86/x11-misc/lightdm/lightdm-1.2.2-r2.ebuild,v 1.1 2012/06/20 04:58:41 ssuominen Exp $ +# $Header: /var/cvsroot/gentoo-x86/x11-misc/lightdm/lightdm-1.2.2-r2.ebuild,v 1.2 2012/06/21 07:37:15 yngwin Exp $ EAPI=4 inherit autotools eutils pam @@ -15,18 +15,16 @@ KEYWORDS=~amd64 ~x86 IUSE=+introspection qt4 -COMMON_DEPEND==dev-libs/glib-2 +COMMON_DEPEND=dev-libs/glib:2 dev-libs/libxml2 sys-apps/accountsservice virtual/pam x11-libs/libX11 =x11-libs/libxklavier-5 - introspection? ( =dev-libs/gobject-introspection-1 ) - qt4? ( - x11-libs/qt-core:4 + introspection? ( dev-libs/gobject-introspection ) + qt4? ( x11-libs/qt-core:4 x11-libs/qt-dbus:4 - x11-libs/qt-gui:4 - ) + x11-libs/qt-gui:4 ) RDEPEND=${COMMON_DEPEND} =sys-auth/pambase-20101024-r2 DEPEND=${COMMON_DEPEND} @@ -36,7 +34,7 @@ sys-devel/gettext virtual/pkgconfig -DOCS=NEWS +DOCS=( NEWS ) src_prepare() { sed -i -e 's:getgroups:lightdm_:' tests/src/libsystem.c || die #412369 @@ -54,18 +52,18 @@ } src_configure() { + # Set default values if global vars unset local _greeter _session _user _greeter=${LIGHTDM_GREETER:=lightdm-gtk-greeter} _session=${LIGHTDM_SESSION:=gnome} _user=${LIGHTDM_USER:=root} - + # Let user know how lightdm is configured einfo Gentoo configuration einfo Default greeter: ${_greeter} einfo Default session: ${_session} einfo Greeter user: ${_user} - econf \ - --localstatedir=/var \ + econf --localstatedir=/var \ --disable-static \ $(use_enable introspection) \ $(use_enable qt4 liblightdm-qt) \ @@ -78,15 +76,17 @@ src_install() { default + # Install missing files insinto /etc/${PN} doins data/{${PN},users,keys}.conf - doins ${FILESDIR}/Xsession fperms +x /etc/${PN}/Xsession + # Remove unnecessary files prune_libtool_files --all rm -rf ${ED}/etc/init + # Install proper pam files pamd_mimic system-local-login ${PN} auth account session pamd_mimic system-local-login ${PN}-autologin auth account session } 1.43 x11-misc/lightdm/ChangeLog file :
Re: [gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags
On Thu, 21 Jun 2012 08:41:23 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Thu, 21 Jun 2012 09:42:36 +0200 Michał Górny mgo...@gentoo.org wrote: You just volunteered to write portage patches. Cheers. Both were already implemented in Paludis, if you're looking for a reference implementation to try it out. There are also examples of use of SDEPEND in the old kdebuilds, and of DEPENDENCIES in Exherbo. I can give you a small patch to turn SDEPEND on for an EAPI if you like (it's just a one line addition to the EAPI definition file). Wait, did I just write to exherbo ml? No, don't think so. 'Implemented in Paludis' doesn't work here. We're discussing Gentoo features, and official package manager in Gentoo is portage. If you don't believe me, check out the docs. And since when was Implemented in Portage a requirement for an EAPI feature? Remember EAPI4 and features which had reference implementation not in portage? -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags
On Thu, 21 Jun 2012 10:54:19 +0200 Michał Górny mgo...@gentoo.org wrote: And since when was Implemented in Portage a requirement for an EAPI feature? Remember EAPI4 and features which had reference implementation not in portage? Actually, yes, since that was most of them. Nearly all of them got implemented quickly. Our policy on this has always been ask Zac whether he thinks they're reasonably quick to implement. But you know this, so kindly keep your disruption to places where you're right. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in x11-misc/lightdm: lightdm-1.2.2-r2.ebuild ChangeLog
On 06/21/2012 11:42 AM, Ben de Groot wrote: Please don't fix things that aren't broken. ditto :)
Re: [gentoo-dev] Re: My wishlist for EAPI 5
On 06/21/2012 04:29 AM, Duncan wrote: Richard Yao posted on Wed, 20 Jun 2012 16:50:33 -0400 as excerpted: On 06/20/2012 04:35 PM, Ciaran McCreesh wrote: On Wed, 20 Jun 2012 16:25:30 -0400 Richard Yao r...@gentoo.org wrote: POSIX Shell compliance So far as I know, every PM relies heavily upon bash anyway (and can't easily be made not to), so even if developers would accept having to rewrite all their eclasses, it still wouldn't remove the dep. Lets address POSIX compliance in the ebuilds first. Then we can deal with the package managers. Additionally, this is extremely unlikely because a number of developers insist on bash, to the extent that it would likely split gentoo in half if this were to be forced. It wouldn't pass council. It's unlikely to even /get/ to council. Openrc could move to POSIX shell because its primary dev at the time wanted it that way and it's only a single package. However, even then, doing it was controversial enough that said developer ended up leaving gentoo in-part over that, tho he did continue to develop openrc as a gentoo hosted project for quite some years. Now you're talking trying to do it for /every/ (well, almost every) package, thus touching every single gentoo dev. It's just not going to happen in even the medium term (say for argument APIs 5-7ish), let alone be something practical enough to implement, soon enough (even if everyone agreed on the general idea, they don't), to be anything like conceivable for EAPI5. So just let that one be. It's simply not worth tilting at that windmill. (Arguably, multi-arch, while practical and actually working at least with portage in an overlay, fails that last bit as well. If it was pushed, perhaps for EAPI6 or 7, but it's just not practical to consider it for EAPI5... unless you want to wait 3-5 years for EAPI5!) It is just a wish list. Anyway, people need to decide on what they want from a new EAPI before one is made. Once they decide, it should be possible to work out the details.
Re: [gentoo-dev] My wishlist for EAPI 5
On Thu, Jun 21, 2012 at 9:25 AM, Pacho Ramos pa...@gentoo.org wrote: El jue, 21-06-2012 a las 08:00 +0100, Ciaran McCreesh escribió: On Thu, 21 Jun 2012 08:08:55 +0200 Pacho Ramos pa...@gentoo.org wrote: Also, if I remember correctly, Tommy asked for this some months ago, you asked for what he sent some days ago and now you require more and more work to delay things to be implemented. I still haven't seen a clear description of exactly what should be changed and why. I've also not seen a description of exactly what problem is being solved, nor a discussion of the relative merits of implementing a solution to whatever that problem is. All I've seen is a mess of code that gets it working in Portage (which isn't the same as implements it for Portage) and a big wall of text that contains lots that no-one needs to know and little of what's important. This needs to go through the GLEP process, and it needs a PMS diff. In case you're not aware, the first time Gentoo did multilib, it was done as a series of random changes to Portage that no-one really thought through or understood. As you can see, that didn't work... Then, looks clear to me that the way to get things approved in newer EAPIs is not clear enough as looks like a lot of devs (like me) don't know them (for example, when things to be added to EAPI need also a GLEP and a PMS diff, also the needing to get an implementation for any package manager). Is this documented in some place? If not, I think it should be documented and, of course, it should be done by PMS team if possible as they clearly know what they expect to get for approval if needed since, I discussed some days ago, council will simply accept some specific features to be included in next eapi once they are accepted by PMS team. That way, we could save a lot of time, know what steps are pending, try to ask for help for some specific steps and, finally, get it discussed in PMS people providing all what is needed. I also don't understand why Gentoo is forced to stick with old ways of doing things until new EAPI is approved That's not what's going on here. The issue is that there might be one person who understands what the new way of doing things, but he hasn't told us what he thinks that is. Once we get a proper explanation, getting an EAPI out doesn't take long. But you must confess that old problems like multilib support, force package rebuilding or optional dep support are still pending while still needing and, the problem with the way things are discussed now is that some day anybody arises the problem again, other one demands more things to be provided, a discussion starts, the problem gets stalled... one year later the same problem arises again. There is clearly a lack of information to the rest of developers about how to propose anything to get accepted for next EAPI. I'm not following you here. 1) Usually features need a reference implementation. 2) For portage, there are like 3-5 people who know portage well enough to write that for you. 3) You generally have to convince them to do it before you can move forward. 4) Most features never even get a reference implementation. There is this vague idea that you can just propose something; get consensus on the ML, everyone goes to implement it, and then it works just as designed. That is usually called the 'waterfall' model and its really hard to do correctly. What I imagine the process is: 1) Submit an idea to the ML; you just need feedback (not consensus, which is likely impossible for non-trivial ideas.) 1.1) Your idea could be a GLEP, but I don't think a GLEP is strictly required. 2) Take feedback from step one and make an initial implementation. You will likely find some assumptions in your 'design' from step one were wrong, as well as other implementation issues (UI, performance, etc.) 3) Modify your idea to address the problems in 2. 4) Modify your implementation to address the problems in 2. 5) Repeat steps 2-4 a few times until you have solved all the 'big' problems. 6) Submit a diff to PMS outlining how the package manager behavior is changed by your feature. This generally needs to be specific enough so that other package manager authors can implement the feature. 7) Submit a devmanual patch telling users how to use the feature. Most people fail at step two; usually because they try to get 'consensus' at step one, which is stupid and a waste of time. There are a few hundred people on this list; we will never all agree, on basically anything. So take the feedback people give you and do something with it. The main problem here isn't even EAPI related. Ebuild developers don't even know what they'll be expected, required or able to do for multilib. while Exherbo is free to implement and use things like that special way of handling DEPENDENCIES without waiting for any EAPI to be accepted... The DEPENDENCIES proposal predates Exherbo. Gentoo originally didn't
Re: [gentoo-dev] Re: Killing UEFI Secure Boot
On 06/21/2012 04:08 AM, Duncan wrote: Richard Yao posted on Wed, 20 Jun 2012 18:16:23 -0400 as excerpted: 3. How does getting a x86 system to boot differ from getting a MIPS system or ARM system to boot? Does it only work because the vendors made it work or is x86 fundamentally harder? I can answer this one. x86 is harder at the bootloader stage, but in turn easier, or perhaps simply different, at the kernel and kernel device interface level. Consider, most MIPS and ARM systems ship with a specific set of basic devices, configured to use specific IO addresses, IRQs, etc, and that's it, at least to get up and running (USB devices, etc, may be able to be plugged in, but they're not normally needed for boot). If you've been keeping up with the kernel (say via LWN, etc), this has been one of the big deals with the ARM tree recently, as until now each board had its own hard-coded kernel config directly in the tree, and it was getting unmanageable. They're switching to device tree, etc, allowing the boot loader to feed the kernel a file with this information at boot time, thus allowing a whole bunch of different boards to boot off the same shipped kernel, while at the same time getting the explosion of individual board files out of the kernel tree. This is a BIG deal on ARM and similar embedded archs, but doesn't affect x86 (either 32-bit or 64-bit) at all. Meanwhile, on x86, the system must be prepared for end-user switch-out of pretty much everything. memory, storage (consider floppy, hard drive, optical disk either direct or el-torito, USB stick, etc, all bootable and all end-user changable!), even quantity and speed of CPUs, and the firmware BIOS (or replacement) must cope with that and be able to boot off it. Even back in the 386 era when everything was jumper-configured, users could still change pretty much everything out, other than the mobo itself. Now days, it's even MORE complex, as most of these devices can be configured in dozens or hundreds of mode combinations via plug-n- pray, and they often don't /have/ a default -- they **MUST** be so configured in ordered to be operable for the intended use. Sure, the BIOS CAN leave some of it for the kernel to do, but other bits, not so much, as otherwise, how does the kernel even get loaded -- the BIOS must pick one of the many boot options, configure it (as well as the CPU and the system between storage and the CPU, storage chipset, memory, etc) at least well enough to read in the boot loader and/or kernel. None of that's necessary on ARM, etc, because (pretty much) everything there's a totally arbitrary-as-shipped config, nothing to dynamically negotiate and get working before the kernel or secondary bootloader (after the BIOS) can even work! A firmware replacement for the BIOS does not need to worry about floppy drives, hard drives, optical drives, usb devices, isa devices, pci devices and pci express drives, etcetera, because those live on buses, which the kernel can detect. It would need a device tree to inform the kernel of what buses are available, but that would be specific to a given board, rather than what is attached to it. If the end user makes hardware changes, the kernel should be able to handle that, with the exception of changes involving RAM, which I believe go into the device tree. With that said, I am not convinced by your argument that x86 is fundamentally more complex. Many of the things you attributed to the BIOS are in fact handled by the kernel. There is plenty of duplication between the two, where the BIOS will configure things and then the kernel will configure them again. However, the BIOS does not accomplish anything useful in those cases.
Re: [gentoo-dev] My wishlist for EAPI 5
On 21 June 2012 05:33, Alec Warner anta...@gentoo.org wrote: On Wed, Jun 20, 2012 at 10:25 PM, Richard Yao r...@gentoo.org wrote: Here is my wishlist for EAPI 5: [...] POSIX Shell compliance There has been a great deal of work done to give the user full control of what is on his system and there is more that we can do there. In particular, I think a lean Gentoo Linux system should be able to use busybox sh and nothing else. That requires POSIX shell compliance. OpenRC init scripts support this and the configure scripts support this. The few exceptions are bugs that are addressed by the Gentoo BSD developers. As such, I think we should make EAPI=5 use POSIX shell by default. If an ebuild requires bash, we can allow the ebuild to declare that (e.g. WANT_SH=bash), but that should be the exception and not the rule. Our ebuilds are written in bash. [...] Screw trying to get the PM to stop using bash; developers are not interested in writing ebuilds in posix shell; bar none. Why would I as an ebuild author waste a bunch of time writing my ebuild in posix compatible sh when I can use bash (and if I had a better language than bash to write ebuilds in; I'd use that too.) You are free to write your ebuilds in posix sh; good luck to you. Ebuilds are written in bash. And the convenience of using bash far outweighs any benefits of using posix sh instead. One needs to make a very strong case to convince enough developers to change this... -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead
Re: [gentoo-dev] My wishlist for EAPI 5
On 06/21/12 15:25, Pacho Ramos wrote: El jue, 21-06-2012 a las 08:00 +0100, Ciaran McCreesh escribió: On Thu, 21 Jun 2012 08:08:55 +0200 Pacho Ramos pa...@gentoo.org wrote: Also, if I remember correctly, Tommy asked for this some months ago, you asked for what he sent some days ago and now you require more and more work to delay things to be implemented. I still haven't seen a clear description of exactly what should be changed and why. I've also not seen a description of exactly what problem is being solved, nor a discussion of the relative merits of implementing a solution to whatever that problem is. All I've seen is a mess of code that gets it working in Portage (which isn't the same as implements it for Portage) and a big wall of text that contains lots that no-one needs to know and little of what's important. This needs to go through the GLEP process, and it needs a PMS diff. In case you're not aware, the first time Gentoo did multilib, it was done as a series of random changes to Portage that no-one really thought through or understood. As you can see, that didn't work... Then, looks clear to me that the way to get things approved in newer EAPIs is not clear enough as looks like a lot of devs (like me) don't know them (for example, when things to be added to EAPI need also a GLEP and a PMS diff, also the needing to get an implementation for any package manager). Is this documented in some place? No, and this is a rather random ad-hoc requirement that hasn't been specified before. All previous EAPI processes went through some debate with dev-portage@ and the other involved people (mostly pkgcore/ferringb and paludis/ciaranm), then the proposal got handed to council to vote on, and if council was happy that proposal was hammered into PMS and the new EAPI published. Most of the time new features had a crude approximation of a patch for PMS available so that the documentation updates were done in a timely manner. I have no idea why Ciaran is trying to redefine the process now suddenly and why people are taking this nonsense seriously. If not, I think it should be documented and, of course, it should be done by PMS team if possible as they clearly know what they expect to get for approval if needed since, I discussed some days ago, council will simply accept some specific features to be included in next eapi once they are accepted by PMS team. That way, we could save a lot of time, know what steps are pending, try to ask for help for some specific steps and, finally, get it discussed in PMS people providing all what is needed. I would say PMS team accepts what council signs off ... or am I seeing the order wrong here? So, the normal way to get a feature into the next EAPI is ... write a specification to the best of your capabilities, present it here, when people are done bashing it ask PMS people to help you prepare a PMS patch so that you can suggest it to Council, and then it's mostly a matter of waiting until the next EAPI is finalized (which currently runs at a glacial pace of about one EAPI a year as far as I remember) Take care, Patrick
Re: [gentoo-dev] My wishlist for EAPI 5
On Thu, 21 Jun 2012 19:15:02 +0800 Patrick Lauer patr...@gentoo.org wrote: Then, looks clear to me that the way to get things approved in newer EAPIs is not clear enough as looks like a lot of devs (like me) don't know them (for example, when things to be added to EAPI need also a GLEP and a PMS diff, also the needing to get an implementation for any package manager). Is this documented in some place? No, and this is a rather random ad-hoc requirement that hasn't been specified before. It's dependent upon the level of complexity of the work, and whether or not anyone on the PMS team understands it enough to be able to do the work themselves. As far as I know, none of us do on this one, so it's down to whoever wants it to educate us enough that we can get it done... All previous EAPI processes went through some debate with dev-portage@ and the other involved people (mostly pkgcore/ferringb and paludis/ciaranm), then the proposal got handed to council to vote on, and if council was happy that proposal was hammered into PMS and the new EAPI published. Most of the time new features had a crude approximation of a patch for PMS available so that the documentation updates were done in a timely manner. Actually, we've been passing pretty much final PMS patches to the Council to vote on. I have no idea why Ciaran is trying to redefine the process now suddenly and why people are taking this nonsense seriously. I'm not. I would say PMS team accepts what council signs off ... or am I seeing the order wrong here? The PMS team makes suggestions to the Council, and the Council accepts a subset of those. The Council can also suggest that the PMS team looks at a particular feature, but as Gentoo has no mechanism in place for forcing work to get done, that only works if there's someone with both the time and the knowledge to figure it out. So, the normal way to get a feature into the next EAPI is ... write a specification to the best of your capabilities, present it here, when people are done bashing it ask PMS people to help you prepare a PMS patch so that you can suggest it to Council Yup, and for difficult cases like the ones under discussion, a part of presenting it is to demo a working implementation on real packages so that we gain real world experience of the feature. It's also important to note that the best of your capabilities may not be anywhere near enough for the PMS people or the package mangler people to do the remainder of the work. and then it's mostly a matter of waiting until the next EAPI is finalized (which currently runs at a glacial pace of about one EAPI a year as far as I remember) I like how you simultaneously troll both sides of that issue. Weren't you previously claiming there were too many EAPIs and that we shouldn't have lots of new ones? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] My wishlist for EAPI 5
On Thu, Jun 21, 2012 at 5:27 AM, Alec Warner anta...@gentoo.org wrote: There is this vague idea that you can just propose something; get consensus on the ML, everyone goes to implement it, and then it works just as designed. That is usually called the 'waterfall' model and its really hard to do correctly. ++ Waterfall has problems even in places where people are paid to do work. It has little chance of working here. Devs aren't paid to do work. They do what interests them. So, the most effective way to make something happen is to do it yourself, or better still make it something interesting, do it yourself, and inspire others to help you out. A working program will always gather more interest than a discussion on a list. Plus Gentoo is all about choice - even if it never becomes the standard lots of people will do it anyway. Look at paludis, systemd, and so on. The autobuilt releases started out as drobbins side project on funtoo before they became the mainstream Gentoo way. Showing people that something works is always better than telling them. Rich
Re: [gentoo-dev] About what would be included in EAPI5
On Wed, 2012-06-20 at 17:50 +0100, Ciaran McCreesh wrote: Then there are ebuilds that don't call eautoreconf, in the first place. Should we require that all of them inherit autotools now, just for the unlikely case that user patches could be applied? If the aim is to provide a working feature to users, yes. The alternative is to not provide user patches support. Damnit, let the user shoot themself in the foot but let them learn from it. Remember back in the day when you had no clue? You learned from it. You can only protect them so much. If they want to use custom patches then they need to learn how. -- Homer Parker hpar...@gentoo.org signature.asc Description: This is a digitally signed message part
[gentoo-dev] Authorship of app-doc/pms
Dear all, according to git blame, this is the distribution of authorship across the current git master of the pms tex source. 2 Pierre-Yves Aillet 5 Fernando J. Pereda 6 Mark Loeser 7 Richard Brown 8 Thomas Anderson 25 NotCommittedYet (???) 27 Bo Ørsted Andresen 28 Brian Harring 37 Michał Górny 197 David Leverton 557 Ulrich Müller 678 Stephen Bennett 694 Christian Faulhammer 1903Ciaran McCreesh Given that and my usual subtlety, I think the current title page misrepresents contributorship, and would like to request that the following patch is applied to branches master and eapi-5. Best, Andreas From 3572b4cb400b2ff156e4f28d3dffe82c687a1dc9 Mon Sep 17 00:00:00 2001 From: Andreas K. Huettel andreas.huet...@physik.uni-r.de Date: Thu, 21 Jun 2012 14:03:24 +0200 Subject: [PATCH] Update author information --- pms.cls | 19 ++- 1 file changed, 14 insertions(+), 5 deletions(-) diff --git a/pms.cls b/pms.cls index db2fd48..b2faef1 100644 --- a/pms.cls +++ b/pms.cls @@ -114,7 +114,7 @@ citecolor=black, linkcolor=black, pdftitle={Package Manager Specification}, -pdfauthor={Stephen P. Bennett, Ciaran McCreesh}, +pdfauthor={Ulrich Mueller, Stephen P. Bennett, Christian Faulhammer, Ciaran McCreesh}, pdfcreator={pdfLaTeX and hyperref}, pdfsubject={Defining a feature set for package managers in the Gentoo world}, @@ -125,10 +125,19 @@ } % Some metadata needed for the title page generation \title{Package Manager Specification} -\author{Stephen P. Bennett \\ -\href{mailto:s...@exherbo.org}{s...@exherbo.org} \and Ciaran -McCreesh \\ -\href{mailto:ciaran.mccre...@googlemail.com} {ciaran.mccre...@googlemail.com}} +\author{ +Ulrich Müller \\ +\href{mailto:u...@gentoo.org}{u...@gentoo.org} +\and +Stephen P. Bennett \\ +\href{mailto:s...@exherbo.org}{s...@exherbo.org} +\and +Christian Faulhammer \\ +\href{mailto:fa...@gentoo.org}{fa...@gentoo.org} +\and +Ciaran McCreesh \\ +\href{mailto:ciaran.mccre...@googlemail.com} {ciaran.mccre...@googlemail.com} +} % Reads the last commit date from the Git repository and even succeeds % when none is available \ifthenelse{\equal{\VCDateISO}{}} -- 1.7.9.4 -- Andreas K. Huettel Gentoo Linux developer kde, sci, arm, tex, printing signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] My wishlist for EAPI 5
On Thu, 2012-06-21 at 08:00 +0100, Ciaran McCreesh wrote: In case you're not aware, the first time Gentoo did multilib, it was done as a series of random changes to Portage that no-one really thought through or understood. As you can see, that didn't work... No, but paved the way for other distros as they had nothing even close. I'm sure you remember back then. Don't be an ass. -- Homer Parker hpar...@gentoo.org signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] My wishlist for EAPI 5
On Thu, 2012-06-21 at 09:24 +0200, justin wrote: Won't it be a good thing, if you instead of showing all of us, that you can tell where people fail to present something in the right way, help and guide them to write the necessary things like PMS patches, GLEPs etc., so that we can proceed in an efficient way? That's not his style. Never has been, and I don't see that changing. -- Homer Parker hpar...@gentoo.org signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] About what would be included in EAPI5
On Thu, 21 Jun 2012 07:04:41 -0500 Homer Parker hpar...@gentoo.org wrote: Damnit, let the user shoot themself in the foot but let them learn from it. Remember back in the day when you had no clue? You learned from it. You can only protect them so much. If they want to use custom patches then they need to learn how. That's not the issue. The issue is advertising a user patches feature when there's no way for the user to know up-front whether or not their patches will be applied. This whole discussion started because user patches are currently randomly ignored sometimes. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] My wishlist for EAPI 5
On Thu, 21 Jun 2012 07:11:27 -0500 Homer Parker hpar...@gentoo.org wrote: On Thu, 2012-06-21 at 08:00 +0100, Ciaran McCreesh wrote: In case you're not aware, the first time Gentoo did multilib, it was done as a series of random changes to Portage that no-one really thought through or understood. As you can see, that didn't work... No, but paved the way for other distros as they had nothing even close. I'm sure you remember back then. Don't be an ass. And what did Gentoo get out of it? What I remember is Gentoo putting in lots of work randomly changing things until things worked, and ending up not knowing what most of those changes were or why they were done. The end result is that there's still a random smattering of multilib-related mess cluttering up ebuild internals that doesn't actually do anything except cause intermittent breakages. Doing experiments is great as a way of understanding the problem, but it isn't how you deliver a solution. That takes a lot more work, and someone has to be prepared to do it. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] My wishlist for EAPI 5
On Thu, 21 Jun 2012 07:14:49 -0500 Homer Parker hpar...@gentoo.org wrote: On Thu, 2012-06-21 at 09:24 +0200, justin wrote: Won't it be a good thing, if you instead of showing all of us, that you can tell where people fail to present something in the right way, help and guide them to write the necessary things like PMS patches, GLEPs etc., so that we can proceed in an efficient way? That's not his style. Never has been, and I don't see that changing. Yeah, I'm afraid I'm not available for hire to work full time on providing basic tutoring and hand-holding on design and technical writing -- it's not really my cup of tea. But if you have the money, there are plenty of others who make their livings teaching that sort of thing. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in x11-misc/lightdm: lightdm-1.2.2-r2.ebuild ChangeLog
On Thu, 21 Jun 2012 16:42:11 +0800 Ben de Groot yng...@gentoo.org wrote: And users might still have older gobject-introspection installed, with nothing forcing the upgrade now. Regular maintenance should take care of that. We are not in the habit of specifying minimal versions for all dependencies. yes we are, if you are not then you should change this. things like https://bugs.gentoo.org/show_bug.cgi?id=266293 are perfectly valid bugs and annoy users. its not because you hadnt had a bug report that its not worth preventing it. A.
[gentoo-dev] Re: Re: [gentoo-pms] Authorship of app-doc/pms
Dear all, according to git blame, this is the distribution of authorship across the current git master of the pms tex source. Not that I particularly mind either way, but your stats are way off due to reformatting. If you just use git blame, someone who changes a \t to a \em in a paragraph gets measured as writing that line and every line in the paragraph following it. If you're looking to change the authors list, I recommend doing so based upon asking people whether they think they should be on there, and adding anyone who says yes, rather than on bogus stats. Well at least I added some data to undermine my request. Your turn now. -- Andreas K. Huettel Gentoo Linux developer kde, sci, arm, tex, printing signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Re: [gentoo-pms] Authorship of app-doc/pms
On Thu, 21 Jun 2012 14:46:39 +0200 Andreas K. Huettel dilfri...@gentoo.org wrote: Not that I particularly mind either way, but your stats are way off due to reformatting. If you just use git blame, someone who changes a \t to a \em in a paragraph gets measured as writing that line and every line in the paragraph following it. If you're looking to change the authors list, I recommend doing so based upon asking people whether they think they should be on there, and adding anyone who says yes, rather than on bogus stats. Well at least I added some data to undermine my request. Your turn now. Oh, I think your request is fine, and your results are reasonable. I just think letting anyone who can say with a straight face that they should be there be there is a better measure than numbers that don't tell you anything. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] My wishlist for EAPI 5
On Thu, 2012-06-21 at 13:30 +0100, Ciaran McCreesh wrote: On Thu, 21 Jun 2012 07:11:27 -0500 Homer Parker hpar...@gentoo.org wrote: On Thu, 2012-06-21 at 08:00 +0100, Ciaran McCreesh wrote: In case you're not aware, the first time Gentoo did multilib, it was done as a series of random changes to Portage that no-one really thought through or understood. As you can see, that didn't work... No, but paved the way for other distros as they had nothing even close. I'm sure you remember back then. Don't be an ass. And what did Gentoo get out of it? What I remember is Gentoo putting in lots of work randomly changing things until things worked, and ending up not knowing what most of those changes were or why they were done. The end result is that there's still a random smattering of multilib-related mess cluttering up ebuild internals that doesn't actually do anything except cause intermittent breakages. Doing experiments is great as a way of understanding the problem, but it isn't how you deliver a solution. That takes a lot more work, and someone has to be prepared to do it. The hell? Other distos where still thinking of how to implement multilib and we had it. I know first hand as I trashed a system trying out the latest-n-greatest.. And the next round fixed it. The -emul packages from then on along with the multilib profiles have worked fine. Again, quit being an ass. Oh, and what I remember is.. You didn't contribute. There was kingtaco, lv, and kuglafang sp?. So you're clear there, you didn't have a damn thing to do with it. -- Homer Parker hpar...@gentoo.org signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] About what would be included in EAPI5
On Thu, 2012-06-21 at 13:25 +0100, Ciaran McCreesh wrote: On Thu, 21 Jun 2012 07:04:41 -0500 Homer Parker hpar...@gentoo.org wrote: Damnit, let the user shoot themself in the foot but let them learn from it. Remember back in the day when you had no clue? You learned from it. You can only protect them so much. If they want to use custom patches then they need to learn how. That's not the issue. The issue is advertising a user patches feature when there's no way for the user to know up-front whether or not their patches will be applied. This whole discussion started because user patches are currently randomly ignored sometimes. I guess I missed it's not a global feature, sorry. That said, everything else stands. -- Homer Parker hpar...@gentoo.org signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] My wishlist for EAPI 5
On Thu, 21 Jun 2012 08:13:50 -0500 Homer Parker hpar...@gentoo.org wrote: And what did Gentoo get out of it? What I remember is Gentoo putting in lots of work randomly changing things until things worked, and ending up not knowing what most of those changes were or why they were done. The end result is that there's still a random smattering of multilib-related mess cluttering up ebuild internals that doesn't actually do anything except cause intermittent breakages. Doing experiments is great as a way of understanding the problem, but it isn't how you deliver a solution. That takes a lot more work, and someone has to be prepared to do it. The hell? Other distos where still thinking of how to implement multilib and we had it. I know first hand as I trashed a system trying out the latest-n-greatest.. And the next round fixed it. The -emul packages from then on along with the multilib profiles have worked fine. ...so why are people running around demanding that reinventing multilib is the number one priority and has to be in EAPI 5 immediately then? I was under the impression that your fellow developers don't consider the -emul packages to be an adequate solution. If that isn't the case, and the existing mechanism is in fact fine as you claim, then great, we can ignore multilib from an EAPI perspective. I can only go on what your colleagues are claiming here. I suggest if you're upset at the suggestion that Gentoo doesn't have a decent multilib implementation then you take it up with all the people who are demanding the PMS team provide them with one. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Killing UEFI Secure Boot
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 21/06/12 05:33 AM, Richard Yao wrote: On 06/21/2012 04:08 AM, Duncan wrote: Richard Yao posted on Wed, 20 Jun 2012 18:16:23 -0400 as excerpted: 3. How does getting a x86 system to boot differ from getting a MIPS system or ARM system to boot? Does it only work because the vendors made it work or is x86 fundamentally harder? I can answer this one. x86 is harder at the bootloader stage, but in turn easier, or perhaps simply different, at the kernel and kernel device interface level. Consider, most MIPS and ARM systems ship with a specific set of basic devices, configured to use specific IO addresses, IRQs, etc, and that's it, at least to get up and running (USB devices, etc, may be able to be plugged in, but they're not normally needed for boot). If you've been keeping up with the kernel (say via LWN, etc), this has been one of the big deals with the ARM tree recently, as until now each board had its own hard-coded kernel config directly in the tree, and it was getting unmanageable. They're switching to device tree, etc, allowing the boot loader to feed the kernel a file with this information at boot time, thus allowing a whole bunch of different boards to boot off the same shipped kernel, while at the same time getting the explosion of individual board files out of the kernel tree. This is a BIG deal on ARM and similar embedded archs, but doesn't affect x86 (either 32-bit or 64-bit) at all. Meanwhile, on x86, the system must be prepared for end-user switch-out of pretty much everything. memory, storage (consider floppy, hard drive, optical disk either direct or el-torito, USB stick, etc, all bootable and all end-user changable!), even quantity and speed of CPUs, and the firmware BIOS (or replacement) must cope with that and be able to boot off it. Even back in the 386 era when everything was jumper-configured, users could still change pretty much everything out, other than the mobo itself. Now days, it's even MORE complex, as most of these devices can be configured in dozens or hundreds of mode combinations via plug-n- pray, and they often don't /have/ a default -- they **MUST** be so configured in ordered to be operable for the intended use. Sure, the BIOS CAN leave some of it for the kernel to do, but other bits, not so much, as otherwise, how does the kernel even get loaded -- the BIOS must pick one of the many boot options, configure it (as well as the CPU and the system between storage and the CPU, storage chipset, memory, etc) at least well enough to read in the boot loader and/or kernel. None of that's necessary on ARM, etc, because (pretty much) everything there's a totally arbitrary-as-shipped config, nothing to dynamically negotiate and get working before the kernel or secondary bootloader (after the BIOS) can even work! A firmware replacement for the BIOS does not need to worry about floppy drives, hard drives, optical drives, usb devices, isa devices, pci devices and pci express drives, etcetera, because those live on buses, which the kernel can detect. It would need a device tree to inform the kernel of what buses are available, but that would be specific to a given board, rather than what is attached to it. If the end user makes hardware changes, the kernel should be able to handle that, with the exception of changes involving RAM, which I believe go into the device tree. I take it the above statement is based on the kernel being directly placed within the BIOS/firmware/nvram on the board, such that you couldn't boot anything else but that kernel? Otherwise I don't see how you could get away with the BIOS not worrying about all those devices.. IE, I don't forsee many general x86 users giving up their ability to boot off usb stick or cdrom or pxe based on a boot-time bios choice, or to boot windows or alternative linux kernels (which could be located who knows where) at whim. And I don't see how an alternative BIOS would be able to provide this ability without dealing with all the things Duncan mentioned... -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) iF4EAREIAAYFAk/jNvoACgkQ2ugaI38ACPD0WwD+LM1PrRtpHIrxEgWcOKKd85uU 7JAmad5qJ7ft0mO7QlIA/2esLqMEfWgiLYko/GoHOuIq01PS1ou9XoePUuOtfCsI =CwME -END PGP SIGNATURE-
Re: [gentoo-dev] Re: Killing UEFI Secure Boot
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/21/2012 11:00 AM, Ian Stakenvicius wrote: A firmware replacement for the BIOS does not need to worry about floppy drives, hard drives, optical drives, usb devices, isa devices, pci devices and pci express drives, etcetera, because those live on buses, which the kernel can detect. It would need a device tree to inform the kernel of what buses are available, but that would be specific to a given board, rather than what is attached to it. If the end user makes hardware changes, the kernel should be able to handle that, with the exception of changes involving RAM, which I believe go into the device tree. I take it the above statement is based on the kernel being directly placed within the BIOS/firmware/nvram on the board, such that you couldn't boot anything else but that kernel? That is correct. Otherwise I don't see how you could get away with the BIOS not worrying about all those devices.. IE, I don't forsee many general x86 users giving up their ability to boot off usb stick or cdrom or pxe based on a boot-time bios choice, or to boot windows or alternative linux kernels (which could be located who knows where) at whim. And I don't see how an alternative BIOS would be able to provide this ability without dealing with all the things Duncan mentioned... An initramfs should be able to provide all of that functionality. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJP4zgzAAoJECDuEZm+6ExkeSUP/0PrjZtnWvbdXpTYwTN/U1wq lVl/nx6mXAq6wwxrhgHMzMvzh68oxqAhZgOASLFoQnO92WbVJzxBZtxBQftR5TGV k5NGVKCLwVkIi7tQGLk3vLHo3l6MnmwCjmfSCSbr7VEqil2hgy5EwhUiWvibzKlp 34m9g75Z/JR/dMk7qcG7z2lvJNSDlL2Ufgqi5YPQqqmqsMHGi350ZM91dkilOkV2 OtBwJzD+JlvQl+ALBv33KmI37VslcB/ydcx08YfE6BuOkHdusOM6/Den4JUrmS2I WDvcejzgxjneOifoL+0hiM9ooG3L6Q19G3ZNSSqAit85P5ms6Cm9Bul2lO6+EiQu iwYLcH/5nwkVC/8bRaHvzTnSaKyvyip9lKzeZyD9fnsMirxV6R3T3aWyIwhBdb8E pe85C+n4Wd5n4nhuwQW8AP860yftco9aNSrx1uIb+PMEi38+yLTwNjrR/shQ7RcK 76mpWIWat/YpLRNF9Va7PN3FaslsTGVyQdgcBtci9S9IXWhwGyc7ZDS7DIq7CYTT 9pE9dYqDOmEl0kWt5e4EgrjD4ibwhOsvddBJBcW2spphnRBuHwkzdp7K7pW3KX1z Wj4triKllBLwMJvIcDk6Nv0tm0YO+kzxDhEsjBajjDR48652ijF6RYLi2cV7Ui+9 Hnsvgz6oEc7sNL9VbPnZ =Aacv -END PGP SIGNATURE-
Re: [gentoo-dev] Re: Killing UEFI Secure Boot
On 2012.06.21 16:05, Richard Yao wrote: On 06/21/2012 11:00 AM, Ian Stakenvicius wrote: A firmware replacement for the BIOS does not need to worry about floppy drives, hard drives, optical drives, usb devices, isa devices, pci devices and pci express drives, etcetera, because those live on buses, which the kernel can detect. It would need a device tree to inform the kernel of what buses are available, but that would be specific to a given board, rather than what is attached to it. If the end user makes hardware changes, the kernel should be able to handle that, with the exception of changes involving RAM, which I believe go into the device tree. I take it the above statement is based on the kernel being directly placed within the BIOS/firmware/nvram on the board, such that you couldn't boot anything else but that kernel? That is correct. [snip] So when you build a dud kernel and flash your BIOS with it, and we all build the odd dud, your motherboard is bricked. Now what? Get out your JTAG adaptor and another PC I suppose. -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods trustees pgp8XbNre5giw.pgp Description: PGP signature
Re: [gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags
Michał Górny wrote: Hello, A simple solution to a program long-unsolved. In GLEP form. Just a couple of minor points/nitpicks: 1) If an installed package has both IUSE_RUNTIME and REQUIRED_USE, should REQUIRED_USE be re-verified: a) for every dep resolution b) when the package is involved in the resolution for some other reason (not necessarily being reinstalled, just when the resolver has some reason to look at it) c) something else? I think b) should be sufficient (and probably easier to implement), but is there any reason why it wouldn't be? 2) It's not forbidden for package A to depend on an IUSE_RUNTIME flag of package B being disabled, but it's unlikely to be useful. To make this more concrete, a fictional but vaguely plausible example: app-text/docmangler: # links to poppler to handle PDFs, and can use Ghostscript for # PostScript support if available IUSE=postscript IUSE_RUNTIME=postscript DEPEND=app-text/poppler RDEPEND=${DEPEND} postscript? ( app-text/ghostscript ) app-misc/coolapp: IUSE=doc # if Ghostscript is installed, docmangler uses it for both # PostScript and PDF files, but Ghostscript misrenders our PDFs DEPEND=doc? ( app-text/docmangler[-postscript] ) Here, the [-postscript] dep would force the user to disable that flag, but it wouldn't do much good because Ghostscript would still be installed. This doesn't happen with regular USE flags because (if the ebuild is written correctly) disabling the flag removes the feature even if its dependencies happen to be installed. Possible solutions: a) automatically rewrite the dep as postscript? ( app-text/ghostscript ) !postscript? ( !app-text/ghostscript ) b) forbid [-foo]-style deps for IUSE_RUNTIME flags (would also make sense in that case to disallow them in !foo-style conditionals in the dependencies of the package itself, as that could cause similar paradoxes) c) don't address it in the spec itself, and require people to manually write the dep in the blocker form if it's required d) something else? a) is pretty icky IMHO, especially if the flag pulls in multiple packages. I could live with either b) or c), but b) is less flexible and c) leaves a potential trap for the unwary. Any opinions?
Re: [gentoo-dev] Re: Killing UEFI Secure Boot
Roy Bamford wrote: I take it the above statement is based on the kernel being directly placed within the BIOS/firmware/nvram on the board, This is sometimes called Linux-as-bootloader (LAB/lab for short) in the coreboot project. such that you couldn't boot anything else but that kernel? Yes and no. A kernel can kexec() another program. So when you build a dud kernel and flash your BIOS with it, and we all build the odd dud, your motherboard is bricked. Any firmware modification has potential to brick, and shouldn't be done unless you are comfortable with the modification, or with solving a brick problem. :) Keep backup flash chips, if your boot flash is socketed. There are also several software techniques to eliminate and/or reduce the brick risk. Again, if you flash nothing but a kernel into the boot flash then the machine will just laugh at you in your face and not start. coreboot has infrastructure for separating normal boot from fallback boot, for when the normal boot fails. Writing to the flash chip is not an all-or-nothing operation. coreboot uses a super simple filesystem for the boot flash, which can be aligned to eraseblocks in the flash chip, such that only ever the normal boot files are erased and rewritten, while leaving fallback contents untouched. Even a power outage during flashing will not brick your machine. Get out your JTAG adaptor and another PC I suppose. PCs don't usually have JTAG as convenient as embedded systems, but the boot flash can always be written with other suitable dedicated hardware, from the outside, as you write. //Peter pgp1B1JHshB5P.pgp Description: PGP signature
Re: [gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 21/06/12 03:05 PM, David Leverton wrote: Michał Górny wrote: Hello, A simple solution to a program long-unsolved. In GLEP form. Just a couple of minor points/nitpicks: [ Snip! ] 2) It's not forbidden for package A to depend on an IUSE_RUNTIME flag of package B being disabled, but it's unlikely to be useful. To make this more concrete, a fictional but vaguely plausible example: app-text/docmangler: # links to poppler to handle PDFs, and can use Ghostscript for # PostScript support if available IUSE=postscript IUSE_RUNTIME=postscript DEPEND=app-text/poppler RDEPEND=${DEPEND} postscript? ( app-text/ghostscript ) app-misc/coolapp: IUSE=doc # if Ghostscript is installed, docmangler uses it for both # PostScript and PDF files, but Ghostscript misrenders our PDFs DEPEND=doc? ( app-text/docmangler[-postscript] ) Here, the [-postscript] dep would force the user to disable that flag, but it wouldn't do much good because Ghostscript would still be installed. This doesn't happen with regular USE flags because (if the ebuild is written correctly) disabling the flag removes the feature even if its dependencies happen to be installed. Possible solutions: a) automatically rewrite the dep as postscript? ( app-text/ghostscript ) !postscript? ( !app-text/ghostscript ) b) forbid [-foo]-style deps for IUSE_RUNTIME flags (would also make sense in that case to disallow them in !foo-style conditionals in the dependencies of the package itself, as that could cause similar paradoxes) c) don't address it in the spec itself, and require people to manually write the dep in the blocker form if it's required d) something else? a) is pretty icky IMHO, especially if the flag pulls in multiple packages. I could live with either b) or c), but b) is less flexible and c) leaves a potential trap for the unwary. Any opinions? I'd say (c) , since IUSE_RUNTIME is not an enforceable state of the tree and if docmangler is used but fails when ghostscript is installed anyways, then the DEPEND should specify this regardless of whether the 'postscript' flag (used by IUSE_RUNTIME) is set or whether ghostscript is in the user's world file. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) iF4EAREIAAYFAk/jc+cACgkQ2ugaI38ACPCUOAD+ICKl69MUhUTRj+2HBQ0pNlvo Bqa5/TmaD0oKIkLi+xgBAIGwynEBXC3dXsG7Amky0OiEUyen41kURybNLR8FIkT2 =jMZ4 -END PGP SIGNATURE-
Re: [gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags
On Thu, 21 Jun 2012 20:05:46 +0100 David Leverton levert...@googlemail.com wrote: Michał Górny wrote: Hello, A simple solution to a program long-unsolved. In GLEP form. Just a couple of minor points/nitpicks: 1) If an installed package has both IUSE_RUNTIME and REQUIRED_USE, should REQUIRED_USE be re-verified: a) for every dep resolution b) when the package is involved in the resolution for some other reason (not necessarily being reinstalled, just when the resolver has some reason to look at it) c) something else? I think b) should be sufficient (and probably easier to implement), but is there any reason why it wouldn't be? Well, I don't understand the difference between a) and b) in your case but the idea is that REQUIRED_USE should be re-verified if either enabled USE flag list or REQUIRED_USE changes. 2) It's not forbidden for package A to depend on an IUSE_RUNTIME flag of package B being disabled, but it's unlikely to be useful. To make this more concrete, a fictional but vaguely plausible example: app-text/docmangler: # links to poppler to handle PDFs, and can use Ghostscript for # PostScript support if available IUSE=postscript IUSE_RUNTIME=postscript DEPEND=app-text/poppler RDEPEND=${DEPEND} postscript? ( app-text/ghostscript ) app-misc/coolapp: IUSE=doc # if Ghostscript is installed, docmangler uses it for both # PostScript and PDF files, but Ghostscript misrenders our PDFs DEPEND=doc? ( app-text/docmangler[-postscript] ) Here, the [-postscript] dep would force the user to disable that flag, but it wouldn't do much good because Ghostscript would still be installed. This doesn't happen with regular USE flags because (if the ebuild is written correctly) disabling the flag removes the feature even if its dependencies happen to be installed. Possible solutions: a) automatically rewrite the dep as postscript? ( app-text/ghostscript ) !postscript? ( !app-text/ghostscript ) b) forbid [-foo]-style deps for IUSE_RUNTIME flags (would also make sense in that case to disallow them in !foo-style conditionals in the dependencies of the package itself, as that could cause similar paradoxes) c) don't address it in the spec itself, and require people to manually write the dep in the blocker form if it's required d) something else? a) is pretty icky IMHO, especially if the flag pulls in multiple packages. I could live with either b) or c), but b) is less flexible and c) leaves a potential trap for the unwary. Any opinions? Good observation. I think b) is the best solution since forced removal of random dependencies is a very bad idea (and misuse of blockers). -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags
Michał Górny wrote: On Thu, 21 Jun 2012 20:05:46 +0100 David Leverton levert...@googlemail.com wrote: 1) If an installed package has both IUSE_RUNTIME and REQUIRED_USE, should REQUIRED_USE be re-verified: a) for every dep resolution b) when the package is involved in the resolution for some other reason (not necessarily being reinstalled, just when the resolver has some reason to look at it) c) something else? Well, I don't understand the difference between a) and b) in your case Suppose kde-base/kde-meta has both IUSE_RUNTIME and REQUIRED_USE, and that I have it installed and then modify one of the flags it uses in my configuration, but don't run any PM commands. Then suppose I install a Gnome package. Normally installing a Gnome package wouldn't require the PM to go anywhere near kde-meta, but being strict about revalidating REQUIRED_USE would require it to look through every installed package, just in case any have IUSE_RUNTIME and REQUIRED_USE set, for every installation command. Is that necessary? but the idea is that REQUIRED_USE should be re-verified if either enabled USE flag list or REQUIRED_USE changes. Would that mean the enabled USE flag list should be updated in the VDB every time REQUIRED_USE is checked, even when the package isn't being reinstalled? I think it would probably be easier to just recheck REQUIRED_USE, without trying to figure out whether any of the IUSE_RUNTIME flags were changed, it's just a question of how eager we want to be. 2) It's not forbidden for package A to depend on an IUSE_RUNTIME flag of package B being disabled, but it's unlikely to be useful. To make this more concrete, a fictional but vaguely plausible example: Possible solutions: a) automatically rewrite the dep as postscript? ( app-text/ghostscript ) !postscript? ( !app-text/ghostscript ) b) forbid [-foo]-style deps for IUSE_RUNTIME flags (would also make sense in that case to disallow them in !foo-style conditionals in the dependencies of the package itself, as that could cause similar paradoxes) c) don't address it in the spec itself, and require people to manually write the dep in the blocker form if it's required d) something else? Good observation. I think b) is the best solution since forced removal of random dependencies is a very bad idea (and misuse of blockers). One case that I forgot to mention before: if some package does something like if has_version app-text/docmangler[postscript]; then # ... else # ... fi Here, again, the else branch can lead to incoherent results as it can't assume that the postscript flag being disabled means Ghostscript isn't installed, and this one can't be forbidden by restricting the allowed dep forms. I think we'd have to just say don't do that then
Re: [gentoo-dev] My wishlist for EAPI 5
On Thu, 2012-06-21 at 14:20 +0100, Ciaran McCreesh wrote: On Thu, 21 Jun 2012 08:13:50 -0500 Homer Parker hpar...@gentoo.org wrote: And what did Gentoo get out of it? What I remember is Gentoo putting in lots of work randomly changing things until things worked, and ending up not knowing what most of those changes were or why they were done. In the beginning there was a method... The end result is that there's still a random smattering of multilib-related mess cluttering up ebuild internals that doesn't actually do anything except cause intermittent breakages. Doing experiments is great as a way of understanding the problem, but it isn't how you deliver a solution. That takes a lot more work, and someone has to be prepared to do it. The hell? Other distos where still thinking of how to implement multilib and we had it. I know first hand as I trashed a system trying out the latest-n-greatest.. And the next round fixed it. The -emul packages from then on along with the multilib profiles have worked fine. ...so why are people running around demanding that reinventing multilib is the number one priority and has to be in EAPI 5 immediately then? I was under the impression that your fellow developers don't consider the -emul packages to be an adequate solution. If that isn't the case, and the existing mechanism is in fact fine as you claim, then great, we can ignore multilib from an EAPI perspective. And now it needs revamped.. I see no problem with re-investigating the problem to make it better/easier/whatever. I can only go on what your colleagues are claiming here. I suggest if you're upset at the suggestion that Gentoo doesn't have a decent multilib implementation then you take it up with all the people who are demanding the PMS team provide them with one. I can only suggest you keep track of your train of thought.. In the beginning vs now are two completely separate issues. We were first, is it surprising the method needs looked at? No. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags
On Thu, 21 Jun 2012 21:26:26 +0100 David Leverton levert...@googlemail.com wrote: Michał Górny wrote: On Thu, 21 Jun 2012 20:05:46 +0100 David Leverton levert...@googlemail.com wrote: 1) If an installed package has both IUSE_RUNTIME and REQUIRED_USE, should REQUIRED_USE be re-verified: a) for every dep resolution b) when the package is involved in the resolution for some other reason (not necessarily being reinstalled, just when the resolver has some reason to look at it) c) something else? Well, I don't understand the difference between a) and b) in your case Suppose kde-base/kde-meta has both IUSE_RUNTIME and REQUIRED_USE, and that I have it installed and then modify one of the flags it uses in my configuration, but don't run any PM commands. Then suppose I install a Gnome package. Normally installing a Gnome package wouldn't require the PM to go anywhere near kde-meta, but being strict about revalidating REQUIRED_USE would require it to look through every installed package, just in case any have IUSE_RUNTIME and REQUIRED_USE set, for every installation command. Is that necessary? No, of course not. Otherwise, every package manager run would practically require it to re-validate all packages in the tree (possibly not only installed ones). Package manager must ensure the flags are valid when package is in the graph. I would think of IUSE_RUNTIME as a last-step action where packages were in the graph for rebuild already but the rebuild is disabled as being unnecessary. but the idea is that REQUIRED_USE should be re-verified if either enabled USE flag list or REQUIRED_USE changes. Would that mean the enabled USE flag list should be updated in the VDB every time REQUIRED_USE is checked, even when the package isn't being reinstalled? I think it would probably be easier to just recheck REQUIRED_USE, without trying to figure out whether any of the IUSE_RUNTIME flags were changed, it's just a question of how eager we want to be. No, the USE flag list in vdb may be updated every time the package gets into the graph with changed runtime flags. I don't consider that necessary, however. Just a nice backwards compatibility feature for other applications looking at vdb. 2) It's not forbidden for package A to depend on an IUSE_RUNTIME flag of package B being disabled, but it's unlikely to be useful. To make this more concrete, a fictional but vaguely plausible example: Possible solutions: a) automatically rewrite the dep as postscript? ( app-text/ghostscript ) !postscript? ( !app-text/ghostscript ) b) forbid [-foo]-style deps for IUSE_RUNTIME flags (would also make sense in that case to disallow them in !foo-style conditionals in the dependencies of the package itself, as that could cause similar paradoxes) c) don't address it in the spec itself, and require people to manually write the dep in the blocker form if it's required d) something else? Good observation. I think b) is the best solution since forced removal of random dependencies is a very bad idea (and misuse of blockers). One case that I forgot to mention before: if some package does something like if has_version app-text/docmangler[postscript]; then # ... else # ... fi Here, again, the else branch can lead to incoherent results as it can't assume that the postscript flag being disabled means Ghostscript isn't installed, and this one can't be forbidden by restricting the allowed dep forms. I think we'd have to just say don't do that then Well, as I see it restricting is more of a policy than a technical requirement. But in the current form, the spec doesn't allow passing IUSE_RUNTIME flags to has_version() so we're on the safe side :P. -- Best regards, Michał Górny signature.asc Description: PGP signature
[gentoo-dev] A friendly reminder: Ciaran McCreesh is not a Gentoo dev
Just a short note as it seems some confusion arises lately: Ciaran McCreesh is not a Gentoo dev and his words don't represent the position of Gentoo development team. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags
Michał Górny wrote: No, of course not. Otherwise, every package manager run would practically require it to re-validate all packages in the tree (possibly not only installed ones). Package manager must ensure the flags are valid when package is in the graph. I would think of IUSE_RUNTIME as a last-step action where packages were in the graph for rebuild already but the rebuild is disabled as being unnecessary. That's what I thought, was just making sure we're on the same page. No, the USE flag list in vdb may be updated every time the package gets into the graph with changed runtime flags. I don't consider that necessary, however. Just a nice backwards compatibility feature for other applications looking at vdb. 'K Well, as I see it restricting is more of a policy than a technical requirement. As long as we're clear on which it is, and what restrictions if any the PM can/should impose... But in the current form, the spec doesn't allow passing IUSE_RUNTIME flags to has_version() so we're on the safe side :P. True. Do we want to keep it that restrictive?
Re: [gentoo-dev] Packages up for grabs due wormo taking care of bug wrangling only
On 06/17/12 at 12:02AM +0200, Christian Ruppert wrote: On 06/16/12 at 11:39AM +0200, Pacho Ramos wrote: app-admin/ulogd app-arch/pdv Feel free to get them Thanks I'll take app-admin/ulogd. -- Regards, Christian Ruppert Role: Gentoo Linux developer, Bugzilla administrator and Infrastructure member Fingerprint: EEB1 C341 7C84 B274 6C59 F243 5EAB 0C62 B427 ABC8 It may take some time till I get to it so if someone else is faster, feel free. :P -- Regards, Christian Ruppert Gentoo Linux developer, Bugzilla administrator and Infrastructure member Fingerprint: EEB1 C341 7C84 B274 6C59 F243 5EAB 0C62 B427 ABC8 pgpQsfUqv2mKF.pgp Description: PGP signature
Re: [gentoo-dev] My wishlist for EAPI 5
On Thu, Jun 21, 2012 at 4:26 PM, Homer Parker hpar...@gentoo.org wrote: In the beginning there was a method... And now it needs revamped.. I see no problem with re-investigating the problem to make it better/easier/whatever. ++ I for one am happy to have had a working amd64 system for the last decade, even if it might have been somewhat better if I had been stuck on 32-bit while the perfect system was devised. Gentoo doesn't need thrown-together hacks, but half-decent solutions that work shouldn't be held up in favor of ideal solutions that don't exist. There is always room for evolution. That said, as far as EAPIs go I'm in favor of shipping whatever is ready to ship. Rich
Re: [gentoo-dev] Re: Killing UEFI Secure Boot
On Thu, Jun 21, 2012 at 3:10 PM, Peter Stuge pe...@stuge.se wrote: Roy Bamford wrote: So when you build a dud kernel and flash your BIOS with it, and we all build the odd dud, your motherboard is bricked. Any firmware modification has potential to brick, and shouldn't be done unless you are comfortable with the modification, or with solving a brick problem. :) So, why are we still going back and forth about this? If people want to work on coreboot they can do so (I'm sure they have a list). If people want to fork coreboot or redo it from scrach they can do so and start their own list. When it is shiny and perfect and has a following of hundreds of linux users we can always discuss whether we recommend using it in the handbook on -dev then. Otherwise it seems about as on-topic as debating whether grub or systemd or openrc should have feature A/B/C - we're a DISTRO - we integrate and ship what upstream gives us... Rich
Re: [gentoo-dev] Re: Killing UEFI Secure Boot
On 06/21/2012 06:51 PM, Rich Freeman wrote: On Thu, Jun 21, 2012 at 3:10 PM, Peter Stuge pe...@stuge.se wrote: Roy Bamford wrote: So when you build a dud kernel and flash your BIOS with it, and we all build the odd dud, your motherboard is bricked. Any firmware modification has potential to brick, and shouldn't be done unless you are comfortable with the modification, or with solving a brick problem. :) So, why are we still going back and forth about this? This idea has technical merit and it has sparked a very insightful discussion in which I learned many things that I did not know. My original intention in emailing the list was to learn such things, so my email has fulfilled its purpose. My email has also led to an interesting off list conversation between myself and Peter about this. I believe that the exchange of ideas that this prompted has been mutually beneficial. My hope is that our discussion catalyzes improvements in both Gentoo and coreboot. On 06/21/2012 06:51 PM, Rich Freeman wrote: we're a DISTRO - we integrate and ship what upstream gives us... RHEL is a distribution, but I understand that RedHat does a great deal of upstream programming and is also upstream for some things. Do you consider it to be inappropriate for us to play a larger role in both upstream development and as upstream ourselves? signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: My wishlist for EAPI 5
On 06/21/2012 04:29 AM, Duncan wrote: Richard Yao posted on Wed, 20 Jun 2012 16:50:33 -0400 as excerpted: On 06/20/2012 04:35 PM, Ciaran McCreesh wrote: On Wed, 20 Jun 2012 16:25:30 -0400 Richard Yao r...@gentoo.org wrote: POSIX Shell compliance So far as I know, every PM relies heavily upon bash anyway (and can't easily be made not to), so even if developers would accept having to rewrite all their eclasses, it still wouldn't remove the dep. Lets address POSIX compliance in the ebuilds first. Then we can deal with the package managers. Additionally, this is extremely unlikely because a number of developers insist on bash, to the extent that it would likely split gentoo in half if this were to be forced. It wouldn't pass council. It's unlikely to even /get/ to council. Openrc could move to POSIX shell because its primary dev at the time wanted it that way and it's only a single package. However, even then, doing it was controversial enough that said developer ended up leaving gentoo in-part over that, tho he did continue to develop openrc as a gentoo hosted project for quite some years. Now you're talking trying to do it for /every/ (well, almost every) package, thus touching every single gentoo dev. It's just not going to happen in even the medium term (say for argument APIs 5-7ish), let alone be something practical enough to implement, soon enough (even if everyone agreed on the general idea, they don't), to be anything like conceivable for EAPI5. So just let that one be. It's simply not worth tilting at that windmill. Would you (or someone else) elaborate on the specific features of bash that people find attractive?
Re: [gentoo-dev] A friendly reminder: Ciaran McCreesh is not a Gentoo dev
On Thu, 2012-06-21 at 23:01 +0200, Michał Górny wrote: Just a short note as it seems some confusion arises lately: Ciaran McCreesh is not a Gentoo dev and his words don't represent the position of Gentoo development team. Amen. -- Homer Parker hpar...@gentoo.org signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] A friendly reminder: Ciaran McCreesh is not a Gentoo dev
Amen to that too, but can you post the actual comments that he said ? 2012/6/21 Homer Parker hpar...@gentoo.org On Thu, 2012-06-21 at 23:01 +0200, Michał Górny wrote: Just a short note as it seems some confusion arises lately: Ciaran McCreesh is not a Gentoo dev and his words don't represent the position of Gentoo development team. Amen. -- Homer Parker hpar...@gentoo.org -- Salut alp Sylvain
Re: [gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags
On 06/21/2012 02:32 PM, David Leverton wrote: Michał Górny wrote: But in the current form, the spec doesn't allow passing IUSE_RUNTIME flags to has_version() so we're on the safe side :P. True. Do we want to keep it that restrictive? Shouldn't has_version allow any atom that would be allowed in *DEPEND? -- Thanks, Zac
Re: [gentoo-dev] A friendly reminder: Ciaran McCreesh is not a Gentoo dev
On Thu, Jun 21, 2012 at 9:12 PM, Sylvain Alain d2racing...@gmail.com wrote: Amen to that too, but can you post the actual comments that he said ? 2012/6/21 Homer Parker hpar...@gentoo.org On Thu, 2012-06-21 at 23:01 +0200, Michał Górny wrote: Just a short note as it seems some confusion arises lately: Ciaran McCreesh is not a Gentoo dev and his words don't represent the position of Gentoo development team. Amen. -- Homer Parker hpar...@gentoo.org -- Salut alp Sylvain Guys, Let's act like adults here. Just because someone disagrees with you doesn't mean they have something personally against you so there's no reason to take it to that level. This thread should end right now in the interest of civil discussion. -- Doug Goldstein
[gentoo-dev] Re: Killing UEFI Secure Boot
Richard Yao posted on Thu, 21 Jun 2012 05:33:22 -0400 as excerpted: A firmware replacement for the BIOS does not need to worry about floppy drives, hard drives, optical drives, usb devices, isa devices, pci devices and pci express drives, etcetera, because those live on buses, which the kernel can detect. But you have to be able to load the kernel first, before it can do all that detection. And to load it, you need to be able to read the device it's located on, which in a modern x86 system (as contrasted with mips/ arm) generally means detection of what's there, some mechanism to choose which available devices to check for a kernel or boot loader or whatever, and some way to dynamically configure it, since many devices are simply (device info probable) bricks until configured, these days. Sure, you can boot directly to a Linux kernel /as/ your firmware (as Ian S suggested), but then you're back to hard-configuring it in ordered to do so, thus losing all that extra flexibility that's part of what makes x86 different. Which was the question that I was addressing. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
Re: [gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags
On Thu, Jun 21, 2012 at 2:42 AM, Michał Górny mgo...@gentoo.org wrote: On Thu, 21 Jun 2012 08:30:24 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Thu, 21 Jun 2012 09:29:49 +0200 Michał Górny mgo...@gentoo.org wrote: On Wed, 20 Jun 2012 18:24:33 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Wed, 20 Jun 2012 19:11:33 +0200 hasufell hasuf...@gentoo.org wrote: On 06/20/2012 07:07 PM, Michał Górny wrote: Please read the rationale. Again. The whole thing. Three times. Please read my suggestions. Again. The whole thing. Three times. Can we all agree to just stop this and just restrict the arguing to being between SDEPEND and DEPENDENCIES? Cheers. You just volunteered to write portage patches. Cheers. Both were already implemented in Paludis, if you're looking for a reference implementation to try it out. There are also examples of use of SDEPEND in the old kdebuilds, and of DEPENDENCIES in Exherbo. I can give you a small patch to turn SDEPEND on for an EAPI if you like (it's just a one line addition to the EAPI definition file). Wait, did I just write to exherbo ml? No, don't think so. 'Implemented in Paludis' doesn't work here. We're discussing Gentoo features, and official package manager in Gentoo is portage. If you don't believe me, check out the docs. -- Best regards, Michał Górny I would recommend the two of you step away from this thread and discussion for a day or two and come back to it with a fresh look at the suggestions and the code that's available and then we can move on getting this into an EAPI from there. -- Doug Goldstein
Re: [gentoo-dev] Re: Killing UEFI Secure Boot
On 06/22/2012 01:02 AM, Duncan wrote: Richard Yao posted on Thu, 21 Jun 2012 05:33:22 -0400 as excerpted: A firmware replacement for the BIOS does not need to worry about floppy drives, hard drives, optical drives, usb devices, isa devices, pci devices and pci express drives, etcetera, because those live on buses, which the kernel can detect. But you have to be able to load the kernel first, before it can do all that detection. And to load it, you need to be able to read the device it's located on, which in a modern x86 system (as contrasted with mips/ arm) generally means detection of what's there, some mechanism to choose which available devices to check for a kernel or boot loader or whatever, and some way to dynamically configure it, since many devices are simply (device info probable) bricks until configured, these days. Sure, you can boot directly to a Linux kernel /as/ your firmware (as Ian S suggested), but then you're back to hard-configuring it in ordered to do so, thus losing all that extra flexibility that's part of what makes x86 different. Which was the question that I was addressing. Placing it in the firmware is what I suggested. I also later stated that it is possible for the firmware to contain an initramfs that would enable it to start a kernel located on a device. It seems to me that this would work if device trees for motherboards were readily available and the EEPROM chips have sufficient capacity. I am under the impression that UEFI firmware is large enough that capacity on UEFI motherboards should not be an issue. The main issue would be obtaining device trees.
[gentoo-dev] Re: My wishlist for EAPI 5
Richard Yao posted on Thu, 21 Jun 2012 20:38:17 -0400 as excerpted: Would you (or someone else) elaborate on the specific features of bash that people find attractive? For me (not a gentoo dev), in simplest terms it's just that I don't like having to keep track of what's a bashism and what's POSIX. If individual devs prefer POSIX code, they can certainly write ebuilds (or a 4th gentoo package manager for that matter) in all POSIX, but there's enough devs that for /whatever/ reason strongly prefer bash, where strongly is ultimately defined as if it's redefined to POSIX, there's a lot of other projects I can spend my time on instead, that won't force me into jumping thru those hoops, and that fact is widely enough known, that it's unlikely in the extreme. But to give you a example I've seen on this list (one of the few bits I know isn't POSIX)... Many people appreciate the advantages of [[ tests, looser quoting, ==/=~ pattern matching tests, etc. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
Re: [gentoo-dev] Re: Killing UEFI Secure Boot
On 06/22/2012 01:10 AM, Richard Yao wrote: On 06/22/2012 01:02 AM, Duncan wrote: Richard Yao posted on Thu, 21 Jun 2012 05:33:22 -0400 as excerpted: A firmware replacement for the BIOS does not need to worry about floppy drives, hard drives, optical drives, usb devices, isa devices, pci devices and pci express drives, etcetera, because those live on buses, which the kernel can detect. But you have to be able to load the kernel first, before it can do all that detection. And to load it, you need to be able to read the device it's located on, which in a modern x86 system (as contrasted with mips/ arm) generally means detection of what's there, some mechanism to choose which available devices to check for a kernel or boot loader or whatever, and some way to dynamically configure it, since many devices are simply (device info probable) bricks until configured, these days. Sure, you can boot directly to a Linux kernel /as/ your firmware (as Ian S suggested), but then you're back to hard-configuring it in ordered to do so, thus losing all that extra flexibility that's part of what makes x86 different. Which was the question that I was addressing. Placing it in the firmware is what I suggested. I also later stated that it is possible for the firmware to contain an initramfs that would enable it to start a kernel located on a device. It seems to me that this would work if device trees for motherboards were readily available and the EEPROM chips have sufficient capacity. I am under the impression that UEFI firmware is large enough that capacity on UEFI motherboards should not be an issue. The main issue would be obtaining device trees. Before anyone says it, information on how to initialize the memory controller and possibly a few other bits prior to loading the kernel is also necessary. I omitted that by mistake.
Re: [gentoo-dev] Re: My wishlist for EAPI 5
On Thu, 21 Jun 2012 20:38:17 -0400 Richard Yao r...@gentoo.org wrote: On 06/21/2012 04:29 AM, Duncan wrote: Richard Yao posted on Wed, 20 Jun 2012 16:50:33 -0400 as excerpted: On 06/20/2012 04:35 PM, Ciaran McCreesh wrote: On Wed, 20 Jun 2012 16:25:30 -0400 Richard Yao r...@gentoo.org wrote: POSIX Shell compliance So far as I know, every PM relies heavily upon bash anyway (and can't easily be made not to), so even if developers would accept having to rewrite all their eclasses, it still wouldn't remove the dep. Lets address POSIX compliance in the ebuilds first. Then we can deal with the package managers. Additionally, this is extremely unlikely because a number of developers insist on bash, to the extent that it would likely split gentoo in half if this were to be forced. It wouldn't pass council. It's unlikely to even /get/ to council. Openrc could move to POSIX shell because its primary dev at the time wanted it that way and it's only a single package. However, even then, doing it was controversial enough that said developer ended up leaving gentoo in-part over that, tho he did continue to develop openrc as a gentoo hosted project for quite some years. Now you're talking trying to do it for /every/ (well, almost every) package, thus touching every single gentoo dev. It's just not going to happen in even the medium term (say for argument APIs 5-7ish), let alone be something practical enough to implement, soon enough (even if everyone agreed on the general idea, they don't), to be anything like conceivable for EAPI5. So just let that one be. It's simply not worth tilting at that windmill. Would you (or someone else) elaborate on the specific features of bash that people find attractive? Local variables, reasonable behavior (like 'FOO=abc bar' where bar is macro), arrays, [[ ]] tests (which are obviously faster than calling external test program). One more use: printing useful die messages (in POSIX sh there's no way to do a backtrace). -- Best regards, Michał Górny signature.asc Description: PGP signature