thanks for reviewing those - ive had a lot of that pending for years - just a
few explanations
On Sat, 06 Jul 2024 11:26:14 -0600 Luke wrote:
> - librerelease:
> + librechroot.conf:REPODEST got replaced by
> TIER0_{USER,HOST,PORT,STAGING}.
> Though it is now clear that if we
> do go back to REPODEST, we will need better docs on when it is
> appropriate to change the userinfo part.)
really, the reason i did that was because the logic was convoluted - the way it
is handled in librerelease reads like an apology - when trying to learn how the
libretools source code works, i found it to be more confusing as it was
(actually, it still is for the most part)
the original REPODEST had to be parsed anyways - there is about 50 LOC just to
validate that the parsing was sensible and split the URL into those same
components (eg: $REPODEST_path), because the components are actually used
separately in more places than REPODEST is used as a complete URL - all that
code is still there, though it does not need to be now - it could be dry'ed a
more now
also, as a matter of design, there is really no reason for anyone to ever change
the destination repo to anything other than the same one as everyone else - it
could be a constant and not even in a user-configurable file - no one would be
confused by it if it was not in a user-configurable file - most people would
never even notice it
On Sat, 06 Jul 2024 11:26:14 -0600 Luke wrote:
> - conf.sh (`$(librelib conf)`):
> + Got an include-guard, so it is safe to include multiple times.
the guard is not doing much ATM - that file does/did get included multiple
times - the includes cascade quite a lot throughout, especially when mksource
is invoked; but that was always safe - mainly, i added that because my copy has
many profiling traces, and all those unnecessary cascading includes are
extremely noisy when traced
so this and REPODEST were more about design smells than anything practical -
mainly to improve overall grokability for the next person who may approach
libretools as legacy like i did
and for the future, i that guard could be more practical, because i also would
like to put some shared constants in that file such as SUPPORTED_ARCHES and
SUPPORTED_ALGOS, which are currently hard-coded in multiple places - those can
change over time and would easier to manage in a central location, and
would not make sense to be over-ridden by the user, and they should not change
during execution (ie: the could be readonly, if they were not sourced
repeatedly)
_______________________________________________
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev
