mintInstall and Packagekit

[redvivi]

Hi,

For the record, Packagekit (Whats is Packagekit: http://www.packagekit.org/pk-intro.html), is a new package manager from RedHat/Fedora community that simplifies the package management across distributions. To my mind, it's a great enhancement over the current solutions, it proposes to the user a software if he tries to open an unknown file type, if a software needs to install a specific dictionary/font (via D-Bus), and the user never cares about .rpm or .deb, console stuff and so on. Select the software to install and you're done. It has just to work, as Mint's philosophy.

mintInstall is a great package manager, more intuitive but also inherently more restrictive than synaptic. I understand some softwares needs some tweaks/enhancements to be integrated to Mint, but from the user experience, is it convenient to have 2 packages manager (btw, a newbie would ask what's a package ? what's a repository ?) ?. One location to install all your softwares/updates, never care about the package's type should be better to me.

If Packagekit becomes the standard package manager, would it be convenient to keep mintInstall ? What would be its future ?

Regards,
RedVivi

[Husse]

Thanks for asking
We are not there yet
But if packagekit becomes more widely used we have to look at it more closely and what happens will be decided then
I have not looked at it much but it is surely a good idea

[Fred]

redvivi,

Binary package management is by no means a trivial task. Many attempts have been made over the years but only .rpm and .deb have survived and flourished. Well there is pacman for Arch, but it is really a different animal altogether.

Due to the difficulty of the task and the track record of the attempts, I am always skeptical of new binary package management systems. I am most often reminded of the term, "reinventing the wheel."

Having said that, I am confident Mint will make the right decisions in that regard if and when the time comes.

Fred

[username]

[quote][/Due to the difficulty of the task and the track record of the attempts, I am always skeptical of new binary package management systems. I am most often reminded of the term, "reinventing the wheel."quote]

HA! Pardon my effrontery as a newbie to LM, but I couldn't help but respond to the mention of reinventing the wheel...IMHO the wheel NEEDS to be reinvented as far as package management goes! This is no easy task!! given the number of Linux distros out there seemingly competing against one another with the comman cause of going against a Giant, we are like Davids. David's haven't progressed much from APT, or derivatives of it. My hope is that newer distro's like Mint & rpm-based ones, etc. can get together upon a cross-platform standard. It would blow everything wide open. These are exciting times.

[dequire]

I installed KPackageKit a few weeks ago and have used it as a "Synaptic replacement" so far, installing updates, packages, etc. It works well for this purpose (and looks better in KDE than Synaptic since it is a KDE/QT front end). I am going to try it out for installing other types of packages and I will report the results. I think it's a great idea.

FWIW - I agree with the poster above. Here's a real world example: you try out KDE CE. You think it's kinda cool. You find there's a great website called http://www.kde-apps.org/ and you explore it. "OMG look at all these cool apps here. And Plasmoids! And themes, and......". SO you want to install a few of them to try them out. But then you notice there's not a .deb in sight. So, you roll up your sleeves and say to yourself that you can do this. You can surely read and follow directions in the unzipped download's readme file. You read and execute "cmake packageXXX". It doesn't work. Oh wait, cmake is not installed by default in Mint / Kubuntu. By now, 90 pct of that "coolness factor" is gone. But 10 pct of you are brave and plow onward. sudo apt-get install cmake gets the job done. Compile...wait..wait..wait...error. Apparently you need some *-dev files in addition, however it is unsure what ones you need, since what they are called (and whether they are installed or even available or not) depends on your distribution.

We know that compiling from source can be a PITA sometimes even for experienced users. Imagine a noobie Mint user who is smart enough to conclude "If I'm running KDE, why can't I use these apps listed on KDE-apps.org?????". So they ask a question in a forum and get all the various answers we all know they will get about distributions, "flavors of Linux", packages, the said benefits of DEB, RPM, PISI, PUP, etc etc depending on the forum they are in.

At this point they will either likely give up, or keep plodding ahead. But most people will say "screw this I only wanted to see that cool looking weather app, it's not that important anyways". And then move on.

My example is just one of 100's out there that can lead a novice user to the same conclusion. Sites like get-deb.net are a good start, however they have very few (in the grand scheme of things) applications. And they are Ubuntu (read: not Xubuntu, Kubuntu, etc.)-centric only.

I hope application packaging continues this evolutionary track it is on. It can only benefit us all.

[redvivi]

I agree with dequire. Firstly, I don't want to blame someone, kill some efforts and so on but we should focus on what is missing to improve Linux.

Is it really necessary to keep .mint packages ? How many users could understand why is there 2 different packages types (and 2 softwares to manages them) in one operating system ? Seems confusing.

To my mind, every time I open the Terminal to solve a problem (and it's often about packages), I think Linux failed somewhere for the common user. We can't ask a newbie to learn about sudo, command line, package management system, packages types and so on to simply use the system.hough.

[DrHu]

http://www.packagekit.org/pk-intro.html

PackageKit is a system designed to make installing and updating software on your computer easier. The primary design goal is to unify all the software graphical tools used in different distributions

So it is essentially a new system/gui combo system ( system process) to allow any package via any package format across any Linux distribution (.rpm based or .deb based) etc., to be handled by the user

Maybe it will just increase complexness

This is what http://www.cnr.com also attempted to do, except as a web site..

But if the issue is only to avoid the native package formats used on a distribution style (Debian -derived, Red Hat -derived): why is that an advantage for all the extra issues that might arise via the thousands of packages /source code files available for all Linux users ?

[redvivi]

But if the issue is only to avoid the native package formats used on a distribution style (Debian -derived, Red Hat -derived): why is that an advantage for all the extra issues that might arise via the thousands of packages /source code files available for all Linux users ?

It's an interesting point. Does it mean that we should jail the users into one package system for one distribution ?

If the answer is yes, only the mainstream distribution (=popular package system = more softwares = more possibilities) will managed to convince users. To my mind, it fragments the Linux usage across many distributions. Hence you fragments the developers' efforts into many packages system (sometimes they choose one package system, so one distribution), reducing the software availability across distribution and the global open-source community efficiency.

If we turn into a single system, I think it would improve global compatibility, standardization and software quality. Then you'll be able to use a Linux flavors without regarding first the softwares you can use on it.

[DrHu]

If we turn into a single system, I think it would improve global compatibility, standardization and software quality. Then you'll be able to use a Linux flavors without regarding first the softwares you can use on it.

I know it is a popular synonym for UNIX, aka what flavor are you
--Linux hasn't forked (borked) in the way that UNIX did..

I just don't think that applies to a distribution, since there are at least two well know types Debian derived and red hat derived, as well as LSB based (which those two distribution types support)

The argument for a single championed Linux system that all supposed users or potential users of Linux would get behind and promote is a fantasy, but it is an argument; despite Microsoft's own evidence of OS versions (dare one say flavors), that users seem to buy or use in droves: again it is the Microsoft string arming of OEM contracts that is at least or maybe mostly responsible for that situation. (vis-a-vis user choice)
http://www.microsoft.com/en/us/default. ... l+Products

Also it should be noted that all developers, whether Linux, Windows, Apple , first develop with source code; then decide how to package their application (development)

If it's a windows application, they might have used an .exe format, but now they will probably have to use some kind of .net format or .msi (already 3 formats for distribution for windows) to ensure compatibility with the later windows OS versions (flavors), like Vista or win7 or next version
http://www.comptechdoc.org/os/windows/w ... wdist.html
http://support.microsoft.com/kb/917607

Windows software distribution file formats..I've lost count

And I don't see how that file format abundance is any better than Linux options..

• Same with Linux
• Same with Apple for OS-X

Except the Linux developer has the option of using a foss model and providing source code or within the GNU license selling it as a application; and perhaps packaging it for a particular distribution or making it a binary (executable file) only, like Nvidia does for their Graphic cards' driver file..