or it will not let me promote ZLibrary that is FBReader's dependency.
Sorry for any lack of knowledge, I have not been the best at keeping up on this thread.
Does this mean you actually did keep zlibrarry in user/*? I'm concerned of spreading issues related to it to something that should be for packages people consider ready for Extras
Some personal philosophy: People having issues in extras-devel is fine, its expected, if you don't want it, stay out. Bringing those issues into extras-testing is bad I think because it should reflect what things should be like in extras (if it was deemed ready immediately and promoted, not that issues shouldn't be left to be found in the QA process) which is bad.
More philosophy: an end-user should not be seeing libraries in Extras. This is going to be enabled by default so anyone and everyone will see "zlibrary" as an installation option. What?
I forgot, what is wrong with the solution of packaging zlibrary inside of fbreader rather than separately? is it really gaining an advantage by being a separate library? Even if one other component depends on it, is the amount of advantage of sharing zlibrary's really outweigh the headache of this?
Does this mean you actually did keep zlibrarry in user/*?
No, it is in "libs" now.
Originally Posted by
Some personal philosophy:
I generally ignore navel-gazing matters when I need to solve a concrete problem.
Originally Posted by
I forgot, what is wrong with the solution of packaging zlibrary inside of fbreader rather than separately? is it really gaining an advantage by being a separate library? Even if one other component depends on it, is the amount of advantage of sharing zlibrary's really outweigh the headache of this?
There is at least one other package using it. Do not remember the name.
Still, I distinctly remember a t.m.o thread where MishaS said that he would prefer not to make libzlibrary part of fbreader package, citing another applicaiton depending on it. I would like to respect that, at least until forced to do otherwise
I would like to respect that, at least until forced to do otherwise
Agreed. It's the right thing to do. At the very least - if you merge it - you'll bring in complications like dpkg trying to overwrite files in another package. As you will know, there are ways around that but it's stupid trying to implement them as I, too, believe they should be kept separate.
But I agree with you that it is strange to have a library in extras. HAM is something like an app store (from consumer point of view) and I can't imagine to have libraries in Ovi Store or Apples App Store so is there no way to release the library to the repository but without showing up in HAM? If Maemo should become more famous then it should be easy for beginners and none of them would understand what a library is and why "nothing" has happened after they have installed it.
But I agree with you that it is strange to have a library in extras. HAM is something like an app store (from consumer point of view) and I can't imagine to have libraries in Ovi Store or Apples App Store so is there no way to release the library to the repository but without showing up in HAM? If Maemo should become more famous then it should be easy for beginners and none of them would understand what a library is and why "nothing" has happened after they have installed it.
I believe by the library being in "libs" rather than "user", it won't show up in HAM. It's still in the repository, but won't show up in the HAM user interface, so that should hopefully answer your concern.
What I'm not quite sure about is what happens if there is a new version of the library. As it won't show up in HAM, presumably it also won't show up when the user is notified about updates, so the user won't be able to update it. Is this correct?
Still, I distinctly remember a t.m.o thread where MishaS said that he would prefer not to make libzlibrary part of fbreader package, citing another applicaiton depending on it. I would like to respect that, at least until forced to do otherwise
I believe his vbataxx game also uses the library (no surprise as he wrote both). On the other hand FBReader always was linked to newest version of the library anyway (the depends line was always to libzlibrary >= the curent version of the library)
Putting it in libs shouldn't be a problem if the depends line requires the latest version. It's only depends on generic stuff like python2.5 (no specific version of 2.5 required) that is likely to cause problems.
