> On Tuesday, July 31, 2012 4:31:08 AM UTC-4, AntoineLeca wrote:
>>> On Friday, July 27, 2012 1:24:23 PM UTC-4, AntoineLeca wrote:
>>>> pikpik wrote:
>>>>> /boot/minix: versions of bootable parts
>>>> BTW, previously there were at most 4 versions there; nowadays only 3
>>>> are kept; I tracked it to [release]tools/mkboot, rotate_oldest(): the
>>>> command ls -t "$base_dir" lists the new .temp/ directory as well, so is
>>>> offset by one (the . is ignored since it is run by root); as a result
>>>> adding the option |4 to the "not much here" case would make sense IMHO.
>>>> Of course the $3 below has to be adjusted to $4 as well.
>> BTW, using shift or even better
>> [ $1 != ".temp" ] || shift
>> would achieve the same effect, perhaps in a more obscure way.
> So, that simply removes the last one?
Sorry, you lost me along the way... (or it is a bit more complex.)
The script does remove one "release" (and only one) when it detects
there are "too much" releases in the store.
As it stood initially, it passed silently when there were 4 releases or
less (the new one, and up to 3 older kept); when there are 5 or more, it
tried to delete the fourth more recent, or more exactly, the third more
recent of all the ones existing before the new one is created.
The idea behind that logic is to keep the oldest, since it is assumed to
be a rock-solid, heavily-tested one, which is retired (manually) only
when the stars are really aligned (also, it adapts to the teaching logic
on MINIX as used in exercises: the oldest one is the reference version
The new way creates the release _before_ doing the cleanup (while the
logic of the script was not adjusted: this is my whole point.)
As a result, it passes silently when there were 3 releases or less (the
new one, and up to 2 older kept); when there are 4 or more, it tried to
delete the third more recent (taking the new one into account.)
I understand logic has to evolve sometimes, particularly since the aims
of MINIX are changing; however I feel that one was perhaps a bug or a
missed point, rather than a feature.
If so, then I'm not sure.
> It seems like if you had one existing version, then the new one would be
> added, the old one would be "shifted" out
No; the one which is shifted away is the first in the list, i.e. .temp,
the new added one.