Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Ciaran McCreesh wrote: > On Fri, 21 Dec 2007 10:59:14 +0800 > Zhang Le <[EMAIL PROTECTED]> wrote: >> 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. > And you are trying to set an even higher barrier for people to reach that level. How many power users or devs do actually care/know what EAPI=1 means? Regards, thomas -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Ciaran McCreesh wrote: > 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... Well putting the eapi per tree/repo and provide a way to fetch directly the tree a package manager can understand sounds pretty much a simpler alternative. Add that basically much of the discussion is founded on uncertain basis since there isn't a document about what exactly eapi is supposed to be, nor other details that you considered compulsory to get a clue about what's being discussed, so there isn't quite a way to say what's good and what isn't beside polling who is hacking package managers about alternatives and have an idea of what the dev base likes better if there are equivalent solutions. and NO there isn't a compelling reason to do anything _real_soon_ 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 10:58:15 +0100 Thomas Pani <[EMAIL PROTECTED]> wrote: > Ciaran McCreesh wrote: > > On Fri, 21 Dec 2007 10:59:14 +0800 > > Zhang Le <[EMAIL PROTECTED]> wrote: > >> 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. > > > And you are trying to set an even higher barrier for people to reach > that level. How many power users or devs do actually care/know what > EAPI=1 means? Developers have to know about EAPIs. It's part of knowing how to write ebuilds. There's no way around that -- if you're writing ebuilds, you have to know what you are and aren't allowed to do in those ebuilds. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Fri, 21 Dec 2007 11:18:53 +0100 Luca Barbato <[EMAIL PROTECTED]> wrote: > Well putting the eapi per tree/repo and provide a way to fetch > directly the tree a package manager can understand sounds pretty much > a simpler alternative. And it defeats the whole point of having EAPI at all. > Add that basically much of the discussion is founded on uncertain > basis since there isn't a document about what exactly eapi is > supposed to be, nor other details that you considered compulsory to > get a clue about what's being discussed, so there isn't quite a way > to say what's good and what isn't beside polling who is hacking > package managers about alternatives and have an idea of what the dev > base likes better if there are equivalent solutions. Then don't say anything. Leave the discussion to those who know what the whole thing is about. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Friday 21 December 2007 08:43:43 Richard Freeman wrote: > Ciaran McCreesh wrote: > > Please don't comment any further until you understand how this whole > > thing works. > CON: > Yet another value to be parsed out of an increasingly-complex filename. > Doesn't look pretty :) Taste is a matter of opinion. I happen to like eapi-1 in the filename so I know a bit about the ebuild before looking through its contents. > Makes a low-level detail more visible to users. > You can't make a wild change to how EAPIs are specified - since old PMs > will expect it to be in the filename in a particular format. This isn't a CON, it is actually a PRO because old PMs won't recognize the new format and everyone will be happy. (something not so easy with the other solutions.) -- 2.6.23-gentoo-r3 signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Ciaran McCreesh a écrit : > Developers have to know about EAPIs. It's part of knowing how to write > ebuilds. There's no way around that -- if you're writing ebuilds, you > have to know what you are and aren't allowed to do in those ebuilds. Then please try to keep things simple :) The majority of devs don't want to know how portage or paludis work internally, that's not what interests most of us. On a somewhat related note : I noticed that among the massive thread, you have brought up several times the issue of cache generation, saying that it was a complicated process. Maybe this process needs to be reworked before the whole EAPI issue can be resolved? Cheers, Rémi -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in x11-libs/qt-opengl: qt-opengl-4.4.0_rc1.ebuild metadata.xml ChangeLog Manifest
> Did you autogenerate these ebuilds? It looks like the deps were pulled > out of a conditional in the original qt. They were pulled out, but they weren't autogenerated. It's all still a work in progress. > I've seen this in all of the split qt ebuilds. Should it go in the eclass? Yep, going to work on an eclass today. > Why do you need to do this again? It should've been saved from the last > phase. This is a remnant from an earlier version with an earlier portage. It's probably safe now not to have. > The postrm comment doesn't match the action. Will fix. Many thanks. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Thu, 2007-12-20 at 17:22 +0100, Luca Barbato wrote:
> I'm thinking about having them embedded in the comment as first line as
> something like
>
> #!/usr/bin/env emerge --eapi $foo
OT: It actually works adding this first line and do chmod +x foo.ebuild:
#! /usr/bin/env ebuild
Then you can do: ./foo.ebuild {digest,install,merge,whatever}
/haubi/
--
Michael Haubenwallner
Gentoo on a different level
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Re: Re: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Ciaran McCreesh wrote: > 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. > How is having a line that states EAPI=foo in the ebuild any less trivial than putting a -foo at the end of the filename? If anything the latter is more typing - since the EAPI=foo line would probably be in skel.ebuild... smime.p7s Description: S/MIME Cryptographic Signature
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Fri, 21 Dec 2007 14:29:25 +0100 Rémi Cardona <[EMAIL PROTECTED]> wrote: > Ciaran McCreesh a écrit : > > Developers have to know about EAPIs. It's part of knowing how to > > write ebuilds. There's no way around that -- if you're writing > > ebuilds, you have to know what you are and aren't allowed to do in > > those ebuilds. > > Then please try to keep things simple :) *Using* EAPIs is simple. *Designing* them, not so much. > The majority of devs don't want to know how portage or paludis work > internally, that's not what interests most of us. Which is fine. But then, the majority of devs shouldn't expect to be able to provide opinions when it comes to the more technical aspects. > On a somewhat related note : I noticed that among the massive thread, > you have brought up several times the issue of cache generation, > saying that it was a complicated process. > > Maybe this process needs to be reworked before the whole EAPI issue > can be resolved? That's partly what the GLEP is doing. Making it any simpler, unfortunately, would involve either a huuge performance hit (we're talking two orders of magnitude here) or removing metadata from the ebuilds entirely -- neither of which are viable solutions. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Thursday 20 of December 2007 19:29:22 Zhang Le wrote: > So please make those people understand, so they can comment usefully. Are we in the elementary school or something? This is really getting ridiculous. -- Best Regards, Piotr Jaroszyński -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Ciaran McCreesh wrote: > Please don't comment any further until you understand how this whole > thing works. > I think this is a bit of an unrealistic expectation. This change impacts EVERYBODY - devs, users, etc. To expect people not to comment on it simply because they're not qualified to write a package manager is a bit naive. Like it or not you do need to obtain some kind of general agreement before making a change of this magnitude. Even so - I'm impressed about how civil this discussion has actually remained. Feel free to continue to make your points, but a GLEP requires some kind of census - not just silence after everybody gets tired of hitting reply. If somebody doesn't know what they're talking about - persuade them - don't just tell them to be quiet. I usually like to look at stuff like this in terms of pros and cons. So here are the pros and cons I can see regarding this change: PRO: Very simple to determine the EAPI of an ebuild - regardless of what is inside Works with existing PMs Simple CON: Yet another value to be parsed out of an increasingly-complex filename. Doesn't look pretty :) Makes a low-level detail more visible to users. You can't make a wild change to how EAPIs are specified - since old PMs will expect it to be in the filename in a particular format. The other option that seems popular is just continuing with EAPI=1 or whatever in the file (likely with a restriction on format that makes it parsable without BASH). I see these pros/cons for this solution: PRO: Very simple to determine the EAPI of an ebuild - regardless of what is inside Works with existing PMs Simple Doesn't add another field to the filename - reducing complexity Not very visible to users Looks pretty :) CON: You can't make a wild change to how EAPIs are specified - since old PMs will expect it to be inside the file in a particular format. I don't see how the latter is any worse than the former - its main limitation applies to both methods - just in a different place. I think you'd get far more consensus to the latter approach. And if for whatever reason this fails way down the road it could always be moved to the filename at that time. smime.p7s Description: S/MIME Cryptographic Signature
Re: [gentoo-dev] Re: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Fri, 21 Dec 2007 08:29:34 -0500 Richard Freeman <[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" > > > > Counterexample. How do you determine the eapi for the following file, > which uses an EAPI that is yet unpublished - but which specifies that > the EAPI NOT go in the filename: foo-1.2.ebuild You're back to using a pre-source EAPI to extract the real EAPI then, which is the way things are currently -- and it means that any EAPI that specifies what you describe has to be sufficiently close to EAPI 0 that package managers that only understand EAPI 0 will work with it. > Making a decision to put the EAPI in the filename for all time doesn't > seem any less restricting than making a decision to put EAPI=1 or > EAPI="1" in the ebuild for all time. And the latter is a whole lot > less messy as far as I can see. It's an awful lot less restrictive. > So far the only objection I've seen to putting EAPI in the ebuild is > that at some point in the future we might want to do it differently. > Well, that is nice, but the same issue would apply to putting it in > the filename - we could want to change that someday too. And if we > put it in the filename why would we want to put it in a function or > whatever inside the ebuild as well? Wouldn't that just be redundant. If the GLEP is followed, you *can* change the filename to absolutely anything that isn't either *.ebuild or *.ebuild-(any-previous-eapi), or various silly things like metadata.xml and files. > And if the whole point of this is to allow massive changes to ebuild > format - why not wait until a need for such a change exists before > instituting it. Why not defer this GLEP until it has some benefit and > not just pain associated with it? There is plenty of need, as you would know had you either read the GLEP or paid attention on this list recently. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Friday 21 December 2007 05:25:00 Zhang Le wrote: > The question is really simple. > Whether we should have two different place to define EAPI? We need two places because it wasn't implemented properly in the first place and we want to retain backwards compatibility for people who use old versions of portage. The whole point is to keep a sane upgrade path available indefinitely for people with old versions of portage. > Proponents are trying to prove that we should at least need it be in file > name. We need the file name to change because otherwise old versions of portage will try to source the ebuild when the EAPI is unknown. This either blocks new useful features that will make old versions of portage fail to source them or results in more bug reports with zillions of dupes (like the bugs in [1]) because people with ancient versions of portage feel the need to report bug reports when portage fails after a sync. At the very least it means waiting for a year between a release with a version of portage that supports this and an EAPI that takes advantage of it. So now that leaves the question whether we want to change the file name once and hope that we won't need to do it again or whether we want to use the technically more flexible way where the file name changes whenever a new EAPI gets agreed upon. Or alternatively whether we want to limit ourselves by using an inferior solution that limits or delays progress considerably and results in more bug reports with zillions of dupes... [1] http://www.gentoo.org/proj/en/portage/doc/common-problems.xml -- Bo Andresen signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Thursday 20 December 2007 17:14:52 Thomas Pani wrote: > > 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] It has changed as long as you don't introduce features that makes old versions of portage fail to source the ebuild. EAPI=1 didn't do that. -- Bo Andresen signature.asc Description: This is a digitally signed message part.
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" > Counterexample. How do you determine the eapi for the following file, which uses an EAPI that is yet unpublished - but which specifies that the EAPI NOT go in the filename: foo-1.2.ebuild Obviously if you go down one road, and then intentionally change things to go down another then old stuff won't work. Any package manager that depends on having the EAPI in the filename won't work if a decision is later made to remove the EAPI from the filename. Making a decision to put the EAPI in the filename for all time doesn't seem any less restricting than making a decision to put EAPI=1 or EAPI="1" in the ebuild for all time. And the latter is a whole lot less messy as far as I can see. So far the only objection I've seen to putting EAPI in the ebuild is that at some point in the future we might want to do it differently. Well, that is nice, but the same issue would apply to putting it in the filename - we could want to change that someday too. And if we put it in the filename why would we want to put it in a function or whatever inside the ebuild as well? Wouldn't that just be redundant. Sure, by not putting it in the filename we restrict ourselves a little from changing things later. However, if we do put in the filename we seem to already have a mass of folks who would want to change it RIGHT NOW. And if the whole point of this is to allow massive changes to ebuild format - why not wait until a need for such a change exists before instituting it. Why not defer this GLEP until it has some benefit and not just pain associated with it? smime.p7s Description: S/MIME Cryptographic Signature
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Fri, 21 Dec 2007 08:43:43 -0500 Richard Freeman <[EMAIL PROTECTED]> wrote: > Ciaran McCreesh wrote: > > Please don't comment any further until you understand how this whole > > thing works. > > I think this is a bit of an unrealistic expectation. This change > impacts EVERYBODY - devs, users, etc. To expect people not to comment > on it simply because they're not qualified to write a package manager > is a bit naive. Like it or not you do need to obtain some kind of > general agreement before making a change of this magnitude. What. It's a small change that's only visible to developers and power users. > CON: > Yet another value to be parsed out of an increasingly-complex > filename. Doesn't look pretty :) It'd only increase complexity in any meaningful way if it were part of the version part of the ebuild. The version part *is* getting pretty tricky to parse correctly. > Makes a low-level detail more visible to users. Users don't see .ebuild files. > You can't make a wild change to how EAPIs are specified - since old > PMs will expect it to be in the filename in a particular format. You can make entirely arbitrary changes to EAPIs with suffixes, provided only that you don't use either .ebuild or .ebuild-(any-existing-eapi). > The other option that seems popular is just continuing with EAPI=1 or > whatever in the file (likely with a restriction on format that makes > it parsable without BASH). I see these pros/cons for this solution: > > CON: > You can't make a wild change to how EAPIs are specified - since old > PMs will expect it to be inside the file in a particular format. Bigger con: it means no non-trivial new EAPIs for a year or more. Another con: EAPI=foo or EAPI="foo" or export EAPI="foo" or what? > I think you'd get far more consensus to the latter approach. Yes, but the latter problem doesn't solve anything, so it doesn't really matter whether or not people like it -- it's utterly pointless. Counting pros and cons is a bad idea -- a single con can make an idea completely worthless, whilst ten trivial "it doesn't look quite as pretty cons" are largely meaningless. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Friday 21 December 2007 03:41:04 Luca Barbato wrote: > > * 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. And then we have to wait till noone use a version of portage that sources the ebuild to get the EAPI. Unless we change the file name.. -- Bo Andresen signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Friday 21 December 2007 05:46:35 Josh Saddler wrote: > 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. GLEP means Gentoo Linux Enhancement Proposal. It was proposed to enhance Gentoo... Paludis already supports this kind of thing for usage outside gentoo-x86. That has no relevance to Gentoo unless the GLEP gets approved... -- Bo Andresen signature.asc Description: This is a digitally signed message part.
Re: EAPI definition Was: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Thursday 20 December 2007 20:01:55 Zhang Le wrote: > IMO, we can not have more than two EAPI's simultaneously. That defeats the whole purpose of having EAPIs. Which is to keep a sane upgrade path... -- Bo Andresen signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Thursday 20 December 2007 22:33:25 Joe Peterson wrote: > Technical reasons to avoid the filename are: > > 2) Having the same info in more than one place is bad (requiring extra > repoman checks and the potential for ambiguity). As opposed to adding checks to make sure that obtaining the EAPI from the contents of the file doesn't require bash? > 3) It uses the extension in a way that goes against common use in computers. What? It uses the extension to determine the format of the contents? -- Bo Andresen signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [RFC] Some new global USE-flags
On Dec 20, 2007 10:48 PM, Jan Kundrát <[EMAIL PROTECTED]> wrote: > Santiago M. Mola wrote: > > These are potentially ambiguos. > > Could you please elaborate a bit about the raw one? > Just that "raw" could mean more things. Anyway, I have no problem with that since current packages in the tree use it as "raw image format" and new packages which need such flag for a different meaning could set it to something more meaningful. -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED]
Re: [gentoo-dev] Project Update: qt-4
This is a followup that I am now committing "qt4-build.eclass" with a lot of the redundant functions for building Qt4 put into it. The only packages that use/depend on it are currently masked, so feel free to comment here with things you'd like to see changed in the eclass. Caleb -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Assuming that the file extension must change to prevent current PMs from trying to parse new format ebuilds (and not require waiting a year or more), I'd be a lot happier seeing it change *once* to a new fixed extension, with the requirement that the new ebuilds are required to contain within them them EAPI. This should future-proof the system. Preferably, shorten the extension and make a new standard. I noticed that ".eb" seems to be unused -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in rox-base/rox: ChangeLog rox-2.7-r2.ebuild
Donnie Berkholz <[EMAIL PROTECTED]> wrote:
> On 15:05 Mon 17 Dec , Jim Ramsay (lack) wrote:
> > lack07/12/17 15:05:57
> > IUSE="+svg +video"
>
> svg already defaults on for all the desktop profiles, so I'm not
> really sure what that's gaining you.
Good point, removed '+' there
> > RDEPEND=">=x11-libs/gtk+-2.4
> > >=dev-libs/glib-2.2
> > >=dev-libs/libxml2-2.4.23
> > >=x11-misc/shared-mime-info-0.14
> > svg? ( gnome-base/librsvg )
> > !ppc? ( rox-base/mime-editor
> > rox-base/thumbs
> > video? ( rox-extra/videothumbnail ) )"
>
> PPC users aren't supposed to get this stuff? If not, is it even a
> real dependency?
I'm waiting on bug 201983 for ppc to keyword those ebuilds. They are
semi-optional runtime dependencies. I'll explain further:
There are buttons in the ROX application's "options" window which
launch each of these applications. Thus they are not *strictly*
required for basic operation, but are required for all the buttons in
the app to actually work. videothumbnail is USE-dependent because it
needs either mplayer or totem, neither of which are very quick to
install. The other two however (mime-editor and thumbs) are reasonably
simple python apps that really only take a second or so to download and
install.
> > (cd src; make clean) > /dev/null
>
> Subshells are icky.
I agree, replaced them all with pushd/popd instead.
> > chmod 0755 "${D}/usr/bin/${WRAPPERNAME}"
> > chmod 0755 "${D}/usr/bin/${WRAPPERNAME}uri"
>
> fperms?
Ah yes. Done.
> > make_desktop_entry ${WRAPPERNAME} ${APPNAME} ${APPNAME}.png
> > "System;Utility;Core;ROX"
>
> Thought I saw something about desktop entries dropping the suffix for
> the icon, but I don't recall the details.
Yes, this is correct. I have removed it. Also technically speaking
there is no 'ROX' category (any more?) so I have removed it as well and
made it better match the defined menu categories.
--
Jim Ramsay
Gentoo/Linux Developer (rox,gkrellm)
signature.asc
Description: PGP signature
Re: [gentoo-dev] Re: Re: Re: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Richard Freeman kirjoitti: > > How is having a line that states EAPI=foo in the ebuild any less trivial > than putting a -foo at the end of the filename? If anything the latter > is more typing - since the EAPI=foo line would probably be in skel.ebuild... > EAPI=foo is already in skel.ebuild but it's commented because EAPI 1 should only be used when there is a need for the new features. Regards, Petteri signature.asc Description: OpenPGP digital signature
[gentoo-dev] wxGTK 2.8
Time to close bug #145884.
After over a year of waiting (but still way ahead of Debian), wxGTK 2.8 is
finally coming to Gentoo. I'd like to thank everyone for their patience while
we got the wrinkles ironed out.
Many of the problems we've had previously with wxWidgets in Gentoo were due in
general to an incomplete separation between two major versions (being 2.4 and
2.6). These ebuilds had many file collisions and would conditionally install
important files based on if the other version was installed or not, leading to
situations where a working system was solely dependent on the order in which
they were installed. Uninstalling or re-emerging one would often break the
other. Packages would be built against whichever version was handy, despite
what its requirements were. Many bugs were filed, and Jakb was sad.
The first thing we did to get ourselves out of this situation was to get rid of
2.4. Then I took some pointers (and patches) from FreeBSD and got 2.6 and 2.8
to coexist nicely. After some fiddling with eclasses, a wrapper or two, and an
eselect module, we seem to be on good ground.
So here's what you need to know.
For the Users:
Nothing. ;P If all you know about wxGTK is it's some dependency you have to
install on your way to building amule or vlc or audacity then everything should
just work without you having to do a thing. You might be happy to know we've
cut the compile time in half though.
For the Other Users:
If you are building software outside of portage, say, doing development on a package that uses wxGTK or building something from CVS/SVN/etc., then we have a new eselect module (eselect-wxwidgets) which can be used to set the default version and type of wxGTK you need. Initially the profile is set to "none" and you'll have to switch to the one you want. This is currently a global setting, and has zero effect on packages built through portage.
We previously planned to allow installing debug and release versions side by
side, but later decided against it. I know there is some interest in this and
I tried to design things to keep it open as an option so we might reconsider it
sometime in the future.
For the Devs:
Basically, /usr/bin/wx-config is now a wrapper. When called from userspace it
falls through to the wx-config corresponding to the profile the user has set
with the eselect module. When called from wxwidgets.eclass, it uses info
provided by the ebuild (WX_GTK_VER, need-wxwidgets) to choose which wx-config
to call. The obvious result of this is that ebuilds *NEED* to be accessing
wx-config through the eclass. There are a few packages which currently don't
do this that I'll be filing bugs for. Eventually (and sooner than later)
calling the wrapper from ${PACKAGE_MANAGER} without going through the eclass
will result in a fatal error.
The eclass has been in the tree for a bit and is documentated so I won't go over it
again here. `emerge eclass-manpages && man wxwidgets.eclass` should do it. If
we missed anything or you have any questions about the eclass please feel free to ask
me and/or leio and/or [EMAIL PROTECTED] One thing I did want to mention is that the
eclass now automatically does the necessary built_with_use checks (X, unicode, etc) for
whatever type of wxGTK you request so they can be dropped from the ebuilds. There is
also a new check_wx function for checking wxGTK for other USE flags (eg. opengl, odbc,
gstreamer) in a consistent way.
The biggest change in our wxGTK-2.8 is we are no longer supporting the ansi
profile; that is, we are unicode-only. The upcoming wxWidgets 3.0 will do away
with the ansi/unicode split and simply use UTF-8 for everything. If your
package supports building against the unicode libraries (most should), we
encourage you to at least provide that option with a unicode USE flag or at
most make it the default. ;)
Thanks to everyone who helped this along, tested, or otherwise poked at us to
get it done.
Your wxWi{ndows,dgets} team.
PS. wxpython-2.8 will also be added shortly, after I finish cleaning up a few
more packages that break when the two versions are both installed.
--
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
[gentoo-dev] Re: EAPI definition Was: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Zhang Le <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Fri, 21 Dec 2007 12:15:10 +0800: > Ciaran McCreesh wrote: >> 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? Agreed with Ciarn here. Certain PMs, call them super-PMs if you will, wish to work with formats other than Gentoo formats, with an ultimate goal of working with distributions other than Gentoo. If it's not for use in the main tree, how does it affect Gentoo, and if it doesn't affect Gentoo, how is it on topic here? -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: Re: Re: Re: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Ciaran McCreesh wrote: > On Thu, 20 Dec 2007 12:48:31 + > Steve Long <[EMAIL PROTECTED]> wrote: >> >> 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. > [This (along with your stubborn refusal to ever explain anything) is what I mean by your manner not inviting discussion.] The datum you want is in a line in the file, easily extractable without sourcing. If you don't understand that it provides the same functionality, kindly go back to Uni and ask them to take your degree back. >> 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. > Nonsense: if the file isn't source'able the package manager will know this due to the EAPI line giving an unknown key, and won't bother doing anything else with it. You can put whatever you want in there as long as you have the EAPI declaration. >> 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. > You can't even be bothered to provide a link, let alone any sort of explanation. You haven't explained at any point why a line in the ebuild is so unacceptable, yet you keep asserting that it's already been established that it won't work. Even though that was the design that was originally agreed upon, back when you were still a Gentoo dev. >> 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. > No you just state it, in other threads too. That's not establishing anything, and certainly not consensus. It is trivial to extract one line and gives the information required without sourcing. In effect, it's stating that the one thing which can't be dynamic in an ebuild is the EAPI setting, which your proposal requires as well. >> 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. > Yes and if the EAPI is unsupported the manager can skip it. >> 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. > Yeah kinda like the idea of having an EAPI setting in the ebuild so that the manager can ignore it if it uses unsupported extensions, or even a different language. >> > 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. > Like I said, it's trivial to extract a line from the ebuild without sourcing. You know it is, and so does everyone else. >> > 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 metad
[gentoo-dev] Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Bo Ørsted Andresen wrote: > On Friday 21 December 2007 03:41:04 Luca Barbato wrote: >> > * 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. > > And then we have to wait till noone use a version of portage that sources > the ebuild to get the EAPI. Unless we change the file name.. > "We generally make sure that the tree is compatible with portage versions released in the past six months, so if you don't have version released in that timeframe it is possible that you won't be able to use the tree anymore."[1] What applications are so important that require this change in order to work, that we have to go through the tool modifications now rather than wait a few months and let the newer versions of portage deal with it, without us having to make any changes at all? After all we can use EAPI="1" already, and if the portage team want to put more features in, they're at liberty to define EAPI="2" or any other. It appears this is being rushed through: we can have some undefined new features (well Paludis users can) now, if only we allow unbounded changes to the filename suffix. That's not a good enough reason. [1] http://www.gentoo.org/proj/en/portage/doc/common-problems.xml -- [EMAIL PROTECTED] mailing list
[gentoo-dev] [GLEP 55] EAPI subdirectories instead of file name suffixes
Piotr Jaroszyński kirjoitti:
> This GLEP proposes usage of EAPI-suffixed file extensions for ebuilds (for
> example, foo-1.2.3.ebuild-1).
It seems many people don't like the idea of having it in the filename
but how about having subdirectories for different eapis. This should
even be faster for the package manager as it can just ignore the
directories it can't understand instead of having to parse the file names.
example:
${PORTDIR}///eapiX/
Regards,
Petteri
signature.asc
Description: OpenPGP digital signature
[gentoo-dev] Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Ciaran McCreesh <[EMAIL PROTECTED]> posted
[EMAIL PROTECTED], excerpted below, on Fri, 21 Dec
2007 13:59:22 +:
> On Fri, 21 Dec 2007 08:43:43 -0500
> Richard Freeman <[EMAIL PROTECTED]> wrote:
>> Ciaran McCreesh wrote:
>> > Please don't comment any further until you understand how this whole
>> > thing works.
>>
>> I think this is a bit of an unrealistic expectation. This change
>> impacts EVERYBODY - devs, users, etc.
> What. It's a small change that's only visible to developers and power
> users.
But it affects all developers (and power users) in the routine way they
do their job, dealing with ebuilds (or ebuilds plus whatever, if this
GLEP goes thru). As such, it's a "big" change, because it affects how a
lot of people do their routine work.
Yes, that's quibbling over semantics and viewpoint, but it's obvious
/some/ people consider it a big change, big enough for them to make a big
deal about, anyway, which is what matters in terms of discussion and
ultimate acception/rejection of the GLEP.
>> Makes a low-level detail more visible to users.
>
> Users don't see .ebuild files.
"Gentoo users", as often used in the context of this list (from my
observation), do. "Gentoo users" are, as used here, "Gentoo system
sysadmins" by another name. As such, they've always been expected to be
at what the general IT world would consider at minimum "power user",
certainly not the "luser" that's the general IT world's usage of "user".
By definition, "Gentoo users" are expected to be able to RTFM, and
expected to actually /enjoy/ the extra control of being able to mess with
ebuild files and the like. Otherwise, why are they using Gentoo at all,
when it's targeted at that "power user", and there are other
distributions out there directly targeted at the "(l)user" level?
So, "users", as used on this list, *do* see ebuild files, or at minimum,
cannot be reasonably said *not* to see them, since many of them in fact
do see them and make use of them, in overlays and the like.
As for the generally IT world usage of the term, (l)user, that doesn't
come up so often here, because it's not what we deal with. Dealing with
them would be the job of /our/ users -- Gentoo sysadmins by another name.
>> You can't make a wild change to how EAPIs are specified - since old PMs
>> will expect it to be in the filename in a particular format.
>
> You can make entirely arbitrary changes to EAPIs with suffixes, provided
> only that you don't use either .ebuild or .ebuild-(any-existing-eapi).
OK, first, a comment on the GLEP itself: I just looked at it again, and
realized it doesn't actually /specify/ the name format in so many words
or in commonly accepted syntax form. One can see what's expected based
on the /examples/, but it's not specified... anywhere that I could see.
So the GLEP needs something like the below (may not be technically
correct, but as an example to be corrected as necessary when added to the
GLEP) syntax specified:
.ebuild[-]
IMO that's the key to beginning to clear up my (I think former)
confusion. Without that clearly stated, I was conflating the two
possible changes, the one given by the GLEP, and the one left unspec-ed,
and thus reserved for the future and/or other non-Gentoo usage,
extensions /other/ than .ebuild[-].
Given the conflation, I was then left confused by the GLEP requirement
that the EAPI not be changed from that found in the filename (with the
filename EAPI defaulting to 0 if not given), set against the argument
that EAPI could then at some point be made dynamic, or otherwise less
firmly specified than filename semantics requires. Separating the
concepts, then, clears up the confusion, since the possibility is left
open to change to something /other/ than .ebuild[-] as deemed necessary.
So now I see how you could state they must remain the same (in the glep)
yet allow for dynamically setting them ("post-source") in future non-
ebuild* formats.
Further suggestion for the GLEP, then: In addition to specifying syntax
explicitly, note explicitly as well, that this glep deals with .ebuild*
only, and that one possible mechanism for future incompatible changes
would therefore be to change the extension to something other
than .ebuild*.
This should eliminate an entire class of objections (and simple
confusion), including my main previous one, due to the present less than
clear specification and the confusion it caused.
(/NOW/ I see...! =8^)
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP 55] EAPI subdirectories instead of file name suffixes
On Saturday 22 of December 2007 02:41:02 Petteri Räty wrote: > Piotr Jaroszyński kirjoitti: > > This GLEP proposes usage of EAPI-suffixed file extensions for ebuilds > > (for example, foo-1.2.3.ebuild-1). > > It seems many people don't like the idea of having it in the filename Seems you are counting the posts, not the people. > but how about having subdirectories for different eapis. This should > even be faster for the package manager as it can just ignore the > directories it can't understand instead of having to parse the file names. It was already proposed, but didn't seem to get much support. It is equivalent to using the suffixes, but I see it rather as perfomarnce hit, not improvement. The package manger would have to look for ebuilds in the main dir and all the subdirs in case it doesn't have/can't use the cache. -- Best Regards, Piotr Jaroszyński -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] wxGTK 2.8
On Fri, 21 Dec 2007 13:31:54 -0600 Ryan Hill <[EMAIL PROTECTED]> wrote: > [ ... ] Thanks for all your work with wxWidgets packages. -- Michal Kurgan http://dev.gentoo.org/~moloh -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Piotr Jaroszyński wrote: > On Thursday 20 of December 2007 19:29:22 Zhang Le wrote: >> So please make those people understand, so they can comment usefully. > > Are we in the elementary school or something? This is really getting > ridiculous. > ietf.org Are they ridiculous? 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)
Michael Haubenwallner wrote:
> On Thu, 2007-12-20 at 17:22 +0100, Luca Barbato wrote:
>
>> I'm thinking about having them embedded in the comment as first line as
>> something like
>>
>> #!/usr/bin/env emerge --eapi $foo
>
> OT: It actually works adding this first line and do chmod +x foo.ebuild:
>
> #! /usr/bin/env ebuild
>
> Then you can do: ./foo.ebuild {digest,install,merge,whatever}
>
if we are lazy enough we could add this (and add --eapi foo support in
ebuild)
--
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)
Bo Ørsted Andresen wrote: > On Friday 21 December 2007 03:41:04 Luca Barbato wrote: >>> * 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. > > And then we have to wait till noone use a version of portage that sources the > ebuild to get the EAPI. Unless we change the file name.. > Not if we move the rsync path properly so - older pm sync to a minimal try apt to upgrading portage and nothing else - newer sync to the full tree now supporting the newer an better and honey and milk eapi. Still I think we should just postpone this discussion and get a 2008.0 out. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Duncan wrote:
> our users -- Gentoo sysadmins by another name.
THANK YOU! Finally someone said it (and explained it better than I could.)
All our users-- the ones who deal with the glitches that can arise in a
source distro which binary users never see-- have the skill level of an
admin anywhere else.
It might take someone two or three months to get the basics on Gentoo, but
if you can manage a manual install and maintain a Gentoo box, no-one should
be sneering at you (especially as they started out knowing nothing too.)
> Without that clearly stated, I was conflating the two
> possible changes, the one given by the GLEP, and the one left unspec-ed,
> and thus reserved for the future and/or other non-Gentoo usage,
> extensions /other/ than .ebuild[-].
>
Interesting: it brings up the possibility of simply using another extension
for files with eapi encoded in the name, and leaving the existing .ebuild
to continue as is.
PMs which don't support versioning would ignore them, since they're
not .ebuild, and existing tools would need the same changes as
with .ebuild-foo; .eapi-foo ?
> Given the conflation, I was then left confused by the GLEP requirement
> that the EAPI not be changed from that found in the filename (with the
> filename EAPI defaulting to 0 if not given), set against the argument
> that EAPI could then at some point be made dynamic, or otherwise less
> firmly specified than filename semantics requires.
But this would have to be based on /some/ sort of eapi suffix in the
filename, or the file would be sourced by current (not future) versions of
portage (the reason for changing the suffix in the first place.) Given that
why not just use the same in the ebuild EAPI="foo" declaration, with the
proviso that it's restricted to only appearing once in the file?
Still seems much cleaner to me. Oh yeah, we have to do this *now*
we can't wait 6 months or so, because there are tons of apps that our users
need, which they can't get without ebuilds using an api which can't be
sourced.
This is supposed to be about the longer-term, not rushing through changes:
it won't exactly take long to get a version of portage that doesn't
automatically source ebuild files: it can just take the first EAPI line it
finds and not source anything it doesn't know about. As ever the maintainer
takes ultimate responsibility for ensuring their ebuild works, and the QA
tool can trivially confirm that there's only one EAPI declaration.
eg, this finds all ebuilds which have more than one SLOT declaration:
find /usr/portage -type f -name '*.ebuild' -exec bash -c 'for f; do
c=$(grep -c "\bSLOT=" "$f"); ((c>1)) && grep -H SLOT "$f"; done' _ {} +
[all one line]
It's not foolproof (gives false positives eg comments) so I'd use that other
regex for EAPI and put some faith in the maintainers (and the
commit-reviews.)
Oh yeah I forgot, McCreesh thinks they're all idiots[1], so let's just do
what he says. Funny thing is I think the USE-flag metadata thing would have
breezed through as a GLEP; I don't recall one person saying they thought it
was a bad idea.
[1]
http://lab.obsethryl.eu/content/paludis-gentoo-and-ciaran-mccreesh-uncensored
--
[EMAIL PROTECTED] mailing list
[gentoo-dev] Re: [GLEP 55] EAPI subdirectories instead of file name suffixes
Piotr Jaroszy?ski wrote: > On Saturday 22 of December 2007 02:41:02 Petteri Räty wrote: >> Piotr Jaroszy?ski kirjoitti: >> > This GLEP proposes usage of EAPI-suffixed file extensions for ebuilds >> > (for example, foo-1.2.3.ebuild-1). >> >> It seems many people don't like the idea of having it in the filename > > Seems you are counting the posts, not the people. > >> but how about having subdirectories for different eapis. This should >> even be faster for the package manager as it can just ignore the >> directories it can't understand instead of having to parse the file >> names. > > It was already proposed, but didn't seem to get much support. That would be counting posts, not people. It just hasn't been discussed. > It is > equivalent to using the suffixes, but I see it rather as perfomarnce hit, > not improvement. The package manger would have to look for ebuilds in the > main dir and all the subdirs in case it doesn't have/can't use the cache. > Yeah but this isn't about performance (or so I heard. I took that to mean it was about ebuilds which can't be sourced, but you might want to check exactly what McCreesh meant, since I am apparently incapable of understanding his missives.) Given that, the subdirectories would do the job fine, and end-users don't have to worry about building the cache anyway. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Fri, 21 Dec 2007 13:34:17 +0100 Piotr Jaroszyński <[EMAIL PROTECTED]> wrote: > On Thursday 20 of December 2007 19:29:22 Zhang Le wrote: > > So please make those people understand, so they can comment > > usefully. > > Are we in the elementary school or something? Yes, for all intents and purposes, assume your readership is in elementary school. They're certainly not dump, maybe just ignorant, and whatever you're trying to achieve is coming their way, so you'd better have them on your side. Kind regards, JeR -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP 55] EAPI subdirectories instead of file name suffixes
On Sat, 22 Dec 2007 03:41:02 +0200
Petteri Räty <[EMAIL PROTECTED]> wrote:
> Piotr Jaroszyński kirjoitti:
> > This GLEP proposes usage of EAPI-suffixed file extensions for
> > ebuilds (for example, foo-1.2.3.ebuild-1).
>
> It seems many people don't like the idea of having it in the filename
> but how about having subdirectories for different eapis. This should
> even be faster for the package manager as it can just ignore the
> directories it can't understand instead of having to parse the file
> names.
>
> example:
>
> ${PORTDIR}///eapiX/
In terms of what it does and doesn't allow, this one's equivalent. But
it has some new disadvantages:
* It's several more directory reads. This is a measurable performance
hit on something that's already i/o bound.
* It's harder to work with for developers. Ebuilds are no longer all in
the same place, and it's harder to see what you're working with.
On a subjective niceness scale, I'd suspect that the file extension is
less unnice.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
Re: [gentoo-dev] Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Sat, 22 Dec 2007 06:35:07 + Steve Long <[EMAIL PROTECTED]> wrote: > Oh yeah I forgot, McCreesh thinks they're all idiots[1] No no. I think some of them are idiots. Get it right. > Funny thing is I think the USE-flag metadata > thing would have breezed through as a GLEP; I don't recall one person > saying they thought it was a bad idea. But you do recall people saying how it needed extending to be useful. Yes, it would have breezed through as a GLEP, but it would have had a half dozen small additions that would have made it a lot more useful. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Sat, 22 Dec 2007 04:19:45 +0100 Luca Barbato <[EMAIL PROTECTED]> wrote: > Piotr Jaroszyński wrote: > > On Thursday 20 of December 2007 19:29:22 Zhang Le wrote: > >> So please make those people understand, so they can comment > >> usefully. > > > > Are we in the elementary school or something? This is really > > getting ridiculous. > > ietf.org Are they ridiculous? Do you see them explaining what TCP is in great detail in every single publication that mentions TCP? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Fri, 21 Dec 2007 09:37:27 -0700 Joe Peterson <[EMAIL PROTECTED]> wrote: > Assuming that the file extension must change to prevent current PMs > from trying to parse new format ebuilds (and not require waiting a > year or more), I'd be a lot happier seeing it change *once* to a new > fixed extension, with the requirement that the new ebuilds are > required to contain within them them EAPI. This should future-proof > the system. Only until another source-level change comes along, which will hopefully be fairly soon -- eclasses need a good kick in the nuts, for example, and that pretty much means a source-level break. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Re: Re: Re: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Sat, 22 Dec 2007 00:59:53 + Steve Long <[EMAIL PROTECTED]> wrote: > >> 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. > > > [This (along with your stubborn refusal to ever explain anything) is > what I mean by your manner not inviting discussion.] > > The datum you want is in a line in the file, easily extractable > without sourcing. If you don't understand that it provides the same > functionality, kindly go back to Uni and ask them to take your degree > back. Except there's absolutely no guarantee that it is, nor that it always will be. > >> 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. > > > Nonsense: if the file isn't source'able the package manager will know > this due to the EAPI line giving an unknown key, and won't bother > doing anything else with it. > > You can put whatever you want in there as long as you have the EAPI > declaration. Which is what I said: it's different 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. > > > You can't even be bothered to provide a link, let alone any sort of > explanation. You haven't explained at any point why a line in the > ebuild is so unacceptable, yet you keep asserting that it's already > been established that it won't work. Even though that was the design > that was originally agreed upon, back when you were still a Gentoo > dev. The GLEP explains it all. > >> 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. > > No you just state it, in other threads too. That's not establishing > anything, and certainly not consensus. > > It is trivial to extract one line and gives the information required > without sourcing. In effect, it's stating that the one thing which > can't be dynamic in an ebuild is the EAPI setting, which your > proposal requires as well. No, it's stating that EAPI has to be static, in a particular format, in a particular place, set in a particular way. Only the first of those is a reasonable requirement. > >> 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. > > > Yes and if the EAPI is unsupported the manager can skip it. Again, you miss the point: at the package manager, there's a distinction between knowing that there's an ebuild that isn't supported because of its EAPI and not even being sure what exactly a particular ebuild is to the extend that you don't know its CATEGORY/PN/PV. Only being able to handle the first of these is insufficient. > > 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. > > > Like I said, it's trivial to extract a line from the ebuild without > sourcing. You know it is, and so does everyone else. Note *the way things are currently*. If you think this is untrue, provide an algorithm that will correctly give the EAPI of any current or future ebuild given that ebuild's filename (hint: you can't). > > 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. > > > So extract the line and get the value, and stop pretending this is > some mystic art only you and the people who agree with you have the > ability to comprehend. It's coding, and yeah it's tricky sometimes, > but it's being run by a CPU; if you can explain it to the computer > you can explain it to someone else (if you want to; if all you're > about is putdowns, ofc, you can obfuscate and take 5 mails to get > across what could have been done in 1, all the while telling the > people who have no choice but to deal with you that it's all their > problem. Asperger's is bad, m'kay?) With the way things are currently you *can't* extract the line and get the value, because there's no
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Sat, 22 Dec 2007 04:24:06 +0100 Luca Barbato <[EMAIL PROTECTED]> wrote: > Not if we move the rsync path properly so > > - older pm sync to a minimal try apt to upgrading portage and nothing > else > > - newer sync to the full tree now supporting the newer an better and > honey and milk eapi. ...and do it again every three months when a new EAPI comes along. Great... -- Ciaran McCreesh signature.asc Description: PGP signature
