Re: setup: problems with local install

[Jon Turney]

On 14/03/2018 19:24, Ken Brown wrote:

On 3/14/2018 12:07 PM, Jon Turney wrote:

On 12/03/2018 13:22, Ken Brown wrote:

On 3/8/2018 4:59 PM, Ken Brown wrote:

On 3/8/2018 10:59 AM, Ken Brown wrote:

On 3/7/2018 4:52 PM, Ken Brown wrote:

On 3/6/2018 1:47 PM, Jon Turney wrote:

On 06/03/2018 15:18, Jon Turney wrote:
I've found another problem with local installs: If a package needs 
upgrading, then the chooser will offer the upgraded version for 
install, even if there's no archive available.  As a result, the 
current version will get uninstalled, and then setup will discover 
that it doesn't have the archive to install the new version.


Thanks very much for finding this.

The problem occurs because packagedb::defaultTrust() is called 
after ScanDownloadedFiles() has already done its work. 
solution.update() and solution.trans2db() are called, and 
pkg->desired is set equal to an inaccessible version pv (which has 
been previously removed from pkg->versions).


I guess trans2db() should check that pv is in pkg->versions before 
acting on an install transaction for pv.  And then we also have to 
make sure to ignore the erase transaction for the current version 
of pkg.


Alternatively, can we just remove an inaccessible packageversion 
from the libsolv pool, or at at least just tell libsolv that we 
don't want to install it?


Attached is an attempt at that.

I think this is preferable, if it works correctly, as I think avoiding 
solutions with these unavailable versions is better than trying to 
massage the solution afterwards.


I agree, and it does seem to work correctly.  But there's one other case 
that it doesn't cover:  Suppose there's no archive for the installed 
version.  Even with your patch, the user can still choose 'Reinstall', 
which will fail.  The first of the patches from my previous email fixes 
this case.


Yes.  I applied that as well.

The subtlety I'd failed to grasp when I wrote that comment is that 
ScanDownloadedFiles() prunes versions which aren't available locally, 
*except* if they are already installed.


Thanks.

Re: setup: problems with local install

[Ken Brown]

On 3/14/2018 12:07 PM, Jon Turney wrote:

On 12/03/2018 13:22, Ken Brown wrote:

On 3/8/2018 4:59 PM, Ken Brown wrote:

On 3/8/2018 10:59 AM, Ken Brown wrote:

On 3/7/2018 4:52 PM, Ken Brown wrote:

On 3/6/2018 1:47 PM, Jon Turney wrote:

On 06/03/2018 15:18, Jon Turney wrote:
So yeah, I guess putting some complexity back in accessible() 
would work, or perhaps the attached?  (This doesn't do the right 
thing for a few packages, for reasons I'm still looking into...)


To be specific it was doing the wrong thing for those few packages 
with no source



  /* scan for local copies of package */
-void
+bool
  packagemeta::scan (const packageversion , bool mirror_mode)
  {
-  /* Already have something */
+  /* empty version */
    if (!pkg)
-    return;
+    return true;


So, this needs to be 'return false', as the empty version is 
always inaccessible, to get the same behaviour as before.


I've found another problem with local installs: If a package needs 
upgrading, then the chooser will offer the upgraded version for 
install, even if there's no archive available.  As a result, the 
current version will get uninstalled, and then setup will discover 
that it doesn't have the archive to install the new version.


Thanks very much for finding this.

The problem occurs because packagedb::defaultTrust() is called 
after ScanDownloadedFiles() has already done its work.  
solution.update() and solution.trans2db() are called, and 
pkg->desired is set equal to an inaccessible version pv (which has 
been previously removed from pkg->versions).


I guess trans2db() should check that pv is in pkg->versions before 
acting on an install transaction for pv.  And then we also have to 
make sure to ignore the erase transaction for the current version 
of pkg.


Alternatively, can we just remove an inaccessible packageversion 
from the libsolv pool, or at at least just tell libsolv that we 
don't want to install it?


Attached is an attempt at that.

I think this is preferable, if it works correctly, as I think avoiding 
solutions with these unavailable versions is better than trying to 
massage the solution afterwards.


I agree, and it does seem to work correctly.  But there's one other case 
that it doesn't cover:  Suppose there's no archive for the installed 
version.  Even with your patch, the user can still choose 'Reinstall', 
which will fail.  The first of the patches from my previous email fixes 
this case.


Ken

Re: setup: problems with local install

[Jon Turney]

On 12/03/2018 13:22, Ken Brown wrote:

On 3/8/2018 4:59 PM, Ken Brown wrote:

On 3/8/2018 10:59 AM, Ken Brown wrote:

On 3/7/2018 4:52 PM, Ken Brown wrote:

On 3/6/2018 1:47 PM, Jon Turney wrote:

On 06/03/2018 15:18, Jon Turney wrote:
So yeah, I guess putting some complexity back in accessible() 
would work, or perhaps the attached?  (This doesn't do the right 
thing for a few packages, for reasons I'm still looking into...)


To be specific it was doing the wrong thing for those few packages 
with no source



  /* scan for local copies of package */
-void
+bool
  packagemeta::scan (const packageversion , bool mirror_mode)
  {
-  /* Already have something */
+  /* empty version */
    if (!pkg)
-    return;
+    return true;


So, this needs to be 'return false', as the empty version is always 
inaccessible, to get the same behaviour as before.


I've found another problem with local installs: If a package needs 
upgrading, then the chooser will offer the upgraded version for 
install, even if there's no archive available.  As a result, the 
current version will get uninstalled, and then setup will discover 
that it doesn't have the archive to install the new version.


Thanks very much for finding this.

The problem occurs because packagedb::defaultTrust() is called after 
ScanDownloadedFiles() has already done its work.  solution.update() 
and solution.trans2db() are called, and pkg->desired is set equal to 
an inaccessible version pv (which has been previously removed from 
pkg->versions).


I guess trans2db() should check that pv is in pkg->versions before 
acting on an install transaction for pv.  And then we also have to 
make sure to ignore the erase transaction for the current version of 
pkg.


Alternatively, can we just remove an inaccessible packageversion 
from the libsolv pool, or at at least just tell libsolv that we 
don't want to install it?


Attached is an attempt at that.

I think this is preferable, if it works correctly, as I think avoiding 
solutions with these unavailable versions is better than trying to 
massage the solution afterwards.


Still another alternative, and maybe the simplest, is to make sure 
that the chooser never shows a version that is not in pkg->versions. 
packagemeta::set_action (trusts const trust) almost does this, except 
for one useless desired.accessible() call.  So that should be fixed, 
as well as the setting of the initial action.


Sorry for this stream of consciousness series of posts, but I'll stop 
after this one.  I think it's possible that restoring the previous 
meaning of 'accessible()', at least for local installs, might solve 
this problem.


Thanks for the patches.


From 2ec3a89555409b43b35a2d5a8f161c41c1a993d9 Mon Sep 17 00:00:00 2001
From: Jon Turney 
Date: Wed, 14 Mar 2018 14:52:57 +
Subject: [PATCH setup] Remove packages not found by scan from solver

Remove (not installed) packages not found by scan from solver, as well as
from packagemeta, to avoid solutions including them from being proposed.

Signed-off-by: Jon Turney 
---
 libsolv.cc  | 10 ++
 libsolv.h   |  2 ++
 package_meta.cc |  3 +++
 3 files changed, 15 insertions(+)

diff --git a/libsolv.cc b/libsolv.cc
index 674d576..fc4e5ec 100644
--- a/libsolv.cc
+++ b/libsolv.cc
@@ -304,6 +304,16 @@ SolvableVersion::compareVersions(const SolvableVersion ,
   return pool_evrcmp(pool, evra, evrb, EVRCMP_COMPARE);
 }
 
+void
+SolvableVersion::remove() const
+{
+  if (!id)
+return;
+
+  Solvable *solvable = pool_id2solvable(pool, id);
+  repo_free_solvable(solvable->repo, id, 0);
+}
+
 // ---
 // implements class SolverPool
 //
diff --git a/libsolv.h b/libsolv.h
index fc68895..7bb0be2 100644
--- a/libsolv.h
+++ b/libsolv.h
@@ -88,6 +88,8 @@ class SolvableVersion
   bool operator > (SolvableVersion const &) const;
   bool operator >= (SolvableVersion const &) const;
 
+  void remove() const;
+
  private:
   Id id;
   Pool *pool;
diff --git a/package_meta.cc b/package_meta.cc
index 8a33bcb..7f8110d 100644
--- a/package_meta.cc
+++ b/package_meta.cc
@@ -724,7 +724,10 @@ packagemeta::ScanDownloadedFiles (bool mirror_mode)
pkg.curr = packageversion ();
  if (pkg.exp == *i)
pkg.exp = packageversion ();
+
+ i->remove();
  pkg.versions.erase (i++);
+
  /* For now, leave the source version alone */
}
  else
-- 
2.16.2

Re: setup: problems with local install

[Ken Brown]

On 3/8/2018 4:59 PM, Ken Brown wrote:

On 3/8/2018 10:59 AM, Ken Brown wrote:

On 3/7/2018 4:52 PM, Ken Brown wrote:

On 3/6/2018 1:47 PM, Jon Turney wrote:

On 06/03/2018 15:18, Jon Turney wrote:
So yeah, I guess putting some complexity back in accessible() would 
work, or perhaps the attached?  (This doesn't do the right thing 
for a few packages, for reasons I'm still looking into...)


To be specific it was doing the wrong thing for those few packages 
with no source



  /* scan for local copies of package */
-void
+bool
  packagemeta::scan (const packageversion , bool mirror_mode)
  {
-  /* Already have something */
+  /* empty version */
    if (!pkg)
-    return;
+    return true;


So, this needs to be 'return false', as the empty version is always 
inaccessible, to get the same behaviour as before.


I've found another problem with local installs: If a package needs 
upgrading, then the chooser will offer the upgraded version for 
install, even if there's no archive available.  As a result, the 
current version will get uninstalled, and then setup will discover 
that it doesn't have the archive to install the new version.


The problem occurs because packagedb::defaultTrust() is called after 
ScanDownloadedFiles() has already done its work.  solution.update() 
and solution.trans2db() are called, and pkg->desired is set equal to 
an inaccessible version pv (which has been previously removed from 
pkg->versions).


I guess trans2db() should check that pv is in pkg->versions before 
acting on an install transaction for pv.  And then we also have to 
make sure to ignore the erase transaction for the current version of 
pkg.


Alternatively, can we just remove an inaccessible packageversion from 
the libsolv pool, or at at least just tell libsolv that we don't want 
to install it?


Still another alternative, and maybe the simplest, is to make sure 
that the chooser never shows a version that is not in pkg->versions. 
packagemeta::set_action (trusts const trust) almost does this, except 
for one useless desired.accessible() call.  So that should be fixed, 
as well as the setting of the initial action.


Sorry for this stream of consciousness series of posts, but I'll stop 
after this one.  I think it's possible that restoring the previous 
meaning of 'accessible()', at least for local installs, might solve this 
problem.


Patches attached (for the topic/fix-local-install branch).

From 1645f2b13616ec71054a5ad35bce864f1f3e0dca Mon Sep 17 00:00:00 2001
From: Ken Brown <kbr...@cornell.edu>
Date: Sun, 11 Mar 2018 10:43:06 -0400
Subject: [PATCH 1/2] Make SolvableVersion::accessible() useful for local
 installs

For a local install, make SolvableVersion::accessible() indicate
whether or not there is an archive available in the local cache.  This
is used in packagemeta::set_action() to prevent the chooser from
offering unavailable versions.
---
 libsolv.cc | 20 
 1 file changed, 8 insertions(+), 12 deletions(-)

diff --git a/libsolv.cc b/libsolv.cc
index 0dc7557..604ff7e 100644
--- a/libsolv.cc
+++ b/libsolv.cc
@@ -14,6 +14,7 @@
 #include "libsolv.h"
 #include "package_db.h"
 #include "package_meta.h"
+#include "resource.h"
 
 #include "solv/solver.h"
 #include "solv/solverdebug.h"
@@ -239,21 +240,16 @@ SolvableVersion::source() const
   return (packagesource *)repo_lookup_num(solvable->repo, id, psrc_attr, 
(unsigned long long)_source);
 }
 
+// If we're doing a locall install, is there an archive available?
+// This assumes that ScanDownloadedFiles() has already been called.
 bool
 SolvableVersion::accessible () const
 {
-  // The 'accessible' check used to test if an archive was available locally or
-  // from a mirror.
-  //
-  // This seems utterly pointless. as binary packages which aren't 'accessible'
-  // never get to appear in the package list.
-  //
-  // For source packages, it's equivalent to the bool conversion operator.)
-  //
-  if (id != 0)
-return TRUE;
-  else
-return FALSE;
+  if (id == 0)
+return false;
+  if (::source == IDC_SOURCE_LOCALDIR)
+return source ()->Cached ();
+  return true;
 }
 
 package_stability_t
-- 
2.16.2

From 365fa9afb8a49c2360bf7cfd2a2c2557522f85e5 Mon Sep 17 00:00:00 2001
From: Ken Brown <kbr...@cornell.edu>
Date: Mon, 12 Mar 2018 09:13:41 -0400
Subject: [PATCH 2/2] Don't put inaccessible packageversions in the package
 database

In a local install, libsolv might choose an inaccessible version for
install.  Change SolverSolution::trans2db() so that such a version is
never used.
---
 libsolv.cc | 12 
 1 file changed, 12 insertions(+)

diff --git a/libsolv.cc b/libsolv.cc
index 604ff7e..1342f3b 100644
--- a/libsolv.cc
+++ b/libsolv.cc
@@ -637,6 +637,8 @@ void
 SolverSolution::trans2db() const
 {
   packagedb db;
+  std::vector inaccessible;
+
   // First reset all packages to the "no change" state
   for (packagedb:

Re: setup: problems with local install

[Ken Brown]

On 3/8/2018 10:59 AM, Ken Brown wrote:

On 3/7/2018 4:52 PM, Ken Brown wrote:

On 3/6/2018 1:47 PM, Jon Turney wrote:

On 06/03/2018 15:18, Jon Turney wrote:
So yeah, I guess putting some complexity back in accessible() would 
work, or perhaps the attached?  (This doesn't do the right thing for 
a few packages, for reasons I'm still looking into...)


To be specific it was doing the wrong thing for those few packages 
with no source



  /* scan for local copies of package */
-void
+bool
  packagemeta::scan (const packageversion , bool mirror_mode)
  {
-  /* Already have something */
+  /* empty version */
    if (!pkg)
-    return;
+    return true;


So, this needs to be 'return false', as the empty version is always 
inaccessible, to get the same behaviour as before.


I've found another problem with local installs: If a package needs 
upgrading, then the chooser will offer the upgraded version for 
install, even if there's no archive available.  As a result, the 
current version will get uninstalled, and then setup will discover 
that it doesn't have the archive to install the new version.


The problem occurs because packagedb::defaultTrust() is called after 
ScanDownloadedFiles() has already done its work.  solution.update() 
and solution.trans2db() are called, and pkg->desired is set equal to 
an inaccessible version pv (which has been previously removed from 
pkg->versions).


I guess trans2db() should check that pv is in pkg->versions before 
acting on an install transaction for pv.  And then we also have to 
make sure to ignore the erase transaction for the current version of pkg.


Alternatively, can we just remove an inaccessible packageversion from 
the libsolv pool, or at at least just tell libsolv that we don't want 
to install it?


Still another alternative, and maybe the simplest, is to make sure that 
the chooser never shows a version that is not in pkg->versions. 
packagemeta::set_action (trusts const trust) almost does this, except 
for one useless desired.accessible() call.  So that should be fixed, as 
well as the setting of the initial action.


Sorry for this stream of consciousness series of posts, but I'll stop 
after this one.  I think it's possible that restoring the previous 
meaning of 'accessible()', at least for local installs, might solve this 
problem.


Ken

Re: setup: problems with local install

[Ken Brown]

On 3/7/2018 4:52 PM, Ken Brown wrote:

On 3/6/2018 1:47 PM, Jon Turney wrote:

On 06/03/2018 15:18, Jon Turney wrote:
So yeah, I guess putting some complexity back in accessible() would 
work, or perhaps the attached?  (This doesn't do the right thing for 
a few packages, for reasons I'm still looking into...)


To be specific it was doing the wrong thing for those few packages 
with no source



  /* scan for local copies of package */
-void
+bool
  packagemeta::scan (const packageversion , bool mirror_mode)
  {
-  /* Already have something */
+  /* empty version */
    if (!pkg)
-    return;
+    return true;


So, this needs to be 'return false', as the empty version is always 
inaccessible, to get the same behaviour as before.


I've found another problem with local installs: If a package needs 
upgrading, then the chooser will offer the upgraded version for install, 
even if there's no archive available.  As a result, the current version 
will get uninstalled, and then setup will discover that it doesn't have 
the archive to install the new version.


The problem occurs because packagedb::defaultTrust() is called after 
ScanDownloadedFiles() has already done its work.  solution.update() and 
solution.trans2db() are called, and pkg->desired is set equal to an 
inaccessible version pv (which has been previously removed from 
pkg->versions).


I guess trans2db() should check that pv is in pkg->versions before 
acting on an install transaction for pv.  And then we also have to make 
sure to ignore the erase transaction for the current version of pkg.


Alternatively, can we just remove an inaccessible packageversion from 
the libsolv pool, or at at least just tell libsolv that we don't want to 
install it?


Still another alternative, and maybe the simplest, is to make sure that 
the chooser never shows a version that is not in pkg->versions. 
packagemeta::set_action (trusts const trust) almost does this, except 
for one useless desired.accessible() call.  So that should be fixed, as 
well as the setting of the initial action.


Ken

Re: setup: problems with local install

[Ken Brown]

On 3/6/2018 1:47 PM, Jon Turney wrote:

On 06/03/2018 15:18, Jon Turney wrote:
So yeah, I guess putting some complexity back in accessible() would 
work, or perhaps the attached?  (This doesn't do the right thing for a 
few packages, for reasons I'm still looking into...)


To be specific it was doing the wrong thing for those few packages with 
no source



  /* scan for local copies of package */
-void
+bool
  packagemeta::scan (const packageversion , bool mirror_mode)
  {
-  /* Already have something */
+  /* empty version */
    if (!pkg)
-    return;
+    return true;


So, this needs to be 'return false', as the empty version is always 
inaccessible, to get the same behaviour as before.


I've found another problem with local installs: If a package needs 
upgrading, then the chooser will offer the upgraded version for install, 
even if there's no archive available.  As a result, the current version 
will get uninstalled, and then setup will discover that it doesn't have 
the archive to install the new version.


The problem occurs because packagedb::defaultTrust() is called after 
ScanDownloadedFiles() has already done its work.  solution.update() and 
solution.trans2db() are called, and pkg->desired is set equal to an 
inaccessible version pv (which has been previously removed from 
pkg->versions).


I guess trans2db() should check that pv is in pkg->versions before 
acting on an install transaction for pv.  And then we also have to make 
sure to ignore the erase transaction for the current version of pkg.


Alternatively, can we just remove an inaccessible packageversion from 
the libsolv pool, or at at least just tell libsolv that we don't want to 
install it?


Ken

Re: setup: problems with local install

[Achim Gratz]

Ken Brown writes:
> I think this one might be OK.  If I'm not mistaken,
> pkg.versions.erase(i++) passes a copy of i to erase, and then
> increments i before erase() has done its work.  But I'm no expert on
> this.

I can't cite chapter and verse right now, but AFAIK iterators over sets
are explicitly OK'ed for deleting the current element of the set
iterated over (that may be restricted to not changing direction of
iteration depending on which version of the standard the implementation
conforms to).


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

SD adaptation for Waldorf microQ V2.22R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: setup: problems with local install

[Jon Turney]

On 06/03/2018 19:31, Ken Brown wrote:

On 3/6/2018 10:18 AM, Jon Turney wrote:
(I also note we have also have another 'erase an element from a vector 
while we are iterating over it' here, so that needs fixing, as well)


I think this one might be OK.  If I'm not mistaken, 
pkg.versions.erase(i++) passes a copy of i to erase, and then increments 
i before erase() has done its work.  But I'm no expert on this.


I think that's still not ok for a vector, but this is actually a set, so 
there's actually no problem.


See e.g. [1], or refer to your copy of the C++ standard :)

[1] https://stackoverflow.com/questions/6438086/iterator-invalidation-rules

Re: setup: problems with local install

[Ken Brown]

On 3/6/2018 10:18 AM, Jon Turney wrote:
(I also note we have also have another 'erase an element from a vector 
while we are iterating over it' here, so that needs fixing, as well)


I think this one might be OK.  If I'm not mistaken, 
pkg.versions.erase(i++) passes a copy of i to erase, and then increments 
i before erase() has done its work.  But I'm no expert on this.


Ken

Re: setup: problems with local install

[Jon Turney]

On 06/03/2018 15:18, Jon Turney wrote:
So yeah, I guess putting some complexity back in accessible() would 
work, or perhaps the attached?  (This doesn't do the right thing for a 
few packages, for reasons I'm still looking into...)


To be specific it was doing the wrong thing for those few packages with 
no source



  /* scan for local copies of package */
-void
+bool
  packagemeta::scan (const packageversion , bool mirror_mode)
  {
-  /* Already have something */
+  /* empty version */
if (!pkg)
-return;
+return true;


So, this needs to be 'return false', as the empty version is always 
inaccessible, to get the same behaviour as before.

Re: setup: problems with local install

[Jon Turney]

On 06/03/2018 02:18, Ken Brown wrote:

On 3/5/2018 1:34 PM, Ken Brown wrote:

This is a followup to the thread started here:

   https://cygwin.com/ml/cygwin/2018-03/msg00027.html

There are two problems with installing from a local directory.

1. In the Category view, "No packages found" is displayed where it 
should say "All" in the first line of the list.  This is probably just 
a cosmetic issue, and I haven't tried to track it down yet.


This actually happens in all setup runs, not just local installs.  It 
looks like it was caused by the rearranging that was done in the 
following commit:


commit 0c539f7f7d86fb100f260f21367682fa2c0bb529
Author: Jon Turney 
Date:   Sat Nov 4 18:01:49 2017 +

     Correctly order preparing packagedb for chooser

I think the problem might be that createListview() is now called too 
early in ChooserPage::OnInit().  But it's not immediately obvious to me 
how to fix this without breaking something else.
I'm kind of inclined to fix this with the attached: I think we only ever 
got "No packages found" before if there were 0 packages, which 
presumably doesn't happen very often :)


We don't update this header if a search reduces the number of packages 
shown to 0, which might make some sort of sense.


(Also, weirdly, we don't remove empty categories from view, except if we 
are doing a search, but this seems to be deliberate? (PickView.cc:311))
From 1a0cf0a86088b4aae7d5a18953f7c214b07d8a03 Mon Sep 17 00:00:00 2001
From: Jon Turney 
Date: Tue, 6 Mar 2018 16:17:30 +
Subject: [PATCH setup] Always give the fake root category the name 'All'

After we rearranged things in 0c539f7f, it's now too early to tell if we
have any packages or not.

The only thing about this category that is ever used is it's name, so we
don't acually need to use the real 'All' category here.

Saying 'No packages found' was never particularly helpful here, so just use
a fake category with the fixed name 'All'.
---
 choose.cc | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/choose.cc b/choose.cc
index 9cf3a50..5a4d3ad 100644
--- a/choose.cc
+++ b/choose.cc
@@ -137,11 +137,8 @@ ChooserPage::createListview ()
 {
   SetBusy ();
   static std::vector empty_cat;
-  static Category dummy_cat (std::string ("No packages found."), empty_cat);
-  packagedb db;
-  packagedb::categoriesType::iterator it = db.categories.find("All");
-  Category  = (it == db.categories.end ()) ? dummy_cat : *it;
-  chooser = new PickView (cat);
+  static Category dummy_cat (std::string ("All"), empty_cat);
+  chooser = new PickView (dummy_cat);
   RECT r = getDefaultListViewSize();
   if (!chooser->Create(this, WS_CHILD | WS_HSCROLL | WS_VSCROLL | 
WS_VISIBLE,))
 throw new Exception (TOSTRING(__LINE__) " " __FILE__,
-- 
2.16.2

Re: setup: problems with local install

[Jon Turney]

On 05/03/2018 18:34, Ken Brown wrote:

This is a followup to the thread started here:

   https://cygwin.com/ml/cygwin/2018-03/msg00027.html

There are two problems with installing from a local directory.


Thanks very much for looking into these.

2. In several of the views, all packages from setup.ini are listed, even 
if there is no corresponding archive in the local directory.  What 
happens is that packagemeta::scan() calls pkg.source()->sites.clear() 
for such packages, but this information is never used to prevent the 
package from appearing in the list.


It used to be that such packages would be declared inaccessible, but 
SolvableVersion::accessible() no longer does this.


Jon, you wrote the following comment in the definition of 
SolvableVersion::accessible():


"The 'accessible' check used to test if an archive was available locally 
or from a mirror.  This seems utterly pointless as binary packages which 
aren't 'accessible' never get to appear in the package list."


Do we need to reinstate the old function of the accessibility check?


I guess I looked at packagemeta::ScanDownloadedFiles() and saw that it 
was removing versions, and thought everything was good.


I didn't notice accessible() was indirectly how the result of scan() was 
returned :S


So yeah, I guess putting some complexity back in accessible() would 
work, or perhaps the attached?  (This doesn't do the right thing for a 
few packages, for reasons I'm still looking into...)


(I also note we have also have another 'erase an element from a vector 
while we are iterating over it' here, so that needs fixing, as well)


I'm kind of uncertain what the side-effects of this code are when source 
!= IDC_SOURCE_LOCALDIR, or if they are desired?  Perhaps it's removing 
packages which have corrupt local copies or something?  It would be 
clearer to omit the whole thing in that case.


From d8aac08cf3d1ddf98ab9a6a8706b2c7b8bdfd7ad Mon Sep 17 00:00:00 2001
From: Jon Turney 
Date: Tue, 6 Mar 2018 14:56:40 +
Subject: [PATCH setup] Fix packagemeta::ScanDownloadedFiles

packagemeta::scan clears the site list if the package was not found, and
packagemeta::ScanDownloadedFiles uses packageversion::accessible() to check
that.

Instead communicate via a return value
---
 package_meta.cc | 27 ---
 package_meta.h  |  2 +-
 2 files changed, 13 insertions(+), 16 deletions(-)

diff --git a/package_meta.cc b/package_meta.cc
index c488e35..f0a0c20 100644
--- a/package_meta.cc
+++ b/package_meta.cc
@@ -664,33 +664,30 @@ packagemeta::logSelectionStatus() const
 }
 
 /* scan for local copies of package */
-void
+bool
 packagemeta::scan (const packageversion , bool mirror_mode)
 {
-  /* Already have something */
+  /* empty version */
   if (!pkg)
-return;
+return true;
 
-  /* Remove mirror sites.
-   * FIXME: This is a bit of a hack.
-   */
   try
 {
   if (!check_for_cached (*(pkg.source ()), NULL, mirror_mode, false)
- && ::source == IDC_SOURCE_LOCALDIR)
-   pkg.source ()->sites.clear ();
+  && ::source == IDC_SOURCE_LOCALDIR)
+return false;
 }
   catch (Exception * e)
 {
   // We can ignore these, since we're clearing the source list anyway
   if (e->errNo () == APPERR_CORRUPT_PACKAGE)
-   {
- pkg.source ()->sites.clear ();
- return;
-   }
+return false;
+
   // Unexpected exception.
   throw e;
 }
+
+  return true;
 }
 
 void
@@ -712,15 +709,15 @@ packagemeta::ScanDownloadedFiles (bool mirror_mode)
   && (*i != pkg.installed
   || pkg.installed == pkg.curr
   || pkg.installed == pkg.exp);
- scan (*i, lazy_scan);
+ bool accessible = scan (*i, lazy_scan);
  packageversion foo = *i;
  packageversion pkgsrcver = foo.sourcePackage ();
- scan (pkgsrcver, lazy_scan);
+ bool src_accessible = scan (pkgsrcver, lazy_scan);
 
  /* For local installs, if there is no src and no bin, the version
   * is unavailable
   */
- if (!i->accessible () && !pkgsrcver.accessible ()
+ if (!accessible && !src_accessible
  && *i != pkg.installed)
{
  if (pkg.curr == *i)
diff --git a/package_meta.h b/package_meta.h
index 32372e2..600a163 100644
--- a/package_meta.h
+++ b/package_meta.h
@@ -170,7 +170,7 @@ protected:
 private:
   std::string trustLabel(packageversion const &) const;
   std::vector 

Re: setup: problems with local install

[Ken Brown]

On 3/5/2018 1:34 PM, Ken Brown wrote:

This is a followup to the thread started here:

   https://cygwin.com/ml/cygwin/2018-03/msg00027.html

There are two problems with installing from a local directory.

1. In the Category view, "No packages found" is displayed where it 
should say "All" in the first line of the list.  This is probably just a 
cosmetic issue, and I haven't tried to track it down yet.


This actually happens in all setup runs, not just local installs.  It 
looks like it was caused by the rearranging that was done in the 
following commit:


commit 0c539f7f7d86fb100f260f21367682fa2c0bb529
Author: Jon Turney 
Date:   Sat Nov 4 18:01:49 2017 +

Correctly order preparing packagedb for chooser

I think the problem might be that createListview() is now called too 
early in ChooserPage::OnInit().  But it's not immediately obvious to me 
how to fix this without breaking something else.


Ken

setup: problems with local install

[Ken Brown]

This is a followup to the thread started here:

  https://cygwin.com/ml/cygwin/2018-03/msg00027.html

There are two problems with installing from a local directory.

1. In the Category view, "No packages found" is displayed where it 
should say "All" in the first line of the list.  This is probably just a 
cosmetic issue, and I haven't tried to track it down yet.


2. In several of the views, all packages from setup.ini are listed, even 
if there is no corresponding archive in the local directory.  What 
happens is that packagemeta::scan() calls pkg.source()->sites.clear() 
for such packages, but this information is never used to prevent the 
package from appearing in the list.


It used to be that such packages would be declared inaccessible, but 
SolvableVersion::accessible() no longer does this.


Jon, you wrote the following comment in the definition of 
SolvableVersion::accessible():


"The 'accessible' check used to test if an archive was available locally 
or from a mirror.  This seems utterly pointless as binary packages which 
aren't 'accessible' never get to appear in the package list."


Do we need to reinstate the old function of the accessibility check?

Ken

xterm from local install

[Dan Berwick]

I have several Win7 64bit machines which cannot be connected to the
internet, and I can't install the xterm package. I am able to run with
the normal cygwin shell. I can start Xwin, but doesn't work very well.
Looking at the X log at least one problem is that it can't find xterm.
When I run setup, and search for xterm it comes up empty. It appears
the entire Misc group is missing.

I'm running setup64.exe version 2.795. To install cygwin on the
offline machines did the following steps

1) setup with the Download Without Installing
2) set local package directory to be in the same directory as the setup64.exe
3) Direct connection (and tried multiple sites)
4) Selected Install for the All category.
5) Went through all the groups and changed all Keep to Retrieve
and waited for download
6) Zipped setup64.exe, the log files and all the packages
7) Unzipped on the offline machine, updated paths in the log files
(different user name)

Much of the cygwin functionality works. I can ssh to a linux box and
work happily away. However, xterm does not seem to be installed and I
want it. Google has failed me (or my search design has failed me), so
I risk potential flame...

Any suggestions on how to get the xterm package installed on these
offline machines?

Thanks,
Dan

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: How to make setup.exe default to local-install?

[Grant Edwards]

On 2009-01-13, Larry Hall (Cygwin) reply-to-list-only...@cygwin.com wrote:
 On 01/12/2009, Grant Edwards wrote:
 It looks like a batch file would work, but it pops up a
 nuisance console window.  [Question: does local directory
 refer to the directory where setup.exe is located or to the
 current working directory?]

 It refers to the local directory containing all the packages
 in the directory structure you get when you download packages.
 So it is neither the directory where 'setup.exe' is located
 not the current working directory.

If it's neither the current working directory nor the directory
where setup.exe is located, then how does setup.exe know where
to find it?

-- 
Grant


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: How to make setup.exe default to local-install?

[Grant Edwards]

On 2009-01-13, Larry Hall (Cygwin) reply-to-list-only...@cygwin.com wrote:
 On 01/12/2009, Grant Edwards wrote:
 It looks like a batch file would work, but it pops up a
 nuisance console window.  [Question: does local directory
 refer to the directory where setup.exe is located or to the
 current working directory?]

 It refers to the local directory containing all the packages in the
 directory structure you get when you download packages.

We haven't downloaded packages yet.  All we've done is start up
setup.exe and we're sitting looking at the first screen.

 So it is neither the directory where 'setup.exe' is located
 not the current working directory.

If you believe the setup.exe source code, it is the currrent
working directory.  The three choices are:

 IDC_SOURCE_DOWNLOAD
 IDC_SOURCE_NETINST
 IDC_SOURCE_CWD 

AFAICT, CWD stands for current working directory.

-- 
Grant Edwards   grante Yow! I want another
  at   RE-WRITE on my CEASAR
   visi.comSALAD!!


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: How to make setup.exe default to local-install?

[Grant Edwards]

On 2009-01-13, Grant Edwards gra...@visi.com wrote:
 On 2009-01-13, Larry Hall (Cygwin) reply-to-list-only...@cygwin.com wrote:
 On 01/12/2009, Grant Edwards wrote:
 It looks like a batch file would work, but it pops up a
 nuisance console window.  [Question: does local directory
 refer to the directory where setup.exe is located or to the
 current working directory?]

 It refers to the local directory containing all the packages in the
 directory structure you get when you download packages.

 We haven't downloaded packages yet.  All we've done is start up
 setup.exe and we're sitting looking at the first screen.

My mistake.  We're at the second screen Choose a download source.

-- 
Grant Edwards   grante Yow! I'm RELIGIOUS!!
  at   I love a man with
   visi.coma HAIRPIECE!!  Equip me
   with MISSILES!!


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: How to make setup.exe default to local-install?

[Larry Hall (Cygwin)]

Grant Edwards wrote:

On 2009-01-13, Larry Hall (Cygwin) reply-to-list-only-lh AT cygwin DOT com 
wrote:

  ^^
http://cygwin.com/acronyms/#PCYMTNQREAIYR.  Thanks.

On 01/12/2009, Grant Edwards wrote:

It looks like a batch file would work, but it pops up a
nuisance console window.  [Question: does local directory
refer to the directory where setup.exe is located or to the
current working directory?]

It refers to the local directory containing all the packages
in the directory structure you get when you download packages.
So it is neither the directory where 'setup.exe' is located
not the current working directory.


If it's neither the current working directory nor the directory
where setup.exe is located, then how does setup.exe know where
to find it?


Are you only interested in knowing where the local directory defaults
to the first time it is run on a machine without a Cygwin installation?
If so, then yes, it is CWD.  Otherwise, the local directory is the local
package directory where packages were downloaded last time, which may
not be the synonymous with the CWD at the time that you start 'setup.exe'.
In any case, the local directory to use is stored in
'/etc/setup/last-cache'.

--
Larry Hall  http://www.rfk.com
RFK Partners, Inc.  (508) 893-9779 - RFK Office
216 Dalton Rd.  (508) 893-9889 - FAX
Holliston, MA 01746

_

A: Yes.
 Q: Are you sure?
 A: Because it reverses the logical flow of conversation.
 Q: Why is top posting annoying in email?

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: How to make setup.exe default to local-install?

[Grant Edwards]

On 2009-01-13, Larry Hall (Cygwin) reply-to-list-only...@cygwin.com wrote:

 Are you only interested in knowing where the local directory defaults
 to the first time it is run on a machine without a Cygwin installation?

Yes.

 If so, then yes, it is CWD.

Thanks for confirming that.  That's what my experiments and
examination of setup.exe sources have shown.

-- 
Grant Edwards   grante Yow! !  Now I understand
  at   advanced MICROBIOLOGY and
   visi.comth' new TAX REFORM laws!!


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

How to make setup.exe default to local-install?

[Grant Edwards]

I'm creating a Cygwin snapshot for installation from CD, and
I've got everything figured out except for one thing: I need
setup.exe to default to a local install.  I can't use a
shortcut to run setup.exe because shortcuts have absolute paths.

It looks like a batch file would work, but it pops up a
nuisance console window.  [Question: does local directory
refer to the directory where setup.exe is located or to the
current working directory?]

I suppose I could build a custom setup.exe that checks the
local install radio button by default instead of the network
install button.  But I was hoping there was somthing a little
easier.

-- 
Grant Edwards   grante Yow! does your DRESSING
  at   ROOM have enough ASPARAGUS?
   visi.com


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: How to make setup.exe default to local-install?

[Larry Hall (Cygwin)]

On 01/12/2009, Grant Edwards wrote:

It looks like a batch file would work, but it pops up a
nuisance console window.  [Question: does local directory
refer to the directory where setup.exe is located or to the
current working directory?]


It refers to the local directory containing all the packages in the
directory structure you get when you download packages.  So it is
neither the directory where 'setup.exe' is located not the current
working directory.

--
Larry Hall  http://www.rfk.com
RFK Partners, Inc.  (508) 893-9779 - RFK Office
216 Dalton Rd.  (508) 893-9889 - FAX
Holliston, MA 01746

_

A: Yes.
 Q: Are you sure?
 A: Because it reverses the logical flow of conversation.
 Q: Why is top posting annoying in email?

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Using cygport for a local install

[Ken Brown]

Suppose I want to modify and rebuild a cygwin package that was created 
using cygport.  I may want to install it in /usr/local to avoid conflict 
with the official version.  One way to do this (I think) is to add 
options like --prefix=/usr/local, --bindir=/usr/local/bin, etc., to the 
call to cygconf.  Is this the recommended method, or does cygport 
provide a simpler way to do it?


Ken


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Using cygport for a local install

[Yaakov (Cygwin/X)]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Ken Brown wrote:
 Suppose I want to modify and rebuild a cygwin package that was created
 using cygport.  I may want to install it in /usr/local to avoid conflict
 with the official version.  One way to do this (I think) is to add
 options like --prefix=/usr/local, --bindir=/usr/local/bin, etc., to the
 call to cygconf.  Is this the recommended method, or does cygport
 provide a simpler way to do it?

cygport was made for creating distributable Cygwin packages, so it is
set to use the /usr prefix.  There is no easy way to override that.


Yaakov
Cygwin/X
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEAREIAAYFAkkrKg8ACgkQpiWmPGlmQSNn+gCggmuMeMUW/yqXAD/cis+odUUu
910AoNo1cTDNIcDF33cYJhZ1ddfywXZ0
=QgY+
-END PGP SIGNATURE-

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Downloading (parts of) Cygwin for later local install?

[Larry Hall (Cygwin)]

On 11/18/2008, tomas wrote:

Hey -- may I copy that?


Since I did, I suppose it's OK. ;-)

--
Larry Hall  http://www.rfk.com
RFK Partners, Inc.  (508) 893-9779 - RFK Office
216 Dalton Rd.  (508) 893-9889 - FAX
Holliston, MA 01746

_

A: Yes.
 Q: Are you sure?
 A: Because it reverses the logical flow of conversation.
 Q: Why is top posting annoying in email?

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Downloading (parts of) Cygwin for later local install?

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

is there an easy way of pre-downloading whatever is necessary to do a
later local Cygwin install?

Note: the recommended method of using Cygwin itself is not available to
me, since I only have a GNU/Linux computer on the Net (lucky me ;-)

Wgetting all of http://cygwin.com/packages/ would seem a tad wasteful
to me (plus I don't know whether the cygwin installer does any magical
munging on the packages while downloading).

I trolled the lists and the FAQ, but I seem to be moving in circles.

Regards
- -- tomás
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFJIS+1Bcgs9XrR2kYRAm4lAJsGSJfKJL1A6sWrIqTDOJwh4dy79wCfYB2l
zVdVcf25lJ4MqK/OcpPUFW4=
=pcpK
-END PGP SIGNATURE-

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Downloading (parts of) Cygwin for later local install?

[Larry Hall (Cygwin)]

[EMAIL PROTECTED] wrote:

is there an easy way of pre-downloading whatever is necessary to do a
later local Cygwin install?

Note: the recommended method of using Cygwin itself is not available to
me, since I only have a GNU/Linux computer on the Net (lucky me ;-)

Wgetting all of http://cygwin.com/packages/ would seem a tad wasteful
to me (plus I don't know whether the cygwin installer does any magical
munging on the packages while downloading).


No magic download munging, no.  'wget' will work and is the recommmended
approach if what you want is a mirror.


I trolled the lists and the FAQ, but I seem to be moving in circles.


The FAQ doesn't like trolls. ;-)

http://cygwin.com/cygwin-ug-net/setup-net.html#id314711


--
Larry Hall  http://www.rfk.com
RFK Partners, Inc.  (508) 893-9779 - RFK Office
216 Dalton Rd.  (508) 893-9889 - FAX
Holliston, MA 01746

_

A: Yes.
 Q: Are you sure?
 A: Because it reverses the logical flow of conversation.
 Q: Why is top posting annoying in email?

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Downloading (parts of) Cygwin for later local install?

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Mon, Nov 17, 2008 at 07:25:13PM -0500, Larry Hall (Cygwin) wrote:
 [EMAIL PROTECTED] wrote:
 is there an easy way of pre-downloading whatever is necessary to do a
 later local Cygwin install?

[...]

 No magic download munging, no.  'wget' will work and is the recommmended
 approach if what you want is a mirror.

Thanks -- I'll try that.

 I trolled the lists and the FAQ, but I seem to be moving in circles.

 The FAQ doesn't like trolls. ;-)

Ah, so that's why ;-))

 http://cygwin.com/cygwin-ug-net/setup-net.html#id314711

Ugh. So it was there, right in front of my nose. Thanks a million for
the pointer.

 A: Yes.
  Q: Are you sure?
  A: Because it reverses the logical flow of conversation.
  Q: Why is top posting annoying in email?

Hey -- may I copy that?

Regards
- -- tomás
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFJImHNBcgs9XrR2kYRAqPJAJ9ZYa1EB+LwZ4yClrgoqcxpuNFvOQCdFlNl
uyJlAd5V2t9ayvxJ3mqumic=
=UF4B
-END PGP SIGNATURE-

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Missing cygwin1.dll per local install attempt

[Scott Ehrlich]

I visited http://www.cygwin.com/setup.exe and downloaded the file to a 
folder called c:\temp\cygwin on my WinXP system.


I ran it, selected the option to download installation files only (do not 
actually install) and directed Cygwin to download the files to 
c:\temp\cygwin


Selected my preferred mirror, and selected a FULL install.

After all files were downloaded, I copied the c:\temp\cygwin directory to 
a USB stick and put it in a system not connected to the Internet.


I copied the cygwin folder from the USB stick to c:\cygwin

I ran setup from c:\cygwin (i.e. the hard drive) and told it to perform a 
local install.


At the end, while trying to run the post install scripts, it kept 
complaining it could not find cygwin1.dll.


After acknowledging the error a few times, Cygwin presented the Congrats! 
window and offered to put a cygwin shortcut on the desktop and my start 
menu.


Why could it not install the cygwin1.dll?   I've used cygwin for years, 
and I think this is the first time I've come across this.


I did perform google searching on this, but found a couple messages from 
2001 and 2003 that didn't really seem to help.


Thanks.

Scott

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

RE: Missing cygwin1.dll per local install attempt

[Jeff Hawk]

 -Original Message-
 From: On
 Behalf Of Scott Ehrlich
 Sent: Wednesday, June 27, 2007 12:02 PM
 To:
 Subject: Missing cygwin1.dll per local install attempt

 I visited http://www.cygwin.com/setup.exe and downloaded the file to a
 folder called c:\temp\cygwin on my WinXP system.

 I ran it, selected the option to download installation files only (do
 not
 actually install) and directed Cygwin to download the files to
 c:\temp\cygwin

 Selected my preferred mirror, and selected a FULL install.

 After all files were downloaded, I copied the c:\temp\cygwin directory
 to
 a USB stick and put it in a system not connected to the Internet.

 I copied the cygwin folder from the USB stick to c:\cygwin

 I ran setup from c:\cygwin (i.e. the hard drive) and told it to perform
 a
 local install.

 At the end, while trying to run the post install scripts, it kept
 complaining it could not find cygwin1.dll.

 After acknowledging the error a few times, Cygwin presented the
 Congrats!
 window and offered to put a cygwin shortcut on the desktop and my start
 menu.

 Why could it not install the cygwin1.dll?   I've used cygwin for years,
 and I think this is the first time I've come across this.

It does not really install cygwin1.dll. It's in the c:\cygwin\bin directory.

Is there anything else unusual about this install?

--Jeff

*The information contained in this communication may be CONFIDENTIAL and is 
intended only for the use of the recipient(s) named above. If you are not the 
intended recipient, you are hereby notified that any dissemination, 
distribution, or copying of this communication, or any of its contents, is 
strictly prohibited. If you have received this communication in error, please 
notify the sender and delete/destroy the original message and any copy of it 
from your computer or paper files.

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Missing cygwin1.dll per local install attempt

[Larry Hall (Cygwin)]

Scott Ehrlich wrote:
I visited http://www.cygwin.com/setup.exe and downloaded the file to a 
folder called c:\temp\cygwin on my WinXP system.


I ran it, selected the option to download installation files only (do 
not actually install) and directed Cygwin to download the files to 
c:\temp\cygwin


Selected my preferred mirror, and selected a FULL install.

After all files were downloaded, I copied the c:\temp\cygwin directory 
to a USB stick and put it in a system not connected to the Internet.


I copied the cygwin folder from the USB stick to c:\cygwin

I ran setup from c:\cygwin (i.e. the hard drive) and told it to perform 
a local install.


snip

If you didn't tell it to install in some directory other than the default,
then you ended up installing in the root directory for the packages.  In
the past, there have been problems when doing this.  The solution is to
copy the packages to a different directory (not under 'c:/cygwin') or
install Cygwin into some other directory.  Either way, you should remove
your broken install and try again.


--
Larry Hall  http://www.rfk.com
RFK Partners, Inc.  (508) 893-9779 - RFK Office
216 Dalton Rd.  (508) 893-9889 - FAX
Holliston, MA 01746

_

A: Yes.
 Q: Are you sure?
 A: Because it reverses the logical flow of conversation.
 Q: Why is top posting annoying in email?

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Missing cygwin1.dll per local install attempt

[Scott Ehrlich]

I tried all methods suggested by everyone, and nothing worked.   So I 
cheated and updated my working version of Cygwin to the latest, then 
copied the dlls from c:\cygwin\bin to a USB stick, plugged the usb stick 
into the isolated PC, and while I got Cygwin set up and installing, copied 
the DLLs from the USB stick to c:\cygwin\bin on the destination system.


That worked fine.

I'd still like to know why the DLLs didn't install from a local install 
attempt of Cygwin.  It simply prevented the Bash post install scripts from 
running.  But after my manual copying, the script worked fine.


Scott

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

cygwin setup local install

[bertrand marquis]

Hello,

i need to run the cygwin setup with the quiet option using the
local-install option but the setup is always loking for the packages in
the directory where cygwin packages have first been stored

is there an option to specifie where is the local packages directory ?

thanks

Re: setup dies on local install

[Robert Collins]

On Fri, 2003-02-28 at 12:43, Steve Miller wrote:

 (Why,
 oh why, dear God, can't Red Hat just make a big
 archive file?) 

For the same reason you haven't read the FAQ
http://cygwin.com/faq/faq.html#SEC14.

Rob
-- 
GPG key available at: http://users.bigpond.net.au/robertc/keys.txt.


signature.asc
Description: This is a digitally signed message part

Re: setup dies on local install

[Christopher Faylor]

On Fri, Feb 28, 2003 at 08:54:30PM +1100, Robert Collins wrote:
On Fri, 2003-02-28 at 12:43, Steve Miller wrote:

 (Why,
 oh why, dear God, can't Red Hat just make a big
 archive file?) 

For the same reason you haven't read the FAQ
http://cygwin.com/faq/faq.html#SEC14.

In Soviet Russia, the FAQ reads you!

Sorry.  SlashDot humor.

cgf

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

setup dies on local install

[Steve Miller]

Hi,

I downloaded everything labeled base and whatever
else I wanted from a Cygwin mirror, preserving the
directory tree, so I could burn a CD for installs on
two machines that will not have internet access. (Why,
oh why, dear God, can't Red Hat just make a big
archive file?) 

So before burning the CD, I try a test install on
Windows 2000 running as the guest OS on a virtual
machine. At least six times, setup dies immediately
after the series of dialogues at the beginning. There
is NOTHING in the setup logs besides a message
claiming that setup has ended or something like that
-- when I _do_ get a log.

Once, I somehow managed a partial install, but all
that got was a dos prompt that promptly vanished.

I am removing the cygwin root directory and registry
entry and shortcuts between attempts. Any ideas? There
is nothing in the FAQ or on the mailing lists that
I've been able to find that looks remotely helpful.

Thanks,

Steve

__
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: setup dies on local install

[Randall R Schulz]

Steve,

Did you use Setup to do the download, or did you use some other tool? 
If it was the latter, then most likely you did not create the proper 
directory naming convention required by Setup.exe.

As for providing Cygwin in a single grotesque tarball, that's really 
infeasible. Updates happen frequently, and each update would require a 
new multi-hundred-megabyte tarball. Furthermore, many (probably most) 
users would be required to download far more data than they want or need.

Check for the very recent posts about how to download under the 
Subject: Re: Setup Download from Internet Question.

This whole business comes under the going against the grain theme. 
You're going to have much better luck, far fewer headaches and keep you 
hair a lot longer if you do things the way they're intended to be done. 
Furthermore, you're going to be told that rolling your own 
installation procedure is not (kindly) supported here.

Randall Schulz

At 17:43 2003-02-27, Steve Miller wrote:
Hi,

I downloaded everything labeled base and whatever
else I wanted from a Cygwin mirror...
...

Thanks,

Steve


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: setup dies on local install

[Randall R Schulz]

At 18:27 2003-02-27, Igor Pechtchanski wrote:
On Thu, 27 Feb 2003, Randall R Schulz wrote:

 [snip]

 This whole business comes under the going against the grain theme.
 You're going to have much better luck, far fewer headaches and keep you
 hair a lot longer if you do things the way they're intended to be done.
 Furthermore, you're going to be told that rolling your own
 installation procedure is not (kindly) supported here.
Randall,

I'm sorry, but this is not quite correct.  The recent discussion about
rolling your own was not about an installation, but rather about
cygwin1.dll.  Which would be expected to coexist with the official
cygwin1.dll.  I think providing your own *mirrors*, whether in CD form or
on a network, is indeed encouraged.  Anyone wanting to do that is directed
to read http://sources.redhat.com/cygwin-apps/setup.html if they also
need to create a custom setup.ini file.
Igor


Igor,

I'm not sure I see how that follows. I was just responding to Steve's 
posting about the problems he had downloading and running Setup. Since 
he used the phrase preserving the directory tree, I guessed that he 
did not use Setup to do the download. Since the directory layout 
created and required by Setup is not identical to that existing on the 
mirror from which the install tarballs are downloaded, one has to take 
extra steps (such as those in my shell script) to create that structure.

Hence my hypothesis that he didn't properly recreate the required 
directory sturcture and my remarks that rolling your own is likely to 
cause one frustration.

Steve's original post didn't mention cygwin1.dll at all, so I don't see 
how it goes to questions of which cygwin1.dll is used.

Randall Schulz

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: setup dies on local install

[Steve Miller]

Randall,

In one word oh.

Didn't think that setup could do that ... but
I didn't try setup.exe in the first place 'cause I was
on a Linux box. It might be nice if there were some
way to download w/o resorting to an exe file.

When I get the chance, I'll run setup.exe from a
Windows machine w/ a CD burner.

Thanks. That stuff you'll feel as I shake your hand
will be my hair

Steve

--- Randall R Schulz [EMAIL PROTECTED] wrote:
 Steve,
 
 Did you use Setup to do the download, or did you use
 some other tool? 
 If it was the latter, then most likely you did not
 create the proper 
 directory naming convention required by Setup.exe.
 
 As for providing Cygwin in a single grotesque
 tarball, that's really 
 infeasible. Updates happen frequently, and each
 update would require a 
 new multi-hundred-megabyte tarball. Furthermore,
 many (probably most) 
 users would be required to download far more data
 than they want or need.
 
 Check for the very recent posts about how to
 download under the 
 Subject: Re: Setup Download from Internet
 Question.
 
 This whole business comes under the going against
 the grain theme. 
 You're going to have much better luck, far fewer
 headaches and keep you 
 hair a lot longer if you do things the way they're
 intended to be done. 
 Furthermore, you're going to be told that rolling
 your own 
 installation procedure is not (kindly) supported
 here.
 
 Randall Schulz
 
 
 At 17:43 2003-02-27, Steve Miller wrote:
 Hi,
 
 I downloaded everything labeled base and whatever
 else I wanted from a Cygwin mirror...
 
 ...
 
 Thanks,
 
 Steve
 
 
 --
 Unsubscribe info: 
 http://cygwin.com/ml/#unsubscribe-simple
 Bug reporting: http://cygwin.com/bugs.html
 Documentation: http://cygwin.com/docs.html
 FAQ:   http://cygwin.com/faq/
 


__
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: setup dies on local install

[Randall R Schulz]

Steve,

Well, you don't _have_ to use Setup.exe, but if you don't, you need to 
know how it re-arranges the directory structure between the mirror host 
and the local directory.

Again, check out the messages I referred to and choose either Michael 
Chase's (Perl) or my (BASH) scripts to do the download or show you how 
to construct some sort of download program of your own.

Randall Schulz

At 19:28 2003-02-27, Steve Miller wrote:
Randall,

In one word oh.

Didn't think that setup could do that ... but
I didn't try setup.exe in the first place 'cause I was
on a Linux box. It might be nice if there were some
way to download w/o resorting to an exe file.
When I get the chance, I'll run setup.exe from a
Windows machine w/ a CD burner.
Thanks. That stuff you'll feel as I shake your hand
will be my hair
Steve

--- Randall R Schulz [EMAIL PROTECTED] wrote:
 Steve,

 Did you use Setup to do the download, or did you use some other tool?
 If it was the latter, then most likely you did not create the proper
 directory naming convention required by Setup.exe.

 As for providing Cygwin in a single grotesque tarball, that's really
 infeasible. Updates happen frequently, and each update would require a
 new multi-hundred-megabyte tarball. Furthermore, many (probably most)
 users would be required to download far more data than they want or need.

 Check for the very recent posts about how to download under the
 Subject: Re: Setup Download from Internet  Question.

 This whole business comes under the going against the grain theme.
 You're going to have much better luck, far fewer headaches and keep you
 hair a lot longer if you do things the way they're intended to be done.
 Furthermore, you're going to be told that rolling your own
 installation procedure is not (kindly) supported here.

 Randall Schulz


 At 17:43 2003-02-27, Steve Miller wrote:
 Hi,
 
 I downloaded everything labeled base and whatever else I wanted 
from a Cygwin mirror...
 
 ...
 
 Thanks,
 
 Steve


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: setup dies on local install

[Igor Pechtchanski]

On Thu, 27 Feb 2003, Randall R Schulz wrote:

 At 18:27 2003-02-27, Igor Pechtchanski wrote:
 On Thu, 27 Feb 2003, Randall R Schulz wrote:
 
   [snip]
  
   This whole business comes under the going against the grain theme.
   You're going to have much better luck, far fewer headaches and keep you
   hair a lot longer if you do things the way they're intended to be done.
   Furthermore, you're going to be told that rolling your own
   installation procedure is not (kindly) supported here.
 
 Randall,
 
 I'm sorry, but this is not quite correct.  The recent discussion about
 rolling your own was not about an installation, but rather about
 cygwin1.dll.  Which would be expected to coexist with the official
 cygwin1.dll.  I think providing your own *mirrors*, whether in CD form or
 on a network, is indeed encouraged.  Anyone wanting to do that is directed
 to read http://sources.redhat.com/cygwin-apps/setup.html if they also
 need to create a custom setup.ini file.
  Igor

 Igor,

 I'm not sure I see how that follows. I was just responding to Steve's
 posting about the problems he had downloading and running Setup. Since
 he used the phrase preserving the directory tree, I guessed that he
 did not use Setup to do the download. Since the directory layout
 created and required by Setup is not identical to that existing on the
 mirror from which the install tarballs are downloaded, one has to take
 extra steps (such as those in my shell script) to create that structure.

 Hence my hypothesis that he didn't properly recreate the required
 directory sturcture and my remarks that rolling your own is likely to
 cause one frustration.

 Steve's original post didn't mention cygwin1.dll at all, so I don't see
 how it goes to questions of which cygwin1.dll is used.

 Randall Schulz

Randall,

Umm, yes, I can see that my post may be misinterpreted.  I was responding
to your comment that you're going to be told that rolling your own
installation procedure is not (kindly) supported here.  I recall exactly
that (creating a local mirror/distribution) being suggested by prominent
project members (including Chris Faylor, IIRC).  I understood that as an
encouragement to do so.  Sorry for the ambiguity.
Igor
P.S. Cygwin developers are just mean, so nothing is kindly supported
anyway, is it? ;-)
-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_[EMAIL PROTECTED]
 |,4-  ) )-,_. ,\ (  `'-'   Igor Pechtchanski
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

Oh, boy, virtual memory! Now I'm gonna make myself a really *big* RAMdisk!
  -- /usr/games/fortune


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

RE: setup.exe local install with 2.218.2.4 fails, 2.78.2.15works

[Kilroy, David]

 It seems that all of these bug reports are on Win2K and XP Pro.  
 Has anyone successfully tested the recent setup.exe releases 
 (since the MD5 updates) on either of these platforms?

I can confirm that setup 2.218.2.4 works on my Win2k SP2 box. Both install
from internet and install from local directory.

I did get the stack and parse errors in previous md5 setup snapshots.

In 2.218.2.4 you will also see a crash if you have a file in the local cache
directory with a 10 letter filename _and_ the string 'setup.ini' in the full
path/filename (Unfortunate if you edit setup.ini with emacs). This may or
may not have been fixed in .5 and .6; if it hasn't, see description below.


Dave.



line nos from 2.218.2.4 src posted to setup_snapshots.
ini.cc: find_routine

line 68:
  if (!strstr (path, setup.ini))
return;

...

line 85:
  /* Attempt to unescape the string */
  path[strlen(path) -10] = '\0';
  String mirror = rfc1738_unescape_part (path);

tries to put null terminator at the last separator.

If at this point you are at the root of the cache, and you are looking at
setup.ini, the byte _before_ path is touched (which may affect further
recursion of directories, see find.cc). The file is then parsed. Packages
added to the mirror 'setup.ini.

If we are looking at setup.ini in a cached mirror directory, everything
works fine.

If strlen(path) is 10 at this point (as with the file setup.ini~) the null
is placed at the first char of path, causing the rfc1738 code to segfault
(passing it a null string).

We attempt to process other files that match and do not cause this fault. If
it is indeed a setup backup, the package entries are added to the database
under a bad? mirror name (hence files will not be found if that package is
selected?).

Possible fix off the top of my head (which matches files _only_ called
setup.ini):

line 68:
if(!strcmp(path + strlen(path)- 9, setup.ini))


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

RE: setup.exe local install with 2.218.2.4 fails, 2.78.2.15works

[Robert Collins]

There is a newer version available ... .6 that has such a fix in it
already.

Rob

 -Original Message-
 From: Kilroy, David [mailto:[EMAIL PROTECTED]] 
 Sent: Tuesday, May 14, 2002 10:51 PM
 To: Cygwin
 Subject: RE: setup.exe local install with 2.218.2.4 fails, 
 2.78.2.15works
 
 
  It seems that all of these bug reports are on Win2K and XP Pro.
  Has anyone successfully tested the recent setup.exe releases 
  (since the MD5 updates) on either of these platforms?
 
 I can confirm that setup 2.218.2.4 works on my Win2k SP2 box. 
 Both install from internet and install from local directory.
 
 I did get the stack and parse errors in previous md5 setup snapshots.
 
 In 2.218.2.4 you will also see a crash if you have a file in 
 the local cache directory with a 10 letter filename _and_ the 
 string 'setup.ini' in the full path/filename (Unfortunate if 
 you edit setup.ini with emacs). This may or may not have been 
 fixed in .5 and .6; if it hasn't, see description below.
 
 
 Dave.
 
 
 
 line nos from 2.218.2.4 src posted to setup_snapshots.
 ini.cc: find_routine
 
 line 68:
   if (!strstr (path, setup.ini))
 return;
 
 ...
 
 line 85:
   /* Attempt to unescape the string */
   path[strlen(path) -10] = '\0';
   String mirror = rfc1738_unescape_part (path);
 
 tries to put null terminator at the last separator.
 
 If at this point you are at the root of the cache, and you 
 are looking at setup.ini, the byte _before_ path is touched 
 (which may affect further recursion of directories, see 
 find.cc). The file is then parsed. Packages added to the 
 mirror 'setup.ini.
 
 If we are looking at setup.ini in a cached mirror directory, 
 everything works fine.
 
 If strlen(path) is 10 at this point (as with the file 
 setup.ini~) the null is placed at the first char of path, 
 causing the rfc1738 code to segfault (passing it a null string).
 
 We attempt to process other files that match and do not cause 
 this fault. If it is indeed a setup backup, the package 
 entries are added to the database under a bad? mirror name 
 (hence files will not be found if that package is selected?).
 
 Possible fix off the top of my head (which matches files _only_ called
 setup.ini):
 
 line 68:
   if(!strcmp(path + strlen(path)- 9, setup.ini))
 
 
 --
 Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
 Bug reporting: http://cygwin.com/bugs.html
 Documentation: http://cygwin.com/docs.html
 FAQ:   http://cygwin.com/faq/
 
 

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

setup.exe local install with 2.218.2.4 fails, 2.78.2.15 works

[A Kerr]

With the current setup.exe 2.218.2.4 I successfully downloaded to my
local directory all Cygwin packages from ftp.nas.nasa.gov.  However when
installing from my local download directory, this version of setup.exe
caused a stack fault in module MSVCRT.dll at 0177:78010618.  I was
unable to correct this after rebooting, uninstalling previous (older)
setup.exe installed Cygwin, rebooting, installing current MS library
update, rebooting etc.  I was installing  into c:\cygwin, with options
all users, and unix file format.  The stack fault happened at the
actual install section of setup, but nothing was installed, and the
stack fault took about 5 minutes to occur, after setup had been running
at 100% cpu.

However when I switched to setup.exe version 2.78.2.15, it successfully
installed the same packages downloaded today by 2.218.2.4.  So the
problem appears to be in setup.exe 2.218.2.4, rather than the downloaded
packages or my system.

I'm running: Win98SE, all current MS patches/updates, IE6, etc, AMD
K6-2+

I'm willing to provide any other information to the developers if it
would help.


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: setup.exe local install with 2.218.2.4 fails, 2.78.2.15 works

[Christopher Faylor]

On Mon, May 13, 2002 at 11:58:35PM -0500, A Kerr wrote:
With the current setup.exe 2.218.2.4 I successfully downloaded to my
local directory all Cygwin packages from ftp.nas.nasa.gov.  However when
installing from my local download directory, this version of setup.exe
caused a stack fault in module MSVCRT.dll at 0177:78010618.

I just uploaded a new version of setup.exe to sources.redhat.com a few
minutes ago.  It should work better.

cgf

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: setup.exe local install with 2.218.2.4 fails, 2.78.2.15 works

[Alan Dobkin]

This new version (2.218.2.6) is the first release of setup.exe 
since the MD5 snapshots that doesn't suck up CPU and memory on 
W2K when installing from a local directory.  Unfortunately, it 
still doesn't work thouugh.  Now the window/process immediately 
disappears when it gets to the progress panel.  No logs are 
written.  If I run it with GDB, I get:

(gdb) run
Starting program: /cygdrive/C/Download/Cygwin/setupnew.exe
warning: LOG: 2 2002/05/14 01:25:31 Starting cygwin install, version
2.218.2.6
warning: LOG: 2 2002/05/14 01:25:31 Current Directory: c:\Download\Cygwin
warning: LOG: 2 2002/05/14 01:25:37 source: from cwd
warning: LOG: 2 2002/05/14 01:25:39 root: D:/cygwin binary system
warning: LOG: 2 2002/05/14 01:25:42 Selected local directory:
P:\Software\Windows\Cygwin
warning: LOG: 1 Found ini file - file://P:\Software\Windows\Cygwin/setup.ini

Program received signal SIGSEGV, Segmentation fault.
[Switching to thread 4124.0xf60]
0x6108d5f8 in ?? ()
(gdb) 

It seems that all of these bug reports are on Win2K and XP Pro.  
Has anyone successfully tested the recent setup.exe releases 
(since the MD5 updates) on either of these platforms?

Alan

--On Tuesday, May 14, 2002 1:13 AM -0400 Christopher Faylor
[EMAIL PROTECTED] wrote:

 On Mon, May 13, 2002 at 11:58:35PM -0500, A Kerr wrote:
 With the current setup.exe 2.218.2.4 I successfully downloaded to my 
 local directory all Cygwin packages from ftp.nas.nasa.gov.  However 
 when installing from my local download directory, this version of 
 setup.exe caused a stack fault in module MSVCRT.dll at 0177:78010618.
 
 I just uploaded a new version of setup.exe to sources.redhat.com 
 a few minutes ago.  It should work better.
 
 cgf

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Local install skips some packages

[Michael Bale]

Downloaded a few additional (cron, make, vim, ssmtp).
The default setup action is to skip the extras.
Would like the default to be install.
Can I change setup.exe behavior?


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

local install?

[Toni Mueller]

Hello,

after reading the docs on the web site and searching the list archive
on MARC a bit, there appears to be no supported way to install while
being offline Eg I will soon have a W2k box that I want to install on,
but certainly won't connect this box to the Internet to do it

So my current guess is that I can download some stuff using eg my Linux
workstation, put them on CD and then move the CD to the W2k box for
local installation there Can anyone please confirm that? Can anyone
please tell me which version of setupexe I should get to be able to
install from a local directory?

(Apart from that I always thought that doing online-installs is both
error-prone and insecure in most cases, and in general, a M$ disease -
why does RedHat do it?)


TIA!


Best,
--Toni++


--
Unsubscribe info:  http://cygwincom/ml/#unsubscribe-simple
Bug reporting: http://cygwincom/bugshtml
Documentation: http://cygwincom/docshtml
FAQ:   http://cygwincom/faq/

Re: local install?

[Randall R Schulz]

Markus,

At 07:31 2002-03-01, Markus Hoenicka wrote:
Hi,

Toni Mueller writes:
   So my current guess is that I can download some stuff using eg my Linux
   workstation, put them on CD and then move the CD to the W2k box for
   local installation there Can anyone please confirm that? Can anyone
   please tell me which version of setupexe I should get to be able to
   install from a local directory?

You lose a lot of the functionality of setupexe if you do it this way but 
you can certainly do this if you want to have a hard time


I don't understand this You get maximum flexibility by separate Download 
from Internet and Install from Local Directory operations That way you 
can download sources and have them at hand without unconditionally 
installing them

By copying my local installation cache to a CD, I can save others very 
large downloads

I cannot see this as a loss of functionality

Can you tell me some functionality only available when one uses Install 
from Internet?

Randall Schulz
Mountain View, CA USA




regards,
Markus


--
Unsubscribe info:  http://cygwincom/ml/#unsubscribe-simple
Bug reporting: http://cygwincom/bugshtml
Documentation: http://cygwincom/docshtml
FAQ:   http://cygwincom/faq/

Re: local install?

[Markus Hoenicka]

Randall,

the original poster's suggestion was not to use setup.exe to download
the packages, but rather a linux box. This way you lose the dependency
tracking in setup.exe (it does not run on Linux afaik), and to
make sure you don't miss a dependency and thus waste a CD you'd have
to download *all* available packages which is a waste of time.

I'm afraid you misunderstood my comments on this issue. I fully agree
that using setup.exe to first download and later install the packages
is the most versatile way of doing things. I just pointed out that
manually downloading the packages, thus bypassing setup.exe in the
first place, will have issues.

regards,
Markus

Randall R Schulz writes:
  You lose a lot of the functionality of setup.exe if you do it this way but 
  you can certainly do this if you want to have a hard time.
  
  
  I don't understand this. You get maximum flexibility by separate Download 
  from Internet and Install from Local Directory operations. That way you 
  can download sources and have them at hand without unconditionally 
  installing them.
  
  By copying my local installation cache to a CD, I can save others very 
  large downloads.
  
  I cannot see this as a loss of functionality.
  
  Can you tell me some functionality only available when one uses Install 
  from Internet?
  
  Randall Schulz
  Mountain View, CA USA
  
  
  ...
  
  regards,
  Markus
  

-- 
Markus Hoenicka, PhD
UT Houston Medical School
Dept. of Integrative Biology and Pharmacology
6431 Fannin MSB4.114
Houston, TX 77030
(713) 500-6313, -7477
(713) 500-7444 (fax)
[EMAIL PROTECTED]
http://ourworld.compuserve.com/homepages/hoenicka_markus/


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

RE: local install?

[Mark Sheppard]

Surely if you were bothering to make a CD you'd want to include
everything anyway, thus you wouldn't need dependency checking.

Mark.


-Original Message-
From: Markus Hoenicka [mailto:[EMAIL PROTECTED]]
Sent: 01 March 2002 15:51
To: Randall R Schulz; [EMAIL PROTECTED]
Subject: Re: local install?


Randall,

the original poster's suggestion was not to use setup.exe to download
the packages, but rather a linux box. This way you lose the dependency
tracking in setup.exe (it does not run on Linux afaik), and to
make sure you don't miss a dependency and thus waste a CD you'd have
to download *all* available packages which is a waste of time.

I'm afraid you misunderstood my comments on this issue. I fully agree
that using setup.exe to first download and later install the packages
is the most versatile way of doing things. I just pointed out that
manually downloading the packages, thus bypassing setup.exe in the
first place, will have issues.

regards,
Markus

Randall R Schulz writes:
  You lose a lot of the functionality of setup.exe if you do it this way
but 
  you can certainly do this if you want to have a hard time.
  
  
  I don't understand this. You get maximum flexibility by separate
Download 
  from Internet and Install from Local Directory operations. That way
you 
  can download sources and have them at hand without unconditionally 
  installing them.
  
  By copying my local installation cache to a CD, I can save others very 
  large downloads.
  
  I cannot see this as a loss of functionality.
  
  Can you tell me some functionality only available when one uses Install 
  from Internet?
  
  Randall Schulz
  Mountain View, CA USA

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: local install?

[Charles Wilson]

Randall R Schulz wrote:


 I don't understand this You get maximum flexibility by separate 
 Download from Internet and Install from Local Directory operations 
 That way you can download sources and have them at hand without 
 unconditionally installing them
 
 By copying my local installation cache to a CD, I can save others very 
 large downloads
 
 I cannot see this as a loss of functionality
 
 Can you tell me some functionality only available when one uses Install 
 from Internet?


Sure:  merging multiple mirrors into a seamless single-view 
installation  (Or, merging an official mirror site + Bob's archive of 
cool cygwin packages + My company's local cygwin ports into a single, 
always-up-to-date single seamless installation)  Sure, you could 
manually download the packages you are interested in from all 27 sites, 
merge them into a single local repo, and then do 'install-from-local' -- 
but setup's extra functionality automatically handles that stuff for 
you -- just point-n-click

--Chuck



--
Unsubscribe info:  http://cygwincom/ml/#unsubscribe-simple
Bug reporting: http://cygwincom/bugshtml
Documentation: http://cygwincom/docshtml
FAQ:   http://cygwincom/faq/

Re: local install?

[Randall R Schulz]

Chuck,

I cannot get setupexe to permit multiple selection of mirrors, so how is 
this magical seamless multi-mirror integration achieved? Can it be done 
without running setupexe more than once? If not, what's the advantage over 
separate download and install?

Furthermore, why doesn't the multi-mirror technique, however effected, work 
for separated download and install, too?

Lastly, am I correct in believing that if one wants to download anything 
but not install it (source, eg, or packages used by some at one's site 
but not by all) that separate download and install is the only way to 
accomplish this?

It still seems to me that control freaks are going to do as I do: Separate 
download and install

Randall Schulz
Mountain View, CA USA


At 07:47 2002-03-01, Charles Wilson wrote:
Randall R Schulz wrote:


I don't understand this You get maximum flexibility by separate 
Download from Internet and Install from Local Directory operations 
That way you can download sources and have them at hand without 
unconditionally installing them

By copying my local installation cache to a CD, I can save others very 
large downloads I cannot see this as a loss of functionality

Can you tell me some functionality only available when one uses Install 
from Internet?


Sure:  merging multiple mirrors into a seamless single-view 
installation  (Or, merging an official mirror site + Bob's archive of 
cool cygwin packages + My company's local cygwin ports into a single, 
always-up-to-date single seamless installation)  Sure, you could manually 
download the packages you are interested in from all 27 sites, merge them 
into a single local repo, and then do 'install-from-local' -- but setup's 
extra functionality automatically handles that stuff for you -- just 
point-n-click

--Chuck


--
Unsubscribe info:  http://cygwincom/ml/#unsubscribe-simple
Bug reporting: http://cygwincom/bugshtml
Documentation: http://cygwincom/docshtml
FAQ:   http://cygwincom/faq/

RE: local install?

[Markus Hoenicka]

Mark Sheppard writes:
  Surely if you were bothering to make a CD you'd want to include
  everything anyway, thus you wouldn't need dependency checking.
  

Thus qoth the man behind a fat pipe. I don't know about the original
poster's situation, but if you use a modem connection the dependency
checking is highly welcome to be a tad more selective with your
bandwidth.

regards,
Markus
-- 
Markus Hoenicka, PhD
UT Houston Medical School
Dept. of Integrative Biology and Pharmacology
6431 Fannin MSB4.114
Houston, TX 77030
(713) 500-6313, -7477
(713) 500-7444 (fax)
[EMAIL PROTECTED]
http://ourworld.compuserve.com/homepages/hoenicka_markus/


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: local install?

[Charles Wilson]

Randall R Schulz wrote:

 Chuck,
 
 I cannot get setupexe to permit multiple selection of mirrors, so how 
 is this magical seamless multi-mirror integration achieved? Can it be 
 done without running setupexe more than once? 


Yes -- you should be able to shift-click or ctrl-click select multiple 
items in the mirror list (assuming you are using the NEW setup snapshot 
20020225)

 If not, what's the 
 advantage over separate download and install?
 
 Furthermore, why doesn't the multi-mirror technique, however effected, 
 work for separated download and install, too?


Because there is no 'remote site selection' step if you are not 
installing/downloading  Sure, you could do a multi-site non-install 
download using setup, and then run setup in 'local dir' mode to install 
  But setup is NOT meant to be an archiving/mirroring tool  It is an 
installation tool  If you want a local mirror -- USE a mirroring tool 
  Good grief, wget has special mirroring options -- that's what I use


 Lastly, am I correct in believing that if one wants to download anything 
 but not install it (source, eg, or packages used by some at one's site 
 but not by all) that separate download and install is the only way to 
 accomplish this?


if the remote site provides a local version of setupini that accurately 
describes the contents of that remote site, then you should be able to 
select the (non-standard) site as a 'download location' and setupexe 
will merge all selected sites, and download (or dl/install) the most 
recent copy of each selected package, from whatever location has the 
most recent version  (incl packages from the non-standard site)


 It still seems to me that control freaks are going to do as I do: 
 Separate download and install

Sure  And some people (incl me) still boot their linux boxen into 
console mode and only run X when required  But that's still no reason 
not to develop xdm/gdm/kdm graphical logon managers

Currently, there are no sites that provide cygwin packages in 
setup-approved format, that are not part of the official cygwin mirror 
system  (Because until now, you couldn't use setup to install from 
ANYPLACE other than localdir or an *official* mirror site)  Now that 
you can enter custom URLs and do multi-site selection, I imagine that 
many uses will be found for the new functionality

Perhaps the Emacs folks (NOT XEmacs -- they already have a different 
solution) will create a cygwin-setup dirtree once their cygwin port is 
complete  Perhaps folks who have ported a package and want to make it 
available, but do NOT want to accept the maintainership responsibilities 
that go with *official* package inclusion, will create 
cygwin-setup-compatible distribution sites with custom setupini's 
These are all great things, and are reason enough for the multi-site 
selection capability -- regardless of whether YOU actually use that 
particular feature

--Chuck


--
Unsubscribe info:  http://cygwincom/ml/#unsubscribe-simple
Bug reporting: http://cygwincom/bugshtml
Documentation: http://cygwincom/docshtml
FAQ:   http://cygwincom/faq/

RE: local install?

[Robert Collins]

 -Original Message-
 From: Charles Wilson [mailto:[EMAIL PROTECTED]] 
  Can you tell me some functionality only available when one uses 
  Install
  from Internet?
 
 
 Sure:  merging multiple mirrors into a seamless single-view 
 installation.  (Or, merging an official mirror site + Bob's 
 archive of 
 cool cygwin packages + My company's local cygwin ports 
 into a single, 
 always-up-to-date single seamless installation).  

Download from internet mode does perform this merging, and the install
from local directory grabs all the found .ini files, and then performs
the same merging. So no loss of functionality.

Rob

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

RE: local install?

[Robert Collins]

 -Original Message-
 From: Randall R Schulz [mailto:[EMAIL PROTECTED]] 

 I cannot get setup.exe to permit multiple selection of 
 mirrors, so how is 
 this magical seamless multi-mirror integration achieved? Can 
 it be done 
 without running setup.exe more than once? If not, what's the 
 advantage over 
 separate download and install?

Ctrl-click or shift-click in the setup mirror site list.
 
 Furthermore, why doesn't the multi-mirror technique, however 
 effected, work 
 for separated download and install, too?

It does.
 
Rob

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

RE: local install?

[Robert Collins]

 -Original Message-
 From: Charles Wilson [mailto:[EMAIL PROTECTED]] 


 Perhaps the Emacs folks (NOT XEmacs -- they already have a different 
 solution) will create a cygwin-setup dirtree once their 
 cygwin port is 
 complete.  Perhaps folks who have ported a package and want 
 to make it 
 available, but do NOT want to accept the maintainership 
 responsibilities 
 that go with *official* package inclusion, will create 
 cygwin-setup-compatible distribution sites with custom setup.ini's. 
 These are all great things, and are reason enough for the multi-site 
 selection capability -- regardless of whether YOU actually use that 
 particular feature.

Yes - federation is good. RPM and .deb achieved this a long time ago...
And now we do to :].

Rob

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: local install?

[Charles Wilson]

[please don't send me personal email related to cygwin  Keep it on the 
list]

Randall R Schulz wrote:

 I tried the NEW setup Let's say it has some problems still I'll switch 
 when the kinks are worked out


Okay, so when you said how can I you meant I know it's supposed to 
work, but it doesn't for me  That's a bug report  Thanks


 Yes We've been over this before Setupexe is still the best tool for 
 me to use to maintain my local Cygwin mirror, and I like wget, too I 
 don't really see why you're so adamant about this Why don't you remove 
 the Download from Internet option if you're so certain setupexe 
 shouldn't be used to mirror Cygwin installable packages?


bootstrapping  You can't use wget until after the initial install 
('cause you don't have a working cygwin environment yet, as required by 
wgetexe)

For personal use, yes -- you can do whatever you like  But when the 
on-disk database format for downloaded tarballs changes, to support 
setup's *primary* goal -- the pseudo-mirroring behavior you like may be 
adversely affected  This has happened in the new setup -- tarballs from 
sites are no longer stored in dir/latest and dir/contrib, but 
are stored under dir/http%%%mirrorsite%path%/contrib etc  If you 
select multiple mirrors, the tarballs will be downloaded into disjoint 
contrib or latest directories, depending on where they came from  This 
disrupts the mirroring behavior you like, but the disruption is nonfatal 
-- you can still do what you want, but it won't be pretty  However, the 
behavioral changes are necessary to support the multisite capability

Basically, the reason we've been harping that setup is not a mirroring 
tool is to preserve the freedom to change setup's on-disk database and 
operational behavior in order to support setup's *primary* goal  If you 
want a local copy of the tarballs that looks just like 
ftp://mirrorsrcnnet/ -- setup may no longer do that for you -- or the 
way it does it may be different than you expect (eg the extra 
'http%%%site%path' directory level)

Using a REAL mirroring tool will insulate you from such surprises -- but 
if you're willing to deal with the changes in setup's behavior, good for 
you


 It still seems to me that control freaks are going to do as I do: 
 Separate download and install


 Sure  And some people (incl me) still boot their linux boxen into 
 console mode and only run X when required  But that's still no reason 
 not to develop xdm/gdm/kdm graphical logon managers
 
 
 I don't believe that analogy is particularly apt I'm not smitten with 
 GUIs and I still don't believe a good IDE exists If the bulk of the 
 (vocal) S/W developers were to be believed, syntax coloring and 
 auto-completion were the end-all of programming support, but I find them 
 unhelpful and undesirable In the beginning was the command line I 
 guess I'm still at the beginning, in some ways


I guess I misunderstood your complaint  Sorry

--Chuck



--
Unsubscribe info:  http://cygwincom/ml/#unsubscribe-simple
Bug reporting: http://cygwincom/bugshtml
Documentation: http://cygwincom/docshtml
FAQ:   http://cygwincom/faq/

Re: local install?

[Randall R Schulz]

At 16:33 2002-03-01, you wrote:
[please don't send me personal email related to cygwin  Keep it on the list]


Just following your lead


--
Unsubscribe info:  http://cygwincom/ml/#unsubscribe-simple
Bug reporting: http://cygwincom/bugshtml
Documentation: http://cygwincom/docshtml
FAQ:   http://cygwincom/faq/

Re: local install?

[Charles Wilson]

Randall R Schulz wrote:

 At 16:33 2002-03-01, you wrote:
 
 [please don't send me personal email related to cygwin  Keep it on 
 the list]
 
 
 
 Just following your lead


Huh?  Wha???  Oh, I see  My earlier messages were reply to all -- 
which meant they were sent (a) directly to you, and also (b) copied to 
the list  Opinions may vary, but personally I consider that to fall 
within the definition of keeping it on the list  But that's just my 
(N-S) humble opinion  Sorry for the confusion and inconvenience

--Chuck



--
Unsubscribe info:  http://cygwincom/ml/#unsubscribe-simple
Bug reporting: http://cygwincom/bugshtml
Documentation: http://cygwincom/docshtml
FAQ:   http://cygwincom/faq/

Re: local install?

[Randall R Schulz]

Chuck,

At 16:33 2002-03-01, you wrote:
[please don't send me personal email related to cygwin  Keep it on the list]

Randall R Schulz wrote:

I tried the NEW setup Let's say it has some problems still I'll switch 
when the kinks are worked out


Okay, so when you said how can I you meant I know it's supposed to 
work, but it doesn't for me  That's a bug report  Thanks

Let me clarify Once the NEW setupexe violated some of my expectations 
(like knowing enough not to download the same packages over and over again 
even though they are right there where it put them the last time) I stopped 
using it So my attempt to shift- or CTRL- click in the mirrors list was 
done with setupexe vers 2125210


Yes We've been over this before Setupexe is still the best tool for me 
to use to maintain my local Cygwin mirror, and I like wget, too I don't 
really see why you're so adamant about this Why don't you remove the 
Download from Internet option if you're so certain setupexe shouldn't 
be used to mirror Cygwin installable packages?


bootstrapping  You can't use wget until after the initial install ('cause 
you don't have a working cygwin environment yet, as required by wgetexe)

For personal use, yes -- you can do whatever you like  But when the 
on-disk database format for downloaded tarballs changes, to support 
setup's *primary* goal -- the pseudo-mirroring behavior you like may be 
adversely affected  This has happened in the new setup -- tarballs from 
sites are no longer stored in dir/latest and dir/contrib, but are 
stored under dir/http%%%mirrorsite%path%/contrib etc  If you select 
multiple mirrors, the tarballs will be downloaded into disjoint contrib or 
latest directories, depending on where they came from  This disrupts the 
mirroring behavior you like, but the disruption is nonfatal -- you can 
still do what you want, but it won't be pretty  However, the behavioral 
changes are necessary to support the multisite capability

Basically, the reason we've been harping that setup is not a mirroring 
tool is to preserve the freedom to change setup's on-disk database and 
operational behavior in order to support setup's *primary* goal  If you 
want a local copy of the tarballs that looks just like 
ftp://mirrorsrcnnet/ -- setup may no longer do that for you -- or the 
way it does it may be different than you expect (eg the extra 
'http%%%site%path' directory level)

Using a REAL mirroring tool will insulate you from such surprises -- but 
if you're willing to deal with the changes in setup's behavior, good for you

This I don't understand If Setup doesn't locally maintain the files it 
downloads as a mirror of the site from which it downloaded them, then how 
does wget or any other mirroring tool serve me better? If I mirror using 
wget or FTP Voyager will I be able to install? I surely don't want 300 
megabytes of files for their own sake or just to be able to say I have 
them I want a local package set that I can use to install Since a local 
script execution phase has been added to the installer, manual installation 
is, it seems, not an option at all I've never wanted to do so, but the 
point is that we depend on setupexe to do installation, so any manner of 
retrieving the files to install that is not directly usably by setupexe 
for the installation per se is not very useful

I'm a software developer, too I fully understand and accept the need to 
keep one's options open Ideally this is done by careful wording of specs 
I guess that doesn't really apply here, since we're not talking about an 
API or any other highly formal (or very complex) specification 
Nonetheless, I'm more than happy accommodate such hedges and reserved and / 
or (pre-) announced behavior changes (eg, removal of the old 
interpreatation of the // file name prefix in the Cygwin DLL) It would 
be nice to know, of course, what the anticipated change is Just saying 
Here's a feature It's there in plain sight Please don't use it without 
adding lest you risk  is kind of hard to accept


It still seems to me that control freaks are going to do as I do: 
Separate download and install


Sure  And some people (incl me) still boot their linux boxen into 
console mode and only run X when required  But that's still no reason 
not to develop xdm/gdm/kdm graphical logon managers

I don't believe that analogy is particularly apt I'm not smitten with 
GUIs and I still don't believe a good IDE exists If the bulk of the 
(vocal) S/W developers were to be believed, syntax coloring and 
auto-completion were the end-all of programming support, but I find them 
unhelpful and undesirable In the beginning was the command line I 
guess I'm still at the beginning, in some ways


I guess I misunderstood your complaint  Sorry

--Chuck


Randall Schulz
Mountain View, CA USA


--
Unsubscribe info:  http://cygwincom/ml/#unsubscribe-simple
Bug reporting: http://cygwincom/bugshtml
Documentation: http://cygwincom/docshtml
FAQ:   

Re: local install?

[Robert Collins]

Sorry about the length, just wanted to be really clear...
===
- Original Message -
From: Charles Wilson [EMAIL PROTECTED]

 Basically, the reason we've been harping that setup is not a
mirroring
 tool is to preserve the freedom to change setup's on-disk database
and
 operational behavior in order to support setup's *primary* goal.  If
you
 want a local copy of the tarballs that looks just like
 ftp://mirrors.rcn.net/ -- setup may no longer do that for you -- or
the
 way it does it may be different than you expect (e.g. the extra
 'http%%%site%path' directory level)

The reason *I've* been harping about setup != mirror tool is that mirror
tools have a *heap* of functionality that setup doesn't, and in my
opinion should not have in the
download-and-bootstrap-and-maintain-cygwin GUI.

I.e.: regexp filters on packages to get, grabbing source as well as
binaries, grabbing all versions available at once, grabbing on a
schedule, and probably more.

Setup's goal is quite simple: Install and update a cygwin net
distribution in a non-confusing manner that is satisfactory to the
broadest possible group of cygwin users, in a reliable fashion.

To this end we have things like:
* Categories (too many packages)
* dependencies (foo does not work without bar)
* a local cache dir (Why does it always download X - I simply want to
reinstall)
* in-place file replacement (I upgraded ssh, but it had an error on
sshd.exe, and now sshd won't start)
* Default to a bare minimum installed (I've a low bandwidth
connection..)

I will very happily change the local dir structure irrespective of folk
using setup as a mirroring tool or not - keeping forward compatability
(but not backwards) is easy.

What I won't do is accept Setup won't let me automagically grab all the
source tarballs shown in the GUI as a bug report. Likewise Setup
defaults to not installing gcc is not IMO a valid bug report, because
it's easy to merge in a setup.ini to add packages to Base or Misc, but
it's much harder to stop packages auto-installing if they are in base or
misc.

So in short, anyone who wants to use setup to maintain a local cache to
install from *should do this*. But don't expect it to be useable as a
run-at-midnight tool to automatically update said cache.

I will happily support endeavours to create such a tool, that leverages
the setup.exe code base and lives in cinstall.

Rob


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: local install?

[Randall R Schulz]

Rob,

[ Our mails are crossing, so just know that I've read both the post I'm 
replying to directly here and the subsequent amplification. I think we are 
mostly just agreeing, albeit loudly. ]


It did *what* ? How do you reproduce it?

Grumble. That must be an even-day bug, because when I went to try to 
reproduce it just now, the mis-behavior was gone.

Here's what I remember. About a half-dozen package updates had been 
announced since I last updated, so I decided to use them as a test case for 
the new setup.exe. It (NEW setup.exe) downloaded the bulk of those packages 
(including their source bundles) and then reported an error (a size 
mis-match, if I recall correctly) and offered to download again. I say OK 
and it downloaded ALL of those packages again, this time without error. 
Then, for whatever reason, I decided to run through the download again from 
the top, and NEW setup.exe it listed all those packages as requiring download.

All this was with my old trusty favorite mirror: http://mirrors.rcn.net;

At that point, I went back to the previous setup.exe (2.125.2.10) and 
downloaded (again) and installed the latest package updates.

Sorry to alarm you. Sadly, at this point all I can say is that it could 
have been cockpit error (occasionally I forget to switch the radio buttons 
to one of Download ... or Install from Local Directory) or it could 
have been a glitch in setup.exe itself.

If more details surface, I'll pass them along.


More below...


At 17:06 2002-03-01, Robert Collins wrote:
- Original Message -
From: Randall R Schulz [EMAIL PROTECTED]
  Randall R Schulz wrote:
  
  I tried the NEW setup. Let's say it has some problems still. I'll
switch
  when the kinks are worked out.
  
  
  Okay, so when you said how can I... you meant I know it's supposed
to
  work, but it doesn't for me.  That's a bug report.  Thanks.
 
  Let me clarify. Once the NEW setup.exe violated some of my expectations
  (like knowing enough not to download the same packages over and over again
  even though they are right there where it put them the last time) I stopped
  using it. So my attempt to shift- or CTRL- click in the mirrors list was
  done with setup.exe vers. 2.125.2.10

It did *what* ? How do you reproduce it? Where they (a) from the same 
mirror, or where you (b) chopping and changing mirrors with each run? If 
(b) then that is somewhat-expected, and future enhancements will address 
this. However, the goal is that you select *all* the mirrors you want to 
download from and then just use those again and again. If (a) then tell me 
*exactly* what you do to make it happen, and send the .log and .log.full 
from a couple of runs please.


  Using a REAL mirroring tool will insulate you from such surprises -- but
  if you're willing to deal with the changes in setup's behavior, good 
 for you.
 
  This I don't understand. If Setup doesn't locally maintain the files it
  downloads as a mirror of the site from which it downloaded them, then how
  does wget or any other mirroring tool serve me better? If I mirror using
  wget or FTP Voyager will I be able to install? I surely don't want 300
  megabytes of files for their own sake or just to be able to say I have
  them. I want a local package set that I can use to install. Since a local
  script execution phase has been added to the installer, manual installation
  is, it seems, not an option at all. I've never wanted to do so, but the
  point is that we depend on setup.exe to do installation, so any manner of
  retrieving the files to install that is not directly usably by setup.exe
  for the installation per se is not very useful.

You're more than welcome to help create the command line installer. One 
patch has been submitted, and feedback given, but no futher news has been 
heard. Likewise I've put qutie some effort towards making the engine of 
setup be able to run under unix, and when that is combined with command 
line parameters, there will exist a mirroring tool that understands 
setup.ini's and can run from a script etc. etc. And yes, setup.exe will do 
the right thing if you use wget or FTP voyager - always. We won't break that.

That's all very nice, but I'm actually completely contented with what we 
have now. Let me be clear that I have no problems or complaints with setup 
(old or new, with the now retracted exception described above). I'm very 
happy with what you (all) have given us. Considering I started using Cygwin 
with b18, you can understand that I have a fair perspective on the 
improvements, including but not limited to installation support, over the 
past several years. It's just that I have a hard time accepting the 
repeated admonition that setup.exe is not a mirroring tool when clearly 
it mirrors Cygwin just fine, for my purposes. I cannot see why one would 
use it for any other purpose, and perhaps that's what you're trying to 
forestall.

I certainly do reach for wget for all my general-purpose mirroring and 

Hello--Question about setting up a local install server?

[Glenn Sieb]

Greetings!

I'm the SysAdmin over here at Lumeta, and we're playing with Cygwin here on 
our Windows2000 boxen. We're wanting to play a bit with Cygwin (and 
OpenSSH) here, and one of the questions I've been asked is, if we can set 
it up so that someone can download the setup.exe from our server, and only 
be able to get the packages from our server (or is there a way to do a 
local directory install and pre-specify what packages can/will be 
installed)? I'm not having much luck finding this kind of information the 
website or the mailing lists

With much appreciation in advance... :)

Glenn

---
Glenn E. Sieb, System Administrator
Lumeta Corp. mailto:[EMAIL PROTECTED]
+1 732 357-3514 (V)
+1 732 564-0731 (Fax)


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Hello--Question about setting up a local install server?

[Sherwood Robinson]

Yes you can tell it to install from a specified location or locally.  When 
you run the install you will see the options.  Just run the install on your 
server or whatever box you want the install files to be available 
from.  Then tell the system you want to install it from where to get the 
files.

run through the setup.exe once and you will see what options it has.

SR

At 02:20 PM 1/16/2002 -0500, Glenn Sieb wrote:
Greetings!

I'm the SysAdmin over here at Lumeta, and we're playing with Cygwin here 
on our Windows2000 boxen. We're wanting to play a bit with Cygwin (and 
OpenSSH) here, and one of the questions I've been asked is, if we can set 
it up so that someone can download the setup.exe from our server, and only 
be able to get the packages from our server (or is there a way to do a 
local directory install and pre-specify what packages can/will be 
installed)? I'm not having much luck finding this kind of information the 
website or the mailing lists

With much appreciation in advance... :)

Glenn

---
Glenn E. Sieb, System Administrator
Lumeta Corp. mailto:[EMAIL PROTECTED]
+1 732 357-3514 (V)
+1 732 564-0731 (Fax)


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/


Sherwood Robinson
Hostmaster
The Free Lance-Star/Internet Department
[EMAIL PROTECTED]
http://www.fredericksburg.com

616 Amelia St.
Fredericksburg, VA 22401
540-374-5000 ext. 5657



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Hello--Question about setting up a local install server?

[Tim Prince]

Glenn Sieb wrote:

  Greetings!
 
  I'm the SysAdmin over here at Lumeta, and we're playing with Cygwin
  here  on our Windows2000 boxen. We're wanting to play a bit with
  Cygwin (and  OpenSSH) here, and one of the questions I've been
  asked is, if we can  set it up so that someone can download the
  setup.exe from our server,  and only be able to get the packages
  from our server (or is there a way  to do a local directory
  install and pre-specify what packages can/will  be installed)? I'm
   not having much luck finding this kind of information  the website
   or the mailing lists

You can set your local package directory on a server, so that repeated 
installation on various machines don't waste bandwidth.  I think it's 
simpler to run the copy of setup.exe stored on the server.  I usually do 
install from internet, so that the local package directory is updated.



-- 
Tim Prince
[EMAIL PROTECTED]



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/