Re: Dependancies of Debian Archive (FYI)
Hi,
On Fri, Mar 07, 2003 at 01:29:54AM +1000, Anthony Towns wrote:
> On Thu, Mar 06, 2003 at 12:53:08AM -0800, Osamu Aoki wrote:
Please do not exclude my key comment from quotation :-)
One measure is "how many other packages depend on it?"
^^^
It is only one aspect of importance. Nothing more. I really meant it.
> > I did some quick(*) research(**) on the Debian archive (stable, testing,
> > unstable combined) and found out followings:
> > 12% of packages had dependencies with more than 5 other packages
> > 88% of packages had dependencies with less than 6 other packages
>
> "more than 5", "5 or less" or "6 or more", "less than 6" -- please, my
> brain can only stand so much.
Yes.
12%: dependencies > 5 other packages
88%: dependencies =< 5 other packages
> > As you can see, most (>75%-90%) packages have very limited impact to
> > the archive consistency.
>
> How about virtual-packages? I notice you have:
>
> 494 smail
> 423 exim
> 33 postfix
> 27 sendmail
> 7 postfix-tls
> 4 exim-tls
Correct. Virtual packages are not accounted at this time. My first and
only run of this stupidly simple and short script took well over 2 hours
on my fast machine. So excuse me for some minor glitches.
(I did run few shell 1 liners before. That one over counted dependencies.)
> But, in some sense, all these packages are more or less equally
> important; the most important thing all these packages do is provide
> mail-transport-agent, and if we lose exim we can relatively easily
> replace it with any of the others.
>
> You might also want to look at collating by source package.
These can be done but it will be an overkill to update this stupid shell
script. I think that reasonable next step is to extend apt-rdepends and
address issues raised here. Simon? will you? or have you?
But the percentage number will stay generally the same since those
important virtual packages are few.
Also each package was given same weight of 1 when I calculated this
scores. It may be not a good idea to use these number as the official
"importance" measure as others has pointed out in this respect.
> > Currently, minor release does not allow any upstream version bumping but
> > just security bug fixes. I wonder that is the right approach or not for
> > these *less* important packages.
>
> > 88% of packages had dependencies with less than 6 other packages
>
> There's no way we can ensure random minor updates of some 8000 packages
> are suitable for stable updates. One thing we don't want to do is force
> sysadmins to check every point update for regressions before rolling
> it out.
I understand your point very well. This comment was meant to provide
thinking references to the future upgrade policy of desktop applications
under yet-unknown 'flavor" thingy. I was expecting some 'testing'
infrastructures will be in action before offering them as possible
upgrades to the users for the intended 'flavor'.
As Michael pointed out, if a package provides console/scripting
application we do not want any new features to screw up local programs
by upgrading the package.
As Javi pointed out, this may be an useful measure to prioritize
adoption of orphaned package.
Anyway, I am happy to see this was somewhat interesting to you all as is.
Thanks.
PS:
I made this table as a part of my archive dependency statistics to be
used for my yet-announced pet project.
--
~\^o^/~~~ ~\^.^/~~~ ~\^*^/~~~ ~\^_^/~~~ ~\^+^/~~~ ~\^:^/~~~ ~\^v^/~~~ +++++
Osamu Aoki <osamu@debian.org> Cupertino CA USA, GPG-key: A8061F32
.''`. Debian Reference: post-installation user's guide for non-developers
: :' : http://qref.sf.net and http://people.debian.org/~osamu
`. `' "Our Priorities are Our Users and Free Software" --- Social Contract
Reply to: