[gentoo-dev] Re: Patch applying function for EAPI 6
On Sun, 18 Aug 2013, Ulrich Mueller wrote: For EAPI 6, introduction of a patch applying function to the package manager itself is being discussed. This would serve two purposes: - support for PATCHES variable in a default src_install phase - a function to apply user patches In bug 463768 the conclusion so far was that implementing the full epatch function in the package manager is not feasible. Therefore, the package manager's implemention would have reduced functionality. The current epatch() would remain available in eutils.eclass for cases where its more advanced modes of operation are needed. The feature list we came up with (see bug 463768 comment 32) includes support for regular patch files, of course. It also includes support for directories, with patches applied in lexical order of their filenames (only files named *.diff and *.patch). So, the questions that I'd like to ask are: Summarising the answers below. 1. Is the above set of features reasonable? Nobody has replied to this one, so I assume that there are no objections. 2. Should the function do automatic -p* detection, or should it default to -p1? Both would be overridable by an explicit -p* option. There are good arguments for either variant (see the above-mentioned bug). Rick Zero_Chaos Farina: | Pretty please autodetection. It's a very nice feature that we seem | to already have sanely implemented. Michael Orlitzky: | With epatch() still available, my instinct is to leave the -p | detection out of PMS for now. The implementation details will be | messy otherwise, [...] Michał Górny: | I'm all for -p1. Instead of auto-detecting stuff on user's side, | we should provide developers with a simple tool that would | automatically 'fix' patches. Not many new arguments, beyond what we had in the bug already. I'd suggest that we follow the KISS principle and go with -p1. There's always epatch if you need more fancy stuff. 3. So far, we don't have a good name for the function. Only suggestion so far is dopatch. I don't really like it because other do* functions are called from src_install. But if nobody comes up with a better name, then it will be dopatch. Ulrich pgp8KqGzq44R0.pgp Description: PGP signature
Re: [gentoo-dev] Re: Patch applying function for EAPI 6
Dnia 2013-08-23, o godz. 11:45:57 Ulrich Mueller u...@gentoo.org napisał(a): 2. Should the function do automatic -p* detection, or should it default to -p1? Both would be overridable by an explicit -p* option. There are good arguments for either variant (see the above-mentioned bug). Rick Zero_Chaos Farina: | Pretty please autodetection. It's a very nice feature that we seem | to already have sanely implemented. Michael Orlitzky: | With epatch() still available, my instinct is to leave the -p | detection out of PMS for now. The implementation details will be | messy otherwise, [...] Michał Górny: | I'm all for -p1. Instead of auto-detecting stuff on user's side, | we should provide developers with a simple tool that would | automatically 'fix' patches. Not many new arguments, beyond what we had in the bug already. I'd suggest that we follow the KISS principle and go with -p1. There's always epatch if you need more fancy stuff. If we go this way, I will try to write a nice tool/wrapper that would help 'fixing' patches. Probably something that calls 'ebuild ... prepare' with hacked dopatch() that detects patchlevel and 'rebases' the patch automatically. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Patch applying function for EAPI 6
On Fri, 2013-08-23 at 11:45 +0200, Ulrich Mueller wrote: On Sun, 18 Aug 2013, Ulrich Mueller wrote: For EAPI 6, introduction of a patch applying function to the package manager itself is being discussed. This would serve two purposes: - support for PATCHES variable in a default src_install phase - a function to apply user patches 3. So far, we don't have a good name for the function. Only suggestion so far is dopatch. I don't really like it because other do* functions are called from src_install. But if nobody comes up with a better name, then it will be dopatch. Ulrich What about: srcpatch() userpatch() If it is for applying user patches, then I prefer userpatch(). It also gets away from the do*() naming. I take it PATCHES variable will be a bash array, or space separated list? signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Patch applying function for EAPI 6
On Fri, 23 Aug 2013, Brian Dolbec wrote: Only suggestion so far is dopatch. I don't really like it because other do* functions are called from src_install. But if nobody comes up with a better name, then it will be dopatch. What about: srcpatch() Hm, that looks like a phase function. userpatch() If it is for applying user patches, then I prefer userpatch(). It also gets away from the do*() naming. User patches would be applied in a separate function. It would call the one we're discussing here, of course. I take it PATCHES variable will be a bash array, or space separated list? Yes, it will be an array. But I guess we will support a space separated list in addition, for consistency with DOCS. Ulrich
Re: [gentoo-dev] Re: Patch applying function for EAPI 6
Dnia 2013-08-23, o godz. 13:35:11
Ulrich Mueller u...@gentoo.org napisał(a):
I take it PATCHES variable will be a bash array, or space separated
list?
Yes, it will be an array. But I guess we will support a space
separated list in addition, for consistency with DOCS.
This would be very bad since most patches use ${FILESDIR}. Putting that
in a plain string sounds like final bullet in whitespace-in-filename
support. Not that it's anywhere near supported most of the place.
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
Re: [gentoo-dev] Re: Patch applying function for EAPI 6
On Fri, 23 Aug 2013, Michał Górny wrote:
Yes, it will be an array. But I guess we will support a space
separated list in addition, for consistency with DOCS.
This would be very bad since most patches use ${FILESDIR}.
Putting that in a plain string sounds like final bullet in
whitespace-in-filename support.
Sure, but I thought it was self-evident that you cannot put anything
that needs quoting into a whitespace separated list. Thinking about
it, the cases where there isn't an absolute path should be rare,
indeed. So maybe non-array support isn't very useful.
Not that it's anywhere near supported most of the place.
Many upstream build systems fail with it. Sorry, no C:\Portage Tree\
for the forseeable future. ;-)
Ulrich
Re: [gentoo-dev] Re: Gnome Stabilization 3.6 or 3.8
On Sat, Aug 10, 2013: Tom Wijsman wrote: Steven J. Long wrote: The core system has to be a usable basis to build everything from. I do agree with this except for shaky; it is a nice goal to pursue... That still does not make us able to do it or make it a realistic goal. But it's exactly what the standard Gentoo install supplies, or used to. So it's very realistic, since it's the basis we've been using for a decade. And you are able to do it. Losing that capability is nothing more or less than a regression for a meta-distribution. Making such a design choice isn't a fault. There is no need for blame. Design choices have consequences in terms of where manpower can go, as well as in terms of end-user capability and flexibility, especially when one of the options has far-reaching implications for the rest of the stack, such that it is a question of my way or the high way, which seems counter to the idea of choice i hear so much about. My way or the high way is giving good service to just a set of users, because you can't listen and support everyone with limited resources; as a result it causes alternatives to be created, effectively giving choice. This is a total non-sequitur, given that we already have choice. Taking it away does not create choice: it merely restricts everyone until a hate fork happens, or some other alternative is provided, to restore the previous state of affairs. Though to be honest, your argument is more akin to a conceptual discussion as to whether an argument could be made rather than what is the best way forward in the long-term for the diverse user-base. Not very practical, imo. Giving service to a set of users is not at all the same as my way or the high way. The latter is what happens when you get non-modular software that tries to do too much, under the banner of One True Way to disguise the awful coupling, however it's dressed up. The former is what happens when you install say an httpd to serve an intranet. It doesn't dictate what other pieces of software you can use for orthogonal purposes (or suddenly expand its feature-base to include everything else so it isn't orthogonal any more.) This is a natural thing to happen, as everything supporting everything does not sound possible at all; it is therefore unrealistic. What's unrealistic is expecting us to swallow regressions as progress. So it's perfectly reasonable for them to be questioned and criticised. Not sure what and whom you mean to refer to by this. Design choices. Hell, that's one of the main purposes of this list; it's why the GLEP process mentions the list, for example. Sorry for delay, missed this in my inbox. Regards, steveL. -- #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
Re: [gentoo-dev] Re: Gnome Stabilization 3.6 or 3.8
On Fri, 23 Aug 2013 14:27:02 +0100 Steven J. Long sl...@rathaus.eclipse.co.uk wrote: On Sat, Aug 10, 2013: Tom Wijsman wrote: Steven J. Long wrote: The core system has to be a usable basis to build everything from. I do agree with this except for shaky; it is a nice goal to pursue... That still does not make us able to do it or make it a realistic goal. But it's exactly what the standard Gentoo install supplies, or used to. So it's very realistic, since it's the basis we've been using for a decade. You start from something small, which does the described thing; but once you grow to something bigger, you are suddenly no longer able to satisfy that description. In order to continue to grow bigger, you need to cut corners and take decisions; in other words, you can no longer hold on to the prototype that was made but start to need to face the realism that is out there. Just because you can start with something, doesn't mean it is scalable; supporting more comes at its own cost, which may not give enough ROI. And you are able to do it. At the cost of other things; so, in the whole picture, one can think of it as an unrealistic goal unless someone does want to do all the work without leaving other users that use the software product in the dark. Losing that capability is nothing more or less than a regression for a meta-distribution. It is as much a loss as it is a gain; a software product that doesn't deal with bugs because it has to be busy with supporting everything that is out there, is going to leave other regressions behind as well. Design choices have consequences in terms of where manpower can go, as well as in terms of end-user capability and flexibility, especially when one of the options has far-reaching implications for the rest of the stack, such that it is a question of my way or the high way, which seems counter to the idea of choice i hear so much about. My way or the high way is giving good service to just a set of users, because you can't listen and support everyone with limited resources; as a result it causes alternatives to be created, effectively giving choice. This is a total non-sequitur, given that we already have choice. You have a choice, but don't have support for it; it is still their choice whether to choose to support you, and when they do, they are giving less support in other places as a result of a cost in time. Taking it away does not create choice: it merely restricts everyone until a hate fork happens, or some other alternative is provided, to restore the previous state of affairs. Well, such happenings would introduce a supported choice. Though to be honest, your argument is more akin to a conceptual discussion as to whether an argument could be made rather than what is the best way forward in the long-term for the diverse user-base. Not very practical, imo. As long as nobody wants to do the work, it remains conceptual; the best way forward is to work with what we are given, until someone gives us what we want or we really want to do the work we want ourselves. Giving service to a set of users is not at all the same as my way or the high way. The latter is what happens when you get non-modular software that tries to do too much, under the banner of One True Way to disguise the awful coupling, however it's dressed up. There are not a lot of products that can give service to everyone; so, people use what they believe is the One True Way for them. The former is what happens when you install say an httpd to serve an intranet. It doesn't dictate what other pieces of software you can use for orthogonal purposes (or suddenly expand its feature-base to include everything else so it isn't orthogonal any more.) When you buy a small row house without a garage or a ramp; you will not be able to park your car in your just bought house. If you try to do it anyway, you will break it. This is a natural thing to happen, as everything supporting everything does not sound possible at all; it is therefore unrealistic. What's unrealistic is expecting us to swallow regressions as progress. The opposite is also unrealistic; so, they had to make a design choice. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] Moving more arches to dev profiles
On Thu, 22 Aug 2013 12:28:24 +0100 Markos Chandras hwoar...@gentoo.org wrote: Wow! That is something we actively encourage people to avoid. Mixed systems are totally unsupported and I am sure quite a few bugs are closed as invalid when a mixed system is detected. It may work on regular basis but encouraging and supporting such configurations is definitely not desirable. It's also a bit ehm, funny, to give them a stable stage3 and then tell them that for everything else, please use ~arch. Really? So you’re telling me that if I want Drupal on my Web server, which if it breaks then takes a few minutes to revert to the previous version and has virtually zero chance of taking anything else down with it, then it’s “definitely not desirable…to encourage” me to use mixed keywords—instead I should be using ~arch versions of, say, glibc, iproute2, openssh, openrc, and the kernel, every single one of which, should it break, would be fixable only with a bus ride across the city, access to a locked room, wiring up a keyboard and monitor, and possibly booting from a live disk? There’s breakage of one package, and then there’s breakage of the *system*. Running mixed versions may increase the chance of breakage of the particular package that’s ~arch as compared to running a full ~arch system, but as long as that package isn’t part of or needed by the system boot process, I can’t see how mixed versions could do anything but decrease the chance of breakage of the system as a whole. Chris signature.asc Description: PGP signature
