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


Corinna Vinschen writes:
> 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.

You have to use the -o / --delete-orphans option for this to kick in.
It should still work in 2.859 or at least it did for me.  This trustp
business in setup is a bit annoying and intransparent, but I'll figure
out how to fix it again.

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

I can make obsolescence packages if anybody thinks it's useful.

> 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,
> certainly.

No, I'm only talking about installing all packages from the same source
with the same version selector (from prev/curr/exp).  The user still
gets to chose which of the packages to install, but shouldn't be able to
install devel from curr and doc from prev and libwhatever from test.

> 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.

I've thought about this before, but that would require the format of
setup.hint and setup.ini to change and (at least optionally) allow
different dependencies per prev/curr/exp section.

> 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.

I sort of have that already, just that I use a setup.conf file to
integrate different package sources coherently into a new setup.ini
file.  At the moment I can only override by prev/test or by putting a
package in a higher priority package source (that's how I implement
patches), but explicit version overrides are on the TODO list.


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

Waldorf MIDI Implementation & additional documentation:
http://Synth.Stromeko.net/Downloads.html#WaldorfDocs


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