Re: [gentoo-dev] Nominations open for the Gentoo Council 2008/2009
On Thu, Jun 05, 2008 at 02:35:16AM -0700, Josh Saddler wrote: Now that nominations are officially open, I nominate the current council members (again): amne Thanks, but not this time. cheers, Wernfried -- Wernfried Haas (amne) - amne (at) gentoo.org Gentoo Forums - http://forums.gentoo.org forum-mods (at) gentoo.org #gentoo-forums (freenode) pgpO0SHx3fMvH.pgp Description: PGP signature
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in profiles: use.local.desc
Hello, Markus. В Вск, 08/06/2008 в 19:28 +, Markus Ullmann (jokey) пишет: jokey 08/06/08 19:28:19 Modified: use.local.desc Log: Rename webkitgtk to webkit-gtk Revision ChangesPath 1.3576 profiles/use.local.desc Whenever you modify anything in profiles directory, please, fill in ChangeLog. ChangeLogs became useless if only part of developers fill them. Just to remind. There are per-arch ChangeLog, base profile ChangeLog, features ChangeLog and for other stuff ChangeLog: /usr/portage/profiles/base/ChangeLog /usr/portage/profiles/arch/sh/ChangeLog [snip other archs ChangeLog] /usr/portage/profiles/default-bsd/ChangeLog /usr/portage/profiles/embedded/ChangeLog /usr/portage/profiles/default-linux/arm/ChangeLog [snip other archs ChangeLog] /usr/portage/profiles/hardened/x86/ChangeLog /usr/portage/profiles/features/ChangeLog /usr/portage/profiles/ChangeLog Thus whenever you change anything in arch profile, or in base or features subdirectory use relevant ChangeLog. For other changes like local USE flags, masking/unmasking/updating masks (not comments :)) use /usr/portage/profiles/ChangeLog. Thank you, -- Peter. -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: A few questions to our nominees
Piotr Jaroszy?ski wrote: Hello, looks like every nominee wants the council to be more technical so I have a few technical questions for you: 1. GLEP54 Doit! 2. GLEP55 Good idea. But the GLEP still contains too many may's and should's. Example: [...] but note that one should never explicitly set both EAPIs to different values. [...]. Define it clearer: It is not allowed to set both EAPIs.. And why don't we change the versioning of the EAPI to a X.Y scheme and demand that changes in the minor version must not break sourcing of the ebuild with older package managers and that major versions do. Major version numbers are written in the postfix, while minor version numbers are written in the ebuild itself as EAPI_MINOR=1. So, the current EAPI 1 would then be in fact 0.1. Cheers, Tiziano -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: A few questions to our nominees
On Mon, 09 Jun 2008 09:45:37 +0200 Tiziano Müller [EMAIL PROTECTED] wrote: And why don't we change the versioning of the EAPI to a X.Y scheme and demand that changes in the minor version must not break sourcing of the ebuild with older package managers and that major versions do. Major version numbers are written in the postfix, while minor version numbers are written in the ebuild itself as EAPI_MINOR=1. So, the current EAPI 1 would then be in fact 0.1. No point. A 0 package manager still couldn't use a 0.1 ebuild. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] A few questions to our nominees
Ciaran McCreesh wrote: Anyone thinking that has a very limited understanding of how things work. Usually in this category you put everybody that disagrees with you, no matter the topic. Let's face it, there hasn't been any correct criticism, and any complaints have been from people who don't understand what's going on anyway and who seek to blame EAPI for Portage's lack of progress, rather than blaming Portage's lack of progress for lack of new EAPIs as they should. I'm afraid you are mixing up emails from this thread. I got complaints about how wrongly the PMS is written, e.g. academic paper markup vs plain text, natural language used to specify syntax while a grammar notation like EBNF would be better suited, when I asked people why so few were contributing about this document. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] A few questions to our nominees
On Mon, 09 Jun 2008 09:58:40 +0200 Luca Barbato [EMAIL PROTECTED] wrote: Ciaran McCreesh wrote: Anyone thinking that has a very limited understanding of how things work. Usually in this category you put everybody that disagrees with you, no matter the topic. And what does that tell you about the average level of response? I'm afraid you are mixing up emails from this thread. I got complaints about how wrongly the PMS is written, e.g. academic paper markup vs plain text, natural language used to specify syntax while a grammar notation like EBNF would be better suited, when I asked people why so few were contributing about this document. Mmm, and how many people claiming that have suggested specific improvements or pointed out specific complaints? All I've received are some vague mutterings about how it should be less formal, some vague mutterings about how it should be more formal, some incoherent rants about how it's in some way unreadable and no actual specifics. All in all, something that looks suspiciously like I don't have any genuine objections but like to moan... So how, specifically, is PMS wrongly written, and why hasn't anyone who thinks so bothered to provide details? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] A few questions to our nominees
On Monday 09 June 2008 09:06:24 Ciaran McCreesh wrote: So how, specifically, is PMS wrongly written, and why hasn't anyone who thinks so bothered to provide details? Probably because you have such a long history of saying it's broken without providing any details. Even when asked you sometimes choose to ignore the question. How does it feel to be on the receiving end for a chance? Thanks Roy -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] glibc-2.8 / gcc-4.3 build failures
it seems packages are failing when built with glibc-2.8 and/or gcc-4.3. these are issues in the package, not the toolchain. previous versions were lazy and included API bleeding which packages took advantage of. with these newer versions, things bleed less means those packages break. some common examples: - code not including limits.h yet using defines from it - code using GNU-specific features but not defining _GNU_SOURCE for it - maybe some other stuff please refrain from assigning to toolchain. if you have questions, feel free to ask. -mike signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Re: Re: A few questions to our nominees
Ciaran McCreesh wrote: On Mon, 09 Jun 2008 09:45:37 +0200 Tiziano Müller [EMAIL PROTECTED] wrote: And why don't we change the versioning of the EAPI to a X.Y scheme and demand that changes in the minor version must not break sourcing of the ebuild with older package managers and that major versions do. Major version numbers are written in the postfix, while minor version numbers are written in the ebuild itself as EAPI_MINOR=1. So, the current EAPI 1 would then be in fact 0.1. No point. A 0 package manager still couldn't use a 0.1 ebuild. That's true, it has at least to be aware the there's an EAPI. But how does such a package manager handle .ebuild-0 files? Ignore them? Failing because of unknown files in a package-dir? Should we care about package managers not being aware of the existence of EAPI's? The advantage of the above would be that we could gradually implement new (not-breaking-sourcing) features incrementing the minor version. Avoiding big chunks of changes (which usually means greater risk). -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] A few questions to our nominees
On Mon, Jun 9, 2008 at 10:06 AM, Ciaran McCreesh [EMAIL PROTECTED] wrote: On Mon, 09 Jun 2008 09:58:40 +0200 Luca Barbato [EMAIL PROTECTED] wrote: Usually in this category you put everybody that disagrees with you, no matter the topic. And what does that tell you about the average level of response? And what does that tell you about how well you fit this community ? So how, specifically, is PMS wrongly written, and why hasn't anyone who thinks so bothered to provide details? See above. Denis. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] A few questions to our nominees
On Mon, 9 Jun 2008 09:26:00 +0100 Roy Marples [EMAIL PROTECTED] wrote: On Monday 09 June 2008 09:06:24 Ciaran McCreesh wrote: So how, specifically, is PMS wrongly written, and why hasn't anyone who thinks so bothered to provide details? Probably because you have such a long history of saying it's broken without providing any details. Even when asked you sometimes choose to ignore the question. How does it feel to be on the receiving end for a chance? No, Roy, no. You're confusing you not understanding the explanation of, say, exploitable security holes in openrc with you not being told about them. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] A few questions to our nominees
On Mon, 9 Jun 2008 10:28:57 +0200 Denis Dupeyron [EMAIL PROTECTED] wrote: On Mon, Jun 9, 2008 at 10:06 AM, Ciaran McCreesh [EMAIL PROTECTED] wrote: On Mon, 09 Jun 2008 09:58:40 +0200 Luca Barbato [EMAIL PROTECTED] wrote: Usually in this category you put everybody that disagrees with you, no matter the topic. And what does that tell you about the average level of response? And what does that tell you about how well you fit this community ? Are you suggesting that Gentoo *should* be a community of people who don't really know what they're doing who base their work upon things they half understand that they think they can change without having to think about the consequences? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Re: A few questions to our nominees
On Mon, 09 Jun 2008 10:27:56 +0200 Tiziano Müller [EMAIL PROTECTED] wrote: Ciaran McCreesh wrote: No point. A 0 package manager still couldn't use a 0.1 ebuild. That's true, it has at least to be aware the there's an EAPI. But how does such a package manager handle .ebuild-0 files? Ignore them? Failing because of unknown files in a package-dir? Should we care about package managers not being aware of the existence of EAPI's? Package managers can't do *anything* with ebuilds with unsupported EAPIs anyway. Encouraging package managers to handle ebuilds with unsupported EAPIs in any way just massively limits what can be done in future EAPIs. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] A few questions to our nominees
Ciaran McCreesh wrote: I'm afraid you are mixing up emails from this thread. I got complaints about how wrongly the PMS is written, e.g. academic paper markup vs plain text, natural language used to specify syntax while a grammar notation like EBNF would be better suited, when I asked people why so few were contributing about this document. Mmm, and how many people claiming that have suggested specific improvements or pointed out specific complaints? You got some right here. Feel free to address them. So how, specifically, is PMS wrongly written, and why hasn't anyone who thinks so bothered to provide details? - rewrite it as an rfc using a markup among xmlrfc, docbook, guidexml. - use EBNF when describing a syntax. - split it and version each functional part. - define EAPI as an aggregate of those versions in a separate part. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] A few questions to our nominees
On 9 Jun 2008, at 10:50, Luca Barbato wrote: Ciaran McCreesh wrote: I'm afraid you are mixing up emails from this thread. I got complaints about how wrongly the PMS is written, e.g. academic paper markup vs plain text, natural language used to specify syntax while a grammar notation like EBNF would be better suited, when I asked people why so few were contributing about this document. Mmm, and how many people claiming that have suggested specific improvements or pointed out specific complaints? You got some right here. Feel free to address them. So how, specifically, is PMS wrongly written, and why hasn't anyone who thinks so bothered to provide details? - rewrite it as an rfc using a markup among xmlrfc, docbook, guidexml. - use EBNF when describing a syntax. - split it and version each functional part. - define EAPI as an aggregate of those versions in a separate part. lu And how specifically is this going to help? You are missing the 'provide details' part. - ferdy -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] glibc-2.8 / gcc-4.3 build failures
Mike Frysinger a écrit : please refrain from assigning to toolchain. if you have questions, feel free to ask. (too lazy to look for it, as we already have our hands full with other library breakages) Is there a howto for users/developers when migrating to glibc 2.8? Something other than a ChangeLog (too much detail) or a NEWS file (usually not enough detail) ? Thanks -- Rémi Cardona LRI, INRIA [EMAIL PROTECTED] [EMAIL PROTECTED] -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in profiles: use.local.desc
Peter Volkov a écrit : Whenever you modify anything in profiles directory, please, fill in ChangeLog. ChangeLogs became useless if only part of developers fill them. For additional info, echangelog works in there too as I found out a few days ago. Cheers -- Rémi Cardona LRI, INRIA [EMAIL PROTECTED] [EMAIL PROTECTED] -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: Re: A few questions to our nominees
That's true, it has at least to be aware the there's an EAPI. But how does such a package manager handle .ebuild-0 files? Ignore them? Failing because of unknown files in a package-dir? Should we care about package managers not being aware of the existence of EAPI's? Current portage would simply ignore them, which allows to use them right away in the tree (we would only need to make sure that developers touching packages using new format have up to date tools). Future portage would handle them nicely w/o the risk of dying when trying to figure out ebuild's EAPI, which is the point here. -- Best Regards, Piotr Jaroszyński
Re: [gentoo-dev] A few questions to our nominees
On Mon, 09 Jun 2008 10:50:11 +0200 Luca Barbato [EMAIL PROTECTED] wrote: So how, specifically, is PMS wrongly written, and why hasn't anyone who thinks so bothered to provide details? - rewrite it as an rfc using a markup among xmlrfc, docbook, guidexml. What technical reason is there to use a markup that's more work for those of us doing the writing? Writing XML is a huge pain in the ass compared to latex. - use EBNF when describing a syntax. Is there any indication that this is any clearer? EBNF gets messy when it comes to describing the whitespace rules, for example. - split it and version each functional part. - define EAPI as an aggregate of those versions in a separate part. From a package manager implementer's perspective, that's a mess. It means looking all over the place to find relevant information on, say, what a package dep spec looks like. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Re: A few questions to our nominees
[..snip..] This doesn't, to me, really seem to be relevant to the original purpose of the thread. Can we either start a new thread or get this one back on topic? welp -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] A few questions to our nominees
Ciaran McCreesh wrote: On Mon, 09 Jun 2008 10:50:11 +0200 Luca Barbato [EMAIL PROTECTED] wrote: So how, specifically, is PMS wrongly written, and why hasn't anyone who thinks so bothered to provide details? - rewrite it as an rfc using a markup among xmlrfc, docbook, guidexml. What technical reason is there to use a markup that's more work for those of us doing the writing? Writing XML is a huge pain in the ass compared to latex. More people can understand those markups, they are consistent with the gentoo documentation, they look better on screen than on paper, tex is a great typesetting markup to write academic books. Right tool for the right task. It address the problem PMS is anything but accessible - use EBNF when describing a syntax. Is there any indication that this is any clearer? EBNF gets messy when it comes to describing the whitespace rules, for example. It is less ambiguous than natural language. That solves the issue The syntax is underspecified lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] A few questions to our nominees
On Mon, 09 Jun 2008 11:49:35 +0200
Luca Barbato [EMAIL PROTECTED] wrote:
Ciaran McCreesh wrote:
On Mon, 09 Jun 2008 10:50:11 +0200
Luca Barbato [EMAIL PROTECTED] wrote:
So how, specifically, is PMS wrongly written, and why hasn't
anyone who thinks so bothered to provide details?
- rewrite it as an rfc using a markup among xmlrfc, docbook,
guidexml.
What technical reason is there to use a markup that's more work for
those of us doing the writing? Writing XML is a huge pain in the ass
compared to latex.
More people can understand those markups
I've yet to see anyone have any difficulties with Tex.
they are consistent with the gentoo documentation
GuideXML can't even begin to cover our requirements. Simple example:
try to rewrite the following in GuideXML:
---START---
Global variables must only contain invariant values
(see~\ref{metadata-invariance}). If a global variable's value is
invariant, it may have the value that would be generated at any given
point in the build sequence.
This is demonstrated by code listing~\ref{lst:env-saving}.
\lstinputlisting[float,caption=Environment state between
functions,label=lst:env-saving]{env-saving.listing}
---END---
they look better on screen than on paper
That's highly questionable. And PMS is sufficiently long that printing
it out is the easiest way of reading it, no matter what format it's in.
tex is a great typesetting markup to write academic books. Right tool
for the right task. It address the problem PMS is anything but
accessible
How does making PMS twice the file size and five times as complicated to
edit make it more accessible?
- use EBNF when describing a syntax.
Is there any indication that this is any clearer? EBNF gets messy
when it comes to describing the whitespace rules, for example.
It is less ambiguous than natural language. That solves the issue
The syntax is underspecified
In what places is the syntax currently underspecified, and in said
places, why is EBNF a better solution that tightening up the existing
language? Please illustrate your answer with real examples.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
[gentoo-dev] Re: Nominations open for the Gentoo Council 2008/2009
Hi, Vlastimil Babka [EMAIL PROTECTED]: opfer (Christian Faulhammer) Thanks, but I decline. V-Li -- Christian Faulhammer, Gentoo Lisp project URL:http://www.gentoo.org/proj/en/lisp/, #gentoo-lisp on FreeNode URL:http://www.faulhammer.org/ signature.asc Description: PGP signature
Re: [gentoo-dev] glibc-2.8 / gcc-4.3 build failures
On Monday 09 June 2008, Rémi Cardona wrote: Mike Frysinger a écrit : please refrain from assigning to toolchain. if you have questions, feel free to ask. Is there a howto for users/developers when migrating to glibc 2.8? Something other than a ChangeLog (too much detail) or a NEWS file (usually not enough detail) ? not really. write your code to use the write API as documented rather than what happens to work ;). i imagine as the list of packages broken stabilizes, one could glean the common threads, but since you're asking for info that depends on the info, we're chicken pucked at this point in time. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] A few questions to our nominees
Ciaran McCreesh wrote:
On Mon, 09 Jun 2008 11:49:35 +0200
Luca Barbato [EMAIL PROTECTED] wrote:
Ciaran McCreesh wrote:
On Mon, 09 Jun 2008 10:50:11 +0200
Luca Barbato [EMAIL PROTECTED] wrote:
So how, specifically, is PMS wrongly written, and why hasn't
anyone who thinks so bothered to provide details?
- rewrite it as an rfc using a markup among xmlrfc, docbook,
guidexml.
What technical reason is there to use a markup that's more work for
those of us doing the writing? Writing XML is a huge pain in the ass
compared to latex.
More people can understand those markups
I've yet to see anyone have any difficulties with Tex.
they are consistent with the gentoo documentation
GuideXML can't even begin to cover our requirements. Simple example:
try to rewrite the following in GuideXML:
---START---
Global variables must only contain invariant values
(see~\ref{metadata-invariance}). If a global variable's value is
invariant, it may have the value that would be generated at any given
point in the build sequence.
This is demonstrated by code listing~\ref{lst:env-saving}.
\lstinputlisting[float,caption=Environment state between
functions,label=lst:env-saving]{env-saving.listing}
---END---
Let's change all that hideous, barely readable multiple brace/bracket
abuse into something more human-readable, shall we?
---
p
Global variables must only contain invariant values (see uri
link=#metadata-invariancelink/uri). If a global variable's value is
invariant, it may have the value that would be generated at any given
point in the build sequence.
/p
p
This is demonstrated by the following:
/p
pre caption=Environment state between functions id=env-saving
bunch o'neat code
/pre
---
Oh, and that id is entirely optional; GuideXML is smart enough to keep
track of successive code blocks, so you automatically have numerical
inter/intra document links, as I'll demonstrate at the end of this email.
GuideXML has moved on, while you seem to be stuck in the past. For
example, look at all the neat things we can do especially for ebuild
syntax highlighting.[1] Might want to read the rest of that document,
while you're at it.
Thanks for playing; you lose.
[1] http://www.gentoo.org/doc/en/xml-guide.xml#doc_chap2_sect7
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] A few questions to our nominees
On Monday 09 June 2008 11:28:03 Josh Saddler wrote: Let's change all that hideous, barely readable multiple brace/bracket abuse into something more human-readable, shall we? Please explain why angle brackets are readable but braces aren't. pre caption=Environment state between functions id=env-saving bunch o'neat code /pre Wow, you mean we just type in bunch o'neat code and the GuideXML processor magically figures out what we want and does it? That's amazing, you've really convinced me! I'm sure we'll have this checked into the repo in no time. Thanks for playing; you lose. LOL -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] A few questions to our nominees
Ciaran McCreesh wrote: On Mon, 09 Jun 2008 03:28:03 -0700 Josh Saddler [EMAIL PROTECTED] wrote: p Global variables must only contain invariant values (see uri link=#metadata-invariancelink/uri). If a global variable's value is invariant, it may have the value that would be generated at any given point in the build sequence. /p First, your link is incorrect. metadata-invariance is in a different file. Pointless nit. Second, the link's text should be the section name or chapter number. Rendered as (see link) is horribly ugly. your opinion, just yours. Third, you should have a non-breaking space between 'see' and the reference. Pointless nit. How does bunch o'neat code deal with our code file containing things that XML considers to be reserved characters? That code probably has ampersands and angle brackets in it. As usual for xml markups. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] A few questions to our nominees
On 09-06-2008 11:49:35 +0200, Luca Barbato wrote: Ciaran McCreesh wrote: On Mon, 09 Jun 2008 10:50:11 +0200 Luca Barbato [EMAIL PROTECTED] wrote: So how, specifically, is PMS wrongly written, and why hasn't anyone who thinks so bothered to provide details? - rewrite it as an rfc using a markup among xmlrfc, docbook, guidexml. What technical reason is there to use a markup that's more work for those of us doing the writing? Writing XML is a huge pain in the ass compared to latex. More people can understand those markups, they are consistent with the gentoo documentation, they look better on screen than on paper, tex is a great typesetting markup to write academic books. Right tool for the right task. It address the problem PMS is anything but accessible I think this is a bit of a pointless discussion. If people insist on reading the source and are scared of LaTeX, then the same can happen for any other language. PMS is available as pdf (or can easily being made by typing `make`), which is readable IMO, and one could always try how far one gets with a LaTeX-XML translator and XSLT transformations afterwards. Still, what is the point of requiring language X over Y? I for one prefer LaTeX over any of the formats you mentioned before, but that should not be of any value here. - use EBNF when describing a syntax. Is there any indication that this is any clearer? EBNF gets messy when it comes to describing the whitespace rules, for example. It is less ambiguous than natural language. That solves the issue The syntax is underspecified Perhaps some examples showing the syntax could improve the situation here? -- Fabian Groffen Gentoo on a different level -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] A few questions to our nominees
On Mon, 09 Jun 2008 12:56:33 +0200 Luca Barbato [EMAIL PROTECTED] wrote: Ciaran McCreesh wrote: On Mon, 09 Jun 2008 03:28:03 -0700 Josh Saddler [EMAIL PROTECTED] wrote: p Global variables must only contain invariant values (see uri link=#metadata-invariancelink/uri). If a global variable's value is invariant, it may have the value that would be generated at any given point in the build sequence. /p First, your link is incorrect. metadata-invariance is in a different file. Pointless nit. No, extremely important point. With PMS we can have things split over lots of files, and not have to care what file something's in when we link to it. This means we can move things around between files, not have to worry about breaking links, and be told automatically if we do screw up a link. How do we get this using GuideXML? Second, the link's text should be the section name or chapter number. Rendered as (see link) is horribly ugly. your opinion, just yours. It's really not. Please point me to professional style guides that do reference links using link as the text. Also see http://www.w3.org/QA/Tips/noClickHere . Third, you should have a non-breaking space between 'see' and the reference. Pointless nit. You're the one that wants good, readable output. How does bunch o'neat code deal with our code file containing things that XML considers to be reserved characters? That code probably has ampersands and angle brackets in it. As usual for xml markups. Which is what? You have to manually copy the source content into the XML document, fixing the code yourself? Or come up with some convoluted build scripts to do it? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] A few questions to our nominees
On Mon, 09 Jun 2008 03:28:03 -0700 Josh Saddler [EMAIL PROTECTED] wrote: p Global variables must only contain invariant values (see uri link=#metadata-invariancelink/uri). If a global variable's value is invariant, it may have the value that would be generated at any given point in the build sequence. /p First, your link is incorrect. metadata-invariance is in a different file. Second, the link's text should be the section name or chapter number. Rendered as (see link) is horribly ugly. Third, you should have a non-breaking space between 'see' and the reference. p This is demonstrated by the following: /p pre caption=Environment state between functions id=env-saving bunch o'neat code /pre How does bunch o'neat code deal with our code file containing things that XML considers to be reserved characters? That code probably has ampersands and angle brackets in it. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Re: lastrite: dev-cpp/libherdstat and app-portage/herdstat
Donnie Berkholz [EMAIL PROTECTED] writes: I usually do something like this: I used to do that too, but it's quite slower than the */*/$blah, because it has to visit all the directories on the grep. Give it a try, took me quite a while to get used to it but it works nicely. -- Diego Flameeyes Pettenò http://blog.flameeyes.eu/ pgpG5kcB0pK0f.pgp Description: PGP signature
Re: [gentoo-dev] A few questions to our nominees
On Mon, Jun 09, 2008 at 01:00:52PM +0200, Fabian Groffen wrote: On 09-06-2008 11:49:35 +0200, Luca Barbato wrote: Ciaran McCreesh wrote: On Mon, 09 Jun 2008 10:50:11 +0200 Luca Barbato [EMAIL PROTECTED] wrote: So how, specifically, is PMS wrongly written, and why hasn't anyone who thinks so bothered to provide details? - rewrite it as an rfc using a markup among xmlrfc, docbook, guidexml. What technical reason is there to use a markup that's more work for those of us doing the writing? Writing XML is a huge pain in the ass compared to latex. More people can understand those markups, they are consistent with the gentoo documentation, they look better on screen than on paper, tex is a great typesetting markup to write academic books. Right tool for the right task. It address the problem PMS is anything but accessible I think this is a bit of a pointless discussion. If people insist on reading the source and are scared of LaTeX, then the same can happen for any other language. PMS is available as pdf (or can easily being made by typing `make`), which is readable IMO, and one could always try how far one gets with a LaTeX-XML translator and XSLT transformations afterwards. Still, what is the point of requiring language X over Y? I for one prefer LaTeX over any of the formats you mentioned before, but that should not be of any value here. ++ I personally have had no problems reading and/or understanding PMS, and I've had to reference a fair bit of it. I'd like to hear exactly who has problems with what sections and how to fix that. As Fabian said it really isn't a matter of We like XML better than LaTeX! It's not those people's perogative. The people who wrote PMS should be able to make the decision for themselves(as they will be maintaining it) as to what language to use. If they use LaTeX, more power to them, it's what enables them to do their job in the easiest way. You don't *have* to read PMS in LaTeX, which by the way makes my eyes bleed somewhat, you can read it in a very well done PDF. Regards, Thomas pgphJhgm1mXuT.pgp Description: PGP signature
Re: [gentoo-dev] A few questions to our nominees
Thomas Anderson wrote: As Fabian said it really isn't a matter of We like XML better than LaTeX! It's not those people's prerogative. Problems like having homogeneous documentation aren't that small. The people who wrote PMS should be able to make the decision for themselves(as they will be maintaining it) as to what language to use. The main point being using latex prevents people from modify it. If they use LaTeX, more power to them, it's what enables them to do their job in the easiest way. Depends on what the job is. You don't *have* to read PMS in LaTeX, which by the way makes my eyes bleed somewhat, you can read it in a very well done PDF. The pdf renders poorly on xpdf due the fonts latex has, usually I'd rather have plain text anyway. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] A few questions to our nominees
On 9 Jun 2008, at 14:18, Luca Barbato wrote: The people who wrote PMS should be able to make the decision for themselves(as they will be maintaining it) as to what language to use. The main point being using latex prevents people from modify it. Your opinion. You don't *have* to read PMS in LaTeX, which by the way makes my eyes bleed somewhat, you can read it in a very well done PDF. The pdf renders poorly on xpdf due the fonts latex has, usually I'd rather have plain text anyway. Pointless nit. - ferdy -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] A few questions to our nominees
On Mon, 09 Jun 2008 14:18:01 +0200 Luca Barbato [EMAIL PROTECTED] wrote: The people who wrote PMS should be able to make the decision for themselves(as they will be maintaining it) as to what language to use. The main point being using latex prevents people from modify it. Are you seriously suggesting that hypothetical contributions we might receive from people who hypothetically might contribute if only we used XML instead of Latex outweigh all the extra work XML requires? You don't *have* to read PMS in LaTeX, which by the way makes my eyes bleed somewhat, you can read it in a very well done PDF. The pdf renders poorly on xpdf due the fonts latex has, usually I'd rather have plain text anyway. The PDF spec requires that PDF readers have certain fonts available, and those're the fonts we're using. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] A few questions to our nominees
On Mon, Jun 09, 2008 at 01:26:53PM +0100, Ciaran McCreesh wrote: On Mon, 09 Jun 2008 14:18:01 +0200 Luca Barbato [EMAIL PROTECTED] wrote: The people who wrote PMS should be able to make the decision for themselves(as they will be maintaining it) as to what language to use. The main point being using latex prevents people from modify it. Are you seriously suggesting that hypothetical contributions we might receive from people who hypothetically might contribute if only we used XML instead of Latex outweigh all the extra work XML requires? Right, and though I don't understand LaTeX all that well, it wasn't too difficult to stop me from writing the spec for one function. I personally dislike XML even more than LaTeX, but that shouldn't stop those who wrote it from using it. pgpNVKiLPgC4x.pgp Description: PGP signature
Re: [gentoo-dev] A few questions to our nominees
On Mon, 2008-06-09 at 14:18 +0200, Luca Barbato wrote: Thomas Anderson wrote: As Fabian said it really isn't a matter of We like XML better than LaTeX! It's not those people's prerogative. Problems like having homogeneous documentation aren't that small. The people who wrote PMS should be able to make the decision for themselves(as they will be maintaining it) as to what language to use. The main point being using latex prevents people from modify it. Untrue... latex is documented, and lots of people feel more comfortable with it than with XML (for example me). It's just a matter of taste and thus a decision of the people actually doing the work. If they use LaTeX, more power to them, it's what enables them to do their job in the easiest way. Depends on what the job is. You don't *have* to read PMS in LaTeX, which by the way makes my eyes bleed somewhat, you can read it in a very well done PDF. The pdf renders poorly on xpdf due the fonts latex has, usually I'd rather have plain text anyway. Install app-text/evince. It looks quite nice there. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] glibc-2.8 / gcc-4.3 build failures
On Monday 09 June 2008, Mike Frysinger wrote: it seems packages are failing when built with glibc-2.8 and/or gcc-4.3. these are issues in the package, not the toolchain. previous versions were lazy and included API bleeding which packages took advantage of. with these newer versions, things bleed less means those packages break. some common examples: - code not including limits.h yet using defines from it - code using GNU-specific features but not defining _GNU_SOURCE for it - maybe some other stuff please refrain from assigning to toolchain. if you have questions, feel free to ask. -mike Just for reference, there are the following tracker bugs for ebuilds failing with either of the two. Please mark build failures as blockers of those. # [tracker] GCC 4.3 porting https://bugs.gentoo.org/show_bug.cgi?id=198121 # [TRACKER] ebuilds failing to build against sys-libs/glibc-2.8 https://bugs.gentoo.org/show_bug.cgi?id=225459 Robert signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Re: glibc-2.8 / gcc-4.3 build failures
Robert Buchholz [EMAIL PROTECTED] writes: # [tracker] GCC 4.3 porting https://bugs.gentoo.org/show_bug.cgi?id=198121 or https://bugs.gentoo.org/show_bug.cgi?id=gcc-4.3 # [TRACKER] ebuilds failing to build against sys-libs/glibc-2.8 https://bugs.gentoo.org/show_bug.cgi?id=225459 or https://bugs.gentoo.org/show_bug.cgi?id=glibc-2.8 I love aliasing :) -- Diego Flameeyes Pettenò http://blog.flameeyes.eu/ pgprbDcyCeB7l.pgp Description: PGP signature
Re: [gentoo-dev] Re: lastrite: dev-cpp/libherdstat and app-portage/herdstat
On Sun, 8 Jun 2008 06:44:59 -0700 Chip Parker [EMAIL PROTECTED] wrote: Although it'll be a bit slower than a direct grep: for m in `find /usr/portage -name metadata.xml `; do grep -Rn foo $m;done That would be horribly slow by comparison. :) Kind regards, JeR -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] A few questions to our nominees
On Sun, 8 Jun 2008 12:27:52 +0100 Ciaran McCreesh [EMAIL PROTECTED] wrote: The current council has raised never actually deciding anything to an art form. Barking up the wrong (portage) tree again? Kindest regards, JeR -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] A few questions to our nominees
Thomas Anderson wrote: I personally have had no problems reading and/or understanding PMS, and I've had to reference a fair bit of it. I'd like to hear exactly who has problems with what sections and how to fix that. As Fabian said it really isn't a matter of We like XML better than LaTeX! It's not those people's perogative. The people who wrote PMS should be able to make the decision for themselves(as they will be maintaining it) as to what language to use. If they use LaTeX, more power to them, it's what enables them to do their job in the easiest way. You don't *have* to read PMS in LaTeX, which by the way makes my eyes bleed somewhat, you can read it in a very well done PDF. For those that don't know me, I'm a member of the Documentation Team. I also have some background with XSLT (not as huge as neysx, our leader, has, but still I'm not really a begginer in this area). That said, I completely agree with the choice of latex in this particular case. If there was a fixed request on GudeXML, this document would not have been at all written yet. Cheers, -jkt -- cd /local/pub more beer /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] A few questions to our nominees
Luca Barbato wrote: Thomas Anderson wrote: As Fabian said it really isn't a matter of We like XML better than LaTeX! It's not those people's prerogative. Problems like having homogeneous documentation aren't that small. See the devmanual. It uses completely different XML markup. It is XML, but not compatible at all with the GuideXML. Cheers, -jkt -- cd /local/pub more beer /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Nominations open for the Gentoo Council 2008/2009
Roy Bamford wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2008.06.05 01:00, ?ukasz Damentko wrote: Hi guys, Nominations for the Gentoo Council 2008/2009 are open now and will be open for the next two weeks (until 23:59 UTC, 18/06/2008). Team, I don't want to nominate anyone who hasn't been nominated already. I would like to address all the candidates who have or will accept council nominations. 1. Please tell us how/if you plan to fix GLEP 39. (You may not consider it broken) A GLEP should not be used directly to document our processes. We should rather have policy files and GLEPs should be used to make changes to those. After having written the policy file we can talk about fixing the things in there. 2. As one of the first priorities will be setting policy for pending appeals what policy do you propose ? 3. If you are not on the council already, how will you make time for the extra work? I have enough spare time for the countil. If not I'll step down as a python-team member. 4. How do you think the council and trustees can work together to make Gentoo better? Not just the code base but the cooperative environment we all work together in too. Disclosure - I have a personal interest in responses as a trustee. I think we should write a policy because I still don't understand where the trustee-domain starts and where it does intersect with the council-domain. 5. Tell us a little about yourself - the skills and experience you can bring to the council? Currently I'm studing physics at the University of Zurich, besides that I work as a CIO in a small company (~30 people). Before that I was lead of the C++ programming team in the same company for a year and I did a larger database project at the University. During my high school I was president of the students organisation for one and a half year and Co-Administrator of the IT-Team. 6. Tell us one outstanding (in your own mind) contribution you made to Gentoo in the last year. The organization of the Gentoo booths at the OpenExpo Zurich and Bern. The transition to the new slotted PostgreSQL ebuilds. Any candidate who does not have time/interest to prepare a manifesto addressing the above and anything else they want to say to the electorate will have a hard time convincing me that they have the time/ interest to undertake the duties of a council member. I look forward to seeing links to your manifestos on http://www.gentoo.org/proj/en/council/voting-logs/council-2008- nominees.xml Stay tuned :-) -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: glibc-2.8 / gcc-4.3 build failures
On 19:03 Mon 09 Jun , Diego 'Flameeyes' Pettenò wrote:
Robert Buchholz [EMAIL PROTECTED] writes:
# [tracker] GCC 4.3 porting
https://bugs.gentoo.org/show_bug.cgi?id=198121
or https://bugs.gentoo.org/show_bug.cgi?id=gcc-4.3
# [TRACKER] ebuilds failing to build against sys-libs/glibc-2.8
https://bugs.gentoo.org/show_bug.cgi?id=225459
or https://bugs.gentoo.org/show_bug.cgi?id=glibc-2.8
I love aliasing :)
Any pybugz lovers, this patch will allow use of aliases.
Thanks,
Donnie
--- bugz.py.orig2008-06-09 12:17:58.0 -0700
+++ bugz.py 2008-06-09 12:18:34.0 -0700
@@ -1301,11 +1301,6 @@
def get(self, bugid, comments = True, attachments = True):
Fetch bug details given the bug id
-try:
-int(bugid)
-except ValueError:
-raise BugzError(bugid must be a number.)
-
self.log('Getting bug %s ..' % bugid)
result = Bugz.get(self, bugid)
[gentoo-dev] Re: Re: Re: A few questions to our nominees
Peter Weller wrote: [..snip..] This doesn't, to me, really seem to be relevant to the original purpose of the thread. Can we either start a new thread or get this one back on topic? In the context of whether this GLEP is complete and should be approved it does make sense. It is important to know whether introducing such a change breaks current apps or not. peper: Can you please add this as a compatibility note to the GLEP? -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: Re: Re: A few questions to our nominees
Ciaran McCreesh wrote: On Mon, 09 Jun 2008 10:27:56 +0200 Tiziano Müller [EMAIL PROTECTED] wrote: Ciaran McCreesh wrote: No point. A 0 package manager still couldn't use a 0.1 ebuild. That's true, it has at least to be aware the there's an EAPI. But how does such a package manager handle .ebuild-0 files? Ignore them? Failing because of unknown files in a package-dir? Should we care about package managers not being aware of the existence of EAPI's? Package managers can't do *anything* with ebuilds with unsupported EAPIs anyway. Encouraging package managers to handle ebuilds with unsupported EAPIs in any way just massively limits what can be done in future EAPIs. Em, that's really not what I meant. The main problem GLEP 55 describes is that with the current system we're limited to changes which don't break sourcing the ebuild (since if it would break sourcing we couldn't even find out the ebuild's EAPI version and therefore not whether the currently used package manager can handle that ebuild). That package managers can't do anything else than masking ebuilds with unsupported EAPIs is clear. But what I wanted to say is: Having the EAPI versioned like this: X.Y where X is the postfix part of the ebuild (foo-1.0.ebuild-X) and Y the EAPI=Y in the ebuild itself we could increment Y in case the changes to the EAPI don't break sourcing (again: a package manager will have to mask those ebuilds) while changes breaking the sourcing of the ebuild need an increment of X to avoid that pm's not being able to even source such an ebuild still can mask it properly (or just ignore it). -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: glibc-2.8 / gcc-4.3 build failures
On Mon, Jun 09, 2008 at 12:19:21PM -0700, Donnie Berkholz wrote:
I love aliasing :)
Any pybugz lovers, this patch will allow use of aliases.
For anybody that wants nicer bugzilla URLS, you can use these:
http://bugs.gentoo.org/${NUMERIC}
http://bugs.gentoo.org/alias/${NUMERIC}
http://bugs.gentoo.org/alias/${ALIAS}
--
Robin Hugh Johnson
Gentoo Linux Developer Infra Guy
E-Mail : [EMAIL PROTECTED]
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
--
gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: Re: Re: A few questions to our nominees
Tiziano Müller wrote: Having the EAPI versioned like this: X.Y where X is the postfix part of the ebuild (foo-1.0.ebuild-X) and Y the EAPI=Y in the ebuild itself we could increment Y in case the changes to the EAPI don't break sourcing (again: a package manager will have to mask those ebuilds) while changes breaking the sourcing of the ebuild need an increment of X to avoid that pm's not being able to even source such an ebuild still can mask it properly (or just ignore it). What benefits would that offer? Cheers, -jkt -- cd /local/pub more beer /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Re: Re: A few questions to our nominees
2008/6/9 Tiziano Müller [EMAIL PROTECTED]: Ciaran McCreesh wrote: On Mon, 09 Jun 2008 10:27:56 +0200 Tiziano Müller [EMAIL PROTECTED] wrote: Ciaran McCreesh wrote: No point. A 0 package manager still couldn't use a 0.1 ebuild. That's true, it has at least to be aware the there's an EAPI. But how does such a package manager handle .ebuild-0 files? Ignore them? Failing because of unknown files in a package-dir? Should we care about package managers not being aware of the existence of EAPI's? Package managers can't do *anything* with ebuilds with unsupported EAPIs anyway. Encouraging package managers to handle ebuilds with unsupported EAPIs in any way just massively limits what can be done in future EAPIs. Em, that's really not what I meant. The main problem GLEP 55 describes is that with the current system we're limited to changes which don't break sourcing the ebuild (since if it would break sourcing we couldn't even find out the ebuild's EAPI version and therefore not whether the currently used package manager can handle that ebuild). That package managers can't do anything else than masking ebuilds with unsupported EAPIs is clear. But what I wanted to say is: Having the EAPI versioned like this: X.Y where X is the postfix part of the ebuild (foo-1.0.ebuild-X) and Y the EAPI=Y in the ebuild itself we could increment Y in case the changes to the EAPI don't break sourcing (again: a package manager will have to mask those ebuilds) while changes breaking the sourcing of the ebuild need an increment of X to avoid that pm's not being able to even source such an ebuild still can mask it properly (or just ignore it). What's the point of sourcing an ebuild that cannot be used anyway? -- Best Regards, Piotr Jaroszyński
Re: [gentoo-dev] merging two packages - upgrade path?
On Montag, 9. Juni 2008, Enrico Weigelt wrote:
* Matthias Schwarzott [EMAIL PROTECTED] schrieb:
Hi,
This post is about how to create a nice upgrade path when merging two
packages.
The packages I care about are
media-plugins/vdr-streamdev-{client,server}, that we wanted to merge into
one media-plugins/vdr-streamdev package.
please, please, don't do at it all.
Server vs. clients things should really be separated, and if there's
shared code between them (eg. proto headers), it should belong to
another package. We've already got enough blowed-up, fat packages.
Same with the -client / -server useflags: they're just a work around
for certain upstream's crap design - if they really understood the
concept named client-server-model, we'd have clean lines and wouldn't
need this at all.
Actually, I didn't check whether the upstream did this mixup or just
you, so I won't accuse you for that ;P. If it's the upstream's fault,
please try to stop them.
Yes, I know Gentoo's policy is to stay as near to upstream as
possible, but there should be a limit. Upstream quality can range
widely, from excellent to crap. Please try to keep the overall
quality as high as possible and leave out the crap.
Well, upstream is just one file/package: vdr-streamdev-0.3.4.tgz
All other distros (that I know of) still have only one package for
vdr-streamdev.
Only gentoo has split this into the client and server parts.
But we want to revert this now, because splitting leads to more maintainance
effort as both ebuilds are almost the same.
Regards
Matthias
--
gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] A few questions to our nominees
On 11:12 Sun 08 Jun , Piotr Jaroszyński wrote: Hello, looks like every nominee wants the council to be more technical so I have a few technical questions for you: 1. GLEP54 2. GLEP55 I don't have any particular objections to these, besides the vague aesthetic one of having EAPI in the filename. Particularly long, weird EAPIs filled with special characters (to which some will reply So don't do that). It would be pretty cool to be able to sync a portage tree excluding ebuilds of any unsupported EAPI, though. 3. Most wanted changes in future EAPIs USE deps (in portage as of $recent, so we might be able to do this soon) Anything that's gotten to the point where people hack around it to use it in the tree is clearly something that should become part of an EAPI, a la built_with_use(). That's one kind of action that shows something is a feature we really need. Some features I'd like to see in general use that may not require new EAPIs: -New eclasses and elibs (GLEP 33) -Clean multilib support (PM treating ABI to allow multiples of the same PVR) -USE flag groups (GLEP 29) that don't suck like USE_EXPAND -Signing everything (eclasses and all) -GLEP 42 (news reporting) finally getting used Other things I'd like to see: -A hosting site for all of our patches. This would enable better collaboration with other distros and upstream. -More unit tests, building on the ones I posted to -dev recently. -A real tinderbox server doing continuous integration tests that people can check at any time and that will do the blame game and email people who broke something. -Someone to finish creandus (pioto's user creation thingy) Thanks, Donnie -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Remember, please don't use upstream-provided bootstrap unless necessary
* Diego 'Flameeyes' Pettenò [EMAIL PROTECTED] schrieb: Hi, Upstream doesn't always know better for our setup (it may try to second there are also a lot of other things, upstream tends not to know ;-P guess our settings by looking for particular automake/autoconf versions), it will show to the user information we don't care about, ah, don't forget those upstreams (eg. mozilla) who are too lazy for fixing their stoneage'd configure.in's for a more recent autoconf version, instead invest enormous amounts of time in writing whole books about why they're unwilling to have a look at ready-to-run and well tested patches. almost all the bootstrap scripts I've seen don't even try to catch when a step in the rebuild fails, they mask the need for autotools, and as you don't inherit autotools eclass for running them, you usually forget to add the autoconf/automake dependencies. And it makes very difficult to track down which ebuilds do actually use autotools to track down if there are changes to do. hmm, isn't it obvious that these scripts are just for the (upstream) devs themselves ? they belong into my (manual ;-)) veryclean stage when starting to work on some package, same as ./configure, aclocal.m4, etc, etc ;-P (for a clean start, I normally wipe out *everything* that's autogenerated) Let's not even start to talk about bootstrap scritps that run ./configure by themselves, those are just plainly evil. ACK. We should instead ask the upstream for cleaned-up releases ;-) Actually, I wouldn't even take the shipped ./configure scripts - I *always* run the whole autoreconf chain on a fresh tree. Please note that sometimes the bootstrap script is used to add extra m4 search directories and options like --foreign to automake. Well, here's the deal: - AT_M4DIR is the variable to use to pass extra m4 search directory to aclocal, no need for the bootstrap script; - eautomake takes care by itself to identify the cases where --foreign is needed (this usually means when some of the standard documentation files are missign); I prefer to fix these broken configure.in's ;-P Also make sure that autotools gets not rebuilt through maintainer mode, that will make the configure run twice, wasting users' time, and is usually evil if you are using unpack to check for the generated configure (yes it happened to me a couple of time). That strange maintainer mode is one of the things on my to-rip-off list, along with the rules for regenerating the configure script. (which sometimes tends to loop forever) ;-o cu -- - Enrico Weigelt== metux IT service - http://www.metux.de/ - Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ - -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] merging two packages - upgrade path?
* Matthias Schwarzott [EMAIL PROTECTED] schrieb: Well, upstream is just one file/package: vdr-streamdev-0.3.4.tgz What I suspected. Actually, I'm not interested in that package. Otherwise there already would be a fork which keeps that separation. But we want to revert this now, because splitting leads to more maintainance effort as both ebuilds are almost the same. If upstream would do it's homework, there would be almost no ebuild maintenance work at all ;-P cu -- - Enrico Weigelt== metux IT service - http://www.metux.de/ - Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ - -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] A few questions to our nominees
Donnie Berkholz wrote: On 11:12 Sun 08 Jun , Piotr Jaroszyński wrote: looks like every nominee wants the council to be more technical so I have a few technical questions for you: 1. GLEP54 2. GLEP55 I don't have any particular objections to these, besides the vague aesthetic one of having EAPI in the filename. Particularly long, weird EAPIs filled with special characters (to which some will reply So don't do that). Donnie, I agree, and I think it would be a mistake to use the filename extension for the EAPI number, even for simple non-long-or-funky EAPIs. I know that my reasons will be considered, by some, to be irrelevant (especially since aesthetics and/or style/elegance are of less importance to some), but I really think this should be carefully considered; a mistake here would be quite a shame. I'll state again (slightly modified) what I wrote a while back on this issue. Technical reasons to avoid the filename: 1) Increase of [needless] complexity in filenames/extensions (and only one example of the impact is that searching for ebuild files becomes less straightforward), when things like SLOT, EAPI, etc., etc., seem to naturally belong as part of the script contents/syntax. 2) Having the same info in more than one place is generally a bad idea in any design - this is true in any discipline. I don't care how many people say a) that this is not an issue or b) that it's not a duplication, in every data system I've worked on, it has been a very bad idea to have more than one version of the same info that can get out of sync with each other. Even if you take great care, I'd still always want to check both and not trust either version of the info blindly. Caching or hashing is different (i.e. where the caching mechanism is robust), since the system itself keeps the cache up to date, and one version of the info is strictly derived from the other rather than both being the source. 3) It uses the extension in a way that goes against common use in computers, especially *nix. No longer could we then say that a file of type Gentoo ebuild has the extension ebuild (simple/straightforward/standard). 4) It seems that the motivation for this GLEP is so that the tools can determine the EAPI without reading/sourcing the script. In order to get around this, the GLEP suggests exposing this technical information in the filename. This is the wrong place to expose it, and the reasons given are not that this detail should be exposed there but rather because it is inefficient to source the file to get the info. So this is a case of trying to solve a technical issue by changing the interface. I believe it would be more correct to attack the technical problem in a way that does not do this, and I am sure this can be solved. Other reasons: 1) Littering the filename with this kind of stuff is potentially confusing to both devs and users - I know it's been stated that users shouldn't care, but I don't think that's a good reason/assumption. 2) It is not an elegant filename policy. Many systems have elegance as a design goal. 3) Assuming going this route is a mistake, it could be hard to reverse. Currently, I consider Gentoo's ebuild filename conventions simple and elegant. In fact, it is beautifully done. I'd hate to see this go down the wrong path now. -Joe -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] A few questions to our nominees
On Mon, 9 Jun 2008, Joe Peterson wrote: Technical reasons to avoid the filename: 1) Increase of [needless] complexity in filenames/extensions (and only one example of the impact is that searching for ebuild files becomes less straightforward), when things like SLOT, EAPI, etc., etc., seem to naturally belong as part of the script contents/syntax. Okay... so: find /usr/portage -name *ebuild becomes: find /usr/portage -name *ebuild* That doesn't seem that much harder to me... Same for the file detection for editors. 2) Having the same info in more than one place is generally a bad idea in any design - this is true in any discipline. [...] If you read the proposal more closely, you would notice that it specifically says to *not* specify EAPI in more than one place. It belongs solely in the filename suffix. The only reason the EAPI variable would be recognized inside the file itself is to allow for backwards compatibility with the current way EAPI=1 is done -- this behavior would be discouraged in all future ebuilds. 3) It uses the extension in a way that goes against common use in computers, especially *nix. No longer could we then say that a file of type Gentoo ebuild has the extension ebuild (simple/straightforward/standard). In most unixes, the file extension is completely meaningless. What matters is the contents of the file. Nautilus, etc, mostly use detection based upon the files contents to identify file types (at least for local files), not file extensoins. 4) It seems that the motivation for this GLEP is so that the tools can determine the EAPI without reading/sourcing the script. In order to get around this, the GLEP suggests exposing this technical information in the filename. This is the wrong place to expose it, and the reasons given are not that this detail should be exposed there but rather because it is inefficient to source the file to get the info. So this is a case of trying to solve a technical issue by changing the interface. I believe it would be more correct to attack the technical problem in a way that does not do this, and I am sure this can be solved. The reason for this is that, while the current two EAPIs don't cause trouble if you try to source them when you don't support them, that doesn't mean future ones won't. I'm not talking about anything silly like rewriting ebuilds in python, but things like changing syntax for DEPEND could potentially confuse older package managers. By adding the EAPI specification to the filename instead, old package managers just plain won't see packages they don't understand, so there's no need to worry about this. Also, sourcing a package to extract one metadata key takes much more time than just not loading it in the first place. Other reasons: 1) Littering the filename with this kind of stuff is potentially confusing to both devs and users - I know it's been stated that users shouldn't care, but I don't think that's a good reason/assumption. New eapis aren't necessarily of any immediate use to people. Those who don't see the need for them can continue to just use EAPI=0, plain old .ebuild files of the sort that've been around for years, and for many packages this is totally appropriate. The only devs who should care are the ones who have a need for the new features. Users shouldn't ever have to read the ebuild files themselves. The package manager should tell them everything they need to know. 2) It is not an elegant filename policy. Many systems have elegance as a design goal. That's a matter of opinion. It seems perfectly elegant to me -- not to mention the various, rather clear technical benefits of it. 3) Assuming going this route is a mistake, it could be hard to reverse. Not really. The entire point of this scheme is that we can change at any time w/o breaking stuff. If we decide to go with .pbuild files for the future, we can just do that. Old package managers still won't care. -- Mike Kelly -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] GLEP 55 (was: A few questions to our nominees)
[EMAIL PROTECTED] wrote: 1) Increase of [needless] complexity in filenames/extensions (and only one example of the impact is that searching for ebuild files becomes less straightforward), when things like SLOT, EAPI, etc., etc., seem to naturally belong as part of the script contents/syntax. Okay... so: find /usr/portage -name *ebuild becomes: find /usr/portage -name *ebuild* That doesn't seem that much harder to me... Same for the file detection for editors. I'm not saying it's a lot harder. But it is more complex and less elegant. Also, it is error-prone. If someone, by habit, looks for all *.ebuild, he will miss a portion of the ebuilds and not even realize it at first (or ever). 2) Having the same info in more than one place is generally a bad idea in any design - this is true in any discipline. [...] If you read the proposal more closely, you would notice that it specifically says to *not* specify EAPI in more than one place. It belongs solely in the filename suffix. The only reason the EAPI variable would be recognized inside the file itself is to allow for backwards compatibility with the current way EAPI=1 is done -- this behavior would be discouraged in all future ebuilds. Still, the GLEP addresses the very point of what logic has to be followed if the EAPI exists in the filename, in the file, or both. It talks of pre-source EAPIs and post-source EAPIs. Complicated. 3) It uses the extension in a way that goes against common use in computers, especially *nix. No longer could we then say that a file of type Gentoo ebuild has the extension ebuild (simple/straightforward/standard). In most unixes, the file extension is completely meaningless. What matters is the contents of the file. Nautilus, etc, mostly use detection based upon the files contents to identify file types (at least for local files), not file extensoins. That wasn't the point I was trying to make. I am not saying that the extension has special meaning (even the . has no meaning, really, in unix) to software. I mean that people associate certain types of files with certain extensions. I'm speaking more of the human interface here. 4) It seems that the motivation for this GLEP is so that the tools can determine the EAPI without reading/sourcing the script. In order to get around this, the GLEP suggests exposing this technical information in the filename. This is the wrong place to expose it, and the reasons given are not that this detail should be exposed there but rather because it is inefficient to source the file to get the info. So this is a case of trying to solve a technical issue by changing the interface. I believe it would be more correct to attack the technical problem in a way that does not do this, and I am sure this can be solved. The reason for this is that, while the current two EAPIs don't cause trouble if you try to source them when you don't support them, that doesn't mean future ones won't. I'm not talking about anything silly like rewriting ebuilds in python, but things like changing syntax for DEPEND could potentially confuse older package managers. By adding the EAPI specification to the filename instead, old package managers just plain won't see packages they don't understand, so there's no need to worry about this. Well, in general, if you rely on extensions changing every time a program cannot deal with a new feature of a file format, it would be quite crazy. For example, if C programs had to start using .c-2, .c-3, etc., it would get ugly fast. Also, it is easy to build EAPI checking into portage now, and when the requisite time passes, you only need to deal with situations where *very* old portage versions are still in use. Since portage is typically the first thing the system upgrades after a sync, I don't see a big issue. Or, if that is not acceptable, see my comment at the end about a one-time change to a new extension like .eb. Also, sourcing a package to extract one metadata key takes much more time than just not loading it in the first place. I understand there are technical/performance issues to solve, but this does not, IMHO, justify moving this info into a filename/extension. 1) Littering the filename with this kind of stuff is potentially confusing to both devs and users - I know it's been stated that users shouldn't care, but I don't think that's a good reason/assumption. New eapis aren't necessarily of any immediate use to people. Those who don't see the need for them can continue to just use EAPI=0, plain old .ebuild files of the sort that've been around for years, and for many packages this is totally appropriate. The only devs who should care are the ones who have a need for the new features. But when they do need the new features, they need to use the new EAPIs. This is not a matter of degree - it is a matter of defining the filename format.
Re: [gentoo-dev] GLEP 55 (was: A few questions to our nominees)
On Mon, 09 Jun 2008 19:49:08 -0600 Joe Peterson [EMAIL PROTECTED] wrote: I'm not saying it's a lot harder. But it is more complex and less elegant. Also, it is error-prone. If someone, by habit, looks for all *.ebuild, he will miss a portion of the ebuilds and not even realize it at first (or ever). Yes, if something changes, and people carry on doing the old thing by habit, then things go wrong. Still, the GLEP addresses the very point of what logic has to be followed if the EAPI exists in the filename, in the file, or both. It talks of pre-source EAPIs and post-source EAPIs. Complicated. And if the GLEP didn't address it people would complain that it allowed undefined behaviour. Well, in general, if you rely on extensions changing every time a program cannot deal with a new feature of a file format, it would be quite crazy. For example, if C programs had to start using .c-2, .c-3, etc., it would get ugly fast. Which is why programs that use any major C feature introduced since 1980 use the extension '.cc' or '.cpp'. Also, it is easy to build EAPI checking into portage now, and when the requisite time passes, you only need to deal with situations where *very* old portage versions are still in use. Since portage is typically the first thing the system upgrades after a sync, I don't see a big issue. Or, if that is not acceptable, see my comment at the end about a one-time change to a new extension like .eb. You completely miss the point of the GLEP. We need new extensions precisely because current package managers can't handle future EAPIs cleanly, and we need to carry on using new extensions because otherwise we restrict what future EAPIs can do. But what users *really* don't care about is EAPIs, and this GLEP would expose that technical detail to them in a very blatent way. Anyone who cares about ebuilds at a file level has to care about EAPIs. Along those lines, as I've said before, migrating to a new extension, *one-time*, as a solution to this, although not optimal, would be far more satisfactory than introducing a series of ever-changing extensions. No it won't. It means future EAPIs will be restricted to some particular source format. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] GLEP 55
Ciaran McCreesh wrote: On Mon, 09 Jun 2008 19:49:08 -0600 Joe Peterson [EMAIL PROTECTED] wrote: I'm not saying it's a lot harder. But it is more complex and less elegant. Also, it is error-prone. If someone, by habit, looks for all *.ebuild, he will miss a portion of the ebuilds and not even realize it at first (or ever). Yes, if something changes, and people carry on doing the old thing by habit, then things go wrong. Yes, if everyone is perfect and remembers to do things perfectly right, there would never be issues in many things, but when you make something more complicated, there will be more errors. Well, in general, if you rely on extensions changing every time a program cannot deal with a new feature of a file format, it would be quite crazy. For example, if C programs had to start using .c-2, .c-3, etc., it would get ugly fast. Which is why programs that use any major C feature introduced since 1980 use the extension '.cc' or '.cpp'. So why would not a one-time new extension (e.g. .eb) do the trick, just like .cc works for C programs? Unless you are talking about needing to specify the EAPI in the file if the more advanced features are to be used, but I see nothing wrong with that requirement - it's not much different than specifying a slot, keywords, whatever. Also, it is easy to build EAPI checking into portage now, and when the requisite time passes, you only need to deal with situations where *very* old portage versions are still in use. Since portage is typically the first thing the system upgrades after a sync, I don't see a big issue. Or, if that is not acceptable, see my comment at the end about a one-time change to a new extension like .eb. You completely miss the point of the GLEP. We need new extensions precisely because current package managers can't handle future EAPIs cleanly, and we need to carry on using new extensions because otherwise we restrict what future EAPIs can do. No, I get that. But once you develop the concept of an EAPI, the very next package manager version can be aware of it and check the EAPI of an ebuild. If the ebuild specifies none, then it is old-style. If it specifies one that is unknown or newer than what that package manager version knows it can handle, it can handle that case (ignore it or whatever). I don't see why you need to keep bumping the filename/extension every time it changes from that point forward. But what users *really* don't care about is EAPIs, and this GLEP would expose that technical detail to them in a very blatent way. Anyone who cares about ebuilds at a file level has to care about EAPIs. Not really. A typical user does not need to know about EAPIs at all, but he might want to peruse the portage tree to look for ebuilds. He might also want to grep for KEYWORDS or whatever. The user can delve into it as much as needed or desired, but if there are these mysterious EAPI numbers tacked onto the extensions, then it's an added complication that is not important to all users. Along those lines, as I've said before, migrating to a new extension, *one-time*, as a solution to this, although not optimal, would be far more satisfactory than introducing a series of ever-changing extensions. No it won't. It means future EAPIs will be restricted to some particular source format. I assume you mean that EAPI needs to be in the file - again, is this bad? Many file formats specify a file format version as part of the file. -Joe -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] GLEP 55
On Mon, 09 Jun 2008 20:15:56 -0600
Joe Peterson [EMAIL PROTECTED] wrote:
Yes, if everyone is perfect and remembers to do things perfectly
right, there would never be issues in many things, but when you make
something more complicated, there will be more errors.
So we shouldn't ever change anything?
Which is why programs that use any major C feature introduced since
1980 use the extension '.cc' or '.cpp'.
So why would not a one-time new extension (e.g. .eb) do the trick,
just like .cc works for C programs? Unless you are talking about
needing to specify the EAPI in the file if the more advanced features
are to be used, but I see nothing wrong with that requirement - it's
not much different than specifying a slot, keywords, whatever.
Because then we won't be able to change source compatibility again in
the future without introducing yet another new extension.
You completely miss the point of the GLEP. We need new extensions
precisely because current package managers can't handle future EAPIs
cleanly, and we need to carry on using new extensions because
otherwise we restrict what future EAPIs can do.
No, I get that. But once you develop the concept of an EAPI, the very
next package manager version can be aware of it and check the EAPI of
an ebuild. If the ebuild specifies none, then it is old-style. If it
specifies one that is unknown or newer than what that package manager
version knows it can handle, it can handle that case (ignore it or
whatever). I don't see why you need to keep bumping the
filename/extension every time it changes from that point forward.
Because the package manager doesn't know how to extract the EAPI from
ebuilds whose EAPI it doesn't support. For example, an EAPI 2 ebuild
might look like this:
require mypackage using ANIMAL=monkey
How do current package managers understand that the EAPI there is 2?
But what users *really* don't care about is EAPIs, and this GLEP
would expose that technical detail to them in a very blatent way.
Anyone who cares about ebuilds at a file level has to care about
EAPIs.
Not really. A typical user does not need to know about EAPIs at all,
but he might want to peruse the portage tree to look for ebuilds. He
might also want to grep for KEYWORDS or whatever. The user can delve
into it as much as needed or desired, but if there are these
mysterious EAPI numbers tacked onto the extensions, then it's an
added complication that is not important to all users.
The typical user should be using a tool to query that sort of thing.
Along those lines, as I've said before, migrating to a new
extension, *one-time*, as a solution to this, although not
optimal, would be far more satisfactory than introducing a series
of ever-changing extensions.
No it won't. It means future EAPIs will be restricted to some
particular source format.
I assume you mean that EAPI needs to be in the file - again, is this
bad? Many file formats specify a file format version as part of the
file.
It's a pain in the ass, because it means no introducing new global
scope functions and no changing behaviour of existing global scope
functions.
Most file formats don't have to deal with the compatibility issues that
we do. For example, try feeding this C++ program to a C++0x compiler:
void foo(int x)
{
auto bool requires(x == 1);
}
Or this C++0x program to a C++ compiler:
template std::Regular T_
T__ foo(T_ x)
{
std::liststd::listT_ l;
return x;
}
In both cases, you get user visible messy errors. That's not something
we have the luxury of being able to do.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
Re: [gentoo-dev] GLEP 55
Ciaran McCreesh wrote: On Mon, 09 Jun 2008 20:15:56 -0600 Joe Peterson [EMAIL PROTECTED] wrote: Yes, if everyone is perfect and remembers to do things perfectly right, there would never be issues in many things, but when you make something more complicated, there will be more errors. So we shouldn't ever change anything? Of course I don't mean that. But humans and computers are each good at a complementary set of things. Computers handle obscure complexity easily; humans do not, so it's better to let computers make our lives easier rather than the reverse when designing systems. So why would not a one-time new extension (e.g. .eb) do the trick, just like .cc works for C programs? Unless you are talking about needing to specify the EAPI in the file if the more advanced features are to be used, but I see nothing wrong with that requirement - it's not much different than specifying a slot, keywords, whatever. Because then we won't be able to change source compatibility again in the future without introducing yet another new extension. But GLEP 55 is suggesting exactly that: yet another extension for each new EAPI (I know it is defines this as .ebuild-EAPI, but that is just semantics). Source compatibility is not an issue once the EAPI syntax in the file is defined and the package manager starts to recognize it. At that point it can handle the ebuild at whatever EAPI the ebuild declares. It is only the older unaware version of the package manager that would get confused, but that would be solved by a one-time extension change: the old one would not even look for the new (e.g.) .eb extension (only the old .ebuild one), which is exactly what GLEP 55 tries to address. But the extension change is only needed once. Once the EAPI syntax is introduced and the package manager has code to read it, the package manager is able to determine the EAPI for all future EAPIs. If some new syntax in an as-yet unsupported EAPI exists, the EAPI-version-aware package manager will not trip on it, since it can just not bother to deal with future EAPI ebuilds. Now, even if there is no extension change, if we wait long enough, the chances of an old machine stubbornly staying at an old (pre-EAPI-aware) portage version gets slimmer and slimmer. So I'm not even sure this one-time extension change is really mandatory. But if it is determined to be so, I still don't see why we need endless extension changes as suggested in GLEP 55. Because the package manager doesn't know how to extract the EAPI from ebuilds whose EAPI it doesn't support. For example, an EAPI 2 ebuild might look like this: require mypackage using ANIMAL=monkey How do current package managers understand that the EAPI there is 2? The old (non-aware) package manager version would not, and yes, it would fail. So there are two alternatives: wait long enough or do a one-time extension change. In the latter case, the package manager would not even see the new files. But the new package manager versions would determine the EAPI from a defined syntax and ignore ebuilds with future EAPIs. And I do understand the issue of sourcing, since ebuilds are bash. If sourcing is an issue (and I'm not sure it is an overriding one - that's a good discussion), I would suggest an out-of-band EAPI specifier, but not in the filename. Put it in a comment line in the header, like: # Copyright 1999-2008 Gentoo Foundation # Distributed under the terms of the GNU General Public License v2 # $Header: /var/cvsroot/gentoo-x86/sys-fs/btrfs-...$ # EAPI=2 inherit eutils ... So, the first non-blank and non-'#' line (in this case, inherit ...) would signify the end of the search for the EAPI= string, making parsing trivial. Therefore, the only rule would have to be that EAPI= needs to be in a header comment. Other rules could be that it needs to be the only thing on such a header line - whatever. Again, these are technical details, and I think we can all put our heads together to come up with the best way to do it. If sourcing is a better way to go (i.e. to allow EAPI= to be anywhere in the file with no comment char), caching it might be the answer. How to make this efficient would become an implementation detail. But what users *really* don't care about is EAPIs, and this GLEP would expose that technical detail to them in a very blatent way. Anyone who cares about ebuilds at a file level has to care about EAPIs. Not really. A typical user does not need to know about EAPIs at all, but he might want to peruse the portage tree to look for ebuilds. He might also want to grep for KEYWORDS or whatever. The user can delve into it as much as needed or desired, but if there are these mysterious EAPI numbers tacked onto the extensions, then it's an added complication that is not important to all users. The typical user should be using a tool to query that sort of thing. Sure, but my point is: some users *will* want to explore - why not
Re: [gentoo-dev] GLEP 55
Joe Peterson schrieb: Ciaran McCreesh wrote: On Mon, 09 Jun 2008 19:49:08 -0600 Joe Peterson [EMAIL PROTECTED] wrote: Well, in general, if you rely on extensions changing every time a program cannot deal with a new feature of a file format, it would be quite crazy. For example, if C programs had to start using .c-2, .c-3, etc., it would get ugly fast. Which is why programs that use any major C feature introduced since 1980 use the extension '.cc' or '.cpp'. So why would not a one-time new extension (e.g. .eb) do the trick, just like .cc works for C programs? Unless you are talking about needing to specify the EAPI in the file if the more advanced features are to be used, but I see nothing wrong with that requirement - it's not much different than specifying a slot, keywords, whatever. Because that is about the same damage (file ext. changes, people might get confused etc.) with less capabilities. Also, it is easy to build EAPI checking into portage now, and when the requisite time passes, you only need to deal with situations where *very* old portage versions are still in use. Since portage is typically the first thing the system upgrades after a sync, I don't see a big issue. Or, if that is not acceptable, see my comment at the end about a one-time change to a new extension like .eb. You completely miss the point of the GLEP. We need new extensions precisely because current package managers can't handle future EAPIs cleanly, and we need to carry on using new extensions because otherwise we restrict what future EAPIs can do. No, I get that. But once you develop the concept of an EAPI, the very next package manager version can be aware of it and check the EAPI of an ebuild. If the ebuild specifies none, then it is old-style. If it specifies one that is unknown or newer than what that package manager version knows it can handle, it can handle that case (ignore it or whatever). I don't see why you need to keep bumping the filename/extension every time it changes from that point forward. Because you can change the EAPI in a way that that may not work anymore. Specifying the EAPI outside the actual ebuild is more flexible. It doesn't have to be the file extension, but that is the obvious solution. But what users *really* don't care about is EAPIs, and this GLEP would expose that technical detail to them in a very blatent way. Anyone who cares about ebuilds at a file level has to care about EAPIs. Not really. A typical user does not need to know about EAPIs at all, but he might want to peruse the portage tree to look for ebuilds. He might also want to grep for KEYWORDS or whatever. The user can delve into it as much as needed or desired, but if there are these mysterious EAPI numbers tacked onto the extensions, then it's an added complication that is not important to all users. No, not really. If you have .txt, .txt-2, .text or .footext in a dir, you would still realize, that those should be text files. Of course, a future EAPI could be named .whatevercomestoyourmind, but first, you can expect people to be smart enough to not do that and second, you can still identify the packages, because they are still named foo-version.whatevercomestoyourmind. Bernd -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] GLEP 55
On Mon, 09 Jun 2008 21:36:24 -0600 Joe Peterson [EMAIL PROTECTED] wrote: Of course I don't mean that. But humans and computers are each good at a complementary set of things. Computers handle obscure complexity easily; humans do not, so it's better to let computers make our lives easier rather than the reverse when designing systems. And a file extension is far less obscurely complex than enforcing arbitrary syntax restrictions upon ebuilds. So why would not a one-time new extension (e.g. .eb) do the trick, just like .cc works for C programs? Unless you are talking about needing to specify the EAPI in the file if the more advanced features are to be used, but I see nothing wrong with that requirement - it's not much different than specifying a slot, keywords, whatever. Because then we won't be able to change source compatibility again in the future without introducing yet another new extension. But GLEP 55 is suggesting exactly that: yet another extension for each new EAPI (I know it is defines this as .ebuild-EAPI, but that is just semantics). GLEP 55 suggests a backwards compatible, forwards compatible way of dealing with the problem that doesn't involve adding new sets of rules every few EAPIs. Source compatibility is not an issue once the EAPI syntax in the file is defined and the package manager starts to recognize it. At that point it can handle the ebuild at whatever EAPI the ebuild declares. No it can't. EAPI has to be known before the source can start. Bash doesn't provide traps for executing code upon changed variables. It is only the older unaware version of the package manager that would get confused, but that would be solved by a one-time extension change: the old one would not even look for the new (e.g.) .eb extension (only the old .ebuild one), which is exactly what GLEP 55 tries to address. But the extension change is only needed once. No, it's only needed once per non-trivial change. So we might as well just change it for every EAPI. Once the EAPI syntax is introduced and the package manager has code to read it, the package manager is able to determine the EAPI for all future EAPIs. Which means we can't change anything useful in future EAPIs. Which, funnily enough, is what the GLEP is designed to solve. Now, even if there is no extension change, if we wait long enough, the chances of an old machine stubbornly staying at an old (pre-EAPI-aware) portage version gets slimmer and slimmer. So I'm not even sure this one-time extension change is really mandatory. Except it is, because current EAPI aware package managers still can't deal with global scope changes. Because the package manager doesn't know how to extract the EAPI from ebuilds whose EAPI it doesn't support. For example, an EAPI 2 ebuild might look like this: require mypackage using ANIMAL=monkey How do current package managers understand that the EAPI there is 2? The old (non-aware) package manager version would not, and yes, it would fail. So there are two alternatives: wait long enough or do a one-time extension change. In the latter case, the package manager would not even see the new files. But the new package manager versions would determine the EAPI from a defined syntax and ignore ebuilds with future EAPIs. And then how do we deal with EAPI 3, where the syntax changes again? And I do understand the issue of sourcing, since ebuilds are bash. If sourcing is an issue (and I'm not sure it is an overriding one - that's a good discussion), I would suggest an out-of-band EAPI specifier, but not in the filename. Put it in a comment line in the header, like: # Copyright 1999-2008 Gentoo Foundation # Distributed under the terms of the GNU General Public License v2 # $Header: /var/cvsroot/gentoo-x86/sys-fs/btrfs-...$ # EAPI=2 Which is way more obscure, complex and arbitrary than a file extension change. And it still imposes massive restrictions upon future EAPIs. Again, these are technical details, and I think we can all put our heads together to come up with the best way to do it. Every issue you've raised so far was already discussed and debunked the first time this discussion happened. Please read the original discussions before continuing. The typical user should be using a tool to query that sort of thing. Sure, but my point is: some users *will* want to explore - why not encourage this? And if so, why not make the conventions used as clean and understandable (and elegant) as possible without added noise from details that do not belong at that (e.g. the filename) level? And when they do explore, they learn straight away what EAPI is. Gentoo is a technical distro, and we encourage users to get technical in every other way. Saying that they should remain at the portage interface level is not consistent with that philosophy. And users who get technical knowing what EAPI is is a good thing. Right: there
Re: [gentoo-dev] GLEP 55
Ciaran McCreesh wrote: And a file extension is far less obscurely complex than enforcing arbitrary syntax restrictions upon ebuilds. I disagree. One is exposed to devs only as ebuild syntax; the other is exposed in an inappropriate location to everyone looking at the portage tree. No it can't. EAPI has to be known before the source can start. Bash doesn't provide traps for executing code upon changed variables. Doing it out-of-band solve this. No, it's only needed once per non-trivial change. So we might as well just change it for every EAPI. Huh? If the new portage knows how to determine the EAPI definitively (and that would be defined), it can deal with the differences. And then how do we deal with EAPI 3, where the syntax changes again? Portage (or whatever PM) reads the EAPI, determines it is 3, and goes from there. If you change the way you declare EAPI each time, yeah, that's a problem, but I'm not sure why that would ne necessary. Which is way more obscure, complex and arbitrary than a file extension change. And it still imposes massive restrictions upon future EAPIs. Massive? Simply a one-line EAPI declaration is not massive nor complex. And is more elegant than putting it in the filename. Every issue you've raised so far was already discussed and debunked the first time this discussion happened. Please read the original discussions before continuing. Debunked according to whom? I believe that some, including you, believe you debunked them, but I do not believe there was wholesale agreement from the dev community. We had that discussion when the GLEP was first proposed. Yes, but nothing was decided, and agreement was not reached. I'd be very surprized if I were the only one here who is not entirely satisfied with GLEP 55's solution to this. -Joe -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] GLEP 55
On Mon, 09 Jun 2008 22:09:04 -0600 Joe Peterson [EMAIL PROTECTED] wrote: Ciaran McCreesh wrote: And a file extension is far less obscurely complex than enforcing arbitrary syntax restrictions upon ebuilds. I disagree. One is exposed to devs only as ebuild syntax; the other is exposed in an inappropriate location to everyone looking at the portage tree. You might as well say We should get rid of Manifest because anyone looking at the tree is exposed to security internals... No it can't. EAPI has to be known before the source can start. Bash doesn't provide traps for executing code upon changed variables. Doing it out-of-band solve this. Doing it out-of-band but in-the-file means the file format is fixed in annoying ways. No, it's only needed once per non-trivial change. So we might as well just change it for every EAPI. Huh? If the new portage knows how to determine the EAPI definitively (and that would be defined), it can deal with the differences. Sure, until there's another format change. Then we need yet another new extension. What will we use then? '.ebld'? The EAPI-in-extension format is cheap. People have been using it for character sets and languages for decades. And then how do we deal with EAPI 3, where the syntax changes again? Portage (or whatever PM) reads the EAPI, determines it is 3, and goes from there. If you change the way you declare EAPI each time, yeah, that's a problem, but I'm not sure why that would ne necessary. But you're not sure that it's not necessary, so why impose entirely pointless restrictions that everyone in the future has to stick by? Which is way more obscure, complex and arbitrary than a file extension change. And it still imposes massive restrictions upon future EAPIs. Massive? Simply a one-line EAPI declaration is not massive nor complex. And is more elegant than putting it in the filename. You're suddenly imposing restrictions upon the content of comments, and requiring a whole new parser to deal with it. The point of comments is that they're ignored. Every issue you've raised so far was already discussed and debunked the first time this discussion happened. Please read the original discussions before continuing. Debunked according to whom? I believe that some, including you, believe you debunked them, but I do not believe there was wholesale agreement from the dev community. That doesn't really matter. Most of the dev community don't care to understand the underlying issue, so all they need to do is go along with the informed decision that the Council was supposed to have made on their behalf. We had that discussion when the GLEP was first proposed. Yes, but nothing was decided, and agreement was not reached. I'd be very surprized if I were the only one here who is not entirely satisfied with GLEP 55's solution to this. Yet GLEP 55 is the only solution that's been proposed that solves the requirements. And your entire argument boils down to file extension changes don't look pretty, for some arbitrary value of pretty that also precludes index.html.en and index.html.utf-8. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] GLEP 55
On 05:20 Tue 10 Jun , Ciaran McCreesh wrote: Yet GLEP 55 is the only solution that's been proposed that solves the requirements. And your entire argument boils down to file extension changes don't look pretty, for some arbitrary value of pretty that also precludes index.html.en and index.html.utf-8. Did anyone already propose specifying this in metadata.xml? Clearly one downside is that PMs would need to be able to parse it to do anything, but that would also enable us to do a lot more with metadata.xml that we currently don't because we can't have PMs rely on it. Thanks, Donnie -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] GLEP 55
On Mon, 9 Jun 2008 22:35:25 -0700 Donnie Berkholz [EMAIL PROTECTED] wrote: Did anyone already propose specifying this in metadata.xml? Yup. That's a no-go, since metadata.xml is quite rightly treated as being not suitable for anything the package manager really needs. It also moves the EAPI definition even further away from the ebuild, which makes it even harder to work with. And, of course, it's not backwards compatible, so it'd still need a file extension change. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-portage-dev] Portage persistence structures :: information about ports tree
Hi. I'm reading portage docs and sources at /usr/lib/portage trying to understand how portage persists information on 'available ports'. So, I'm reading /usr/lib/portage/bin/emerge: --- snip --- portdb = trees[porttree].dbapi --- snip --- Where 'trees' is a parameter to 'search's object construction. But who really uses 'search class' is 'action_search' as we can see below: --- snip --- def action_search(settings, trees, myopts, myfiles, spinner): [...] searchinstance = search(settings, trees, spinner, --searchdesc in myopts, --quiet not in myopts, --usepkg in myopts, --usepkgonly in myopts) [...] --- snip --- Later in 'emerge' file we have --- snip --- action_search(settings, trees[settings[ROOT]], --- snip --- ... and so on ... I'm trying to track the calls, instantiations, etc to figure out how portage persists ports info. May someone give me some help on this ? How does portage do the searchs ? Walk into the ports tree and build some structure or store this info on some embedded database like berkeley db or sqlite ? Thanks in advance. -- João Macaíba [EMAIL PROTECTED] -- gentoo-portage-dev@lists.gentoo.org mailing list
Re: [gentoo-portage-dev] Portage persistence structures :: information about ports tree
On Tue, 2008-06-10 at 01:07 +0200, Marius Mauch wrote: On Mon, 09 Jun 2008 17:36:14 -0300 João Macaíba [EMAIL PROTECTED] wrote: May someone give me some help on this ? How does portage do the searchs ? Walk into the ports tree and build some structure or store this info on some embedded database like berkeley db or sqlite ? You're probably looking for the portdbapi class defined in pym/portage.py (or pym/portage/dbapi/porttree.py in 2.2), in particular the cp_all(), cpv_all(), cp_list() and aux_get() methods. Marius Thanks very much, Marius, for you help/time ! :) I'll take a look at them. Best regards. -- João Macaíba [EMAIL PROTECTED] -- gentoo-portage-dev@lists.gentoo.org mailing list
Re: [gentoo-portage-dev] Portage persistence structures :: information about ports tree
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 João Macaíba wrote: May someone give me some help on this ? How does portage do the searchs ? Walk into the ports tree and build some structure or store this info on some embedded database like berkeley db or sqlite ? If you want to use sqlite, you might find this useful: http://gentoo-wiki.com/TIP_speed_up_portage_with_sqlite Zac -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkhN2tgACgkQ/ejvha5XGaMxqACgqCDf40D3UHrvrTsyGACfIPJ8 HgUAoKKeHLASAaO6KrJXW8jpCg/0dWin =r1mc -END PGP SIGNATURE- -- gentoo-portage-dev@lists.gentoo.org mailing list
Re: [gentoo-portage-dev] Portage persistence structures :: information about ports tree
On Mon, 2008-06-09 at 20:51 -0300, João Macaíba wrote: On Tue, 2008-06-10 at 01:07 +0200, Marius Mauch wrote: On Mon, 09 Jun 2008 17:36:14 -0300 João Macaíba [EMAIL PROTECTED] wrote: May someone give me some help on this ? How does portage do the searchs ? Walk into the ports tree and build some structure or store this info on some embedded database like berkeley db or sqlite ? You're probably looking for the portdbapi class defined in pym/portage.py (or pym/portage/dbapi/porttree.py in 2.2), in particular the cp_all(), cpv_all(), cp_list() and aux_get() methods. Marius I think for searching you may find the xmatch function to be a very versatile and useful tool. I think it is one of the more used functions that porthole uses from portage. Thanks very much, Marius, for you help/time ! :) I'll take a look at them. Best regards. -- João Macaíba [EMAIL PROTECTED] -- Brian [EMAIL PROTECTED] -- gentoo-portage-dev@lists.gentoo.org mailing list
