Ciaran McCreesh wrote: > Steven J Long wrote: >> Robert R. Russell wrote: >> <snip> >> > 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. >> >> No, portage will reject an ebuild with an unknown EAPI, as per the >> spec. > > You're confusing the term 'unknown' here. > > Before an ebuild has had its metadata generated, its EAPI is unknown. At > this point, the package manager assumes EAPI 0. > With the format restriction, that everyone last year seemed happy with, apart from the few pushing GLEP-55, this isn't an issue. The mangler *should* be scanning first for the EAPI to see if it can even handle the rest of the ebuild (assuming it's not from the main tree or an upstream overlay, or we're not a normal user. Developer machines rightly need to do a bit more work, but it's not exactly onerous since portage automatically does it for you.)
> After an ebuild has had its metadata generated, its EAPI is either > known or unsupported, but if known may be unspecified. If it is known > but unspecified, the package manager treats it as equivalent to EAPI 0. > Yes, empty = 0 as well-understood. > Conceptually, these aren't the same thing. > In practical terms, this is a useless proposal. It rightly got trashed last year. Let's just use a prefix instead of a suffix to indicate vcs, keep branch and upstream for dep specification, not filename, to allow inter-repo dependency for overlays for the few cases where it's actually needed, and add debian-style epochs to guarantee future expansion. If you have a use-case that actually requires more in a version specifier for upstream software, please present it and explain how it cannot be represented with the above. In passing, I must express bewildered amusement at the idea of a format with an unlimited amount of extensions. If you really want something so radically different that it cannot be handled in the Gentoo scheme, or BASH, use ONE _other_ extension. Have a good weekend, all. -- #friendly-coders -- We're friendly but we're not /that/ friendly ;-)
