Re: setup

[Achim Gratz <Stromeko at nexgo dot de>]

Corinna Vinschen writes:
>> Why?  In any case it'd be easy enough to make it switchable.
>
> Transition period.  We should do changes like that in two steps, first
> updating to a setup which handles the new checksums, then changing the
> generation of checksums to the new method.  Like we did with
> MD5->SHA512.  It's smoother that way.  It's also certainly not a bad
> idea to continue supporting the older checksum methods.  You're very
> likely not the only person creating his/her own setup.ini files and
> every change may break a script elsewhere :)

Yes, but in this case you're really talking about the setup.exe side,
not the generation of the setup via upset or genini (which I thought you
were talking about, since that's the part implemented in Perl).  If we
use the SHA512: prefix then both hex and base64 encoded checksum are
distinguishable easily and we might even throw in MD5 just for fun.  I
don't see off-hand why either upset or genini should be capable of
emitting both styles into the same setup.ini, but it is easy enough to
do this per setup.ini file creation by adding an option to specify which
digest you want.

> You seem to be doing this on a regular basis with your own scripts.  Is
> that right?  Would you think your own method is just hacked to work, or
> do you think your own ini creation scripts are clean enough to release
> them to the public?

No, it's fairly sophisticated already, but not yet feature-complete and
requires a few clean-ups (don't they always?).

> I'm asking because, right now, we're relying on a convoluted perl script
> set which is hard to understand (at least for non-perl guys), is missing
> comments, has no maintainer, and above all, has a questionable license.

What I have is also mostly a Perl script plus a few CMD files around it,
so that part likely wouldn't change.

> Upset is a beast.  It handles ini file creation as well as creating the
> package information for https://cygwin.com/cgi-bin2/package-grep.cgi,
> as well as the package upload post-processing.

Since I can't even look at upset, I use genini for the initial setup.ini
creation for any local packages (I have many of those).  The rest of the
process is taking multiple setup.ini files and rewrites them into a new
one, then installs the necessary files into a staging area, which can
optionally be cleaned of files not being referenced anymore after an
update or change of packages to install.  The staging area is then
replicated onto the real installation directory.  This is under control
of a setup.conf file that looks more or less exactly like the name
implies.  You define your package sources and their dependency order
(should they provide the same package, which is what happens for
packages that I carry local patches for), and then list the packages you
want to have available (you can inject new group names so it's easier to
install via setup.exe).  Dependencies are pulled in automatically and
you can specify that you want an experimental or previous package
instead of current.  It can also automatically pull devel and debug
packages into groups so that they do not clutter the install for
non-developer installs and are by default available on those install
that are for developers.  You can also blacklist a package in some
package source if you want to reverse the order just for one package or
if there's a packaging error in an external package source.

> I would very much appreciate if we could split these tasks into separate,
> independent scripts or tools under GPL or BSD license.

Well, if we keep this as a task for Perl it would make most sense to put
those things into Perl modules, one per task.  If a standalone script is
preferred in some place we can always fatpack those modules again.

> So, what about your scripts?  Do you think they could be used as a
> start?  Do you have, perhaps, fun to rewrite the upset functionality in
> a maintainable form and *gasp* maintain it?

As I said, I'm coming at this from a different angle: the need to
integrate multiple package sources and make a new install hierarchy that
can be used locally, without being connected to the Internet and without
carrying all the baggage around that a full mirror would have.  Plus, I
need the install to be fully scriptable to install for users that have
no admin rights.

The features that I'm missing is explicit version pinning (unfortunately
I'll have to do some extensive changes under the hood to get rid of the
current prev-curr-test structure, didn't think of that early enough) and
the ability to keep different versions of an installation around.  I
sort of can do that already if I'm careful enough not to clean away
files that are still needed, but it's too fragile even for very sparse
usage, so I use the staging directory for release tests at the moment.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds