3 ms·

Another potential possibility: Ubuntu Firefox is Mozilla's Firefox coupled with arbitrary modifications by the Ubuntu developers. In principle I respect Ubunt

by evmar 14y ago

Another potential possibility: Ubuntu Firefox is Mozilla's Firefox coupled with arbitrary modifications by the Ubuntu developers. In principle I respect Ubuntu's position and desire to make things right by their users. But in practice, having been in the same relationship as an author of Chrome for Linux I can tell you that it's always dangerous to have people who aren't browser developers make modifications to a browser. More than once the Ubuntu Chromium packager made changes to Chrome that were harmful for users because they didn't understand the consequences of their changes.

el_presidente 14y ago
Maintaining Chromium packages on Linux is a nightmare. Here's the line count for different browser packages on Gentoo: 408 chromium/chromium-20.0.1123.4.ebuild 349 firefox/firefox-12.0.ebuild 42 rekonq/rekonq-0.9.2.ebuild 98 midori/midori-0.4.5.ebuild 90 epiphany/epiphany-3.4.1.ebuild 61 conkeror/conkeror-1.0_pre20120223.ebuild 64 dillo/dillo-3.0.2.ebuild
- jamesaguilar 14y ago
  So, it's of the same order of difficulty as Firefox? Is this surprising?
  - lmm 14y ago
    For a modern codebase, yes.
- mst 14y ago
  The interesting question isn't the raw number, it's what those 408 lines are doing - it's entirely possible that half of that could go upstream. For some years, lots of vendors had patches to mess around with perl's default @INC order, all of which were distro-specific and not really generalisable, because nobody had bothered to submit the upstream change that would have got rid of that whole class of patches. Now, I suspect the reasons for that may have been to do with perl's then rather slower pace of releases, so people didn't see the point when perl5 version 10 was apparently not getting any closer, but just because that reason doesn't apply to chromium doesn't mean there isn't a similarly convincing one for local patches. It also doesn't mean there -is-; I've always been fond of local patches to software being corresponded with a distro bug and preferably with an upstream bug explaining the rationale; it may not avoid the necessity for the patch but it at least means the conversation that led to it is both visible and involved the right people.
  - simcop2387 14y ago
    Looking through the ebuild it looks like a decent amount of it is related to keeping it from using bundled libraries instead of the system ones when building. After that it looks like most of the rest of the complexity is related to getting things installed to the proper places.
wasd 14y ago
I think this is precisely it. I've had this same problem and others on Linux Mint. I wasn't able to fix them until I built FF from source.
- deleted 14y ago
  [deleted]
deleted 14y ago
[deleted]

by evmar 14y ago

el_presidente 14y ago

Maintaining Chromium packages on Linux is a nightmare. Here's the line count for different browser packages on Gentoo: 408 chromium/chromium-20.0.1123.4.ebuild 349 firefox/firefox-12.0.ebuild 42 rekonq/rekonq-0.9.2.ebuild 98 midori/midori-0.4.5.ebuild 90 epiphany/epiphany-3.4.1.ebuild 61 conkeror/conkeror-1.0_pre20120223.ebuild 64 dillo/dillo-3.0.2.ebuild

jamesaguilar 14y ago
So, it's of the same order of difficulty as Firefox? Is this surprising?
- lmm 14y ago
  For a modern codebase, yes.
mst 14y ago
The interesting question isn't the raw number, it's what those 408 lines are doing - it's entirely possible that half of that could go upstream. For some years, lots of vendors had patches to mess around with perl's default @INC order, all of which were distro-specific and not really generalisable, because nobody had bothered to submit the upstream change that would have got rid of that whole class of patches. Now, I suspect the reasons for that may have been to do with perl's then rather slower pace of releases, so people didn't see the point when perl5 version 10 was apparently not getting any closer, but just because that reason doesn't apply to chromium doesn't mean there isn't a similarly convincing one for local patches. It also doesn't mean there -is-; I've always been fond of local patches to software being corresponded with a distro bug and preferably with an upstream bug explaining the rationale; it may not avoid the necessity for the patch but it at least means the conversation that led to it is both visible and involved the right people.
- simcop2387 14y ago
  Looking through the ebuild it looks like a decent amount of it is related to keeping it from using bundled libraries instead of the system ones when building. After that it looks like most of the rest of the complexity is related to getting things installed to the proper places.

wasd 14y ago

I think this is precisely it. I've had this same problem and others on Linux Mint. I wasn't able to fix them until I built FF from source.

deleted 14y ago
[deleted]

deleted 14y ago

[deleted]