Forgot your password?
typodupeerror
Ubuntu Software Linux

Ubuntu Developing Its Own Package Format, Installer 466

Posted by Soulskill
from the anything-they-can-do-we-can-do-better dept.
An anonymous reader writes "While complementing Debian APT/DPKG, Canonical is now developing their own package format. The new package format has promised highlights of having no dependencies between applications, each package would install to its own directory, root support wouldn't always be required, and overall a more self-contained and easier approach for developers than it stands now for Debian/Ubuntu packages. The primary users of the new packaging system would be those distributing applications built on the Ubuntu Touch/Phone SDK. The initial proof-of-concept package management system is written in Python and uses JSON representation." This quote from the post by Canonical's Colin Watson bears repeating: "We'll continue to use dpkg and apt for building the Ubuntu operating system, syncing with Debian, and so on."
This discussion has been archived. No new comments can be posted.

Ubuntu Developing Its Own Package Format, Installer

Comments Filter:
  • Good (Score:4, Insightful)

    by MightyMartian (840721) on Wednesday May 08, 2013 @05:42PM (#43669275) Journal

    Good, another reason to avoid Ubuntu like the plague.

  • Bloat (Score:4, Insightful)

    by paulej72 (1177113) on Wednesday May 08, 2013 @05:43PM (#43669287)
    If everything has no dependencies, then all of the dependencies must be included in the install. I wounder how many copies of each low level program would be on a given machine.
  • by Anonymous Coward on Wednesday May 08, 2013 @05:43PM (#43669293)

    A better headline:

    Ubuntu Phone apps will use a different package format than debian/dpkg/apt

    I guess that's not really as exciting though

  • Re:Good (Score:5, Insightful)

    by Penguinisto (415985) on Wednesday May 08, 2013 @05:45PM (#43669313) Journal

    Indeed... this sentence:

    The new package format has promised highlights of having no dependencies between applications

    ...tells me there's gonna be a whole shitload of bloat, duplicate binaries, and a performance hit from Hell.

    I could be wrong, but...

  • More Flexibility? (Score:5, Insightful)

    by organgtool (966989) on Wednesday May 08, 2013 @05:48PM (#43669343)

    each package would install to its own directory

    Would it allow users to install multiple versions of the same application from packages? One of my gripes with Linux is that it's not easy to test new or beta versions of software since there is no easy way to install from packages alongside the existing (stable) version. Yes, I know that I could build the app from source, but that can be quite a hassle sometimes.

  • Re:Bloat (Score:5, Insightful)

    by fph il quozientatore (971015) on Wednesday May 08, 2013 @05:49PM (#43669353) Homepage

    If everything has no dependencies, then all of the dependencies must be included in the install. I wounder how many copies of each low level program would be on a given machine.

    And, especially, good luck installing a security update on *all* your copies of a core library.

  • Re:Good (Score:3, Insightful)

    by Penguinisto (415985) on Wednesday May 08, 2013 @05:49PM (#43669355) Journal

    The presence and use of /Library on my MBP says differently. ;)

  • by sidragon.net (1238654) on Wednesday May 08, 2013 @05:51PM (#43669379)

    http://en.wikipedia.org/wiki/Application_bundle [wikipedia.org]

    Once again, racing as fast as we can towards where the puck was 20 years ago.

  • Re:Bloat (Score:4, Insightful)

    by Anonymous Coward on Wednesday May 08, 2013 @05:52PM (#43669381)

    Quite frankly, disk space is cheap. If this eats another 10 gigabytes of hard drive space over the traditional approach, I personally wouldn't even notice. If it made things even 50% less likely to break because of dependency problems I would be all for it.

  • by jandrese (485) <kensama@vt.edu> on Wednesday May 08, 2013 @05:56PM (#43669423) Homepage Journal
    I don't think we're going to see a completely separate install of Gnome for every single Gnome app on your system. I think this is intended for standalone apps like you see on phones and tablets.
  • Re:Good (Score:5, Insightful)

    by buchner.johannes (1139593) on Wednesday May 08, 2013 @05:58PM (#43669449) Homepage Journal

    Also, this might be the dawn of malware for Linux on the PC.

  • by Anonymous Coward on Wednesday May 08, 2013 @06:05PM (#43669551)

    Which is actually even worse, because it has to exist alongside dpkg/apt. Still re-building the wheel and adding useless bloat, no matter how you look at it.

  • Re:Bloat (Score:2, Insightful)

    by Anonymous Coward on Wednesday May 08, 2013 @06:07PM (#43669577)

    If it made things even 50% less likely to break because of dependency problems I would be all for it.

    What if it makes things more likely to break because package A and package B are using incompatible versions of a library? What if you get compromised because a package uses an old version of a library with a zero-day exploit? Even though you already updated the same library for other applications.

  • by X0563511 (793323) on Wednesday May 08, 2013 @06:20PM (#43669723) Homepage Journal

    Sure, if you call 'ldconfig' "a half dozen different methods"

  • Re:apt (Score:2, Insightful)

    by phantomfive (622387) on Wednesday May 08, 2013 @06:21PM (#43669735) Journal
    Designing the capability to bundle libraries with an application install is a good idea, the problem is.....

    Ubuntu is building their own system for doing it, instead of using APT, which gets them 90% of the way there. Most likely, it will be poorly done, which is the common fate of those who are too lazy to understand existing systems.
  • Re:Bloat (Score:3, Insightful)

    by interval1066 (668936) on Wednesday May 08, 2013 @06:22PM (#43669739) Homepage Journal

    Quite frankly, disk space is cheap. If this eats another 10 gigabytes of hard drive space over the traditional approach, I personally wouldn't even notice.

    Might as well use Windows with that philosophy. The big difference with Linux is its efficiency. Get rid of that, might as well get rid of linux.

  • by phantomfive (622387) on Wednesday May 08, 2013 @06:26PM (#43669791) Journal
    Talk about simplicity. Here is an example 'Makefile' [tuhs.org] from Unix 6. Compare it to today's auto-tools:

    chdir lib
    cc -c -O *.c
    ar r /lib/liby.a *.o
    rm *.o
    chdir ../source
    cc -s -O y?.c
    cmp a.out /usr/bin/yacc
    cp a.out /usr/bin/yacc
    rm a.out *.o
  • by cas2000 (148703) on Wednesday May 08, 2013 @06:56PM (#43670113)

    actually, it's something that Windows gets dead-wrong, because executable installer apps (setup.exe and the like) are just plain fucking stupid.

    they're an unfortunate necessity because windows doesn't have, and never has had a decent package management system. and is unlikely to ever get one because the windows software market is primarily commercial and proprietary.

    when you have 10 (or 100 or 500) packages to upgrade on a single system (and then multiply that by 100 or 1000 systems), executing hundreds of installer packages one after another is the worst possible way to do it.

    i've never understood why Windows (or Apple) users tolerate that shit. it's a tedious chore that's ripe for automation - exactly the kind of thing that computers are good at doing and users are bad at doing (due to boredom, fatigue, loss of attention, ignorance, or stupidity)

    which is precisely why linux distros (and other *nixes) don't do it that way. they have packaging systems because systems are consistent, predictable, and easily automated.

    windows users and windows developers often have just the wrong way of looking at things, the wrong mental model of how things work and how they should work.

    I ran across a program for Windows recently called Ninite. It's a multi-app installer and updater. it sounds like a good idea and is. it's a big improvement over the usual click-and-execute for each individual program.

    except the way it works is weird and clumsy:

    you go to their website and select which apps you want to install (from a bunch of internet-available apps, including free software and proprietary freeware like adobe flash), and then it builds you an installer app that you download and run, and it installs and/or upgrades the apps you selected off their website.

    WTF?

    nice starting idea, but the implementation is idiotic. Why not just have one Ninite app that fetches a list of available apps and installer URLs and whatever custom installer scripts ninite needs for them) and allow the user to select which apps whenever they run it?

    i.e. instead of a moronic implementation, actually make a smart and useful implementation that copies good ideas from linux distro installers like apt-get and yum, and re-purposes them for the Windows environment.

    (oh, and adobe are sending cease-and-desist letters and threatening to sue if the ninite developer doesn't remove the ability to install & update downloadable adobe products like flash, so his good ideas and good intentions are fucked by the corporate vermin mindset that dominates the windows software market)

    another thing windows devs don't get is shared libraries (DLLs in windows terminology). Why does every single app have to install their own copy of the MS C++ libraries? or .net? or nvidia physx? and numerous other common library packages? these things are supposed to be shared resources provided and kept up-to-date by the operating system, not bundled with every app that uses them.

  • by characterZer0 (138196) on Wednesday May 08, 2013 @07:19PM (#43670329)

    You're just angry that I'm pointing out that linux lacks a central repository for application and kernel settings and you have to dig through /etc 's mass of files to do the same thing. Linux is still rocking the equivalent of ".ini" files, and yeah -- it is primitive. And I'm not a moron for bringing it up, you're a moron for not seeing that sometimes, your religion of choice, could benefit from looking outside of itself and seeing that other developers have done something better.

    Text files for configuration are great. I can version control them, copy them from one system to another, see meaningful diffs between them, and invidual applications can choose formats that are sensible for them.

    Why on earth would I want to cram everything into a central repository?

  • Nope.. (Score:5, Insightful)

    by Junta (36770) on Wednesday May 08, 2013 @07:27PM (#43670395)

    *If* everyone picked exactly the same lib version, yes.

    In practice, people aren't going to standardize on the same library version.

    Bonus problem: Now each app provider is responsible for addressing a hypothetical libcrytpo vulnerability rather than the distro patching it in one place.

  • by girlintraining (1395911) on Wednesday May 08, 2013 @07:54PM (#43670629)

    That's not an unmitigated good however, especially if you want to make edits but not commit them until you're done. Unix gets it mostly right in that I can send a NOHUP to tell the other process to reload.

    Look, all I'm saying is that as far as ease of use, Linux fails here. I'm not saying linux can't perform well, or that it doesn't get the job done, etc., etc. What I am saying is that it's way of organizing configuration options is about thirty years old. Newer things have come along since, with clear advantages. Do they have disadvantages of their own? Of course.

    But linux would benefit enormously from advancing to at least a central repository for application and operating system settings. If it's feeling particularly daring, it could even look at what Microsoft has done with .net assemblies and COM architecture. But, you know, baby steps...

  • Re:apt (Score:5, Insightful)

    by exomondo (1725132) on Wednesday May 08, 2013 @07:59PM (#43670663)

    Ubuntu is building their own system for doing it, instead of using APT, which gets them 90% of the way there. Most likely, it will be poorly done, which is the common fate of those who are too lazy to understand existing systems.

    So you're saying Colin Watson is too lazy to understand existing systems? You've never actually looked at commits for APT have you.

  • by Anonymous Coward on Wednesday May 08, 2013 @08:01PM (#43670687)

    Anyone on this site who is stumped by grep missing need leave. Now.

  • Re:Good (Score:3, Insightful)

    by mr_shifty (202071) on Wednesday May 08, 2013 @08:05PM (#43670725) Homepage

    This. ^

  • by Anonymous Coward on Wednesday May 08, 2013 @08:06PM (#43670727)

    /etc is the registry, and it is no more or less centralized than the Windows registry (which consists of multiple files).

    The difference is that /etc is implemented using two of the most mature and well understood pieces of the system: a file system directory hierarchy and text files.

    The windows registry, in contrast, is implemented using a limited and clunky database, which is difficult to manage and drives even experienced users to frustration.

    And speaking of "rich access control". /etc has extremely robust access control via the filesystem. Access control that is well tested, well documented and well understood.

  • Re:Good (Score:4, Insightful)

    by rroman (2627559) on Wednesday May 08, 2013 @09:54PM (#43671385)
    Actually, the "shitload of bloat duplicate binaries" is quite good. Nobody gives a damn about 10 MB of their disk space because the program takes it's libraries with it. However, everyone gives ten tones of damn when they can't install new application because of "dependency problem". Solving dependency problems costs time and hence money. Disk space is cheap.
    Disclaimer: I'm not saying, that new Ubuntu does that, I'm just arguing against the philosophy of bad duplicate binaries.
  • by MavEtJu (241979) <slashdotNO@SPAMmavetju.org> on Wednesday May 08, 2013 @10:43PM (#43671605) Homepage

    Call me old-fashioned, but I prefer a proper Makefile which only compiles the files required and which separates between the build and install phase.

FORTRAN is a good example of a language which is easier to parse using ad hoc techniques. -- D. Gries [What's good about it? Ed.]

Working...