On Saturday 16 May 2009 20:17:14 Nick Fortino wrote: Ciaran McCreesh wrote: On Sat, 16 May 2009 16:39:40 -0700 Nick Fortino nfort...@gmail.com wrote: Given the above, it should be clear that any argument which states some future improvement to the ebuild format will be impossible based upon making the wrong choice between proposal 1 and proposal 2 must be invalid, as they have the same expressive power. Note that allowable algorithms for which the proof works includes caching and version ordering as well as the simple execution of the ebuild. Unfortunately, your argument is entirely wrong, as can be illustrated by a simple counter-example that you would already know about, had you read the GLEP or the thread. With EAPI in a fixed format, it is impossible to allow extensions to the version format in future EAPIs. Even given a fixed format and a constant extension, adding foo-1.23-rc1.ebuild will cause breakage, but adding foo-1.23-rc1.ebuild-4 will not. This has already been covered at length, and is explained in the GLEP. Why did you disregard this when posting your 'proof'? I didn't intentionally disregard that case, but I see your point. I made the assumption that package mangers wouldn't try to source ebuilds with a sourcing EAPI they didn't understand. I concede this is a terrible assumption, unless such a thing is specified in the PMS itself. It is still fixed by a single extension change, as opposed to a whole set. Once this is done, simply state that all package managers should ignore EAPIs they don't understand (a requirement of GLEP-55 as well). Your point still does not dispute that specifying the EAPI within the ebuild and outside the ebuild convey identical information (this is all I was trying to prove in the first place). For the case you bring up: If foo-1.23-rc1.ebuild is added, it must not be in any of the currently existing EAPIs, for if it were, it would be illegal. Thus, a package manager would open this file, get the sourcing EAPI in an EAPI independent way, realize it doesn't understand, and abort the sourcing of that ebuild. Changing the extension once insures current package managers don't try to do things they aren't capable of (I apologize for not putting this in my first mailing). Given this change, however, I still assert the statement of the two schemes have identical expressive power. For versioning, it has been pointed out (by you and others) that getting the latest version would require, under any implementation, opening N files in case 1, and reading N file names in case 2. I do not dispute this in any way. Instead, I would like to point out that moving the argument from features which are possible to support (which I still contend are essentially identical), to efficiency vs. a perceived prettiness would be significant progress. Indeed, at this point it would be possible to make a decision based on reference implementations for known common use cases, and an executive council decision about whether timing or extension consistency is more important. If it turns out that using a solution of type 1 takes minutes to resolve versions, than by all means, GLEP-55 is by far the best proposed solution. If, instead, the runtime difference in real use cases is negligible, then the pure philosophical arguments for using a single extension holds true (in my opinion). Nick Fortino And we could probably switch between types if forced to do so.
On Friday 15 May 2009 05:44:47 Richard Freeman wrote: Ciaran McCreesh wrote: On Thu, 14 May 2009 20:06:51 +0200 Patrick Lauer patr...@gentoo.org wrote: Let EAPI be defined as (the part behind the = of) the first line of the ebuild starting with EAPI= Uh, so horribly utterly and obviously wrong. inherit foo EAPI=4 where foo is both a global and a non-global eclass that sets metadata. This seems to come up from time to time but I don't see how this is a problem that GLEP 55 solves. If the rule is first line of the ebuild starting with EAPI= and the ebuild is as you suggest above, then the EAPI is 4 (without any regard whatsoever to what might be in foo). The counterargument seems to be that eclasses should be able to modify EAPI behavior. However, if you want to do this then you DEFINITELY don't want to put the EAPI in the filename - unless you want eclasses to start renaming the ebuilds to change their EAPIs and then trigger a metadata regen. This seems to be a case where a problem is proposed, with a solution. Somebody proposes an alternate solution and the complaint is raised that it doesn't handle situation X. However, the original proposed solution doesn't handle situation X either, so that can hardly be grounds for accepting it over the alternate. I'm actually more in favor of an approach like putting the EAPI in a comment line or some other place that is more out-of-band. Almost all modern file formats incorporate a version number into a fixed position in the file header so that it is trivial for a program to figure out whether or not it knows how to handle the file. Another common approach is to put a header-length field and add extensions to the end of a header, so that as long as you don't break past behavior you could create a file that is readable by older program versions (perhaps with the loss of some metadata that the older version doesn't understand). Just look up the UStar tar file format or the gzip file format for examples. Of course, such file formats generally aren't designed to be human-readable or created with a text editor. The same applies to executables. It is impossible from the filename to tell if /bin/bash is in a.out or ELF format, or if it is a shell script. Instead a simple standard is defined that allows the OS to figure it out and handle it appropriately. If you try to run an ELF on some ancient version of linux it doesn't crash or perform erratic behavior - it will simply tell you that it doesn't understand the file format (invalid magic number). In any case, I'm going to try to restrain myself from replying further in this thread unless something genuinely new comes up. When I see 26 new messages in my gentoo-dev folder I should know by now that somebody has managed to bring up GLEP 55 again... :) If I understand the problem GLEP 55 is trying to solve correctly, it stems from portage's assumption that an unknown EAPI is equal to EAPI 0. Could that assumption be changed to an unknown EAPI is equal to the latest supported EAPI. Now I understand that this change would have to wait until all the ebuilds in the portage tree correctly define their EAPI, but would the idea be technically feasible at least excluding EAPI0 ebuilds? I think it would be if all EAPIs are forward compatible up until the EAPI declaration in the ebuild.
On Saturday 21 March 2009 19:03:45 AllenJB wrote: Patrick Lauer wrote: Hi all, with the discussion about EAPI3 we have now 4 (or 7, depending on how you count them ;) ) EAPIs available or almost available. This is getting quite confusing. To make our lives easier I would suggest deprecating EAPI0 and migrating existing ebuilds over some time to EAPI1 or higher until EAPI0 can be obsoleted at some point in the future. I would set the start of deprecation warnings about 3 months from now and the obsoletion quite a time later, maybe 12 months from now, when a sufficient amount of ebuilds has been migrated. Deprecating EAPI1 at the same time would reduce the amount of EAPIs we have to think about, but since it has some changes like adding src_prepare migration would not be as trivial. So I'd prefer keeping it around a bit longer. Comments? Patrick While there definitely arguments for deprecating EAPIs, I would suggest caution. A low number of active EAPIs can make life easier for developers, but it can also make life harder for some users. There are still users coming to the forums upgrading systems which only understand EAPI 0. I accept that Gentoo is certainly a relatively fast moving distro, but I think that developers also do need to consider users who have systems that are currently just working and may not upgrade often (once a year or even less) As such, I would suggest that forcing a move to the most recent stable EAPI is possibly unwise. snip AllenJB Note, this just my opinion. It may not be entirely practical or cover all the issues regarding backwards compatibility. I intend it to provoke questions and thought as to what a reasonable policy for backwards compatibility might cover. Waiting a year or longer to upgrade a gentoo system carries a good risk of having something explode into a near unrecoverable mess. I definitely do think that some major focus needs to be placed on how far behind a gentoo system could be and should still be expected to catch up. An oversimplified example. Assume that I can find all required patches and source code to do the initial builds, and that all normal configuration file checks/updates are done after the current tree is installed. I create three different virtual machines from cvs snapshots of the portage tree. The first is dated 6 months ago. The second is dated 12 months ago. The third is dated 18 months ago. Which of these should be reasonably updateable to the current portage tree? My suggestion is that policy should allow machine 1 to be updated through regular update procedures to the current tree, unless major changes dictate otherwise. Major changes being incompatible ebuild formats, toolchains, and other here is the line sorry kind of changes. A careful operator should probably be able get machine 2 updated to the current tree, again unless major changes dictate otherwise. We should not make go out of our way to make upgrading from this point out hard for the operator, but, new growth should be favored over the ease of upgrading. Machine 3 is just out of luck. Here is the new install cd and handbook, have fun. Regular update procedures would be: emerge --sync; emerge -uND world -f; emerge -uND world; revdep-rebuild; emerge --depclean; The careful operator might update the toolchain first and emerge -e world or something similar.
On Monday 22 December 2008 11:40:32 pm Branko Badrljica wrote: Duncan wrote: Branko Badrljica bran...@avtomatika.com posted 494f1518.2020...@avtomatika.com, excerpted below, on Mon, 22 Dec 2008 05:18:32 +0100: Maybe I should have filed this as a bug, but don't have a clue to which package should I assign it, if any. FWIW, this would have been a perfect question for the gentoo-desktop list, but doesn't really belong on the -dev list. There's also the gentoo-user list, altho that one has very heavy volume so you might not wish to subscribe there. Well, regarding the actual error, i think it might interest someone here, also. Although I mentioned just baselayout and openrc, I did check ( end reemerged etc) hal also, and it indeed emerged _without_ /etc/init.d/hald. I tracked it down to root cause: Although I don't use it, I have compiled-in selinux support ( and selinux=0 as kernel start parameter). When I was makeconfiging my kernel, I saw also SMACK support, read info and thought what the heck, it can't hurt me, but I might want to play with it, so I compiled-in that, too. Then after some time I realised that I never got to actually used all that and changed my config file by cutting out that all that security stuff. And recompiled all my kernels accordingly. Around that time I saw people recommending using tmpfs for /var/tmp as this would speed-up emerges etc, so I did that. I didn't know that while I was on SMACK (pun intended) , machine would add extended attr to every file machine would write. ( It was SMACK64 in security domain ). After cleaning my system, even though those attributes were still on all files, everything was fine until I actually tried to copy something from that FS to some other FS. /bin/cp would realise that there are extra security attrs on a file and would try to duplicate them on a copy. And since new kernel was without SMACK support, it would fail. When emerging stuff with /var/tmp on tmpfs, /bin/cp seems to get rarely used in such way when copying stuff into /var/tmp or maybe it was because distfiles were without SMACK attrs- so most ebuilds would seemingly sucseed. Most errors seem tho have been made when ebuild needed some local data, usually in /etc that had SMACK64 attr. If /bin/cp was used to get that data, it would fail, but this would not stop the ebuild. It would usually finished its work just as if nothing happened. Once I unmounted /var/tmp, ebuild could finish normally. Also, after removing security attr from all files, ebuild has started working normally from tmpfs partition again. It is also interesting that on 2.6.27* kernel ebuild fails sometimes and when it fails, it does so silently most of the time. With newest 2.6.28-rc9 i couldn't emerge a thing... Since I might not be the only tinkerer on Gentoo to try stuff like that and since it took me a day to find this, maybe it wouldn't hurt to check for this kind of thing in portage ? At the very least failed cp should stop emerge... Very nice edge case and great work tracking down the cause.
On Monday 15 December 2008 05:47:47 pm Duncan wrote: Paul Varner fuzzy...@gentoo.org posted 1229371818.21630.7.ca...@txslpc1d36.wkst.vzwnet.com, excerpted below, on Mon, 15 Dec 2008 14:10:17 -0600: # Paul Varner fuzzy...@gentoo.org (14 Dec 2008) # Dead upstream, masked for removal in ~30 to 60 days. app-portage/udept Additionally, it doesn't play well with EAPI's greater than zero. The removal bug is Bug #250839. If upstream comes back alive or someone forks and actively maintains, I will unmask or re-add to the tree. Ouch! This one hurts! The main thing I use it for, and therefore the question I have about any useful substitute, is quickly getting a changelog when portage won't spit one out. In particular, when there's a USE flag change in an existing package, or a downgrade, emerge --log won't output anything, because it's not an upgrade. However, I find the info in such logs often useful! Of course I can check the package category and type in the whole long path to the changelog and edit/head/view it by hand, but a quick dep -j pkg is a lot faster and very useful! While I'm at it, is there anything useful to display metadata.xml? In particular, the long descriptions and use flags can be useful. With use.desc and especially the local version thereof going deprecated, and with additional info about global flags sometimes in the metadata... Does anyone have a substitute for udept's clean word file and clean /etc/portage options?
On Tuesday 09 December 2008 12:13:40 pm Petteri Räty wrote: Robert R. Russell wrote: My personal opinion on this matter is pick one of the following: 1) perform the bugfix without a version bump and remain at the current EAPI version 2) perform the bugfix with a version bump and remain at the current EAPI version 3) perform the bugfix with a version bump and upgrade to the latest EAPI Options 1 and 2 are how most updates are done, the user can mask the latest version or upgrade. Option 3 allows the user to continue using the previous version while they decide to update to a portage version that supports the new EAPI. The current policy states that ebuilds should only be bumped if the installed files change. Changing EAPI from 1 to 2 has no effect outside the vdb so the current policy means developers should use option 3. There was a bug in stable Portage when EAPI 2 went in the tree that made Portage stack trace but that's a problem with Portage not with the policy in general. I would prefer that option 3 be made policy because I run several ~arch packages that either don't have a stable version (kradio) or have a feature that I need (gentoo-sources), and will not be pushed to stable immediately for various reasons from lack of maintainer time to everybody says it conflicts with major pieces of the system (Firefox 3, 64 bit netscape-flash, and xorg). Why should we prefer making it a little bit easier for stable users over making ~arch users needlessly recompile stuff? Regards, Petteri My answer is a simple example from my own system. My current system uses a motherboard that is around 6 months old and is only correctly supported by the latest ~arch gentoo-sources. The add on video card, a 1 to 2 year old nvidia card, works great with x11-drivers/xf86-video-nv-2.1.12 as long as I am using the latest ~arch xorg-x11. The internal video card isn't even recognized by the xf86-video-intel drivers except the ~arch versions. Even some of the packages I use for school work such as kile have bugfixes and other improvements between the versions in stable and ~arch that are important to getting work done. The ability to selectively upgrade only the specific packages needed to get a working system is a major strength for Gentoo. Why should I have to run more packages from ~arch than I absolutely need to? We all know that upgrading more software than absolutely necessary will result in bad things happening to a computer. The easiest solution to the problem with ~arch having the only working versions of some packages is to get more of those packages stabilized. But, we all know that the manpower required simply doesn't exist.
On Monday 08 December 2008 06:00:10 pm Jean-Marc Hengen wrote: snip This mail is about EAPI usage in the portage tree. Let me describe it, with what happened today: I'm running a mostly stable system (91 of 1255 installed packages are unstable), but I test here and there some packages. On of the packages, which I installed and is currently masked unstable, is dev-util/cmake-2.6.2. I use it on a daily basis and happy with it so far. Today, while updating, portage wanted to downgrade cmake to the stable release, due to all cmake 2.6.x version masked by EAPI 2. The cmake-2.6.2 ebuild was updated to use EAPI 2 (along with fixing a bug). My rule of thumb is to only use unstable on none system packages snip With kind regards, Jean-Marc Hengen, a happy gentoo user The problem is not that an EAPI 2 supporting portage is unstable or that he is using a ~arch version of one particular package, but the during a bugfix the maintainer moved the ebuild to EAPI 2 without a version bump forcing Jean-Marc to downgrade to the stable version. The question on policy is, can a maintainer upgrade an ebuild to the latest EAPI while doing some other bugfixing without a version bump? My personal opinion on this matter is pick one of the following: 1) perform the bugfix without a version bump and remain at the current EAPI version 2) perform the bugfix with a version bump and remain at the current EAPI version 3) perform the bugfix with a version bump and upgrade to the latest EAPI Options 1 and 2 are how most updates are done, the user can mask the latest version or upgrade. Option 3 allows the user to continue using the previous version while they decide to update to a portage version that supports the new EAPI. I would prefer that option 3 be made policy because I run several ~arch packages that either don't have a stable version (kradio) or have a feature that I need (gentoo-sources), and will not be pushed to stable immediately for various reasons from lack of maintainer time to everybody says it conflicts with major pieces of the system (Firefox 3, 64 bit netscape-flash, and xorg).
Some of the packages that I use are ~arch keyworded right now and I was wanting to ask some questions about when to file stabilization requests and about how much information needs to be provided when filling them. 1) How long do you recommend using a package before filing a stabilization request? 2) Should I file stabilization requests on software that works mostly as in everything that I use it for normally but I can force it to fail if I feed it some really strange input or contrive a specific set of options that will cause invalid or incorrect output. 3) Should I provide a patch that removes the ~arch keyword when I file the stabilization request? Thanks.