On Friday, April 24, 2020 1:03 AM, Alec Ten Harmsel <a...@alectenharmsel.com>
wrote:
> If it's so easy, why don't you implement it? /s
because busy and got better things in life.
but what is your point?
1. are you trying to get to know me a bit closer?
2. or are you trying to indirectly a claim that
making portage faster is too hard?
if (1) then off-topic. if (2) then you're
committing a logical fallacy. some version of
appeal to majority? hence your claim is
unsubstantiated, and is deleted from space thanks
to occam's razor.
if it was too hard for most people in the past, it
doesn't mean that it is hard for everyone else.
not saying that your claim is wrong. but saying
that your tool to show that claim is not working.
not saying that your claim is right either. it's
so far floating somewhere in the ``unknown''
region (until a proof is presented; not a logical
fallacy).
> Sorry for being a little glib but every couple months I go through this
> thought process:
>
> 1. Wow, portage is slow
> 2. I can make this faster, it can't be that hard
> 3. ...wow, nevermind, it is really hard
> 4. Thank you portage maintainers!!!!!
if your point is to share history, thanks. else:
logical fallacy (read above).
> I don't think it's O(log n). Roughly, for 1 package portage has to make the
> full dep
> tree, solve all the constraints to resolve to actual packages that can be
> installed,
> and order and merge the tree into a single branch of packages to install. I'm
> probably missing some steps and obviously that's not a rigorous explanation
> but
> it's at least O(n) where n is the total number of dependencies.
not mutually exclusive. your n (number of deps)
is different than my n (number of packages in
portage). e.g. i think that :
O(your n) = O(log(my n))
i think the real trick is to split portage into
two separate parts:
1. index: pre-compiled indexed global dependency
graph. this should allow efficient jumping
into the right spot of the graph to efficiently
walk around to meet the dependencies based on
constraints (e.g. USE flags, versions).
imo this can do the dependency resolution that
emerge does in 45 seconds in less than 3
seconds.
2. scripts to carry out the compile/installation.
currently portage has (1) and (2) mixed into a
single directory-based structure containing files
in a format that is not efficient for graph
walking, and uses the wrong tool (python).
> Speeding up portage would be a fun project but it's less important
> that portage being correct.
yes, the speed issue is not a problem (more like a
psychological issue). but that's misleading.
portage's problems is beyond the timing issue.
e.g.:
1. the fact that emerge uses python is horrible.
ideally a package manager must have least
run-time dependencies possible. but now,
emerge is based on python, which limits our
freedom in upgrading python versions in the
fear of wrecking emerge (and getting stuck,
needing manual attention). which is why i
think ideally new emerge should be some
statically linked compiled binary.
2. i'm sure smart people can point out better
reasons about how emerge is wrong.
