Slashdot Mirror
Ubuntu Developing Its Own Package Format, Installer
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."
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
Karma: Excellent. 15 moderator points expire sometime.
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.
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.
There's no -1 for "I don't get it."
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:
Ask me about repetitive DNA
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.
Hi. Developer here. No, no it is not. Pain in the ass is thunking, handlers that silently disconnect from message pumps, calls to win32 that are "unmanaged" and so often lead to memory leaks even when you diligently try to do garbage collection, undocumented exceptions that are thrown by system calls that even the debugger blanches at, and endless layers of class and interfaces nine levels deep, many of which only document the public methods and tell you nothing else. The registry though? The registry is stupid easy. If you think that's a pain in the ass, you fail as a programmer. Turn in your badge.
Getting rid of the registry was a huge selling point for Windows 8,
So was the 'Metro' interface. And I don't see many people around here talking about how great Windows 8 is going to be -- everyone says it's going to be a three coiled turd. And this is what you use to advance your argument?
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.
There's no such thing as 'virii' and I don't think you know what a honey pot is. But perhaps you mean it's a rich repository of system and application settings that could be exploited by malicious people? Yes, that is correct. But then, scanning down the C: for a list of filenames can do that too. The registry has a rich set of access controls; Your lack of familiarity with other security concepts suggests you probably didn't know that.
Linux DOES INDEED have a system for library control, its called pkg_config and it works very well.
A tool used to assist in compiling is not a "library control" tool dude. It's main job is to tell whether a library is installed or not, what version it is, and where it is located. It doesn't do much else. It most certainly does not have any management functions.
Its not my problem if developers are too lazy to use it.
*facepalm* Who wrote the applications you're using right now? Are you sure their "lazyness" isn't your problem?
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.
That whooshing sound is the point flying over your head. 100% of windows applications have to go through the kernel to load dlls, and so it presents a standardized interface for doing so. Linux does not have this. Whether it's 90% of linux apps, or 99%, the lack of a standard means you, the developer, have to guess, pray, or assume, things about the environment. You can't rely on it.
I do quite well with Linux, thank you.
That's nice. I'm a neo-pagan who dances around poles naked, and it works quite well for me. But I'm not going to suggest it's for everyone, or that there aren't occasional problems in going "sky clad" in a public place. The police, for example, aren't as understanding as one might hope.
#fuckbeta #iamslashdot #dicemustdie
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.
You asked for it, Debian delivers. The Debian CUT Project aims to publish usable snapshots of Debian Testing on a monthly basis. They're pretty new but picking up steam.
Does ldconfig allow for different versions of the same library to be requested by the application?
Yes.
Can you please point out which setting in the man page allows you to set this, oh great wizard of Linux? Because I think you're just being a contrarian right now, and haven't actually read the damn page.
Better than that. You as a user can see what libraries are loaded from where and which ones are missing precisely.
Again, read the man page. You can specify which directories it uses to build its cache. That's it. There's no "precision" in that; And if you think I'm going to grep a few thousand lines of output to figure out which library it matched first, you've clearly spent too much time as a user and not enough time as a system administrator. I want something that just works... not having to screw around with a dozen /etc/ config files and another half dozen commands to suss out what went wrong everytime I upgrade a library or application.
The "superior alternative" is just a black box.
It's a black box that happens to meet the business needs of most organizations I have worked for. Linux has not. So, at least as far as usability is concerned, it is a superior alternative. MacOS is even superior from an administration perspective. Linux is good for servers, and that's it. You can build a linux system and then let it happily chortle away for years, even decades -- as long as you don't change anything. Keeping hundreds of linux boxes up to date and patched is a fucking nightmare.
#fuckbeta #iamslashdot #dicemustdie
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.
Live today, because you never know what tomorrow brings
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.
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
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.
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
A typical desktop distro is an example of a system that is very 'fat' in terms of available components, but poor in terms of what can be considered integral to the system. There is gobs of duplicated functionality, and the packaging system treats all these pieces pretty equally and a lot of it can get in the way when you have independantly installed apps. So I think the difficulty for upgrading that you speak of is more acute in desktop distros than it is for, say, OS X.
Ubuntu is starting to limit the role of the managed repository: It will continue to be used for the core OS, but apps will increasingly use the new format which primarily specifies the OS version as a dependency to be checked. If the app needs more than what the OS offers, then they are free to include the extra libraries in their own tree. This makes a lot of sense and I hope it catches on with app developers.