[gentoo-dev] some additions to portage/ebuild and some other nice thingys i'dd like :)

[gentoo-dev] some additions to portage/ebuild and some other nice thingys i'dd like :)

[troxx]

Hiya all,

Just a few things i'dd like to see in RC5 (or earlier):
at this point there are a few reason's why the system can get un-optimized or just not-working.
One reason is that if libraries get updated that were STATICALLY linked in other packages, those packages don't get rebuilt automatically... this is not good. So packages that depend on it should be rebuilt... But there is one thing to think about... it's NOT always needed... for example if perl gets updated we don't want all packages that depend on it to get updated... so there has to be a flag in the ebuild-files that specifies wheter or not a package needs to be rebuilt if a dependancy gets updated... so for example add a ! to the dependancy-name... 
Then the ebuild update command will have to walk through all packages and look if any !marked dependancies got updated... and if so, rebuild the package... the reason why i'dd like ebuild update to do it is that i don't want to do it automatically if i update some library... takes to much time(and it means ebuild will have to search through the entire db every time)

The second reason why the system gets unoptimized or uncomplete is due to changes in the USE variable... 
Of cource we don't want the entire system to be rebuilt after echt USE-change... so we need "ebuild update" to remember the previous state of USE, and compare it to the current one. And after that it should rebuild ONLY the packages that are affected. For this another enhancement to ebuild-files is needed... a field to specify what USE-parameters affect the package (this also allows nice GUI's in the future to ask you if you want to toggle some USE-switches if you select the package).


Another thing that would be nice is a way to see if packages got updated (not ebuild-files, but real sources).
This would allow people to easily see what ebuild-files have to be updated...
I know rock-linux allready has the script for it (to check on source-locations, for ALL versions available) which can be modified to check for NEWER versions only...

I'm sorry for bugging about missing things i'dd like to see... It's not that I'm too lazy to implement them myself, I would love to... but I need some practise on scripting for now...
Just think those additions would make gentoo really the king of distributions :)

bye!
/troxx

AW: [gentoo-dev] some additions to portage/ebuild and some other nice thingys i'dd like :)

[Sebastian Werner]

Rebuild Dependecies - a really good idea. I wonder that Gentoo don't save
package-information in a database like db3 or postres. It's not really fast
to search hundrets of ebuild-files or?

Sebastian

-----Ursprungliche Nachricht-----
Von: gentoo-dev-admin@gentoo.org [mailto:gentoo-dev-admin@gentoo.org]Im
Auftrag von troxx@segfault.nl
Gesendet: Mittwoch, 25. April 2001 20:10
An: gentoo-dev@gentoo.org
Betreff: [gentoo-dev] some additions to portage/ebuild and some other
nice thingys i'dd like :)


Hiya all,

Just a few things i'dd like to see in RC5 (or earlier):
at this point there are a few reason's why the system can get un-optimized
or just not-working.
One reason is that if libraries get updated that were STATICALLY linked in
other packages, those packages don't get rebuilt automatically... this is
not good. So packages that depend on it should be rebuilt... But there is
one thing to think about... it's NOT always needed... for example if perl
gets updated we don't want all packages that depend on it to get updated...
so there has to be a flag in the ebuild-files that specifies wheter or not a
package needs to be rebuilt if a dependancy gets updated... so for example
add a ! to the dependancy-name...
Then the ebuild update command will have to walk through all packages and
look if any !marked dependancies got updated... and if so, rebuild the
package... the reason why i'dd like ebuild update to do it is that i don't
want to do it automatically if i update some library... takes to much
time(and it means ebuild will have to search through the entire db every
time)

The second reason why the system gets unoptimized or uncomplete is due to
changes in the USE variable...
Of cource we don't want the entire system to be rebuilt after echt
USE-change... so we need "ebuild update" to remember the previous state of
USE, and compare it to the current one. And after that it should rebuild
ONLY the packages that are affected. For this another enhancement to
ebuild-files is needed... a field to specify what USE-parameters affect the
package (this also allows nice GUI's in the future to ask you if you want to
toggle some USE-switches if you select the package).


Another thing that would be nice is a way to see if packages got updated
(not ebuild-files, but real sources).
This would allow people to easily see what ebuild-files have to be
updated...
I know rock-linux allready has the script for it (to check on
source-locations, for ALL versions available) which can be modified to check
for NEWER versions only...

I'm sorry for bugging about missing things i'dd like to see... It's not that
I'm too lazy to implement them myself, I would love to... but I need some
practise on scripting for now...
Just think those additions would make gentoo really the king of
distributions :)

bye!
/troxx



_______________________________________________
gentoo-dev mailing list
gentoo-dev@gentoo.org
http://www.gentoo.org/mailman/listinfo/gentoo-dev

Re: [gentoo-dev] some additions to portage/ebuild and some other nice thingys i'dd like :)

[Daniel Robbins]

On Wed, Apr 25, 2001 at 08:17:39PM +0200, Sebastian Werner wrote:
> Rebuild Dependecies - a really good idea. I wonder that Gentoo don't save
> package-information in a database like db3 or postres. It's not really fast
> to search hundrets of ebuild-files or?

We don't use a database because we are modeled after the FreeBSD ports system.
Many people prefer plain text in /var/db/pkg so that they can easily see what's
going on without using a special tool.

However, we now have a dblink() python class that handles database access,
specifically designed to allow mysql, db3, postgres, oracle, etc backends to be
added easily.  If you implement a new db-aware dblink() class, portage will
automatically store all data in a database rather than in text files.

But the default db format is likely to remain plain-text since it is preferred
by many users and is the least-complex solution.  And, it's very likely that
the dblink() class will be moved to C++ at some point... which will increase
performance by a good amount.

Best Regards,

-- 
Daniel Robbins					<drobbins@gentoo.org>
President/CEO					http://www.gentoo.org 
Gentoo Technologies, Inc.			

Re: AW: [gentoo-dev] some additions to portage/ebuild and some other nice thingys i'dd like :)

[Achim Gottinger]

Sebastian Werner wrote:
> 
> Rebuild Dependecies - a really good idea. I wonder that Gentoo don't save
> package-information in a database like db3 or postres. It's not really fast
> to search hundrets of ebuild-files or?

Well, reiserfs is really fast with small files, I heared that peolpe try
to
use files on reiserfs for db3 databases at the moment.

bye achim~

Re: [gentoo-dev] some additions to portage/ebuild and some other nice thingys i'dd like :)

[Daniel Robbins]

On Wed, Apr 25, 2001 at 08:09:49PM +0200, troxx@segfault.nl wrote:

> Just a few things i'dd like to see in RC5 (or earlier):

If you pay me a good sum of money, I'll make sure they end up in rc5.
Otherwise, they'll need to wait until after 1.0 because I need to pay
bills in the meantime :)

> at this point there are a few reason's why the system can get un-optimized or
> just not-working.  One reason is that if libraries get updated that were
> STATICALLY linked in other packages, those packages don't get rebuilt
> automatically... this is not good. So packages that depend on it should be
> rebuilt... But there is one thing to think about... it's NOT always needed...
> for example if perl gets updated we don't want all packages that depend on it
> to get updated... so there has to be a flag in the ebuild-files that
> specifies wheter or not a package needs to be rebuilt if a dependancy gets
> updated... so for example add a ! to the dependancy-name... 

The static library example you describe should not break any packages, although
a recompile would allow them to potentially be better optimized.  Achim and I
have been dicussing how to implement auto-dep-rebuilding, but you probably
won't see it until Portage 1.7.  We have other more important features to
implement first.

> The second reason why the system gets unoptimized or uncomplete is due to
> changes in the USE variable... 

> Of cource we don't want the entire system to be rebuilt after echt
> USE-change... so we need "ebuild update" to remember the previous state of

It already records the USE, CXXFLAGS, CFLAGS and CHOST settings that were used
at compile-time.

> USE, and compare it to the current one. And after that it should rebuild ONLY
> the packages that are affected. For this another enhancement to ebuild-files
> is needed... a field to specify what USE-parameters affect the package (this
> also allows nice GUI's in the future to ask you if you want to toggle some
> USE-switches if you select the package).

> Another thing that would be nice is a way to see if packages got updated (not
> ebuild-files, but real sources).  This would allow people to easily see what
> ebuild-files have to be updated...  I know rock-linux allready has the script
> for it (to check on source-locations, for ALL versions available) which can
> be modified to check for NEWER versions only...

# emerge --pretend system
(view packages that need to be installed to make the system profile-compliant;
will only add a package to satisfy the profile)

# emerge --pretend update
(view all the packages that need to be installed to make the system completely up-to-date;
will upgrade older packages)

These features are currently experimental and should not be used without first
calling them with "--pretend" to make sure they aren't installing anything that
they shouldn't.  Right now, they could potentially remerge a newer version of
baselayout which would cause your /etc/passwd, /etc/group, etc to get wiped.

Also, Warren is currently working on a Gento Linux web update frontend called
"gentool", which is at version 0.0.1 and is quite nice.

> I'm sorry for bugging about missing things i'dd like to see... It's not that
> I'm too lazy to implement them myself, I would love to... but I need some
> practise on scripting for now...  Just think those additions would make
> gentoo really the king of distributions :)

Features like this are in the works, but we'll be adding config file management
and more fine-grained dep-strings next.  Then we'll have the necessary features
to safely handle auto-dep-rebuild features.

Best Regards,

-- 
Daniel Robbins					<drobbins@gentoo.org>
President/CEO					http://www.gentoo.org 
Gentoo Technologies, Inc.