[gentoo-dev] Re: [RFC] Some new global USE-flags
Markus Meier <[EMAIL PROTECTED]>: No, to the following (others already gave reasons): > server12 > custom-cflags 7 > multislot 6 > editor5 Is ambigious, too. [-] editor (games-arcade/bomns): enables building the level editor [-] editor (games-sports/xmoto): Depend on inkscape, scripts to convert svg to level (svg2lvl) > latex: Adds support for LaTeX (typesetting package) > [this one is questionable, as this flag has different meanings/effects > - but is one of the tetex-flag replacements] But ways better than the old tetex USE flag, as we split the meaning. V-Li -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://www.faulhammer.org/> signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] Some new global USE-flags
On Thu, 2007-12-20 at 19:57 +0100, Markus Meier wrote: > Potential candidates (flag-name, count): > xemacs5 This count will very likely go up in the future as we enable more support for packages similar to the level of support for emacs. +1 on making this a global USE flag. Kind regards, Hans signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Fri, 21 Dec 2007 07:24:26 +0100 Luca Barbato <[EMAIL PROTECTED]> wrote: > Since seems that enough people are against this glep and many are > undecided I started polling around for alternatives... But there has yet to be a correct technical objection, nor a correct alternative proposed, nor a demonstration of why the problems discussed in the GLEP are safely ignorable... -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Ciaran McCreesh wrote: >> Near as I can tell, it's only the Paludis folks that are interested >> in pushing this GLEP through. > > Have you tried asking the Portage developer? > yes, and I'm waiting for others' opinions too ^^; Since seems that enough people are against this glep and many are undecided I started polling around for alternatives... lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Thu, 20 Dec 2007 20:46:35 -0800 Josh Saddler <[EMAIL PROTECTED]> wrote: > Ciaran McCreesh wrote: > > On Fri, 21 Dec 2007 03:17:12 +0100 > > Luca Barbato <[EMAIL PROTECTED]> wrote: > >> Putting a tag in the file name or at the to of the file as comment > >> (maybe using a #! line) is the same ... > > > * It's a format restriction. Some formats have to start with > > something that's not #!. > > Who cares? Gentoo uses the ebuild/bash-with-shebang format. If you're > trying to shove in something outside of that, that would be a package > manager-specific format. Like XML-stuff (that can't include the > shebang or EAPI="foo" at the top) specifically for, say, Paludis. And that's the kind of thinking that landed Gentoo in the "unable to add new features" camp for several years. > If it's package manager-specific, then it doesn't belong in the main > tree, as you stated. Would that include trying to push in the proposed > suffix changes? Uh, no. It's a GLEP so that everyone can do it. > If they have uses outside of it, then consider supporting it *only > in that package manager*, rather than trying to force it on what is > largely an unreceptive Gentoo group. Paludis has it already for other trees. We're trying to get Gentoo, and all ebuild-using package managers, to start using it because it's a good solution and solves several problems that Gentoo has currently. > Near as I can tell, it's only the Paludis folks that are interested > in pushing this GLEP through. Have you tried asking the Portage developer? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Ciaran McCreesh wrote: > On Fri, 21 Dec 2007 03:17:12 +0100 > Luca Barbato <[EMAIL PROTECTED]> wrote: >> Putting a tag in the file name or at the to of the file as comment >> (maybe using a #! line) is the same ... > * It's a format restriction. Some formats have to start with something > that's not #!. Who cares? Gentoo uses the ebuild/bash-with-shebang format. If you're trying to shove in something outside of that, that would be a package manager-specific format. Like XML-stuff (that can't include the shebang or EAPI="foo" at the top) specifically for, say, Paludis. But wait, Ciaran McCreesh wrote: >> robertz wrote: >> especially PM specific EAPI. We can't have PM specific EAPI, >> otherwise we are risking forking/splitting ourself. > > Package manager EAPIs don't belong in the main tree, but they have > uses outside of it. If it's package manager-specific, then it doesn't belong in the main tree, as you stated. Would that include trying to push in the proposed suffix changes? If they have uses outside of it, then consider supporting it *only in that package manager*, rather than trying to force it on what is largely an unreceptive Gentoo group. Near as I can tell, it's only the Paludis folks that are interested in pushing this GLEP through. It doesn't seem like additional suffix flexibility is all that desirable except to the folks who represent one package manager. And, well, one PM does not make a specification. Mostly. Sorta. Occasionally. Sometimes. You'd think. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Fri, 21 Dec 2007 12:27:31 +0800 Zhang Le <[EMAIL PROTECTED]> wrote: > But I am not sick of EAPI's. You see? I am sick of so *many* EAPI's. What? All two of them that you need to know about, where the second one is the first one with three new features? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Fri, 21 Dec 2007 12:20:31 +0800 Zhang Le <[EMAIL PROTECTED]> wrote: > It is not about whether it is agreed upon currently. It is. That's the entire point of the whole discussion. > As long as there is an agreement in any given point of time, it is OK. > Such as, put your EAPI definition on the first line of your ebuild, > like EAPI="value" No good for package managers written before the agreement. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Ciaran McCreesh wrote: > On Fri, 21 Dec 2007 12:03:25 +0800 > Zhang Le <[EMAIL PROTECTED]> wrote: >> We can't take the risk of forking/splitting ourselves in exchange of >> only a little features. > > EAPI introduces no risk of that. Quite the opposite -- it reduces it by > making it less likely that people will get sick of the inability to add > new features and go and do so elsewhere instead. Yes and no. I agree with your above sentence. But I am not sick of EAPI's. You see? I am sick of so *many* EAPI's. -- Zhang Le, Robert GPG key ID: 1E4E2973 Fingerprint: 0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973 -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Ciaran McCreesh wrote: > On Fri, 21 Dec 2007 11:56:35 +0800 > Zhang Le <[EMAIL PROTECTED]> wrote: >> By "all people", I mean all those who have participated in this >> discussion. They shown their concern. >> We should listen to what they said. > > Even when what they said was nonsense No nonsense, so far, IMO. The question is really simple. Whether we should have two different place to define EAPI? Proponents are trying to prove that we should at least need it be in file name. However so far they are not successful in proving that. They just said you don't understand and you don't need to be able to influence on this decision. -- Zhang Le, Robert GPG key ID: 1E4E2973 Fingerprint: 0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973 -- [EMAIL PROTECTED] mailing list
Re: EAPI definition Was: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Fri, 21 Dec 2007 12:15:10 +0800 Zhang Le <[EMAIL PROTECTED]> wrote: > I think we should first decide on how EAPI works. That was decided a long time ago. > Just because we need a new feature, then we produce a new EAPI? > I think that is not feasible, and will confuse developers. Uh... Yes. It's entirely feasible, it's how things work and it's an entirely sensible model. The *problem* is not EAPI itself. The problem is how EAPI is currently specified by ebuilds. That's all the GLEP changes, and all it really needs to change. > >> especially PM specific EAPI. We can't have PM specific EAPI, > >> otherwise we are risking forking/splitting ourself. > > > > Package manager EAPIs don't belong in the main tree, but they have > > uses outside of it. > > Then would you please introduce how paludis-1 EAPI differs from > official EAPI's? It has a bunch of arbitrary, randomly changing features that I need when doing test cases for functionality that isn't covered by any official EAPI. For example, a long before EAPI 1 came along, Paludis had slot dep support. In order to test slot deps, we needed an EAPI that permitted them -- hence paludis-1. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Ciaran McCreesh wrote: > On Fri, 21 Dec 2007 11:51:03 +0800 > Zhang Le <[EMAIL PROTECTED]> wrote: >> That's the problem about the agreement between PM and ebuild. >> >> If this is agreed upon >>> import vim-spell using language="en" >> You should be able to get it. >> >> If not, then blame the ebuild writer. There is no problem with the >> agreement. > > Uh... It's not agreed upon currently. It is not about whether it is agreed upon currently. As long as there is an agreement in any given point of time, it is OK. Such as, put your EAPI definition on the first line of your ebuild, like EAPI="value" >>> Bear in mind that >>> package managers can only use what's been agreed upon at the time >>> they were released, not what might be agreed upon later -- and yet >>> they need to be able to extract the EAPI from anything agreed upon >>> later. >> Exactly my point. > > So we all agree that suffixes are the solution, since they solve this > problem and in-ebuild-content restrictions don't. Good. No, quite contrary. See above. -- Zhang Le, Robert GPG key ID: 1E4E2973 Fingerprint: 0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973 -- [EMAIL PROTECTED] mailing list
Re: EAPI definition Was: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Ciaran McCreesh wrote: > On Fri, 21 Dec 2007 11:23:08 +0800 > Zhang Le <[EMAIL PROTECTED]> wrote: > >> I really don't see the necessity to have so many EAPI's > > A new EAPI is needed for new features, so new EAPIs will be needed in > the future. Equally, migrating the whole tree at once to newer EAPIs is > a) a lot of unnecessary work, and b) unnecessarily irritating to people > using older package managers. I think we should first decide on how EAPI works. This is also a prerequisite for this glep to be further discussed. Just because we need a new feature, then we produce a new EAPI? I think that is not feasible, and will confuse developers. > >> especially PM specific EAPI. We can't have PM specific EAPI, >> otherwise we are risking forking/splitting ourself. > > Package manager EAPIs don't belong in the main tree, but they have uses > outside of it. Then would you please introduce how paludis-1 EAPI differs from official EAPI's? -- Zhang Le, Robert GPG key ID: 1E4E2973 Fingerprint: 0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973 -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Fri, 21 Dec 2007 12:03:25 +0800 Zhang Le <[EMAIL PROTECTED]> wrote: > We can't take the risk of forking/splitting ourselves in exchange of > only a little features. EAPI introduces no risk of that. Quite the opposite -- it reduces it by making it less likely that people will get sick of the inability to add new features and go and do so elsewhere instead. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Fri, 21 Dec 2007 11:56:35 +0800 Zhang Le <[EMAIL PROTECTED]> wrote: > By "all people", I mean all those who have participated in this > discussion. They shown their concern. > We should listen to what they said. Even when what they said was nonsense and the equivalent of running around saying that aliens are mind controlling the government and that we should make all developers wear tinfoil hats to prevent it? Because that's the level of contribution we're getting from some of the participants in this thread... -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Ciaran McCreesh wrote: > On Fri, 21 Dec 2007 11:34:07 +0800 > Zhang Le <[EMAIL PROTECTED]> wrote: >>> * We have to wait a year before we can use it. >> Why rush on this thing? >> If the EAPI's feature is not freezing, I think we should do nothing >> but wait. > > There's no reason to make Gentoo go even longer without features. We can't take the risk of forking/splitting ourselves in exchange of only a little features. We are already very cool and unique and featured. Note I am not rejecting new features. But we should know what price we will pay for the new features. -- Zhang Le, Robert GPG key ID: 1E4E2973 Fingerprint: 0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973 -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Fri, 21 Dec 2007 11:51:03 +0800 Zhang Le <[EMAIL PROTECTED]> wrote: > That's the problem about the agreement between PM and ebuild. > > If this is agreed upon > > import vim-spell using language="en" > You should be able to get it. > > If not, then blame the ebuild writer. There is no problem with the > agreement. Uh... It's not agreed upon currently. It may be agreed upon in the future, but that's no good for current package managers. Current package managers have to be able to deal with future agreements, without limiting those future agreements to not being able to make changes like the above example. > > Bear in mind that > > package managers can only use what's been agreed upon at the time > > they were released, not what might be agreed upon later -- and yet > > they need to be able to extract the EAPI from anything agreed upon > > later. > > Exactly my point. So we all agree that suffixes are the solution, since they solve this problem and in-ebuild-content restrictions don't. Good. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Ciaran McCreesh wrote: > On Fri, 21 Dec 2007 11:38:43 +0800 > Zhang Le <[EMAIL PROTECTED]> wrote: >> I am afraid if we want all people accept this GLEP wholeheartedly, >> someone ought to be stand out and take this responsibility. > > No no, we want all the people who are qualified to discuss it to accept > it, and the rest to accept that those people know what they're doing. By "all people", I mean all those who have participated in this discussion. They shown their concern. We should listen to what they said. -- Zhang Le, Robert GPG key ID: 1E4E2973 Fingerprint: 0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973 -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Ciaran McCreesh wrote: > On Fri, 21 Dec 2007 11:26:06 +0800 > Zhang Le <[EMAIL PROTECTED]> wrote: >>> And no, it's not worth writing them. If people have time to spend >>> documenting ebuildy things, there are a lot more useful places to >>> start. >> It worths. It will influence our future. > > And bringing devmanual up to date will influence it a lot more. That's a different question. Please keep on topic. For this glep to pass, we don't need devmanual to be up-to-date. -- Zhang Le, Robert GPG key ID: 1E4E2973 Fingerprint: 0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973 -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Ciaran McCreesh wrote: > On Fri, 21 Dec 2007 10:52:04 +0800 > Zhang Le <[EMAIL PROTECTED]> wrote: >> Ciaran McCreesh wrote: >>> On Fri, 21 Dec 2007 03:14:12 +0100 >>> Luca Barbato <[EMAIL PROTECTED]> wrote: Ciaran McCreesh wrote: > Ok. What's the EAPI for the following ebuild that's written in an > EAPI that hasn't been published yet? And how would I extract it? > > # Copyright blah blah > > import vim-spell using language="en" If isn't published it doesn't exist in the main tree... >>> You miss my point. If a package manager encounters the above, how >>> does it determine the EAPI? >> As long as there is an agreement between the PM and ebuild, you can >> get what you want no matter how it is defined. > > So how does one get the EAPI in the above example? That's the problem about the agreement between PM and ebuild. If this is agreed upon > import vim-spell using language="en" You should be able to get it. If not, then blame the ebuild writer. There is no problem with the agreement. > Bear in mind that > package managers can only use what's been agreed upon at the time they > were released, not what might be agreed upon later -- and yet they need > to be able to extract the EAPI from anything agreed upon later. Exactly my point. -- Zhang Le, Robert GPG key ID: 1E4E2973 Fingerprint: 0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973 -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Fri, 21 Dec 2007 11:38:43 +0800 Zhang Le <[EMAIL PROTECTED]> wrote: > I am afraid if we want all people accept this GLEP wholeheartedly, > someone ought to be stand out and take this responsibility. No no, we want all the people who are qualified to discuss it to accept it, and the rest to accept that those people know what they're doing. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Ciaran McCreesh wrote: > On Fri, 21 Dec 2007 10:49:04 +0800 > Zhang Le <[EMAIL PROTECTED]> wrote: > >> It should not appear as a black box, and effectively prevent normal >> gentoo users and developers from contributing to decisions which may >> have a great impact on their distro. > > The GLEP doesn't have a great impact. It's a purely internal matter > that shouldn't be visible to users at all and should be very easy for > developers to follow once implemented. > > Really, the idea that anyone can contribute and express a useful opinion > is all very well, but it's terribly naive. Do you expect to be asked to > give your opinion upon the proportion of zinc mixed in with the > aluminium in your car? Do you tell your doctor how much thimerosal you > want in your medicine? Those are not analogous to open source software development, IMO. People can't decide on those things. But they can and should be able to influence on decision we are making here. -- Zhang Le, Robert GPG key ID: 1E4E2973 Fingerprint: 0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973 -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Fri, 21 Dec 2007 11:34:07 +0800 Zhang Le <[EMAIL PROTECTED]> wrote: > > * We have to wait a year before we can use it. > > Why rush on this thing? > If the EAPI's feature is not freezing, I think we should do nothing > but wait. There's no reason to make Gentoo go even longer without features. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Ciaran McCreesh wrote: > On Fri, 21 Dec 2007 11:09:44 +0800 > Zhang Le <[EMAIL PROTECTED]> wrote: >> I see it differently. >> Everyone participated in this discussion has shown their concerns >> about their distro. >> If someone don't understand, we should help them to understand, not >> just exclude them from this discussion. >> They should learn, however we should at least give them directions. > > Which is all very well, but highly impractical. If someone wants to > write up a document explaining the metadata process then they're more > than welcome to -- but there are much more useful things that could be > documented if people had time... I am afraid if we want all people accept this GLEP wholeheartedly, someone ought to be stand out and take this responsibility. -- Zhang Le, Robert GPG key ID: 1E4E2973 Fingerprint: 0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973 -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Fri, 21 Dec 2007 11:26:06 +0800 Zhang Le <[EMAIL PROTECTED]> wrote: > > There are none. If anyone really wants to know, they can read the > > code for their package manager of choice (or better, all of them). > > Then I suggest stop this discussion and make a documentation first. > Seriously. The GLEP doesn't require that everyone understand it in order to progress. All it requires is that the package manager people agree that it's the best way forward and that developers can follow the rules it adds. > > And no, it's not worth writing them. If people have time to spend > > documenting ebuildy things, there are a lot more useful places to > > start. > > It worths. It will influence our future. And bringing devmanual up to date will influence it a lot more. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Ciaran McCreesh wrote: > On Fri, 21 Dec 2007 03:17:12 +0100 > Luca Barbato <[EMAIL PROTECTED]> wrote: >> Putting a tag in the file name or at the to of the file as comment >> (maybe using a #! line) is the same ... > > Three problems: > > * We have to wait a year before we can use it. Why rush on this thing? If the EAPI's feature is not freezing, I think we should do nothing but wait. -- Zhang Le, Robert GPG key ID: 1E4E2973 Fingerprint: 0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973 -- [EMAIL PROTECTED] mailing list
Re: EAPI definition Was: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Fri, 21 Dec 2007 11:23:08 +0800 Zhang Le <[EMAIL PROTECTED]> wrote: > > Quite the opposite. EAPI's are designed to live happily together in > > the same repository. A current example: most (or lots...) ebuilds in > > the tree don't need EAPI="1" and it's pointless to migrate all of > > them. We can switch EAPI on an as needed basis. > > But EAPI's can not always co-exist harmoniously. > What if a future EAPI come up with a totally new DEPENDENCY > setting[1], which is incompatible with existing ones. DEPENDENCIES can exist in the same tree as *DEPEND. They can't exist within the same ebuild, but that's OK because you can't mix EAPIs at that level. > I really don't see the necessity to have so many EAPI's A new EAPI is needed for new features, so new EAPIs will be needed in the future. Equally, migrating the whole tree at once to newer EAPIs is a) a lot of unnecessary work, and b) unnecessarily irritating to people using older package managers. > especially PM specific EAPI. We can't have PM specific EAPI, > otherwise we are risking forking/splitting ourself. Package manager EAPIs don't belong in the main tree, but they have uses outside of it. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Ciaran McCreesh wrote: > On Fri, 21 Dec 2007 03:46:00 +0100 > Luca Barbato <[EMAIL PROTECTED]> wrote: >> Ciaran McCreesh wrote: >>> People who know what they're talking about are more than welcome to >>> contradict me. People who don't understand what's being discussed >>> (which is most people in this thread) need to learn to stop wasting >>> people's time. >> Point the documents that could help people getting an informed >> opinion, they would have to be referenced in the GLEP anyway. > > There are none. If anyone really wants to know, they can read the code > for their package manager of choice (or better, all of them). Then I suggest stop this discussion and make a documentation first. Seriously. > And no, it's not worth writing them. If people have time to spend > documenting ebuildy things, there are a lot more useful places to > start. It worths. It will influence our future. -- Zhang Le, Robert GPG key ID: 1E4E2973 Fingerprint: 0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973 -- [EMAIL PROTECTED] mailing list
Re: EAPI definition Was: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Santiago M. Mola wrote: > On Dec 20, 2007 8:01 PM, Zhang Le <[EMAIL PROTECTED]> wrote: >> How many EAPI's do we have now? > > In Portage tree we have "0" (default) and "1". There are others in > external projects, for example "prefix" (in Gentoo/Alt:Prefix) or > "paludis-1" (used in paludis repositories). > >> Where is the detailed definition of those EAPI's? > > "0", "1" and any further official EAPI are defined in PMS. There's a > svn repository at http://svn.repogirl.net/pms > >> How can we produce a new EAPI? > > I can't tell you the exact process, but look at EAPI bug trackers or > search for bugs assigned to [EMAIL PROTECTED] Also, search in > @-dev's archive. We should make a FAQ about all this. > >> IMO, we can not have more than two EAPI's simultaneously. >> The only situation in which we can have two EAPI is in the transition period >> of those two EAPI's. And we should set a time constraint on the transition. >> > > Quite the opposite. EAPI's are designed to live happily together in > the same repository. A current example: most (or lots...) ebuilds in > the tree don't need EAPI="1" and it's pointless to migrate all of > them. We can switch EAPI on an as needed basis. But EAPI's can not always co-exist harmoniously. What if a future EAPI come up with a totally new DEPENDENCY setting[1], which is incompatible with existing ones. I really don't see the necessity to have so many EAPI's, especially PM specific EAPI. We can't have PM specific EAPI, otherwise we are risking forking/splitting ourself. [1] https://bugs.gentoo.org/show_bug.cgi?id=201499 -- Zhang Le, Robert GPG key ID: 1E4E2973 Fingerprint: 0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973 -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Fri, 21 Dec 2007 11:09:44 +0800 Zhang Le <[EMAIL PROTECTED]> wrote: > no slang in one's words is just a minimum requirement of > communication. There was no slang. That was plain English. > I see it differently. > Everyone participated in this discussion has shown their concerns > about their distro. > If someone don't understand, we should help them to understand, not > just exclude them from this discussion. > They should learn, however we should at least give them directions. Which is all very well, but highly impractical. If someone wants to write up a document explaining the metadata process then they're more than welcome to -- but there are much more useful things that could be documented if people had time... -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Fri, 21 Dec 2007 10:59:14 +0800 Zhang Le <[EMAIL PROTECTED]> wrote: > However, it is only 3 chars. > ebuild-1 is way too long, which is what I think not elegant. Why? This is Unix, not dos. > And file extension like welcome.html.fr is quite self-explanatory. > But an total outsider has no chance to deduce what the 1 in ebuild-1 > means on his own. A total outsider doesn't need to know. The only people who will be dealing with .ebuild-* files are developers and power users. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Ciaran McCreesh wrote: > On Thu, 20 Dec 2007 14:54:10 +0100 > "Denis Dupeyron" <[EMAIL PROTECTED]> wrote: >> On Dec 20, 2007 12:12 PM, Ciaran McCreesh >> <[EMAIL PROTECTED]> wrote: >>> I'm guessing there're lots of people moaning because they think they >>> understand filenames and can therefore comment. Unfortunately, most >>> of those people don't understand the metadata generation process, >>> and therefore can't comment usefully... >> Stop guessing, then. You're way off. You apparently do not understand >> that an assertion without justification has no value in a serious >> discussion. > > I was being nice. Next time I'll post a list of names of people who > don't understand the metadata generation process and who therefore > can't comment usefully... no slang in one's words is just a minimum requirement of communication. > >> And sorry to disappoint you but you're not alway >> right. You have to give people a chance to contradict you, for your >> own good. > > People who know what they're talking about are more than welcome to > contradict me. People who don't understand what's being discussed > (which is most people in this thread) need to learn to stop wasting > people's time. I see it differently. Everyone participated in this discussion has shown their concerns about their distro. If someone don't understand, we should help them to understand, not just exclude them from this discussion. They should learn, however we should at least give them directions. -- Zhang Le, Robert GPG key ID: 1E4E2973 Fingerprint: 0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973 -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Fri, 21 Dec 2007 03:46:00 +0100 Luca Barbato <[EMAIL PROTECTED]> wrote: > Ciaran McCreesh wrote: > > People who know what they're talking about are more than welcome to > > contradict me. People who don't understand what's being discussed > > (which is most people in this thread) need to learn to stop wasting > > people's time. > > Point the documents that could help people getting an informed > opinion, they would have to be referenced in the GLEP anyway. There are none. If anyone really wants to know, they can read the code for their package manager of choice (or better, all of them). And no, it's not worth writing them. If people have time to spend documenting ebuildy things, there are a lot more useful places to start. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Fri, 21 Dec 2007 10:49:04 +0800 Zhang Le <[EMAIL PROTECTED]> wrote: > > Because the process is decidedly non-trivial, and anyone who hasn't > > spent a considerable time studying it and understanding it isn't > > going to be able to contribute anything useful anyway. > > But human beings are able to understand it, right? Sure, if they think about it carefully. > Is there any documentation about it? Nope. Not beyond the code, anyway... Although the code is clear enough that anyone who's going to be able to understand the explanation can understand the code. > If not, why not consider write one? Because it's a waste of time. > It should not appear as a black box, and effectively prevent normal > gentoo users and developers from contributing to decisions which may > have a great impact on their distro. The GLEP doesn't have a great impact. It's a purely internal matter that shouldn't be visible to users at all and should be very easy for developers to follow once implemented. Really, the idea that anyone can contribute and express a useful opinion is all very well, but it's terribly naive. Do you expect to be asked to give your opinion upon the proportion of zinc mixed in with the aluminium in your car? Do you tell your doctor how much thimerosal you want in your medicine? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Fri, 21 Dec 2007 03:44:20 +0100 Luca Barbato <[EMAIL PROTECTED]> wrote: > Ciaran McCreesh wrote: > > On Fri, 21 Dec 2007 03:14:12 +0100 > > Luca Barbato <[EMAIL PROTECTED]> wrote: > >> Ciaran McCreesh wrote: > >>> Ok. What's the EAPI for the following ebuild that's written in an > >>> EAPI that hasn't been published yet? And how would I extract it? > >>> > >>> # Copyright blah blah > >>> > >>> import vim-spell using language="en" > >> If isn't published it doesn't exist in the main tree... > > > > You miss my point. If a package manager encounters the above, how > > does it determine the EAPI? > > > > from : > > - a default set by the repository, if we chose to use that > - a default set by itself > - by not understanding it thus failing in a brutal (hard error) or > gentle (ignore the file, warn) way. None of those solve the original problem. > I'm looking for alternatives. From the filename suffix. Simple! -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Ciaran McCreesh wrote: > On Fri, 21 Dec 2007 02:52:16 +0800 > Zhang Le <[EMAIL PROTECTED]> wrote: >> Exactly. >> And this way is not elegant. >> File name is used to uniquely identify a file in a system, not to >> decide how the content of the file should be interpreted. >> Never ever seen a file type extension with a version number. > > http://httpd.apache.org/docs/2.0/mod/mod_mime.html > > You might find that interesting reading. Thanks. Actually coldwind also reminded me of mp3. However, it is only 3 chars. ebuild-1 is way too long, which is what I think not elegant. And file extension like welcome.html.fr is quite self-explanatory. But an total outsider has no chance to deduce what the 1 in ebuild-1 means on his own. -- Zhang Le, Robert GPG key ID: 1E4E2973 Fingerprint: 0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973 -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Fri, 21 Dec 2007 10:52:04 +0800 Zhang Le <[EMAIL PROTECTED]> wrote: > Ciaran McCreesh wrote: > > On Fri, 21 Dec 2007 03:14:12 +0100 > > Luca Barbato <[EMAIL PROTECTED]> wrote: > >> Ciaran McCreesh wrote: > >>> Ok. What's the EAPI for the following ebuild that's written in an > >>> EAPI that hasn't been published yet? And how would I extract it? > >>> > >>> # Copyright blah blah > >>> > >>> import vim-spell using language="en" > >> If isn't published it doesn't exist in the main tree... > > > > You miss my point. If a package manager encounters the above, how > > does it determine the EAPI? > > As long as there is an agreement between the PM and ebuild, you can > get what you want no matter how it is defined. So how does one get the EAPI in the above example? Bear in mind that package managers can only use what's been agreed upon at the time they were released, not what might be agreed upon later -- and yet they need to be able to extract the EAPI from anything agreed upon later. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Fri, 21 Dec 2007 03:41:04 +0100 Luca Barbato <[EMAIL PROTECTED]> wrote: > Ciaran McCreesh wrote: > > On Fri, 21 Dec 2007 03:17:12 +0100 > > Luca Barbato <[EMAIL PROTECTED]> wrote: > >> Putting a tag in the file name or at the to of the file as comment > >> (maybe using a #! line) is the same ... > > > > Three problems: > > > > * We have to wait a year before we can use it. > > We have to wait till we got a new release and I hope it isn't > 12months. No, you have to wait until it's safe to assume that everyone's using a package manager that supports it. > > * It's a format restriction. Some formats have to start with > > something that's not #!. > > if the format doesn't allow anymore the #! comment for then it won't > be an ebuild anymore but an xbuild a ybuild a jbuild or whatever > markup you may propose as alternative to shell like syntax. Mmhmm. And then... Oh, we'd use a new file extension. > > * Ebuilds can't sensibly run in a Unix interpreterish way. > > Would you mind articulate a bit? There's no sensible way for ./blah-1.23.ebuild to work. Ebuilds aren't self-hosting, and a package manager isn't an interpreter, so the #! model doesn't work very well. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Ciaran McCreesh wrote: > People who know what they're talking about are more than welcome to > contradict me. People who don't understand what's being discussed > (which is most people in this thread) need to learn to stop wasting > people's time. Point the documents that could help people getting an informed opinion, they would have to be referenced in the GLEP anyway. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Ciaran McCreesh wrote: > On Fri, 21 Dec 2007 03:17:12 +0100 > Luca Barbato <[EMAIL PROTECTED]> wrote: >> Putting a tag in the file name or at the to of the file as comment >> (maybe using a #! line) is the same ... > > Three problems: > > * We have to wait a year before we can use it. We have to wait till we got a new release and I hope it isn't 12months. > * It's a format restriction. Some formats have to start with something > that's not #!. if the format doesn't allow anymore the #! comment for then it won't be an ebuild anymore but an xbuild a ybuild a jbuild or whatever markup you may propose as alternative to shell like syntax. > * Ebuilds can't sensibly run in a Unix interpreterish way. Would you mind articulate a bit? lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Fri, 21 Dec 2007 03:17:12 +0100 Luca Barbato <[EMAIL PROTECTED]> wrote: > Putting a tag in the file name or at the to of the file as comment > (maybe using a #! line) is the same ... Three problems: * We have to wait a year before we can use it. * It's a format restriction. Some formats have to start with something that's not #!. * Ebuilds can't sensibly run in a Unix interpreterish way. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Fri, 21 Dec 2007 03:14:12 +0100 Luca Barbato <[EMAIL PROTECTED]> wrote: > Ciaran McCreesh wrote: > > Ok. What's the EAPI for the following ebuild that's written in an > > EAPI that hasn't been published yet? And how would I extract it? > > > > # Copyright blah blah > > > > import vim-spell using language="en" > > If isn't published it doesn't exist in the main tree... You miss my point. If a package manager encounters the above, how does it determine the EAPI? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Ciaran McCreesh wrote: > No. Issues like this benefit from *well informed* diverse viewpoints. > They don't benefit from people running around going "waah! waah! > doesn't look nice! add format restrictions!" without understanding why > it's necessary. Putting a tag in the file name or at the to of the file as comment (maybe using a #! line) is the same ... We aren't on DOS we can use that nice tool called file and it's magic... lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Ciaran McCreesh wrote: > Ok. What's the EAPI for the following ebuild that's written in an EAPI > that hasn't been published yet? And how would I extract it? > > # Copyright blah blah > > import vim-spell using language="en" If isn't published it doesn't exist in the main tree... lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: [RFC] Some new global USE-flags
Ciaran McCreesh wrote: custom-cflags 7 This one shouldn't be a use flag at all. Pushing it global will just encourage even more people to use it. +1 -- looks like christmas at fifty-five degrees this latitude weakens my knees EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 (0xF9A40662) -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [RFC] Some new global USE-flags
On Thu, 20 Dec 2007 19:57:12 +0100 Markus Meier <[EMAIL PROTECTED]> wrote: > server12 See previous discussions on why this can't be global (essentially, it has different meanings for everything). > custom-cflags 7 This one shouldn't be a use flag at all. Pushing it global will just encourage even more people to use it. > multislot 6 Ditto. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Thu, 20 Dec 2007 14:54:10 +0100 "Denis Dupeyron" <[EMAIL PROTECTED]> wrote: > On Dec 20, 2007 12:12 PM, Ciaran McCreesh > <[EMAIL PROTECTED]> wrote: > > I'm guessing there're lots of people moaning because they think they > > understand filenames and can therefore comment. Unfortunately, most > > of those people don't understand the metadata generation process, > > and therefore can't comment usefully... > > Stop guessing, then. You're way off. You apparently do not understand > that an assertion without justification has no value in a serious > discussion. I was being nice. Next time I'll post a list of names of people who don't understand the metadata generation process and who therefore can't comment usefully... > Even it that has already been explained somewhere else, it > may have been interpreted differently by different people (assuming > they can find it). How they interpret is different from the objective fact of what the process is. > And sorry to disappoint you but you're not alway > right. You have to give people a chance to contradict you, for your > own good. People who know what they're talking about are more than welcome to contradict me. People who don't understand what's being discussed (which is most people in this thread) need to learn to stop wasting people's time. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Thu, 20 Dec 2007 14:33:25 -0700 Joe Peterson <[EMAIL PROTECTED]> wrote: > P.S. I just joined Gentoo this year, and it is disheartening to see > the nastiness that some people are resorting to on this list. I've > never seen so much anger and biting remarks in a project, and I can > imagine it keeps some from responding, which is ashame, since issues > like this benefit from many diverse viewpoints. No. Issues like this benefit from *well informed* diverse viewpoints. They don't benefit from people running around going "waah! waah! doesn't look nice! add format restrictions!" without understanding why it's necessary. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Fri, 21 Dec 2007 02:52:16 +0800 Zhang Le <[EMAIL PROTECTED]> wrote: > Exactly. > And this way is not elegant. > File name is used to uniquely identify a file in a system, not to > decide how the content of the file should be interpreted. > Never ever seen a file type extension with a version number. http://httpd.apache.org/docs/2.0/mod/mod_mime.html You might find that interesting reading. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Thu, 20 Dec 2007 08:56:01 -0500 Richard Freeman <[EMAIL PROTECTED]> wrote: > Ciaran McCreesh wrote: > > Because a) a future EAPI might want to change EAPI into a function > > rather than a variable, > > Why? It couldn't be dynamic - not if you're going to put it in the > filename as well. And why have it in two places? If you are going to > put the EAPI in the filename, why put it inside the ebuild as well? > We don't do that with version numbers or package names. eapi 3 Is considered by some to look nicer than EAPI="3" > > b) there are a zillion ways of setting a > > variable in bash and people already use all of them and c) > > introducing new weird format requirements is silly. > > But this GLEP is already proposing a format requirement. It is just > putting it in the filename instead of in the ebuild contents. It > isn't like you could just put anything in the filename anywhere you > want and the package manager will be able to understand it. If devs > are going to have to get correct "-1" at the end of the filename, why > couldn't they also get right "EAPI=1" inside the file? Because in the future we might want to have something other than setting EAPIs by EAPI=1. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Fri, 21 Dec 2007 02:45:48 +0800 Zhang Le <[EMAIL PROTECTED]> wrote: > Ciaran McCreesh wrote: > > And again, you show that you don't understand what's going on. EAPI > > is only specified once except where developers screw up. The GLEP > > merely moves the EAPI to being set *before* the metadata is > > generated, which removes all the restrictions that having EAPI as > > part of the ebuild's content imposes. > > So, you are saying if developers screw up, then the EAPI could be > specified twice, namely in file name and in file content. > But why should we tolerate that? Uh, you don't. You just specify how the package manager handles it because there's no room for undefined behaviour here. > And as I have said before, I don't see why having EAPI as part of the > ebuild's content has any restrictions. > You can extrace the definition from file content no matter how it is > defined using whatever way you like. Ok. What's the EAPI for the following ebuild that's written in an EAPI that hasn't been published yet? And how would I extract it? # Copyright blah blah import vim-spell using language="en" -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Re: Re: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Thu, 20 Dec 2007 12:48:31 + Steve Long <[EMAIL PROTECTED]> wrote: > Point is that your filename format restricts it in exactly the same > manner. So let's just stick with the use cases which /that/ supports, > which can more easily be supported with the original design and the > simple restriction people keep asking for. Er, the use case is having trivial-as-possible ebuilds for things that really are purely eclass managed. > >> No: without knowing the EAPI when generating said data. If that > >> needs to be known relatively soon in order to generate the rest, > >> extract it early. You still only need to load the file from disk > >> once, and you don't need to source to get that data, given one > >> simple restriction (only declaring it once.) > > > > You can't get the EAPI from the ebuild without knowing what EAPI the > > ebuild uses. That's one of the points you're missing. > > > Wow that doesn't half sound like nonsense. Unfortunately, it's not nonsense. It's entirely true. If you don't understand that then you can't contribute anything useful to the discussion, so kindly stay out of it. > An EAPI="blah" at top-level in the file is exactly the same as the > suffix in terms of what can be represented But not in what can be changed. > According to the original discussion this was always supposed to be a > variable set in the ebuild source: And things moved on. Right back when this first came up several people pointed out why a variable isn't an optimal solution. > At that time others made the case for restricting its format in > exactly the same way you have been resisting for the ebuild source, > but see as fine for tacking onto the end of the filename: > "I would also suggest requiring that EAPI can be retrieved by a > simple line by line parsing without using bash. (This allows for > changing the parsing system)"[2] Except that that proposal doesn't work, as we've already established. > The idea of a different suffix was discussed back then as well: > "portage *should not* ignore those ebuilds. If the user > wants to merge something that is a later ebuild api then they have, > at least portage chucks an exception that the UI can wrap into > 'upgrade portage'. There are times when the ebuilds have to be ignored. > With what you're proposing, we instead get bugs about portage missing > packages."[3] Only when absolutely necessary -- and it's only absolutely necessary when introducing changes such as version suffix extensions that would result in packages not being usable anyway. > (That was written when there were no other PMs besides > portage3/pkgcore) Learn your history. > > It's an ebuild issue, not a package manager issue. > > > You keep saying that; sure EAPI is visible to ebuild and maintainer > (doh) but the reason you have stated for this change in file naming > (which is a lot more far-reaching than a simple restriction on the > format of a variable) is so that the *PM* doesn't have to source the > ebuild to get the EAPI. It's so that the ebuild's EAPI can be extracted. The way things are currently, there is no way to get an ebuild's EAPI without already knowing its EAPI. > > You're confusing the two different types of metadata. Which again > > shows that you need to start understanding the metadata process > > before trying to discuss design decisions relating to it... > > > It doesn't make any practical difference[4]: the computational issue > is how to avoid a source statement via bash from another language. > > I note in passing that a metadata cache is available, with no runtime > requirement on the user's part, since it is taken from the rsync'ed > data. And *again* you demonstrate that you don't understand the metadata process. The metadata cache cannot be generated without already knowing the ebuild's EAPI, which is part of its metadata. > >> (optimising early here seems silly tbh, given that paludis now > >> requires ruby.) > > > > Eh? Now what're you on about? > > > http://bugs.gentoo.org/show_bug.cgi?id=198864 Thankyou for demonstrating to everyone that you don't know what a USE flag is. > >> >> > Ebuilds are not config files. > >> >> > > >> >> Indeed not, but they can be parsed as such for simple, core, > >> >> metadata. > >> > > >> > There is currently no information available from an ebuild that > >> > can be parsed by any tool other than bash. > >> > > >> OK, but restricting EAPI= across the board (in the way that others > >> have already asked for) and enforcing it via repoman would mean > >> EAPI could easily be extracted. > > > > Except that it's an arbitrary, pointless restriction. > > > Er arbitrary, no, since in practise it means exactly the same thing > as the filename suffix (one single string declaration.) Pointless not > at all, since it allows you to avoid calling bash and waiting for it > to source, without an ugly hack. It also keeps the existing work > practises that everyone is used to and doesn't mandate any changes to > suppo
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Thu, 20 Dec 2007 16:57:54 +0100 Michael Haubenwallner <[EMAIL PROTECTED]> wrote: > What if we do not start with "EAPI=1" variable, but "eapi 1" function > immediately ? Uh. Then we're back to the zillion months wait before people can use anything. > *) Given it is the first bash-command in the ebuild: > Just 'echo' the required EAPI and exit while PM is in "look-for-eapi" > mode (remember 'eapi' function is part of PM, or profile.bashrc as > fallback for ancient PM). There isn't a look for eapi mode. > *) As 'eapi' being a bash function, it could *migrate* the > bash-environment from the PM's default EAPI to the given one - or just > spit "cannot migrate EAPI from A to B"... Uh... No it couldn't. And there's no default EAPI. > *) Or just spit a message "update your PM" (from profile.bashrc) ... Uh... No it couldn't. Please don't comment any further until you understand how this whole thing works. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Fri, 21 Dec 2007 02:27:27 +0800 Zhang Le <[EMAIL PROTECTED]> wrote: > Ciaran McCreesh wrote: > > You need to understand the metadata generation process to > > understand why the package manger has to assume a particular EAPI > > when generating the metadata. > > There are many people watching this thread all over the world I think. > Not all of them understand the process. > And you are keeping scolding people for not understanding the process. > > So, why not introduce the process a little bit? Because the process is decidedly non-trivial, and anyone who hasn't spent a considerable time studying it and understanding it isn't going to be able to contribute anything useful anyway. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: EAPI definition Was: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Thursday, 20. December 2007 21:27:03 Markus Ullmann wrote: > Erm no, PMS isn't officially until council made a decision on it (and > I'm not aware of one yet). > Currently "official" EAPIs are 0 and 1. And EAPI-1 is defined where? :) -- Best regards, Wulf signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [RFC] Some new global USE-flags
Santiago M. Mola wrote: > These are potentially ambiguos. Could you please elaborate a bit about the raw one? Cheers, -jkt -- cd /local/pub && more beer > /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Thomas Pani wrote: > My concern is technical: Filenames are for identifying files uniquely. > An ebuild is uniquely identified by /-, so that's what it's > filename should be. Adding anything else to the filename will only > clutter the tree and lead to additional inconsitencies. Yes, you can > check for these using QA tools. But if it's not in the filename you > don't have to check. > If you say that package managers need the EAPI info so early that they > can't even read the first non-comment line of an ebuild that's fine. Go > and place it in the filename. But nobody had a *technical* argument why > that's the only possible solution so far. All I got was "you don't > understand all that fancy PM stuff". Good point. First of all, and this is an architecture/design issue, the only valid reason to put the EAPI in the filename is that is *belongs* there in principal. File extensions are for file types, not for info that really should be in the file. If the motivation for placing the info in the filename (and worse, the *extension*) is that of performance, you should think twice about putting it there. If this is to address a technical problem, it should be solved in a technical way. The format of a filename should be determined by policy, not technical implementation or convenience. Technical reasons to avoid the filename are: 1) Increase of [needless] complexity in filenames/extensions (and only one example of the impact is that searching for ebuild files becomes less straightforward). 2) Having the same info in more than one place is bad (requiring extra repoman checks and the potential for ambiguity). 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 stricty 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. Other reasons: 1) Littering the filename with this kind of stuff is potentially confusing do both devs and users - I know it's been stated that users don't care, but I don't think that's a good assumption. 2) It does not appear to be an elegant filename policy (and this can be considered technical as well), since elegance is something designed int good systems. 3) Assuming going this route is a mistake, it could be hard to reverse. I just don't want to see something like this happen as a quick fix without exploring all of the implications and how it effects what I consider a very good system (portage/ebuilds) currently. Also, it seems to me that there are lots of other alternatives that have been discussed here (and some dismissed rather quickly). Portage and its policy are very core to Gentoo, and care should be taken on this. -Joe P.S. I just joined Gentoo this year, and it is disheartening to see the nastiness that some people are resorting to on this list. I've never seen so much anger and biting remarks in a project, and I can imagine it keeps some from responding, which is ashame, since issues like this benefit from many diverse viewpoints. -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: EAPI definition Was: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Santiago M. Mola wrote: > On Dec 20, 2007 8:01 PM, Zhang Le <[EMAIL PROTECTED]> wrote: >> Where is the detailed definition of those EAPI's? > > "0", "1" and any further official EAPI are defined in PMS. There's a > svn repository at http://svn.repogirl.net/pms Erm no, PMS isn't officially until council made a decision on it (and I'm not aware of one yet). Currently "official" EAPIs are 0 and 1. Greetz -Jokey signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in x11-libs/qt-opengl: qt-opengl-4.4.0_rc1.ebuild metadata.xml ChangeLog Manifest
On 16:33 Thu 20 Dec , Caleb Tennis (caleb) wrote:
> Revision ChangesPath
> 1.1 x11-libs/qt-opengl/qt-opengl-4.4.0_rc1.ebuild
>
> file :
> http://sources.gentoo.org/viewcvs.py/gentoo-x86/x11-libs/qt-opengl/qt-opengl-4.4.0_rc1.ebuild?rev=1.1&view=markup
> plain:
> http://sources.gentoo.org/viewcvs.py/gentoo-x86/x11-libs/qt-opengl/qt-opengl-4.4.0_rc1.ebuild?rev=1.1&content-type=text/plain
> RDEPEND="=x11-libs/qt-4.4.0_rc1
> ( virtual/opengl virtual/glu )"
Did you autogenerate these ebuilds? It looks like the deps were pulled
out of a conditional in the original qt.
> pkg_setup() {
> QTBASEDIR=/usr/$(get_libdir)/qt4
> QTPREFIXDIR=/usr
> QTBINDIR=/usr/bin
> QTLIBDIR=/usr/$(get_libdir)/qt4
> QTPCDIR=/usr/$(get_libdir)/pkgconfig
> QTDATADIR=/usr/share/qt4
> QTDOCDIR=/usr/share/doc/${PF}
> QTHEADERDIR=/usr/include/qt4
> QTPLUGINDIR=${QTLIBDIR}/plugins
> QTSYSCONFDIR=/etc/qt4
> QTTRANSDIR=${QTDATADIR}/translations
> QTEXAMPLESDIR=${QTDATADIR}/examples
> QTDEMOSDIR=${QTDATADIR}/demos
> }
I've seen this in all of the split qt ebuilds. Should it go in the eclass?
> src_compile() {
> export PATH="${S}/bin:${PATH}"
> export LD_LIBRARY_PATH="${S}/lib:${LD_LIBRARY_PATH}"
>
> [ $(get_libdir) != "lib" ] && myconf="${myconf} -L/usr/$(get_libdir)"
>
> # Disable visibility explicitly if gcc version isn't 4
> if [[ "$(gcc-major-version)" != "4" ]]; then
To future-proof, might want to check for -ge 4 instead.
> src_install() {
> export PATH="${S}/bin:${PATH}"
> export LD_LIBRARY_PATH="${S}/lib:${LD_LIBRARY_PATH}"
Why do you need to do this again? It should've been saved from the last
phase.
> pkg_postinst()
> {
> # Need to add opengl to QT_CONFIG line
> sed -i -e "s:opengl ::g" ${QTDATADIR}/mkspecs/qconfig.pri
> sed -i -e "s:QT_CONFIG += :QT_CONFIG += opengl :g"
> ${QTDATADIR}/mkspecs/qconfig.pri
> }
>
> pkg_postrm()
> {
> # Need to add opengl to QT_CONFIG line
> sed -i -e "s:opengl ::g" ${QTDATADIR}/mkspecs/qconfig.pri
> }
The postrm comment doesn't match the action.
Thanks,
Donnie
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On 11:26 Thu 20 Dec , Bo Ørsted Andresen wrote: > On Thursday 20 December 2007 11:09:44 Donnie Berkholz wrote: > > > > Looking at my kernel config, ext3 and reiser explicitly support > > > > xattrs, and I see jfs and xfs have acls and security labels, > > > > which might be usable. > [...] > > The idea of the sqlite-based fallback is what's interesting here. > > I thought some of the other ideas were pretty bad... Guess I was > wrong... This is the worst idea I have ever heard. Thanks for your useful and detailed criticism. Donnie -- [EMAIL PROTECTED] mailing list
Re: EAPI definition Was: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Dec 20, 2007 8:01 PM, Zhang Le <[EMAIL PROTECTED]> wrote: > > How many EAPI's do we have now? In Portage tree we have "0" (default) and "1". There are others in external projects, for example "prefix" (in Gentoo/Alt:Prefix) or "paludis-1" (used in paludis repositories). > Where is the detailed definition of those EAPI's? "0", "1" and any further official EAPI are defined in PMS. There's a svn repository at http://svn.repogirl.net/pms > How can we produce a new EAPI? I can't tell you the exact process, but look at EAPI bug trackers or search for bugs assigned to [EMAIL PROTECTED] Also, search in @-dev's archive. > > IMO, we can not have more than two EAPI's simultaneously. > The only situation in which we can have two EAPI is in the transition period > of those two EAPI's. And we should set a time constraint on the transition. > Quite the opposite. EAPI's are designed to live happily together in the same repository. A current example: most (or lots...) ebuilds in the tree don't need EAPI="1" and it's pointless to migrate all of them. We can switch EAPI on an as needed basis. > Other than that we can only have one working EAPI which all package managers > conforms to. Read above, and other discussions. That's also pointless because we don't need to force all third party overlays to upgrade EAPI everytime we have a new one... -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED] -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Petteri Räty wrote: > Donnie Berkholz kirjoitti: >> Unportable to filesystems that don't support extended attributes isn't >> very interesting to me, unless they're common. Out of curiosity, do you >> know which ones that would be? Looking at my kernel config, ext3 and >> reiser explicitly support xattrs, and I see jfs and xfs have acls and >> security labels, which might be usable. Unsyncable would be a problem, >> so it's a good thing rsync has USE=xattr -- do the difficulties come in >> on the CVS side? Why do you say unmaintainable? >> > > Many users might have extended attributes support turned off in the kernel. /me raises hand. yup. don't use 'em. waste of kernel space. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Some new global USE-flags
On Dec 20, 2007 7:57 PM, Markus Meier <[EMAIL PROTECTED]> wrote: > > raw: Add support for raw image formats > keyring: Enable gnome-keyring support for storing passwords > These are potentially ambiguos. I have no objections for the others. -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED] -- [EMAIL PROTECTED] mailing list
Re: EAPI definition Was: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Luca Barbato wrote: > Before spending even more time on it, could we try to come up with a > definition of what eapi is, which problem is trying to solve and put > that somewhere that isn't a long thread or an handful of threads > scattered across mailing lists. I think we also need to know: How many EAPI's do we have now? Where is the detailed definition of those EAPI's? How can we produce a new EAPI? IMO, we can not have more than two EAPI's simultaneously. The only situation in which we can have two EAPI is in the transition period of those two EAPI's. And we should set a time constraint on the transition. Other than that we can only have one working EAPI which all package managers conforms to. Otherwise, I think we may be risking forking the portage tree. -- Zhang Le, Robert GPG key ID: 1E4E2973 Fingerprint: 0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973 -- [EMAIL PROTECTED] mailing list
[gentoo-dev] [RFC] Some new global USE-flags
Potential candidates (flag-name, count): server12 subversion10 latex 9 suid 8 atm 7 zeroconf 7 logrotate 7 gimp 7 cgi 7 custom-cflags 7 wavpack 7 timidity 6 branding 6 java5 6 v4l2 6 multislot 6 webdav6 vnc 6 audacious 6 demo 6 music 5 fax 5 raw 5 gsm 5 novideo 5 xemacs5 editor5 keyring 5 networkmanager5 oci8-instant-client 5 html 5 css 5 enscript 5 gnuplot 5 xcb 5 lzo 5 nfs 5 jingle5 hddtemp 5 rss 5 cxx 5 cvs 5 http 5 taglib5 Propositions: subversion: Enable subversion support latex: Adds support for LaTeX (typesetting package) [this one is questionable, as this flag has different meanings/effects - but is one of the tetex-flag replacements] suid: Enable seduid root program, with potential security risks atm: Enable Asynchronous Transfer Mode protocol support zeroconf: Support for DNS Service Discovery (DNS-SD) gimp: Build a plugin for the GIMP cgi: Add CGI script support custom-cflags: Use CFLAGS from /etc/make.conf rather than the default package CFLAGS (not supported) wavpack: Add support for wavpack timidity: Build with Timidity++ (MIDI sequencer) support branding: Enable Gentoo specific branding [questionable, as used for splashes/shortcuts/artwork] v4l2: Enable video4linux2 support vnc: Enable vnc support raw: Add support for raw image formats xemacs: Add support for XEmacs keyring: Enable gnome-keyring support for storing passwords networkmanager: Enable networkmanager support oci8-instant-client: Use dev-db/oracle-instantclient-basic as Oracle provider instead of requiring a full Oracle server install enscript: Add enscript support to colourize code stored in the repository gnuplot: Enable gnuplot support xcb: Support the X C-language Binding, a replacement for Xlib lzo: Enables support for lzo compression jingle: Enables voice calls for jabber hddtemp: Enable monitoring of hdd temperature (app-admin/hddtemp) rss: Enables support for RSS feeds taglib: Enable tagging support with taglib Comments are welcome. Markus signature.asc Description: PGP signature
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Jim Ramsay wrote: > Luca Barbato <[EMAIL PROTECTED]> wrote: >> How would it be different than having EAPI="string" put in a defined >> position of the file? > > It's not - It is just defining that position to be in the name of the > file instead of the contents :) Exactly. And this way is not elegant. File name is used to uniquely identify a file in a system, not to decide how the content of the file should be interpreted. Never ever seen a file type extension with a version number. -- Zhang Le, Robert GPG key ID: 1E4E2973 Fingerprint: 0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973 -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Ciaran McCreesh wrote: > And again, you show that you don't understand what's going on. EAPI is > only specified once except where developers screw up. The GLEP merely > moves the EAPI to being set *before* the metadata is generated, which > removes all the restrictions that having EAPI as part of the ebuild's > content imposes. So, you are saying if developers screw up, then the EAPI could be specified twice, namely in file name and in file content. But why should we tolerate that? And as I have said before, I don't see why having EAPI as part of the ebuild's content has any restrictions. You can extrace the definition from file content no matter how it is defined using whatever way you like. -- Zhang Le, Robert GPG key ID: 1E4E2973 Fingerprint: 0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973 -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Ciaran McCreesh wrote: > I'm guessing there're lots of people moaning because they think they > understand filenames and can therefore comment. Unfortunately, most of > those people don't understand the metadata generation process, and > therefore can't comment usefully... So please make those people understand, so they can comment usefully. -- Zhang Le, Robert GPG key ID: 1E4E2973 Fingerprint: 0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973 -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Ciaran McCreesh wrote: > > You need to understand the metadata generation process to understand why > the package manger has to assume a particular EAPI when generating the > metadata. There are many people watching this thread all over the world I think. Not all of them understand the process. And you are keeping scolding people for not understanding the process. So, why not introduce the process a little bit? -- Zhang Le, Robert GPG key ID: 1E4E2973 Fingerprint: 0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973 -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Ciaran McCreesh wrote: > On Thu, 20 Dec 2007 09:43:59 + (UTC) > Duncan <[EMAIL PROTECTED]> wrote: >>> Because a) a future EAPI might want to change EAPI into a function >>> rather than a variable, b) there are a zillion ways of setting a >>> variable in bash and people already use all of them and c) >>> introducing new weird format requirements is silly. >> So you're proposing putting the function into the filename? > > No, I'm saying that the data goes into the filename. then why not let it go into the file content? if data goes into file content, then function is not needed you are contradicting with yourself here. > >> As he stated, the only credible reason (so far given) bash must be >> used to parse EAPI is if it's dynamic, say a function, and that won't >> work so well in a filename either. > > No no no. Bash is the only thing that can parse bash. Ebuilds are bash. Getting the first line of a file using whatever language is just a piece of cake. And I don't see why setting a rule on the syntax of EAPI definition is so silly. How many ways to define a variable in bash can you think of? Is it that hard to come up with a way to normalized the definition? Just like charset code normalization, e.g. from UTF-8 to utf8? -- Zhang Le, Robert GPG key ID: 1E4E2973 Fingerprint: 0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973 -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Luca Barbato wrote: > Rémi Cardona wrote: > >> I'll speak up then :) >> >> What I _really_ would like to see ASAP : >> >> 1) Dropping digest-* files for real (ie, not even having them on the >> master rsync server and CVS) >> Slated for after 2007.1 is released. >> 2) Slotted deps (I had the feeling we were really close to having this a >> while back, and then radio silence, maybe I missed the final announcement?) >> You can already. Assuming you don't mind putting EAPI=1 inside of your ebuilds. >> 3) USE-deps >> > > Ok those interesting. > > >> As for the politics behind the naming of the EAPI, where it should be >> placed in the ebuild, whether it should be in metadata.xml or in the >> filename, I don't really care that much. >> > > I'm thinking about having them embedded in the comment as first line as > something like > > #!/usr/bin/env emerge --eapi $foo > > I always wondered why we didn't put a shebang as such at the top of ebuilds. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Rémi Cardona wrote: > I'll speak up then :) > > What I _really_ would like to see ASAP : > > 1) Dropping digest-* files for real (ie, not even having them on the > master rsync server and CVS) > > 2) Slotted deps (I had the feeling we were really close to having this a > while back, and then radio silence, maybe I missed the final announcement?) > > 3) USE-deps Ok those interesting. > As for the politics behind the naming of the EAPI, where it should be > placed in the ebuild, whether it should be in metadata.xml or in the > filename, I don't really care that much. I'm thinking about having them embedded in the comment as first line as something like #!/usr/bin/env emerge --eapi $foo or # EAPI=$foo IFF we want to consider single ebuilds, but since I don't like the approach at all here another proposal: I'd rather have a way to sync the tree so that: - if your pm supports all the features you get the tree - if your pm doesn't you get a minimal tree that let you update to the newer one. That means having a way to maintain a branch with just system and the update path and have a way to put eapi versioning per tree. This solves pretty much the root problems: "do not have the package manager break on tree update" and "have a way to update the package manager from an ancient setup w/out unpacking a newer stage on it (that could be yet another solution)" Feel free to flame/decostruct this proposal as you please. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Wulf C. Krueger wrote: >> I DO understand. > > You don't. The complete paragraph of yours shows you don't. > Interesting, because my statement is the same (in meaning) that Ciaran made two days ago. He stated it was "[...] another option. It's considered less ideal [...]" ([1], in case you want to look it up) >> But you're totally ignoring my point. So once again: You're trying to >> *SET* a standard here. There are lots of people telling you that they're >> not happy with the proposal to change the ebuild filename suffix. > > Yes, indeed. They're not happy with it. That's about all most > participants here have stated so far. There are two or three valid > *technical* concerns and all the rest is basically noise. > My concern is technical: Filenames are for identifying files uniquely. An ebuild is uniquely identified by /-, so that's what it's filename should be. Adding anything else to the filename will only clutter the tree and lead to additional inconsitencies. Yes, you can check for these using QA tools. But if it's not in the filename you don't have to check. If you say that package managers need the EAPI info so early that they can't even read the first non-comment line of an ebuild that's fine. Go and place it in the filename. But nobody had a *technical* argument why that's the only possible solution so far. All I got was "you don't understand all that fancy PM stuff". >> There seem to be less people opposed to having that ebuild format >> restriction. > > If this was only about the ebuild format restriction, I wouldn't even > bother to write a single mail on this subject. It's much more important > than that - the suggested GLEP would allow us to make use of new EAPI > features much earlier than now and without causing major problems, I think. > > Just this morning when I was reading my backlog in #-dev, I saw a > discussion between between two devs that culminated in the following: > > a> "So we can make use of this feature in about a year?" > b> "Yeah." > > Are we Debian now? A new feature gets implemented (obviously because we > *need* it) and we can make use of it in a *year*? > No, we're not Debian, thank god. I thought the "wait 1+ year" policy changed? Again citing Ciaran: "That was only the case because previously, using new features that Portage didn't support would cause horrible breakage. Now, instead, the ebuilds show up as being masked." [2] Regards, thomas [1] http://archives.gentoo.org/gentoo-dev/msg_149455.xml [2] http://archives.gentoo.org/gentoo-dev/msg_149031.xml -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Luca Barbato a écrit : > Wulf C. Krueger wrote: >> a> "So we can make use of this feature in about a year?" >> b> "Yeah." >> >> Are we Debian now? A new feature gets implemented (obviously because we >> *need* it) and we can make use of it in a *year*? > > What do we need so desperately? > >>> So either choose the one that's accepted by the majority >> The majority of devs doesn't even read here (not to speak of active >> participation). > > That says a lot in itself... I'll speak up then :) What I _really_ would like to see ASAP : 1) Dropping digest-* files for real (ie, not even having them on the master rsync server and CVS) 2) Slotted deps (I had the feeling we were really close to having this a while back, and then radio silence, maybe I missed the final announcement?) 3) USE-deps As for the politics behind the naming of the EAPI, where it should be placed in the ebuild, whether it should be in metadata.xml or in the filename, I don't really care that much. I'm much more interested in the 3 points above. To all devs that will end up hacking on PMS and their respective PM : don't let yourselves drown into loong term plans. Let's be an opensource community with a "release early, release often" mentality. Happy Holidays :) Rémi -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Thu, 2007-12-20 at 14:08 +0100, Thomas de Grenier de Latour wrote: Seems that there is a chain of different metadata levels: 1) The parser/interpreter/compiler/whatever to grok the ebuild. 2) *How* to extract the EAPI value from the ebuild(-filename), using 1) 3) The *value* of EAPI for that ebuild, using 2) 4) The contents of the ebuild, based on 3) To 1: for me it's absolutely acceptable to have it encoded in the filename (or extension). Fex we want to switch from bash to xml (for whatever reason), we could rename from *.ebuild to *.xbuild. > But yeah, to be honest, you're right that my original "as long as > ebuilds stay bash" was a bit optimistic: it was assuming there would > be no decision of changing that rule as long as there would be no good > reason for it (like a switch to xml or whatever other not-bash > format). To 2: it might be acceptable to have it encoded into the filename. To 3 (and 2): Thomas++ > I still think that changing file names when absolutly required > (switching from "EAPI=foo" to "eapi foo", or moving it elsewhere, or > switching to xml, etc.) is less disturbing than changing it for every > single new EAPI. It's not because one new extension may not be > eternally enough that we should introduce an infinity right now. To 4: we agree that this never will be encoded in the filename ;) Just another bit of brainstorm (forget it if too broken): What if we do not start with "EAPI=1" variable, but "eapi 1" function immediately ? I could think of several implementations to let PM detect EAPI: *) Given it is the first bash-command in the ebuild: Just 'echo' the required EAPI and exit while PM is in "look-for-eapi" mode (remember 'eapi' function is part of PM, or profile.bashrc as fallback for ancient PM). *) As 'eapi' being a bash function, it could *migrate* the bash-environment from the PM's default EAPI to the given one - or just spit "cannot migrate EAPI from A to B"... *) Or just spit a message "update your PM" (from profile.bashrc) ... Just want to show that using 'eapi-function' should be more flexible than 'EAPI-variable', and thus will not be subject to change too often and require 2) (see above). /haubi/ -- Michael Haubenwallner Gentoo on a different level -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Wulf C. Krueger wrote: > a> "So we can make use of this feature in about a year?" > b> "Yeah." > > Are we Debian now? A new feature gets implemented (obviously because we > *need* it) and we can make use of it in a *year*? What do we need so desperately? > >> So either choose the one that's accepted by the majority > > The majority of devs doesn't even read here (not to speak of active > participation). That says a lot in itself... lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Project Update: qt-4
On Thu, 2007-12-20 at 09:37 -0500, Caleb Tennis wrote: > > How about splitting qmake out to help with the WebKitGtk stuff, so we > > don't have to dep on qt? > > In theory it can be done very easily, because qmake doesn't rely on any Qt > libraries. However, it DOES rely on all sorts of .prf and configure time > option > files that are installed to the file system. But I'm hoping to get a very > minimal > package together that will mitigate the need for a big Qt install for builing > WebKitGtk, yes. > > Caleb > Cool, thanks for the information :). -- Patrick Ohearn Email: [EMAIL PROTECTED] XMMP: [EMAIL PROTECTED] -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Project Update: qt-4
> How about splitting qmake out to help with the WebKitGtk stuff, so we > don't have to dep on qt? In theory it can be done very easily, because qmake doesn't rely on any Qt libraries. However, it DOES rely on all sorts of .prf and configure time option files that are installed to the file system. But I'm hoping to get a very minimal package together that will mitigate the need for a big Qt install for builing WebKitGtk, yes. Caleb -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Project Update: qt-4
> Great news. Why don't you split everything, though? In qt-4.3.0-r2, I > see Core, Gui, Network, OpenGL, Sql, Script, Svg, Xml, Designer, > UiTools, Assistant, 3Support, Test and DBus and can certainly imagine > that at least putting the Gui out would make sense for console-based Qt > applications. I'm definitely considering this. At the very least I'd like to make a qt-core package with all of the non-GUI stuff in it, then have a gui package that has everything else. It's a work in progress, but I'm hoping we can get it to this kind of thing soon. Caleb -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Project Update: qt-4
On Thu, 2007-12-20 at 09:05 -0500, Caleb Tennis wrote: > Just a quick update on the happens in the x11-libs/qt world, as I'm > introducing some > changes that will probably affect people in the not-to-distant future. > > Since Qt is starting to get rather, ahem, big, I've decided that with the > introduction of version 4.4 it's a good time to try and split it down into > more > manageable chunks. I'm introducing a few new packages that are designed to > break > out some of the major pieces into their own packages. I present: > > x11-libs/qt > x11-libs/qt-dbus ( Breaking out into its own package ) > x11-libs/qt-phonon ( New for 4.4, a wrapper around various sound modules ) > x11-libs/qt-qt3support ( Breaking out into its own package ) > x11-libs/qt-webkit ( New for 4.4, Qt's integrated WebKit support ) > > There may be some more of these as time goes on and necessity/desire dictate. > > The main motivation behind doing this is to make the package a little more > manageable, in that it's not one huge monolithic package with a million use > flags > dictating which modules get built. This should make dependant package > maintenance > nicer, as you can just depend on the necessary packages and not have to > resort to > the built_with_use trickery that we all love so much. > > As well, we gain in the same vein as the split KDE style packages, that > updates and > security fixes don't require a recompilation of all of the non-affected > modules. > > There are still lots of goodies that need to be tested. I'm sure there are > edge-case USE flag scenarios that may need to be accounted for, performance > tweaks > to be made, and other things I haven't thought of. If you're into bleeding > edge, > I'd love to have you try out some of these new packages and see if you've got > any > failures or ideas for making them better. > > As usual, this stuff is all package.masked right now pending lots of tweaks > and > changes in the short term. My guess is that it will hit portage proper by > the end > of 1Q2008. Hopefully we can have it all happy by then. > > Feel free to file any bug reports you can find or think of. Patches are > especially > encouraged. > > Thanks, > Caleb > How about splitting qmake out to help with the WebKitGtk stuff, so we don't have to dep on qt? Or can't this be done as easy as the other parts? -- Patrick Ohearn Email: [EMAIL PROTECTED] XMMP: [EMAIL PROTECTED] -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Project Update: qt-4
Caleb Tennis wrote: > Since Qt is starting to get rather, ahem, big, I've decided that with the > introduction of version 4.4 it's a good time to try and split it down into > more > manageable chunks. I'm introducing a few new packages that are designed to > break > out some of the major pieces into their own packages. I present: > > x11-libs/qt > x11-libs/qt-dbus ( Breaking out into its own package ) > x11-libs/qt-phonon ( New for 4.4, a wrapper around various sound modules ) > x11-libs/qt-qt3support ( Breaking out into its own package ) > x11-libs/qt-webkit ( New for 4.4, Qt's integrated WebKit support ) Great news. Why don't you split everything, though? In qt-4.3.0-r2, I see Core, Gui, Network, OpenGL, Sql, Script, Svg, Xml, Designer, UiTools, Assistant, 3Support, Test and DBus and can certainly imagine that at least putting the Gui out would make sense for console-based Qt applications. Cheers, -jkt -- cd /local/pub && more beer > /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Ciaran McCreesh wrote: > Because that would be introducing a new, non-extensible, inflexible > requirement upon the content of ebuilds, and the goal of EAPI is to > avoid doing exactly that. > If you're putting all this metadata in the filename, I'm not sure how you can distinguish between the filename and the content regarding flexibility. If anything I'd rather have more flexibility in filenames and less in content. For example, cat/pkgname/version could be a whole lot more flexible if they were just a string and didn't have to be parsed out of the concatenated fields in the filename. Mind you, I'm not proposing this, but it seems like putting yet another concatenated field in the filename is only going to make the filenames that much more complicated. Unless you're going to make ebuilds semi-machine-built objects like xml files it is going to be hard to make them completely flexible without having package managers with a bazillion cases in them for parsing the files. That will naturally limit support for lots of EAPIs. I do agree with your goals - it just seems like there HAS to be a better way of doing it than putting something at the end of the filename. smime.p7s Description: S/MIME Cryptographic Signature
[gentoo-dev] Project Update: qt-4
Just a quick update on the happens in the x11-libs/qt world, as I'm introducing some changes that will probably affect people in the not-to-distant future. Since Qt is starting to get rather, ahem, big, I've decided that with the introduction of version 4.4 it's a good time to try and split it down into more manageable chunks. I'm introducing a few new packages that are designed to break out some of the major pieces into their own packages. I present: x11-libs/qt x11-libs/qt-dbus ( Breaking out into its own package ) x11-libs/qt-phonon ( New for 4.4, a wrapper around various sound modules ) x11-libs/qt-qt3support ( Breaking out into its own package ) x11-libs/qt-webkit ( New for 4.4, Qt's integrated WebKit support ) There may be some more of these as time goes on and necessity/desire dictate. The main motivation behind doing this is to make the package a little more manageable, in that it's not one huge monolithic package with a million use flags dictating which modules get built. This should make dependant package maintenance nicer, as you can just depend on the necessary packages and not have to resort to the built_with_use trickery that we all love so much. As well, we gain in the same vein as the split KDE style packages, that updates and security fixes don't require a recompilation of all of the non-affected modules. There are still lots of goodies that need to be tested. I'm sure there are edge-case USE flag scenarios that may need to be accounted for, performance tweaks to be made, and other things I haven't thought of. If you're into bleeding edge, I'd love to have you try out some of these new packages and see if you've got any failures or ideas for making them better. As usual, this stuff is all package.masked right now pending lots of tweaks and changes in the short term. My guess is that it will hit portage proper by the end of 1Q2008. Hopefully we can have it all happy by then. Feel free to file any bug reports you can find or think of. Patches are especially encouraged. Thanks, Caleb -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Ciaran McCreesh wrote: > Because a) a future EAPI might want to change EAPI into a function > rather than a variable, Why? It couldn't be dynamic - not if you're going to put it in the filename as well. And why have it in two places? If you are going to put the EAPI in the filename, why put it inside the ebuild as well? We don't do that with version numbers or package names. > b) there are a zillion ways of setting a > variable in bash and people already use all of them and c) introducing > new weird format requirements is silly. But this GLEP is already proposing a format requirement. It is just putting it in the filename instead of in the ebuild contents. It isn't like you could just put anything in the filename anywhere you want and the package manager will be able to understand it. If devs are going to have to get correct "-1" at the end of the filename, why couldn't they also get right "EAPI=1" inside the file? smime.p7s Description: S/MIME Cryptographic Signature
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Dec 20, 2007 12:12 PM, Ciaran McCreesh <[EMAIL PROTECTED]> wrote: > I'm guessing there're lots of people moaning because they think they > understand filenames and can therefore comment. Unfortunately, most of > those people don't understand the metadata generation process, and > therefore can't comment usefully... Stop guessing, then. You're way off. You apparently do not understand that an assertion without justification has no value in a serious discussion. Even it that has already been explained somewhere else, it may have been interpreted differently by different people (assuming they can find it). And sorry to disappoint you but you're not alway right. You have to give people a chance to contradict you, for your own good. Also, please stop thinking people have the exact same thing in mind as you because that leads to misunderstandings. All of us being different and thinking differently is why we are this good. There's nothing you can do about this, it's human nature. The day you'll understand all of this you'll be a much better dev and human being in general. And this day, working with you will be lots of fun. Too bad you were late when the specification for Man was written, because it seems we would have been much better than we are, and it would have been easier for you now. Denis. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Donnie Berkholz wrote: > Here's some other ideas for how to express EAPI. What if we: If this idea of eapi is the best. I'm doubtful it is. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Re: Re: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Thu, Dec 20, 2007 at 02:12:24PM +0100, Bo Ørsted Andresen wrote: > On Thursday 20 December 2007 13:48:31 Steve Long wrote: > > >> (optimising early here seems silly tbh, given that paludis now > > >> requires ruby.) > > > > > > Eh? Now what're you on about? > > > > http://bugs.gentoo.org/show_bug.cgi?id=198864 > > So here you're showing that you don't know what a USE flag is? It is good he made it crystal clear though. Nobody has to 'guess' now. - ferdy -- Fernando J. Pereda Garcimartín 20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4 pgpgzm13Sp0xr.pgp Description: PGP signature
Re: [gentoo-dev] Re: Re: Re: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Thursday 20 December 2007 13:48:31 Steve Long wrote: > >> (optimising early here seems silly tbh, given that paludis now > >> requires ruby.) > > > > Eh? Now what're you on about? > > http://bugs.gentoo.org/show_bug.cgi?id=198864 So here you're showing that you don't know what a USE flag is? -- Bo Andresen signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On 2007/12/20, Ciaran McCreesh <[EMAIL PROTECTED]> wrote: > Uh, it works in both those cases. The package manager will simply not > see the ebuild at all. > > Which is pretty much the point... Yes, because a change in the way EAPI is read implies a change in the files naming rule, so that the PM recognize the file only if it can do something useful with it. That's true for both proposals, which was pretty much my point. And that thus, it was not an argument in favor of one against the other. I still think that changing file names when absolutly required (switching from "EAPI=foo" to "eapi foo", or moving it elsewhere, or switching to xml, etc.) is less disturbing than changing it for every single new EAPI. It's not because one new extension may not be eternally enough that we should introduce an infinity right now. But yeah, to be honest, you're right that my original "as long as ebuilds stay bash" was a bit optimistic: it was assuming there would be no decision of changing that rule as long as there would be no good reason for it (like a switch to xml or whatever other not-bash format). -- TGL. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Re: Re: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Dec 20, 2007 12:48 PM, Steve Long <[EMAIL PROTECTED]> wrote: > Ciaran McCreesh wrote: > > On Thu, 20 Dec 2007 00:07:35 + > > Steve Long <[EMAIL PROTECTED]> wrote: > >> (optimising early here seems silly tbh, given that paludis now > >> requires ruby.) > > > > Eh? Now what're you on about? > > > http://bugs.gentoo.org/show_bug.cgi?id=198864 Correct, paludis uses dev-ruby/syntax to highlight its ruby examples. When it's building. We thought it was worth the performance hit, apparently we were wrong. /me hangs head in shame, searches for a syntax highlighter written in cross-platform assembly. -- Richard Brown -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
I DO understand. You don't. The complete paragraph of yours shows you don't. But you're totally ignoring my point. So once again: You're trying to *SET* a standard here. There are lots of people telling you that they're not happy with the proposal to change the ebuild filename suffix. Yes, indeed. They're not happy with it. That's about all most participants here have stated so far. There are two or three valid *technical* concerns and all the rest is basically noise. There seem to be less people opposed to having that ebuild format restriction. If this was only about the ebuild format restriction, I wouldn't even bother to write a single mail on this subject. It's much more important than that - the suggested GLEP would allow us to make use of new EAPI features much earlier than now and without causing major problems, I think. Just this morning when I was reading my backlog in #-dev, I saw a discussion between between two devs that culminated in the following: a> "So we can make use of this feature in about a year?" b> "Yeah." Are we Debian now? A new feature gets implemented (obviously because we *need* it) and we can make use of it in a *year*? So either choose the one that's accepted by the majority The majority of devs doesn't even read here (not to speak of active participation). -- Best regards, Wulf pgpZtv993UOWc.pgp Description: PGP Digital Signature
Re: [gentoo-dev] [GLEP] Use EAPI inside ebuild filename (.EAPI-ebuild of different?)
While it's may be a good idea to set EAPI inside filename and if we ever
decide on this, consider different implementation.
I really dislike idea of EAPI-suffixed extensions. It's easier for me
(and I think for others too) to differentiate ebuilds between other
files in directory when ebuild files have common suffix. We are people
so we should simplify things that are not hidden under the hood, like
this...
This hack is just to solve portage problem which does not ignore .ebuild
files which does not follow pkg-ver.ebuild syntax and suggested solution
is not the only solution. Other possibilities are, which I like more:
1. USE pkg-ver.-ebuild
2. USE pkg-ver${EAPITAG}.ebuild
Here ${EAPITAG} is string to simplify parsing from
version. E.g. EAPITAG could be _eapi or EAPI or something
else.
Although second solution does not solve the problem with portage I like
it more, as we all have habit to look at .ebuild suffix. But this is
different problem. Once we define good NEW format for filename it's
possible to decide on transition path which allows us to use eapi right
now. E.g. start using this format only with .ebuild-ng suffix and after
three years pass it's possible to rename all .ebuild-ng into .ebuild.
And another idea which was already mentioned somewhere in this thread. I
think .ebuild should be written only in BASH. Again if we ever decide to
use ebuilds with different syntax we should use different suffix.
--
Peter.
signature.asc
Description: Эта часть сообщения подписана цифровой подписью
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Extended attributes can be turned off during compile time for each filesystem you mentioned. If you turn off features you need, things break. There's nothing new about that. If you disable ext3 support in your kernel, you can't mount an ext3 partition and you'll get an error during boot about not finding the root. What you're proposing, though, is *requiring* a feature most people don't even know about or use. Yes, if I want to boot from ext3, I'll need support for it in the kernel. That's a very fundamental assumption and one that even our most "challenged" users will understand. Requiring extended attributes for the Portage tree is something completely different. There's simply no need to require additional features for something that can be done in the filename. Is there any *technical* reason you object to the GLEP? Because your aesthetic sense may be commendable but I for one find the suggestion *beautifully* simple. :-) Of course, taste can't be argued about (obviously I have an excellent taste and you don't! ;-) ) so I'd be really curious if there are technical reasons. It wouldn't be great to require extended attributes for each and every Gentoo box... Why not? Because we shouldn't require stuff we don't *have* to. -- Best regards, Wulf pgpuUbIFjtifc.pgp Description: PGP Digital Signature
[gentoo-dev] Re: Re: Re: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Ciaran McCreesh wrote: > On Thu, 20 Dec 2007 00:07:35 + > Steve Long <[EMAIL PROTECTED]> wrote: >> Do you think a generated EAPI is a good idea? I'm curious as to >> how that would be reflected in the filename (as well as your reasons >> ofc.) > > I'm suggesting that if EAPI is a variable, there are use cases for being > able to set the variable in ways other than right at the top of the > ebuild. If it isn't a variable then those use cases aren't relevant. > Point is that your filename format restricts it in exactly the same manner. So let's just stick with the use cases which /that/ supports, which can more easily be supported with the original design and the simple restriction people keep asking for. >> No: without knowing the EAPI when generating said data. If that needs >> to be known relatively soon in order to generate the rest, extract it >> early. You still only need to load the file from disk once, and you >> don't need to source to get that data, given one simple restriction >> (only declaring it once.) > > You can't get the EAPI from the ebuild without knowing what EAPI the > ebuild uses. That's one of the points you're missing. > Wow that doesn't half sound like nonsense. On the one hand you want a restricted filename suffix, on the other it *has* to be full bash parsing. An EAPI="blah" at top-level in the file is exactly the same as the suffix in terms of what can be represented (actually more capable: it also enables eg prefix EAPIs which I understand was one of the main motivations to extend the format away from a defined ordering.) If the EAPI introduces a further eapi function, all well and good; the same datum is still required, whether kept in the filename or in the ebuild. According to the original discussion this was always supposed to be a variable set in the ebuild source: "We would like to introduce a new ebuild variable named EBUILD_FORMAT, that tags the ebuild with a specific ebuild API version it provides or uses."[1] At that time others made the case for restricting its format in exactly the same way you have been resisting for the ebuild source, but see as fine for tacking onto the end of the filename: "I would also suggest requiring that EAPI can be retrieved by a simple line by line parsing without using bash. (This allows for changing the parsing system)"[2] The idea of a different suffix was discussed back then as well: "portage *should not* ignore those ebuilds. If the user wants to merge something that is a later ebuild api then they have, at least portage chucks an exception that the UI can wrap into 'upgrade portage'. With what you're proposing, we instead get bugs about portage missing packages."[3] (That was written when there were no other PMs besides portage3/pkgcore) http://www.mail-archive.com/gentoo-dev%40lists.gentoo.org/msg03946.html has a fuller discussion. > It's an ebuild issue, not a package manager issue. > You keep saying that; sure EAPI is visible to ebuild and maintainer (doh) but the reason you have stated for this change in file naming (which is a lot more far-reaching than a simple restriction on the format of a variable) is so that the *PM* doesn't have to source the ebuild to get the EAPI. Several people have independently suggested the same solution that would work fine in the existing framework, which was in fact proposed in 2005: "Mainly, limiting the syntax has the undesired affect of deviating from what users/devs know already; mistakes *will* occur. QA tools can be written, but people are fallable; both in writing a QA tool, and abiding by the syntax subset allowed."[3] I don't think those are really an issue nowadays; devs know to run repoman, and so do sunrise submitters. I haven't seen one lucid explanation from you for why it wouldn't work, beyond ramblings about requiring full bash sourcing capability for what you yourself envisage as being a static variable, fixed per file. >> I accept it would make metadata generation quicker, but the >> end-user can already use -metadata-transfer atm and never need to run >> that process. It would save many more cycles if more users did imo > > You're confusing the two different types of metadata. Which again shows > that you need to start understanding the metadata process before trying > to discuss design decisions relating to it... > It doesn't make any practical difference[4]: the computational issue is how to avoid a source statement via bash from another language. I note in passing that a metadata cache is available, with no runtime requirement on the user's part, since it is taken from the rsync'ed data. >> (optimising early here seems silly tbh, given that paludis now >> requires ruby.) > > Eh? Now what're you on about? > http://bugs.gentoo.org/show_bug.cgi?id=198864 >> Given that, as a user I see no benefit to my machines that would >> justify the maintenance headache which I know as a coder this will >> result in. > > There is no maintenance headache. > Ye
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Thu, 20 Dec 2007 12:06:59 +0100 Thomas Pani <[EMAIL PROTECTED]> wrote: > But you're totally ignoring my point. So once again: You're trying to > *SET* a standard here. There are lots of people telling you that > they're not happy with the proposal to change the ebuild filename > suffix. There seem to be less people opposed to having that ebuild > format restriction. So either choose the one that's accepted by the > majority (and I'm not saying that EAPI=xxx is the one; I'm saying > that we'll have to figure that out), or think of something completely > new. The ebuild format restriction does not solve the problem at hand. I'm guessing there're lots of people moaning because they think they understand filenames and can therefore comment. Unfortunately, most of those people don't understand the metadata generation process, and therefore can't comment usefully... -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Ciaran McCreesh wrote: > On Thu, 20 Dec 2007 11:37:01 +0100 > Thomas Pani <[EMAIL PROTECTED]> wrote: >> As cat/pkg-ver ultimately is ONE file in the filesystem, there's no >> reason to put any information about the EAPI in the filename. > > Sure there is. It's the sanest place to put it such that it's available > when it's needed -- that is, before the ebuild is sourced. > >> I still don't get why EAPI=xxx is s bad. Obviously the GLEP (and >> the last 500 comments lack to explain that. Ebuilds are bash. >> EAPI=xxx is bash syntax. > > Uh, I've explained it far too many times in this thread already. Go > back and read. Don't post again until you understand it. > I DO understand. You say that explicitly having EAPI=xxx in the first non-comment line / in the ebuild header / whereever imposes restrictions on the ebuild format itself that go beyond "it has to be bash". That's right. But you're totally ignoring my point. So once again: You're trying to *SET* a standard here. There are lots of people telling you that they're not happy with the proposal to change the ebuild filename suffix. There seem to be less people opposed to having that ebuild format restriction. So either choose the one that's accepted by the majority (and I'm not saying that EAPI=xxx is the one; I'm saying that we'll have to figure that out), or think of something completely new. Thomas Pani -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Thu, 20 Dec 2007 11:37:01 +0100 Thomas Pani <[EMAIL PROTECTED]> wrote: > As cat/pkg-ver ultimately is ONE file in the filesystem, there's no > reason to put any information about the EAPI in the filename. Sure there is. It's the sanest place to put it such that it's available when it's needed -- that is, before the ebuild is sourced. > I still don't get why EAPI=xxx is s bad. Obviously the GLEP (and > the last 500 comments lack to explain that. Ebuilds are bash. > EAPI=xxx is bash syntax. Uh, I've explained it far too many times in this thread already. Go back and read. Don't post again until you understand it. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Here's why I think you can't -- or at least shouldn't -- put EAPI into the filename. >From your EAPI definition: > A cat/pkg-ver has exactly one EAPI. That EAPI belongs to the > cat/pkg-ver as a whole, and is static across that cat/pkg-ver. It's clearly NOT the purpose of a filename to describe how the contents of a file are structured/formatted/encoded/etc. It's sole purpose is to uniquely identify a file. Example: I use .txt to identify my text documents. However, I don't use .txt-utf-8, .txt-latin-1, .txt-iso-8859-15 just because their encoding differs. As cat/pkg-ver ultimately is ONE file in the filesystem, there's no reason to put any information about the EAPI in the filename. I still don't get why EAPI=xxx is s bad. Obviously the GLEP (and the last 500 comments lack to explain that. Ebuilds are bash. EAPI=xxx is bash syntax. If you just don't like EAPI being defined as variable (because future EAPIs could define that EAPI is assigned via a function), there are other ways to put this into the ebuild. Eg. Python PEP 0263 ([1]) proposes a way to declare the encoding inside of the source file. Same could be done for the EAPI. Or just write a GLEP that states EAPI has to be assigned via the EAPI variable. You're trying to *set* a standard here, so act accordingly. thomas [1] http://www.python.org/dev/peps/pep-0263/ -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Donnie Berkholz wrote: > If you turn off features you need, things break. There's nothing new > about that. If you disable ext3 support in your kernel, you can't mount > an ext3 partition and you'll get an error during boot about not finding > the root. I see your point, but extended attributes aren't as common as ext3, are they. And stuff that got broken because Portage suddenly started to require new features on the kernel side is bad. > The idea of the sqlite-based fallback is what's interesting here. If it is a fallback that must be supported (because of NFS), then there isn't much point in using xattrs. What benefits do they provide? There's no speed constraint here as we already cache metadata somewhere. >> Also note that in some circumstances like when running in a >> virtualized environment, imposing additional requirements on the kernel >> might be problematic. > > Why's that? Things with Xen got better than they were, but I can imagine a situation where some hosting provider offers their customers a virtual Xen box and their kernel configuration doesn't include extended attributes. You can't use your own kernel without access to dom0. >> It wouldn't be great to require extended attributes for each and every >> Gentoo box... > > Why not? Because they aren't so common, NFS doesn't support them and we haven't ever required them. Cheers, -jkt -- cd /local/pub && more beer > /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: New eclass osgi.eclass
Hello all, I have a new version of the eclass ready, with much of the remarks addressed. It now goes by the name java-osgi and in the new form, should be ready to enter the tree. I fixed the performance problem I mentionned earlier, cleaned up the eclass API, and simplified the code almost everywhere. Waiting for your feedback. Cheers Elvanör java-osgi.eclass Description: Binary data
