Active Topics
-
The N900 is now 15 years old! (9)
to Nokia N900 by Arno_11 - 6 hrs, 3 mins ago -
Sailfish OS for the Motorola Moto G7 Power (XT1955-5) - (ocean) (4)
to SailfishOS by Maemish - 5 days, 18 hrs ago - more...
|
2009-12-22
, 21:24
|
|
Posts: 1,418 |
Thanked: 1,541 times |
Joined on Feb 2008
|
#102
|
Originally Posted by fiferboy
I am afraid you will also have to vote here:
Link to voting page is here: http://maemo.org/packages/package_in...ader/0.10.7-9/
http://maemo.org/packages/package_in...rary/0.10.7-9/
or it will not let me promote ZLibrary that is FBReader's dependency.
 |
|
2009-12-22
, 21:55
|
|
Posts: 1,684 |
Thanked: 1,562 times |
Joined on Jun 2008
@ Austin, TX
|
#103
|
Originally Posted by fms
Sorry for any lack of knowledge, I have not been the best at keeping up on this thread.
I am afraid you will also have to vote here:
http://maemo.org/packages/package_in...rary/0.10.7-9/
or it will not let me promote ZLibrary that is FBReader's dependency.
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?
__________________
770, n810, n900, Ideapad S10-3t
TheOneRing, DialCentral, Gonvert, Quicknote, Multilist, ejpi, nQa, Waters of Shiloah
Programming Blog
770, n810, n900, Ideapad S10-3t
TheOneRing, DialCentral, Gonvert, Quicknote, Multilist, ejpi, nQa, Waters of Shiloah
Programming Blog
|
|
2009-12-23
, 06:07
|
|
Posts: 1,418 |
Thanked: 1,541 times |
Joined on Feb 2008
|
#104
|
Originally Posted by epage
No, it is in "libs" now.
Does this mean you actually did keep zlibrarry in user/*?
Some personal philosophy:
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?
 |
|
2009-12-23
, 09:13
|
|
Posts: 4,274 |
Thanked: 5,358 times |
Joined on Sep 2007
@ Looking at y'all and sighing
|
#105
|
Originally Posted by fms
~ $ apt-cache rdepends libzlibrary
There is at least one other package using it. Do not remember the name.
libzlibrary
Reverse Depends:
fbreader
fbreader
fbreader
fbreader
libzlibrary-dev
fbreader
fbreader
libzlibrary-dev
fbreader
fbreader
fbreader
fbreader
libzlibrary-dev
fbreader
fbreader
libzlibrary-dev
fbreader
fbreader
libzlibrary-dev
fbreader
fbreader
libzlibrary-dev
|
|
2009-12-23
, 10:43
|
|
Posts: 1,418 |
Thanked: 1,541 times |
Joined on Feb 2008
|
#106
|
Originally Posted by qwerty12
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
~ $ apt-cache rdepends libzlibrary
libzlibrary
Reverse Depends:
fbreader
libzlibrary-dev
|
|
2009-12-23
, 10:46
|
|
Posts: 4,274 |
Thanked: 5,358 times |
Joined on Sep 2007
@ Looking at y'all and sighing
|
#107
|
Originally Posted by fms
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.
I would like to respect that, at least until forced to do otherwise
|
|
2009-12-23
, 11:46
|
|
Posts: 729 |
Thanked: 155 times |
Joined on Dec 2009
|
#108
|
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.
 |
|
2009-12-23
, 11:55
|
|
Posts: 2,121 |
Thanked: 1,540 times |
Joined on Mar 2008
@ Oxford, UK
|
#109
|
Originally Posted by DaSilva
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.
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.
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?
|
|
2009-12-23
, 14:35
|
|
Posts: 196 |
Thanked: 141 times |
Joined on Aug 2007
|
#110
|
Originally Posted by fms
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)
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
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.
| The Following 2 Users Say Thank You to jcharpak For This Useful Post: | ||
http://maemo.org/packages/package_in...ader/0.10.7-9/
Check out:
Large Statusbar Clock (https://garage.maemo.org/projects/statusbarclock/)
Personal Menu (https://garage.maemo.org/projects/personal-menu/)
Countdown Home (https://garage.maemo.org/projects/countdown-home/)
Personal Launcher (https://garage.maemo.org/projects/personal-launch/)