Re: [gentoo-dev] [RFC] Allow bash-4.0 features in EAPI=3 ebuilds
2009-05-20 20:00:43 Ciaran McCreesh napisał(a): On Wed, 20 May 2009 19:12:56 +0200 Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org wrote: This error occurs only when there is no up-to-date cache for given ebuild. rsync users would see only the usual masked by: EAPI 3 message. We always have to assume that there might not be an up to date cache. The Gentoo rsync mirrors do not always ship up to date cache, particularly if someone's just changed a widely used eclass. Users can wait an hour and run `emerge --sync` again. Anyway, Portage still allows to install other ebuilds (with lower EAPI) of given package, so this corner case doesn't need to slow down progress. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [RFC] Allow bash-4.0 features in EAPI=3 ebuilds
On Thu, 21 May 2009 19:57:49 +0200 Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org wrote: We always have to assume that there might not be an up to date cache. The Gentoo rsync mirrors do not always ship up to date cache, particularly if someone's just changed a widely used eclass. Users can wait an hour and run `emerge --sync` again. ...but that's not what happens. Instead, the users get their screen spammed with annoying messages, get confused and run to bugzilla in droves. This just takes us right back to the bad old days when changing anything would result in mass user confusion. The whole 'EAPI' thing wasn't an arbitrary whim. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] The fallacies of GLEP55
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.
[gentoo-dev] Re: [RFC] Allow bash-4.0 features in EAPI=3 ebuilds
Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org posted 200905211957.55040.arfre...@gentoo.org, excerpted below, on Thu, 21 May 2009 19:57:49 +0200: 2009-05-20 20:00:43 Ciaran McCreesh napisał(a): On Wed, 20 May 2009 19:12:56 +0200 Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org wrote: This error occurs only when there is no up-to-date cache for given ebuild. rsync users would see only the usual masked by: EAPI 3 message. We always have to assume that there might not be an up to date cache. The Gentoo rsync mirrors do not always ship up to date cache, particularly if someone's just changed a widely used eclass. Users can wait an hour and run `emerge --sync` again. Anyway, Portage still allows to install other ebuilds (with lower EAPI) of given package, so this corner case doesn't need to slow down progress. Except that users are STRONGLY encouraged (on threat of ban) from syncing more than once a day. A 24-hour wait can seem like a long time, especially when you're doing your weekly update on your one off day a week, so it's effectively a 7-day wait, or you were updating your folks computer on holiday and it could be a multi-month wait, or when something's broken that you're depending on to make that presentation in the morning and you know the new version fixes it because the bug said so. If we're going to be saying wait an hour, then let's get rid of the wait 24-hours thing. Otherwise, that's mixed messages to users and as Ciaran points out, users get confused by such things. -- 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
Re: [gentoo-portage-dev] rsync support for fetching binary packages
On Tue, May 19, 2009 at 02:47:45PM +0300, Amit Dor-Shifer wrote: Hi. Looking at getbinpkg.py, I see that BINPKGs can be retrieved using http/s s/ftp. I'm wondering about rsync, as it is mostly supported across portage (and also in layman). Is there some design reasoning behind this lack of support, or is it that no-one has yet gotten around to implement it? I'm raising the question because I'm implementing a private repository and would prefer not to service it via http if I don't have to. Right now, the only feature which is blocking me is this lack of support for binary packages. Look in the code to be sure, but I'd expect it just hasn't been implemented. If I were in your shoes, I'd generalize the SYNC proto support into something usable for binpkgs also- I did this in pkgcore, works fairly well (and could be extended to fetching in general, which again works well enough). Personally, I wouldn't dick around with rsync for individual file transfers- http/ftp seems better suited, but I may be missing something about your setup that warrants it. Cheers- ~harring pgpWLgNBHXAcF.pgp Description: PGP signature