Re: [gentoo-dev] RFD: EAPI specification in ebuilds
On 9 March 2012 06:30, Jeroen Roovers wrote:
> On Thu, 8 Mar 2012 17:14:58 +
> Ciaran McCreesh wrote:
>
>> Having a different, special rule for something that looks exactly like
>> lots of other things that do not have that different, special rule is
>> hardly hair splitting. This rule would have to be documented and have
>> special code to carefully enforce it. That's a big deal.
>
> Exactly like HOMEPAGE is a big deal?
>
> HOMEPAGE Package's homepage. If you are unable to locate an
> official one, try to provide a link to freshmeat.net or a similar
> package tracking site. Never refer to a variable name in the string;
> include only raw text.
I'm not sure if that is a good example of "things that are weird like EAPI"
You can set HOMEPAGE in an eclass for instance, using anything you can
do with bash and build it out of substrings.
perl-module.eclass does just that.
[[ -z "${HOMEPAGE}" ]] && \
HOMEPAGE="http://search.cpan.org/dist/${MY_PN:-${PN}}/";
Not really comparable in entirety to EAPI.
--
Kent
perl -e "print substr( \"edrgmaM SPA NOcomil.ic\\@tfrken\", \$_ * 3,
3 ) for ( 9,8,0,7,1,6,5,4,3,2 );"
Re: [gentoo-dev] media-optical, net-zope, sgml, text-markup herds are empty
El vie, 09-03-2012 a las 21:15 +0100, Pacho Ramos escribió: > El vie, 09-03-2012 a las 22:02 +0200, Samuli Suominen escribió: > > On 03/09/2012 09:48 PM, Pacho Ramos wrote: > > > El vie, 09-03-2012 a las 16:57 +0100, Michał Górny escribió: > > >> On Fri, 09 Mar 2012 09:02:23 +0100 > > >> Pacho Ramos wrote: > > >> > > >>> El dom, 04-03-2012 a las 13:56 +0100, Pacho Ramos escribió: > > El dom, 04-03-2012 a las 13:51 +0100, Pacho Ramos escribió: > > > El dom, 04-03-2012 a las 13:47 +0100, Pacho Ramos escribió: > > >> Even if they have some people in their mail aliases, looks like > > >> herds are empty. If nobody volunteers to join to them, I think > > >> we should drop that herds and move their packages to > > >> maintainer-needed in a week or so. > > >> > > >> What do you think? > > >> > > > > > > The same applies to "sgml" now that cryos is retiring :( > > > > and text-markup, I think it's the last empty herd now > > >>> > > >>> Maybe we could do the same as did in the past for openoffice herd: > > >>> - Change metadatas and bugs to assign them to maintainer-needed (and > > >>> reflect reality) > > >>> - Keep herd in metadatas and CCed them to bug reports > > >>> > > >>> The other option would be to simply drop that herds, assign packages > > >>> to maintainer-needed and wait developers to grab whatever they want > > >> > > >> For net-zope, I'd prefer dropping it. We decided to get rid of Zope, > > >> removed almost all relevant packages, so there's no point in keeping > > >> the herd. > > >> > > > > > > OK but, what about the rest? ;) > > > > Please leave at least media-optical@ be as it is. Changing it doesn't > > make any sense. > > > > > > Well, the idea would be to get their bugs assigned to maintainer-needed > and media-optical CCed if somebody wants to take that stuff someday, it > would reflect better reality as, currently, their bugs are being > assigned to an empty herd (yes, xarthisius (I think he was in alias but > not officially in herd last time I checked, anyway it's only one > example, nothing personal against him of course :)). What will occur > when he simply drops his mail from alias as he never wanted to be a > member of that herd? What would occur if he only wants to maintain some > packages but others are getting ignored? > > The idea to get them moved to "orphan" is to reflect reality and, that > way, try to get developers (or users willing to proxy maintain them) > involved on exact apps they really want to keep maintained. As talked just now with Samuli, he added him to media-optical (both, to alias and herds.xml) and then, this no longer applies to media-optical obviously ;) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] media-optical, net-zope, sgml, text-markup herds are empty
El vie, 09-03-2012 a las 22:02 +0200, Samuli Suominen escribió: > On 03/09/2012 09:48 PM, Pacho Ramos wrote: > > El vie, 09-03-2012 a las 16:57 +0100, Michał Górny escribió: > >> On Fri, 09 Mar 2012 09:02:23 +0100 > >> Pacho Ramos wrote: > >> > >>> El dom, 04-03-2012 a las 13:56 +0100, Pacho Ramos escribió: > El dom, 04-03-2012 a las 13:51 +0100, Pacho Ramos escribió: > > El dom, 04-03-2012 a las 13:47 +0100, Pacho Ramos escribió: > >> Even if they have some people in their mail aliases, looks like > >> herds are empty. If nobody volunteers to join to them, I think > >> we should drop that herds and move their packages to > >> maintainer-needed in a week or so. > >> > >> What do you think? > >> > > > > The same applies to "sgml" now that cryos is retiring :( > > and text-markup, I think it's the last empty herd now > >>> > >>> Maybe we could do the same as did in the past for openoffice herd: > >>> - Change metadatas and bugs to assign them to maintainer-needed (and > >>> reflect reality) > >>> - Keep herd in metadatas and CCed them to bug reports > >>> > >>> The other option would be to simply drop that herds, assign packages > >>> to maintainer-needed and wait developers to grab whatever they want > >> > >> For net-zope, I'd prefer dropping it. We decided to get rid of Zope, > >> removed almost all relevant packages, so there's no point in keeping > >> the herd. > >> > > > > OK but, what about the rest? ;) > > Please leave at least media-optical@ be as it is. Changing it doesn't > make any sense. > > Well, the idea would be to get their bugs assigned to maintainer-needed and media-optical CCed if somebody wants to take that stuff someday, it would reflect better reality as, currently, their bugs are being assigned to an empty herd (yes, xarthisius (I think he was in alias but not officially in herd last time I checked, anyway it's only one example, nothing personal against him of course :)). What will occur when he simply drops his mail from alias as he never wanted to be a member of that herd? What would occur if he only wants to maintain some packages but others are getting ignored? The idea to get them moved to "orphan" is to reflect reality and, that way, try to get developers (or users willing to proxy maintain them) involved on exact apps they really want to keep maintained. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] RFD: EAPI specification in ebuilds
On 03/09/12 13:56, Zac Medico wrote: > On 03/09/2012 10:33 AM, Michael Orlitzky wrote: >> On 03/09/12 13:02, James Broadhead wrote: >>> On 9 March 2012 17:31, Michael Orlitzky wrote: At any rate, I'm now convinced that we all want GLEP 55, but with a different name. >>> >>> I think that moving the data to the filename is probably a better >>> approach than semi- or repeat parsing, but I prefer preserving the >>> .ebuild extension, and think that eapi should be specified similarly >>> to ebuild revision, as a suffix. for instance: >>> >>> app-foo/bar-1.0.0-r1.ebuild # EAPI0 (or the highest EAPI prior to the >>> new schema) >>> app-foo/bar-1.0.0-r1-e1.ebuild >>> app-foo/bar-1.0.0-r1-e99.ebuild >>> >> >> One of the benefits of GLEP 55 naming is that old package managers won't >> try to parse them. So, for example, if we put new features in, >> >> app-foo/bar-1.0.0.ebuild-5 >> >> portage from 2003 won't try to source it. > > Every software product has an end of life. I think if a system hasn't > been updated in the last 2 years or so, then it's fair to assume that it > will never be updated. So, all relevant versions of portage should > simply show a warning message if the encounter an ebuild name such as > "app-foo/bar-1.0.0-r1-e99.ebuild". I was just repeating your point against the eapi function =) And there is a non-zero benefit to it, I've had to rescue systems that haven't seen an update in years. The best reason I can think of for using ebuild-EAPI is simply semantic. The basename of the ebuild refers to the package, the extension decides what interprets it. That is at least consistent with every other file extension.
Re: [gentoo-dev] media-optical, net-zope, sgml, text-markup herds are empty
On 03/09/2012 09:48 PM, Pacho Ramos wrote: El vie, 09-03-2012 a las 16:57 +0100, Michał Górny escribió: On Fri, 09 Mar 2012 09:02:23 +0100 Pacho Ramos wrote: El dom, 04-03-2012 a las 13:56 +0100, Pacho Ramos escribió: El dom, 04-03-2012 a las 13:51 +0100, Pacho Ramos escribió: El dom, 04-03-2012 a las 13:47 +0100, Pacho Ramos escribió: Even if they have some people in their mail aliases, looks like herds are empty. If nobody volunteers to join to them, I think we should drop that herds and move their packages to maintainer-needed in a week or so. What do you think? The same applies to "sgml" now that cryos is retiring :( and text-markup, I think it's the last empty herd now Maybe we could do the same as did in the past for openoffice herd: - Change metadatas and bugs to assign them to maintainer-needed (and reflect reality) - Keep herd in metadatas and CCed them to bug reports The other option would be to simply drop that herds, assign packages to maintainer-needed and wait developers to grab whatever they want For net-zope, I'd prefer dropping it. We decided to get rid of Zope, removed almost all relevant packages, so there's no point in keeping the herd. OK but, what about the rest? ;) Please leave at least media-optical@ be as it is. Changing it doesn't make any sense.
Re: [gentoo-dev] media-optical, net-zope, sgml, text-markup herds are empty
El vie, 09-03-2012 a las 16:57 +0100, Michał Górny escribió: > On Fri, 09 Mar 2012 09:02:23 +0100 > Pacho Ramos wrote: > > > El dom, 04-03-2012 a las 13:56 +0100, Pacho Ramos escribió: > > > El dom, 04-03-2012 a las 13:51 +0100, Pacho Ramos escribió: > > > > El dom, 04-03-2012 a las 13:47 +0100, Pacho Ramos escribió: > > > > > Even if they have some people in their mail aliases, looks like > > > > > herds are empty. If nobody volunteers to join to them, I think > > > > > we should drop that herds and move their packages to > > > > > maintainer-needed in a week or so. > > > > > > > > > > What do you think? > > > > > > > > > > > > > The same applies to "sgml" now that cryos is retiring :( > > > > > > and text-markup, I think it's the last empty herd now > > > > Maybe we could do the same as did in the past for openoffice herd: > > - Change metadatas and bugs to assign them to maintainer-needed (and > > reflect reality) > > - Keep herd in metadatas and CCed them to bug reports > > > > The other option would be to simply drop that herds, assign packages > > to maintainer-needed and wait developers to grab whatever they want > > For net-zope, I'd prefer dropping it. We decided to get rid of Zope, > removed almost all relevant packages, so there's no point in keeping > the herd. > OK but, what about the rest? ;) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] RFD: EAPI specification in ebuilds
On Fri, 09 Mar 2012 10:56:03 -0800 Zac Medico wrote: > Every software product has an end of life. I think if a system hasn't > been updated in the last 2 years or so, then it's fair to assume that > it will never be updated. So, all relevant versions of portage should > simply show a warning message if the encounter an ebuild name such as > "app-foo/bar-1.0.0-r1-e99.ebuild". It's worth noting that "showing a warning message" will result in zillions of freaking out users, and that we want to be able to introduce new EAPIs without having a stable Portage version that handles it around. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] RFD: EAPI specification in ebuilds
On Fri, 09 Mar 2012 11:49:44 -0500 Michael Orlitzky wrote: > >> isnt the whole point of the proposal to get eapi without sourcing ? > >> > >> so that we can use new bash features at local or global scope > >> without risking that people with an old bash get syntax errors > >> trying to get the eapi > > > > Right. Michael has lost sight of the goal and is moving off on a > > tangent. > > The point was to be able to get the EAPI without crashing if the > ebuild uses newer features. No, it's not. There's more to it than that. Some EAPIs really require defining certain environment variables, shell options, sandbox things etc *before* the sourcing starts. It's a massive pain in the ass to try to handle setting that kind of thing on the fly once the sourcing has already started. Knowing the EAPI before having to spawn a bash process isn't just about performance, it's also about making ebuilds much less difficult to deal with. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] RFD: EAPI specification in ebuilds
On Fri, Mar 9, 2012 at 12:47 PM, Zac Medico wrote: > Anyway, lets focus on our main goal, which is to decide on a way to > obtain the EAPI _without_ sourcing the ebuild. Agreed. Plus, an approach that either uses the filename or something like a comment line is also going to be much more flexible if bash syntax changes substantially, or if we want to support ebuilds-in-python or some other approach. That is the main merit I see to the shebang approach - you could define some kind of API that actually involves executing the ebuild. Sticking the EAPI in the filename is a little less complicated and it gives you the same flexibility - I'm not aware of any file format that is fussy about the content of the filename. Even approaches like putting EAPI=5 in the file (even inside a comment) might break if the file is meant to be generally interpreted by some program that has rigid syntax rules.Most scripting languages could probably handle this somehow, but if you ever wanted ELF ebuilds that wouldn't be so likely to fly unless you could embed \nEAPI=ELF8\n in something near the start of the file. Sure, I doubt we'll ever want ELF ebuilds (I'd consider non-programatic ebuilds for more trivial packages more likely), but the point is that we should prefer options that offer more flexibility down the road over ones that solve the immediate need but just leave us with the same debate two years from now. Rich
Re: [gentoo-dev] RFD: EAPI specification in ebuilds
On 03/09/2012 10:33 AM, Michael Orlitzky wrote: > On 03/09/12 13:02, James Broadhead wrote: >> On 9 March 2012 17:31, Michael Orlitzky wrote: >>> At any rate, I'm now convinced that we all want GLEP 55, but with a >>> different name. >> >> I think that moving the data to the filename is probably a better >> approach than semi- or repeat parsing, but I prefer preserving the >> .ebuild extension, and think that eapi should be specified similarly >> to ebuild revision, as a suffix. for instance: >> >> app-foo/bar-1.0.0-r1.ebuild # EAPI0 (or the highest EAPI prior to the >> new schema) >> app-foo/bar-1.0.0-r1-e1.ebuild >> app-foo/bar-1.0.0-r1-e99.ebuild >> > > One of the benefits of GLEP 55 naming is that old package managers won't > try to parse them. So, for example, if we put new features in, > > app-foo/bar-1.0.0.ebuild-5 > > portage from 2003 won't try to source it. Every software product has an end of life. I think if a system hasn't been updated in the last 2 years or so, then it's fair to assume that it will never be updated. So, all relevant versions of portage should simply show a warning message if the encounter an ebuild name such as "app-foo/bar-1.0.0-r1-e99.ebuild". -- Thanks, Zac
Re: [gentoo-dev] RFD: EAPI specification in ebuilds
On 03/09/12 13:02, James Broadhead wrote: > On 9 March 2012 17:31, Michael Orlitzky wrote: >> At any rate, I'm now convinced that we all want GLEP 55, but with a >> different name. > > I think that moving the data to the filename is probably a better > approach than semi- or repeat parsing, but I prefer preserving the > .ebuild extension, and think that eapi should be specified similarly > to ebuild revision, as a suffix. for instance: > > app-foo/bar-1.0.0-r1.ebuild # EAPI0 (or the highest EAPI prior to the > new schema) > app-foo/bar-1.0.0-r1-e1.ebuild > app-foo/bar-1.0.0-r1-e99.ebuild > One of the benefits of GLEP 55 naming is that old package managers won't try to parse them. So, for example, if we put new features in, app-foo/bar-1.0.0.ebuild-5 portage from 2003 won't try to source it.
Re: [gentoo-dev] RFD: EAPI specification in ebuilds
On 03/09/2012 10:24 AM, Alexis Ballier wrote: > On Fri, 9 Mar 2012 18:02:51 + > James Broadhead wrote: > >> On 9 March 2012 17:31, Michael Orlitzky wrote: >>> At any rate, I'm now convinced that we all want GLEP 55, but with a >>> different name. >> >> I think that moving the data to the filename is probably a better >> approach than semi- or repeat parsing, but I prefer preserving the >> .ebuild extension, and think that eapi should be specified similarly >> to ebuild revision, as a suffix. for instance: >> >> app-foo/bar-1.0.0-r1.ebuild # EAPI0 (or the highest EAPI prior to the >> new schema) >> app-foo/bar-1.0.0-r1-e1.ebuild >> app-foo/bar-1.0.0-r1-e99.ebuild >> > > if you want to keep .ebuild you need to keep current naming, afaik > package managers fail on invalid names Invalid names like those should only trigger warnings. -- Thanks, Zac
Re: [gentoo-dev] RFD: EAPI specification in ebuilds
On Fri, 9 Mar 2012 18:02:51 + James Broadhead wrote: > On 9 March 2012 17:31, Michael Orlitzky wrote: > > At any rate, I'm now convinced that we all want GLEP 55, but with a > > different name. > > I think that moving the data to the filename is probably a better > approach than semi- or repeat parsing, but I prefer preserving the > .ebuild extension, and think that eapi should be specified similarly > to ebuild revision, as a suffix. for instance: > > app-foo/bar-1.0.0-r1.ebuild # EAPI0 (or the highest EAPI prior to the > new schema) > app-foo/bar-1.0.0-r1-e1.ebuild > app-foo/bar-1.0.0-r1-e99.ebuild > if you want to keep .ebuild you need to keep current naming, afaik package managers fail on invalid names
Re: [gentoo-dev] RFD: EAPI specification in ebuilds
On 03/09/12 12:47, Zac Medico wrote: > > Ulrich is talking about extensions which require a newer version of > bash. These kinds of extensions are quite common and don't cause > "massive breaking" because people simply have to upgrade bash in order > to use the new extensions, and their old scripts continue to run because > the new extensions don't interfere with backward compatibility. > > Your eapi() function proposal is especially fragile in this context > because it assumes that the installed version of bash will be able to > execute a script that may target a newer version of bash. This is a > special case that is typically not a problem, although it is a major > problem under the specific conditions that your eapi() function approach > induces. Well, you wouldn't need to execute the script targeting a newer version of bash. You would need to source it, which involves maybe setting EAPI=5, and then calling the 'eapi' function which will immediately exit. The new features aren't a problem because you never get to them. (If you try to use some new bash extension to compute your EAPI value, well, you shouldn't have done that.) > Anyway, lets focus on our main goal, which is to decide on a way to > obtain the EAPI _without_ sourcing the ebuild. Agreed. I'm forced to agree with Ciaran: can we just ignore the previous council's decision, and reconsider the merits of GLEP 55?
Re: [gentoo-dev] RFD: EAPI specification in ebuilds
On 9 March 2012 17:31, Michael Orlitzky wrote: > At any rate, I'm now convinced that we all want GLEP 55, but with a > different name. I think that moving the data to the filename is probably a better approach than semi- or repeat parsing, but I prefer preserving the .ebuild extension, and think that eapi should be specified similarly to ebuild revision, as a suffix. for instance: app-foo/bar-1.0.0-r1.ebuild # EAPI0 (or the highest EAPI prior to the new schema) app-foo/bar-1.0.0-r1-e1.ebuild app-foo/bar-1.0.0-r1-e99.ebuild
Re: [gentoo-dev] RFD: EAPI specification in ebuilds
On Fri, 09 Mar 2012 12:31:24 -0500 Michael Orlitzky wrote: > On 03/09/12 12:11, Ulrich Mueller wrote: > >> On Fri, 09 Mar 2012, Michael Orlitzky wrote: > > > >>> What if bash starts to parse the script completely and barfs at > >>> 'syntax error' before it starts executing stuff? > > > >> It doesn't parse the script completely, it executes line-by-line, > >> so we can bail out early. > > > > How can you tell that this behaviour won't be changed in a future > > bash version? > > > > Who's to say that in the future my computer won't be made out of > delicious ice cream, eliminating the need for EAPIs entirely? > > Chances are, this would break thousands of scripts, so we hope they > wouldn't do it. If it does happen, we either deal with it then, or > don't upgrade to that version of bash -- the same as we would do with > any other massive breaking change. Thousands of scripts? So... you're saying that people actually use thousands of scripts which have invalid syntax... Well, one thing I can think of now is makeself and similar. Those are indeed a quite good argument. But the main point here is that at some point someone may want to use a non-bash syntax for ebuilds. Or some kind of optional bash extension. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] RFD: EAPI specification in ebuilds
On 03/09/2012 09:31 AM, Michael Orlitzky wrote: > On 03/09/12 12:11, Ulrich Mueller wrote: >>> On Fri, 09 Mar 2012, Michael Orlitzky wrote: >> What if bash starts to parse the script completely and barfs at 'syntax error' before it starts executing stuff? >> >>> It doesn't parse the script completely, it executes line-by-line, so >>> we can bail out early. >> >> How can you tell that this behaviour won't be changed in a future bash >> version? >> > > Who's to say that in the future my computer won't be made out of > delicious ice cream, eliminating the need for EAPIs entirely? > > Chances are, this would break thousands of scripts, so we hope they > wouldn't do it. If it does happen, we either deal with it then, or don't > upgrade to that version of bash -- the same as we would do with any > other massive breaking change. Ulrich is talking about extensions which require a newer version of bash. These kinds of extensions are quite common and don't cause "massive breaking" because people simply have to upgrade bash in order to use the new extensions, and their old scripts continue to run because the new extensions don't interfere with backward compatibility. Your eapi() function proposal is especially fragile in this context because it assumes that the installed version of bash will be able to execute a script that may target a newer version of bash. This is a special case that is typically not a problem, although it is a major problem under the specific conditions that your eapi() function approach induces. Anyway, lets focus on our main goal, which is to decide on a way to obtain the EAPI _without_ sourcing the ebuild. -- Thanks, Zac
Re: [gentoo-dev] RFD: EAPI specification in ebuilds
On 03/09/12 12:11, Ulrich Mueller wrote: >> On Fri, 09 Mar 2012, Michael Orlitzky wrote: > >>> What if bash starts to parse the script completely and barfs at >>> 'syntax error' before it starts executing stuff? > >> It doesn't parse the script completely, it executes line-by-line, so >> we can bail out early. > > How can you tell that this behaviour won't be changed in a future bash > version? > Who's to say that in the future my computer won't be made out of delicious ice cream, eliminating the need for EAPIs entirely? Chances are, this would break thousands of scripts, so we hope they wouldn't do it. If it does happen, we either deal with it then, or don't upgrade to that version of bash -- the same as we would do with any other massive breaking change. At any rate, I'm now convinced that we all want GLEP 55, but with a different name.
Re: [gentoo-dev] RFD: EAPI specification in ebuilds
> On Fri, 09 Mar 2012, Michael Orlitzky wrote: >> What if bash starts to parse the script completely and barfs at >> 'syntax error' before it starts executing stuff? > It doesn't parse the script completely, it executes line-by-line, so > we can bail out early. How can you tell that this behaviour won't be changed in a future bash version? Ulrich
Re: [gentoo-dev] RFD: EAPI specification in ebuilds
On 03/09/2012 08:49 AM, Michael Orlitzky wrote: > The point was to be able to get the EAPI without crashing if the ebuild > uses newer features. If you can get the EAPI without sourcing, that > obviously accomplishes the goal. But there are other goals, too, like > not limiting the syntax of the EAPI assignment. I was just trying to > think up something that addresses them all. Yeah, but you compromised on what can be considered our primary goal, which is to obtain the EAPI without sourcing the ebuild. > In any case, yeah, it would crash and burn if someone synced his tree > with an ancient version of portage. But so would the comment solution. Don't forget the possibility of bash syntax extensions triggering a syntax error [1]. The comment and bash assignment solutions are immune to that because bash is exceedingly unlikely to break backward compatibility in the comment and bash assignment syntax. [1] http://archives.gentoo.org/gentoo-dev/msg_2c1fbbb32f5bc47756303ca18055bee4.xml -- Thanks, Zac
Re: [gentoo-dev] RFD: EAPI specification in ebuilds
On 03/09/12 11:29, Michał Górny wrote:
>
> What if bash starts to parse the script completely and barfs at 'syntax
> error' before it starts executing stuff?
>
It doesn't parse the script completely, it executes line-by-line, so we
can bail out early.
This returns 1:
exit 1
QWE*$)@#$%IT@$KTRGV{PO#J$%$M@#$_)TVI!%K@B)$YJMV$%())@K#@)
Re: [gentoo-dev] RFD: EAPI specification in ebuilds
On 03/09/12 10:58, Zac Medico wrote: > On 03/09/2012 07:51 AM, Alexis Ballier wrote: >> On Fri, 09 Mar 2012 07:41:09 -0800 >> Zac Medico wrote: >> >>> On 03/09/2012 07:21 AM, Michael Orlitzky wrote: The advantage that the eapi function has over a comment is that it's not magic -- it's just normal bash syntax. So we've addressed that issue at a small performance cost (we're really only sourcing the ebuild up to 'exit'). >>> >>> Also consider the case where a user syncs after not having updated >>> for a couple of months, and the tree contains some ebuilds with EAPIs >>> that are not supported by the currently installed package manager. >>> >>> In this case, when resolving dependencies and filtering ebuilds based >>> on whether or not their EAPI is supported, spawning bash once per >>> ebuild is much more costly than the alternatives. >> >> isnt the whole point of the proposal to get eapi without sourcing ? >> >> so that we can use new bash features at local or global scope without >> risking that people with an old bash get syntax errors trying to get >> the eapi > > Right. Michael has lost sight of the goal and is moving off on a tangent. The point was to be able to get the EAPI without crashing if the ebuild uses newer features. If you can get the EAPI without sourcing, that obviously accomplishes the goal. But there are other goals, too, like not limiting the syntax of the EAPI assignment. I was just trying to think up something that addresses them all. In any case, yeah, it would crash and burn if someone synced his tree with an ancient version of portage. But so would the comment solution. If you want to fix that, we either have to rename everything (and hope we get it right this time) or reconsider GLEP 55.
Re: [gentoo-dev] RFD: EAPI specification in ebuilds
On 03/09/2012 08:33 AM, Eray Aslan wrote: > On Fri, Mar 09, 2012 at 08:15:11AM -0800, Zac Medico wrote: >> They may or may not have issues. Our goal is to minimize our >> vulnerability to these kinds of issues as much as possible. Being able >> to obtain the ebuild EAPI without the expense of sourcing it is one >> small step toward this goal. > > EAPI is metadata and is best treated as such. In other words, history > aside, it does not belong inside an ebuild. Making EAPI info part of > the filename does look like a reasonable solution - similar to > seen/replied flags in the filenames in maildir directories. Heck, even > version numbers in an ebuild filename is similar. > > I don't understand why there is a strong objection to it. I have a mild preference for the "parse EAPI assignment" approach, simply because it's the least invasive. That said, ultimately it doesn't make much difference to me whether we parse it from inside the ebuild or from its file name. From my perspective, arguing between these approaches boils down to hair-splitting [1]. [1] http://en.wikipedia.org/wiki/Trivial_objections -- Thanks, Zac
Re: [gentoo-dev] RFD: EAPI specification in ebuilds
On Fri, Mar 09, 2012 at 08:15:11AM -0800, Zac Medico wrote: > They may or may not have issues. Our goal is to minimize our > vulnerability to these kinds of issues as much as possible. Being able > to obtain the ebuild EAPI without the expense of sourcing it is one > small step toward this goal. EAPI is metadata and is best treated as such. In other words, history aside, it does not belong inside an ebuild. Making EAPI info part of the filename does look like a reasonable solution - similar to seen/replied flags in the filenames in maildir directories. Heck, even version numbers in an ebuild filename is similar. I don't understand why there is a strong objection to it. But anyway, it is Friday night and I am out of here. Have fun. -- Eray Aslan pgpgziRXSe880.pgp Description: PGP signature
Re: [gentoo-dev] RFD: EAPI specification in ebuilds
On Fri, 09 Mar 2012 00:35:14 -0500 Michael Orlitzky wrote: > On 03/09/2012 12:04 AM, Michał Górny wrote: > >> > >> This is of course isomorphic to requiring a specific EAPI=4 format, > >> but does allow you to do stupid things like x=`seq 4 4`; eapi $x; > >> if you want. > > > > What advantage does it give us? We still can't change ebuild syntax > > in global scope because bash will barf. > > > > Not in EAPI=5, no, but once all PMs are using the eapi function we > could. > > The function can do any crazy thing you want. Right now, we need to > source the entire ebuild to get at its environment. Before we source > it for real, we just want to know the value of $EAPI. Since eapi() > will be the first function called, it can be our interface to this > variable. What if bash starts to parse the script completely and barfs at 'syntax error' before it starts executing stuff? -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] RFD: EAPI specification in ebuilds
On 03/09/2012 07:52 AM, Ian Stakenvicius wrote: > On 09/03/12 10:41 AM, Zac Medico wrote: >> On 03/09/2012 07:21 AM, Michael Orlitzky wrote: >>> The advantage that the eapi function has over a comment is that >>> it's not magic -- it's just normal bash syntax. So we've >>> addressed that issue at a small performance cost (we're really >>> only sourcing the ebuild up to 'exit'). > >> Also consider the case where a user syncs after not having updated >> for a couple of months, and the tree contains some ebuilds with >> EAPIs that are not supported by the currently installed package >> manager. > > > IIRC we get this already, when the EAPI isn't supported by the version > of portage installed -- upgrading really old systems won't allow an > emerge of python-2.7 due to a too-new EAPI, and python-2.7 is needed > to upgrade to the newer portage. You're talking about a very specific (unfortunate) upgrade path breakage. We should keep the discussion focused on more generic cases that apply to future upgrade scenarios, rather than focusing on past breakages (though it's obvious that we should also try to avoid such upgrade path breakages in the future). Assuming that there is still a viable upgrade path, the package manager needs resolve dependencies and filter ebuilds based on whether or not their EAPI is supported. There are basically two ways to do the EAPI filtering: 1) Access the EAPI from the metadata cache. This assumes that the package manager is able to validate metadata cache entries for EAPIs that it does not support, which is a somewhat fragile assumption given the complexities of cache validation, which involves verification of ebuilds and additional sources of metadata which may include eclasses and possibly other files in the future. 2) Parse the ebuild from the ebuild using a pre-defined protocol (parse EAPI assignment, parse comment, or parse file name as in GLEP 55...). > I don't see how the EAPI check itself failing and thereby excluding an > ebuild is much different than the specified EAPI excluding it..? > Either way, the end user is going to have issues if they don't keep > their portage up to date. They may or may not have issues. Our goal is to minimize our vulnerability to these kinds of issues as much as possible. Being able to obtain the ebuild EAPI without the expense of sourcing it is one small step toward this goal. -- Thanks, Zac
Re: [gentoo-dev] media-optical, net-zope, sgml, text-markup herds are empty
On Fri, Mar 9, 2012 at 16:57, Michał Górny wrote: > For net-zope, I'd prefer dropping it. We decided to get rid of Zope, > removed almost all relevant packages, so there's no point in keeping > the herd. +1. Cheers, Dirkjan
Re: [gentoo-dev] RFD: EAPI specification in ebuilds
On 03/09/2012 07:51 AM, Alexis Ballier wrote: > On Fri, 09 Mar 2012 07:41:09 -0800 > Zac Medico wrote: > >> On 03/09/2012 07:21 AM, Michael Orlitzky wrote: >>> The advantage that the eapi function has over a comment is that >>> it's not magic -- it's just normal bash syntax. So we've addressed >>> that issue at a small performance cost (we're really only sourcing >>> the ebuild up to 'exit'). >> >> Also consider the case where a user syncs after not having updated >> for a couple of months, and the tree contains some ebuilds with EAPIs >> that are not supported by the currently installed package manager. >> >> In this case, when resolving dependencies and filtering ebuilds based >> on whether or not their EAPI is supported, spawning bash once per >> ebuild is much more costly than the alternatives. > > isnt the whole point of the proposal to get eapi without sourcing ? > > so that we can use new bash features at local or global scope without > risking that people with an old bash get syntax errors trying to get > the eapi Right. Michael has lost sight of the goal and is moving off on a tangent. -- Thanks, Zac
Re: [gentoo-dev] media-optical, net-zope, sgml, text-markup herds are empty
On Fri, 09 Mar 2012 09:02:23 +0100 Pacho Ramos wrote: > El dom, 04-03-2012 a las 13:56 +0100, Pacho Ramos escribió: > > El dom, 04-03-2012 a las 13:51 +0100, Pacho Ramos escribió: > > > El dom, 04-03-2012 a las 13:47 +0100, Pacho Ramos escribió: > > > > Even if they have some people in their mail aliases, looks like > > > > herds are empty. If nobody volunteers to join to them, I think > > > > we should drop that herds and move their packages to > > > > maintainer-needed in a week or so. > > > > > > > > What do you think? > > > > > > > > > > The same applies to "sgml" now that cryos is retiring :( > > > > and text-markup, I think it's the last empty herd now > > Maybe we could do the same as did in the past for openoffice herd: > - Change metadatas and bugs to assign them to maintainer-needed (and > reflect reality) > - Keep herd in metadatas and CCed them to bug reports > > The other option would be to simply drop that herds, assign packages > to maintainer-needed and wait developers to grab whatever they want For net-zope, I'd prefer dropping it. We decided to get rid of Zope, removed almost all relevant packages, so there's no point in keeping the herd. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] RFD: EAPI specification in ebuilds
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 09/03/12 10:41 AM, Zac Medico wrote: > On 03/09/2012 07:21 AM, Michael Orlitzky wrote: >> The advantage that the eapi function has over a comment is that >> it's not magic -- it's just normal bash syntax. So we've >> addressed that issue at a small performance cost (we're really >> only sourcing the ebuild up to 'exit'). > > Also consider the case where a user syncs after not having updated > for a couple of months, and the tree contains some ebuilds with > EAPIs that are not supported by the currently installed package > manager. IIRC we get this already, when the EAPI isn't supported by the version of portage installed -- upgrading really old systems won't allow an emerge of python-2.7 due to a too-new EAPI, and python-2.7 is needed to upgrade to the newer portage. I don't see how the EAPI check itself failing and thereby excluding an ebuild is much different than the specified EAPI excluding it..? Either way, the end user is going to have issues if they don't keep their portage up to date. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) iF4EAREIAAYFAk9aJ0QACgkQAJxUfCtlWe2tTAEA7iUgDOCaGoQhz1dXukQ/a3lY rsdqewd2DYZWtsv+3XoA/iRVe+qf4HXdkWTchFRHlolaTJechz6AZCzKY/sNdu4w =1e/8 -END PGP SIGNATURE-
Re: [gentoo-dev] RFD: EAPI specification in ebuilds
On Fri, 09 Mar 2012 07:41:09 -0800 Zac Medico wrote: > On 03/09/2012 07:21 AM, Michael Orlitzky wrote: > > The advantage that the eapi function has over a comment is that > > it's not magic -- it's just normal bash syntax. So we've addressed > > that issue at a small performance cost (we're really only sourcing > > the ebuild up to 'exit'). > > Also consider the case where a user syncs after not having updated > for a couple of months, and the tree contains some ebuilds with EAPIs > that are not supported by the currently installed package manager. > > In this case, when resolving dependencies and filtering ebuilds based > on whether or not their EAPI is supported, spawning bash once per > ebuild is much more costly than the alternatives. isnt the whole point of the proposal to get eapi without sourcing ? so that we can use new bash features at local or global scope without risking that people with an old bash get syntax errors trying to get the eapi
[gentoo-dev] Lastrite: app-pda/syncevolution
# /home/ssuominen/gentoo-x86/profiles/package.mask: # Samuli Suominen (09 Mar 2012) # Fails to build with GCC-4.6 wrt #380767. A lot has changed # in new version wrt #388543. Other bugs #354323, #354863, # and #407183. # Unless fixed, removal in 30 days. app-pda/syncevolution
Re: [gentoo-dev] RFD: EAPI specification in ebuilds
On 03/09/2012 07:21 AM, Michael Orlitzky wrote: > The advantage that the eapi function has over a comment is that it's not > magic -- it's just normal bash syntax. So we've addressed that issue at > a small performance cost (we're really only sourcing the ebuild up to > 'exit'). Also consider the case where a user syncs after not having updated for a couple of months, and the tree contains some ebuilds with EAPIs that are not supported by the currently installed package manager. In this case, when resolving dependencies and filtering ebuilds based on whether or not their EAPI is supported, spawning bash once per ebuild is much more costly than the alternatives. -- Thanks, Zac
Re: [gentoo-dev] RFD: EAPI specification in ebuilds
On 03/09/12 10:05, Zac Medico wrote: >> >> Surely we can source one or two lines of the ebuild safely, like the >> example shows? > > Why would we though, when sourcing is a relatively costly operation, and > there are much more efficient ways to get the EAPI? There do not seem to be any that people agree on =) I mean, it's /easy/ to get the EAPI. There's a list of ways on the GLEP, but all of them have trade-offs. The header comment seems to be the preference in this thread. The advantage that the eapi function has over a comment is that it's not magic -- it's just normal bash syntax. So we've addressed that issue at a small performance cost (we're really only sourcing the ebuild up to 'exit'). Whether or not that trade-off is worth it, who knows. I would prefer to make it work before we make it fast; but new ideas can't hurt considering nobody has agreed on an old one. > Also, you've got a chicken and egg problem, since you're assuming that > your eapi() function is going to be available in the global environment > when the ebuild is sourced. The whole point of knowing the EAPI in > advance is so that we will be able to make changes to the global > environment, such as add, remove, or change the behavior of _any_ function. Nah, at the top of the ebuild, you would have, EAPI=5 eapi 5 until package managers catch up, just like we would have to do with the comment. Once they've caught up, we can drop the EAPI= assignment, and begin using new features after the call to 'eapi'.
Re: [gentoo-dev] RFD: EAPI specification in ebuilds
On 03/09/2012 06:42 AM, Michael Orlitzky wrote: > On 03/09/12 00:51, Zac Medico wrote: >> On 03/08/2012 09:35 PM, Michael Orlitzky wrote: >>> The function can do any crazy thing you want. >> >> We don't need a function. We need to know the EAPI before we source the >> ebuild, and a function doesn't give us that. > > Surely we can source one or two lines of the ebuild safely, like the > example shows? Why would we though, when sourcing is a relatively costly operation, and there are much more efficient ways to get the EAPI? Also, you've got a chicken and egg problem, since you're assuming that your eapi() function is going to be available in the global environment when the ebuild is sourced. The whole point of knowing the EAPI in advance is so that we will be able to make changes to the global environment, such as add, remove, or change the behavior of _any_ function. -- Thanks, Zac
Re: [gentoo-dev] RFD: EAPI specification in ebuilds
On 03/09/12 00:51, Zac Medico wrote: > On 03/08/2012 09:35 PM, Michael Orlitzky wrote: >> The function can do any crazy thing you want. > > We don't need a function. We need to know the EAPI before we source the > ebuild, and a function doesn't give us that. Surely we can source one or two lines of the ebuild safely, like the example shows?
Re: [gentoo-dev] RFD: EAPI specification in ebuilds
* Zac Medico schrieb am 08.03.12 um 17:30 Uhr: > On 03/08/2012 01:42 AM, Marc Schiffbauer wrote: > > * Ulrich Mueller schrieb am 08.03.12 um 08:27 Uhr: > >> Such constructs also cannot be used with any of the other proposed > >> solutions. And in fact, nobody is using such things in practice. > >> _All_ ebuilds in the Portage tree can be successfully parsed with the > >> regexp proposed. > > > > Ebuilds are bash scripts. I think introducing exceptions or > > constraints here is not straightforward. > > Given that ebuilds already have to conform to a vast number of > constraints that ordinary bash scripts do not. I think that it's > perfectly reasonable for ebuilds to have a constrained syntax for EAPI > assignments. There are constraints in ebuilds, right. But its an *ebuild* in the end, not an ordinary shell script. Thats true. So if EAPI is very special, and I am now convinced it is, then well, this might be the most important contraint in an ebuild at all. If that is true I would vote to keep this as simple as possible: * EAPI *must* *be* the first non-Argument / shell code in an ebuild * The value of EAPI in the assignment *MUST* *NOT* contain any other variables or other shell substitutions. Period. Done. * That would be the least invasive change. * Could easily be checked by repoman * Is easy parsable by other programs (python code) -Marc -- 8AAC 5F46 83B4 DB70 8317 3723 296C 6CCA 35A6 4134 pgpFVfsBDxzOc.pgp Description: PGP signature
Re: [gentoo-dev] media-optical, net-zope, sgml, text-markup herds are empty
El dom, 04-03-2012 a las 13:56 +0100, Pacho Ramos escribió: > El dom, 04-03-2012 a las 13:51 +0100, Pacho Ramos escribió: > > El dom, 04-03-2012 a las 13:47 +0100, Pacho Ramos escribió: > > > Even if they have some people in their mail aliases, looks like herds > > > are empty. If nobody volunteers to join to them, I think we should drop > > > that herds and move their packages to maintainer-needed in a week or so. > > > > > > What do you think? > > > > > > > The same applies to "sgml" now that cryos is retiring :( > > and text-markup, I think it's the last empty herd now Maybe we could do the same as did in the past for openoffice herd: - Change metadatas and bugs to assign them to maintainer-needed (and reflect reality) - Keep herd in metadatas and CCed them to bug reports The other option would be to simply drop that herds, assign packages to maintainer-needed and wait developers to grab whatever they want What do you prefer? signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Doubts about need for "ewarn" when strip-linguas is used
El mar, 06-03-2012 a las 11:46 +0100, Pacho Ramos escribió:
> I usually read messages in /var/log/portage/elog/summary.log to simply
> warn me about "es es_ES" LINGUAS not being supported by that package.
> That comes from eutils.eclass inside strip-linguas:
> ewarn "Sorry, but ${PN} does not support the LINGUAS:" ${nols}
>
> Is this warning really required, personally I know a lot of packages
> that don't support spanish translations and I get no warning from them
> (as they don't use strip-linguas). When I set LINGUAS variable in my
> make.conf I assume a lot of packages won't support spanish translations,
> and I see no point on being informed about that for some packages using
> strip-linguas.
>
> What do you think?
OK with dropping message completely or use "einfo" instead of "ewarn"?
signature.asc
Description: This is a digitally signed message part
