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

[tvali]

I take it shortly together as Rene didn't catch all and so I was fuzzy:

Portage tree has automatically updateable parts, which should not changed by
user, and overlay, which will be. Thus, index of this automatic part should
be updated only after "emerge --sync".

Speedup should contain custom filesystem, which would be called PortageFS,
for example. In initial version, PortageFS uses current portage tree and
generates additional indexes.

So, when you bootup, you have portage tree in /usr/portage. At some point,
PortageFS is mounted into the same directory, /usr/portage. It will map real
/usr/portage directory into /usr/portage mount point and create some
additional folders like /usr/portage/search, which maps files to do real
searches. /usr/portage/handler would be a file, where you can write query
and read result. It also contains virtual files to check dependancies and
such stuff - many things you could use with your scripts.

When it's mounted, every change is noticed and indexes will be automagically
updated (and sometimes after communication with portage - for example,
updates when doing "emerge --sync" should not happen automagically maybe, as
it makes things slower. When it's not mounted, you can change user files,
but must run some notification script afterwards maybe to rebuild indexes.

Indexes are built-in into FS.

If PortageFS is not mounted, for example because of some emergency reboot,
portage can work without indexes, using real directory instead of this mount
point.

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

[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

[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 

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

[tvali]

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, things simple:

   - Create standard filesystem, which can be used to contain portage tree.
   - Add all nessecary notifications to change and update files.
   - *Mount this filesystem to the same dir, where actual files are placed -
   if it's not mounted, portage will almost not notice this (so in emergency,
   things are just slower). You can navigate to a directory, then mount new one
   - I am not on linux box right now, but if I remember correctly, you can use
   files in real directory after mounting smth other there in such way.*
   - Create indexes and other stuff.

2008/11/24 Fabian Groffen <[EMAIL PROTECTED]>

> On 24-11-2008 10:34:28 +0100, René 'Necoro' Neumann wrote:
> > tvali schrieb:
> > > There is daemon, which notices about filesystem changes -
> > > http://pyinotify.sourceforge.net/ would be a good choice.
> >
> > Disadvantage: Has to run all the time (I see already some people crying:
> > "oh noez. not yet another daemon...").
>
> ... and it is Linux only, which spoils the fun.
>
>
> --
> Fabian Groffen
> Gentoo on a different level
>
>


-- 
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

[tvali]

ether there has been a change to the ebuild system is a
> major point in the whole thing. What does a great index serves you, 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] search functionality in emerge

[tvali]

lass's
>> execute() method simply iterates over all packages (and descriptions
>> and package sets) and matches against the searchkey.  You might need
>> to look into pym/portage/dbapi/porttree.py for portdbapi as well.
>>
>> If you intend to index and support fast regex 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.pm<http://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

[tvali]

Try esearch.

emerge esearch
esearch ...

2008/11/23 Emma Strubell <[EMAIL PROTECTED]>

> Hi everyone. My name is Emma, and I am completely new to this list. I've
> been using Gentoo since 2004, including Portage of course, and before I say
> anything else I'd like to say thanks to everyone for such a kickass package
> management system!!
>
> Anyway, for my final project in my Data Structures & Algorithms class this
> semester, I would like to modify the search functionality in emerge.
> Something I've always noticed about 'emerge -s' or '-S' is that, in general,
> it takes a very long time to perform the searches. (Although, lately it does
> seem to be running faster, specifically on my laptop as opposed to my
> desktop. Strangely, though, it seems that when I do a simple 'emerge -av
> whatever' on my laptop it takes a very long time for emerge to find the
> package and/or determine the dependecies -  whatever it's doing behind that
> spinner. I can definitely go into more detail about this if anyone's
> interested. It's really been puzzling me!) So, as my final project I've
> proposed to improve the time it takes to perform a search using emerge. My
> professor suggested that I look into implementing indexing.
>
> However, I've started looking at the code, and I must admit I'm pretty
> overwhelmed! I don't know where to start. I was wondering if anyone on here
> could give me a quick overview of how the search function currently works,
> an idea as to what could be modified or implemented in order to improve the
> running time of this code, or any tip really as to where I should start or
> what I should start looking at. I'd really appreciate any help or advice!!
>
> Thanks a lot, and keep on making my Debian-using professor jealous :]
> Emma
>



-- 
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...

[gentoo-portage-dev] few licences, which should exist

[tvali]

(portage list is maybe the best place to send this, but still, maybe
usable as i dont know lists with such specific purpose -- so sending it
to gentoo list and gnu)

I have thought about such things:

1. Formats like mp3 are put together in such way that basically noone
can use them with a free application. There should be licence, which
grants some file formats an opposite -- that no application, which
supports any commercial file format, must not support them. Then people
who want, may put all their free music up in that format -- or even
licence their music in such way that it's only free as long as it is
used together with it. Goal of such licence would be to give gnu people
the same ways to take their market position, as corporations do -- this
may not seem "nice" to those corporations, but it targets the problem,
i think.

1a. Licence, which protects a format against being used in any app,
which supports any poorly documented format like MS word document and
by any product by any company, which owns any such format.

2. In many countries there are software patents. I think that there
should be licence against them similar to previous licence -- so that i
may patent my free software in such way that any company, which uses
any commercial patent in it's production, must not use that software
[or, as alternative licence, must pay for it to gnu, licence owner or
anyone that patenter sees as deserving it]. So, not "if used in
commercial products", but "if used by commercial company". Patents may
be also used in different ways -- for example, there may be long list
of things a company *must not do* or *must not be*, if they want to use
the patent.

I think that there are several kinds of people using gnu licences:
* Those, who actually fight against certain types of licences,
corporative policies etc. and want to protect their work against to be
used in any such project -- maybe even in marketing campain of a
corporation, who is "supporting free software" by taking it's code into
use or just supporting it, like IBM with Red Hat. Those people may,
therefore, even want it to be not given away freely with $40 CD and
book.
* Those, who just dont want their code to be used with any direct
commercial purpose and want it to be open, but dont go too far in
philosophy and let their programming language, for example, be used in
making commercial product.
* Those, who want their code to be free and open and any development to
be free and open, but may say something like "wow our soft is used even
in commercial products".
* Those, who just give it for free to students and schools, for example.
* Those nasty people who make those "free lite versions", which almost work and spam all search engines ;)

Ok, my additions here are -- gnu should think more about those people,
who are actually wanting their code to be propagated only by
freeware-makers and run only in environments, which contain no
commercial products and are not used for any commercial purposes. Ok,
they still contain commercial hardware and people may write their
commercial e-mails in them, but anyway, to have a music format, which
licence does it's best to make it so that you have to *choose between
mp3 and mpfree*, not choose between having both or only free one, would
be good. Freeware builders should have at least one "market", which
uses all nasty microsoft-intel trusted corporate policies to protect
itself against everyone other who use them ;) Such "corporation" could
be nice macintosh to other free products, which are not so radical in
their way (ok, what we would eat, when going too radical, but still --
Microsoft actually *fights* openoffice, so what having alternative
openoffice format, which is, for example, illegal to be used on
commercial OS or, alternatively, illegal to be used in any application
supporting word doc's).-- tvalihttp://www.friesian.com/types.htm

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

[tvali]

On 24/03/06, tvali <[EMAIL PROTECTED]> wrote:
> On 24/03/06, Paul de Vrieze <[EMAIL PROTECTED]> wrote:
> > On Friday 24 March 2006 12:40, tvali wrote:
> > 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 :)

btw if it seems like if i cant write c++, it's actually that i cant
write english as i'm estonian ;) anyway, i agree that programming
languages are a mess. I sometimes think that the whole conception of
putting it together from characters of alphabet always makes them
messy. Building another abstraction layer or library, anyway, will
make even a perfect language non-perfect again :)

--
tvali

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

There are two kind of sysadmins: Paranoids and Losers. -(adapted from D. Bach)

You can't measure time in days the way you can money in dollars
because every day is different. -Jorge Luis Borges

"Never let your boss or your customer talk you into doing a bad job."

http://www.approximity.com/public/quotes.html ;)

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

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

[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 (A { b(B,A); }
>
> And header file 2 defines the following macro
> #define c(x,y) { int A = x; int B = y; if (A>B) { 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

[tvali]

On 24/03/06, Paul de Vrieze <[EMAIL PROTECTED]> wrote:
...

is there any good text about sonames and other unix-specific things i
should know about headers and including?

>
> Paul
>
> ps.
>
> > 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.
>
> Practice without theory is when something seems to work. Until you change
> the environment, after which things fail spectecularly.

This was just a quote and a bit a joke, but not so much (as really
everything hangs and does not do exactly what it should and really
noone knows why) ...but on the same time, i agree with you, i "hate"
all those practical people who never have enough time to think a bit
about what they are doing, espesially to do some generalization ;)

> --
> 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

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

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

[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

[tvali]

On 24/03/06, Paul de Vrieze <[EMAIL PROTECTED]> wrote:
> On Thursday 23 March 2006 21:38, Gustavo Sverzut Barbieri wrote:
> > Cons:
> >  - it's not the final solution to the problem, as said, interfaces
> > would be better... but interfaces would demand much more effort and
> > not being automatically generated, would be async and probably
> > incorrect at some point
>
> Interfaces, while nice, would overcomplicate things. They are also not
> needed as we have depend atoms.
>
> Paul

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);

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.

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.

--
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

[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

[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

[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 be  extended. Useflag dependencies would be at least usefull. BINSLOT would be
  almost required. We already saw that SLOT can't always be used for BINSLOT.
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

[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

[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

[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] Re: User created package lists

[tvali]

2006/3/23, Brian <[EMAIL PROTECTED]>:
On Tue, 2006-21-03 at 10:50 -0600, MIkey wrote:> tvali wrote:>> > So, if portage would be looked as lists and operations with lists> > (calculating dependencies of package would be operation with list of
> > that package and list of all - portage tree -, then); building tools> > [shell commands] for creating those lists and tools for operations> > with those lists and leaving "emerge" tool just a handy interface to
> > command them would be imho great.For a completely re-vamped portage, broken up into many smaller modulescheck out the pkgcore development.
http://gentooexperimental.org/~ferringb/bzr/pkgcore/
Thanks. Will check out when get some time. 
>> 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.>I think you both are making it more complicated than it needs to be.
Creating meta packages listing all the deps etc. may make portage workfor emerges but won't give a user the heads up when one of those depsare upgradable so easily.Marius has stated that user package lists are to be supported in the
future (OK), Porthole will have the ability to get ahead of portagebecause it is not concerned with the direct merging/unmerging ofpackages and system management.  It is merely a way to display packagedata and ask portage (emerge) to merge/unmerge packages.  So back to my
original question:Will user created lists be located in the /etc/portage directory alongwith the other user configs?  If so will the format be similar to thepackage.* files?  For user package lists I imagine there could be the
need to control version ranges, so the standard atoms should somehowapply.I would like to try and get as close to a portage format as can beforeseen so that it will require less updates/re-coding later when that
feature is implemented.
Yes, i agree that package list should be more specific after a bit of thinking :)

Having package lists as files allows:

* Copy them to other computer

* Do operations with them

I think that dependencies should not be contained in those lists anyhow but they should be meant to be used with portage tree. 

Package list should only be usable for two things:
* List packages
* List package data specific to user computer

Keeping any other data in package lists would be useless as there would
be two things to update instead of one portage tree. As package list
file identifies package by name and add then user-specific data maybe
(version), it's enough.
eg./etc/portage/lists/This directory would hold any number of user created lists.  I am not
sure that additional subdirectories would be desired or needed.  Afterall this feature would be to help simplify some tasks, not make oneshead explode trying to follow something overly complex./etc/portage/lists/userlist1
format:net-www/apachewww-apache/mod_perl...How would you atomize a version range?  >=, <=, =, <, > for one endedrange limits the existing format from package.* files could be used.
eg. limit net-www/apache to version 2 only?  Lets pretend a version 3 isalready released, so there could be versions series1, series 2, series3.>=net-www/apache-2.0.0<=net-www/apache-2.99.99
www-apache/mod_perl...Where the upper range limit would immediately follow the lower rangelimitOr would an fstab type format be used.  More available options could beeasily assigned.
#
package  
lowest-version  highest-version
updatesnet-www/apache  2.0.0  
2.99.0  M,KWhere updates could be one or more of "M" manual, "A" automatic, "N"never, "K" binary packages only.
I dont know exactly, where, but  i think that using comma-separated list of ranges should be considered everywhere.

Ranges should be like:
1.*
2.0..2.0.4
(3.3.2)..3.3.6   # not including 3.3.2 -- is needed?

Comma-separated list:
[1.*,2.0..2.0.4,(3.3.2)..3.3.6]
It would not be that hard to implement features like the updates fieldand range limits in porthole.  Since it is not feasible in the current
portage code-base, a wrapper module/script could be made to implement itfor cli.
Now i dont know what youre talking about but you shouldnt try to
explain as i havent yet gone through all portage code as there's some
lack of time, but i will :) --Brian <[EMAIL PROTECTED]
>--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 thi

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

[tvali]

Supposing that you have those
#provide header 
lines in all your packages, which provide something (and, of course,
only in those places in code, where they actually do so that useflags
might be correct), there may be some command of dep builder, which just
uses those providings, putting them together with it's
#use header 

This is not maybe common case, when interfaces and atoms have to be used.

File with
#provide header 
lines could also be autobuilt -- if you have copied all common *.h
files into some dir, which you are going to just put into /lib, then
you're done.

That's somewhat a question, how it should be differenciated if .so is
needed or just headers and code, but there are several more or less
simple solutions. In all cases, data about which .so file is needed
should be contained in .h file, not in a package, which is going to use
it -- i think so.
2006/3/22, tvali <[EMAIL PROTECTED]>:
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  header, it needs library ? -- but
when you need  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
 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=544&Name=Borenstein,_Nathaniel_S
.
-
http://www.softwarequotes.com/ShowQuotes.asp?ID=571&Name=Boehm,_Barry


-- 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=544&Name=Borenstein,_Nathaniel_S.
-
http://www.softwarequotes.com/ShowQuotes.asp?ID=571&Name=Boehm,_Barry

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

[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  header, it needs library ? -- but
when you need  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
 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=544&Name=Borenstein,_Nathaniel_S.
-
http://www.softwarequotes.com/ShowQuotes.asp?ID=571&Name=Boehm,_Barry

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

[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=544&Name=Borenstein,_Nathaniel_S.
-
http://www.softwarequotes.com/ShowQuotes.asp?ID=571&Name=Boehm,_Barry

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

[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 
/* when  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 
#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 
/* if runasdaemon and something, atom "test" is needed */
#include 

/* atoms could be provided as well; interface is a simple atom with few params; just  could be provided, also: */
#ifdef portage-providers
#provide header 
#use header 
#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 
#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 
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 
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=544&Name=Borenstein,_Nathaniel_S.
-
http://www.softwarequotes.com/ShowQuotes.asp?ID=571&Name=Boehm,_Barry

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

[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 
#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 
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 
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=544&Name=Borenstein,_Nathaniel_S.
-
http://www.softwarequotes.com/ShowQuotes.asp?ID=571&Name=Boehm,_Barry

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

[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=544&Name=Borenstein,_Nathaniel_S.
- http://www.softwarequotes.com/ShowQuotes.asp?ID=571&Name=Boehm,_Barry

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

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

[tvali]

> would indicate easily if any packages in the special list are upgradable
> irregardless of whether it is in world, system, whatever.

Ok. Kind of mirroring, then.

>From where the "current version" identifier for each package comes,
then? Will the packages be just downloaded to that central computer
and kept up-to-date there?

Is "list" specifier needed as there are many lists anyway? I mean,
there is no "--list" before world or system.



Actually, it seems to me that "emerge" should be divided into smaller
packages so that users could do such things by scripting.

For example, if there were utilities, which build different types of
lists [system, kde-meta, world] and output them in some standard
format, optionally including versions. elist --currently_installed >>
world.list && elist kde-meta kdevelop >> packages.list.

Then utility, which takes list into stdin and outputs, which items are
newer in server.

Then utility for different kinds of comparations of lists (mix --
mixes two lists into one; onlyinfirst, newerversioninfirst and so on).

Then utility, which is able to emerge all packages, which are
contained in a specific list.

What i mean -- it should be possible to use more shell scripting in
portage. Any competent admin would be able to run "elist
--currently_installed >> world.list" on all machines, then mix them in
one machine and check for updates (and then download all those updates
into local cache, for example).

This should be discussed more deeply, but i think that if portage is
divided into several smaller tools, it would be simpler to develop and
more scalable. In such case, what portage is about -- lists and
checking them against each other; emerging everything in given list;
unmerging everything in given list; checking for dependancies of a
given list.

It is not a small work to think out exactly *how* it should be
divided, but i think that the results would be worth of it. Currently,
imho, the portage code is grown complex enough that making it simpler
is more important than giving new features to it -- if it becomes
simple and robust, many new features will find their way in by
themselves without any work on developer side, i think :)

So, if portage would be looked as lists and operations with lists
(calculating dependencies of package would be operation with list of
that package and list of all - portage tree -, then); building tools
[shell commands] for creating those lists and tools for operations
with those lists and leaving "emerge" tool just a handy interface to
command them would be imho great.

So, something like:
# create list file of all in world
$ elist --currently_installed --options=fullname,installedversion >> world.list
# is cmd for create list file of all in portage tree too slow or usable enough?
# check if list of all (portage tree) contains anything newer
(all.list is symbolic name here for portage tree to get interface
ordered)
$ ecompare world.list all.list --newer --deep >> update.list
# there is another computer, which is not connected to internet, but
has some needs, too
$ ecompare othercomputerworld.list all.list --newer --deep >> update2.list
# mix those lists together
$ emix update.list update2.list >> allupdates.list
# download updates
$ efetch allupdates.list --where /var/portageupdates
# copy all updates mentioned in update.list to CD image

# update [build and install] all packages, using /var/portageupdates
as source of tar files


--
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=544&Name=Borenstein,_Nathaniel_S.
- http://www.softwarequotes.com/ShowQuotes.asp?ID=571&Name=Boehm,_Barry

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

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

[tvali]

I am not sure if i can understand exactly, what you are speaking here.

This will be somewhat half-thought idea here, but..

As much as i have got, system contains packages nessecary for me and
world is all what i have emerged? And system comes basically from
profile?

For me as an user, there is no differences between "system", "world"
and "kde-meta" (syntactically), except that world will contain
kde-meta after i have emerged it and system will contain packages from
my selected profile.

Now, wouldnt it be good if they were exactly the same thing on system
level, and all configureable?

Lets imagine configuration file with the following syntax:
# System points to x86
System=>System x86 2.6
# World is included from another file
@world.list
[system]
#system contains an additional package "moo"
++moo
[world]
#world.list file may contain "moo", but not world
--moo
[kde-meta]
++kicker

Those files could be called patches and optionally contain includes
from random servers.

2006/3/21, Brian <[EMAIL PROTECTED]>:
> I remember that a while back I asked about user created package lists to
> supplement system & world.  If I remember correctly, I believe you
> (portage devs) were open to the idea.
>
> I have been working on re-coding the upgrades view in porthole partially
> to get around a gtk treeview bug causing segfaults (reportedly fixed in
> >=gtk+-2.8.14).  The other reason is to add a feature I have thought
> about for some time (the reason I asked this last time).  Anyway I have
> the basic re-coding done.  It is now possible to break down the
> upgradeable packages into as many lists as desired.
>
> Currently lists are hard coded but will be configurable. (Easier to get
> one thing working at a time) "System" list is generated at run time
> (using the self.system_cmd, then using portage.catsplit to trim the
> version info):
>
> self.cat_order = ["System", "User list1", "World", "Dependencies"]
> self.categories = {"System":None, "World":"World", "User list1":None, 
> "Dependencies":"Dependencies"}
> self.upgradables = {}
> self.pkg_count = {}
> for key in self.categories:
> self.upgradables[key] = {}
> self.pkg_count[key] = 0
> self.count = 0
> # command lifted fom emwrap and emwrap.sh
> self.system_cmd = "emerge -ep --nocolor --nospinner system | cut -s 
> -f2 -d ']'| cut -f1 -d '[' | sed 's/^[ ]\+//' | sed 's/[ ].*$//'"
>
> [snip]
>
> upgradable = package.is_upgradable()
> if upgradable: # is_upgradable() = 1 for upgrade, -1 for 
> downgrade
> if upgradable == 1 or not self.upgrade_only:
> for key in self.cat_order:
> if package.in_list(self.categories[key]):
> self.upgradables[key][package.full_name] = 
> package
> self.pkg_count[key] += 1
> break
>
>
> Is there any plans for officially supported user lists?  eg:
>
> # emerge -up --list mylist
>
> where mylist is in /etc/portage/lists/ (for example)
>
>  Should I set it up to use them from /etc/portage/lists/. Or just from a
> users .porthole directory?  I may have missed it if it has already been
> done :)
>
>
> --
> Brian <[EMAIL PROTECTED]>
>
> --
> 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=544&Name=Borenstein,_Nathaniel_S.
- http://www.softwarequotes.com/ShowQuotes.asp?ID=571&Name=Boehm,_Barry

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

Re: [gentoo-portage-dev] make.conf.* madness

[tvali]

Is this good to create a new file for 2 variables?

Maybe it would be more simpler if all happened with one switch?

2006/3/21, Zac Medico <[EMAIL PROTECTED]>:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Marius Mauch wrote:
> > Don't think I have to reiterate the whole story of having arch specific
> > make.conf files and why that sucks, but just had an idea how to solve
> > the problem other than removing them completely:
> > Just move the arch specific crap (CHOST and CFLAGS) to a separate file,
> > and reintegrate it at install time. So make.conf.x86 in svn would only
> > contain CHOST/CFLAGS and related comments while make.conf (which
> > currently is only a fallback) contains the portage relevant parts, and
> > the ebuild just concatenates them in src_compile to create a single
> > arch specific make.conf.example.
>
> That seems a lot better than the current situation.
>
> > First I also considerd using the "source" instruction instead of
> > reintegrating the files, but that doesn't really work for an example
> > file that's mainly intended to be read by the user.
> >
> > Of course removing the arch specific files completely and only have
> > the fallback make.conf is still an option, but would need a discussion
> > with releng and the docs team probably.
>
> Perhaps it's better to maintain such arch specific information somewhere else 
> such as the handbook.  It'd be nice to keep the docs included with portage as 
> arch independent as possible.
>
> > Any objections against doing this for the next releases?
>
> I'd like to do this (at least the first option) for the next release.
>
> Zac
>
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.2.2 (GNU/Linux)
>
> iD8DBQFEH52w/ejvha5XGaMRAnM6AJ9fTcydIqjkuXcrr1lllIcYd+unUQCgt0jJ
> B9xus7XtBMo1bRwWYpu4hC0=
> =IPBf
> -END PGP SIGNATURE-
> --
> gentoo-portage-dev@gentoo.org mailing list
>
>


--
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

[tvali]

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?

> So I wouldn't mind fixing it to one package instead of a slot.
>
> I mean, if user compiled software X-1.0 and it depends on library
> Y-2.0, provided at the moment of X-1.0 compilation by package Z-3.0,
> then make X-1.0 depend on Z-3.0.
>
> If you were to remove Z-3.0 or upgrade it or even add other option by
> means of USE, have X-1.0 to be recompiled too... you could be even
> more correct to make it check CFLAGS too.
>
> Of course this correctness could piss users, then you could have a
> --nodeps or something like that to avoid this and use the old
> behaviour.
>
> --
> Gustavo Sverzut Barbieri
> --
> Jabber: [EMAIL PROTECTED]
>MSN: [EMAIL PROTECTED]
>   ICQ#: 17249123
>  Skype: gsbarbieri
> Mobile: +55 (81) 9927 0010
>  Phone:  +1 (347) 624 6296; [EMAIL PROTECTED]
>GPG: 0xB640E1A2 @ wwwkeys.pgp.net
>
> --
> gentoo-portage-dev@gentoo.org mailing list
>
>



--
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

[gentoo-portage-dev] Non-root installs

[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] Short question

[tvali]

Is /usr/lib/portage/pym dir and /usr/bin/emerge files together the
whole portage (excluding package tree)? Is there any portage code
outside those dirs?-- 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

[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] DB and binary dependency

[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

[gentoo-portage-dev] Portage sqlite support

[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] [PATCH] Manifest2 reloaded

[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

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

[tvali]

sorry
lines
char tt;
for (tt=0; tt<40; 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: portage from C (was Re: [gentoo-portage-dev] Hello! && portage UI)

[tvali]

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

#include 
#include 
#include 
#include 
#include 

void python(int input[2], int output[2]) {
dup2(output[1], STDOUT_FILENO);
dup2(input[0], STDIN_FILENO);
close(output[0]);
close(output[1]);
close(input[0]);
close(input[1]);
char *const args[] = { "/usr/bin/python", NULL };
execv(args[0], args);
_exit(EXIT_FAILURE);
}

int main(int argc, char *argv[])
{
int input[2];
pipe(input);
int output[2];
pipe(output);

if (fork() == 0) python(input, output);

FILE *inputf, *outputf;

close(output[1]);
close(input[0]);
outputf = fdopen(output[0], "r");
inputf = fdopen(input[1], "w");

fputs("print 123\n", inputf);
fclose(inputf);

char tt;
for (tt=0; tt<40; tt++)
  fputc(tt, inputf);

int c;
while ((c = fgetc(outputf)) != EOF)
	  fputc(c, stdout);

fputc(EOF, inputf);

wait(NULL);
return 0;
}

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

[tvali]

Not so simply :)

This is a clear way, i think. I havent c++ installed right now as it
gives some errors and i havent too much urge yet.

Anyway, with piping..
python > /root/test.out < /root/test.in

You can write things like "import module" to test.in, then use result
from test.out.

I did write words "print 'hello!'" to test.in, which left 1 word
"hello" into test.out -- of course it's slower than getting it work as
realtime interaction :)

http://www.math.mcgill.ca/services/linux_basics.php -- there is also
command1 | command2 for piping between apps.

Tcl script: http://www.cs.mun.ca/~donald/msc/node72.html

When i get kdevelop to work here, i will look this thing more and
produce some code -- i like it more than Kate :) Anyway, i think that
it shouldnt be hard at all :) And using io files, it's achievable now,
too.

2006/3/15, solar <[EMAIL PROTECTED]>:
> On Wed, 2006-03-15 at 17:12 +0200, tvali wrote:
> > Could :P
> >
> > Python has this interactive interpreter, what every scripting language has.
>
> ...
>
> > If you are able to run command-line app, send keyboard input and catch
> > it's output, you're done with it.
> >
> > You can also write some small python function, which will parse python
> > variables into some form, which you can simply parse into something,
> > what is easily readable in C.
>
> An example please. 5 lines of code have more meaning than ~30 emails on
> the topic that simply state 'it can be done'
>
>
> > 2006/3/15, solar <[EMAIL PROTECTED]>:
> > > 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.
> > >
> > > --
> > > 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
> >
> --
> 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

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

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

[tvali]

Could :P

Python has this interactive interpreter, what every scripting language has.

If you are able to run command-line app, send keyboard input and catch
it's output, you're done with it.

You can also write some small python function, which will parse python
variables into some form, which you can simply parse into something,
what is easily readable in C.

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

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

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

[tvali]

Sorry ...one more question ...who is doing search of packages he has
changed by himself? When i update some package, i will probably never
want to search it.

But anyway, in some cases, where GUI uses that search, it would be
good. And going to SQL would be anyway cleaner :)

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


--
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]

[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: sync suggestions [was Re: [gentoo-portage-dev] Few things, which imho would make portage better]

[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: [gentoo-portage-dev] Few things, which imho would make portage better

[tvali]

And if it's not a bugfix? Still there?

2006/3/14, Grant Goodyear <[EMAIL PROTECTED]>:
> tvali wrote:
> > 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?
>
> bugs.gentoo.org
>
>
>
>


--
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

[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

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

[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] Hello! && portage UI

[tvali]

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

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

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

[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] Few things, which imho would make portage better

[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

[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

[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] Hello! && portage UI

[tvali]

Ok, i will finish this chat about making portage cache, then learn
portage code, then write basic sql modules and when this thing is
running, i am more able to be involved in portage GUI as i can
understand background of portage, then ...i hope you have time to wait
for me :)

2006/3/14, Brian <[EMAIL PROTECTED]>:
> 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++
> >
> > 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
>
> First I would unmask it and emerge it so that you have all dependencies
> installed.  enable the debug use flag or emerge pycrash-0.43 separately.
>
> # echo =app-portage/porthole-0.5.0 /etc/portage/package.unmask
> # echo app-portage/porthole /etc/portage/package.keywords
> # emerge porthole
>
> If you like it and want to make a kde interface for it,
>
> Go to our sourceforge page and do a cvs checkout.
> http://sourceforge.net/projects/porthole/
>
> > * Change that source
>
> cd into the directory, edit as desired
>
> > * Build my version of it in such way that my portage tree is OK after
> > that
> >
> then run it from a terminal:
>
> # ./porthole -l -d
>
>
> Also sign up to the 2 mail lists for porthole so we can discuss any
> problems, etc..  This list is for portage development.
>
> Then any changes can be diffed for commit.
>
> cvs diff -u > somefile
>
> Of course I will have to make changes to the interface loading so that
> your changes won't kill the gtk interface code.
>
>
> > Are --fetchonly and --usepkgonly somehow related to that?
> >
> --fetchonly will just get the tarball downloaded into the distfiles
> directory.
>
> --usepkgonly is for telling emerge to use binary packages only.
>
>
> > 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 one
> > that 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
> > can
> > interact with and use portage code for information retrieval
> > then check
> > out 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 that
> > there 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
> --
> 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

[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

[tvali]

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.

I think that SQL functions for searching and other things are maybe
not much faster than py (as py seems to be fast enough, at least if
there are more important things to do), but simpler to use. Therefore
i think that rewriting the whole thing with SQL support may be still
better.

I will make it clear for me, what those emerge db functions do and
still try to do something, what connects them to SQL.

Anyway, i am still interested, is there some code or other
documentation about how portage works, especially how it keeps it's
data?

2006/3/14, tvali <[EMAIL PROTECTED]>:
> 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.
>
> There could be table, which contains two fields -- Id and query (for
> example -- in reality, it could be a bit more complex for whatever
> reason; datetime, for example -- or filename and it's content to
> support current portage filetree). If i do emerge --sync, then one
> query could be done, SELECT query FROM updates WHERE Id >
> LastDownloadedUpdateId ORDER BY Id, then run all queries.
>
> I guess that in such case, portage --sync would be faster and less
> server-expensive. I dont know about this cache it builds, but i
> suppose that this could be made faster, too :)
>
> Ok, i will work now a bit, but i hope you have time to explain to me,
> if something i tell here is stupid or not-so-important for whatever
> reason.
>
> 2006/3/14, tvali <[EMAIL PROTECTED]>:
> > 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 cl

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

[tvali]

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.

There could be table, which contains two fields -- Id and query (for
example -- in reality, it could be a bit more complex for whatever
reason; datetime, for example -- or filename and it's content to
support current portage filetree). If i do emerge --sync, then one
query could be done, SELECT query FROM updates WHERE Id >
LastDownloadedUpdateId ORDER BY Id, then run all queries.

I guess that in such case, portage --sync would be faster and less
server-expensive. I dont know about this cache it builds, but i
suppose that this could be made faster, too :)

Ok, i will work now a bit, but i hope you have time to explain to me,
if something i tell here is stupid or not-so-important for whatever
reason.

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

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

[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
&g

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

[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 an

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

[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-49

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

[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

[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] Hello! && portage UI

[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

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

[tvali]

I think that it would make things more clear and simple if portage did
support the following (maybe some are already included, but not found
by me):



* Add package to "world" checking all dependencies, but not emerging

* Remove package from "world" without unmerging

* Save all important messages into file instead of beeping (i may be away from home); optionally replay them at end of update

* 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-- 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] Hello! && portage UI

[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