Re: [gentoo-portage-dev] search functionality in emerge

2008-11-24 Thread tvali
There is one clear problem:

   1. Some other app opens some portage file.
   2. Tree is mounted and indexed.
   3. Other app changes this file.
   4. Index is out-of-date.

To disallow such thing it should be first suggested that all scripts change
portage tree only after mount. As defence against those, which dont listen
to that suggestion, portage should just not use this altered data - portage
should totally rely on it's internal index and when you change some file and
index is not updated, you change should be as well as lost. Does this make
portage tree twice as big as it is?

I guess not, because:

   - Useflags can be indexed and refferred with numbers.
   - Licence, homepage and such data is not needed to be duplicated.

Also, as overlay directories are suggested anyway, is it needed at all to
check *all* files for updates? I think that when one does something wrong,
it's OK when everything goes boom and if someone has update scripts, which
dont use overlays and other suggested ways to do thing, then adding one more
thing, which breaks, is not bad. Hashing those few files isnt bad idea and
keeping internal duplicate of overlay directory is not so bad, too - then
you need to emerge --commithandmadeupdates and that's all.

Some things, which could be used to boost:

   - Dependancy searches are saved - so that emerge -p pck1 pck2 pck3
   saves data about deps of those 3 packages.
   - Package name list is saved.
   - All packages are given integer ID.
   - List of all words in package descriptions are saved and connected to
   their internal ID's. This could be used to make smaller index file. So when
   i search for al, then all words containing those chars like all are
   considered and -S search will run only on those packages.
   - Hash file of whole portage tree is saved to understand if it's changed
   after last remount.

2008/11/24 tvali [EMAIL PROTECTED]

 So, mornings are smarter than evenings (it's Estonian saying) ...at night,
 I thought more about this filesystem thing and found that it simply answers
 all needs, actually. Now I did read some messages here and thought how it
 could be made real simple, at least as I understand this word. Yesterday I
 searched if custom filesystems could have custom functionality and did not
 find any, so I wrote this list of big bunch of classes, which might be
 overkill as I think now.

 First thing about that indexing - if you dont create daemon nor filesystem,
 you can create commands emerge --indexon, emerge --indexoff, emerge
 --indexrenew. Then, index is renewed on emerge --sync and such, but when
 user changes files manually, she has to renew index manually - not much
 asked, isn't it? If someone is going to open the cover of her computer, she
 will take the responsibility to know some basic things about electricity and
 that they should change smth in bios after adding and removing some parts of
 computer. Maybe it should even be emerge --commithandmadechanges, which
 will index or do some other things, which are needed after handmade changes.
 More such things might emerge in future, I guess.

 But about filesystem...

 Consider such thing that when you have filesystem, you might have some
 directory, which you could not list, but where you can read files. Imagine
 some function, which is able to encode and decode queryes into filesystem
 format.

 If you have such function: search(packagename, dependencies) you can
 write it as file path:
 /cgi-bin/search/packagename/dependencies - and packagename can be encoded
 by replacing some characters with some codes and separating long strings
 with /. Also, you could have API, which has one file in directory, from
 where you can read some tmp filename, then write your query to that file and
 read the result from the same or similarly-named file with different
 extension. So, FS provides some ways to create custom queries - actually
 that idea came because there was idea of creating FS as cgi server on LUFS
 page, thus this cgi-bin starting here is to simplify. I think it's similar
 to how files in /dev/ directory behave - you open some file and start
 writing and reading, but this file actually is zero-sized and contains
 nothing.

 Under such case, API could be written to provide this filesystem and
 nothing more. If it is custom-mapped filesystem, then it could provide
 search and such directories, which can be used by portage and others. If
 not, it would work as it used to.

 So, having filesystem, which contains such stuff (i call this subdir dev
 here):

- /dev/search - write your query here and read the result.
- /dev/search/searchstring - another way for user to just read some
listings with her custom script.
- /portage/directory/category/packagename/depslist.dev - contains
dynamic list of package dependencies.
- /dev/version - some integer, which will grow every time any change to
portage tree is made.

 Then, other functions would be added eventually.

 Now

Re: [gentoo-portage-dev] search functionality in emerge

2008-11-24 Thread tvali
2008/11/24 René 'Necoro' Neumann [EMAIL PROTECTED]

 What you mentioned for the filesystem might be a nice thing (actually I
 started something like this some time ago [1] , though it is now dead
 ;)), but it does not help in the index/determine changes thing. It is
 just another API :).


My thoughline is that when this FS is mounted, it's *only *portage dir - so
having this FS mounted, changes are all noticed, because you do all changes
in that FS. Anyway, when you unmount it and remount, some things might go
wrong and that's what I'm thinking about ...but that's not a big problem.

Perhaps the index after sync is sufficient for most parts of the
 userbase - but esp. those who often deal with their own local overlays
 (like me) do not want to have to re-index manually - esp. if re-indexing
 takes a long time. The best solution would be to have portage find a)
 THAT something has been changed and b) WHAT has been changed. So that it
 only has to update these parts of the index, and thus do not be sth
 enerving for the users (remind the Generate Metadata stuff (or
 whatever it was called) in older portage versions, which alone seemed to
 take longer than the rest of the sync progress)

 Regards,
 René

 [1] https://launchpad.net/catapultfs
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v2.0.9 (GNU/Linux)
 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

 iEYEARECAAYFAkkqxSsACgkQ4UOg/zhYFuBPSACdH9H6VChrhlcovucgVAcCsp/B
 j+AAmgPXPmuBs5GWnNAfs5nss4HlBEMT
 =WG8B
 -END PGP SIGNATURE-




-- 
tvali

Kuskilt foorumist: http://www.cooltests.com - kui inglise keelt oskad.
Muide, üle 120 oled väga tark, üle 140 oled geenius, mingi 170 oled ju mingi
täica pea nagu prügikast...


Re: [gentoo-portage-dev] search functionality in emerge

2008-11-23 Thread tvali
 lookup, then you need to
 do some fancy indexing, which I'm not terribly familiar with.  You
 could follow in the steps of eix[1] or other indexed search utilities
 and design some sort of index layout, which is easier than the
 following thought.  You might consider implementing a suffix trie or
 similar that has sublinear regexp lookup and marshalling the structure
 for the index.  I couldn't find a python implementation for something
 like this, but here is a general trie class[2] that you might start
 with if you go that route.  There is a perl module[3],
 Tie::Hash::Regex, that does that, but properly implementing that in
 python would be a chore. :)

 That project sounds interesting and fun. Good luck!

 Lucian Poston

 [1] https://projects.gentooexperimental.org/eix/wiki/IndexFileLayout
 [2]
 http://www.koders.com/python/fid7B6BC1651A9E8BBA547552FE3F039479A4DECC45.aspx
 [3]
 http://search.cpan.org/~davecross/Tie-Hash-Regex-1.02/lib/Tie/Hash/Regex.pmhttp://search.cpan.org/%7Edavecross/Tie-Hash-Regex-1.02/lib/Tie/Hash/Regex.pm





-- 
tvali

Kuskilt foorumist: http://www.cooltests.com - kui inglise keelt oskad.
Muide, üle 120 oled väga tark, üle 140 oled geenius, mingi 170 oled ju mingi
täica pea nagu prügikast...


Re: [gentoo-portage-dev] search functionality in emerge

2008-11-23 Thread tvali
, if
 it does not notice the changes the user made in his own local overlay?
 :) Manually re-indexing is not a good choice I think...

 If somebody comes up here with a good (and fast) solution, this would be
 a nice thing ;) (need it myself).

 Regards,
 René
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v2.0.9 (GNU/Linux)
 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

 iEYEARECAAYFAkkp0kAACgkQ4UOg/zhYFuAhTACfYDxNeQQG6dysgU5TrNEZGOiH
 3CoAn2wV6g8/8uj+T99cxJGdQBxTtZjI
 =2I2j
 -END PGP SIGNATURE-




-- 
tvali

Kuskilt foorumist: http://www.cooltests.com - kui inglise keelt oskad.
Muide, üle 120 oled väga tark, üle 140 oled geenius, mingi 170 oled ju mingi
täica pea nagu prügikast...


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

2006-03-24 Thread tvali
On 24/03/06, Paul de Vrieze [EMAIL PROTECTED] wrote:
 On Thursday 23 March 2006 21:35, tvali wrote:
 
  BINSLOT is a new word for me.

 Ok BINSLOT is normally slot. However in some cases packages are in the
 same slot, but not binary compatible (like their libraries having a
 different SONAME e.g. openssl-0.9.6 and 0.9.7 (iirc)).

 Calculating after build is only for validating configurations. It allows
 one to see whether one can merge binary package A on the current system

Ok, i'm starting to fully understand it :)

So it is something what could be helpful even on other linux systems
than gentoo?

 Header files come from packages that should be mentioned in the
 dependencies.

Yes i'm here thinking about my code-deps :)

 Calculating dependencies automatically is diabolically hard. The fact that
 we have a tree that largely works shows that predicting them works well.
 The reason is that the dependencies are statically defined by the source
 of the package. At those parts where people make mistakes, or the build
 systems are broken, occur the dependencies could be verified by automatic
 tools that check most dependencies. Doing that for native code is easiest
 done by disecting the libraries and executables. For header files,
 inclusion parsing is probably a good approach. But then look at what is
 installed, not what was started with. The reason being that at what is
 installed is no longer dynamic based on a configure script, but totally
 static. The only disadvantage being that this only checks the current
 combination of useflags+context. Many checks by many users would however
 give a good test coverage.

If i can understand you now, then i would think that you didnt
understand me fully. I will write my script, then..

 Not really, with a static library A and a static library B that uses the
 static A, this dependency is only runtime when the interface of B exposes
 the headers of A. If not, one could unmerge both the static library and
 the headers and one could still compile against the library.

I meant headers as .h or .hpp files, which contain function headers.
They're needed, but they are in many cases, included in pack which
uses them, even if that means putting some .h's into all libs.

 Ok, let me clarify. With a binary dependency I mean the actual
 requirements of a package once it has been compiled. In general one could
 say that given a depend atom sys-libs/db-4.* could be statisfied by
 ebuilds in 5 slots: db-4.{0,1,2,3,4}. The sourcecode does not care which
 one is used. However, code compiled agaist db-4.0.14 will not run against
 any libdb-4.{1,2,3,4}.*. This is because these should libraries live in
 different BINSLOT's (in other words, they are incompatible). As these
 libraries have different SLOT's they can coexist though. For a binary
 package therefore it is necessary to record the version of db it was
 actually compiled against. As this might be very strict I also want to
 say that any package within the same BINSLOT with a higher version than
 the one compiled against also works (as it does).

Cant understand it. Do the *headers* change so much through versions?
Is there no backward-compability in so many cases?

 Paul

 --
 Paul de Vrieze
 Gentoo Developer
 Mail: [EMAIL PROTECTED]
 Homepage: http://www.devrieze.net





--
tvali

Measuring programming progress by lines of code is like measuring
aircraft building progress by weight. -Bill Gates

For every complex problem there is an answer that is clear, simple,
and wrong. -H L Mencken

Theory is when you know something, but it doesn't work. Practice is
when something works, but you don't know why. Programmers combine
theory and practice: Nothing works and they don't know why.

http://www.eskimo.com/~hottub/software/programming_quotes.html
http://www.softwarequotes.com/

-- 
gentoo-portage-dev@gentoo.org mailing list



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

2006-03-24 Thread tvali
On 24/03/06, Brian Harring [EMAIL PROTECTED] wrote:
 Checking the interfaces/symbols sucks however, because you can only do
 it _after_ you've built whatever you're building (packages do adjust
 the defines/typedefs/structs dependant on configure/build options).

 As I stated earlier, bincompat (not binslot paul :P) is the route to
 go- it gives you up front information so a resolver can plan out what
 has to be rebuilt automatically.

no-no-no i'm not talking about binary and i will make another thread
when i go further with my own topic :) to use those interfaces, u dont
need to compile anything.

 ~harring

--
tvali

Measuring programming progress by lines of code is like measuring
aircraft building progress by weight. -Bill Gates

For every complex problem there is an answer that is clear, simple,
and wrong. -H L Mencken

Theory is when you know something, but it doesn't work. Practice is
when something works, but you don't know why. Programmers combine
theory and practice: Nothing works and they don't know why.

http://www.eskimo.com/~hottub/software/programming_quotes.html
http://www.softwarequotes.com/

-- 
gentoo-portage-dev@gentoo.org mailing list



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

2006-03-24 Thread tvali
On 24/03/06, Paul de Vrieze [EMAIL PROTECTED] wrote:
 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.

Sorry i thought about it for a moment, then left out later as broken
design cases didnt seems so important. Versioning of distinct
functions would be good, anyway not automatic.

 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.

Ok, assuming broken design it's harder. Anyway, how would binary deps
solve this? This seems to be humans work in all cases.

  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.

Thats true that C# has much more clearness in it's language about what is what.

Anyway, as .h files have become as well as standard, you may show in
code as well as in bin, which functions are needed.

Is there any advantage of bin dep over code dep is a question for me
..some here suggest that there is, i think that everything can be done
as well with code deps.

  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.

I actually know c++, but dont know c. Anyway, what i mean is that if
you have .h files, you may make up automatic check if interfaces fit
each other. I have to think about if c++ is a mess :)

 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.

I think it should be solved with:
// system's header
#include ...
// own header
#include ...

But, yes, not in all cases.

Ok -- i agree that there are several problems, which have to be solved
before taking this topic up again and that they are possibly
unsolvable in many cases and possibly too much work in many others.

 Paul

 --
 Paul de Vrieze
 Gentoo Developer
 Mail: [EMAIL PROTECTED]
 Homepage: http://www.devrieze.net





--
tvali

If I had eight hours to chop down a tree, I'd spend six sharpening my
axe. -Abraham Lincoln

http://www.kuro5hin.org/story/2005/1/28/32622/4244

-- 
gentoo-portage-dev@gentoo.org mailing list



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

2006-03-23 Thread tvali
Can someone tell me, which portage python commands should be used or
which kind of file created, if i'm going to test this idea? -- in
beginning, i would like to just add simple deps - are ebuilds the only
place to change and is there any clear doc of them [as i wouldnt like
to go through them all to be sure that there is no rarely used things i
dont know]?

Also, where i can find relations between useflags and c/c++ #defines?-- tvaliMeasuring programming progress by lines of code is like measuring aircraft building progress by weight. -Bill Gates
For every complex problem there is an answer that is clear, simple, and wrong. -H L MenckenTheory
is when you know something, but it doesn't work. Practice is when
something works, but you don't know why. Programmers combine theory and
practice: Nothing works and they don't know why.http://www.eskimo.com/~hottub/software/programming_quotes.html
http://www.softwarequotes.com/


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

2006-03-23 Thread tvali
On 23/03/06, Alec Warner [EMAIL PROTECTED] wrote:
 tvali wrote:
  Can someone tell me, which portage python commands should be used or
  which kind of file created, if i'm going to test this idea? -- in
  beginning, i would like to just add simple deps - are ebuilds the only
  place to change and is there any clear doc of them [as i wouldnt like to
  go through them all to be sure that there is no rarely used things i
  dont know]?
 
  Also, where i can find relations between useflags and c/c++ #defines?

 USE flags technically have anything to do with C++ defines; they can
 technically enable/disable any optional support ( docs, plugins, etc.. )
 Usually USE flags interact with a packages build system (configure or
 whatnot)


In c++ code, use flags must definitely have something to do with
#defines. Otherwise they couldnt do what they do -- so
uflags=buildsys=defines.

Configure, for example, will define set of #defines.

Ok, your answer at least shows that this relation is not as simple and
clear as i would like it :)

Where i could see some useflag actually interacting with build? Where
i see that line which makes it so that if i define gtk, gtk support
will be added to makefile?

--
tvali

Measuring programming progress by lines of code is like measuring
aircraft building progress by weight. -Bill Gates

For every complex problem there is an answer that is clear, simple,
and wrong. -H L Mencken

Theory is when you know something, but it doesn't work. Practice is
when something works, but you don't know why. Programmers combine
theory and practice: Nothing works and they don't know why.

http://www.eskimo.com/~hottub/software/programming_quotes.html
http://www.softwarequotes.com/

-- 
gentoo-portage-dev@gentoo.org mailing list



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

2006-03-23 Thread tvali
>From Paul de Vrieze:The semantics that make up the relationships between useflags and the actual
source as goes out of the preprocessor is very complicated. Probably theeasiest way to find it out is to try each permutation and somehow hook intogcc/g++ to get the result of that choice.And that's only for C and C++ sources.

Ok, thanks :)

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?

-- tvaliMeasuring programming progress by lines of code is like measuring aircraft building progress by weight. -Bill GatesFor every complex problem there is an answer that is clear, simple, and wrong. -H L Mencken
Theory
is when you know something, but it doesn't work. Practice is when
something works, but you don't know why. Programmers combine theory and
practice: Nothing works and they don't know why.http://www.eskimo.com/~hottub/software/programming_quotes.html
http://www.softwarequotes.com/


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

2006-03-23 Thread tvali
On 23/03/06, Paul de Vrieze [EMAIL PROTECTED] wrote:
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 notdoing 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 sourcepackage 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 dependenciesare relevant (well in gentoo anyway, we don't have initial configurationdeps). Binary packages do however further restrict the configurations from
the runtime dependencies. These restrictions originate from the configurationwhen 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 beextended. Useflag dependencies would be at least usefull. BINSLOT would be
almost required. We already saw that SLOT can't always be used for BINSLOT.
BINSLOT is a new word for me.

I dont see any meaning in calculating dependencies after build. There would be too much problems:
* If any of packages you depend on, are masked, you get an error after build, but should get it before
* In many cases, not only libs, but also headers are included from
another pack [kernel headers, for example, as i have seen from error
messages]
* You cant pre-calculate dependancies

My interest, for sure, is code dependancies. At first i see a clear way
to get it work for now, secondly i think it can be used for bin deps,
also.

In cases, where both headers and libs are included from other pack,
which is same on both cases, this is totally irrelevant for deps if
this other pack is statically or dynamically used.

In cases, where headers are in pack to be compiled and .so is in
another package, i havent yet checked, how to understand if dependancy
is binary -- i cant say for sure that this does not include some work
from user.

Ok, i better write few lines of code now as i know where i should start
(or at least i have one part of code, which could be discussed here, in
front of my minds-eye).

Thanks. You will understand me better when something works :)
Paul--Paul de VriezeGentoo DeveloperMail: 
[EMAIL PROTECTED]Homepage: http://www.devrieze.net-- tvaliMeasuring programming progress by lines of code is like measuring aircraft building progress by weight. -Bill Gates
For every complex problem there is an answer that is clear, simple, and wrong. -H L MenckenTheory
is when you know something, but it doesn't work. Practice is when
something works, but you don't know why. Programmers combine theory and
practice: Nothing works and they don't know why.http://www.eskimo.com/~hottub/software/programming_quotes.html
http://www.softwarequotes.com/


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

2006-03-23 Thread tvali
On 23/03/06, Gustavo Sverzut Barbieri [EMAIL PROTECTED] wrote:
Ok... this discussion is missing my initial point that is how toprovide binary dependency and avoid many crashes we have now withalmost no effort.
Paul was not missing it ;)

Part of his message was for me, part was for you.

I have got my job now so i leave for a while :)
--Gustavo Sverzut Barbieri--Jabber: 
[EMAIL PROTECTED] MSN: [EMAIL PROTECTED]ICQ#: 17249123 Skype: gsbarbieriMobile: +55 (81) 9927 0010 Phone:+1 (347) 624 6296; 
[EMAIL PROTECTED] GPG: 0xB640E1A2 @ wwwkeys.pgp.net--gentoo-portage-dev@gentoo.org
 mailing list-- tvaliMeasuring programming progress by lines of code is like measuring aircraft building progress by weight. -Bill GatesFor every complex problem there is an answer that is clear, simple, and wrong. -H L Mencken
Theory
is when you know something, but it doesn't work. Practice is when
something works, but you don't know why. Programmers combine theory and
practice: Nothing works and they don't know why.http://www.eskimo.com/~hottub/software/programming_quotes.html
http://www.softwarequotes.com/


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

2006-03-22 Thread tvali
I was thinking about it, too, and found something i do like maybe more.
It would be not binary, but code dependancy. This is limited to
specific languages, then, but after all, there may also be different
binary dependencies, too [for example, you may depend on fonts 
images from another package].

Ok, my thought is like that. Lets imagine a simple c file:

#ifdef usepackagex
#include packagex.h
#endif

As it is simple to see, this file could be used to calculate non-binary
dependency, inluding useflags. And there is a plus -- tool, which just
reads those #ifdef's and #includes, could easily understand, which
flags make up which dependancy, without building package again and
again with different useflags. PS. i dont mean X by packagex, but
rather a random pack. I write here as if #define always includes
useflag name - i may be wrong, but it doesnt make a huge difference.
Sure, there are #ifdef's in code, which should not read, so we must
have an array for legal useflags - but this is also not important in my
explanation.

Lets add some custom comment syntax (line numbers are given for explanation):
1. #ifdef usepackagex
2. /* Portage: packagex.h = abc-def/packagex = 1.0.2 */
3. /* Portage: use fonts/customfontpackage */
4. #include packagex.h
5. #endif

Now, what a parser does:

Start parse: setup empty array UseFlags = []

Line 1: #ifdef usepackagex
Add useflag name into useflags array:
UseFlags = ['usepackagex']
Line 2: /* Portage: packagex.h = abc-def/packagex = 1.0.2 */
This line maybe outside of any #ifdef's as well, but in our small application there is no external conf.c file ;)
Dictionary 'Links' will contain a notice that whenever packagex is
included, it must be at least version 1.0.2 of package abc-def/packagex.
Line 3: /* Portage: use fonts/customfontpackage */
Dependancy on fonts/customfontpackage, therefore add to dependancies:
[['usepackagex'], 'fonts/customfontpackage']
Line 4: #include packagex.h
Dependancy on fonts/customfontpackage, therefore add to dependancies:

[['usepackagex'], 'abc-def/packagex = 1.0.2']
Line 5: #endif
Remove 'usepackagex' from useflags:
UseFlags = []
2006/3/22, Gustavo Sverzut Barbieri [EMAIL PROTECTED]:
On 3/20/06, tvali [EMAIL PROTECTED] wrote: 2006/3/20, Gustavo Sverzut Barbieri [EMAIL PROTECTED]:   I do think you're overcomplicating things where you shouldn't.
   Declaring stuff manually will always break, and to ensure a safe  system, it's better to use compiler information. In all cases, dependancy should be based on interfaces, not code.
 All packages may: * Provide an interface * Use an interface Depending on useflags, OS and other compile options, it differs, which interfaces are provided and used.
 This is, abstractly, what portage does with interfaces. If portage uses some interface, it may need it's header files when building. It may also need another lib for static build. This means
 that binary check is not possible in all cases. Now, the problem is: * How to get an information about a package, which specifies exactly, which interface is needed. How to get it before building in case when
 this interface is needed to be emerged before compilation [before linking everything together, at least]. Which is a form of this information and what could be read out from that? * How to get information about which interfaces are provided by which
 packages *not yet emerged* -- by their current use flags(?). This means that it must be possible to know, which interfaces are provided by packages, without first building it -- and the form given by binary
 check must be the same as the form of descriptor used by this package check. So, how to get correct provider together with correct client?Ok, I agree with you that this would be the perfect solution, but it
would demand too much effort to have this right.I'm not proposing the final-perfect solution, just something betterthan we have now. It would not cover every case, but would cover mostcases in a satisfactory way.
--Gustavo Sverzut Barbieri--Jabber: [EMAIL PROTECTED] MSN: [EMAIL PROTECTED]
ICQ#: 17249123 Skype: gsbarbieriMobile: +55 (81) 9927 0010 Phone:+1 (347) 624 6296; [EMAIL PROTECTED] GPG: 0xB640E1A2 @ 
wwwkeys.pgp.net--gentoo-portage-dev@gentoo.org mailing list-- tvaliFrom a programmer's point of view, the user is a peripheral that types when you issue a read request.-P. Williams
If
you think your management doesn't know what it's doing or that your
organisation turns out low-quality software crap that embarrasses you,
then leave.-Ed YourdonWe all agree on the necessity of compromise. We just can't agree on when it's necessary to compromise. -Larry Wall[
http://www.softwarequotes.com/ ] -
http://www.softwarequotes.com/ShowQuotes.asp?ID=544Name=Borenstein,_Nathaniel_S.
-
http://www.softwarequotes.com/ShowQuotes.asp?ID=571Name=Boehm,_Barry


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

2006-03-22 Thread tvali
I hope you did read my previous mail of code dependancy -- if not, it's
at the end of message. This here is not so much overthought thing, but
a good starting point, maybe, if code deps are used.

Anyway, i give here the same idea in more complete form and good syntax
(good, because it could be added to compilers, for example):

/* As compiler may give warnings or errors otherwise, portage code parses defines portage-providers. */
#ifdef runasdaemon

#ifdef portage-providers
#provide interface customdaemon
/* if provided *as*, then does not actually provide anything before include clause */
#use interface daemonheaders 1.0.2 as dhead.h
/* when test.h is included, depends on dev-apps/test at least version 1.0.2 */
#provider-atom test set package=dev-apps/test
#provider-atom test set version=1.0.2
/* require testflag to be set */
#provider-atom test need useflag testflag Hello world!
/* require testflag2 to be unset */
#provider-atom test hate useflag testflag2 Testflag2 bad :(
/* have some good taste in warnings */
#provider-atom test warn useflag testflag3 Test warning!
#provider-atom test ask useflag testflag4 Testflag4 good :)
#use atom test as test.h
#provider-atom otheratom set package=dev-apps/otherpackage
/* if runasdaemon, otheratom will be required */
#use atom otheratom
#endif

#ifdef something

/* if runasdaemon and something, daemonheaders 1.0.2 is needed */
#include dhead.h
/* if runasdaemon and something, atom test is needed */
#include test.h

/* atoms could be provided as well; interface is a simple atom with few params; just test.h could be provided, also: */
#ifdef portage-providers
#provide header welcome.h
#use header someheader.h
#endif

#endif

#endif2006/3/22, tvali [EMAIL PROTECTED]:
I was thinking about it, too, and found something i do like maybe more.
It would be not binary, but code dependancy. This is limited to
specific languages, then, but after all, there may also be different
binary dependencies, too [for example, you may depend on fonts 
images from another package].

Ok, my thought is like that. Lets imagine a simple c file:

#ifdef usepackagex
#include packagex.h
#endif

As it is simple to see, this file could be used to calculate non-binary
dependency, inluding useflags. And there is a plus -- tool, which just
reads those #ifdef's and #includes, could easily understand, which
flags make up which dependancy, without building package again and
again with different useflags. PS. i dont mean X by packagex, but
rather a random pack. I write here as if #define always includes
useflag name - i may be wrong, but it doesnt make a huge difference.
Sure, there are #ifdef's in code, which should not read, so we must
have an array for legal useflags - but this is also not important in my
explanation.

Lets add some custom comment syntax (line numbers are given for explanation):
1. #ifdef usepackagex
2. /* Portage: packagex.h = abc-def/packagex = 1.0.2 */
3. /* Portage: use fonts/customfontpackage */
4. #include packagex.h
5. #endif

Now, what a parser does:

Start parse: setup empty array UseFlags = []

Line 1: #ifdef usepackagex
Add useflag name into useflags array:
UseFlags = ['usepackagex']
Line 2: /* Portage: packagex.h = abc-def/packagex = 1.0.2 */
This line maybe outside of any #ifdef's as well, but in our small application there is no external conf.c file ;)
Dictionary 'Links' will contain a notice that whenever packagex is
included, it must be at least version 1.0.2 of package abc-def/packagex.
Line 3: /* Portage: use fonts/customfontpackage */
Dependancy on fonts/customfontpackage, therefore add to dependancies:
[['usepackagex'], 'fonts/customfontpackage']
Line 4: #include packagex.h
Dependancy on fonts/customfontpackage, therefore add to dependancies:

[['usepackagex'], 'abc-def/packagex = 1.0.2']
Line 5: #endif
Remove 'usepackagex' from useflags:
UseFlags = []
-- tvaliFrom a programmer's point of view, the user is a peripheral that types when you issue a read request.-P. WilliamsIf
you think your management doesn't know what it's doing or that your
organisation turns out low-quality software crap that embarrasses you,
then leave.-Ed YourdonWe all agree on the necessity of compromise. We just can't agree on when it's necessary to compromise. -Larry Wall[
http://www.softwarequotes.com/ ] -
http://www.softwarequotes.com/ShowQuotes.asp?ID=544Name=Borenstein,_Nathaniel_S.
-
http://www.softwarequotes.com/ShowQuotes.asp?ID=571Name=Boehm,_Barry


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

2006-03-22 Thread tvali
2006/3/22, Patrick Lauer [EMAIL PROTECTED]:
There are a few reasons why this won't work :-)First: What if I have assembler? python? perl?Your example is limited to the C preprocessor.
Yes that i did tell there that it's limited to c already :) but bin
dep, after all, is limited to lib dependencies and probably just .so
files -- which means probably not python (as it's too dynamic to
programmatically understand, where and which libs are used), not perl
(as it doesnt have binaries). So i dont see my version being much worse
than bin.

If you have an assembler, then everything depends on which one you
have. If that's internal assembler of c, everything works fine ;) If
that is some macro-assembler, then there is a bit different syntax from
c, but other code is basically the same (parsing needed information out
from assembler code is not too hard).

If that's python, then you cant anymore make it so simple -- there is
nothing like #define in python, as it's dynamic. In python, you have
several ways -- adding dependencies in classical way; adding a *.c
file, which talks about dependancies or making some python script,
which is able to tell on what it depends -- the last way has the same
weakness with bin dep that it should be downloaded before.

About perl, i dont know enough to tell, how it could be used there, but
anyway, as it is scripting language, i think that smth similar to py
applies.

I think that there could be simple dependency builder for packages,
which will be compiled, but not for dynamic languages. There is no
simple way in dynamic languages for knowing, which libs will be used,
even if you know the useflags or have them built into pyc files. As
code deps are only my thought about repairing the biggest bottleneck in
bin-dep - that you cant say anything about deps of a random combination
of flags without rebuilding with excactly that combination -, i am not
trying to make it usable in dynamic/scripting languages.
Second: You'll have to get this depend information applied by upstreamunless you want to patch every file ... and as upstream I'd laugh at
anyone proposing that
This is actually simple build. I just told about method, which would
allow you to include dependancy metadata directly in c code. It could
be compiled into current portage dependancy data as well.
Third: Since there is no easy way of generating this automaticallyyou'll have to replicate every bit of dependency information that is in
the ebuilds. That will be much work, you won't keep ebuilds synchronizedto the included dep info ...
Data in ebuilds should be generated from that data.
So in short, interesting concept, but I don't see how it can work andhow it is an improvement over what we have now. Please don't reinvent
the wheel ;-)
Yes, if it comes to wheels, i better try to invent a better wheel, not reinvent an old wheel ;)

PS. in my last example, i dont show how useflags are related to
#defines. That's because i guess that it must be already described
somewhere and have not to be in c code :) I hope it is so ;)
Patrick--Stand still, and let the rest of the universe move-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.2-ecc0.1.6 (GNU/Linux)iD8DBQBEIZTiqER3hOUoZM4RAkEtAJ913WnthMPjRZrUGQCgYnOw9Xcu7ACeO1DhVKWKYb6XcDuugBJSSBFMgc0==xD2e-END PGP SIGNATURE-
-- tvaliFrom a programmer's point of view, the user is a peripheral that types when you issue a read request.-P. WilliamsIf
you think your management doesn't know what it's doing or that your
organisation turns out low-quality software crap that embarrasses you,
then leave.-Ed YourdonWe all agree on the necessity of compromise. We just can't agree on when it's necessary to compromise. -Larry Wall[
http://www.softwarequotes.com/ ] -
http://www.softwarequotes.com/ShowQuotes.asp?ID=544Name=Borenstein,_Nathaniel_S.
-
http://www.softwarequotes.com/ShowQuotes.asp?ID=571Name=Boehm,_Barry


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

2006-03-22 Thread tvali
As an addition to code deps discussion.

I didnt understand exactly, why bin deps were supposed to be better
than what we have now, as i am not yet exactly sure what we have :)

Anyway, i see one basic plus of code deps. It's that you may have huge
number of codelines, all containing #defines and #ifdefs. You may know
that whenever it uses ?.h header, it needs library ? -- but
when you need ?.h may be somewhat complex case. There may be,
for example, 40 different .h files of your own, which include ?.h file
-- and each of them may be included only if corresponding useflag is
set. In such case, it's easier to describe, which package you need when
?.h is used than to write all those if's twise in code and some
other place, which make sure if you need that ? pack or not.

I havent done such thing in reality, so i dont know, how big problem it
is for a programmer (how much you have that situation i described in
real life), but i guess that this is the problem what binary deps were
supposed to solve.
-- tvaliFrom a programmer's point of view, the user is a peripheral that types when you issue a read request.-P. WilliamsIf
you think your management doesn't know what it's doing or that your
organisation turns out low-quality software crap that embarrasses you,
then leave.-Ed YourdonWe all agree on the necessity of compromise. We just can't agree on when it's necessary to compromise. -Larry Wall[
http://www.softwarequotes.com/ ] -
http://www.softwarequotes.com/ShowQuotes.asp?ID=544Name=Borenstein,_Nathaniel_S.
-
http://www.softwarequotes.com/ShowQuotes.asp?ID=571Name=Boehm,_Barry


Re: [gentoo-portage-dev] Re: User created package lists

2006-03-21 Thread tvali
 What about something along these lines...

 Add the capability for emerge to take a category as an argument, emerge
 www-apps for example, and emerge all packages within that category.
 Optionally make it so this will only work on categories within
 PORTDIR_OVERLAY, or create a new type of overlay, LIST_OVERLAY.

 Then the user can create overlays with their own category names and symlink
 in the package directories they want from the real portage tree.

Yup i thought smth similar, but in my mind those were keywords and
somehow that word broke the thoughtline this time :P

But, yes, masks should be similar [and all other things].

Then there would be several symbolic lists, which may not exist as
files -- those, which portage keeps in portage tree. Or,
alternatively, such a commands, which give it out in common list
format.

Anyway, what makes me worry a bit in such case is the size of that
output -- isn't mask, which contains all package names and versions as
list, too much bigger, than just some boolean/keyword added to common
list? Doesnt such format of overlays, then, make things noticeably
slower?

Maybe it would be best if packages have their default mask marked as
keyword in list, but user can use custom lists and mix them fith some
commands -- mask all packages contained in that list with this
keyword.

It has imho to be kept in mind that automated portage shouldnt become
slower or more complex in that process; lists and their commands must
allow everything portage does right now with few logical commands.

 --
 gentoo-portage-dev@gentoo.org mailing list




--
tvali

From a programmer's point of view, the user is a peripheral that types
when you issue a read request.  -P. Williams

If you think your management doesn't know what it's doing or that your
organisation turns out low-quality software crap that embarrasses you,
then leave.  -Ed Yourdon

We all agree on the necessity of compromise. We just can't agree on
when it's necessary to compromise. -Larry Wall

[ http://www.softwarequotes.com/ ] -
http://www.softwarequotes.com/ShowQuotes.asp?ID=544Name=Borenstein,_Nathaniel_S.
- http://www.softwarequotes.com/ShowQuotes.asp?ID=571Name=Boehm,_Barry

-- 
gentoo-portage-dev@gentoo.org mailing list



[gentoo-portage-dev] Non-root installs

2006-03-19 Thread tvali
Many types of applications, like games, would be installed as normal user as well.

Would it have any point to make portage user-installations into user space?-- tvali(e-mail: [EMAIL PROTECTED]; msn: 
[EMAIL PROTECTED];icq: 317-492-912)I
like net more than life, cause if i do something wrong, then people in
net will tell me that i do, so that i can fix it -- people in life will
tell others that i do.


[gentoo-portage-dev] Locales

2006-03-17 Thread tvali
http://bugs.gentoo.org/show_bug.cgi?id=125264

Most of installation scripts of et locale are broken. Because of that,
i would like some way to configure portage in such way that it starts
with changing locale into english, then installs and then starts locale
back into estonian -- otherwise i have to do so by hand :)

[ there are some my, Tambet's, comments near that bug in topic ]-- tvali(e-mail: [EMAIL PROTECTED]; msn: 
[EMAIL PROTECTED];icq: 317-492-912)I
like net more than life, cause if i do something wrong, then people in
net will tell me that i do, so that i can fix it -- people in life will
tell others that i do.


Re: [gentoo-portage-dev] [PATCH] Manifest2 reloaded

2006-03-16 Thread tvali
Just in case ...what i have to do to test those results


...ps. should i send it here if i have a working c++ class for forking
-- it evolved from that python thought here, which evolved into
general interest to those pipes and interacting with other apps in my
case (which is, as i have understood, important in unix-like
operating systems) ..therefore i encapsulate it into some generic c++
class to do piping and add some error checking, which would give
simple way to use scripting languages, too. i have still not installed
that c++ ide i like, but anyway, Kate is not so bad :) I have it
almost ready but it seems that i have to do some work now for a while
...do i send it here, too, when done or noone needs such thing
anymore? it just runs some command and gives a simple way to send
messages to its stdin and read its stdout so that interacting with
things like python could be simple, too.

2006/3/16, Brian Harring [EMAIL PROTECTED]:
 On Wed, Mar 15, 2006 at 11:14:04PM -0800, Donnie Berkholz wrote:
  Brian Harring wrote:
   python -m timeit -s 's=asdf*400;s+=fdsa.ebuild' 
   's.endswith(.ebuild)'
   100 loops, best of 3: 0.88 usec per loop
 
   python -m timeit -s 's=asdf*400;s+=fdsa.ebuild' 's[-7:] == .ebuild'
   100 loops, best of 3: 0.564 usec per loop
 
   Use endswith
 
   oddly, worth noting that startswith differs in this behaviour...
   python -m timeit -s 's=asdf*400;s+=fdsa.ebuild' 's[:7] == .ebuild'
   100 loops, best of 3: 0.592 usec per loop
 
   python -m timeit -s 's=asdf*400;s+=fdsa.ebuild' 
   's.startswith(.ebuild)'
   100 loops, best of 3: 0.842 usec per loop
 
  Um, those both read the same way to me. You just switched the ordering
  around, so the (starts|ends)with is on the bottom instead of the top,
  but both times (starts|ends)with is longer.

 This is why crack is bad, mm'kay.

 /me lights the pipe and goes back to his corner.

 Pardon, just did a quick test and screwed the results ;)
 ~harring






--
tvali
(e-mail: [EMAIL PROTECTED]; msn: [EMAIL PROTECTED];
icq: 317-492-912)

Ühe eesti internetifirma lehel kohtasin tsitaati:
If you don't do it excellently, dont do it at all. Because if it's not
excellent, it won't be profitable or fun, and if you're not in
business for fun or profit, what the hell are you doing here?
Robert Townsend

-- 
gentoo-portage-dev@gentoo.org mailing list



[gentoo-portage-dev] Portage sqlite support

2006-03-16 Thread tvali
Brian told that portage already has sqlite support.

Where i can find it or how i can turn it on? Is there any bugs or
other reasons to not use it? I would like to support it's code as this
is nr. 1 priority for me right now :)

--
tvali
(e-mail: [EMAIL PROTECTED]; msn: [EMAIL PROTECTED];
icq: 317-492-912)

I like net more than life, cause if i do something wrong, then people
in net will tell me that i do, so that i can fix it -- people in life
will tell others that i do.

-- 
gentoo-portage-dev@gentoo.org mailing list



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

2006-03-16 Thread tvali
 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

All those interfaces and groups could be file links --
lib_interfacegroup_interface1.a would link to libinterface1.a.

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.

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.

 Paul

 --
 Paul de Vrieze
 Gentoo Developer
 Mail: [EMAIL PROTECTED]
 Homepage: http://www.devrieze.net





--
tvali
(e-mail: [EMAIL PROTECTED]; msn: [EMAIL PROTECTED];
icq: 317-492-912)

I like net more than life, cause if i do something wrong, then people
in net will tell me that i do, so that i can fix it -- people in life
will tell others that i do.

-- 
gentoo-portage-dev@gentoo.org mailing list



Re: sync suggestions [was Re: [gentoo-portage-dev] Few things, which imho would make portage better]

2006-03-15 Thread tvali
But if any user-side changes are assumed to be separated?

I mean if there is a boolean field user, which is triggered for
user-changed tables.

Or, to be simpler, i use 2 tables in my example.

Lets assume that user wants to change description of dev-lang/php --
so that user has to change dev-lang/php in table user-tree, but
leave the same in table portage-tree unchanged.

Of course, current example would make queries into portage-db more
complex than they should be, so more optimized version should be found
-- but, anyway, there are ways to make things work.


Imagine that (i take only ebuild files into consideration here):
* Portage tree is kept in SQL base, which contains the following fields:
** Id
** LongName (dev-db/mysql-4.1.14)
** Name (dev-db/mysql)
** ShortName (mysql)
** Slot
** Server -- which server or server group contains that ebuild (if
same ebuild is in several server, it should be repeated in SQL). If
empty, then this ebuild is created by user
** ServerStatus -- false if deleted from server (only used if UserInfo
is not NULL)
** Status -- if false, this row will not be used
** Current -- if this ebuild is what should be installed if emerge
mysql is written on this system
** Description
** /.../ -- other fields parsed from ebuild
** ServerInfo -- ebuild file from server
** UserInfo -- user additions to that file

* Dependency tree
** Will be updated from prev. table

Now, updates in server should be in the following form:
* Id
* ServerInfo
* Action -- add/delete/update

All other fields will be parsed out from Action in user's computer.

Any changes to portage tree will be then done via portage commands,
not directly to SQL.

2006/3/15, Brian Harring [EMAIL PROTECTED]:
 On Tue, Mar 14, 2006 at 03:50:18PM +0200, tvali wrote:
  Another question now is about sync.
 
  I did read somewhere, that this is not good user behavior to sync more
  than once per day. I understand that as if this is a huge download
  even if there is nothing changed.
 
  Isnt it nice idea to have this database just optimized?
 
  I mean (assuming portage using SQL now) -- that would be really simple
  to log every change in portage tree as series of SQL queries, which
  would reproduce this change.

 Pushing the delta (what you're suggesting) is only usable if it can be
 guranteed the user hasn't modified their tree at all (thus resulting
 in cache db differing from upstreams).

 That right there is the brass tacks of it; You wouldn't be able to
 push just the changes, you would have to regenerate the _whole_ db
 (slow, 20k inserts assuming only one table).

 Sidenote... please post seperate threads for seperate
 ideas/discussions, else it's damn hard to look back and pull the
 specific thread were something was discussed.
 ~harring






--
tvali
(e-mail: [EMAIL PROTECTED]; msn: [EMAIL PROTECTED];
icq: 317-492-912)

Ühe eesti internetifirma lehel kohtasin tsitaati:
If you don't do it excellently, dont do it at all. Because if it's not
excellent, it won't be profitable or fun, and if you're not in
business for fun or profit, what the hell are you doing here?
Robert Townsend

-- 
gentoo-portage-dev@gentoo.org mailing list



Re: esearch integration [was Re: [gentoo-portage-dev] Few things, which imho would make portage better]

2006-03-15 Thread tvali
Yes SQL tables are better for that as it's simpler to update them :)

2006/3/15, Brian Harring [EMAIL PROTECTED]:
 On Tue, Mar 14, 2006 at 04:33:06PM +0200, tvali wrote:
  I did think about it now and it seems to me that probably it would be
  much faster if esearch is not just another package, but part of
  portage.
 
  I mean -- functions of portage, which query db, should use esearch
  index wherever they need information, which exists in that index.
 
  As much as i can understand, /var/cache/edb/ contains esearch database
  in many files and esearchdb.py is search index as python script.

 No...
 esearch is a static db- only useful for 'frozen' trees, eg rsync
 distributed trees with no eclasses in overlays.  All cvs users (devs)
 run unfrozen trees (readonly/readwrite is better terminology), thus
 portage updates the cache db on the fly as needed.

 If esearch was integrated into portage the result would be stale
 metadata for cvs users, and stale metadata for rsync users when
 overlays with eclasses are involved- no go.

 That and esearch last I looked just generates a giant dict (thus the
 cache is in memory), which kind of blows the 25mb mem usage 2.1
 now sports :)

 ~harring





--
tvali
(e-mail: [EMAIL PROTECTED]; msn: [EMAIL PROTECTED];
icq: 317-492-912)

Ühe eesti internetifirma lehel kohtasin tsitaati:
If you don't do it excellently, dont do it at all. Because if it's not
excellent, it won't be profitable or fun, and if you're not in
business for fun or profit, what the hell are you doing here?
Robert Townsend

-- 
gentoo-portage-dev@gentoo.org mailing list



Re: portage from C (was Re: [gentoo-portage-dev] Hello! portage UI)

2006-03-15 Thread tvali
sorry
lines
char tt;
for (tt=0; tt40; tt++)
  fputc(tt, inputf);

/.../

fputc(EOF, inputf);

are not needed at all and do nothing -- i was just testing a thought
before i catched how those pipes and forks work in linux :) i have
mostly done things in windows and c++ and WinApi so i dont catch
everything immedietly yet :)

2006/3/16, tvali [EMAIL PROTECTED]:
 So I was the last one :)

 My example is using python interpreter -- it's maybe simpler to use in
 many cases, but theoretically slower.

 It is, anyway, not so advanced to import portage, but you can add that line ;)

 2006/3/15, solar [EMAIL PROTECTED]:
  On Wed, 2006-03-15 at 21:42 +0100, Kevin F. Quinn (Gentoo) wrote:
   On Wed, 15 Mar 2006 09:52:13 -0500
   solar [EMAIL PROTECTED] wrote:
  
On Wed, 2006-03-15 at 10:51 +0100, Paul de Vrieze wrote:
   
[snip]
   
 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.
   
If you could demonstrate an 'import portage' and a simple
printf(PORTDIR=%s\n, PORTDIR); in C I'd be highly interested.
  
   Try attached :)  Had a go 'coz I was curious.  Compile with:
  
   gcc -o getportdir getportdir.c -lpython2.4
  
   Does the equivalent of:
  
   #!/usr/bin/portage
   import portage;
   print portage.settings[PORTDIR];
  
   (more or less).  Docs on the API itself (which comes with Python) are at
   http://docs.python.org/api/api.html
 
  thanks Kevin,
   marienz also put 3 examples together to demonstrate it.
 
  /me feels like a kid in a candy store.
 
  thanks guys.
 
 
  --
  solar [EMAIL PROTECTED]
  Gentoo Linux
 
  --
  gentoo-portage-dev@gentoo.org mailing list
 
 


 --
 tvali
 (e-mail: [EMAIL PROTECTED]; msn: [EMAIL PROTECTED];
 icq: 317-492-912)

 Ühe eesti internetifirma lehel kohtasin tsitaati:
 If you don't do it excellently, dont do it at all. Because if it's not
 excellent, it won't be profitable or fun, and if you're not in
 business for fun or profit, what the hell are you doing here?
 Robert Townsend





--
tvali
(e-mail: [EMAIL PROTECTED]; msn: [EMAIL PROTECTED];
icq: 317-492-912)

Ühe eesti internetifirma lehel kohtasin tsitaati:
If you don't do it excellently, dont do it at all. Because if it's not
excellent, it won't be profitable or fun, and if you're not in
business for fun or profit, what the hell are you doing here?
Robert Townsend

-- 
gentoo-portage-dev@gentoo.org mailing list



Re: [gentoo-portage-dev] Hello! portage UI

2006-03-14 Thread tvali
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'm new to gentoo, so could you tell me, where i find some clear manual for doing the following:
* Download gentoo source of Porthole
* Change that source
* Build my version of it in such way that my portage tree is OK after that

Are --fetchonly and --usepkgonly somehow related to that?
2006/3/14, Brian [EMAIL PROTECTED]:
On Tue, 2006-14-03 at 00:39 +0200, tvali wrote:For KDE there are 2 projects that come to mind Kuroo, and another onethat was designed to run in Konguerer, but I don't remember the name.Kuroo is being actively developed right now, I don't recall seeing
anything recently on the other one.If your thinking of something being coded in python so that it caninteract with and use portage code for information retrieval then checkout Porthole.It is a gtk app not KDE, but will run on a KDE desktop.
It sounds like it already does things similar to what you had in mind.If you wanted to port the gui code from pygtk to pyQt, I am sure thatthere would be a number of KDE users that would be pleased.I would
definitely consider adding an optional KDE interface to it. :)--Brian [EMAIL PROTECTED]--gentoo-portage-dev@gentoo.org
 mailing list-- tvali(e-mail: [EMAIL PROTECTED]; msn: [EMAIL PROTECTED]
;icq: 317-492-912)Ühe eesti internetifirma lehel kohtasin tsitaati:If
you don't do it excellently, dont do it at all. Because if it's not
excellent, it won't be profitable or fun, and if you're not in business
for fun or profit, what the hell are you doing here?Robert Townsend


Re: [gentoo-portage-dev] Few things, which imho would make portage better

2006-03-14 Thread tvali
2006/3/14, Simon Stelling [EMAIL PROTECTED]:
tvali wrote: * Add package to world checking all dependencies, but not emerging * Remove package from world without unmergingUhm, why would you want that?

On my computer, building takes several hours on some packages. I have
used it in such way that it builds in several windows on the same time,
but i guess that that's not at all the best practice, especially with
some combinations of packages. So i would like to add all packages,
seeing all blocks and inter dependencies, then start building when
ready (and go out of home, when it builds, and be sure that it will do
it's best when i'm away).

 * Save all important messages into file instead of beeping (i may be away from home); optionally replay them at end of update
elog can do this.
Will check out.

 * When updating or installing new package, if something goes wrong, still emerge other packages, which havent failed packages as dependencies -- in my
 case, for example, when i do --update, for example, then the fact that update of first package fails does not definitely mean that i dont want to update others--resume

I know --resume, but that's not what i meant.

Imagine the situation:
emerge -p package1 package2

part1 (needed by package1)
part2 (needed by part3)
part3 (needed by package2)
part4 (needed by package2)
part5 (needed by both package1 and package2)
package1
package2

now i start emerge package1 package2 and go to work (or sleep or party or sauna).

part2 fails -- some bug or misconfiguration.

currently it means that when i came back home, i see that part1 is
built, but nothing more and 4-5 hours are actually just wasted.

There should be a way to have all those built when i came home:

part1 (needed by package1)
part4 (needed by package2)

part5 (needed by both package1 and package2)

package1

There should be an error message listing all others. Also, i would add
them to world and then emerge so that --update would try to emerge them
again, asking me about all previously failed packages when i start it,
if i want to retry this time (yes, no, all, none).
--Kind Regards,Simon StellingGentoo/AMD64 Developer--
gentoo-portage-dev@gentoo.org mailing list-- tvali(e-mail: [EMAIL PROTECTED]; msn: 
[EMAIL PROTECTED];icq: 317-492-912)Ühe eesti internetifirma lehel kohtasin tsitaati:If
you don't do it excellently, dont do it at all. Because if it's not
excellent, it won't be profitable or fun, and if you're not in business
for fun or profit, what the hell are you doing here?Robert Townsend


Re: [gentoo-portage-dev] Few things, which imho would make portage better

2006-03-14 Thread tvali
I did think about some priorities too, so that it could be perfect for me.

It should be possible to add package with a priority. I will give you an use case and explanation how i would use portage.

emerge --justadd kdebase-meta kicker --priority 10
emerge --justadd kdenetwork-meta kdeutils-meta kdeadmin-meta --priority 9
emerge --justadd kdeedu-meta kdetoys-meta kdegames-meta kdeartwork-meta --priority 1
emerge --justadd koffice-meta kdegraphics-meta kdemultimedia-meta --priority 5
emerge --justadd kdewebdev-meta kdevelop htmltidy kompare cervisia --priority 7
emerge --justadd kdepim-meta --priority 3
emerge --justadd kdeaddons-meta kde-meta --priority 20
emerge --changepriority kdeaddons-meta kde-meta --priority 0

Now, when i run emerge --update, it should:

* Sort packages in such order that packages with highest priority would be installed as soon as possible
* Start installing
* If something goes wrong, then skip this package and all, which depend
on it. This should be optional, if those, which dont depend on it, but
are needed by same package, will stay in their positions (go to end of
same priority packages) or go to end.

When i need to use my computer and need much resources, i will press ctrl-c, use it, then start (continue) emerge --update.

2006/3/14, tvali [EMAIL PROTECTED]:
2006/3/14, Simon Stelling [EMAIL PROTECTED]:

tvali wrote: * Add package to world checking all dependencies, but not emerging * Remove package from world without unmergingUhm, why would you want that?

On my computer, building takes several hours on some packages. I have
used it in such way that it builds in several windows on the same time,
but i guess that that's not at all the best practice, especially with
some combinations of packages. So i would like to add all packages,
seeing all blocks and inter dependencies, then start building when
ready (and go out of home, when it builds, and be sure that it will do
it's best when i'm away).

 * Save all important messages into file instead of beeping (i may be away
 from home); optionally replay them at end of update
elog can do this.
Will check out.

 * When updating or installing new package, if something goes wrong, still
 emerge other packages, which havent failed packages as dependencies -- in my
 case, for example, when i do --update, for example, then the fact that update of first package fails does not definitely mean that i dont want to update others--resume


I know --resume, but that's not what i meant.

Imagine the situation:
emerge -p package1 package2

part1 (needed by package1)
part2 (needed by part3)
part3 (needed by package2)
part4 (needed by package2)
part5 (needed by both package1 and package2)
package1
package2

now i start emerge package1 package2 and go to work (or sleep or party or sauna).

part2 fails -- some bug or misconfiguration.

currently it means that when i came back home, i see that part1 is
built, but nothing more and 4-5 hours are actually just wasted.

There should be a way to have all those built when i came home:

part1 (needed by package1)
part4 (needed by package2)

part5 (needed by both package1 and package2)

package1

There should be an error message listing all others. Also, i would add
them to world and then emerge so that --update would try to emerge them
again, asking me about all previously failed packages when i start it,
if i want to retry this time (yes, no, all, none).
--Kind Regards,Simon StellingGentoo/AMD64 Developer
--
gentoo-portage-dev@gentoo.org mailing list-- tvali(e-mail: 
[EMAIL PROTECTED]; msn: 
[EMAIL PROTECTED];icq: 317-492-912)Ühe eesti internetifirma lehel kohtasin tsitaati:If
you don't do it excellently, dont do it at all. Because if it's not
excellent, it won't be profitable or fun, and if you're not in business
for fun or profit, what the hell are you doing here?Robert Townsend

-- tvali(e-mail: [EMAIL PROTECTED]; msn: [EMAIL PROTECTED];
icq: 317-492-912)Ühe eesti internetifirma lehel kohtasin tsitaati:If
you don't do it excellently, dont do it at all. Because if it's not
excellent, it won't be profitable or fun, and if you're not in business
for fun or profit, what the hell are you doing here?Robert Townsend


Re: [gentoo-portage-dev] Few things, which imho would make portage better

2006-03-14 Thread tvali
Another place, where it would be good, is that it could interact well with GUI and it's Apply button.

Another thing, what would be imho improved, is the speed of following functions:
* emerge -s, emerge -S
They should be cached somehow.

Also, i think that when speaking about *speed* of portage, which is
imho notably slow right now (speed of searching, building trees and so
on), sql-support should be considered. In /usr/portage/, i see many
folders and files, which tend to contain one or two words, lists of
hashes and so on. Actually i see relational database there. With many
caches and other optimizations it could be tuned fast, but having SQL
doing all that, it would be achieved very simply (maybe it would be a
jump to have all linux configurations in one SQL filesystem? ...ok,
just fantasy:))

There are several small and simple SQL databases. With such tool, big
parts of portage become unnessecary, but it's speed will become much
faster. This should be optional if one uses some tiny sql, mysql or big
clustered sql with nas and load-balancer, but by default some tiny
version of SQL should be built.

Also, i currently dont see a possibility to see dependency tree of installed package.2006/3/14, tvali [EMAIL PROTECTED]:
I did think about some priorities too, so that it could be perfect for me.

It should be possible to add package with a priority. I will give you an use case and explanation how i would use portage.

emerge --justadd kdebase-meta kicker --priority 10
emerge --justadd kdenetwork-meta kdeutils-meta kdeadmin-meta --priority 9
emerge --justadd kdeedu-meta kdetoys-meta kdegames-meta kdeartwork-meta --priority 1
emerge --justadd koffice-meta kdegraphics-meta kdemultimedia-meta --priority 5
emerge --justadd kdewebdev-meta kdevelop htmltidy kompare cervisia --priority 7
emerge --justadd kdepim-meta --priority 3
emerge --justadd kdeaddons-meta kde-meta --priority 20
emerge --changepriority kdeaddons-meta kde-meta --priority 0

Now, when i run emerge --update, it should:

* Sort packages in such order that packages with highest priority would be installed as soon as possible
* Start installing
* If something goes wrong, then skip this package and all, which depend
on it. This should be optional, if those, which dont depend on it, but
are needed by same package, will stay in their positions (go to end of
same priority packages) or go to end.

When i need to use my computer and need much resources, i will press ctrl-c, use it, then start (continue) emerge --update.

2006/3/14, tvali [EMAIL PROTECTED]:

2006/3/14, Simon Stelling [EMAIL PROTECTED]:


tvali wrote: * Add package to world checking all dependencies, but not emerging * Remove package from world without unmergingUhm, why would you want that?

On my computer, building takes several hours on some packages. I have
used it in such way that it builds in several windows on the same time,
but i guess that that's not at all the best practice, especially with
some combinations of packages. So i would like to add all packages,
seeing all blocks and inter dependencies, then start building when
ready (and go out of home, when it builds, and be sure that it will do
it's best when i'm away).

 * Save all important messages into file instead of beeping (i may be away
 from home); optionally replay them at end of update
elog can do this.
Will check out.

 * When updating or installing new package, if something goes wrong, still
 emerge other packages, which havent failed packages as dependencies -- in my
 case, for example, when i do --update, for example, then the fact that update of first package fails does not definitely mean that i dont want to update others--resume



I know --resume, but that's not what i meant.

Imagine the situation:
emerge -p package1 package2

part1 (needed by package1)
part2 (needed by part3)
part3 (needed by package2)
part4 (needed by package2)
part5 (needed by both package1 and package2)
package1
package2

now i start emerge package1 package2 and go to work (or sleep or party or sauna).

part2 fails -- some bug or misconfiguration.

currently it means that when i came back home, i see that part1 is
built, but nothing more and 4-5 hours are actually just wasted.

There should be a way to have all those built when i came home:

part1 (needed by package1)
part4 (needed by package2)

part5 (needed by both package1 and package2)

package1

There should be an error message listing all others. Also, i would add
them to world and then emerge so that --update would try to emerge them
again, asking me about all previously failed packages when i start it,
if i want to retry this time (yes, no, all, none).
--Kind Regards,Simon StellingGentoo/AMD64 Developer
--
gentoo-portage-dev@gentoo.org mailing list-- tvali(e-mail: 

[EMAIL PROTECTED]; msn: 
[EMAIL PROTECTED];icq: 317-492-912)Ühe eesti internetifirma lehel kohtasin tsitaati:If
you don't do it excellently, dont do it at all. Because if it's not
excellent, it won't be profitable or fun

Re: [gentoo-portage-dev] Few things, which imho would make portage better

2006-03-14 Thread tvali
Ok, i send a lot of them, but hopefully they're interesting :)

I did research a bit about adding SQL support to portage -- as much as
i see, mysql is smallest sql server, which could be emerged with
python module.

In beginning, i think that SQL database structure should be created,
which supports basic fields from ebuilds (DESCRIPTION, HOMEPAGE,
SRC_URI, LICENSE, SLOT, KEYWORDS, IUSE, DEPEND, RDEPEND).

Then emerge --createsql command should be set up, which adds data from
/usr/portage/ filetree into this sql database.

Then, portage_db files should be copied into new folder, where queries
will be brought partially into sql. Emerge --usesql should affect
sys.path = [/usr/lib/portage/pym]+sys.path in emerge.py so that user
can control, if she wants to use experimental sql functions. Search
and tree-building are first functions, which should get sql-support,
as they are slowest.

Objective of adding sql support would getting portage search and
pretend functions fast -- so that all real use of portage would be
without long waiting in any place -- only waiting would be in --update
command, then, which could be run when noone is nearby.

I have some questions now:
* Where i could find basic ebuild specification?
* Where i could find basic portage tree datastructure specification,
if there is any?
* Does portage have some code documentation for faster learning?
(or should i just read the code?)

I think that i will start with sql support, then go to UI -- as sql
support seems to have far more important functionality.

I would like to build sql table-structure after getting the
information and send it into this list here so that you could hek out
if it has something missing or poorly optimized. PS. i dont like rules
of database normalizing, so my strutures usually have some hacks in
them -- i hope that noone complains about that; normalized structures
are just dull and optimized only for dumb-user-human-readability,
which is imho not the biggest virtue of software code.

2006/3/14, tvali [EMAIL PROTECTED]:
 Another place, where it would be good, is that it could interact well with 
 GUI and it's Apply button.

  Another thing, what would be imho improved, is the speed of following 
 functions:
  * emerge -s, emerge -S
  They should be cached somehow.

  Also, i think that when speaking about *speed* of portage, which is imho 
 notably slow right now (speed of searching, building trees and so on), 
 sql-support should be considered. In /usr/portage/, i see many folders and 
 files, which tend to contain one or two words, lists of hashes and so on. 
 Actually i see relational database there. With many caches and other 
 optimizations it could be tuned fast, but having SQL doing all that, it would 
 be achieved very simply (maybe it would be a jump to have all linux 
 configurations in one SQL filesystem? ...ok, just fantasy:))

  There are several small and simple SQL databases. With such tool, big parts 
 of portage become unnessecary, but it's speed will become much faster. This 
 should be optional if one uses some tiny sql, mysql or big clustered sql with 
 nas and load-balancer, but by default some tiny version of SQL should be 
 built.

  Also, i currently dont see a possibility to see dependency tree of installed 
 package.



 2006/3/14, tvali [EMAIL PROTECTED]:
   I did think about some priorities too, so that it could be perfect for me.
 
   It should be possible to add package with a priority. I will give you an 
  use case and explanation how i would use portage.
 
   emerge --justadd kdebase-meta kicker --priority 10
   emerge --justadd kdenetwork-meta kdeutils-meta kdeadmin-meta --priority 9
   emerge --justadd kdeedu-meta kdetoys-meta kdegames-meta kdeartwork-meta 
  --priority 1
   emerge --justadd koffice-meta kdegraphics-meta kdemultimedia-meta 
  --priority 5
   emerge --justadd kdewebdev-meta kdevelop htmltidy kompare cervisia 
  --priority 7
   emerge --justadd  kdepim-meta --priority 3
   emerge --justadd kdeaddons-meta kde-meta --priority 20
   emerge --changepriority kdeaddons-meta kde-meta --priority 0
 
   Now, when i run emerge --update, it should:
 
   * Sort packages in such order that packages with highest priority would be 
  installed as soon as possible
   * Start installing
   * If something goes wrong, then skip this package and all, which depend on 
  it. This should be optional, if those, which dont depend on it, but are 
  needed by same package, will stay in their positions (go to end of same 
  priority packages) or go to end.
 
   When i need to use my computer and need much resources, i will press 
  ctrl-c, use it, then start (continue) emerge --update.
 
 
  2006/3/14, tvali [EMAIL PROTECTED]:
 
2006/3/14, Simon Stelling [EMAIL PROTECTED]:
  
   tvali wrote:
 * Add package to world checking all dependencies, but not emerging
 * Remove package from world without unmerging
   
Uhm, why would you want that?
   
  
  
On my computer, building takes

Re: [gentoo-portage-dev] Few things, which imho would make portage better

2006-03-14 Thread tvali
Thank you much!

This is what i meant about searching :) Would it be now good to mix
this esearch code with emerge, then adding fields to db and making
emerge treebuilding fast, too? Or is there some utility to emerge,
which does all that?

2006/3/14, Devon Miller [EMAIL PROTECTED]:
 Try emerge esearch. Replace emerge --sync with esync, emerge -s with
 esearch, and emerge -S with esearch -S.
 After running emerge --update ..., run eupdatedb.

 As for dependency tree: emerge --pretend --tree world
 Or, to also check additional dependencies: emerge --deep --pretend --tree
 world
 And, if you want to see how *everything* relates: emerge --deep --emptytree
 --pretend --tree

 dcm



 On 3/14/06, tvali [EMAIL PROTECTED] wrote:
 
  Another place, where it would be good, is that it could interact well with
 GUI and it's Apply button.
 
  Another thing, what would be imho improved, is the speed of following
 functions:
  * emerge -s, emerge -S
  They should be cached somehow.
 
  Also, i think that when speaking about *speed* of portage, which is imho
 notably slow right now (speed of searching, building trees and so on),
 sql-support should be considered. In /usr/portage/, i see many folders and
 files, which tend to contain one or two words, lists of hashes and so on.
 Actually i see relational database there. With many caches and other
 optimizations it could be tuned fast, but having SQL doing all that, it
 would be achieved very simply (maybe it would be a jump to have all linux
 configurations in one SQL filesystem? ...ok, just fantasy:))
 
  There are several small and simple SQL databases. With such tool, big
 parts of portage become unnessecary, but it's speed will become much faster.
 This should be optional if one uses some tiny sql, mysql or big clustered
 sql with nas and load-balancer, but by default some tiny version of SQL
 should be built.
 
  Also, i currently dont see a possibility to see dependency tree of
 installed package.
 
 
 
  2006/3/14, tvali  [EMAIL PROTECTED]:
   I did think about some priorities too, so that it could be perfect for
 me.
  
   It should be possible to add package with a priority. I will give you an
 use case and explanation how i would use portage.
  
   emerge --justadd kdebase-meta kicker --priority 10
   emerge --justadd kdenetwork-meta kdeutils-meta kdeadmin-meta --priority
 9
   emerge --justadd kdeedu-meta kdetoys-meta kdegames-meta kdeartwork-meta
 --priority 1
   emerge --justadd koffice-meta kdegraphics-meta kdemultimedia-meta
 --priority 5
   emerge --justadd kdewebdev-meta kdevelop htmltidy kompare cervisia
 --priority 7
   emerge --justadd  kdepim-meta --priority 3
   emerge --justadd kdeaddons-meta kde-meta --priority 20
   emerge --changepriority kdeaddons-meta kde-meta --priority 0
  
   Now, when i run emerge --update, it should:
  
   * Sort packages in such order that packages with highest priority would
 be installed as soon as possible
   * Start installing
   * If something goes wrong, then skip this package and all, which depend
 on it. This should be optional, if those, which dont depend on it, but are
 needed by same package, will stay in their positions (go to end of same
 priority packages) or go to end.
  
   When i need to use my computer and need much resources, i will press
 ctrl-c, use it, then start (continue) emerge --update.
  
  
   2006/3/14, tvali [EMAIL PROTECTED]:
  
2006/3/14, Simon Stelling [EMAIL PROTECTED]:
   
 tvali wrote:
  * Add package to world checking all dependencies, but not
 emerging
  * Remove package from world without unmerging

 Uhm, why would you want that?

   
   
On my computer, building takes several hours on some packages. I have
 used it in such way that it builds in several windows on the same time, but
 i guess that that's not at all the best practice, especially with some
 combinations of packages. So i would like to add all packages, seeing all
 blocks and inter dependencies, then start building when ready (and go out of
 home, when it builds, and be sure that it will do it's best when i'm away).
   
   
  * Save all important messages into file instead of beeping (i may
 be away
  from home); optionally replay them at end of update

 elog can do this.
   
   
Will check out.
   
   
  * When updating or installing new package, if something goes
 wrong, still
  emerge other packages, which havent failed packages as
 dependencies -- in my
  case, for example, when i do --update, for example, then the fact
 that
  update of first package fails does not definitely mean that i dont
 want to
  update others

 --resume
   
   
I know --resume, but that's not what i meant.
   
Imagine the situation:
emerge -p package1 package2
   
part1 (needed by package1)
part2 (needed by part3)
part3 (needed by package2)
part4 (needed by package2)
part5 (needed by both package1 and package2)
package1

Re: [gentoo-portage-dev] Few things, which imho would make portage better

2006-03-14 Thread tvali
 You're talking about the cache, take a look at the cache subsystem and
 write a mysql module for it. This will never become a default though (we
 would get killed if portage starts to depend on mysql).

I think that it should not become default as mysql module, but if it
is working, it should become default as portable sql module.

# emerge sqlite pysqlite

I havent used sqlite, but it seems to be small and usable. I think
that it should start with it.

I think that portage should *support* sql by default, but of course it
should not be default before it's clear that many people like it and
use it. What is imho more important is how to make one usable
interface, which would cover both fs and sql portage db's so that
development didnt go into two products.

--
tvali
(e-mail: [EMAIL PROTECTED]; msn: [EMAIL PROTECTED];
icq: 317-492-912)

Ühe eesti internetifirma lehel kohtasin tsitaati:
If you don't do it excellently, dont do it at all. Because if it's not
excellent, it won't be profitable or fun, and if you're not in
business for fun or profit, what the hell are you doing here?
Robert Townsend

-- 
gentoo-portage-dev@gentoo.org mailing list



Re: [gentoo-portage-dev] Few things, which imho would make portage better

2006-03-14 Thread tvali
2006/3/14, Alec Warner [EMAIL PROTECTED]:
 tvali wrote:
  Ok, i send a lot of them, but hopefully they're interesting :)
 
  I would like to build sql table-structure after getting the
  information and send it into this list here so that you could hek out
  if it has something missing or poorly optimized. PS. i dont like rules
  of database normalizing, so my strutures usually have some hacks in
  them -- i hope that noone complains about that; normalized structures
  are just dull and optimized only for dumb-user-human-readability,
  which is imho not the biggest virtue of software code.

 Uhhh you don't like normalizing your schemas?  Normalizing does two
 things, reduces redundant data, and increases database speed as tables
 are designed in a manner that minimalizes merging time.

I will consider what you sayd about db app design.

Anyway, i usually try to keep tables more dynamic and look at task at
hand, trying to make tables specially for it. When i tested
normalizing, i got about 60 tables where i had 5 without normalizing.
I didnt build both and test speed, but i have believed that indexing
tables makes them fast, too. In that specific case about 40 of those
tables were very similar and i did join them a bit and made some
multifunctinal fields, others were about connections between tables,
which i did put into one table. In that case, which i am talking
about, code, which used those tables, were just a lot simpler and
shorter, when tables were built in such way, also i didnt have to fear
that when i need to do mixed searches or other things like that, code
gets complex. I think that looking database structures without
considering normalizing rules gives much -- only this db app
optimization, which you mentioned, may really make normalized tables
better in some cases (and i still hope that there is a way out as i
couldnt understand, why one makes such a powerful language as SQL just
to deny most of it's beauty afterwards :D).

 Running with a schema you pulled out of your ass is likely to give poor
 database performance.

 -Alec Warner





--
tvali
(e-mail: [EMAIL PROTECTED]; msn: [EMAIL PROTECTED];
icq: 317-492-912)

Ühe eesti internetifirma lehel kohtasin tsitaati:
If you don't do it excellently, dont do it at all. Because if it's not
excellent, it won't be profitable or fun, and if you're not in
business for fun or profit, what the hell are you doing here?
Robert Townsend

-- 
gentoo-portage-dev@gentoo.org mailing list



Re: [gentoo-portage-dev] Few things, which imho would make portage better

2006-03-14 Thread tvali
2006/3/14, Brian [EMAIL PROTECTED]:
 On Tue, 2006-14-03 at 16:33 +0200, tvali wrote:
 If I recall, (there has been lots of discussion about converting portage
 to use databases, just check the mail archives and forum) portage
 already has sqlite support, but is not yet used.  Sqlite is smaller and
 has less dependencies than mysql.

How to use sqlite support in portage?

 Also, many of the features you talked about are already implemented in
 porthole,  such as continuing after a failed package, filtering out
 warnings, important messages, etc..

 Check it out.

Is this ok:
!!! All ebuilds that could satisfy porthole have been masked.
Or is there any, which is not masked?

And -- if portage is meant as main engine and porthole as it's gui,
isnt it a bit fuzzy to add speed-ups to porthole instead of portage?
If it continues like that, it may end up with someone writing
command-line tool for controlling porthole :P I think that if
application has 2 layers, one for logic and another for GUI, then it's
maybe not the best way of coding to add such kind of features to GUI
part of package. I personally would definitely try to make portage
itself support indexing and other such stuff to keep things clean. Am
i wrong? Or is it in plans to make gentoo a GUI linux with very weak
command-line support?

I think that GUI code would be *clean* if it's just a GUI!

 --
 Brian [EMAIL PROTECTED]

 --
 gentoo-portage-dev@gentoo.org mailing list




--
tvali
(e-mail: [EMAIL PROTECTED]; msn: [EMAIL PROTECTED];
icq: 317-492-912)

Ühe eesti internetifirma lehel kohtasin tsitaati:
If you don't do it excellently, dont do it at all. Because if it's not
excellent, it won't be profitable or fun, and if you're not in
business for fun or profit, what the hell are you doing here?
Robert Townsend

-- 
gentoo-portage-dev@gentoo.org mailing list



Re: [gentoo-portage-dev] Few things, which imho would make portage better

2006-03-14 Thread tvali
I didnt think of case Item1, Item2, Item3.

I thought of cases, for example, where i use Id field as TableName and
IdInThatTable, where TableName shows, which table this IdInThatTable
points and so on. I dont use, too, Item1/2/3 :) I just use tables
sometimes in a more generalized form, where it's hard to say from
table name or fields, what it is supposed to contain, as it contains
different things in different cases -- therefore allowing me to make
more functionality to general datastructures rather than writing
specific tables with specific functions. Anyway, this is an example --
i just think that normalizing makes it so that there is 1 way to do
things, but i like to rethink any specific case (and in some cases,
normalized table just appears best to me, but not because it's
normalized). Nothing more. Anyway, i think that this is not a topic to
discuss in this list :) I think that db-app otimizations was best
argument ever possible on side of normalization -- others are those,
which will appear to me, too, but i havent much thought about which
db's are optimized to which structures -- and this seems so that as
normalization is in, any engines probably really are optimized for
that.

2006/3/14, Johannes Fahrenkrug [EMAIL PROTECTED]:
 tvali wrote:

 I will consider what you sayd about db app design.
 
 Anyway, i usually try to keep tables more dynamic and look at task at
 hand, trying to make tables specially for it. When i tested
 normalizing, i got about 60 tables where i had 5 without normalizing.
 
 
 I'm not a Gentoo dev, but a programmer who deals with software and db
 design issues every day.
 Normalizing your data structures keeps them - and the apps that use them
 - flexible.

 Of course a table with fields like customernr, customername, item1,
 item2, item3 is easier to create and smaller
 than one table for the customers and one for items. But what if there's
 a 4th and a 5th item? You have to change
 your table and every place in your app that uses it (which should only
 be one).

 I assume you're also not too fond of design patterns because some
 require you to create 5 classes for something you could do with one ;-)...

 - Johannes.


 --
 gentoo-portage-dev@gentoo.org mailing list




--
tvali
(e-mail: [EMAIL PROTECTED]; msn: [EMAIL PROTECTED];
icq: 317-492-912)

Ühe eesti internetifirma lehel kohtasin tsitaati:
If you don't do it excellently, dont do it at all. Because if it's not
excellent, it won't be profitable or fun, and if you're not in
business for fun or profit, what the hell are you doing here?
Robert Townsend

-- 
gentoo-portage-dev@gentoo.org mailing list



Re: [gentoo-portage-dev] Few things, which imho would make portage better

2006-03-14 Thread tvali
2006/3/14, solar [EMAIL PROTECTED]:
 On Tue, 2006-03-14 at 15:50 +0200, Marius Mauch wrote:
  Heh, make the dep resolver even more complex ;)
  Also don't really see a need for such a feature, pretty much no benefit
  with a lot of additional complexity.

 agreed.

Ok, but if making it layered (several layers or passes). To explain
my thought about how they should be sorted:

Layer 1 would calculate real dependencies of packages -- using current
use flags. Those dependencies would also be saved into portage tree
after calculating (--newuse would update them).

Layer 2 would be used to make a list of all packages, which would be
installed right now -- this happens when some emerge or pretend is
being done.

Layer 3 would only use those calculated dependencies and
ready-selected list of packages and sort them.

One possible sort would look like that:

* Packages, which have given importance, will have this importance
forever -- it will be written to world.
* When sorting packages, only those, which are directly in world, will
be considered -- dependancies are installed as late as possible.

It should be enough:
1. Make list
2. Add all packages, starting with those, which have higher priority
3. Add their dependencies, trying to put any of them right before the
first package, which needs them (more advanced sorting would use also
default priorities of dependancies -- putting them before first
package, which needs them, and after last package, which has bigger
importance than this first package)

Any other sort optimizations would be unnessecary as user can just use
right priority numbers to get everything ok with this type of sorting.

Sorting is good especially when user makes a long list of packages and
then starts to emerge them at once.

In my case i did install gentoo only at daytime, having my computer
off at nights (as i dont like it's sound in my room when i sleep). It
took several days -- and i started to use it right after getting it
up; i started also using kde right after it included kicker, konqueror
and konsole. I wanted to install graphics, toys and other such things
as last thing. And i didnt want to make pauses between emerges, but
had, because i wasnt always there, when one emerge was finished (as
they took hours).

--
tvali
(e-mail: [EMAIL PROTECTED]; msn: [EMAIL PROTECTED];
icq: 317-492-912)

Ühe eesti internetifirma lehel kohtasin tsitaati:
If you don't do it excellently, dont do it at all. Because if it's not
excellent, it won't be profitable or fun, and if you're not in
business for fun or profit, what the hell are you doing here?
Robert Townsend

-- 
gentoo-portage-dev@gentoo.org mailing list



Re: [gentoo-portage-dev] Hello! portage UI

2006-03-14 Thread tvali
I looked over that:

SIP also makes it easy to take a Python application (maybe a
prototype) and selectively implement parts of the application (maybe
for performance reasons) in C or C++.

This could mean that portage could be made fully compatible with c++
app? Again, havent tried/tested, just assuming :)

2006/3/14, tvali [EMAIL PROTECTED]:
 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.

 http://www.riverbankcomputing.co.uk/sip/index.php

  Marius
  --
  gentoo-portage-dev@gentoo.org mailing list
 
 


 --
 tvali
 (e-mail: [EMAIL PROTECTED]; msn: [EMAIL PROTECTED];
 icq: 317-492-912)

 Ühe eesti internetifirma lehel kohtasin tsitaati:
 If you don't do it excellently, dont do it at all. Because if it's not
 excellent, it won't be profitable or fun, and if you're not in
 business for fun or profit, what the hell are you doing here?
 Robert Townsend



--
tvali
(e-mail: [EMAIL PROTECTED]; msn: [EMAIL PROTECTED];
icq: 317-492-912)

Ühe eesti internetifirma lehel kohtasin tsitaati:
If you don't do it excellently, dont do it at all. Because if it's not
excellent, it won't be profitable or fun, and if you're not in
business for fun or profit, what the hell are you doing here?
Robert Townsend

-- 
gentoo-portage-dev@gentoo.org mailing list



Re: [gentoo-portage-dev] Few things, which imho would make portage better

2006-03-14 Thread tvali
Ok, i think i have reasonable amount of information to start something
now :) As a last question -- what i do after some additions to
portage? Send it where?

2006/3/14, tvali [EMAIL PROTECTED]:
 2006/3/14, solar [EMAIL PROTECTED]:
  On Tue, 2006-03-14 at 15:50 +0200, Marius Mauch wrote:
   Heh, make the dep resolver even more complex ;)
   Also don't really see a need for such a feature, pretty much no benefit
   with a lot of additional complexity.
 
  agreed.

 Ok, but if making it layered (several layers or passes). To explain
 my thought about how they should be sorted:

 Layer 1 would calculate real dependencies of packages -- using current
 use flags. Those dependencies would also be saved into portage tree
 after calculating (--newuse would update them).

 Layer 2 would be used to make a list of all packages, which would be
 installed right now -- this happens when some emerge or pretend is
 being done.

 Layer 3 would only use those calculated dependencies and
 ready-selected list of packages and sort them.

 One possible sort would look like that:

 * Packages, which have given importance, will have this importance
 forever -- it will be written to world.
 * When sorting packages, only those, which are directly in world, will
 be considered -- dependancies are installed as late as possible.

 It should be enough:
 1. Make list
 2. Add all packages, starting with those, which have higher priority
 3. Add their dependencies, trying to put any of them right before the
 first package, which needs them (more advanced sorting would use also
 default priorities of dependancies -- putting them before first
 package, which needs them, and after last package, which has bigger
 importance than this first package)

 Any other sort optimizations would be unnessecary as user can just use
 right priority numbers to get everything ok with this type of sorting.

 Sorting is good especially when user makes a long list of packages and
 then starts to emerge them at once.

 In my case i did install gentoo only at daytime, having my computer
 off at nights (as i dont like it's sound in my room when i sleep). It
 took several days -- and i started to use it right after getting it
 up; i started also using kde right after it included kicker, konqueror
 and konsole. I wanted to install graphics, toys and other such things
 as last thing. And i didnt want to make pauses between emerges, but
 had, because i wasnt always there, when one emerge was finished (as
 they took hours).

 --
 tvali
 (e-mail: [EMAIL PROTECTED]; msn: [EMAIL PROTECTED];
 icq: 317-492-912)

 Ühe eesti internetifirma lehel kohtasin tsitaati:
 If you don't do it excellently, dont do it at all. Because if it's not
 excellent, it won't be profitable or fun, and if you're not in
 business for fun or profit, what the hell are you doing here?
 Robert Townsend



--
tvali
(e-mail: [EMAIL PROTECTED]; msn: [EMAIL PROTECTED];
icq: 317-492-912)

Ühe eesti internetifirma lehel kohtasin tsitaati:
If you don't do it excellently, dont do it at all. Because if it's not
excellent, it won't be profitable or fun, and if you're not in
business for fun or profit, what the hell are you doing here?
Robert Townsend

-- 
gentoo-portage-dev@gentoo.org mailing list



[gentoo-portage-dev] Hello! portage UI

2006-03-13 Thread tvali
Hello!

I am thinking about making user interface for portage.

I see the possibility to browse portage tree, turning different filters
on and off, as it's most important feature. I dont think that it should
contain any functions for updating, emerging or unmerging or syncing at
it's beginning, as i think that i havent used portage long enough to
make a clear design of such a tool.

Anyway, package browser would be usable for me as a new user of portage.

I describe shortly, what i see as it's functionality:
* General UI, which looks like a classical e-mail client with
folder-list on left panel, mail-list on top and one e-mail on bottom.
Additionally, top and bottom panel should be together in right panel.
* Left panel contains 2 main folders -- one is to access folders in
/usr/portage/, another contains keywords like kdebase-meta (or
kde-base) -- which has packages like kdegraphics-meta inside it (click
+). This other tree should be hand-made tree + others folder, last
containing all package groups, which are not included in this tree. At
least, i think that automation may not be possible -- it depends on
structure, which i dont know.
* Right panel, which contains tabs -- first tab is for top/bottom panels, other are web browsers (konqueror).
* Top panel contains package list like detailed view of folders
* Botton panel contains details -- also button for opening www-address of package in new tab.
+ there should be search feature.
+ some special folders should be added: --update world, which contains
all outdated packages jpc. As it would be slow, portage or this UI
should be cache such things and clean this cache when --sync happens.

It is possible that integration into Konqueror could be simple and usable (like portage:/ protocol).

In future, additional features like tray-icon for autosync and
notifications, also adding packages to world and removing, could be
considered; code should be build in such way that is would be possible
to add them later in different ways.
-- tvali(e-mail: [EMAIL PROTECTED]; msn: [EMAIL PROTECTED];icq: 317-492-912)Ühe eesti internetifirma lehel kohtasin tsitaati:
If
you don't do it excellently, dont do it at all. Because if it's not
excellent, it won't be profitable or fun, and if you're not in business
for fun or profit, what the hell are you doing here?Robert Townsend