Emerge - the future?

NiXZe · Posted: Fri Aug 15, 2003 12:34 am Post subject:

I've been thinking the system of rsync seams a litle bit od to me or more correctly the use of the ebuilds in the rsync process... (i don't use all the ebuild files why wast my "pressius" hd space) what if instead something like a text file with all .ebuilds availeble when u want to install a package u do a emerge some_package then it downloads a tgz/tar.bz2 with the ebuild and Manifest * * (files neaded) and then goes further downloading the dependency ebuilds?......

this makes the issue with the serch so lets transfer the idea of the textfile over to a db with ebuildname and all the other info that comes up in emerge -s?

so now that is a easy way to not have a hell of a long time doing an emerge sync (not it's realy that long but still and we also have minimised the serch time with some kind of db)???

now this makes some non broadband users yell hey what if i want to be able to do an emerge -p without having to be online well for those users we still got the ebuilds on rsync mirrors to download the tree if they want to or maybe just all the ebuilds that are used in "world" during the sync process.

P.S. if you think that i think that i've got wings or something else od let me know

_________________
What? Where? Oh! this one, it's Gentoo.
If you don't have anything constructive to say, you might want to consider staying quiet instead.
To many destructive comments, which in no way will help making the Gentoo community better.

dol-sen · Posted: Fri Aug 15, 2003 6:03 am Post subject:

Many of thoe features everyone is talking about have been or are being worked on, just not a single co-ordinated effort. For a database driven portage check out portage-sql being worked on at breakmygentoo.net.

As for a database driven portage tree, non-broadband users would not have a problem with dependancy checking, etc. as the database should contain all pertinent data about the package, just not the ebuild itself. The ebuild should be downloaded with the package, for non-broadband/offline emerges there would still be the

charlieg · Posted: Fri Aug 15, 2003 11:24 am Post subject:

Joe · n00b Joined: 01 Jul 2002 Posts: 70 Location: Europe

I am a little disappointed by the USE Flags read by emerge.

First, negative USE flags are a bad idea IMHO. Something like moznoirc, moznocompose, nocardbus etc. should be avoided.
Call them mozirc, mozcompose and cardbus and leave them unset.

Second, the system should take notice of the fact, that there are no global USE flags for your box.

Actually I have to adjust my flags for every package installation (and for each rebuild/update!).

For example, if I want to emerge php, I need postgresql but not X and pam. Later I want to emerge courier, but I dont want courier to use postgresql but pam. For postgresql I dont want SSL support (just local access required), but php should use it of course and so on.

In short words: Its kind of impossible to find a USE flag configuration which fits to your needs over all packages going to be compiled.

Yeah, ufed is your friend, but anyway I think that was not the idea behind the USE flags.
Besides, an "emerge world" is quite useless for me without "-vp".

Third, I want a possibility to find out afterwards with which flags set a package has been compiled. As you can imagine I am not able to find out which flags I used a month ago by peeking into /etc/make.conf.

Fourth and last, I would like the possibility to see a changelog or at least some quick info why I should upgrade a package without having to visit the projects homepage.

Regards,

Joacher

Senso · Posted: Fri Aug 15, 2003 12:47 pm Post subject:

Hoeken · n00b Joined: 07 Feb 2003 Posts: 7 Location: Iowa

scrllock · Tux's lil' helper Joined: 14 Oct 2002 Posts: 102

nixze's point is quite good. In freebsd, using cvsup to upgrade your ports, you can specify that you don't want, say the astrology and biology sections. thus time and bandwidth and diskspace are all saved.. I don't know if rsync can do this though. however, if an alternate method of syncing was made available...

M104 · Posted: Fri Aug 15, 2003 5:58 pm Post subject: Re: USE flag nonsense

dol-sen · Posted: Sat Aug 16, 2003 7:01 am Post subject:

to joe

Genone · Posted: Sat Aug 16, 2003 9:12 am Post subject:

Ok, I've read the majority of the posts here and I think I should adress some of the issues presented here:

portage speed:
Yes, portage is not as fast as possible. All the import statements in portage.py and emerge cause a startup delay (about 3-5s on my P2 233). The actual runtime performance is more affected by the disk accesses, not the implementation language. This is not so much an issue when emerging a package, but really annoying for searches or pretending. There are several scripts to improve search speed by using an index file (search for esearch or fastsearch).

(dis)advantages of C/C++ over python:
The speed improvements would not be that much. A major improvement would be error checking on compile time. On the other hand it's much easier to fix bugs or implement new features in python. And anyone who thinks that the ebuild syntax is tied to portage written in python is wrong: ebuilds are written in bash

DB backend:
I'll quote carpaski (the current portage maintainer) from an IRC discussion today (a bit edited):

Lowspirit · Posted: Sat Aug 16, 2003 9:43 am Post subject:

Let's pretend I'm doing a big multi-ebuild emerge over ssh, how do I know which package it is on then and of how many/etc? I tend to login with a new user and just "emerge package -p" and see how many is left but that's not smoooth.

All suggestions in this thread for that "flaw" was aimed towards X usage as far as I could tell.
_________________
Gentoo | AMD X2 3800+ 2GB RAM | Kernel 2.6.30 . ReiserFS . CFQ . GCC4.3.3 | Firefox 3.5 | Gnome 2.26 w/ Compiz-Fusion
"Penguins are the only fish that can fly"

Joe · n00b Joined: 01 Jul 2002 Posts: 70 Location: Europe

plate · Posted: Sat Aug 16, 2003 12:13 pm Post subject:

kernja · n00b Joined: 12 Jun 2003 Posts: 65

What I'd like to see is when doing an "emerge -u world", for example, if one app fails to compile the emerge won't stop but will just not try to compile anything dependent on the failed package. I'm sure most of us have gone to sleep after running"emerge -u world" only to find it the morning that two packages were compiled the third failed and 50 others were aborted.

Ox- · Guru Joined: 19 Jun 2003 Posts: 305

Genone · Posted: Sun Aug 17, 2003 2:19 pm Post subject:

Ox- · Guru Joined: 19 Jun 2003 Posts: 305

tactless · Posted: Mon Aug 18, 2003 12:45 pm Post subject:

A little note about the progress meters: SBUs, or Static Bash Units. Time a static compilation of bash, and, for example, a compilation of the latest xfree86. Divide, and you get the compilation time of xfree86 in SBUs. Add this information to the ebuild.
Then, have the user do something like "emerge sbtime" to figure out how long an SBU takes on his own system. When he emerges xfree86, it'll tell him approximately how long that will take on his system, running under the same parameters as the static bash compilation. Not precise, but better than what we have now.
_________________
Tactless

"If it wasn't for fog, the world would run at a really crappy framerate."

Jabber: tactless@amessage.info

Ximinez · n00b Joined: 28 Apr 2002 Posts: 7 Location: Cork, Ireland

Souperman · Posted: Mon Aug 18, 2003 1:52 pm Post subject:

You should be able to see which package is currently being merged and how many are being merged in the current operation, e.g.:

Ximinez · n00b Joined: 28 Apr 2002 Posts: 7 Location: Cork, Ireland

STEDevil · Apprentice Joined: 24 Apr 2003 Posts: 156