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

[tvali]

2006/3/23, Brian <dol-sen@×××××.net>:
>
> 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 <dol-sen@×××××.net>
>
> --
> gentoo-portage-dev@g.o 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