Beta

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Ubuntu Developing Its Own Package Format, Installer

Soulskill posted about a year ago | from the anything-they-can-do-we-can-do-better dept.

Ubuntu 466

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

cancel ×

466 comments

Sorry! There are no comments related to the filter you selected.

Good (4, Insightful)

MightyMartian (840721) | about a year ago | (#43669275)

Good, another reason to avoid Ubuntu like the plague.

Re:Good (4, Insightful)

Penguinisto (415985) | about a year ago | (#43669313)

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 (1)

Jeremiah Cornelius (137) | about a year ago | (#43669325)

Apple. NeXT.

Re:Good (2, Insightful)

Penguinisto (415985) | about a year ago | (#43669355)

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

Re:Good (5, Informative)

Jeremiah Cornelius (137) | about a year ago | (#43669635)

Go open a mac .app sometime. Libraries and resources galore can be found. The Systme libraries and frameworks can be over-ridden. like having ~/Library on a per-app basis.

Re:Good (1)

phantomfive (622387) | about a year ago | (#43669703)

The Systme libraries and frameworks can be over-ridden.

Really? How does that work? I would love to know.

Re:Good (5, Informative)

Jeremiah Cornelius (137) | about a year ago | (#43669919)

"Dunno if there's a way to specify that inside Xcode or not, but for our app we use a build script that includes some code like the following. The code uses Apple's install_name_tool utility to modify the application so that instead of pointing to /usr/lib/libsndfile.so, it points to a libsndfile.so path that is in the application's package instead.

Note this is just a cut-down script excerpt to give you an idea; it will probably require some tweaking before it works for you (and of course you'll need to modify it to operate on other libraries besides libsndfile if that is what you want):"

#!/bin/bash -e
 
BINARY="MyAppFolder/MyAppName"
FRAMEW_FOLDER="MyAppFolder/MyAppName/Contents/Frameworks/"
 
function DoInstallNameTool {
    xLIB="$1"
    xLIB_NAME="$2"
    xBINARY="$3"
    echo install_name_tool -change \"${xLIB}\" \"@executable_path/../Frameworks/${xLIB_NAME}\" \"${xBINARY}\"
    install_name_tool -change ${xLIB} "@executable_path/../Frameworks/${xLIB_NAME}" "${xBINARY}"
}
 
for LIB in $(otool -L "${BINARY}"|grep libsndfile|cut -d '(' -f -1)
do
    echo "Handling Lib: $LIB"
    LIB_NAME=$(basename "$LIB")
    echo " Adding ${LIB_NAME}"
    cp -Rf "${LIBSNDFILE_DIR}/src/.libs/${LIB_NAME}" "${FRAMEW_FOLDER}"
 
    DoInstallNameTool "$LIB" "$LIB_NAME" "$BINARY"
done

http://stackoverflow.com/questions/7470637/dynamic-library-in-application-bundle-mac-os-x [stackoverflow.com]

Re:Good (0)

Anonymous Coward | about a year ago | (#43669657)

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

I could be wrong, but...

Apple. NeXT.

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

Well, interesting that you have experience with OS X, because if you unrolled the third-party contents under your /Library to each app under /Applications that needed it, and compare your OS X experience to the potentially "massive" library of 3rd party Linux software...
did you HONESTLY think you stood a chance of being right?

By all means show us an example from /Library/ if you have one, and I'm going to laugh if you say the JRE.

Re:Good (1)

gandhi_2 (1108023) | about a year ago | (#43669327)

Oooh!
  A Modularity vs DRY argument!

Lets..... GetItOn!

Re:Good (5, Insightful)

buchner.johannes (1139593) | about a year ago | (#43669449)

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

Re:Good (2)

K. S. Kyosuke (729550) | about a year ago | (#43669665)

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

Re:Good (1)

Anonymous Coward | about a year ago | (#43669837)

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

There is a story related to this, it goes:

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

Re:Good (2)

X0563511 (793323) | about a year ago | (#43669709)

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

Re:Good (1)

pentalive (449155) | about a year ago | (#43669913)

http://www.gobolinux.org/ [gobolinux.org]

Re:Good (0)

Anonymous Coward | about a year ago | (#43670085)

Glad I wasn't the only one who thought "sounds like Gobo Linux" upon reading the snippet

Re:Good (4, Funny)

Anonymous Coward | about a year ago | (#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.

Re:Good (1)

hduff (570443) | about a year ago | (#43669685)

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.

apt (3, Informative)

kthreadd (1558445) | about a year ago | (#43669281)

Sounds like a complement to dpkg, not a replacement

Re:apt (1)

Anonymous Coward | about a year ago | (#43669351)

Sounds like a complement to dpkg, not a replacement

Oh, I hope so. I like Ubuntu - even Unity - but I won't tolerate them going all Apple on me.

Because if in the future I am stuck with either Canonical's depositories (half of my software is from other sources) or compiling everything from source - all those dependencies and everything - bye buy Ubuntu.

Re:apt (2, Insightful)

phantomfive (622387) | about a year ago | (#43669735)

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.

Bloat (4, Insightful)

paulej72 (1177113) | about a year ago | (#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 (4, Insightful)

fph il quozientatore (971015) | about a year ago | (#43669353)

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 (0)

Anonymous Coward | about a year ago | (#43669701)

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.

Isn't the main purpose of the packaging/installation system to track all libraries and executables, no matter how many copies you have?

Re:Bloat (1)

jedidiah (1196) | about a year ago | (#43669853)

With n+1 copies of something you have n+1 entities that need to update their shared components. Most of them might not bother. If they don't bother, then you don't have anything to update.

Re:Bloat (0)

Anonymous Coward | about a year ago | (#43669895)

Especially when the security update breaks the API because there's no other way to fix it...

Re:Bloat (4, Insightful)

Anonymous Coward | about a year ago | (#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:Bloat (2, Insightful)

Anonymous Coward | about a year ago | (#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.

Re:Bloat (0)

Anonymous Coward | about a year ago | (#43669597)

I'm sure you'll also appreciate your computer using an additional 10GB for all of the now duplicate shared objects that need to get loaded into RAM as well...

Re:Bloat (2, Insightful)

interval1066 (668936) | about a year ago | (#43669739)

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 (1)

Anonymous Coward | about a year ago | (#43669941)

What about all the waste and mistakes being caused by duplication of efforts and storage?
Not managing dependency problems means capitulation on OS management.
Now, this might be good for the intended use, for simple management of applications, but essentially you give up on all the benefits of managing your libraries and applications in the first place. If everyone thinks like that, the whole value proposition of dealing with an OS diminishes exponentially.

Seems kinda silly to spend 20+ years developing OSes and then just give up on it and go back to the "simple" solutions, which history shows does not work very well at all for many various reasons. Anyways, good luck with that. I'm glad I don't have to share the pain.

Re:Bloat (1)

iggymanz (596061) | about a year ago | (#43669405)

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.

Why stop there? (0)

Anonymous Coward | about a year ago | (#43669289)

They should do it all on their own. No more leaching off Debian.

troll bait headline (5, Insightful)

Anonymous Coward | about a year ago | (#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:troll bait headline (4, Interesting)

MrEricSir (398214) | about a year ago | (#43669475)

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.

Re:troll bait headline (0)

Anonymous Coward | about a year ago | (#43669505)

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.

Ah, yes, the Microsoft theory! Man, that must be good, given how rich Microsoft is! Say, how is that strategy working for them?

GoboLinux? (2)

Skinkie (815924) | about a year ago | (#43669319)

Wasn't this exactly what GoboLinux embraced?

Re:GoboLinux? (1)

oodaloop (1229816) | about a year ago | (#43670071)

No, it was his Uncle Travelling Matt.

The good old days (3, Interesting)

thomasdz (178114) | about a year ago | (#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

Re:The good old days (3, Insightful)

phantomfive (622387) | about a year ago | (#43669791)

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

Re:The good old days (2)

Anonymous Coward | about a year ago | (#43670037)

You didn't build emacs back in the bad old days, did you?

Re:The good old days (2)

oodaloop (1229816) | about a year ago | (#43670081)

Oh, I'm terribly sorry. I didn't realize I was standing on your lawn. I'll remove myself forthwith.

More Flexibility? (5, Insightful)

organgtool (966989) | about a year ago | (#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:More Flexibility? (0, Flamebait)

girlintraining (1395911) | about a year ago | (#43669473)

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.

That's because Linux suffers from a similar problem that Windows 95/98, and XP to a lesser extent did: DLL hell. The average linux installation has thousands of libraries. And they're all referenced and indexed using a half dozen different methods from files in /etc to compile-time kernel flags, etc.

Microsoft solved this (partially) using a centralized registry and integrated it into the operating system. They've tried to add integrity-checking and what-not so that critical DLLs can be reverted in place... a primitive version-control system you can access by running "sfc /scannow" at the command prompt.

Linux doesn't even have that much. It's a crap shoot as to which library version your executable will load. That's why adding 'beta' versions to the mix isn't easy: You could blow up your entire installation, so usually, beta releases are 'static' linked. I don't know why the kernel devs haven't addressed this problem.

Re:More Flexibility? (2, Insightful)

X0563511 (793323) | about a year ago | (#43669723)

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

Re:More Flexibility? (1)

girlintraining (1395911) | about a year ago | (#43669995)

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

Does ldconfig allow for different versions of the same library to be requested by the application? Does ldconfig warn you when a dependancy isn't met? Does it allow per-application flags to override global settings?

Nope.

Re:More Flexibility? (1)

Anonymous Coward | about a year ago | (#43669821)

Microsoft solved this (partially) using a centralized registry and integrated it into the operating system. They've tried to add integrity-checking and what-not so that critical DLLs can be reverted in place... a primitive version-control system you can access by running "sfc /scannow" at the command prompt....Linux doesn't even have that much

Thank God, that's definitely NOT the right solution.

Re:More Flexibility? (5, Informative)

interval1066 (668936) | about a year ago | (#43669861)

Microsoft solved this (partially) using a centralized registry...

Um, the MS registry is a huge pain in the butt for developers and M$ knows it, but they can't get rid of it becuase its too ingrained. Getting rid of the registry was a huge selling point for Windows 8, as it was for Vista... and so on. I dare you to ask me why... if you don't realize its a huge honey pot for virii and hackers you have no business even asking. Linux DOES INDEED have a system for library control, its called pkg_config and it works very well. Its not my problem if developers are too lazy to use it. 90% of linux apps I've ever envountered use it, so don't come whining to me there's no soluton this lib hell of which you speak. I do quite well with Linux, thank you.

Re:More Flexibility? (4, Informative)

jedidiah (1196) | about a year ago | (#43669923)

> That's because Linux suffers from a similar problem that Windows 95/98, and XP to a lesser extent did: DLL hell.

"DLL hell" has squat to do with it. The package manager is going to want to replace one version of an app with another. That is the only real problem here. If you ignore the package manager, you can install what you want.

Linux has had versioned shared libraries for ever.

The registry is just crap and you're a moron for even bringing it up in this context.

Re:More Flexibility? (0)

Anonymous Coward | about a year ago | (#43669535)

another broken feature (1)

Anonymous Coward | about a year ago | (#43669345)

Ubuntu is dead.

Augment audio support which worked with Pulse which doesn't work.
Replace X which worked with Wayland/Whatever, which has fewer features and doesn't work as well.
Replace gnome with Unity which runs slower and lets you do less and is unusable on many setups.
Now, replacing a package manager which is common, well-supported, and works with one which will be none of those things.

Explain to me why anyone uses Ubuntu any more..... Oh yeah - it's because of marketing and ignorance and nerd-wannabees. In-the-know nerds have abandoned it years ago for OS's which actually make life easier - something which Ubuntu was intended to do, but not fails miserably at.

Stop re-building the wheel, please!

Re:another broken feature (1)

NGRhodes (2742089) | about a year ago | (#43669471)

Please re-read the original post, they are not replacing dpkg/apt.

Re:another broken feature (2, Insightful)

Anonymous Coward | about a year ago | (#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.

Would make sense if... (0)

Anonymous Coward | about a year ago | (#43669347)

They are planning statically linked applications. Of course they might want to build their own DLL hell in which case they are on the right track using shared libraries...

duplicated programs & libraries & configs (1)

iggymanz (596061) | about a year ago | (#43669349)

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

but... WHY? (0)

girlintraining (1395911) | about a year ago | (#43669361)

Why do we need yet another packaging standard? Isn't the whole point of open source to take good ideas and merge them together? So why then, do we see divergence like this so much more than convergence? Sigh. I suspect the reasons for this are political rather than technical; The main failing of open source as a community is that while the source is open, the politics are messy and it results in dozens of incompatible "open" standards, protocols, etc. We bitch and moan about closed source protocols and having to reverse-engineer everything, which is a massive waste of effort because we're duplicating previous work... and then we're busy doing it to ourselves. :(

Re:but... WHY? (1)

Picass0 (147474) | about a year ago | (#43669497)

>> "Isn't the whole point of open source to take good ideas and merge them together?"

No, it's not. Open source is so you or anyone else may use the code as a starting point for your own changes, to learn from, study, improve, etc...

Re:but... WHY? (5, Informative)

amorsen (7485) | about a year ago | (#43669573)

We need it because while current packaging systems are great for central control, they are bad for actually letting users contribute.

a) You cannot submit a bug to a developer, get a fixed beta release, and install that in the packaging system (unless you know how to handle spec files)
b) You cannot do parallel installations of newer (or older) versions for testing unless the package is built specifically for that
c) It is difficult to make distribution-independent packages, so users become dependent on the distribution for all software
d) Almost all packages require root, the packaging system cannot track software installed by users themselves

On the other hand, switching to a Mac-style packaging system has at least these problems:

1) Security updates to common code are unlikely to actually get applied to all packages
2) Some libraries will not be shared, costing extra memory and cache footprint
3) Centralized control over what software is installed suddenly becomes difficult
4) Without dependencies you need to define the minimal environment that software can depend on. LSB tried to do that and failed.

Re:but... WHY? (2)

EvanED (569694) | about a year ago | (#43669759)

We need it because while current packaging systems are great for central control, they are bad for actually letting users contribute.

One more:
e) Most current packaging systems don't let you pick an installation directory. (Many programs have directories set in stone when you compile them.)

This is one that has affected me, because in the environment I work in, we have standard stuff installed locally but a lot of more esoteric software as well as more current versions of software installed to network drives. (For instance, we run RHEL6 which comes packaged with Python 2.6, but I almost always use Python 2.7 off of the network. Or we have Clementine available for use only over the network.) But the way existing package managers work means that we can't really use them, which means that if I want to make something new available over the network, I have to go and chase down its dependencies myself and then compile everything.

3) Centralized control over what software is installed suddenly becomes difficult

I would argue that point for the most part. From some vantage point, it's already difficult to have centralized control over what's installed. After all, I can still do what I described above to install software, without the support of the package manager. It's just a pain. Or even if you switch to a better package manager that allows users to have control over what gets installed, you can still block that as an administrator by setting noexec on the drives.

Re:but... WHY? (1)

hawguy (1600213) | about a year ago | (#43669601)

Isn't the whole point of open source to take good ideas and merge them together?

What gave you that idea? There are many Linux window managers [techradar.com] , Word Processors [wikipedia.org] , Image Editors [about.com] , etc. That diversity is both a strength and a weakness.

Re:but... WHY? (1)

Anonymous Coward | about a year ago | (#43669645)

Because that is the way many improvements are made: by trying something new. By basically trying to reinvent the wheel.
As long as canonical does not enforce usage of the new system (because new = better), I'm fine with all of this: let them try out something.
And then when it's released, we can judge if it is indeed something useful and/or better...or not... not harm done in trying.

So, staticly compiled? (1)

magic maverick (2615475) | about a year ago | (#43669363)

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

let's see... (1)

Anonymous Coward | about a year ago | (#43669371)

I dont think this is so bad. One cause of Windows' (tm) success is for sure that developers and users dont have to think about broken library dependencies after an update. For commercial (proprietary) software such packaging system could finally start the year of the linux desktop (y).

Re:let's see... (1)

armanox (826486) | about a year ago | (#43669455)

Except commercial software has been able to do this for years. I've used quite a few static linked applications, that usually are packaged as .bin or .run (some have even been .rpm).

Re:let's see... (1)

X0563511 (793323) | about a year ago | (#43669777)

You can blame that on c:\windows\winsxs and the 15gb it wastes in the process.

(go have a look - it's normally hidden)

Also known as application bundles. (3, Insightful)

sidragon.net (1238654) | about a year ago | (#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:Also known as application bundles. (0)

Anonymous Coward | about a year ago | (#43669451)

Everything goes in cycles....

Because Apt-get is soooooo inferior. (2, Interesting)

JeremyMorgan (1428075) | about a year ago | (#43669403)

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.

Re:Because Apt-get is soooooo inferior. (2)

EvanED (569694) | about a year ago | (#43669459)

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.

but is apt/dpkg perfect? (2)

OrangeTide (124937) | about a year ago | (#43669499)

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.

Re:Because Apt-get is soooooo inferior. (1)

fuzzyfuzzyfungus (1223518) | about a year ago | (#43669757)

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.

Goodbye Ubuntu (3, Informative)

FuzzNugget (2840687) | about a year ago | (#43669409)

Hello Debian

Re:Goodbye Ubuntu (1)

SeanBlader (1354199) | about a year ago | (#43669517)

Going to have to agree with FuzzNugget here. Seems like a good time to finally bite the bullet and move myself upstream.

Cutting Edge Debian (2)

tuppe666 (904118) | about a year ago | (#43669845)

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.

I think this is for "apps" not applications (3, Insightful)

jandrese (485) | about a year ago | (#43669423)

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:I think this is for "apps" not applications (1)

MoxFulder (159829) | about a year ago | (#43669915)

What does "standalone" even mean? The Wikipedia app on my Android phone uses some HTML5-to-app Javascript framework, the mobile banking apps use some other HTML5-to-app framework(s), the Wifi network debugger app uses some Busybox tools and would probably have been a lot simpler to write if it could rely on standard Linux wireless-tools, etc.

When I look on the Android market and I see 20 apps that do roughly the same thing, but 18 of them do it badly, and they all duplicate the basic functionality of a standard open-source utility... I weep with despair. :-p

NIH sydrome but already been done (2)

OrangeTide (124937) | about a year ago | (#43669457)

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.

Re:NIH sydrome but already been done (1)

X0563511 (793323) | about a year ago | (#43669789)

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

It wasn't clear in your comment... (1)

OrangeTide (124937) | about a year ago | (#43669957)

So are you saying that Ubuntu should or should not follow in Puppy's footsteps?

We need another standard..? (1)

kagaku (774787) | about a year ago | (#43669477)

Obligatory: http://xkcd.com/927/ [xkcd.com]

Re:We need another standard..? (1)

johnsnails (1715452) | about a year ago | (#43669559)

Beaten 2 it

Been done many times (1)

laffer1 (701823) | about a year ago | (#43669493)

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+ ?

I never got "packaging systems" (-1)

Anonymous Coward | about a year ago | (#43669521)

IMHO, this is something Windows gets right. It's a fucking executable dammit. Yeah, it calls some APIs that are needed for installing. Installation library, sure; but "packaging system"??? Package format? Sooner or later you'd think that Linux people would just wake up and realize it's an executable.

Re:I never got "packaging systems" (1)

X0563511 (793323) | about a year ago | (#43669793)

No, it's not just an executable. Go look in c:\windows\system32 and c:\windows\winsxs (and in c:\Program Files\Common Files) and you'll find more DLLs than you can shake a stick at.

Re:I never got "packaging systems" (0)

Anonymous Coward | about a year ago | (#43669931)

Yeah sure, but the *installer* is just an executable. That's what I'm talking about. All you need are APIs that tell you what dynamic libraries are installed, what versions they are, and what (if any) applications are currently using them. The installer doesn't need to be in a "packaging format", it's just executable code, that's what I'm talking about. APIs that tell you what the installer needs to know ought to have been settled a long, long time ago. Then you could make the installer anything you want. On Windows that's EXE, but there's nothing to stop it from being a batch file, Perl script, Pythoh, whatever, and it gets along fine with all the other installations as long as it makes the correct API calls.

Re:I never got "packaging systems" (1)

fuzzyfuzzyfungus (1223518) | about a year ago | (#43669933)

IMHO, this is something Windows gets right. It's a fucking executable dammit. Yeah, it calls some APIs that are needed for installing. Installation library, sure; but "packaging system"??? Package format? Sooner or later you'd think that Linux people would just wake up and realize it's an executable.

You'd better go tell Microsoft about that, they've apparently been running headlong away from 'getting it right' since 1999... While it doesn't have the concept of 'repositories' in the same sense that Linux package managers generally do, the Windows Installer Service [microsoft.com] and the .msi, .msp, and .mst files that it works with are easily as or more complex as anything on the Linux side(and that's in addition to the distinct Windows Update mechanism, which interacts either with Microsoft, with a WSUS server, or with .msu files, exactly what circumstances require this rather than WIS are not 100% clear to me).

Yes, Windows doesn't forbid much simpler mechanisms like the nullsoft installer or 'just click foo.exe'; but neither does linux. Plenty of non-packaged software comes as an 'install.sh' or just an executable binary you copy somewhere.

Shoot it again! (1)

Chris Mattern (191822) | about a year ago | (#43669537)

The bugger ain't dead yet!

Finally!!! (-1)

Anonymous Coward | about a year ago | (#43669591)

Finally, the last piece of the puzzle is about to fall into place, allowing the inevitable takeover of the mainstream desktop by Linux to proceed!

Seriously??? Does no one here even begin to realize this is an example of why Linux is a toy OS on the desktop for uberusers? Linux developers spend way, WAY too much time reinventing BS like this instead of, oh, I don't know, eradicating every last requirement for a user to type in a command or (here's a radical thought) developing a leading edge file manager. I've used Linux off and on for almost 20 years, and it blows my mind how even the wretched Explorer in Windows is light years more capable than anything I've seen on Linux. When you look at the third-party FM's available for Windows, the situation is even worse.

Watching Linux try to advance on the desktop is like watching the NHL try to become more than a distant 4th place in the "big four" sports in the US. Self-indulgent, old-school thinking, a refusal to do what's needed, and constant self-delusion. It's pathetic.

The NHL is better then the 2 shit baseball teams i (1)

Joe_Dragon (2206452) | about a year ago | (#43669695)

The NHL is better then the 2 shit baseball teams in my home town.

Why not concentrate (1)

thrill12 (711899) | about a year ago | (#43669611)

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.

A crippled version of APT (3, Interesting)

gringer (252588) | about a year ago | (#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

Bad idea. (1)

Eravnrekaree (467752) | about a year ago | (#43669627)

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 the seperate directory holding multiple versions and the symlink from /usr/bin would point to the default version.

Re:Bad idea. (1)

EvanED (569694) | about a year ago | (#43669909)

Then you would end up with a massive PATH variable...

First: that's only one solution. For example, I have (issues file system query) probably three or four thousand different packages available to me right now, all installed into their own directory. (This counts multiple versions separately. As a disclamer, some of those packages are very very old and won't even run on this system as the library dependencies aren't present or they are only built for another architecture, and most of the others are obsolete and there's little reason to use them. Point being: I have access to tons of packages.) My $PATH has 21 entries, including some redundancies.

The first step to reconciling these facts is basically what you suggest later in your post: that there are multiple directories with symlinks. For instance, ~/bin is in my $PATH, and it has a few dozen symlinks to some of those packages.) But doing this or what you said ("one possibility might involve putting symlinks in /usr/bin to program files into another directory where different versions of the program can be stored") still requires a package manager which can install to a different location, which is not really supported by the Apt toolchain.

Second: just because you have a package available doesn't mean you need it in your $PATH. I have a ton of different GCC versions available, and I use three or four with some regularity. (I use even more of them infrequently.) But I don't necessarily need, say, GCC 4.5 in my $PATH. If I want 4.5 explicitly, I can always run /path/to/gcc-4.5/bin/gcc.

Third: you have to remember who Ubuntu is aimed at. It's aimed at casual users. Casual users don't even care about $PATH in the first place, because they don't start things from the command line. They just hit the windows key or whatever they do to bring up the launcher, choose what program they want to run, and click it. ...and also does not follow the time honored Unix tradition which needs to be respected.

They need to be respected, even if it has significant problems in some environments and fatal problems in others (e.g. mine)?

Re:Bad idea. (2)

EvanED (569694) | about a year ago | (#43669947)

Crap, shoulda previewed. Sorry for the formatting. Fixed version:

Then you would end up with a massive PATH variable...

First: that's only one solution. For example, I have (issues file system query) probably three or four thousand different packages available to me right now, all installed into their own directory. (This counts multiple versions separately. As a disclamer, some of those packages are very very old and won't even run on this system as the library dependencies aren't present or they are only built for another architecture, and most of the others are obsolete and there's little reason to use them. Point being: I have access to tons of packages.) My $PATH has 21 entries, including some redundancies.

The first step to reconciling these facts is basically what you suggest later in your post: that there are multiple directories with symlinks. For instance, ~/bin is in my $PATH, and it has a few dozen symlinks to some of those packages.) But doing this or what you said ("one possibility might involve putting symlinks in /usr/bin to program files into another directory where different versions of the program can be stored") still requires a package manager which can install to a different location, which is not really supported by the Apt toolchain.

Second: just because you have a package available doesn't mean you need it in your $PATH. I have a ton of different GCC versions available, and I use three or four with some regularity. (I use even more of them infrequently.) But I don't necessarily need, say, GCC 4.5 in my $PATH. If I want 4.5 explicitly, I can always run /path/to/gcc-4.5/bin/gcc.

Third: you have to remember who Ubuntu is aimed at. It's aimed at casual users. Casual users don't even care about $PATH in the first place, because they don't start things from the command line. They just hit the windows key or whatever they do to bring up the launcher, choose what program they want to run, and click it.

...and also does not follow the time honored Unix tradition which needs to be respected.

They need to be respected, even if it has significant problems in some environments and fatal problems in others (e.g. mine)?

Unix had a ton of really great ideas. But many of them have run their course. You can't progress if you say you can't change stuff.

AppV for Linux? (0)

Anonymous Coward | about a year ago | (#43669705)

This sounds like Microsoft's AppV. At least by my feeble understanding of AppV and what little I read in the summary. All dynamic libraries are packaged with the application and delivered as a unit. OS's and underlying hypervisors can use memory de-duplication to reduce the bloat that this might otherwise cause.

Why? (1)

robmv (855035) | about a year ago | (#43669717)

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

this is as far from UNIX philosophy as you can get (1)

pm_rat_poison (1295589) | about a year ago | (#43669725)

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?

More Redundancy Department output (0)

Anonymous Coward | about a year ago | (#43669755)

So now they are going to reinvent, rename, and claim full credit for Android Package files (.apk), the same way they reinvented, repackaged, and claimed credit for Debian?

ubuntu has jumped the shark. (0)

Anonymous Coward | about a year ago | (#43669907)

The majority of Ubuntu software comes from Debian. What are they thinking?

stupid Why break something that is fixed? (0)

Anonymous Coward | about a year ago | (#43669993)

Why break something that is fixed?
Absurd..

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?
or Connect with...

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>