[prev in list] [next in list] [prev in thread] [next in thread] 

List:       opensuse-packaging
Subject:    Re: [opensuse-packaging] fubar mozilla repos?
From:       Felix Miata <mrmazda () earthlink ! net>
Date:       2014-03-16 0:05:58
Message-ID: 5324EAE6.2040802 () earthlink ! net
[Download RAW message or body]

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-i686/en-US/firefox-17.0.11esr.tar.bz2
> >  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


[prev in list] [next in list] [prev in thread] [next in thread]