Re: [gentoo-portage-dev] DB and binary dependency
going to be able to make something that works in 95% of the cases of C and C++ programs. This however is not enough to base automatic dependencies on. You need something a lot more reliable. For verification (instead of automatic deps) 95% is however acceptable. The problem stays however that many of the packages in the tree are not C or C++ based (or worse, mixes). Analysis of binary files is something that works on all elf objects, regardless of their language or compiler. The results of analysing are roughly the same as the result of source analysis. It is A LOT easier to do though as there are tools, and you don't need to parse at all. It's also faster to do, as the ELF format is highly structured. Additionally one could do a fast scan of #include headers of all installed header files. These things are all not done yet, and quite cheap to do (both in time for running, as in development time). This verification will probably yield a better coverage than source analysis will. It is also closer to what we are interested in. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpVnyKuUsiXj.pgp Description: PGP signature
Re: [gentoo-portage-dev] DB and binary dependency
On Friday 24 March 2006 12:40, tvali wrote:
Interface can be made somewhat automatically checkable.
For example:
void a(int);
void b(int, int);
void b(int, char);
Is compatible with:
void a(int);
void b(int, int);
Unfortunately, your wrong. This only makes sure that you have the right
slots to put your squares, triangles and circles in. It does not say that
b(int,int) from the first lib actually does the same thing as b(int,int)
from the second library.
To make it worse, suppose that header file 1 defines the following macro:
#define c(x,y) { int A = x; int B = y; if (AB) { b(A,B); } else
{ b(B,A); }
And header file 2 defines the following macro
#define c(x,y) { int A = x; int B = y; if (AB) { b(A,B); } else
{ b(B,A); }
And the semantics of B are such that one is supposed to use c(x,y) to call
b, and b1 accordingly expects the first argument to be smaller, and b2
expects the second one to be smaller. On the source level, this macro
makes it transparent. The libraries, although they may seem different,
are incompatible. While they implement the same source interface, they do
NOT implement the same binary interface. On a binary (read compiled)
level, they can not be exchanged for eachother.
While the above example is clearly broken design, this does happen enough
in actual libraries in way more subtle ways. And that is disregarding the
fact that the linux/elf ABI does not include argument lists in symbol
linking. As such b(int,char) is indistinguishable from b(int,int). To
overcome this C++ uses name mangling which creates names based on the
signature.
And this can be checked automatically - real header must have all
headings that interface describes. Microsoft has actually done good
work in C# on that topic -- first place where i saw something like
that after thinking about it myself :) This MS version is feature of a
language, of course, not a feature of compiler. Anyway, that might
give an idea.
There is a reason that MS implements it on the language level, in C#. It
is impossible to do while keeping the (admittedly extremely poor)
semantics of C and C++. Unfortunately the linux ABI (Application Binary
Interface) is based on C. As such one has to take C into account.
I'm actually sure that this all can be calculated up from sourcecode
and bindep would be after that a check if cpu didnt calculate
something wrong :P Another question, how difficult it is and is it
worth the time.
Perhaps you should read up your knowledge of the C language. After you
found that the C language is a mess, try C++, it makes things worse.
After that's finished take a look at solving this problem for ALL
languages.
Automatic source analysis for dependency calculation is a dead end. Even
if you manage to find the proper interfaces (oops, the package had it's
own gl.h instead of using the system one), you don't know anything about
the semantics of those interfaces. Two things with the same name may very
well have very different behaviours.
Paul
--
Paul de Vrieze
Gentoo Developer
Mail: [EMAIL PROTECTED]
Homepage: http://www.devrieze.net
pgp9iE5mTKGuU.pgp
Description: PGP signature
Re: [gentoo-portage-dev] DB and binary dependency
On Friday 24 March 2006 13:10, Brian Harring wrote: As I stated earlier, bincompat (not binslot paul :P) is the route to If you want to call it bincompat, I'd have to insist to make it BINCOMPAT ;-). go- it gives you up front information so a resolver can plan out what has to be rebuilt automatically. An argument I forgot to mention indeed. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpeje4vSUL4a.pgp Description: PGP signature
Re: [gentoo-portage-dev] DB and binary dependency
On Thursday 23 March 2006 20:53, tvali wrote: So this interaction is one more thing to get simpler? I'm starting to think that i should seek for some very-very small part of portage to develop, because size of things [amount of work], which i already think i should improve in some way, is getting to somewhere near infinity :) ...ok, near what infinity is for me, not theoretical infinity ;) What is the simplest way to get one portage running in some virtual space where i could install and uninstall without actually changing my system? Using chroot in the same way as when installing gentoo is good? Certainly, chroot combined with lvm snapshots would be the easiest way. If you want to focus on binary packages, you might want to start with not doing it automatically, but using some crude heuristics. You can make it configurable for when the heuristics don't work. Basically what is the difference between a binary package and the source package is the dependencies. You can regard a dependency as a restriction on the configurations in which the package can be installed. For binary packages only runtime dependencies are relevant (well in gentoo anyway, we don't have initial configuration deps). Binary packages do however further restrict the configurations from the runtime dependencies. These restrictions originate from the configuration when compiling the package. Then I have some good and bad news. The good news: - Binary dependencies are as necessary for binary packages, as for validating a current configuration (set of installed packages). The bad: - For proper binary dependencies the depend expression possibilities must be extended. Useflag dependencies would be at least usefull. BINSLOT would be almost required. We already saw that SLOT can't always be used for BINSLOT. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpC1Bf8otT4G.pgp Description: PGP signature
Re: [gentoo-portage-dev] DB and binary dependency
On Wednesday 15 March 2006 16:13, Gustavo Sverzut Barbieri wrote: Hello, There is any provision for binary dependency on Gentoo/Portage? The way it works now is quite messy with things like revdep-rebuild. I have an idea to solve this problem: after software is build, you check which files it links (ldd binaries libraries) and check the used against installed packages. If a library is not provided by an installed package we could have a policy to inform user or just abort installation. Also, if we implement these dependencies in rpm-generator, we could just generate RPM packages and install it in the RPM-DB and let it handle these kind of things. With these in place emerge would handle the build stage (where it excels), but rpm would handle the binary installation and dependencies (where it excels). Solving this is not trivial. Basically suppose application X depends on sys-libs/db-4.* This can be resolved by differently slotted libraries. We need to record which one was actually used (not easy by itself, but more an issue of the ebuild itself, if more than 1 candidate is available). But suppose that we know that the application was compiled to use db-4.3.29. We must then know that it is ok to replace the db-4.3.29 package with 4.3.30, but that it isn't ok to replace it by 4.3.28 or 4.4.20. To make this things worse, the above example assumes that within a slot, the libraries are binary compatible. There are examples of libraries that are not. And what about a library whose interface is dependent on a third library: B uses A, C uses B, but B exports A. So B is dependent on A, and the binary package of C must record that B was compiled with A. In short, welcome to binary package hell. This is the reason that binary distributions must use versions. Even debian. It is just very very hard to fix these kinds of indirect dependencies. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpqRcIBYHhbT.pgp Description: PGP signature
Re: [gentoo-portage-dev] DB and binary dependency
On Thursday 16 March 2006 15:18, tvali wrote: To make this things worse, the above example assumes that within a slot, the libraries are binary compatible. There are examples of libraries that are not. And what about a library whose interface is dependent on a third library: B uses A, C uses B, but B exports A. So B is dependent on A, and the binary package of C must record that B was compiled with A. In short, welcome to binary package hell. This is the reason that binary distributions must use versions. Even debian. It is just very very hard to fix these kinds of indirect dependencies. I think that there are many reasons, why such kind of important thing should not be automatically generated. Starting from the fact that one thing is dependency in binary, another thing is knowledge if this combination actually works, has no bugs, should not be masked. Anyway, if such binary dependancyes should ever be used, then it would be best to: 1. register version number of interfaces 2. register interface groups I mean: If some lib supports commands turnon() and turnoff(), but one version supports additionally command int checkifturnedon() and another supports char checkifturnedon(), then there should be: * Interface group, which states only that there are turnon and turnoff functions -- as many apps use only most standard and minimalistic set of commands from one lib, there is no need to know if some advanced features are 0.9.80 or 0.9.64 compatible. * Two interface versions, 0.9.80a and 0.9.80b, for example While theoretically one can't even know that the semantics are correct, we know from experience that hell will not break through. Downgrading libraries is always problematic though. It's not desirable enough to try to support it. All those interfaces and groups could be file links -- lib_interfacegroup_interface1.a would link to libinterface1.a. Looking at a sub-package level is going to make things way too complex. I don't think that doing so is going to help gentoo/portage in any way. If there is 1 library with 2 sets of minimal functionality, then it's questionable, how to implement both (there would be linker error in some cases) -- which makes this conception weaker. Anyway, when standard interfaces are used and linked, that would help a bit. IMHO we need to know from every binary or installed package which package version and slot was used to satisfy it. We also need to know which of those dependencies must be exported to packages which use this one. All this must also take useflags into account ;-) of course. Anyway -- why should i check dependencies *after* building of a big pack, maybe hours of building, when i can check it without even downloading it, when there is nice portage tree? And, i think that making it binary would allow too much bad style -- there are imho things, which should not be automated without very-very careful thinking even if one can only win with automating them in theory and portage tree is most definitely one of them. The difference between binary packages and tracking what is installed with which relations are very small. Basically once compiled, the candidates that may resolve a dependency are fewer. While a BINSLOT variable could be an option (Although I'm not sure whether this would be needed), we still need to know the minimal version of the package within the slot. It's not about checking dependencies after building. It's about seeing whether one should rebuild package B because it depends on package A that has been rebuilt. Perhaps package A is slotted, so I don't need to rebuilt. But then when I want to remove the old version, portage should realise that while the source dependencies are still met, the binary dependencies have not been met, so a rebuild is needed. Revdep-rebuild is not going to solve this. It is a hack because it does not work on portage/package level. It tries to understand the elf (executable) format and as a result it tries to find libraries and executables (can't find all though, if they are installed at the wrong place) that depend on a particular library. Then it tries to find the package that the dependant library/executable comes from. As however libraries may have unresolved symbols, some libraries (e.g. libapr-util) do not actually state their dependencies. Further revdep-rebuild does not work with downgrades, or with scripts or other things that are not in the elf format. Finally revdep-rebuild needs to scour the filesystem too much. Recording binary dependencies can be used to resolve this. It is however not easy to do. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgp9RhC4YUuuN.pgp Description: PGP signature
Re: [gentoo-portage-dev] DB and binary dependency
On Thursday 16 March 2006 15:24, Brian Harring wrote: I would have called bincompat BINSLOT, but the idea is the same. As per the norm, requires a smart resolver; for c++ would expect cycles to occur where the only solution is to pull in libstdc++ (fex) to sidestep horkage while doing the rebuilds... Don't start about c++. Suppose you have a library A that is build against libstdc++ 5, It contains a class B with a toString method that returns an std::string instance. Next we have application C that extends class B in class D. It (also) redefines the toString method. This application is binary and we don't have (or don't want to use) the source. It was however linked against libstdc++ 6. Question: Which std::string should class D return in it's toString method? The one from libstdc++5 or from libstdc++6 ? (And for a moment disregard the fact that actually the string classes are binary compatible so it doesn't matter). -- answer follows after some lines --- Answer: There is no right answer. We have hit a situation whose solution is undefined. In reality this is solved by the fact that the dynamic linker does not look at which library a particular symbol (read name) is from. With linker symbol versions, what happens is that the types are silently cast. This however breaks runtime type information. We can namely now get the situation where two std::string instances do not actually have the same runtime type. This breaks casting. Fun isn't it. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpTksQAd6Qop.pgp Description: PGP signature
Re: [gentoo-portage-dev] Hello! portage UI
On Tuesday 14 March 2006 17:48, tvali wrote: 2006/3/14, Marius Mauch [EMAIL PROTECTED]: Brian wrote: On Tue, 2006-14-03 at 13:14 +0200, tvali wrote: Ok, i was, yes, speaking about kde. I will check out this Porthole :) I was actually thinking more about c ++, but nothing against python -- i was quite a fan of python when i first found it. I believe Kuroo is in C, maybe c++ For the record: Kuroo is known to be conceptually broken (uses the cache directly), but the author is looking to fix that in a future version. Generally writing portage utils in languages other than python is difficult as you can't use the primary API directly. There seems not to be c++ bintings to python, anyway there is dev-python/sip. I havent done such thing, but i suppose that it would not be impossible to start portage inside Kuroo as a thread, then interact with this thread, having sip between them. If it's used for creation of PyQt, such two-way interaction should be possible. Actually, C++ being strongly related to C, can just use the C python api's. As such it could directly interface with python, and use the python portage api. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpyvIdbNhH88.pgp Description: PGP signature
Re: [gentoo-portage-dev] IUSE_DEFAULTS-v0.1
On Wednesday 15 February 2006 16:48, Alec Warner wrote: Paul de Vrieze wrote: On Tuesday 14 February 2006 13:44, Alec Warner wrote: Well that problem would be, no one wants to modify everything in app-portage/ :). If my portage EAPI is 1, but my tools don't support processing +- in IUSE, how does EAPI help me here? The support check is only for portage_const, so the tool remains fucked. Unless I'm missing something. Tools should also be EAPI aware. I know too many aren't, but that doesn't mean they shouldn't be. Paul I guess my point here is, last I checked we can't pass an EAPI less than portage_const.EAPI. EAPI is not sortable, as such a lower EAPI should have no meaning for anything. Portage supports a welldefined set of EAPI values. The fact that these are based on numbers is because humans like that, portage however needs just see whether that particular version is supported. The portage api should expose the EAPI version of an ebuild, and tools could then map this against their own set of supported EAPI versions. And perhaps also portage could have an api identifier that the tools could also check against. In this example, say portage's EAPI is at 2, but my tool only handles EAPI 0, there is no way to set this in portage so I get EAPI 0 results. So perhaps we need this implemented as well. The first thing would be to just refuse functioning on ebuilds with an unsupported EAPI version. Portage does not itself have an EAPI version. It has a list of supported ebuild EAPI values. Those would in that case be [1, 2, 3]. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgp3OxGrjBcVr.pgp Description: PGP signature
Re: [gentoo-portage-dev] IUSE_DEFAULTS-v0.1
On Tuesday 14 February 2006 13:44, Alec Warner wrote: Well that problem would be, no one wants to modify everything in app-portage/ :). If my portage EAPI is 1, but my tools don't support processing +- in IUSE, how does EAPI help me here? The support check is only for portage_const, so the tool remains fucked. Unless I'm missing something. Tools should also be EAPI aware. I know too many aren't, but that doesn't mean they shouldn't be. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpHwgLSvVTCU.pgp Description: PGP signature
Re: [gentoo-portage-dev] Order of operations: buildpkg
On Tuesday 24 January 2006 14:19, Mike Frysinger wrote: On Tuesday 24 January 2006 03:43, Francesco Riosa wrote: Indeed, could someone shade a light on what happen to /var/db/pkg and world file when using ebuild this manner ? Could be rephrased as Does it act exactly the same way emerge does ? the 'qmerge' step would take care of updating /var/db/pkg -mike And yes it should, except that this does not clean out the /var/tmp/portage/pkgname-version directory. Use the clean command for that. If you find out the results are not the same it's a bug. (Of course package creates a package, which emerge might or might not do based on your config). The package step can also be skipped. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpEaqnF93Dos.pgp Description: PGP signature
Re: [gentoo-portage-dev] Latest version vs specific version
On Friday 02 December 2005 15:43, Andrea Carpani wrote: Hi all. Here's my problem. I'm using a lot binary packages of in portage and custom created ebuilds. I have a virtual ebuild I use that contains only dependencies and I use this one to merge given versions of packages all in one shot: sort of a shanpshot of a given moment in time (sort of tag). Eg: virtual-1.0.ebuild contains RDEPEND= a-2.0.ebuild b-3.0.ebuild c-4.0.ebuild d-5.0.ebuild So that emerge -K virtual-1.0 emerges all a,b,c,d on given versions and: virtual-2.0.ebuild contains RDEPEND= a-2.1.ebuild b-3.1.ebuild c-4.1.ebuild d-5.1.ebuild My problem is that if a-2.0.ebuild and a-2.1.ebuild contain RDEPEND= c-1.0 and I have binary packages for both c-4.0 and c-4.1 when I emerge virtual-2.0.ebuild i get c-4.1.ebuild but if I emerge virtual-1.0 I get both c-4.0 (required as a dependency for virtual-1.0) and c-4.1 (as a dep for a-2.0 who gets the latest c even though c-4.0 would have satisfied the dependency. Any info on how to avoid this? It would a different planner component in portage. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpS7KI6FTa4j.pgp Description: PGP signature
[gentoo-portage-dev] Changelogs
Hi guys, Is there any particular reason that the changelog was dropped from recent portage versions. I'd like to have it to see what changed. Especially with release candidates that sometimes develop issues. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpmwuEq3qrkA.pgp Description: PGP signature
Re: [gentoo-portage-dev] PATCH: gentoolkit: Make portage.config object a global object
On Saturday 17 September 2005 02:32, Alec Warner wrote: Jason Stubbs wrote: On Saturday 17 September 2005 01:59, Paul Varner wrote: http://bugs.gentoo.org/show_bug.cgi?id=90680 Author: Paul Varner The current implementation of gentoolkit creates a portage.config object for every package object that it creates. While this is the correct thing to do from an object-oriented programming point of view, this implementation consumes an excessive amount of memory and CPU. The proposed patch changes the portage.config object for each package object to point to a single global object. If no one sees any serious issues with the patch, I will be placing it into gentoolkit. I tried doing this once before locally, but found some issue with it. Unfortunately, I can't remember what that issue was. If you are calling setcpv() for every call to the package object that utilizes the config object and no utilizing packages (in gentoolkit or otherwise) are utilizing threading, it should theoretically be okay. Actually, I think it was the threading issue that delayed the fix. I can't remember the model for this, but there is some logic along the lines of intercepting config object writes with setattr and then cloning the config object. That way if the config is read-only only 1 is instantiated, but if you attempt to modify it, the config would clone itself, then proceed with the modification and return the cloned copy. Not sure how easy that would be to implement, perhaps some sort of wrapper class? To share such an object the right way from an OO perspective would require to pass the object along at package object instanciation. I doubt though that the config object should be modified. But if it must in some cases a lazy copy scheme is probably most efficient. You'd probably have the editing code do something like: this-editableConfig()-changeAttribute(...) Where the editableConfig function checks whether a copy has been made, if so, it will just use that copy, else it will make a copy and return it. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpDlxwohvwF2.pgp Description: PGP signature
Re: [gentoo-portage-dev] PATCH: gentoolkit: Make portage.config object a global object
On Monday 19 September 2005 10:26, Jason Stubbs wrote: On Monday 19 September 2005 17:18, Paul de Vrieze wrote: I doubt though that the config object should be modified. The Package object needs to call setcpv() on the config object to get at the per-package USE flags after they have been stacked. But if it must in some cases a lazy copy scheme is probably most efficient. Unfortunately not in this case. There would either be one config instance (for processes that don't deal with USE flags) or as many config instances as there are packages (for processes that do). Should probably read the source a bit but you're completely right of course. The only thing that could be done for this is splitting up the object, or having it do internal sharing of shared things. Or to make it clear, it is not some cases, but almost all cases. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgplfCFHSRRMu.pgp Description: PGP signature
Re: [gentoo-portage-dev] PATCH: initial EAPI awareness
On Friday 02 September 2005 07:27, Zac Medico wrote: Paul de Vrieze wrote: On Wednesday 31 August 2005 14:57, Brian Harring wrote: Re: tagging EAPI at the top of a file, infra would probably shoot me for doing such- till a live, fully compatible and *roughly* equivalent parser is available, portage would have to do a bit of grepping, jacking up the regen times. If in cache EAPI can be gotten from the cache. If not, I don't think it matters where in the file EAPI occurs from the standpoint of getting it's value. The only thing would be that in the future a fast EAPI parser could be made that would just look at EAPI and get its version. I could easilly write you such a parser. It is impossible write a parser for an unconstrained and unknown format that may exist in the future. If we put a constraint on the format, in order to parse the EAPI, then we contradict our original goal (to unconstrain the format). It would be possible to make these restrictions small. A workable restriction could be to put the EAPI statement in the front of the file only preceded by whitespace and comments. After the line with the EAPI statement anything could happen. Even a completely binary format could be used. But indeed no constraints is impossible, so putting the format statement in the start of the file is the best solution. Besides the fact that it makes detecting the format that much faster, and allows bailing out before parsing the whole file if an unsupported api is detected. A better approach IMO would be to store the EAPI in a separate file such as metadata.xml. This would allow *absolute* flexibility in the ebuild format. Portage would be able to select an appropriate parser with no need to examine the ebuild itself. Please don't. Parsing xml is a lot harder than recognizing lines. A simple EAPI parser would probably use canned (library) line reading functions and then look if the line starts with EAPI=. If so it reads the EAPI, else it checks the next line. No need to understand anything else of the file format. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgp3kuxMM0HR2.pgp Description: PGP signature
Re: [gentoo-portage-dev] PATCH: initial EAPI awareness
On Friday 02 September 2005 08:04, Brian Harring wrote: Like I've said, EAPI is ebuild specific. Ebuild is a format; eapi defines revisions of it, in my mind a minor revision of the ebuild 1 format. Any form of loss of backwards compatability *should* be a different format, .ebuild2 for all I care. The new proposed format loses backwards compatibility. If there is backwards compatibility no new format or api version is needed. EAPI should work on the python level, not only on the ebuild.sh level. Trying to use EAPI to allow for N different formats into one format is wrong from where I sit; you would need a container format for it, which ebuild wasn't designed for (nor is it easily extensible to be made so I posit). No it would state that the eclass is 100% compatible with both by the formats overlapping and the ebuild not threading outside the overlapped area. Take for an example many simple kde applications. Those use the kde eclass to do all the work and only contain a skeleton of variables themselves. These ebuilds are compatible with both the current as the proposed new API. When marked so, they could be used as EAPI=1 as soon as the kde eclass is ported to EAPI=1. Similarly many eclasses do not provide src_compile, and as such are compatible with both EAPI versions. EAPI's original specification was for handling addition of new funcs, different hooks in the ebuild; I prefer it remain as this. The core rewrite is format agnostic, if a new format is defined (whether a massively managled version of ebuild or flat out new), it's a seperate format and should be handled via the core, not via ebuild specific package handling. EAPI now is going to be used for the above. It can however with very little effort be made such that future ebuild format revisions are possible. Also don't be mistaken that splitting out configure and make stages do need support from the python part. There's no reason a repository can't hold multiple formats internally; the capability is there, use that rather then trying to jam too much into EAPI, imo at least. How would you suggest to do this then. The ebuilds/eclasses are completely the same except for their EAPI definition. They also have the same (file)name. And that is not counting the fact that two files containing the same is bad design as there will allways be an issue of one file being updated and the other not. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpvjqA2Lzlsg.pgp Description: PGP signature
Re: [gentoo-portage-dev] PATCH: initial EAPI awareness
On Saturday 27 August 2005 12:53, Brian Harring wrote: Hola. Attached is a patch that A) adds EAPI awareness to portage; mainly, if 0, complain and be unwilling to merge the package B) tweaks to portage_db_flat, addition of portage_db_metadata, and portage_db_flat_hash I just realised that there are possible issues with incompatble eclasses and ebuilds. What (should) happen(s) when an eclass supports EAPI=1 with src_configure and src_make, while the ebuild supports/expects EAPI=0 with src_compile. This means that in some way eclasses should state which EAPI versions they support. Possibly with making EAPI a space separated list of api's accepted. This would mean some checking in the inherit code AND that EAPI in the ebuild should be defined before the inherit. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgprAJqRnIcTX.pgp Description: PGP signature
