[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-dev
Subject:    Re: [gentoo-dev] exist an automated ebuilds removal ?
From:       Francesco Riosa <francesco () pnpitalia ! it>
Date:       2004-12-31 13:58:45
Message-ID: 41D55FBB.4060209 () pnpitalia ! it
[Download RAW message or body]

Stuart Herbert wrote:

>Hi Francesco,
>
>I don't support this proposal.  I've added some constructive critisism below.
>  
>
Thanks I love constructive critisism, it's difficult to find them theese
days

>On Friday 31 December 2004 02:56, Francesco Riosa wrote:
>  
>
>>Abstract
>>There is no automated removal of ebuilds
>>    
>>
>
>There is a case for automated removal of some ebuilds, but I don't believe 
>that this is it.
>  
>
With your help (read constructive critisism) I will try to better
explain my motivation and to understund myself if they are correct.

>  
>
>>Motivation
>>Portage is formed by now from more than 2**12 packages and more than
>>2**14 ebuilds. This one explodes in a portage tree of more than 100000
>>files.
>>    
>>
>
>Why is this a motivation?  If the size of the portage tree is an issue, you'd 
>need to explain the actual issue.
>  
>
Here I made a pair of  assumptions:
. a wide choice is good for the user, may be only a bit more time
consuming to choose from.
. have a wide tree need a wide effort from developer and maintainer.
. portage tree is something that travel a lot over internet, so its size
is important for both sides, client and server

>  
>
>>The idea is try to see if some of theese are unused from the users,
>>individuate which ones and remove them.
>>    
>>
>
>Hrm.  You'll never get the data you need to make this decision automatically, 
>and this is where the idea falls down imho.
>  
>
may be, probably it will be, but difficult be sure of that not trying it
before, you need to valuate the effort to analize/try this solution, if
it's too high the whole should be abandoned.

>  
>
>>Specification
>>webserver logs will be used to have some statistics, since there are 185
>>mirrors listed in gentoo mirror page, you should choose to monitor some
>>of theese (at least 20%) in various country.
>>    
>>
>
>The decision of which packages to remove would be based on a sampled subset of 
>the download data from the Gentoo mirror sites?
>  
>
yes I can't see how to implement this part better :(

>How will you track the packages that are downloaded from the upstream site?  
>This can happen for a number of reasons, not limited to
>
>a) mirror is out of date
>  
>
two solutions,
- simply ignore outdated mirrors, we don't suppose to monitor them all
- shift the time slice, we will consider 4 month starting from 5 month ago

>b) upstream has their own mirrors, which the ebuild tries first
>  
>
I don't fully understand this (english), but I think it's assimilable to
c) and d)

>c) package has RESTRICT=nomirror
>d) package has RESTRICT=fetch
>  
>
There are 485 ebuild with nomirror and 165 ebuilds with fetch
restrictions, this is about 4 % of the totale ebuilds number, theese
will be hand moved.
e) some users have a local mirror or a shared distfiles dir for more pc,
this will lower their weight in the statistic.
unsolved

>  
>
>>If all the files owned from one ebuild are not been downloaded in the
>>last 4 month the ebuild shoud be moved in alternate portage tree
>>(portage_attic), the files included only from that ebuild should follow it.
>>tar.gz should be moved also to an alternate tree (distfile_attic)
>>portage_attic and distfile_attic should be public but not from the
>>mirrors (or on only few ones).
>>These are not to be managed from the gentoo team, nor in emerge script,
>>the user can download them in his overlay if he/she need it.
>>    
>>
>
>This replaces the simplicity of 'emerge --sync' and 'emerge <pkg>' which is a 
>definite advantage over (say) RPM-based distros.
>  
>
The replace should not be so traumatic thinking in a statistic way. the
equation should sound like this:
[n.of ebuild/packages removed] * [cx of small tree advantages]  >
[missed hit of emerge foobar] * [cx of  unsatisfaction of build an
overlay for that one]  + [developer effort needed]

>  
>
>>Rationale
>>Chances are that this can save resources of gentoo team, rsync server
>>resources, space on mirrors.
>>    
>>
>
>"Chances are"?  Have you identified real resource problems which will be 
>addressed by this solution?  It sounds like you have a solution looking for a 
>problem.
>  
>
I've not identified real resources problems, you can have a wider view
of the whole stuff if the other seems reasonable you can choose to
analyze this.

>>Backwards Compatibility
>>Need hacking from the user. But users that need unusual stuff generally
>>are also users that well know what they are doing.
>>    
>>
>
>Unusual, yes ... but this proposal doesn't demonstrate that it will separate 
>unusual from simply unused.
>  
>
Very opinable but they shoul be threated the same.

>This section doesn't address dependency issues.  Some of the packages moved to 
>the attic may be a dep for another package.  How will that be handled?  
>
>  
>
Two way, if the package is required from another both will be downloaded
(not deterministic), in every case a database of dependancies shold be
kept and enquired

>Best regards,
>Stu
>  
>
Best regards
Francesco


--
gentoo-dev@gentoo.org mailing list

[prev in list] [next in list] [prev in thread] [next in thread]