From: Houder <houder@xs4all.nl>
To: cygwin@cygwin.com
Subject: Re: Package choosing algorithm ...
Date: Wed, 06 Apr 2016 10:29:00 -0000 [thread overview]
Message-ID: <b280bfc8b3631815927f40c6b779df3b@xs4all.nl> (raw)
In-Reply-To: <20160322095250.GK7179@calimero.vinschen.de>
[-- Attachment #1: Type: text/plain, Size: 4033 bytes --]
Title: Re: Package choosing agorithm ...
Hi Corinna,
(Of course I am formally addressing the project leader, but Achim, Jon,
Yaakov,
others? are welcome to correct me if I am wrong below).
D w/o I = Download without Install
I f LD = Install from Local Directory
As a reminder: I reported that a new test release of Cygwin is NOT
offered
for install (having installed the previous test release) in my case.
https://cygwin.com/ml/cygwin/2016-03/msg00425.html
Relevant in my case is:
- I am not using a local mirror ...
- but a "partially populated Local Directory"
- I do not invoke setup.exe with the -m option
- my local directory does not have the current release of Cygwin
As you replied "it works for me" and "not using the -m option should not
make a difference", I decided to study the source code of setup.exe.
As I had never seen the source code of setup before, I started my study
where
you had "left off" modifying (about a year ago).
Subsequently, I reported back to the list, announcing that I found the
bug,
but was not sure I had.
https://cygwin.com/ml/cygwin/2016-03/msg00480.html
I was wrong.
My patch did work, but for the wrong reasons.
So does your modification of packagemeta::trustp ...
Here is another attempt of mine (attempt? I seriously doubt whether
there is
someone which fully understands the source code in all its details ...)
You will find 2 patch files attached. These patch files modify
(correct):
1. packagemeta::ScanDownLoadedFiles and
2. packagemeta::trustp
(yes, I do realize, that this correction to setup, is NOT important
enough to
most of you - using a local mirror and all that; consequently, do
whatever you
like with my post - I am merely providing info to the list).
My argument for the correction is as follows:
- packagedb::packages, a class variable, is the "package database" that
is
used by setup.
- basically, it is a list of pairs (mapping between the packagename and
its
entry in setup.ini) (one where installed.db has been "integrated").
- formally:
- typedef std::map <std::string, packagemeta *> packagecollection;
- static packagecollection packages;
- packagemeta is the type that describes a "package entry" from
setup.ini
- an object of type packagemeta does not only describe the previous,
current
and experimental (if applicable) lines from a package entry in
setup.ini,
it also describes the installed version of a package, as if
installed.db is
part of setup.ini.
--
- bottom-line: the prev, curr, exp and installed data member of
packagemeta
are "static": these data members represent the info from setup.ini
(and
installed.db) and they should never be "nullified".
- yet, that is exactly what happens in
metapackage::ScanDownLoadedFiles.
--
- packagemeta ALSO has a "not so static" data member, called versions;
like
packages, the contents of versions is "variable"
- versions, a set of type packageversion, contains the versions of
the
package that are available (the source code speaks about
"accessible")
- available (in my simplistic view) means whether or not the tarball
is
present in the (local) repo
- unfortunately, though versions specifies which versions are
available,
it does not tell us whether the previous, current or experimental
version of a package is available or not
--
- bottom-line: version numbers can be compared if that info is present
in
setup.ini; however, although the info may be present, it does not
tell us
that the associated tarball is available (neither does versions).
- consequently, metapackage:trustp does not only have to verify that
setup.ini has the required info, it also has to verify that the
tarball
is available, before it can give the "go-ahead".
Lastly: No, I have not tested (been able) my modification for each
possible
configuration out there (for instance, I do not install source
tarballs).
Regards,
Henri
=====
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: package_meta_cc.patch --]
[-- Type: text/x-diff; name=package_meta_cc.patch, Size: 869 bytes --]
diff --git a/package_meta.cc b/package_meta.cc
index 34ff78c..ff787a8 100644
--- a/package_meta.cc
+++ b/../src2/package_meta.cc
@@ -683,15 +683,18 @@ packagemeta::ScanDownloadedFiles (bool mirror_mode)
/* For local installs, if there is no src and no bin, the version
* is unavailable
*/
- if (!i->accessible () && !pkgsrcver.accessible ()
- && *i != pkg.installed)
+ if (*i != pkg.installed
+ && !i->accessible () && !pkgsrcver.accessible () )
{
+// Henri: innihilate the info that has been collected from setup.ini? DO NOT!
+ #if 0
if (pkg.prev == *i)
pkg.prev = packageversion ();
if (pkg.curr == *i)
pkg.curr = packageversion ();
if (pkg.exp == *i)
pkg.exp = packageversion ();
+ #endif
pkg.versions.erase (i++);
/* For now, leave the source version alone */
}
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: package_meta_h.patch --]
[-- Type: text/x-diff; name=package_meta_h.patch, Size: 856 bytes --]
diff --git a/package_meta.h b/package_meta.h
index b24d4fc..3d2b775 100644
--- a/package_meta.h
+++ b/../src2/package_meta.h
@@ -105,12 +105,14 @@ public:
if (_default && curr && installed
&& packageversion::compareVersions (curr, installed) < 0)
{
- if (exp && packageversion::compareVersions (installed, exp) < 0)
+// Henri: no, no, no ... first check whether the associated tarball is in the repo or not!
+ if (exp.accessible() && exp && packageversion::compareVersions (installed, exp) < 0)
return exp;
return installed;
}
/* Otherwise, if a "curr" version exists, return "curr". */
- if (curr)
+// Henri: no, no, no ... first check whether the associated tarball is in the repo or not!
+ if (curr.accessible() && curr)
return curr;
/* Otherwise return the installed version. */
return installed;
[-- Attachment #4: Type: text/plain, Size: 218 bytes --]
--
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
next prev parent reply other threads:[~2016-04-06 10:29 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-20 16:55 Houder
2016-03-21 10:00 ` Corinna Vinschen
2016-03-21 10:23 ` Houder
2016-03-21 12:40 ` Houder
2016-03-22 9:52 ` Corinna Vinschen
2016-03-22 17:44 ` Ian Lambert
2016-03-23 16:22 ` Houder
2016-04-06 10:29 ` Houder [this message]
2016-04-06 10:49 ` Package choosing algorithm ... more clarification Houder
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b280bfc8b3631815927f40c6b779df3b@xs4all.nl \
--to=houder@xs4all.nl \
--cc=cygwin@cygwin.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).