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.

    • 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...

      • 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.

        • Re: (Score:3, Insightful)

          by mr_shifty (202071)

          This. ^

        • by tehcyder (746570)

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

          Then it will truly be the year of Linux on the desktop, as Windows will lose its one remaining USP. Hold on a sec...

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

        Hmmm, wouldn't it be possible to solve the duplicate binaries problem by simply reference-counting identical files?

        • 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.

        • Re:Good (Score:4, Interesting)

          by smash (1351) on Thursday May 09, 2013 @02:02AM (#43672449) Homepage Journal

          Yes. ZFS will do this, as will HAMMER. However, I suspect the gains REALLY aren't there. The core OS binaries (including all libraries) on a modern system account for what... 1-2% of the disk space? If that? The bulk of the code in your new application will be the new application. Even more disk will be consumed by the resources used only for that app (graphics, widget layouts, etc.).

          Disk today is cheap. Having dealt with both linking (Windows, Unix) and self contained Applications (OS X), I much prefer the latter. Installation / un-installation is way, way easier. Compatibility issues are less common.

      • by X0563511 (793323)

        Sounds like the dynamic linker is going to need an overhaul to include data-deduplication. As well as the filesystem.

        • No it doesn't. PC-BSD has had this model for application installs for ages. The installer hard links duplicate libraries and so on together. Hard links are already reference counted, and have been since the early days of UNIX, so you end up with one copy of each library. The logic in the installer is relatively complicated, but the uninstaller just has to delete the tree.

          The way that the packages in the repository are built ensures that programs using the same library ship the same binary. If you upgr

      • 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.
      • Re:Good (Score:5, Interesting)

        by smash (1351) on Thursday May 09, 2013 @01:58AM (#43672431) Homepage Journal

        Which, given most people have upwards of half a terabyte of storage, and the OS consumes only 1% of that, storage space is no longer at a premium.

        The benefits of totally self contained packages are huge. You'll probably find that the vast majority of your application is NOT duplicated data anyhow. It will be graphic resources, it's own code, etc.

        Couple that with de-dup in modern filesystems (inline still a major overhead, but scheduled de-dup isn't a major problem) and the advantages to just linking to libraries everywhere are not so clear cut anymore.

        Having lived with the OS X way of packaging for a few years, and dealt with both Linux, FreeBSD and Windows since the early 90s, I know which method I prefer.

    • Re:Good (Score:4, Funny)

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

      This is going to be the best thing for linux. Most users will enjoy and maybe switch to linux instead of windows. Dependecies that link multiple times to other dependancies get very convoluted. Normal peoples linux finally.

      • Except for the fact that dependencies are already handled by package managers. It can already be done and is done transparently in Ubuntu Software Center.
        • by Skrapion (955066)

          And that works reasonably well for popular open source projects, where volunteers can build new binaries to keep up with updated dependencies, but it's a real problem for closed-source projects.

          Whether or not paving the way for closed-source projects on Linux is a good thing will depend on whom you ask, but I suspect that's one of the major motivations for this project.

    • by hduff (570443)

      Good, another reason to avoid Ubuntu like the plague.

      They've already farked up "Steam for Lin^H^H^HUbuntu", so this is not surprising.

    • Flamebait??? C'mon people. Canonical seems to be hell-bent on digging their own grave.
  • apt (Score:4, Informative)

    by kthreadd (1558445) on Wednesday May 08, 2013 @05:43PM (#43669281)

    Sounds like a complement to dpkg, not a replacement

    • Re: (Score:2, Insightful)

      by phantomfive (622387)
      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: (Score:3, Funny)

        by Anonymous Coward

        Yeah, Colin Watson knows nothing about apt. Maybe he wouldn't be so lazy if he would start maintaining some packages in debian.

      • 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.

  • 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.
    • 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: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.

      • Re: (Score:2, Insightful)

        by Anonymous Coward

        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.

      • Re: (Score:3, Insightful)

        by interval1066 (668936)

        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.

        • Re:Bloat (Score:4, Interesting)

          by Kjella (173770) on Wednesday May 08, 2013 @07:44PM (#43670533) Homepage

          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.

          Fast, cheap, good - pick two? >:-) If you have a modern system, no OS should take a significant amount of resources on its own. Don't waste just to waste but as long as developer time is a limited resource, I'd rather have more features, higher quality and better performance than lower resource usage. The hardware is there to be used, that's what it's bought for. Hell, I regularly run an application that likes to chew through it's whole 32 bit memory space (4GB) and I let it because I still have 12 to spare and there's no direct replacement and it mostly works. What you care about is simply nothing that I care about at all, but then so I took your advice on my machine in favor of Windows 7. If Microsoft continues down their path I might have to migrate to Linux again, but if so I'd like a few other things than efficiency. Otherwise it might be a Mac, but I'd rather not.

        • Seriously? Look at how bloated the average "modern" base install is. Look how many background daemons there are. Efficiency went out the window along time ago. The linux of Slackware, or even Gentoo, has largely ceased to be. It has become what it once reviled.

          • by ArsonSmith (13997)

            I know, my cluster base CentOS 6.3 is nearly 800Megs. What happened to the days when I could boot/root two floppies and have a full Unix OS.

      • Quite frankly, disk space is cheap.

        Not on a 64GB tablet.

    • by iggymanz (596061)

      there are plenty of applications that must use the common config & libraries & program file of other applications, can't have separate copies or versions to have a useful coherent system.

  • 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

    • by MrEricSir (398214) on Wednesday May 08, 2013 @06:00PM (#43669475) Homepage

      Ubuntu Phone apps

      Let's be clear: Canonical's vision doesn't involve "phone apps." They want the same apps running on your phone and on your desktop.

      • by rsborg (111459)

        Ubuntu Phone apps

        Let's be clear: Canonical's vision doesn't involve "phone apps." They want the same apps running on your phone and on your desktop.

        Have they by chance been hiring Microsoft employees of late?

        And what's with this OS unification frenzy that ignores how touch and pointers behave differently. I even hate it in OSX Lion with the "natural" scroll (though OSX is much less tablet-zombified than Win8). Scroll on a touchscreen is "natural" direction as your fingers track the object 1:1 in real time (hopefully). Scroll on a perpendicular surface separated from the screen (trackpad), and sensitivity could be greater than 1:1 - it's NOT natural t

  • by Skinkie (815924) on Wednesday May 08, 2013 @05:46PM (#43669319) Homepage
    Wasn't this exactly what GoboLinux embraced?
  • The good old days (Score:4, Interesting)

    by thomasdz (178114) on Wednesday May 08, 2013 @05:48PM (#43669331)

    Remember the good old days when everything was just a single -r-xr-xr-x executable in /bin or /usr/bin

    sigh, the good old days

  • 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.

  • many packages use the programs, configs, libraries of other packages, to say nothing of application frameworks spread across multiple packages (like say openvas client, server, manager, libraries) to address cases where a server might have some local and some remote parts, or all be on one machine. this idea would make a mess of things

  • I'm guessing that they are going to statically compile everything. Otherwise they couldn't get rid of dependencies. Which is bad generally for various reasons, except in specific cases.

    Also, isn't there a variant of Linux that already does this? They also used symlinks to make a more sensible (and modern) file system, and other things. GoboLinux, I just found it. Actually, I'm not sure how similar they are...

    (Also, the first link is not needed, please don't include such rubbish.)

  • 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.

  • I think it's just a case of "because different" and "not developed here". I don't see how they could make any significant improvements over apt, but it doesn't surprise me from this group of hipsters.

    Stop pissing in the pool Ubuntu.

    • by EvanED (569694)

      I don't want to get into whether you could use DPKG packages for what they want to do; that's beyond my scope of knowledge. However, what I can tell you is that for some tasks, apt-get just flat out doesn't work.

      In particular, if you want to install programs to something other than /usr (for instance, you want to install to a network drive, or without root), then the mainstream package managers just flat out don't work.

    • Arch's pacman is has some significant improvements over apt/dpkg, especially when it comes to creating new packages. And gentoo portage/emerge has lots of useful features that don't exist in dpkg/apt either.

      Debian is solid and has an excellent package system. But it isn't the pinnacle of achievement. We can take package management further still, I am certain.

    • I think it's just a case of "because different" and "not developed here". I don't see how they could make any significant improvements over apt, but it doesn't surprise me from this group of hipsters.

      Stop pissing in the pool Ubuntu.

      It does seem a trifle odd because, to the best of my knowledge, there isn't anything preventing existing tools from working normally with .deb packages that just happen to include everything, and have no defined dependencies. There might be some modest changes needed to allow you to process packages that don't do anything requiring root privileges without being asked for them; but that hardly seems like enough to justify an entire new tool.

    • by exomondo (1725132)

      I don't see how they could make any significant improvements over apt, but it doesn't surprise me from this group of hipsters.

      Right because Colin Watson never made any improvements to apt.

      Stop pissing in the pool Ubuntu.

      What is with this attitude of 'you're not allowed to create different things and disrupt the status quo'? Who cares if the build it?

  • Goodbye Ubuntu (Score:4, Informative)

    by FuzzNugget (2840687) on Wednesday May 08, 2013 @05:54PM (#43669409)
    Hello Debian
    • Hello Debian

      Except Ubuntu users want cutting edge Debian, not tried and tested Debian...and unfortunately using Debian is not going to make it more cutting edge.

      ...Now if Debian decided to produce a (stable) cutting edge Desktop version (perhaps working with an existing Distribution team). To complete there ultra stable, you have me sold.

      • by neiras (723124) on Wednesday May 08, 2013 @07:00PM (#43670141)

        Except Ubuntu users want cutting edge Debian, not tried and tested Debian...and unfortunately using Debian is not going to make it more cutting edge.

        ...Now if Debian decided to produce a (stable) cutting edge Desktop version (perhaps working with an existing Distribution team). To complete there ultra stable, you have me sold.

        You asked for it, Debian delivers [debian.net]. The Debian CUT Project aims to publish usable snapshots of Debian Testing on a monthly basis. They're pretty new but picking up steam.

  • 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.
  • by OrangeTide (124937) on Wednesday May 08, 2013 @05:58PM (#43669457) Homepage Journal

    it seems like they suffer from Not Invented Here [wikipedia.org] but at the same time, I seem to recall that Puppy Linux already installs self-contained package bundles into individual directories. Not unlike OSX/NeXT app bundles.

    • by X0563511 (793323)

      Puppy is a specialist distribution (like Damn Small Linux). What Puppy does may not work well for a more general purpose distro.

  • This reminds me of PBI from PC-BSD. Others have pointed out the similarities with Apple / NeXT as well.

    For simple applications, it makes sense to do this. However, imagine creating a package for something large like firefox, libreoffice or kde? WIth the mass number of dependencies... it's a nightmare. Do I really need hundreds of copies of a PNG library on my system? What about zlib? gtk+ ?

  • The bugger ain't dead yet!

  • on having good stable API's of core libraries that are backwards compatible up to an extent, rather than continuously fighting dependency hell when it comes to updating packages ?
    This proposal seems basically like "we statically link every binary", and we all know that is not wanted because of disk usage and more importantly: memory usage. Especially in constrained embedded systems statically that could be a concern if you start having a lot of running applications.
  • by gringer (252588) on Wednesday May 08, 2013 @06:11PM (#43669615)

    From the email:

    The proof of concept I wrote also isn't entirely new code. It's tiny due to using .deb as a container format (minus maintainer scripts, full dependencies, etc.), so I get to save effort by using dpkg to unpack things, which leaves us room to selectively use more of its features in future if we want to.

    So they start off with what they think they need, then become more like APT as they need to add more features.

    So the scope of what I've been considering is purely leaf apps built on a fixed "base system", which in the case of the initial target of the Ubuntu phone/tablet work would be the run-time part of the Ubuntu SDK.

    In other words, this is something to be used in addition to APT (i.e. post-install), rather than instead of APT.

    * no dependencies between apps; single implicit dependency on the base
          system by way of a Click-Base-System field

    Just like Debian has an implicit dependency on the base system (except for base packages, which have more complicated rules). In other words, this system will only accept a single dependency, the Click-Base-System. I'm not quite sure why this is different from only accepting applications that only depend on Click-Base-System.

    And note that the "each package will install to its own directory" bit is on the to-do list:

    Obvious items I still need to work on:

    • produce a strawman hooks implementation with some real worked examples
    • integrate (or demonstrate how to integrate) the container isolation properties worked on elsewhere
    • Click-Base-System field is skeletally simple right now, and may need to be expanded to at least leave open the possibility of multiple flavours of base system (see also GNOME's profiles idea)
    • adjust unpack handling to avoid problems with project renames and name clashes, and to unpack each version into its own directory and flip symlinks to allow for multi-user independence
    • integrate into the Ubuntu SDK, as well as providing examples of how it can be integrated into other build systems too
  • puttting each program in its own directory is an absurdly bad idea. Then you would end up with a massive PATH variable and also does not follow the time honored Unix tradition which needs to be respected. For allowing multiple versions of the same program I would prefer to see some other solution, one possibility might involve putting symlinks in /usr/bin to program files into another directory where different versions of the program can be stored. the different versions of the program could be accessed in

  • by robmv (855035)

    I am not well versed in the dpkg format, but RPM has Relocatable Packages [rpm5.org], not many people use it, but if you want to do something like Ubuntu wants on an RPM based distribution without creating another format, You hack rpm commands so it can check a per user packages database using relocatable packages, no need of a new format

  • so every time I install something which is bundled with (say) java, I'll get java every time? How many copies of java with inconsistent and possibly incompatible behaviour does a person need?
    example, say I have an app which comes bundled with "helper-program" version 1.0, which keeps its config files in ~/.helperprogram/config
    and then I have another app which comes bundled with "helper-program" version 1.1 which keeps its config files in ~/.helperprogram/config
    wtf??? am I missing something here?
  • I've definitely not been a fan of their track record these past few years, but they do occasionally hit on some really good ideas (if somehow managing to screw up their implementations: Upstart was a good in principle, and so was making a verical launcher/taskbar instead of making our widescreens even shorter.) This is another one. Well, sort of. Maybe not 'no dependencies' but at least 'no dependency conflicts, ever.' It's two thousand thirteen, why are we still tolerating this shit? There's absolutely no reason why the package manager can't chroot/symlink the little fuckers and make them see what they need to see so they can coexist with any other package. If the package manager is informed enough to recognize a conflict, it's also smart enough to resolve it without the user doing anything beyond confirming the installation of the extra required dependencies, and yet for some reason none of the current crop of package mangers do this.

    I'd rather have a bad solution from Ubuntu inspiring people to do it the right way (see: Mir lighting a fire under GNOME's ass to help out with Wayland) than have no solution at all.

Their idea of an offer you can't refuse is an offer... and you'd better not refuse.

Working...