Hi, On Friday, April 20, 2007 at 13:24:53, Benji Weber wrote: > On 4/20/07, Henne Vogelsang <[EMAIL PROTECTED]> wrote: > > On Friday, April 20, 2007 at 12:00:25, Duncan Mac-Vicar Prett wrote: > > > On Thursday 19 April 2007 11:33:42 Henne Vogelsang wrote: > > > > Is that not the same as we have now? > > > > > > No, now packages from other vendors are locked. Nothing should be > > > locked unless the user locks it. > > > > > > I am just saying the solver should not take a update from a > > > _different_ vendor (different from what you have right now, not != > > > SUSE) in consideration (unless the user explicitly do it) , that > > > does not mean you lock it. > > I like the suggestion a lot. The user will specifically want to > install the packman versions of crippled packages, but won't want > build service re-cripped newer versions to override them.
This is is such a special usecase that you will only be able to solve this, without user knowledge, if you can mark repos as leading, authorative or whatever. I dont think you can (and should) solve these usecases on a package level. > Also it would help discourage upgrade all mentality which would replace all > suse supported packages with the newer unsupported versions on packman > when the user doesn't require the newer version. The user specifically requested newer unsupported packages by adding the 3rd party repo. Why would the package manager hold back those packages and install them only on request? > > I see and i dont like it. Because that would mean that you never get > > anything updated from a 3rd party repo because there the vendor will > > always be != <what you have now a.k.a. SUSE after a install > > User would still be able to request upgrade to a different vendor, but > automatic upgrades to different vendor are more likely to cause > problems than be useful imo. Automatic inter-vendor updates are what people expect to happen. Its what we currently do not deliver with yast but with all other package managers. There it works fine since ages. Why would we prohibit it (again)? Henne -- Henne Vogelsang, Teamlead Core Services http://www.opensuse.org --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
