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 modules
check 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 work
for emerges but won't give a user the heads up when one of those deps
are 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 portage
because it is not concerned with the direct merging/unmerging of
packages and system management. It is merely a way to display package
data 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 along
with the other user configs? If so will the format be similar to the
package.* files? For user package lists I imagine there could be the
need to control version ranges, so the standard atoms should somehow
apply.
I would like to try and get as close to a portage format as can be
foreseen 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. After
all this feature would be to help simplify some tasks, not make ones
head explode trying to follow something overly complex.
/etc/portage/lists/userlist1
format:
net-www/apache
www-apache/mod_perl
...
How would you atomize a version range? >=, <=, =, <, > for one ended
range limits the existing format from package.* files could be used.
eg. limit net-www/apache to version 2 only? Lets pretend a version 3 is
already released, so there could be versions series1, series 2, series
3.
>=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 range
limit
Or would an fstab type format be used. More available options could be
easily assigned.
# package lowest-version highest-version updates
net-www/apache 2.0.0 2.99.0 M,K
Where 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 field
and range limits in porthole. Since it is not feasible in the current
portage code-base, a wrapper module/script could be made to implement it
for 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] >
--
[email protected] 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
