Re: Proposal: Rethink Fedora multilib support

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 5 January 2017 at 19:29, Josh Boyer <jwboyer@xxxxxxxxxxxxxxxxx> wrote:
> On Thu, Jan 5, 2017 at 4:40 PM, Japheth Cleaver <cleaver@xxxxxxxxxxxxxx> wrote:
>> On 1/5/2017 9:12 AM, Jonathan Wakely wrote:
>>>
>>> On 05/01/17 09:56 -0700, Chris Murphy wrote:
>>>>
>>>> Teamviewer comes in an i686 only package for Fedora. So is there going
>>>> to be this interim approach, and then yet another change when they're
>>>> expected to use FlatPak? That's a lot of changes... And are these two
>>>> approaches compatible with the other platforms they target, or are
>>>> they just likely to drop the one it stops working on?
>>>>
>>>> I can hardly imagine Teamviewer is the only 32-bit only GUI program.
>>>
>>>
>>> There are all sorts of proprietary programs like Skype that are only
>>> provided as 32-bit packages (there's a "skypeforlinux" package which
>>> is 64-bit but it's an "alpha" release).
>>>
>>> Maybe it would work fine from inside a 32-bit container, I have no
>>> idea, but we should be careful not to make it harder for normal users
>>> to install and use software distributed outside Fedora. And not make
>>> it harder for ISVs to provide RPMs that work on Fedora with minimal
>>> effort.
>>
>>
>> I feel like if this happens it will hasten the day when those of us
>> primarily working in EL-variant land have to consider a need for a new,
>> EL-forward, RPM-based open source "community" OS.
>
> Can you elaborate why you think that?  Particularly the "EL-forward"
> part.  I don't understand how Stephen's line of thinking is not
> EL-forward.
>

I think it is because EL-forward means different things to different people.

1. Developer definition. EL-Forward is looking towards how something
will work in EL-next.
2. Enterprise operations. EL-Forward is looking towards how to take
something in current Fedora and move it forward to the version of
Enterprise you have deployed. [From a developer point of view it is
moving it backwards but it is because we are driving in two different
directions.]

A large amount of Enterprise ops people have to work in environments
with 30% of the systems being EL-5, 50% of the systems being EL-6 and
20% being EL-7. They have to both make corporate apps work with
ancient code bases but also get apps that need later items to make
things work. The work flow for this is

1. Find it in an 'approved' repo. [This was in the past EPEL but less
so due to aging items.]
2. Take the latest Fedora rpm and recompile/mangle the bits until it
works on EL5/EL6.
3. Get a bunch of tar-balls and make them work... but pay for the
upgrade problems later.

If they have problems in 2 or 1 they feed that back as bug reports and
considered that how they pushed Fedora forward. At some point they
would get to be able to install EL-8 and would have packages they knew
worked in Fedora from say Fedora-30 that would work for what they
needed.

Why does this not look forward to them?
1) They are still primarily having to deal with 32 bit applications.
2) They are only getting to virtualize their main environments. Yes
they have some systems somewhere in the giant bank IT that are
containered and that admin gets trotted out at docker con as the
forward way the world is working but 99% of the operations staff is
having to deal with an OS which is going to be EOL in 3 months and is
only now getting a budget which says they can move it to EL6. [They
can't move it to EL7 because the vendor still hasn't produced a
version of XYZ that 'works with systemd' (eg it relys on some initd
hack that they don't know how to fix to start up).]
3) Containers don't look baked yet. People are still arguing about how
to upgrade/update them.. the ones they google to see how it works of
them say they are read only but have instructions of 'install an ssh
and then log in and make these changes to really get it to work' etc
etc. Maybe Fedora will deliver all the packages in Fedora 27 with
docker formatting.. and maybe Fedora 28 will use a completely new
one..
4) The oracles they rely on to say this is how things are done in
Linux haven't agreed yet. The usual rule from previous technology
changes is don't bet on what the markets are using.. see what one
Linus uses for N months and if he doesn't like it see what he replaces
it with as that will be the way things go. [This is usually from
people who were burned deploying enterprise CVS, SVN, HG, BZR
solutions to have them all replaced with git in the last 5 years..
older admins have other Linus did it this way and everyone went that
way too.. the fact that Linus didn't have a tantrum and replace
systemd was pretty much the "ok it looks like this is the way things
are going"]

So if the OS they rely on to grab/build packages no longer offers a
way they can consume them (it has to be in a container which you will
need to run in your EL5/6 environment somehow..) then it can look like
the OS is no longer wanting EL to use it.

And it doesn't matter how much Red Hat says it is banking on
containers.. that is something that most of these Enterprise op people
aren't going to see for a decade.


-- 
Stephen J Smoogen.
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux