Use cases for official generic “Linux” builds vs. ABI-unstable system libraries

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

Use cases for official generic “Linux” builds vs. ABI-unstable system libraries

Henri Sivonen
(Taking discussion from Bugzilla to groups; see
https://bugzilla.mozilla.org/show_bug.cgi?id=794282 )
(In reply to Mike Hommey [:glandium] from comment #6)
> I doubt this is possible to do for official builds. Distro builds could do
> it, but official will likely have a hard time maintaining binary
> compatibility with different versions of the system libraries. Look at the
> ABI changes between 0.10 and 1.0.
> http://upstream-tracker.org/versions/gstreamer.html

(In reply to Mike Hommey [:glandium] from comment #7)
> and no, embedding gstreamer like we embed other third party libraries won't
> help. The only way it would work would be to also embed the mp4 decoder, and
> that's opening a legal can of worms.

First of all, I am in no way suggesting that we demote Linux in terms
of the tier-1 status as it applies to backing out breaking patches or
automated test builds.

With that out of the way:

What are the use cases for Mozilla-supplied generic Linux Firefox
tarball binary releases? Who uses them and why?

At least in the case of Ubuntu, even if you want to test a non-release
channel, you can get distro builds that integrate nicely with the
package management of the system. You can even get daily builds:
https://launchpad.net/~ubuntu-mozilla-daily/+archive/ppa
And on the other hand, Ubuntu-supplied builds work better on Ubuntu,
because they integrate with the global menu. (Consider how silly it
would be if we shipped on Mac without support for the system-style of
menu bar!)

If the ABI-instability of GStreamer or Unity’s global menu make it
unpractical to support generic “desktop Linux” with binary releases,
shouldn't we have a different way of releasing for “desktop Linux”
until “desktop Linux” gets its binary compatibility act together?

Instead of considering “Linux” a Mozilla-supported platform should we
consider “Ubuntu”, “Fedora” and “openSUSE” Mozilla-supported platforms
and let binary-incompatible x86/x86_64 Linux distros take care of
compiling their own binaries like they are already doing anyway at
least for the release channel? After all, the way we do automated
testing has been that the tests run on one popular distro, so de facto
“Linux” isn't a tier-1 platform for automation and backup purposes but
one of the distros is.

And if our supported platforms were “Ubuntu”, “Fedora” and “openSUSE”,
could Mozilla then work out a deal with them so that the builds they
make use at Mozilla-blessed compiler tool chain configuration so that
performance work done by Mozilla on e.g. the linker level would be
applicable to the builds and users actually get? And then Mozilla
would point to the distro packeges instead of generic tarballs. And
Mozilla would then accept bug reports for the distro-specific builds
for the “supported” distros. (My recollection is that when
Mozilla-supplied .deb or .rpm packages have been suggested, there have
been worries about stepping on the distros’ toes.) (I left “Debian”
out of the list, since clearly [and sadly], Mozilla and Debian still
don’t have the trademark stuff sorted out and Debian ships very old
libs anyway.)

--
Henri Sivonen
[hidden email]
http://hsivonen.iki.fi/
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Use cases for official generic “Linux” builds vs. ABI-unstable system libraries

Mike Hommey
On Wed, Sep 26, 2012 at 10:41:04AM +0300, Henri Sivonen wrote:

> (Taking discussion from Bugzilla to groups; see
> https://bugzilla.mozilla.org/show_bug.cgi?id=794282 )
> (In reply to Mike Hommey [:glandium] from comment #6)
> > I doubt this is possible to do for official builds. Distro builds could do
> > it, but official will likely have a hard time maintaining binary
> > compatibility with different versions of the system libraries. Look at the
> > ABI changes between 0.10 and 1.0.
> > http://upstream-tracker.org/versions/gstreamer.html
>
> (In reply to Mike Hommey [:glandium] from comment #7)
> > and no, embedding gstreamer like we embed other third party libraries won't
> > help. The only way it would work would be to also embed the mp4 decoder, and
> > that's opening a legal can of worms.
>
> First of all, I am in no way suggesting that we demote Linux in terms
> of the tier-1 status as it applies to backing out breaking patches or
> automated test builds.
>
> With that out of the way:
>
> What are the use cases for Mozilla-supplied generic Linux Firefox
> tarball binary releases? Who uses them and why?

And what proportion of Linux users do use them? I've seen the question
asked many times, but I don't recall seeing any answer to that question.

I do know some Debian users use the Mozilla builds because they don't
like iceweasel for some reason, or because they want the latest release
instead of what is in stable, backports or unstable, not knowing that,
in fact, Debian packages for releases, beta and aurora builds are
available.

I /think/ some users of other distros use the Mozilla builds because
they don't want the integration bits and/or because they have issues
with their distro builds.

Mike
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Use cases for official generic “Linux” builds vs. ABI-unstable system libraries

Zack Weinberg-2
In reply to this post by Henri Sivonen
On 2012-09-26 6:58 AM, Mike Hommey wrote:
>>
>> What are the use cases for Mozilla-supplied generic Linux Firefox
>> tarball binary releases? Who uses them and why?
>
> And what proportion of Linux users do use them? I've seen the question
> asked many times, but I don't recall seeing any answer to that question.

I generally think scrapping binary "generic Linux" tarball distribution
would be a good move on Mozilla's part, especially if it went along with
a move away from "the only supported configuration is embedded rather
than system libraries".

That said, I have *once* found the binary tarball useful, when I was
stuck with a corporate Linux desktop based on an ancient version of
Ubuntu, whose stock browser was Firefox 4 (when Mozilla was on 13,
iirc).  I did not have the ability to upgrade it, and I did not have
enough disk quota (or dependencies) to compile from source, but I was
able to unpack the tarball in my home directory and use that.  This is a
pretty marginal use case; if the tarball hadn't been available I would
probably have been able to persuade corporate IT to install a newer
browser from somebody's PPA, or something like that.

zw
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Use cases for official generic “Linux” builds vs. ABI-unstable system libraries

Mike Hommey
On Wed, Sep 26, 2012 at 12:20:29PM -0400, Zack Weinberg wrote:

> On 2012-09-26 6:58 AM, Mike Hommey wrote:
> >>
> >>What are the use cases for Mozilla-supplied generic Linux Firefox
> >>tarball binary releases? Who uses them and why?
> >
> >And what proportion of Linux users do use them? I've seen the question
> >asked many times, but I don't recall seeing any answer to that question.
>
> I generally think scrapping binary "generic Linux" tarball
> distribution would be a good move on Mozilla's part, especially if
> it went along with a move away from "the only supported
> configuration is embedded rather than system libraries".
>
> That said, I have *once* found the binary tarball useful, when I was
> stuck with a corporate Linux desktop based on an ancient version of
> Ubuntu, whose stock browser was Firefox 4 (when Mozilla was on 13,
> iirc).  I did not have the ability to upgrade it, and I did not have
> enough disk quota (or dependencies) to compile from source, but I
> was able to unpack the tarball in my home directory and use that.
> This is a pretty marginal use case; if the tarball hadn't been
> available I would probably have been able to persuade corporate IT
> to install a newer browser from somebody's PPA, or something like
> that.

The binary tarballs are also useful for regression tracking. It's much
harder to do with distro packages, if at all possible.

Mike
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Use cases for official generic “Linux” builds vs. ABI-unstable system libraries

pascal chevrel
In reply to this post by Henri Sivonen
Le 26/09/2012 09:41, Henri Sivonen a écrit :

> (Taking discussion from Bugzilla to groups; see
> https://bugzilla.mozilla.org/show_bug.cgi?id=794282 )
> (In reply to Mike Hommey [:glandium] from comment #6)
>> I doubt this is possible to do for official builds. Distro builds could do
>> it, but official will likely have a hard time maintaining binary
>> compatibility with different versions of the system libraries. Look at the
>> ABI changes between 0.10 and 1.0.
>> http://upstream-tracker.org/versions/gstreamer.html
>
> (In reply to Mike Hommey [:glandium] from comment #7)
>> and no, embedding gstreamer like we embed other third party libraries won't
>> help. The only way it would work would be to also embed the mp4 decoder, and
>> that's opening a legal can of worms.
>
> First of all, I am in no way suggesting that we demote Linux in terms
> of the tier-1 status as it applies to backing out breaking patches or
> automated test builds.
>
> With that out of the way:
>
> What are the use cases for Mozilla-supplied generic Linux Firefox
> tarball binary releases? Who uses them and why?

Hi,

Most of our core localizers are Linux users, they follow mozilla-central
and use our localized nightly builds to see their strings and QA their
builds.

They are not users as in 'people that add to our marketshare', but I
think that building firefox for them is important if we want products of
quality.

There are also problems with distro-provided packages related to l10n,
for example they don't release localized builds but en en-US build with
a language pack, that means for example that the search engines are not
local, that the default protocol providers (mail, news, rss) are the
default en-US ones and that the provided dictionnary is the OS
dictionnary, usually a myspell one that doesn't work correctly, while
the official Mozilla build comes with our own dictionnary based on hunspell.


Cheers

Pascal

PS: also, not all Ubuntu users keep unity as their environment, Ubuntu
user here and happy Gnome 3 user to ;)
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Use cases for official generic “Linux” builds vs. ABI-unstable system libraries

Karl Tomlinson-4
In reply to this post by Henri Sivonen
Our nightly users, at least the ones that report bugs, are very
valuable for product quality.

I doubt we would get a similarly smooth daily upgrade from each of
the distributions, and I haven't heard of distribution packaging
systems that provide for installation and differential upgrades
without root privileges.
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Use cases for official generic “Linux” builds vs. ABI-unstable system libraries

Nicolas B. Pierron
On 09/26/2012 03:23 PM, Karl Tomlinson wrote:
> I doubt we would get a similarly smooth daily upgrade from each of
> the distributions, and I haven't heard of distribution packaging
> systems that provide for installation and differential upgrades
> without root privileges.

You can use an external package manager such as Nix which handles both of
your concerns, see sections “Multi-user support” and “Binary patching” at
http://nixos.org/nix/ .

--
Nicolas B. Pierron
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Use cases for official generic “Linux” builds vs. ABI-unstable system libraries

Henri Sivonen
In reply to this post by Henri Sivonen
So to summarize use cases for Mozilla-supplied tarball builds for Linux:

Use cases for Mozilla-supplied tarball releases for Linux:
 1) People who don't like to look at Iceweasel branding get to look at
Firefox branding instead.
 2) People who are unaware that up-to-date versions Iceweasel are
available get to run up-to-date software nonetheless.
 3) Resolving unspecified issues with distro builds.
 4) Installing the latest version without root access when whoever has
root access does not keep Firefox up-to-date.
 5) Getting locale-specific search engine and
registerProtocolHandler() defaults.
 6) Getting better spellchecking in some non-English cases.

Use cases for Mozilla-supplied tarball nightlies for Linux:
 7) Being able to test nightlies at all on distros that don't provide
a nightly channel.
 8) Being able to bisect for regressions more easily than with
packages from a distro-provided nightly channel.
 9) Being able to test nightlies without root access.
10) Using localized nightlies to track the localization status.

The first three points don't seem particularly strong to me. While I
would prefer users of the code base being able to look at Firefox
branding rather than Iceweasel branding, it seems a lot less important
to me to allow Debian users work around the consequences of the
collision of Debian and Mozilla policies around trademarks than to
support functionality like system GStreamer or Unity global menu.
Also, it seems like a bad idea for Mozilla to allocate resources to
address Debian user unawareness of how to deal with Debian policies
that require shipping out-of-date software by default (i.e.
unawareness of the repo chooser at http://mozilla.debian.net/). As for
unspecified issues with distro builds, I think the point isn't
particularly strong without concrete data about what the issues are
and why they aren't being fixed by the relevant distributions.

From my own experience, I recognize points 4 and 9 being real issue
for some users, but to me the non-root case seems such a minority case
that I doubt it's being important enough for Mozilla to address when
balanced against supporting system GStreamer, Unity global menu and
integration with the package manager in the common case.

Point #5 makes me wonder why locale-specific search engine and
registerProtocolHandler() defaults cannot be bundled in a language
pack. It seems to me that that would be a much better solution than
having users fight their distro.

In the case of points #6 and #10, I don't understand well enough why
things are the way they are. Why do distros downgrade spellchecking
capability? Is it a licensing thing? (For Finnish, the proper
spellchecker is Finnish-specific [i.e. not a hunspell dict anyway] and
is provided as an add-on, so I'm not familiar with the case of
downgrading capability when a hunspell dict would work.) Is there a
reason why it's more convenient to provide localized nightly builds as
opposed to making a language pack installed in a nightly auto-update
together with a nightly build?

As for point #7, do we know how our nightly testers are spread across
Linux distributions? Which distributions would need to have nightly
coverage to avoid shrinking the tester population significantly if
nightlies were produced on a per-distro basis? Is Ubuntu currently the
only distro with a distro-specific daily/nightly channel?

To me, point #8 looks the strongest. Is it feasible to automatically
rearrange the contents of a .deb or an .rpm into tarball whose
contents run on the same distro that the .deb or .rpm package would
run on? That is, if .deb and .rpm nightlies were the solution for
getting builds that auto-update and reflect the configuration of the
builds that most of our Linux users end up using when they obtain
release builds from their distro, would it be feasible to produce
tarballs for regression bisection by munging the .deb and .rpm
packages into tarballs without having to spend infrastructure
resources to recompile?

--
Henri Sivonen
[hidden email]
http://hsivonen.iki.fi/
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Use cases for official generic “Linux” builds vs. ABI-unstable system libraries

Chris Double
On Thu, Nov 8, 2012 at 1:35 AM, Henri Sivonen <[hidden email]> wrote:
>  3) Resolving unspecified issues with distro builds.

I don't think Gentoo provides nightly builds. The version of Firefox
they have seems to be 10.0.9 ESR. I'd rather use a nightly build from
Mozilla without GStreamer than 10.0.9 ESR.

Chris.
--
http://www.bluishcoder.co.nz
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Use cases for official generic “Linux” builds vs. ABI-unstable system libraries

Alexander L. Slovesnik-2
In reply to this post by Henri Sivonen

В письме от Срд, 07 Ноя 2012, 16:35 Henri Sivonen пишет:
> In the case of points #6 and #10, I don't understand well enough why
> things are the way they are. Why do distros downgrade spellchecking
> capability? Is it a licensing thing? (For Finnish, the proper
> spellchecker is Finnish-specific [i.e. not a hunspell dict anyway] and
> is provided as an add-on, so I'm not familiar with the case of
> downgrading capability when a hunspell dict would work.) Is there a
> reason why it's more convenient to provide localized nightly builds as
> opposed to making a language pack installed in a nightly auto-update
> together with a nightly build?

Language packs, installed from ftp.mozilla.org, don't autoupdate (Bug
451824).

--
Sincerely yours,
 Alexander L. Slovesnik a.k.a. Unghost
==>Web-page: http://www.unghost.ru/
==>Jabber ID: [hidden email]
==>Gmail Talk ID: [hidden email]
==>ICQ: 205497659
==>IRC: irc://irc.mozilla.org/mozilla-ru

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Use cases for official generic “Linux” builds vs. ABI-unstable system libraries

Robert Kaiser
In reply to this post by Henri Sivonen
Henri Sivonen schrieb:
>   8) Being able to bisect for regressions more easily than with
> packages from a distro-provided nightly channel.

I see that as really major - esp. as usually the distros do not keep
archives of of packages (which are needed for that regression tracking).

Also, the easy scriptable "installing" of those builds is essential in
being able to run our automated test suites right on our own Mozilla
systems.

Robert Kaiser

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Use cases for official generic “Linux” builds vs. ABI-unstable system libraries

Henri Sivonen
In reply to this post by Chris Double
On Wed, Nov 7, 2012 at 3:48 PM, Chris Double <[hidden email]> wrote:
> On Thu, Nov 8, 2012 at 1:35 AM, Henri Sivonen <[hidden email]> wrote:
>>  3) Resolving unspecified issues with distro builds.
>
> I don't think Gentoo provides nightly builds. The version of Firefox
> they have seems to be 10.0.9 ESR. I'd rather use a nightly build from
> Mozilla without GStreamer than 10.0.9 ESR.

Isn’t it against the spirit of Gentoo to use binaries compiled by
someone else? :-)

More seriously, though, if the choice is between giving tested system
GStreamer support to Ubuntu and Fedora users versus enabling Gentoo
users work around the Firefox versioning policy of their distro, I'd
much rather give system GStreamer support to Ubuntu and Fedora users.

On Wed, Nov 7, 2012 at 4:25 PM, Robert Kaiser <[hidden email]> wrote:

> Henri Sivonen schrieb:
>
>>   8) Being able to bisect for regressions more easily than with
>> packages from a distro-provided nightly channel.
>
> I see that as really major - esp. as usually the distros do not keep
> archives of of packages (which are needed for that regression tracking).
>
> Also, the easy scriptable "installing" of those builds is essential in being
> able to run our automated test suites right on our own Mozilla systems.

Being able to bisect is a good reason to keep archived nightly
tarballs available. It doesn't follow that the tarballs should be
generic. In particular, if most of our users use distro-provided
release builds, I think it would be better for our nightly tester
population to test the same build configuration even if for bisecting
those bits are provided as tarballs rather than a .deb or .rpm. Right
now, the Linux nightly tester population tests a different
configuration than the configurations most of the release version
users end up using.

It could be a problem if the mix of distributions used by the nightly
tester population differs significantly from the mix of distributions
used by release channel users. For example, if we determined that
release channel users use Ubuntu and Fedora, targeting nightly builds
to Ubuntu and Fedora would be a problem if our nightly tester
population was instead predominantly using Debian and Gentoo.

Do we have data about the mix of distributions used by the natural
tester population and the mix of distributions used by the release
population (including people who obtain their Firefox binary from
their distribution).

--
Henri Sivonen
[hidden email]
http://hsivonen.iki.fi/
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Use cases for official generic “Linux” builds vs. ABI-unstable system libraries

Mounir Lamouri-3
In reply to this post by Chris Double
On 07/11/12 13:48, Chris Double wrote:
> On Thu, Nov 8, 2012 at 1:35 AM, Henri Sivonen <[hidden email]> wrote:
>>  3) Resolving unspecified issues with distro builds.
>
> I don't think Gentoo provides nightly builds. The version of Firefox
> they have seems to be 10.0.9 ESR. I'd rather use a nightly build from
> Mozilla without GStreamer than 10.0.9 ESR.

That is incorrect. Gentoo provides 16.0.2, 15.0.1, 10.0.{10, 9, 7, 6} as
binary builds [1] and 16.0.2, 10.0.{10, 9, 7, 6, 5, 4} as source-based
builds.

ESR builds are the only ones marked as "stable". This explains why there
are so many versions of it: depending on your architecture, 10.0.x or
10.0.y might be marked as stable (given that the process imply manual
testing).

[1] http://packages.gentoo.org/package/www-client/firefox-bin
[2] http://packages.gentoo.org/package/www-client/firefox

Cheers,
--
Mounir
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Use cases for official generic “Linux” builds vs. ABI-unstable system libraries

Robert Kaiser
In reply to this post by Chris Double
Henri Sivonen schrieb:
> Being able to bisect is a good reason to keep archived nightly
> tarballs available. It doesn't follow that the tarballs should be
> generic.

If we don't want to heighten the storage requirements by providing
packages for multiple distros (say, the 3-5 major Linux ones plus
ubuntu, which seems to recently not label themselves as Linux any more),
then the generic ones that *should* work independent of distros should
be the best choice. Also, it's really nice for regression testing if you
don't have to replace your "stable" browser with the one you're testing
- but distro-format packages usually are not flexible in where to be
installed, while our generic tarballs are.

> It could be a problem if the mix of distributions used by the nightly
> tester population differs significantly from the mix of distributions
> used by release channel users. For example, if we determined that
> release channel users use Ubuntu and Fedora, targeting nightly builds
> to Ubuntu and Fedora would be a problem if our nightly tester
> population was instead predominantly using Debian and Gentoo.

Or openSUSE, or Arch, or ScientificLinux, or... (you get the picture)

Robert Kaiser
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Use cases for official generic “Linux” builds vs. ABI-unstable system libraries

Brian Smith-31
In reply to this post by Henri Sivonen
Henri Sivonen wrote:
> In the case of points #6 and #10, I don't understand well enough why
> things are the way they are. Why do distros downgrade spellchecking
> capability? Is it a licensing thing? (For Finnish, the proper
> spellchecker is Finnish-specific [i.e. not a hunspell dict anyway]
> and is provided as an add-on, so I'm not familiar with the case of
> downgrading capability when a hunspell dict would work.) Is there a
> reason why it's more convenient to provide localized nightly builds
> as opposed to making a language pack installed in a nightly
> auto-update together with a nightly build?

IMO, we should only let a distro call their build of Firefox "Firefox" if it is as good as our builds of Firefox. Why not just put explicit requirements for spellchecking and other functionality that tends to be degraded (including ECC support) into the Firefox trademark policy?

Similarly, I am not sure why we can't just say that the GStreamer v.Whatever+ system library is a requirement for Firefox the same way glibc v.Whatever+ is.

> To me, point #8 looks the strongest. Is it feasible to automatically
> rearrange the contents of a .deb or an .rpm into tarball whose
> contents run on the same distro that the .deb or .rpm package would
> run on? That is, if .deb and .rpm nightlies were the solution for
> getting builds that auto-update and reflect the configuration of the
> builds that most of our Linux users end up using when they obtain
> release builds from their distro, would it be feasible to produce
> tarballs for regression bisection by munging the .deb and .rpm
> packages into tarballs without having to spend infrastructure
> resources to recompile?

I thought that RPM was the standard, as far as the Linux Standard Base is a standard for Linux. My understanding is that Debian and Ubuntu can install RPMs without too much hassle using alien. I also understand that it is possible to create RPMs that are relocatable so that users can install them in their home directories, or wherever, without being root; see rpm --relocate. It seems alien also understands relocatable packages. So, it seems to me like we should be able to build a single RPM that has a dependency on the GStreamer package and whatever, and call it a day. Would that solve the problems you're trying to solve?

It might be nice for marketing reasons if we could create a .deb too, if it is not a lot of work. (I suspect that if we standardize on RPM, somebody will contribute the equivalent/better .deb packaging just to show us how silly it is to only ship RPMs.)

Cheers,
Brian
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Use cases for official generic “Linux” builds vs. ABI-unstable system libraries

Ben Hearsum-2
In reply to this post by Henri Sivonen
On 11/10/12 05:54 PM, Brian Smith wrote:

> Henri Sivonen wrote:
>> In the case of points #6 and #10, I don't understand well enough why
>> things are the way they are. Why do distros downgrade spellchecking
>> capability? Is it a licensing thing? (For Finnish, the proper
>> spellchecker is Finnish-specific [i.e. not a hunspell dict anyway]
>> and is provided as an add-on, so I'm not familiar with the case of
>> downgrading capability when a hunspell dict would work.) Is there a
>> reason why it's more convenient to provide localized nightly builds
>> as opposed to making a language pack installed in a nightly
>> auto-update together with a nightly build?
>
> IMO, we should only let a distro call their build of Firefox "Firefox" if it is as good as our builds of Firefox.

"as good" is not just defined by features. It's defined by performance
(which is affected by things like which versions of libraries you link
to, how you compile it, etc.) as well as crashiness.

What kind of tests do distros run on their builds of Firefox? Do they
run unit tests? Perf tests?

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Use cases for official generic “Linux” builds vs. ABI-unstable system libraries

Henri Sivonen
In reply to this post by Brian Smith-31
On Sun, Nov 11, 2012 at 12:54 AM, Brian Smith <[hidden email]> wrote:
> IMO, we should only let a distro call their build of Firefox "Firefox" if it is as good as our builds of Firefox. Why not just put explicit requirements for spellchecking and other functionality that tends to be degraded (including ECC support) into the Firefox trademark policy?

It’s worth keeping in mind that the next option that distros are
likely to consider if Mozilla becomes too annoying with trademarks is
no longer unbranded Firefox but Chromium.

I think it would be more fruitful to have two-way communication with
distros in order to move to a situation where Mozilla tests what
distros will ship and not only by the means of Mozilla dictating to
distros what to ship but listening to distros what sort of config
needs testing.

> Similarly, I am not sure why we can't just say that the GStreamer v.Whatever+ system library is a requirement for Firefox the same way glibc v.Whatever+ is.

With glibc, “Whatever+” works because future glibc will provide an ABI
that works with programs compiled against a past glibc. The
observation that started this thread was that GStreamer’s ABI does not
have that compatibility characteristic. Neither has the ABI of the
library for interfacing with Unity’s global menu.

This thread is about two things:

1) From the perspective of an ISV seeking to ship binaries, “Desktop
Linux” is full of fail and facepalm, because ABIs may not be
forward-compatible within a given distro and may not be
sideways-compatible between distros. As such an ISV, Mozilla is shy to
use APIs that it should use in order to properly integrate with the
platform.

2) As a consequence of #1, many open-source apps born in the Linux
world don’t even try to ship Linux binaries, only ship Windows and Mac
binaries (again, full of fail and facepalm) and tell users to get
their binaries from the distro. In accordance with this pattern, most
Firefox users on “Desktop Linux” get their Firefox from their distro
(in the case of e.g. Ubuntu with Ubuntu-specific platform integration
features). Yet, Mozilla pretends that it's shipping a “Desktop Linux”
product as a binary the way it is shipping Windows and Mac products.
This leads to Mozilla testing a different “Desktop Linux” product than
what most “Desktop Linux” users end up using.

(The situation with binary compatibility is quite twisted. For
example, when a new release of GIMP comes out, you can download
binaries for Windows and Mac by following links from the official site
but for various Linux distributions you either need to wait for a new
release of the distribution or use some random build from somewhere
and hope that it is legitimate. See http://www.gimp.org/downloads/

The major open source projects that still ship binaries seem to be the
ones that have their own GUI toolkit that uses Gtk mainly for theming:
Firefox, Eclipse and LibreOffice.

If you want ABI compatibility across Linux distributions and versions,
the best bet is probably writing to Win32 and using Wine!)

>> To me, point #8 looks the strongest. Is it feasible to automatically
>> rearrange the contents of a .deb or an .rpm into tarball whose
>> contents run on the same distro that the .deb or .rpm package would
>> run on? That is, if .deb and .rpm nightlies were the solution for
>> getting builds that auto-update and reflect the configuration of the
>> builds that most of our Linux users end up using when they obtain
>> release builds from their distro, would it be feasible to produce
>> tarballs for regression bisection by munging the .deb and .rpm
>> packages into tarballs without having to spend infrastructure
>> resources to recompile?
>
> I thought that RPM was the standard, as far as the Linux Standard Base is a standard for Linux.

What's written down in the Linux Standard Base doesn't really matter.
What matters is what systems our end-users use are like. (Where “our”
includes users of distro-provided Firefox builds.)

> My understanding is that Debian and Ubuntu can install RPMs without too much hassle using alien.

Do you have an example of a non-trivial app for which this method
actually works? For starters, alien is not installed by default on
Ubuntu and there does not seem to be any GUI facilities for installing
downloaded .rpm packages.

I managed to locate Maxima as an example of a non-trivial app that is
distributed as a set of supposedly distro-independent .rpm files and
not distributed as a .deb, but the .rpm files were only available as
32-bit and alien on 64-bit Ubuntu can't deal with 32-bit .rpm files,
so I couldn’t test further.

> I also understand that it is possible to create RPMs that are relocatable so that users can install them in their home directories, or wherever, without being root; see rpm --relocate. It seems alien also understands relocatable packages. So, it seems to me like we should be able to build a single RPM that has a dependency on the GStreamer package and whatever, and call it a day. Would that solve the problems you're trying to solve?

It would not solve the problem of users being on different sides of an
ABI discontinuity. Also, having a single RPM build would not solve the
problem of Mozilla testing a different config than what Linux users
end up using.

> It might be nice for marketing reasons if we could create a .deb too, if it is not a lot of work.

It would probably work as anti-marketing to have .rpm without having
.deb at the same time.

--
Henri Sivonen
[hidden email]
http://hsivonen.iki.fi/
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning