This is the mail archive of the cygwin-apps mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Multiple pending setup patches


Igor, I'm very thankful to have patches from you, and I appreciate that
you're contributing.  I seriously need to work on being more timely
about this.

Igor Pechtchanski wrote:

> Here's a list of setup patches I submitted in September:
> 
> <http://cygwin.com/ml/cygwin-apps/2005-09/msg00502.html>

This looks OK.  The solution I had in mind was to connect once to get
the setup.bz2, then disconnect, and create a new connection after
package selection.  But your method is much simpler.

> <http://cygwin.com/ml/cygwin-apps/2005-09/msg00503.html>
>         (GTG: <http://cygwin.com/ml/cygwin-apps/2005-09/msg00514.html>)

I suppose this is OK too.  The only reservation I have is that it
imposes a new requirement on all package maintainers: that if your
package contains a postinstall script you must include bash in the
"requires" line.  That is something that I think many packagers will get
wrong.  It's non-obvious because both bash and ash are in category Base
and can be assumed to exist on any system.  It might be better if setup
could figure this out on its own -- when unpacking the package if it
sees a .sh file in /etc/postinstall, it should add bash to the
dependencies if not there already.  But that's probably a bit overkill.

On the other hand, accidently omitting this dependency is probably no
worse than the current situation where the scripts are run in
alphabetical filename order.  So, go ahead.

Maybe we should update the setup.html page to explicitly state this. 
And it would be nice if we could run a quick script against the package
repository to check if there are currently any packages with postinstall
scripts that don't have bash on their requires line.

> <http://cygwin.com/ml/cygwin-apps/2005-09/msg00508.html>

OK.

> <http://cygwin.com/ml/cygwin-apps/2005-09/msg00538.html>

OK.

> <http://cygwin.com/ml/cygwin-apps/2005-09/msg00544.html>

OK.

> Some of them are rather important.  A big collective PING on all of them.

Go ahead and commit those.  And again, thanks.

I have been wanting to release a new setup with these and the other
minor fixes that have gone into it since the last release.  However,
there are two things I'd like to resolve first:

1. This time we should do a release candidate, and advertise its
availability on the main list.  With the last release there was a whole
flood of bug reports, which tells me that hardly anyone reads
cygwin-apps closely enough to tun test releases announced there.

2. I'd like to really fix this "package validation error" thing.  It's
certainly easy enough just to disable the error such that if the size of
the file on disk doesn't match that of setup.ini, it's just silently
ignored.  But since this validation code is used in all the various
install methods, this could also lead to the following scenario: User
selects "install from internet", connection closes early on one package
causing a truncated file, package validation code sees it as invalid and
silently pretends the package isn't there, and that package is simply
not installed.  If that package happened to be something like "cygwin"
or "libintl3" or another package required by many things, it will result
in a very borked installation.  A similar scenario exists if you do
"Download with installing" and then later "Install from local directory"
where one of the packages was truncated during the download phase.  At
some point a package with invalid size needs to either generate an
error, or cause a redownload.

I'm not even sure if the above scenarios are possible, because I haven't
checked.  My point is just that we can't just go disabling checks, we
need to make sure that if packages on disk are borked that we deal with
it in some way that doesn't cause a borked Cygwin installation
afterwards.

Brian


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]