Re: nvr issues, yum distro-sync

On 05/28/2010 07:54 PM, seth vidal wrote: > file it and we'll get it changed to be a more helpful msg. > https://bugzilla.redhat.com/show_bug.cgi?id=597336 Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel

Re: nvr issues, yum distro-sync

On Fri, 2010-05-28 at 05:30 +0530, Rahul Sundaram wrote: > On 05/28/2010 05:23 AM, seth vidal wrote: > > protect packages is no-more! > > > > we've merged the functionality into core yum to keep people from > > shooting themselves in the foot > > > > There is something misleading about what it

Re: nvr issues, yum distro-sync

On 27/05/10 21:07, seth vidal wrote: --snip-- > > that's going to be up to the pk maintainer(s). > > but I don't think moving to distro-sync necessarily makes sense there. > > distro-sync is mostly valuable for folks playing between two releases. > > -sv > > or someone with a local repo on a

Re: nvr issues, yum distro-sync

On Fri, May 28, 2010 at 05:30:03AM +0530, Rahul Sundaram wrote: > "Error: Trying to remove "yum" which is protected > You could try using --skip-broken to work around the problem > You could try running : rpm -Va --nofiles --nodigest" > Neither suggestions are applicable here. The protect pack

Re: nvr issues, yum distro-sync

On Thu, May 27, 2010 at 07:53:26PM -0400, seth vidal wrote: > > Oooh, ooh! (*Raises hand, jumps in chair*.) yum-protect-packages plugin! > protect packages is no-more! > we've merged the functionality into core yum to keep people from > shooting themselves in the foot I saw! It's always nice to se

Re: nvr issues, yum distro-sync

On 05/28/2010 05:23 AM, seth vidal wrote: > protect packages is no-more! > > we've merged the functionality into core yum to keep people from > shooting themselves in the foot > There is something misleading about what it does. yum remove yum in Rawhide tells "Error: Trying to remove "yum" wh

Re: nvr issues, yum distro-sync

On Thu, 2010-05-27 at 19:41 -0400, Matthew Miller wrote: > On Thu, May 27, 2010 at 09:35:18PM +0100, Jonathan Underwood wrote: > > Yes - this is rather important, because our user facing docs (on the > > wiki) for preupgrade recommend removing all packages identified with > > package-cleanup --orph

Re: nvr issues, yum distro-sync

On Fri, May 28, 2010 at 05:13:09AM +0530, Rahul Sundaram wrote: > That functionality is merged into yum in Rawhide. Well, I *knew* it was a good idea. :) -- Matthew Miller mat...@mattdm.org -- devel mailing list devel@lists.fedoraproject.org https://admin

Re: nvr issues, yum distro-sync

On 05/28/2010 05:11 AM, Matthew Miller wrote: > On Thu, May 27, 2010 at 09:35:18PM +0100, Jonathan Underwood wrote: > >> Yes - this is rather important, because our user facing docs (on the >> wiki) for preupgrade recommend removing all packages identified with >> package-cleanup --orphans. A na

Re: nvr issues, yum distro-sync

On Thu, May 27, 2010 at 09:35:18PM +0100, Jonathan Underwood wrote: > Yes - this is rather important, because our user facing docs (on the > wiki) for preupgrade recommend removing all packages identified with > package-cleanup --orphans. A naive user could literally wipe out their > system by blin

Re: nvr issues, yum distro-sync

On Thu, 2010-05-27 at 16:53 -0400, Matt McCutchen wrote: > Sure, though I would hope the user would stop a removal of 1500 packages > and complain on the list like Klaus did. > > Another solution is to move away from incremental maintenance of the set > of installed packages and instead solve the

Re: nvr issues, yum distro-sync

On Thu, 2010-05-27 at 21:35 +0100, Jonathan Underwood wrote: > On 27 May 2010 20:58, Matt McCutchen wrote: > > On Thu, 2010-05-27 at 15:03 -0400, James Antill wrote: > >> While it's not good packaging, most of the time these bad versions > >> don't cause any problems. > > > > It's better to have

Re: nvr issues, yum distro-sync

On Thu, 2010-05-27 at 16:32 -0400, Matt McCutchen wrote: > I think the word "release" is being misused there. In the mirror > layout, "releases" refers to the originally released content without > updates, but the distribution version stays constant across updates. > > In an ideal world, I would

Re: nvr issues, yum distro-sync

On 27 May 2010 20:58, Matt McCutchen wrote: > On Thu, 2010-05-27 at 15:03 -0400, James Antill wrote: >>  While it's not good packaging, most of the time these bad versions >> don't cause any problems. > > It's better to have the packages that are supported (to the extent that > the community provi

Re: nvr issues, yum distro-sync

On Thu, 2010-05-27 at 16:19 -0400, seth vidal wrote: > On Thu, 2010-05-27 at 16:16 -0400, Matt McCutchen wrote: > > On Thu, 2010-05-27 at 16:10 -0400, Matt McCutchen wrote: > > > > distro-sync is mostly valuable for folks playing between two releases. > > > > > > For users who don't downgrade rele

Re: nvr issues, yum distro-sync

On Thu, 2010-05-27 at 16:16 -0400, Matt McCutchen wrote: > On Thu, 2010-05-27 at 16:10 -0400, Matt McCutchen wrote: > > > distro-sync is mostly valuable for folks playing between two releases. > > > > For users who don't downgrade releases, [...] > > "Releases" there means distribution versions (

Re: nvr issues, yum distro-sync

On Thu, 2010-05-27 at 16:10 -0400, Matt McCutchen wrote: > > distro-sync is mostly valuable for folks playing between two releases. > > For users who don't downgrade releases, [...] "Releases" there means distribution versions (i.e., collections in the Package DB). Ugh, confusing terminology. P

Re: nvr issues, yum distro-sync

On Thu, 2010-05-27 at 16:07 -0400, seth vidal wrote: > On Thu, 2010-05-27 at 15:58 -0400, Matt McCutchen wrote: > > On Thu, 2010-05-27 at 15:03 -0400, James Antill wrote: > > > While it's not good packaging, most of the time these bad versions > > > don't cause any problems. > > > > It's better t

Re: nvr issues, yum distro-sync

On Thu, 2010-05-27 at 15:58 -0400, Matt McCutchen wrote: > On Thu, 2010-05-27 at 15:03 -0400, James Antill wrote: > > While it's not good packaging, most of the time these bad versions > > don't cause any problems. > > It's better to have the packages that are supported (to the extent that > the