[opensuse-packaging] fubar mozilla repos?
On a 13.1 system I just tried to upgrade firefox-esr from MozillaLegacy from 17.0.10 to 17.0.11. I've been doing this on multiple systems for months since 17.0.x reached end of life last fall with no apparent problems. Today if failed, as 17.0.11 now in the repos requires mozilla-nss and/or mozilla-certs
= the highest available in any standard or Mozilla or MozillaLegacy 13.1 repo. To get it to install the required minimum version and thus install 17.0.11 I had to add the Mozilla repo for Factory.
Installed and apparently working now on host gx62b: firefox-esr-17.0.11-1.3.x86_64 firefox-esr-branding-upstream-17.0.11-1.3.x86_64 mozilla-nspr-4.10.4-67.1.x86_64 mozilla-nss-3.15.5-1.1.x86_64 mozilla-nss-certs-3.15.5-1.1.x86_64 -- "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-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Hi, Am 15.03.2014 06:30, schrieb Felix Miata:
On a 13.1 system I just tried to upgrade firefox-esr from MozillaLegacy from 17.0.10 to 17.0.11. I've been doing this on multiple systems for months since 17.0.x reached end of life last fall with no apparent problems. Today if failed, as 17.0.11 now in the repos requires mozilla-nss and/or mozilla-certs >= the highest available in any standard or Mozilla or MozillaLegacy 13.1 repo. To get it to install the required minimum version and thus install 17.0.11 I had to add the Mozilla repo for Factory.
Installed and apparently working now on host gx62b: firefox-esr-17.0.11-1.3.x86_64 firefox-esr-branding-upstream-17.0.11-1.3.x86_64 mozilla-nspr-4.10.4-67.1.x86_64 mozilla-nss-3.15.5-1.1.x86_64 mozilla-nss-certs-3.15.5-1.1.x86_64
the problem is that mozilla:legacy has finished building against the NSPR/NSS from mozilla but the mozilla repo itself has not finished building/publishing with those versions. So instead of using some wrong package you might have wanted to wait until the conflicts go away automatically. Wolfgang -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 2014-03-15 09:15 (GMT+0100) Wolfgang Rosenauer composed:
Felix Miata composed:
On a 13.1 system I just tried to upgrade firefox-esr from MozillaLegacy from 17.0.10 to 17.0.11. I've been doing this on multiple systems for months since 17.0.x reached end of life last fall with no apparent problems. Today if failed, as 17.0.11 now in the repos requires mozilla-nss and/or mozilla-certs >= the highest available in any standard or Mozilla or MozillaLegacy 13.1 repo. To get it to install the required minimum version and thus install 17.0.11 I had to add the Mozilla repo for Factory.
Installed and apparently working now on host gx62b: firefox-esr-17.0.11-1.3.x86_64 firefox-esr-branding-upstream-17.0.11-1.3.x86_64 mozilla-nspr-4.10.4-67.1.x86_64 mozilla-nss-3.15.5-1.1.x86_64 mozilla-nss-certs-3.15.5-1.1.x86_64
the problem is that mozilla:legacy has finished building against the NSPR/NSS from mozilla but the mozilla repo itself has not finished building/publishing with those versions. So instead of using some wrong package you might have wanted to wait until the conflicts go away automatically.
Ordinarily, that's what I would have done. However, as e.g. http://ftp.mozilla.org/pub/mozilla.org/firefox/releases/latest-17.0esr/linux... is timestamped November 2013 when the line's support ceased, it seems illogical not to assume the corresponding version on http://download.opensuse.org/repositories/mozilla:/legacy/openSUSE_13.1/i586... would have a last built date in the days or maybe a week or two following upstream's last build. It's similarly non-obvious that content in mozilla:/legacy would have non-generic depends on some other repo than mozilla:/legacy, or that even if so, the dependency wouldn't have been published first if not coincident. In the instant case, the system is an occasional use system. Updates need to be done in its available use window. Waiting would disrupt the use window scheduling that shouldn't need to be flexible except WRT alpha/beta testing, not supported final releases, and not "obsolete" packages. This resurfaces the question what advantage there may be in rpm packages over the upstream generics at least WRT legacy releases? Upstream's 17.0.11 runs in 13.1's KDE4 without complaining even when all of mozilla-nspr, mozilla-nss and mozilla-nss-certs are not installed. -- "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-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Hi, Am 15.03.2014 21:59, schrieb Felix Miata:
On 2014-03-15 09:15 (GMT+0100) Wolfgang Rosenauer composed:
Ordinarily, that's what I would have done. However, as e.g. http://ftp.mozilla.org/pub/mozilla.org/firefox/releases/latest-17.0esr/linux... is timestamped November 2013 when the line's support ceased, it seems illogical not to assume the corresponding version on http://download.opensuse.org/repositories/mozilla:/legacy/openSUSE_13.1/i586... would have a last built date in the days or maybe a week or two following upstream's last build.
Then you didn't really understand what Linux distribution packaging is, how reliable build systems work and what OBS is all about.
It's similarly non-obvious that content in mozilla:/legacy would have non-generic depends on some other repo than mozilla:/legacy, or that even if so, the dependency wouldn't have been published first if not coincident.
OBS has no support for dependency tracking like this. Actually it could have since it knows that mozilla is the base repo for mozilla:legacy. Keeping unmaintained packages in mozilla is no option. I'm already scared about having them in mozilla:legacy alone.
In the instant case, the system is an occasional use system. Updates need to be done in its available use window. Waiting would disrupt the use window scheduling that shouldn't need to be flexible except WRT alpha/beta testing, not supported final releases, and not "obsolete" packages.
This resurfaces the question what advantage there may be in rpm packages over the upstream generics at least WRT legacy releases? Upstream's 17.0.11 runs in 13.1's KDE4 without complaining even when all of mozilla-nspr, mozilla-nss and mozilla-nss-certs are not installed.
Your choice. It also means that you wouldn't benefit from possible security improvements in those components. It all has pros and cons. Wolfgang -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 2014-03-15 22:17 (GMT+0100) Wolfgang Rosenauer composed:
Felix Miata composed
On 2014-03-15 09:15 (GMT+0100) Wolfgang Rosenauer composed:
Ordinarily, that's what I would have done. However, as e.g. http://ftp.mozilla.org/pub/mozilla.org/firefox/releases/latest-17.0esr/linux... is timestamped November 2013 when the line's support ceased, it seems illogical not to assume the corresponding version on http://download.opensuse.org/repositories/mozilla:/legacy/openSUSE_13.1/i586... would have a last built date in the days or maybe a week or two following upstream's last build.
Then you didn't really understand what Linux distribution packaging is, how reliable build systems work and what OBS is all about.
s/really/fully/, and you're right. There's more to it than I'm aware of, including how to have multiple versions of Gecko browsers installed and running at once, a problem easily enough dealt with by using upstream binaries and keeping MOZ_NO_REMOTE set. I've chosen Firefox-17.0.x as the rpm version installed to standardize at a version with a level of feature loss lower than what upstream has implemented since, one that I can live with for the foreseeable future.
It's similarly non-obvious that content in mozilla:/legacy would have non-generic depends on some other repo than mozilla:/legacy, or that even if so, the dependency wouldn't have been published first if not coincident.
OBS has no support for dependency tracking like this. Actually it could have since it knows that mozilla is the base repo for mozilla:legacy. Keeping unmaintained packages in mozilla is no option. I'm already scared about having them in mozilla:legacy alone.
In the instant case, the system is an occasional use system. Updates need to be done in its available use window. Waiting would disrupt the use window scheduling that shouldn't need to be flexible except WRT alpha/beta testing, not supported final releases, and not "obsolete" packages.
This resurfaces the question what advantage there may be in rpm packages over the upstream generics at least WRT legacy releases? Upstream's 17.0.11 runs in 13.1's KDE4 without complaining even when all of mozilla-nspr, mozilla-nss and mozilla-nss-certs are not installed.
Your choice. It also means that you wouldn't benefit from possible security improvements in those components. It all has pros and cons.
Again you make it sound like one is ever enough. When "security" actually matters, I'm using latest release(s). When doing things that can't be done in latest, I use a version that supports what needs doing. I typically have 5 or more different ones running on one desktop, for all practical purposes, all the time. How could YaST or Zypper help with that? -- "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-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
participants (2)
-
Felix Miata -
Wolfgang Rosenauer