Re: [gentoo-portage-dev] DB and binary dependency

2006-03-26 Thread Paul de Vrieze
 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

2006-03-24 Thread Paul de Vrieze
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

2006-03-24 Thread Paul de Vrieze
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

2006-03-23 Thread Paul de Vrieze
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

2006-03-16 Thread Paul de Vrieze
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

2006-03-16 Thread Paul de Vrieze
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

2006-03-16 Thread Paul de Vrieze
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

2006-03-15 Thread Paul de Vrieze
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

2006-02-16 Thread Paul de Vrieze
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

2006-02-15 Thread Paul de Vrieze
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

2006-01-24 Thread Paul de Vrieze
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

2005-12-02 Thread Paul de Vrieze
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

2005-10-10 Thread Paul de Vrieze

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

2005-09-19 Thread Paul de Vrieze
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

2005-09-19 Thread Paul de Vrieze
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

2005-09-02 Thread Paul de Vrieze
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

2005-09-02 Thread Paul de Vrieze
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

2005-08-29 Thread Paul de Vrieze
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