gmane.linux.gentoo.devel

Re: Re: [RFC] What features should be included inEAPI 2?

Thomas Anderson — 2008-08-21T17:37:13

As someone who has worked with exheres, I very much want this phase for EAPI 2. It makes things simpler and more logical. Why should patching be done in _unpack? It shouldn't, and that's a reason why _prepare should be added. To me, yes

Re: Re: Re: Re: [RFC] What features should be included in EAPI 2?

Ciaran McCreesh — 2008-08-21T15:58:18

On Thu, 21 Aug 2008 16:35:18 +0100 Steve Long rathaus.eclipse.co.uk> wrote: What? Deliberately arguing against an idea because it comes from the wrong people, even though they're the only ones with the practical experience on the issue? Are you saying it is entirely up to him or that it should be entirely up to him? It's about making the ebuild language fit what most ebuilds do. This one's a developer-targeted feature. The benefit to users is that a) developers have a nicer package format to work with, and b) when they want to add patches to an ebuild locally, they don't have to know how to reimplement src_unpack correctly. And all of those are complicated features that can't be delivered with ten minutes work, which would mean delaying EAPI 2. You misunderstand, again. Exheres has two improvements on default functions: the default_*/default mechanism, and better default_ implementations. Portage is taking only the former for EAPI 2. Sure. You can do away with all the helpers and all the default functions in a future EAPI if you want. But all that'd do is make writing correct ebuilds much more tedious. Or, you can go the other way, as Exheres has, and improve the current lot of defaults to make writing ebuilds even easier. Neither src_configure nor src_prepare makes much difference to live ebuilds. Uhm. I think you're completely misunderstanding src_prepare. Go back and read the original email. If that's not clear enough for you, also have a look at how it's being used in Exherbo -- you can see plenty of practical examples. Then, once you've done so, please explain how the added simplicity and clarity is not a benefit.

Re: Re: Re: [RFC] What features should be included in EAPI 2?

Steve Long — 2008-08-21T15:35:18

Hmm fun as it isn't playing these games with you.. Which is no reason to add a new phase. OFC if zac wants to provide it that's entirely up to him. Oh so this is about correct nomenclature rather than anything else? I see. Yes, I see, because it's really needed; real functionality our users have been crying out for. Yes, a defined, configurable API for dealing with any version control would be useful, though your minion seemed to argue against it in #-portage. I can think of a couple of things that would be more useful to end-users: pkg_check for interactive ebuilds (eg license acceptance or media access), proper support for cross-compiling, integration of prefix, better handling of overlays, and of binpkgs.. Tsk of course not. default functions are in the pipeline in any case, but glad to see you're still using this list for proselytising your pet project while avoiding true discussion. In any event, it wouldn't be needed. As ever, you fail to argue the actual case, preferring to hide behind "the same reasons as.." which is a variant on the "if you don't understand some one line comment, you're not qualified to discuss anything (plus you're ugly.)" The reasoning others have given (yes it is possible to explain why without making people read thru 20 one line emails) is that this would be useful for live ebuilds. In maintenance terms (when looking at the lifecycle of an ebuild) I don't see the need, since there is no unpacking required from a vcs pull. Once it's made into a normal ebuild, any preparation would necessarily require review and might not be needed at all. Call the function what you like (or add a new phase with the hooks) it's still logically one point in time. For a live ebuild it's to prepare the src, for a normal one to (possibly) unpack and prepare. src_configure is a logically distinct action which warrants a new phase, since the e*conf call in compile makes retrying a long build (without having to recompile stuff which doesn't need it) much more difficult; its absence prevents full use of make. Prepare does not warrant a new phase imo since it should only be run once per compilation instance; anything it does can either be done in unpack, or in configure should that be more useful.

Re: License Interpretation

Sven Vermeulen — 2008-08-21T10:36:17

Actually (and I'm no lawyer either), I think a binary patch isn't allowed: The rest of the paragraph is about obtaining (or trying to obtain) its source code or application behavior, i.e. learn the program, not modify it. Wkr, Sven Vermeulen

Re: License Interpretation

Duncan — 2008-08-21T02:02:43

Richard Freeman gentoo.org> posted 48ACBFBC.4070902< at >gentoo.org, excerpted below, on Wed, 20 Aug 2008 21:07:08 -0400: It probably doesn't apply in this particular case, but note that Gentoo DOES distribute software in binary form on the LiveCDs, and prepackaged on the package-CDs as well. That definitely applies to GPLed works, for instance, and there's a discussion in the archive where it was pointed out that at the time, Gentoo wasn't in compliance, because we weren't ensuring our sources were available for three years, thus missing on the offer-to-provide, good-for-three-years, clause, AND we weren't always satisfying the make-sources-available-at-the-time-of-distribution alternative clause either. (In that, at the time, for conference distribution and the like, we often made available LiveCDs, without corresponding directly available at the time of distribution, copies of the sources used to create them, not just patches, but the complete sources.) This came up because it had been applied to Knoppix and etc and had forced them to change their ways, and Gentoo was interested in correcting the problem before it likewise became a legal one for us. Again, note that the license specifies all sources and scripts necessary to build, etc, NOT just distribution applied patches, which is what many were doing and what was catching them off guard. There was also some discussion of removing some of the outdated LiveCDs etc from distribution, so the three- year-clock could start ticking, since until distribution has ceased it is being continuously reset. Presumably that has been corrected now, and releng is properly archiving all sources used in the creation of the LiveCDs, etc, for three years after they've ceased distribution. The alternative, as mentioned, would be to ensure that sources are always made available at the time of distribution, including at conferences and the like. In either case, presumably we've stopped distributing historic LiveCDs and etc for which this was not done, so at least the 3-year clock is ticking, even if we can't easily go back and get the required sources should anyone call us on the 3-year thing before it expires.

Re: License Interpretation

Richard Freeman — 2008-08-21T01:07:08

Obviously I'm not a lawyer but I don't see an issue here. I don't see that Gentoo or its developers are in any way a party to this agreement. This is an agreement between Adobe and those who distribute its software. Some argue that EULAs also apply to those who use software (which is debatable), but Gentoo does not use this software either (to my knowledge). Gentoo distributes ebuilds - which are not the property of Adobe and are not derivative works of any of Adobe's software. A user who executes an ebuild might obtain a copy of an Adobe product that Adobe distributes. A user who executes an ebuild might create a derivative work of an Adobe product, and users who use proprietary software are advised to consult with lawyers as appropriate if they are concerned about the terms of license agreements that they may or may not be parties to. To me this is kind of like RiffTrax or similar along-side products that allow users to improve the experience of using a copyrighted work, but which are not themselves derivatives of copyrighted works. If a user using one of these products happens to create a derivative work that is a matter between them and the copyright owner. If such work is occurring without further distribution in an end-user context it is likely to be considered fair use. Gentoo doesn't distribute software (well, except to the degree that we mirror it). Gentoo makes it easier for users to use software that others distribute. As a result, Gentoo stays fairly clear of copyright law, and we do make a good-faith effort to not mirror content which we are not licensed to redistribute. That is my personal take on things like this, but again, I'm not a lawyer and others might not agree (makes no difference to me one way or another if you don't). :)

Re: License Interpretation

Robert Bridge — 2008-08-20T19:32:04

On Wed, 20 Aug 2008 15:10:18 -0400 Jim Ramsay gentoo.org> wrote: IANAL, but the following line is critical: Given the situation as you outline it, I think the sub-section above expressly permits the binary patch. The request has been made, Adobe have not co-operated, that clause has been invoked... At least, that's how I would read it. Rob.

License Interpretation

Jim Ramsay — 2008-08-20T19:10:18

IANAL, and I'm sure most of us aren't either, but I would appreciate some opinions on Bug https://bugs.gentoo.org/234542 and whether the binary patch proposed there conflicts with section 2.5.1 of the license agreement from Adobe: http://www.adobe.com/products/eulas/pdfs/Reader_Player_WWEULA-Combined-20060724_1430.pdf Specifically, here is the passage I'm wondering about: 2.5.1 You may not modify, adapt, translate or create derivative works based upon the Software. You may not reverse engineer, decompile, disassemble or otherwise attempt to discover the source code of the Software except to the extent you may be expressly permitted to decompile under applicable law, it is essential to do so in order to achieve operability of the Software with another software program, and you have first requested Adobe to provide the information necessary to achieve such operability and Adobe has not made such information available. I *think* I would be okay using this binary patch since: 1) This is specifically to make it operable with libcurl.so.4 2) I have (and others have) asked Adobe to recompile it with support for libcurl.so.4 instead of libcurl.so.3, but they have not done so (or responded to any of these requests, as far as I am aware). Anyone care to weigh in, lawyer or not?

Re: Re: News item: World file handling changes in Portage-2.2

Vaeth — 2008-08-20T08:13:42

Duncan wrote: One could avoid the confusion about world != < at >world completely, if one would simply rename < at >world into e.g. < at >worldfile Then one could define without any ambiguity world = < at >world = < at >worldfile + < at >system (and of course, one should then let < at >system not be a < at >worldfile candidate, at least by default). I am aware that currently < at >world is already implemented, but only in testing portage and probably not too many user scripts have been converted to this already (resp. _if_ they have been converted, they have most probably been converted from "world" to "< at >world < at >system" which would not harm either).

Re: News item: World file handling changes inPortage-2.2

Duncan — 2008-08-19T22:37:34

Joe Peterson gentoo.org> posted 48AB3EE7.3080000< at >gentoo.org, excerpted below, on Tue, 19 Aug 2008 15:45:11 -0600: I believe that's the way it is now, yes. Thus what we're proposing would simply keep the legacy meaning for world (and system) as they are, while < at >world (and < at >system) would refer to the specific sets. Now that it has been suggested, I do believe that's the simplest way to handle it, since it would involve no change at all for the existing words. < at >system would of course be the same as system, but there'd be a slight difference between world and < at >world. I think that's still less confusing, however, because people who don't care about the new functionality wouldn't have to worry about it, while for those that do, world could be simply explained as a legacy special-case. Since the only people worried about the difference between world and < at >world would be by definition the folks learning the new functionality anyway, that single legacy corner-case, once documented, shouldn't be a big deal. People learning < at >world can be told not to worry about the world case anyway, and just remember that sets always get < at >, and they're < at >world view (hehe, punny!) will once again be consistent. But I'm not one of the portage devs implementing it, so I'm not the one making the rules how the implementation should work. Someone (or ones, plural, yes I know someones isn't a valid plural, but anyway) else gets to decide all that. =8^)

Re: Re: Re: News item: World file handling changes inPortage-2.2

Joe Peterson — 2008-08-19T21:45:11

Ah, OK. I have been considering that "world" is simply a grandfathered name for "< at >world" (and same for system). I.e. that "world" is also specifying the world set, but that only world and system are allowed to have the "< at >" dropped to avoid breaking things for users. Isn't that the way the code treats it now? Or is "world" (no "< at >") really not a set? It just seems like that's the most common case (expecting "world" to include "< at >system" and "< at >world"), so if it doesn't, warn the user, and in the process migrate users to using "< at >" (to avoid the warning). True, but as Duncan discovered, if you leave off the -1, < at >system gets put in world_sets anyway, and some might want that. Then < at >world includes both. I know what you mean. And I'm not sure what makes most sense. It still seems potentially confusing for "world" and "< at >world" to mean different things. If the words were different, it would not seem that way. Yeah, I'd vote for that. -Joe

Re: Re: Re: [RFC] What features should be included in EAPI 2?

Ciaran McCreesh — 2008-08-19T20:43:53

On Tue, 19 Aug 2008 21:27:03 +0100 Steve Long rathaus.eclipse.co.uk> wrote: Oh really? Any reason you can provide for src_configure being useful can be used with slight modification for src_prepare. Yes, the 'unpack' in the name really does go along with the phase being used to prepare things. Make a phase for each common logically distinct operation. Which, with src_prepare being added, we almost have. (The one missing is a src_fetch_extra or somesuch, for use by the scm eclasses. But that wants special handling, and is probably best left to another EAPI...) Well, if you're proposing that Gentoo also adopts the more complicated default_* functions from exheres-0, you're more than welcome to write up a proposal... The same as the benefit of splitting src_compile into src_configure and src_compile, except that it'll be of use to a slightly larger proportion of ebuilds.

Re: Re: [RFC] What features should be included in EAPI 2?

Steve Long — 2008-08-19T20:27:03

Er, that would be the new src_configure? How so? From a user point of view, and from a maintenance point of view, src_configure is very useful. Yeah I've always seen src_unpack as being more cogent to preparation of src files, than to actually untarring stuff. So what? Why make a new phase which every new dev has to know about, and we have to provide pre_ and post_ hooks for, when the existing phase covers the usage fine? Well it's easy enough to auto-apply patches, given a declaration in the ebuild (since files for all versions are in the same dir.) It certainly doesn't need a new phase. So the real, fully-defined, explicit benefit is..

Re: Re: News item: World file handling changes inPortage-2.2

Steve Long — 2008-08-19T20:14:14

Yeah that was my thinking (only better expressed ;) I don't see that as major from a user pov; as soon as you see < at > you're in set territory, which is for finer-grained control. We already expect users to have the ability to read docs and the like, and this way we're not introducing any surprises; for the standard update procedure we're all used to, sets don't come into it. It's starting to get tricky.. ;) .. and we still get the issue that future usage would mean needing: emerge < at >world < at >system # or should it be the other way round? ..when we used to have a simple 'emerge world'[1]. I don't see how that helps our users. iow the change feels like a loss, not an improvement (which the set code certainly is), when a little tweaking with the option parser would mean we had both uses. I see it as polishing the UI, nothing more. Maybe there's a case for dropping system as a special-case over time, and giving a deprecation warning. Personally I don't see the problem with simply continuing to support it, or even changing to mean system without any user-defined stuff/ as per-profile; option parsing is hardly the bottleneck ;) [1] Assuming user doesn't want < at >world always including < at >system, which makes sense to a power-user who would be interested in sets, as Duncan showed.

Re: Gentoo Council Reminder for August 7

Robert Buchholz — 2008-08-19T18:35:23

If we are talking policies, can someone please define the term 'forecefully retired'? What about people whom had been complained about to devrel, and who then resigned? Does it include people who are retired due to inactivity? What benifit does this proposal have over an enforcement of the CoC on retired developers? If they choose to stay part of our community, any misbehaviour can also be penalized using that document. If they choose to stay and contribute properly, why ban them? I'm happy about all bugs I get, even by the most evil compile persons. Robert

Re: Re: [RFC] What features should be included in EAPI 2?

Ciaran McCreesh — 2008-08-19T18:18:04

On Tue, 19 Aug 2008 23:31:17 +0530 Arun Raghavan gentoo.org> wrote: It's not a huge issue, any more than src_configure is. Equally, it's not expensive to implement. In the grand scheme of things, no. In the grand scheme of things, you only *need* a single src_ function. From a maintainer convenience perspective, however, src_prepare is marginally more useful than having a split src_configure. It's a better mapping of the things ebuilds do than the current set of functions. The logic is this: lots of ebuilds end up duplicating src_unpack (or, in future EAPIs, calling 'default') and then adding things to do preparation work. Experience suggests that the most common reason for overriding src_unpack is to do preparation work, not to change how things are unpacked. (Number-wise... For Exherbo, where the split's already been made, custom src_prepare functions are three times more common than custom src_unpack functions. And that figure's significantly lower than what Gentoo would see, because with exheres-0 'default' functions you don't need to write a src_prepare if you're merely applying patches.) Such a system wouldn't be usable... Not all of Gentoo's patches are non-essential.

Re: Re: [RFC] What features should be included in EAPI 2?

Arun Raghavan — 2008-08-19T18:01:17

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ciaran McCreesh wrote: [...] a) Is this really an issue for maintainers? b) Does it really matter? c) So the flow will look like: ... src_unpack src_prepare src_configure src_compile ... To me this seems like an unnecessary overgeneralisation. The *only* potential "benefit" I see here is that at some point of time in the nebulous future, it might be possible to tell the PM to always skip src_prepare in order to give a system where everything is "vanilla". This is not something I see as being useful to us. - -- Arun -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkirCm0ACgkQ+Vqt1inD4uyTvQCgjEPHRCJUFrIsoyk5EnYb/jNC Lu8An0KTbHP59UXa4UcShSC7VwLUgQpI =zwPv -----END PGP SIGNATURE-----

media-fonts/droid licensing: should fonts include Apache licensein tarball?

Peter Volkov — 2008-08-19T13:25:42

Hello. There are droid fonts package in the tree. Author states that they are apache licensed [1] (supposedly similar to google's android sdk) but license itself is not included in the package (only .ttf files are there). Should we RESTRICT="mirror" in such case or it's safe to drop such restriction? [1] http://damieng.com/blog/2007/11/14/droid-sans-mono-great-coding-font Thank you for any hints,

Re: Re: [RFC] What features should be included in EAPI 2?

Ciaran McCreesh — 2008-08-19T12:45:30

On Tue, Aug 19, 2008 at 12:12 PM, Steve Long rathaus.eclipse.co.uk> wrote: Uh, count again. It's not just one line of typing saved. The benefit is that it's a logically separate action, and will avoid all the silliness of people repeatedly changing their minds about which phase should do the eautoreconf calls and so on.

Re: Re: News item: World file handling changes inPortage-2.2

Joe Peterson — 2008-08-19T12:42:57

The only drawback I see is that we would then have the following: < at >system == system ...but... < at >world != world This, I would think, could cause confusion too - and we'd have to live with and document this "quirk". How about issuing a warning when portage starts if the user specifies "world" (with no "< at >" sign) as the only specified target *and* < at >system is not in world_sets? It would warn that the world set no longer automatically includes system (i.e., < at >system) and also that it is better, from now on, to explicitly use the "< at >" sign for all sets like world and system (since these two are special cases grandfathered in). -Joe

Re: Gentoo Council Reminder for August 7

Mauricio Lima Pilla — 2008-08-19T12:31:33

Although it isn't feasible in practice, such a policy would allow us to defenestrate forcefully retired developers that keep coming back to mailing lists or channels with the same attitude that got then kicked, without having to resort to long process and waste of our human resources. We wouldn't have to go through the same process over and over again: if somebody was retired and keeps doing the same things as when was a developer, then people in charge of channels or mailing lists might take instant action as they find it necessary. If they get a new attitude after retired, I'm sure that the people in charge will not take the extra work to ban them for nothing. My R$ 0.02. Pilla