On Aug 22 03:53, Brian Dessent wrote:
Corinna Vinschen wrote:
Something's obviously missing...
Yes, I led you astray, sorry. That is going to purge absolutely
everything that setup knows about packages. In order to get that back
it would be necessary to re-parse setup.ini and re-scan
Corinna Vinschen wrote:
Ok, I'll have a look. Any idea about my other question? How to remove
the entire installed.db package DB when the user goes back to the root
dir selection dialog so we can reload from another location, should the
user choose one?
My aborted unfinished attempt at a
Brian Dessent wrote:
- the Replaced-by would have to be transitive in the dependency
computation code as well. So if a maintainer renames package OLDNAME to
And, as a corollary to that: Replaced-by should accept only a single
packagename as predicate, since we have this requirement of
On Aug 22 01:52, Brian Dessent wrote:
Corinna Vinschen wrote:
Ok, I'll have a look. Any idea about my other question? How to remove
the entire installed.db package DB when the user goes back to the root
dir selection dialog so we can reload from another location, should the
user
Brian Dessent wrote:
- the Replaced-by method would not allow a determined user to continue
using an old version of a package without upgrading. With the current
scheme they can just mark the existing package as Keep (or select a
Prev version) which has the effect of blocking the upgrade
Corinna Vinschen wrote:
IMHO, the replaced-by would add nothing in terms of less maintainence
burden. The old package still has to be tweaked in one way or another.
The only extra work without replaced-by is to create empty tar archives
for the old packages, which is really simple.
As I do
On Aug 22 11:24, Corinna Vinschen wrote:
On Aug 22 01:52, Brian Dessent wrote:
As far as the actual freeing of memory, I think it would go something
like
for (vector packagemeta *::iterator i = packages.begin ();
i != packages.end (); ++i)
{
delete *i;
}
Corinna Vinschen wrote:
Something's obviously missing...
Yes, I led you astray, sorry. That is going to purge absolutely
everything that setup knows about packages. In order to get that back
it would be necessary to re-parse setup.ini and re-scan the local
package directory for its contents
On Aug 20 23:21, Yaakov (Cygwin Ports) wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Corinna Vinschen wrote:
What if we add an obsoletes: line to setup.{ini,hint}?
The idea is that you don't have to provide empty replacement packages
for the old packages anymore, and setup
On Aug 21 10:26, Corinna Vinschen wrote:
On Aug 20 23:21, Yaakov (Cygwin Ports) wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Corinna Vinschen wrote:
What if we add an obsoletes: line to setup.{ini,hint}?
The idea is that you don't have to provide empty replacement
On Aug 21 12:35, Corinna Vinschen wrote:
On Aug 21 10:26, Corinna Vinschen wrote:
On Aug 20 23:21, Yaakov (Cygwin Ports) wrote:
Corinna Vinschen wrote:
What if we add an obsoletes: line to setup.{ini,hint}?
[...]
Any progress yet on this one?
Unfortunately not. The package
Corinna Vinschen wrote:
IIUC, the ConnectedLoopFinder::visit() function is the core function
which creates the dependency order. What I don't get is this: The
That code is concerned with creating a topological ordering for the
specific purpose of running postinstall scripts. This isn't
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Corinna Vinschen wrote:
What if we add an obsoletes: line to setup.{ini,hint}?
The idea is that you don't have to provide empty replacement packages
for the old packages anymore, and setup removes all packages noted in
the obsoletes: line
On Jul 25 11:40, Corinna Vinschen wrote:
Corinna Vinschen wrote:
| I'm not sure if there's really a big difference between these two points.
| Since we're using two different installation directories, we can get rid
| of old cruft, if we just look carefully what's still used and what not.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Corinna Vinschen wrote:
| What if we add an obsoletes: line to setup.{ini,hint}?
|
| The idea is that you don't have to provide empty replacement packages
| for the old packages anymore, and setup removes all packages noted in
| the obsoletes: line
On Wed, Jul 30, 2008 at 02:18:15PM +0200, Corinna Vinschen wrote:
On Jul 25 11:40, Corinna Vinschen wrote:
Corinna Vinschen wrote:
| I'm not sure if there's really a big difference between these two points.
| Since we're using two different installation directories, we can get rid
| of old
On Jul 27 21:20, Yaakov (Cygwin Ports) wrote:
Christopher Faylor wrote:
| It seems like maybe another change to setup.exe would be in order here
| or maybe there could be a base package which did any cleanup required to
| purge unneeded packages.
Could setup-1.7 know if the last installation
Yaakov (Cygwin Ports) wrote:
Could setup-1.7 know if the last installation was 1.5, and simply ignore
the installed.db?
As outlined in http://cygwin.com/ml/cygwin-apps/2008-04/msg00169.html
the way that it will work is entirely dependent on what you enter for
the root location. It will start
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Christopher Faylor wrote:
| It seems like maybe another change to setup.exe would be in order here
| or maybe there could be a base package which did any cleanup required to
| purge unneeded packages.
Could setup-1.7 know if the last installation
On Jul 24 18:44, Yaakov (Cygwin Ports) wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Corinna Vinschen wrote:
| I'm not sure if there's really a big difference between these two points.
| Since we're using two different installation directories, we can get rid
| of old cruft, if we
On Fri, Jul 25, 2008 at 11:40:34AM +0200, Corinna Vinschen wrote:
Nice example. Still, for now we should assume that we go the upgrade
path. I'm going to investigate the impact of a clean cut in the next
couple of days.
It seems like maybe another change to setup.exe would be in order here
or
On Jul 25 10:52, Christopher Faylor wrote:
On Fri, Jul 25, 2008 at 11:40:34AM +0200, Corinna Vinschen wrote:
Nice example. Still, for now we should assume that we go the upgrade
path. I'm going to investigate the impact of a clean cut in the next
couple of days.
It seems like maybe
On Fri, Jul 25, 2008 at 05:16:30PM +0200, Corinna Vinschen wrote:
On Jul 25 10:52, Christopher Faylor wrote:
On Fri, Jul 25, 2008 at 11:40:34AM +0200, Corinna Vinschen wrote:
Nice example. Still, for now we should assume that we go the upgrade
path. I'm going to investigate the impact of a
Corinna Vinschen wrote:
- Potentially case sensitivity file operations (on OSes and FSes
supporting it).
Have managed mounts been fixed yet? Sorry, I've been out of the loop for quite
awhile. Anyway, I noticed that Yakkov was using this feature in Cygwin Ports, so
I thought I might
On Jul 23 23:43, Yaakov (Cygwin Ports) wrote:
What I *do* know about by now is porting and packaging for Cygwin,
having done it for almost five years now. And with the transition to
1.7 coming up, there are a few general packaging issues that I think it
would be timely to address.
Can't
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Corinna Vinschen wrote:
| I'm not sure if there's really a big difference between these two points.
| Since we're using two different installation directories, we can get rid
| of old cruft, if we just look carefully what's still used and what not.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
As we start preparing for 1.7, I know that until now the focus has been
on the development of Cygwin itself. I'll admit that I know little
about Cygwin's internals, and hence have contributed very little to the
DLL itself, but I do very much
27 matches
Mail list logo
