| |||||||||||||
Untz: Results of the App Installer meeting, and some thoughts on cross-distro collaborationUntz: Results of the App Installer meeting, and some thoughts on cross-distro collaborationPosted Jan 26, 2011 2:57 UTC (Wed) by skvidal (subscriber, #3094)Parent article: Untz: Results of the App Installer meeting, and some thoughts on cross-distro collaboration
package/app install/updating is critical to how a distro does everything it does. So to suggest more collaboration between distros is to, implicitly suggest collapsing distros together.
What's the major distinguishing factor between debian and fedora?
dpkg vs rpm.
Why would debian want to switch to rpm? What does it do for them to have to retrofit a million things into new processes and new behaviors?
Why would fedora want to switch to dpkg? What does it do for them to retrofit a million things into new processes and new behaviors?
So, what is the incentive for a distro that wants to survive and be independent to collaborate on this kind of technology?
There has to be a big win to the technology to promote collaboration and thus far there's been nothing.
I suspect that the pain of migration will continue to outweigh the benefit of the technology and what is more likely to happen is that more and more of the major distros will die out due to external economic realities until the options are winnowed down. Then cross-distro collaboration is less important.
(Log in to post comments)
Untz: Results of the App Installer meeting, and some thoughts on cross-distro collaboration Posted Jan 26, 2011 3:27 UTC (Wed) by yarikoptic (subscriber, #36795) [Link]
> So, what is the incentive for a distro that wants to survive and be independent to collaborate on this kind of technology?
Because there is LOTS of effort duplication going on and joining the forces would benefit all communities and companies staying behind (echoing your 'Debian/Fedora difference question'). Neither distribution is suicidal enough to artificially create "differences" just for the sake of staying "different"; but it historically happened that different approaches/instrumentations/ideologies came into existence and now split the "distributions" market and userbase.
Untz: Results of the App Installer meeting, and some thoughts on cross-distro collaboration Posted Jan 26, 2011 3:38 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link]
there is work that can be re-used (figuring out what apps and library versions a particular application needs for example), and there are parts that cannot (the final packaging into .deb or .rpm)
keep in mind that there are applications that do a pretty good job of converting between .deb and .rpm today, that could be enhanced, or a new metadata format could be created that contains a superset of the data that the different package formats need (making the job of creating packages for multiple distros easier)
also, feeding patches between distros and to the upstream will also help reduce duplicated effort.
Untz: Results of the App Installer meeting, and some thoughts on cross-distro collaboration Posted Jan 26, 2011 22:07 UTC (Wed) by vonbrand (subscriber, #4458) [Link] there is work that can be re-used (figuring out what apps and library versions a particular application needs for example) Most of that is done automatically today. E.g. in Fedora the packaging guidelines specify that only in rare cases the packager should give dependencies explicitly. keep in mind that there are applications that do a pretty good job of converting between .deb and .rpm today, that could be enhanced, or a new metadata format could be created that contains a superset of the data that the different package formats need (making the job of creating packages for multiple distros easier) It isn't just a "format" issue, the differences are in packaging policies (i.e., what packages are named, how much to split up packages for libraries, handling of documentation). And futhermore there are differences in configuration handling (e.g., how/if default configurations are handled, where configuration is kept, how it is handled). also, feeding patches between distros and to the upstream will also help reduce duplicated effort. That is a distribution policy issue. I believe distributions have gotten ever better at working (with) upstream, keeping local patches only where strictly necessary (or as an interim fix while upstream fixes their code). Disclaimer: I'm a Fedora user and ambassador, so the above might certainly be biased by the distribution I do know best.
Untz: Results of the App Installer meeting, and some thoughts on cross-distro collaboration Posted Jan 26, 2011 4:10 UTC (Wed) by nevyn (subscriber, #33129) [Link]
> Because there is LOTS of effort duplication going on and joining the forces would benefit all
> communities and companies staying behind
Sure, and there's lots of effort duplication between Qt+KDE and gtk+GNOME ... and with GNOME3 and Ubuntu that looks like it might split again.
As Seth said, the problem is that after the initial split and time investment it's just _really_ hard to merge back. And to create "a standard" that multiple people can implement to easily, is at least as hard as everyone just doing their own thing with very few benefits (what users will care that backend format X is shared with distro. FOO which they'll never use).
Untz: Results of the App Installer meeting, and some thoughts on cross-distro collaboration Posted Jan 26, 2011 4:29 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link]
I'll point out that KDE and Gnome are cooperating, that's what freedesktop.org is all about, they are working to define the underlying pieces in a way that they can both live with, even if the implementation and visible result is significantly different between the two.
Ubuntu is straying from this a bit, but unless they get buy-in from lots of application developers to write to a different, Ubuntu specific API, it won't stay separate long term (it may be that Ubuntu moves back to mechanisms that currently exist, or it may be that some of the things that Ubuntu is trying become standard and the other desktops start supporting them)
Untz: Results of the App Installer meeting, and some thoughts on cross-distro collaboration Posted Jan 26, 2011 15:46 UTC (Wed) by nix (subscriber, #2304) [Link]
freedesktop.org often looks a lot more like 'GNOME people define stuff, KDE people use it'. GNOME people get their stuff in without effort: when KDE people try, all too often there is endless argument and nothing happens.
Untz: Results of the App Installer meeting, and some thoughts on cross-distro collaboration Posted Jan 28, 2011 4:08 UTC (Fri) by markshuttle (subscriber, #22379) [Link]
Much of the Unity work in Ubuntu is based on FreeDesktop.org collaboration with, amongst others KDE, and it's Gnome which has decided to purse a different course.
The Ubuntu indicators framework, for example, was developed in Ubuntu after discussions with Gnome developers, and was also developed in collaboration with KDE developers. When it was ready, Gnome Shell said they had decided to do something different altogether. It's a little perverse to be accused of being uncollaborative when you:
o discuss work in advance with the Gnome team and get a go-ahead to drive forward
The dynamics of collaboration in open source are fluid and complex. There's a lot that happens which is constructive, and there are also things that make everyone want to despair. But it's simply inaccurate to paint one group as a primary bad guy; much just depends on who was where at the time.
Untz: Results of the App Installer meeting, and some thoughts on cross-distro collaboration Posted Jan 26, 2011 9:39 UTC (Wed) by oldtomas (guest, #72579) [Link]
Yes. As dlang said, there are many creative ways projects can cooperate, and things become really interesting in the realm of Free Software. The important part is to stay in touch and try to talk to others while implementing new stuff (watch, for example, the Emacs vs. XEmacs cooperation these days. When introducing changes, thought goes into how those changes can benefit both).
Things which come to mind cross-distro:
* Abstract package structure (which attributes, what's a dependency, etc.)
No need to be directly able to install an RPM in Debian (although even this is somewhat possible these days!)
dpkg v rpm Posted Jan 26, 2011 4:27 UTC (Wed) by corbet (editor, #1) [Link] Interesting...when I think about the differences between Debian and Fedora, the package manager is mostly an incidental detail. Sort of like saying the main difference between Australia and the US is that they drive on different sides of the street. Things like release process, how the community works, project governance, etc. strike me as being much more important.
dpkg v rpm Posted Jan 26, 2011 7:39 UTC (Wed) by skvidal (subscriber, #3094) [Link]
How does project governance matters to how the OS works?
B/c that's what we're talking about.
Not how the community hangs together (or not) as the case may be.
we're talking about the processes to:
it's all coupled tightly to the packaging tools.
The os itself is the same ON PURPOSE.
apache on debian and apache on fedora are, by and large, the same.
The set of policies/rules are just the sausage-making process.
Take a distro to its component parts of the OS:
parts 1, 2, and 3 need to be very similar for us to call it 'linux' don't they?
Packaging/installation/maintenance is the separation point.
Debian
So, I don't generally group rpm and deb as the split. It's more like 'families' of distros.
debian is one family of distros including: debian and ubuntu and all the derivatives thereof.
red hat is another including: rhel, fedora, centos, etc.
SuSE is another including: SLED/SLES and OpenSUSE
Mandriva is another.
The tools that tie each of these together are their installation/update/pkging tools.
Those are the tools the admin/user end up having to be most familiar with.
That's what I mean when I say the packaging is where things vary.
dpkg v rpm Posted Jan 26, 2011 14:16 UTC (Wed) by sorpigal (subscriber, #36106) [Link]
For me the most important differences between a Debian system and a Fedora system aren't package format (no one cares) or package manager (even though apt is better!) or package related tools. The important differences are the results of policies that are different.
How are network interfaces configured? What about firewalls? Where do defaults get set? What tools control runlevel services? What is the layout of /var/? Where is documentation stored? What can be found in /usr/local/? If you have a bug, what do you do? Everything here is different and has nothing to do with packaging as such. In some cases such decisions can be made by the user by installing a different package from the default, but then which was the default was a distro policy decision.
I'm all for working together on things not related to packaging, but I use Debian because I tend to like the design decisions Debian makes. I don't want to see other distribution's decisions creeping in to mine (and I'm sure this is mutual).
dpkg v rpm Posted Jan 26, 2011 17:58 UTC (Wed) by iabervon (subscriber, #722) [Link] Take a distro to its component parts of the OS: Parts 1 and 2 are generally very similar (although the initial filesystem stuff was, at least until recently, totally custom for each distro). But part 3 varies widely between distros, at least with respect to the willingness to experiment with alternatives and be early adopters. Distros varied in when they started using Pulseaudio; what replacement(s) for sysv init they tried; how they set up networking; the support code for init scripts; when they adopted what of hal/dbus/udev/ConsoleKit/PolicyKit; the default mail server; the default mailbox file format; and so on, down to whether they ship a version of Alpine that outputs utf-8 or are too concerned about the legal status of those patches. And, of course, these adoption decisions are made using the distro's project governance process. Furthermore, these differences trickle into the packages; when one distro is using upstart and another is using sysv init, their apache packages have to include different scripts to manage getting apache to run, and when a third distro is also using upstart, there isn't a way to avoid duplicating the uninteresting work of maintaining the script for the apache package. That is, the differentiation between distros is a bunch of choices the distro makes that matter in small but critical ways to the packages they ultimately provide. This forces them to maintain their own packages independently, and the individualized packages are a cost, not a benefit, of the differentiation.
Untz: Results of the App Installer meeting, and some thoughts on cross-distro collaboration Posted Jan 26, 2011 4:34 UTC (Wed) by elanthis (guest, #6227) [Link]
"dpkg vs rpm."
That is the single least important detail there is.
I suppose you think Debian and Ubuntu are identical in every way, or that Fedora and Mandrake and openSUSE are identical in every way, because their greatest difference is something less important than whether you type 'dpkg' or 'rpm' to query packages.
There's no noteworthy difference between dpkg and rpm. They are functionally equivalent in just about every important way. The only times the user is even made aware of the difference is when downloading packages, due to the artificial barriers to compatibility imposed by the packaging systems, forcing them to have to pick the right download link using archaic knowledge about system implementation detals. But then, you run into that same problem trying to download a random RPM because the distros add all kinds of other arbitrary and artificial compatibility barriers that serve absolutely no purpose at all but which make it so a single RPM may not even install on different releases of the exact same distribution.
Untz: Results of the App Installer meeting, and some thoughts on cross-distro collaboration Posted Jan 26, 2011 11:50 UTC (Wed) by dgm (subscriber, #49227) [Link]
Agreed. Even package availability doesn't mater much. How many Ubuntu derivatives are there? All share the exact same repositories (and thus package format), yet each has it's own personal twist.
Untz: Results of the App Installer meeting, and some thoughts on cross-distro collaboration Posted Jan 26, 2011 14:09 UTC (Wed) by Seegras (subscriber, #20463) [Link]
> There's no noteworthy difference between dpkg and rpm. They are
> functionally equivalent in just about every important way.
Nope. dpkg had dependencies on packages, whereas rpm has dependencies on libraries/programs. Thus rpm needs a database to look up which package contains a dependency, whereas dpkg does not.
Untz: Results of the App Installer meeting, and some thoughts on cross-distro collaboration Posted Jan 26, 2011 14:50 UTC (Wed) by Darkmere (subscriber, #53695) [Link]
Actually, RPM has _both_ kinds of dependencies. Both listing filenames, and package/program-names.
Untz: Results of the App Installer meeting, and some thoughts on cross-distro collaboration Posted Jan 26, 2011 10:31 UTC (Wed) by renox (subscriber, #23785) [Link]
>> package/app install/updating is critical to how a distro does everything it does. So to suggest more collaboration between distros is to, implicitly suggest collapsing distros together. <<
A baseless assertion: there is a large number of combinations of application and customisations which can be chosen by the distributions!
More simply: I don't care at all what type of package the distribution use, I do care that chromium is available and well integrated..
Untz: Results of the App Installer meeting, and some thoughts on cross-distro collaboration Posted Jan 26, 2011 12:42 UTC (Wed) by drag (subscriber, #31333) [Link]
Yes. All the same distros releases around the same time period use the same kernel versions, gcc versions, X versions... etc etc.
They have a hell of a lot in common. Much more then have in differences.
A lot of the package and software incompatibilities are just caused by relatively insignificant implementation details. Stuff like install location or how the packages are divided up into parts or the versioning scheme used.
Companies and projects that support installing software across multiple distros don't bother compiling them statically or anything weird like that. They will include some libs, but often only because they need special features or versions not typically included by the distros.
For the most part I know I can 90% of the software built for Fedora and have no issues running it on Ubuntu. The biggest barrier is the package management itself.
Untz: Results of the App Installer meeting, and some thoughts on cross-distro collaboration Posted Jan 26, 2011 19:26 UTC (Wed) by martinfick (subscriber, #4455) [Link]
> A lot of the package and software incompatibilities are just caused by relatively insignificant implementation details. Stuff like install location or how the packages are divided up into parts or the versioning scheme used.
Insignificant? But, those are exactly the most important things that make a distribution a distribution. Without policies which force unrelated software to work together on a system you are left with the nightmare that you see in windows. The whole point of a distribution is for the package maintainers to think about these things for you. They are the added value of a distribution over simply downloading and installing upstream packages.
Untz: Results of the App Installer meeting, and some thoughts on cross-distro collaboration Posted Jan 26, 2011 15:35 UTC (Wed) by xxiao (subscriber, #9631) [Link]
maybe we should unify all distros, make it a single OS, something like windows, users just switch themes to differentiate their system?
in reality, however, this is pointless and nothing new.
should Suse/Mandriva have used deb instead of rpm, maybe there is no ubuntu today...
Untz: Results of the App Installer meeting, and some thoughts on cross-distro collaboration Posted Jan 26, 2011 18:32 UTC (Wed) by vonbrand (subscriber, #4458) [Link] There are deeper differences than just RPM vs dpkg. For example, SUSE packages (while also RPM) couldn't be installed on Fedora because the division of e.g. library packages were wildly different, and the package names didn't match up (for resolving dependencies), and often the location and names of the configuration files was different. Even among Red Hat derived distributions (like Mandrake and Fedora) it wasn't easy, as they used different library versions and compiler flags. The safest bet was to get the source RPM for a foreign distribution, dissect that one to create a native binary RPM (perhaps by hacking the patches or updates from the foreign one into to native source package). The big advantage of dpkg is that all the dpkg based distributions track Debian rather closely.
Untz: Results of the App Installer meeting, and some thoughts on cross-distro collaboration Posted Jan 28, 2011 16:56 UTC (Fri) by eean (guest, #50420) [Link]
dpkg, rpm are of course different, but they aren't that different. They solve the same problem with much of the same methods. There's no reason for a dpkg-only or a rpm-only installation GUI to exist.
so... what are you even talking about?
|
|||||||||||||