It's not possible to cover everything. In case of libpng: we try to work around issues by creating symlinks. But libpng is a pain, it's one of the messiest libraries around (in terms of compatibility). And sometimes packages have to static link small/obscure libraries to work around the dependancy problem. Those solutions are not technically attractive, but at least they work. Long term goal is to educate developers about proper library versioning and the importance of compatibility.
"progress meters or UI el;ements that look like them do not go back and forwards"
What? The Human Interface Guidelines explictly tells me to use that kind of progress bars for operations with unknown duration. I'm just following the HIG. How's that a usability mistake?
"make your dialogs all the same size/look"
They would look really ugly if they're all the same size.
"no cancel button"
This is a technical limitation and can't be done. The cancel button is removed on purpose.
"dont ask for passwords if they are not needed"
The thing is - they are needed. How else do you want to find out whether the user wants to install as root or not?
"progress meters should accurately reflect the install processes completion, i shouldnt see anything happening to the system beyond 100% why have a progress meter for extracting files but nothing else ?"
Because it's technically impossible. Again - this has been thought of. It cannot be done.
"the uninstaller said one package needed root access to uninstall yet had no option to enter a root password"
Well, I tried packaging a Java app before but I gave up. It's just not possible to provide an easy installation experience, because of the Sun JVM, which is proprietary. I cannot auto-install the JVM because of the license, which prohibits distribution. You *may* be able to get away with this if you compile your app with GCJ but GCJ does not have a stable ABI...
Maybe you didn't take a good look at our website. We have had a solution for binary problems for a long time now, and it's called apbuild. If you have any specific questions, feel free to come over at #autopackage at irc.freenode.net
Re:Conflicts with existing package managers
on
AutoPackaging for Linux
·
· Score: 4, Informative
Autopackage is meant to be an add-on that coexists with your native package manager. It's not meant to replace anything. And the conflicts you're talking about will only occur if you try to install the same deb and autopackage on purpose. For post-1.0, native package manager integration is on our todo list.
Re:Where does everything get autopackaged to?
on
AutoPackaging for Linux
·
· Score: 4, Informative
By default, autopackage either installs to/usr or to $HOME (depending on what the user wants). If you really want it to use another prefix, you still can. The reason we use/usr instead of/usr/local is because there are many broken distributions that don't setup paths for/usr/local correctly. And/usr is the standard for many/most distributions.
There's a mirror of the autopackage website's information here.
I knew someone would say that. Read our FAQ. Mike posted a part of it below. Please read our website for the full FAQ once the Slashdotting is over. And we'll be available at #autopackage at irc.freenode.net if you have questions.
No doubt lots of people will have all kinds of questions about autopackage, such as: - "What idiots!! Another packaging format is the last thing we need!" - "What's wrong with apt-get?" - "Everybody should use Gentoo!"
Slashdotters are highly encouraged to read the autopackage FAQ! Our project has existed for over 2 years now, and many people have asked us those questions. In short: autopackage is not meant to replace RPM/DEB/apt-get/etc.
If you have more questions, feel free to come over at #autopackage at irc.freenode.net We'll be glad to answer your questions
"and it's another to participate in what's billed as an enterprise product."
As I said, I never billed my projects "enterprise product". Many open source developers have never claimed so. In fact, most people who claim so are users, not developers (or corporate people who really are selling enterprise products). So why do you keep generalizing and blaming everything on the hobby developers?
"Really what I'm questioning is whether a software developer can shirk his responsibilities to his users on the basis of the software being open-sourced."
You are assuming that there are responsibilities at all. Amateur Windows closed source freeware developers don't have responsibilities. The ONLY difference between amateur Windows closed source freeware and amateur open source software is the license. Where does this sudden "responsibility" come from? Why do amateur open source developers have responsibilities, while amateur Windows closed source freeware developers don't?
So complain to the GNOME foundation or RedHat or Novell or whatever. Stop generalizing things to "open source developers". I never advertised MY projects as "enterprise-level products".
How are "Text Editor" (menu label for gedit), "Inkscape Vector Drawing Program" (menu label for Inkscape), "Mozilla Web Browser" (menu label for Mozilla) and "Totem Movie Player" (menu label for Totem) not descriptive?
"If I were looking for a music player on Google, I wouldn't even give search results about programs named Muine, MooTag or Bluefunk a second glance, simply because they don't sound like music players."
By your reasoning, you wouldn't even take a look at Winamp and FooBar2000 even if someone is holding a gun to your head.
In what way are DivX;-) (yes including smiley), Revemu, Freya, Cake Walker and Maya descriptive? Do you hear people complaining about those names?
By your own reasoning: closed source programmers are good at a lot of things, but naming their programs isn't one of them.
That's what certification and unit testing program are for. You only get the label "100% compatible JVM implementation" if you pass the test. Where's the problem?
Even if Sun doesn't open their implementation, people will still create Java compilers. Take a look at the Kaffe and GCJ project. Why don't you complain about them "fragmentating" the Java community? If Sun open sources their JVM implementation, how will it suddenly generate more fragmentation than GCJ/Kaffe already do?
Slashdot Mirror
That would not be a good idea. Autopackage is not designed for distribution core packages, it's designed for third party desktop software.
It's not possible to cover everything. In case of libpng: we try to work around issues by creating symlinks. But libpng is a pain, it's one of the messiest libraries around (in terms of compatibility). And sometimes packages have to static link small/obscure libraries to work around the dependancy problem. Those solutions are not technically attractive, but at least they work. Long term goal is to educate developers about proper library versioning and the importance of compatibility.
"progress meters or UI el;ements that look like them do not go back and forwards"
What? The Human Interface Guidelines explictly tells me to use that kind of progress bars for operations with unknown duration. I'm just following the HIG. How's that a usability mistake?
"make your dialogs all the same size/look"
They would look really ugly if they're all the same size.
"no cancel button"
This is a technical limitation and can't be done. The cancel button is removed on purpose.
"dont ask for passwords if they are not needed"
The thing is - they are needed. How else do you want to find out whether the user wants to install as root or not?
"progress meters should accurately reflect the install processes completion, i shouldnt see anything happening to the system beyond 100%
why have a progress meter for extracting files but nothing else ?"
Because it's technically impossible. Again - this has been thought of. It cannot be done.
"the uninstaller said one package needed root access to uninstall yet had no option to enter a root password"
Are you sure? It asks the password for me.
"Why not have the binaries already as chmod+x downloadable"
Because it can't be done. File permissions are set by the browser and not a single browser sets +x for file downloads.
"Mmm. I can not install, because the site is down."
Well of course. We were Slashdotted. You can't really blame us for not having that much bandwidth can you?
Native package manager integration is planned for post-1.0.
Well, I tried packaging a Java app before but I gave up. It's just not possible to provide an easy installation experience, because of the Sun JVM, which is proprietary. I cannot auto-install the JVM because of the license, which prohibits distribution. You *may* be able to get away with this if you compile your app with GCJ but GCJ does not have a stable ABI...
Maybe you didn't take a good look at our website. We have had a solution for binary problems for a long time now, and it's called apbuild. If you have any specific questions, feel free to come over at #autopackage at irc.freenode.net
Autopackage is meant to be an add-on that coexists with your native package manager. It's not meant to replace anything. And the conflicts you're talking about will only occur if you try to install the same deb and autopackage on purpose.
For post-1.0, native package manager integration is on our todo list.
By default, autopackage either installs to /usr or to $HOME (depending on what the user wants). If you really want it to use another prefix, you still can. The reason we use /usr instead of /usr/local is because there are many broken distributions that don't setup paths for /usr/local correctly. And /usr is the standard for many/most distributions.
There's a mirror of the autopackage website's information here.
Mike setup a mirror of the autopackage website! It's here. The FAQ is also available on that mirror.
I knew someone would say that. Read our FAQ. Mike posted a part of it below. Please read our website for the full FAQ once the Slashdotting is over.
And we'll be available at #autopackage at irc.freenode.net if you have questions.
autopackage is definitely not the same as apt-get. Please read our FAQ. Mike posted it below. You may also want to read the website when it's up.
It seems our servers can't withstand slashdotting. Mike posted the FAQ below. Scroll down to read it.
No doubt lots of people will have all kinds of questions about autopackage, such as:
- "What idiots!! Another packaging format is the last thing we need!"
- "What's wrong with apt-get?"
- "Everybody should use Gentoo!"
Slashdotters are highly encouraged to read the autopackage FAQ! Our project has existed for over 2 years now, and many people have asked us those questions. In short: autopackage is not meant to replace RPM/DEB/apt-get/etc.
If you have more questions, feel free to come over at #autopackage at irc.freenode.net
We'll be glad to answer your questions
People who don't know what ethernet is probably don't know what a network card is.
Hello? That's a user's giving his opinion. Heck, even the almighty user doesn't give a fuck. That should say a lot.
How does raytracing differ from OpenGL/Direct3D-style 3D?
"and it's another to participate in what's billed as an enterprise product."
As I said, I never billed my projects "enterprise product". Many open source developers have never claimed so. In fact, most people who claim so are users, not developers (or corporate people who really are selling enterprise products). So why do you keep generalizing and blaming everything on the hobby developers?
"Really what I'm questioning is whether a software developer can shirk his responsibilities to his users on the basis of the software being open-sourced."
You are assuming that there are responsibilities at all. Amateur Windows closed source freeware developers don't have responsibilities. The ONLY difference between amateur Windows closed source freeware and amateur open source software is the license. Where does this sudden "responsibility" come from? Why do amateur open source developers have responsibilities, while amateur Windows closed source freeware developers don't?
So complain to the GNOME foundation or RedHat or Novell or whatever. Stop generalizing things to "open source developers". I never advertised MY projects as "enterprise-level products".
This just proofs that Slashdotters know nothing about usability or what average users want.
Does Linux have something like this? Fedora has had Exec-Shield long before Windows had DEP.
How are "Text Editor" (menu label for gedit), "Inkscape Vector Drawing Program" (menu label for Inkscape), "Mozilla Web Browser" (menu label for Mozilla) and "Totem Movie Player" (menu label for Totem) not descriptive?
;-) (yes including smiley), Revemu, Freya, Cake Walker and Maya descriptive? Do you hear people complaining about those names?
"If I were looking for a music player on Google, I wouldn't even give search results about programs named Muine, MooTag or Bluefunk a second glance, simply because they don't sound like music players."
By your reasoning, you wouldn't even take a look at Winamp and FooBar2000 even if someone is holding a gun to your head.
In what way are DivX
By your own reasoning: closed source programmers are good at a lot of things, but naming their programs isn't one of them.
That's what certification and unit testing program are for. You only get the label "100% compatible JVM implementation" if you pass the test. Where's the problem?
Even if Sun doesn't open their implementation, people will still create Java compilers. Take a look at the Kaffe and GCJ project. Why don't you complain about them "fragmentating" the Java community? If Sun open sources their JVM implementation, how will it suddenly generate more fragmentation than GCJ/Kaffe already do?
RAR better than bzip2? Are you kidding? Did you use bzip2 --best? Every single tar+bzip2 archive I've made is smaller than the RAR archive.
For example, I compress OpenKore 1.5.2 (1.5 MB of source files).
RAR (-m5 -md4096): 249 KB
tar/bzip2 (--best): 225 KB
Another example: Gimp 2.0.6 (source code + compiled objects), 140 MB.
RAR: 36 MB
tar/bzip2: 30 MB