Mail Archives: cygwin-developers/2001/09/23/06:28:17
----- Original Message -----
From: "Christopher Faylor" <cgf AT redhat DOT com>
> I've checked in a new 'temp' directory in the sources.redhat.com
> repository. It contains the tools I used to create a populated
> setup.ini.
I'm assembling a little TODO list. it's pulled from my comments in this
email + a quick review of setup.exe. Chris, if you could comment on this
list - is anything missing, is anything inappropriate. I propose that
the net contributors use this TODO to get a category/dependency based
setup "out there".
So far:
1) show both package name and description. or provide a popup with the
description it. Something anyway.
2) Alter update-setup (if needed) to allow listing of category and
dependency information. As I understand it's operation, the contents of
setup.hint are copied verbatim so no changes should be needed.
3) create a complete list of allowed categories.
4) create initial setup.hint files for every package. (delegated to the
maintainers).
> "rh" is a perl script. If you say "rh -d setup.ini.base > setup.ini"
> it will create a setup.ini that is loosely based on debian categories
> and descriptions. setup.ini.base is any setup.ini created by DJ's
> update-setup script. I've recently posted a pointer to this script.
Where? I couldn't find a pointer for "update-setup" in the recent
history for cygwin-apps or -developers. I'll work on the presumtion that
it is the script that reads setup.hint and the files and creates
setup.ini from that.
> Without the "-d" the rh output is based on Red Hat's rpms. You do
need
> to have all of the packages on your system that are in the cygwin
> release to use this, though.
As I understand rh, it's meant to post process the output of DJ's
update-setup to create a categorised environment. I think this is the
wrong approach. I don't think we should be generically pulling in either
the rpm or debian information. (However, as a kick start for the meta
data it's ok, but not long term).
Possible option: As a use for "rh", how about we have it create
setup.hint files if they are missing, rather than a setup.ini. Then we
tweak those files by hand. It means that there will not be constant
tweaking of a script as things change. Maintainers can take
responsibility for putting things in the right category and
dependencies.
This gives up instant short term metadata in setup.hint for every
package and we should review that and then consider it authoritative.
That metadata will then become the responsibility of the maintainer to
keep up to date. We should have an authoritative list of categories as
well.
Long term the packages should have the metadata in them, so that local
packages auto assemble into the correct categories.
> The generated setup.ini file currently causes setup.exe to SEGV.
> It seems to get about as far as calling add_required for the ncurses
> package and then it starts recursively calling insert_pkg, for some
> reason. It would be great if someone could debug this.
"Works for me". Is the included setup.ini the one that crashes your
setup? If not, what exact options are needed to create the fault - or
better yet can you post the fault ini?
> I'm also open to other category names. You can see the ones that
> I/Debian used in setup.ini.
I suggest we agree on the TODO at the top, and then visit this as a
specific item. I'm partial to debian too :].
> As I was setting up the category names I could hear the cygwin mailing
> list voices asking "Why is gawk in the base category!!!??? I don't
like
> gawk! It sounds like someone is vomiting!" I'm wondering if our
category
> method will immediately prove that we really need something as
> sophisticated as rpm or apt.
Debian has gawk in base, because it's needed to operate some of the apt
update-foo scripts. I think the answer to that is the same as our
current one "we do not support a setup without foo". I.e. we will likely
end up with a very similar list of minimim packages needed for the post-
and pre-install scripts to operate properly.
> I was also wondering if we wanted to have a minimal category, too,
which
> only included bash, cygwin, ash, and...???
That would be the "Required" hard coded category. The name can obviously
be changed. I'd have said that it becomes "Base", but I have no
deliberated view.
> And, another thing that I thought would be neat would be for there to
be
> some way for users to specify their own categories so that a "Bob"
> category could contain "cygwin, bash, and libtiff" but nothing else.
Uhmm, walk first, please :]. IMO the way to do this is to allow merging
of metadata from an external file. Such a file could say things like:
category Bob
cygwin
bash
libtiff
category SSH
cygwin
bash
cygrunsrv
ssh
and these would merge into the setup.ini listed metadata. Not too hard
to do, but I think that having the basic stuff stable is more important
now.
> If you think you have a good idea but you don't wipe out a previous
> version of a setup.ini or rh file, feel free to add a new file to
> this directory for everyone's amazement and delight. As I said,
> I'll probably delete this directory eventually anyway.
Well my good idea is basically to delegate the responsibility and
authority to maintaing the category and depenency stuff to the
maintainers. IMO that solves the problem in one hit. We allow 1 week for
all the maintainers to create setup.hint files with category and
requires lines. At the end of the week we put up the new setup.exe.
Rob
- Raw text -