opensuse
[Arriba] [Todas las Listas]

[opensuse] Re: Re: Re: zypper [Arriba de vs patch && duppr{^de 11.3 a 11

To: opensuse@xxxxxxxxxxxx
Subject: [opensuse] Re: Re: Re: zypper [Arriba de vs patch && duppr{^de 11.3 a 11.4 ??}
From: "Joe(theWordy)Philbrook" <jtwdyp@xxxxxxxx>
Date: Mon, 19 Sep 2011 23:42:01 -0400
Delivered-to: opensuse@xxxxxxxxxxxxxxxxxxx
Delivery-date: Mon, 19 Sep 2011 23:44:12 -0400
Envelope-to: traductor@xxxxxxxxxxx
In-reply-to: <alpine.LNX.2.00.1109191737170.5240@Telcontar.valinor>
List-archive: <http://lists.opensuse.org/opensuse/>
List-help: <mailto:opensuse+help@opensuse.org>
List-owner: <mailto:opensuse+owner@opensuse.org>
List-post: <mailto:opensuse@opensuse.org>
List-subscribe: <mailto:opensuse+subscribe@opensuse.org>
List-unsubscribe: <mailto:opensuse+unsubscribe@opensuse.org>
Mailing-list: contact opensuse+help@xxxxxxxxxxxx; run by mlmmj
References: <alpine.LNX.2.00.1109151010560.15863@OpenSuSEme2010.localdomain> <20110915154121.GC31513@suse.de> <CAGpXXZKLiH+e+=Ls5RH3ZiqJcouSnPuX7btWqaLkwxUtdLZNHQ@mail.gmail.com> <alpine.LNX.2.00.1109161223000.5102@OpenSuSEme2010.localdomain> <alpine.LNX.2.00.1109181530000.5240@Telcontar.valinor> <alpine.LNX.2.00.1109190157260.6308@OpenSuSEme2010.localdomain> <alpine.LNX.2.00.1109191737170.5240@Telcontar.valinor>
User-agent: Alpine 2.00 (LNX 1167 2008-08-23)
Aparecería que en *Sep 19, Carlos *E. *R. Dijo:

> En lunes, 2011-09-19 en 04:03 -0400, Joe(*theWordy)*Philbrook escribió:
> 
> > > me quedaría claro de *zypper *dup, a no ser que realmente entiendes lo que él
> > > ,
> > > o si lo utilizas para cambiar *distro versión.
> > 
> > *Yeah, utilicé para sentir aquella manera, pero gradualmente la lista de archivos que lo
> > molestado
> > para decir no sería *upgraded, por "*zypper arriba" acontecía demasiado grande para comodidad. No sé lo que el porcentaje era para "cambios de vendedor" pero *zypper *dup conseguía #mío
> > 11.3 cuando hasta fecha como posible. Cuál podría haber ayudado cuándo lo utilicé a *upgrade
> > a 11.4...
> 
> Aquello es la manera incorrecta de pensamiento.

No lo que sería la manera incorrecta de pensar para *_el ME_* sería para pensar
como cualquiera además yo... 

> Si *zypper arriba  no *upgrade algo es porque las reglas has puesto *impede lo, tan lo que dice hará es la cosa correcta.

Estado de acuerdo si el dentro-reglas "de sitio" puesto que es *behavior *impede es *upgrading un
paquete entonces está haciendo la cosa correcta. Está sirviendo a *alert me que
puede haber un asunto que necesita resolver para un más completo *upgrade.

> Qué tienes que hacer es cambia las reglas. 

O cambiar el método. Especialmente si no sé cuáles gobiernan que yo yo
 no la habilidad es *impeding los resultados estoy buscando...

Mencioné estoy manteniendo múltiple *distros hasta fecha... Incluso si era bastante listo a *customize el *default "reglas" para cada *distro administración
de paquete, no probablemente tengo el tiempo... En cualquier caso "yo" nunca puesto
cualesquier "reglas" para *zypper (excepto una cerradura "ocasional" que nunca dejo en
sitio mucho tiempo bastante para olvidar es allí.)#Adv, si era posible de poner una cerradura negativa para decir *zypper a NUNCA
instalar un paquete particular, sencillamente he puesto una cerradura permanente para "gobernar"
fuera de *iced-té hace algún tiempo...}

* Citado *excerpts de hombre "*zypper"

=>  actualizar (arriba de) [opciones] [*packagename] ...
=>         Actualiza paquetes instalados con versiones más nuevas, donde posible.
=>
=>         Esta orden no actualizará paquetes que requerirían cambio
=>         de vendedor    de paquete  a no ser que   el   vendedor   es   especificado   en
=>         /*etc/*zypp/vendedores.*d, o que requeriría resolución manual de =
>         problemas con dependencias. Tal  no-*installable  actualiza  
=>         entonces  ser  listado en sección separada del resumen como "El *fol-
=>         *lowing el paquete actualiza NO será instalado:".

No lo tengo en mí a pista todos los cambios de vendedor para mantener un viable
*venders.*d El Archivo actualizó. Ni a segunda suposición los asuntos de dependencias que
requerirían "intervención manual". Si veo uno o dos particularmente deseado
*upgrade(*s) listó debajo "NO será instalado" podría abortar y probar un
directo instalar orden para ver lo que#pr{^arriba de/abajo}grados, y saca, sería
provocado por los me preocupo aproximadamente. Pero  *otherwise tender para ignorar la lista
hasta que acontecía demasiado grande para mi comodidad. En los cuales señalan el rápidamente fijar
es a#adv} utilizar un martillo más grande:

=>  *dist-*upgrade (*dup) [opciones]
=>         Actúa  una  distribución *upgrade. Esta orden aplica el estado
=>         de (especificado) *repositories al sistema; *upgrades  (o incluso  
=>         *downgrades)  paquetes  instalados  a las versiones encontradas en *reposito-
=>         *ries, saca paquetes que son no más largo  en    el *repositories
=>         y posar    un problema de dependencia para el *upgrade, rupturas de paquete
=>         de los mangos y rebautiza, *etc.

Pagando atención cercana a qué (si cualquier cosa) sería "sacado" para traer mi
sistema más plenamente en *sync con la corriente *repo *defaults. Si no me gustan
los cambios haría entonces podría volver a *zypper "arriba de hasta" que puedo
encontrar el tiempo para imaginar fuera de alguna "intervención manual"...

Cualquier manera aquello es la manera mi cerebro resuelve tales asuntos...

Pero *thanks para el consejo. && Tiene un día 'guapo'.

-- 
|   ---   ___
|   <0>   <->     Joe (*theWordy) *Philbrook
|       ^              *J(*tWdy)*P
|    \___/      <<jtwdyp@xxxxxxxx>>

-- 
A *unsubscribe, *e-correo: *opensuse+unsubscribe@xxxxxxxxxxxx
Puesto que órdenes adicionales, *e-correo: *opensuse+help@xxxxxxxxxxxx


It would appear that on Sep 19, Carlos E. R. did say:

> On Monday, 2011-09-19 at 04:03 -0400, Joe(theWordy)Philbrook wrote:
> 
> > > I would stay clear of zypper dup, unless you really understand what it
> > > does,
> > > or if you use it to change distro version.
> > 
> > Yeah, I used to feel that way, but gradually the list of files that it
> > bothered
> > to say wouldn't be upgraded, by "zypper up" became too large for comfort. I
> > don't know what percentage was for "vendor changes" but zypper dup got my
> > 11.3 as up to date as possible. Which might have helped when I used it to
> > upgrade to 11.4...
> 
> That's the wrong way of thinking.

No what would be the wrong way of thinking for *_ME_* would be to think
like anybody besides myself... 

> If zypper up will not upgrade something it is because the rules you
> have set impede it, so what it says will do is the correct thing.

Agreed if the in-place "rules" for it's behavior impede it's upgrading a
package then it is doing the correct thing. It's serving to alert me that
there may be an issue that needs resolving for a more complete upgrade.

> What you have to do is change the rules. 

Or change the method. Especially if I don't know which rule that I myself
didn't craft is impeding the results I'm looking for...

I did mention I'm keeping multiple distros up to date... Even if I was smart
enough to customize the default "rules" for each distro's package
management, I wouldn't likely have the time... In any case "I" never set
any "rules" for zypper (except for an occasional "lock" which I never leave in
place long enough to forget it's there.) 
{Of course, if it was possible to set a negative lock to tell zypper to NEVER
install a particular package, I'd have simply set a permanent lock to "rule"
out iced-tea some time ago...}

* quoted excerpts from "man zypper"

=>  update (up) [options] [packagename] ...
=>         Update installed packages with newer versions, where possible.
=>
=>         This command will not update packages which would require change
=>         of  package  vendor  unless   the   vendor   is   specified   in
=>         /etc/zypp/vendors.d, or which would require manual resolution of
=>         problems with dependencies. Such  non-installable  updates  will
=>         then  be  listed in separate section of the summary as "The fol-
=>         lowing package updates will NOT be installed:".

I don't have it in me to track all the vendor changes to keep a viable
venders.d file updated. Nor to second guess the dependencies issues that
would require "manual intervention". If I see one or two particularly desired
upgrade(s) listed under "will NOT be installed" I might abort and try a
direct install command to see what {up/down}grades, and removes, would be
triggered by the ones I care about. But would otherwise tend to ignore the
list until it became too large for my comfort. At which point the quick fix
is to {provisionally} use a bigger hammer:

=>  dist-upgrade (dup) [options]
=>         Perform  a  distribution upgrade. This command applies the state
=>         of (specified) repositories onto the system; upgrades  (or  even
=>         downgrades)  installed  packages  to versions found in reposito-
=>         ries, removes packages that are no longer  in  the  repositories
=>         and  pose  a dependency problem for the upgrade, handles package
=>         splits and renames, etc.

Paying close attention to what (if anything) would be "removed" to bring my
system more fully in sync with the current repo defaults. If I don't like
the changes it would make then I might go back to "zypper up" until I can
find the time to figure out some "manual intervention"...

Any way that's the way my brain resolves such issues...

But thanks for the advice. && Have a 'nice' day.

-- 
|   ---   ___
|   <0>   <->     Joe (theWordy) Philbrook
|       ^              J(tWdy)P
|    ~\___/~      <<jtwdyp@xxxxxxxx>>

-- 
To unsubscribe, e-mail: opensuse+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse+help@xxxxxxxxxxxx


<Anterior por Tema] Tema Actual [Siguiente por Tema>