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

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

Re: Setup patch to keep test version if test version installed

On Jan 27 19:25, Achim Gratz wrote:
> Corinna Vinschen writes:
> > On Jan 27 07:55, Achim Gratz wrote:
> >> You may have solved a long-standing problem.  Let's see if everything
> >> else still works... :-)
> Orpahned package removal doesn't work anymore, but I have no time to
> take a closer look this week.

Example?  I just tried the libppl and libmpc1 packages, and they simply
don;'t show up anymore, neither in the current setup 2.859, nor ithe
test setup 2.861.  I don't see a difference in behaviour.

Maybe it was a mistake to simpy remove the packages, rather then going
out of my way and mark the packages obsolete instead?

> >> BTW, if you switch one package to "test" (or "prev"), then all packages
> >> belonging to the same source package must be switched to the same state.
> >> I'm currently doing this with an external tool via setup.ini rewrites,
> >> but setup.exe should be taught how to do that for manual intervention.
> >
> > That's a bit over my head in terms of understanding setup's dependency
> > resolution algorithm.  Perhaps we should rewrite it in plain C...
> The idea would be to tie the decision of what version gets installed to
> the source package rather than each individual one.  I haven't looked
> into how that might be possible, but since each package already knows
> its source package that shouldn't be impossible.

That's another type of dependency.  You're talking about installing all
packages that are created from the same source, which is a good idea,

I was talking about entirely different packages the "test" package
depends on.  Let's say, Eric releases a new "test" bash and a new "test"
readline.  When somebody chooses to install the "test" bash, the
dependency algorithm should automatically install the "test" libreadline
since bash depends on readline.

Resolving your kind of dependency is probably much easier to solve.  The
other type of dependency, if implemented in all seriousness, would
probably require to define version dependecies, kind of like defining
minimum version numbers for dependencies in setup.hint.


Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

Attachment: pgpqB1eQ5WhyL.pgp
Description: PGP signature

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