[opensuse-factory] zypper in zypper requires deinstallation of gfxboot
What? How can this be? Attempting upgrade from M1 to factory-snapshot. Zypper in gfxboot wants to upgrade 54 packages. :-O Does gfxboot really depend on all of perl and most of yast2? Is this just a quirk caused by rubyfying Yast? -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Felix Miata <mrmazda@earthlink.net> writes:
Zypper in gfxboot wants to upgrade 54 packages. :-O Does gfxboot really depend on all of perl and most of yast2?
gfxboot depends on perl, thus everything that depends on perl needs to be updated. Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2013-07-18 10:23 (GMT+0200) Andreas Schwab composed:
Felix Miata wrote:
Zypper in gfxboot wants to upgrade 54 packages. :-O Does gfxboot really depend on all of perl and most of yast2?
gfxboot depends on perl,
Of course it does. But, a specific perl version? It didn't previously. Why? It runs before a kernel loads. Even for maintenance running while booted, dependence on a specific perl version doesn't seem to make any sense. The problem this creates is I get tired of having to rerun gfxboot after each update to get /boot/message back the way I want it. Until sometime post-12.3, locking gfxboot avoided this nuisance. Having the gfxboot lock prevent updating zypper (and all the critical package system functions that depend on it), which is also dependent on a specific perl version, from a macro perspective is just wrong.
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Felix Miata <mrmazda@earthlink.net> writes:
It didn't previously.
In 12.3 it does, and I have no reason to believe that it changed in the mean time. Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2013-07-18 11:00 (GMT+0200) Andreas Schwab composed:
Felix Miata wrote:
It didn't previously.
In 12.3 it does
12.3 isn't the only previous release. I've just spent the past several days applying updates to mostly 12.1 & 12.2 systems, with no complaints on account of locked gfxboot. Only on my 2nd or 3rd 13.1 update since M3 announcement did I hit this. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Felix Miata <mrmazda@earthlink.net> writes:
I've just spent the past several days applying updates to mostly 12.1 & 12.2 systems, with no complaints on account of locked gfxboot.
How does that have anything to do with the subject of this thread? Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2013-07-18 11:53 (GMT+0200) Andreas Schwab composed:
Felix Miata wrote:
I've just spent the past several days applying updates to mostly 12.1 & 12.2 systems, with no complaints on account of locked gfxboot.
How does that have anything to do with the subject of this thread?
Isolated as you've made it by limited quoting it would be hard do guess. In context of the whole thread, it means gfxboot could in pre-12.3 releases be kept locked and /boot/message left unmolested without interfering with updates to zypper, libzypp, perl, and other essential packages. What the thread is about is an apparent unjustified dependency, gfxboot locked to a particular perl version. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
I don't understand what you are after. The fact that gfxboot depends on a fixed perl version has not changed in any way. Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2013-07-18 12:29 (GMT+0200) Andreas Schwab composed:
I don't understand what you are after. The fact that gfxboot depends on a fixed perl version has not changed in any way.
Something must have changed somehow. I used to be able to keep /boot/message from being rewritten without applying chattr +i to it. In the past year or so more and more openSUSE packages have taken to halting the zypper up/dup process instead of just writing an .rpmnew file on encountering immutable files. What I'm after is a way to protect /boot/message from being changed from attractive to ugly at every new milestone that does not require impeding update processing; a way that does not involve removing the gfxboot package via rpm system then reinstalling it from without the rpm system. 2nd best option: cut way down the weights of brown and yellow in the greens in the themes. Green is nice only when it isn't connoting sick, dead or dying. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 18.07.2013 18:06, schrieb Felix Miata:
mv /boot/message /boot/mymessage sed -i 's#/boot/message#/boot/mymessage#' /boot/grub/menu.lst done. If you have /boot not on the root partition, just edit menu.lst by hand. I'm sure you get the idea. -- Stefan Seyfried "If your lighter runs out of fluid or flint and stops making fire, and you can't be bothered to figure out about lighter fluid or flint, that is not Zippo's fault." -- bkw -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2013-07-19 10:50 (GMT+0200) Stefan Seyfried composed:
Felix Miata, in English, wrote:
On 2013-07-18 12:29 (GMT+0200) Andreas Schwab composed:
I don't understand what you are after. The fact that gfxboot depends on a fixed perl version has not changed in any way.
Something must have changed somehow. I used to be able to keep /boot/message from being rewritten without applying chattr +i to it. In
mv /boot/message /boot/mymessage sed -i 's#/boot/message#/boot/mymessage#' /boot/grub/menu.lst
I had that idea. It's no more than a marginally acceptable workaround. /boot/message is customizable, like such things as /etc/HOSTNAME, /etc/resolv.conf, /etc/samba/smb.conf, /etc/exports & etc. It doesn't live in /usr or /bin or /sbin or /run or /lib. So, user customizations should not be stripped or altered at update times. Incompatible changes need to go in .rpmnew files instead of destroying customizations made via gfxboot --change-config. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thursday 2013-07-18 10:48, Felix Miata wrote:
gfxboot depends on perl,
Of course it does. But, a specific perl version? It didn't previously. Why?
gfxboot did previously (in 12.3) require a specific perl version (5.16.2). Must be a not too intelligent macros.perl that does the autorequires. Whenever a package X has something in /usr/lib/perl5/vendor_perl/5.16.2, it will only be usable with version 5.16.2, because 5.18 won't look in there. That in itself is a bit annoying, and I wish perl would be smarter about it. |x \%Config 'installarchlib' => '/usr/lib/perl5/5.16.2/x86_64-linux-thread-multi' 'installprivlib' => '/usr/lib/perl5/5.16.2' 'installsitearch' => '/usr/lib/perl5/site_perl/5.16.2/x86_64-linux-thread-multi' 'installsitelib' => '/usr/lib/perl5/site_perl/5.16.2' 'installvendorarch' => '/usr/lib/perl5/vendor_perl/5.16.2/x86_64-linux-thread-multi' 'installvendorlib' => '/usr/lib/perl5/vendor_perl/5.16.2' 'otherlibdirs' => '/usr/lib/perl5/site_perl' In other words, the non-versioned dir is SUSE-specific (see perl.spec) and not even up for discussion from perl's (and ExtUtils::install's) perspective. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thu, Jul 18, 2013 at 11:01:24AM +0200, Jan Engelhardt wrote:
gfxboot did previously (in 12.3) require a specific perl version (5.16.2). Must be a not too intelligent macros.perl that does the autorequires.
No, our autorequires do not do this. It's because the specfile contains: %perl_requires That requires a specific perl version. It probably can be changed to a simple: Requires: perl Cheers, Michael. -- Michael Schroeder mls@suse.de SUSE LINUX Products GmbH, GF Jeff Hawn, HRB 16746 AG Nuernberg main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);} -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (5)
-
Andreas Schwab -
Felix Miata -
Jan Engelhardt -
Michael Schroeder -
Stefan Seyfried