Active Topics
-
Error after installing Leste on sdcard (13)
to Maemo 7 / Leste by Maemish - 3 hrs, 13 mins ago -
TLS 1.2 for N9 is ready (29)
to MeeGo / Harmattan by smatkovi - 12 hrs, 3 mins ago -
Camera phone competition March 2023 "Endless" (35)
to General by Maemish - 3 days, 21 hrs ago -
Maemo repository (3)
to Community by torsen - 4 days, 13 hrs ago -
Introducing ubiboot N9 (multiboot OS loader) (1,393)
to Alternatives by smatkovi - 6 days, 17 hrs ago - more...
| The Following User Says Thank You to egoshin For This Useful Post: | ||
|
2010-02-19
, 02:47
|
|
Posts: 992 |
Thanked: 995 times |
Joined on Dec 2009
@ California
|
#172
|
Originally Posted by f(x)
Thank you, I know now why I can't install a package named 'perl' on my N900. It is an exactly the same - missing 'perl-modules'.
While the others are scared from RPM dependency hell*. All what I can say, RPM issue might still be existed even that I am running centos without problem.
*For those whom are wondering what is that, It is a problem you might encounter that wont let you install your app/lib or whats ever, because of a requirement that couldn't be satisfied.
"Error: Missing Dependency: X is needed by package Y"
But wait... it is DEB, not RPM, right?
| The Following 2 Users Say Thank You to egoshin For This Useful Post: | ||
|
|
2010-02-19
, 04:51
|
|
Posts: 1 |
Thanked: 1 time |
Joined on Feb 2010
|
#173
|
First of all, I got tired after 4 hours of reading debates over RPM vs DEB. Really, my first reaction was: 'do not change! please!'. But afterwards I read that it's actually a new RPM, a new thing, incompatible. A new invention? I don't know. I got even more upset with it. But I don't think we are getting anywhere with these discussions. What we all need is something to look at, something to animate people to develop new things. A community debating about these things without access to any real code and documentation, is a anxious and insecure community. Exactly there I think Nokia and Intel could add something...
If there's some need to change things, in my opinion it has to be made clear why, and more importantly: what are the advantages. I can live with RPM as well as with DEB, but if I have to change my programs, I always (as every human being) want to see some evolution, something new I didn't see before, something that makes me feel exited. Just this new project with this new name is getting me anxious. And I see more people getting anxious, not knowing if there's a future....
I've read about 'a build system', about flame wars about a lot of things, but nothing make me feel I will get something new. The build system is (as far as I know) compatible with DEB as well as with RPM, so that's no argument. What is the argument for changing? Even if there's no argument for a change (just the result of the merge where something is kept from both sides), I think it could be put in a way we do see something new.
I feel that it's simply the way Intel and Nokia see that they could merge the two projects, leaving both sides with some things they used to use. But even if it's just this, I think it could be put better. If Intel has something that's nice / good / hot to use: link to some article, show something new. People love to see a future. I really regret seeing people leaving this way...
But again, as it's a commercial project, I could be asking too much for now. I bet that within a few months, we all will now quite a lot more about what's hot and what's new. Nokia never announced a lot of things in advance. They just come up with something done.
For now I will stay confused (though with great expectations). I'll try to focus on other things for now, like dreaming about oFono and terminating my port of the HP48 emulator to Maemo4 and Maemo5 (packages in .... .deb)...
If there's some need to change things, in my opinion it has to be made clear why, and more importantly: what are the advantages. I can live with RPM as well as with DEB, but if I have to change my programs, I always (as every human being) want to see some evolution, something new I didn't see before, something that makes me feel exited. Just this new project with this new name is getting me anxious. And I see more people getting anxious, not knowing if there's a future....
I've read about 'a build system', about flame wars about a lot of things, but nothing make me feel I will get something new. The build system is (as far as I know) compatible with DEB as well as with RPM, so that's no argument. What is the argument for changing? Even if there's no argument for a change (just the result of the merge where something is kept from both sides), I think it could be put in a way we do see something new.
I feel that it's simply the way Intel and Nokia see that they could merge the two projects, leaving both sides with some things they used to use. But even if it's just this, I think it could be put better. If Intel has something that's nice / good / hot to use: link to some article, show something new. People love to see a future. I really regret seeing people leaving this way...
But again, as it's a commercial project, I could be asking too much for now. I bet that within a few months, we all will now quite a lot more about what's hot and what's new. Nokia never announced a lot of things in advance. They just come up with something done.
For now I will stay confused (though with great expectations). I'll try to focus on other things for now, like dreaming about oFono and terminating my port of the HP48 emulator to Maemo4 and Maemo5 (packages in .... .deb)...
| The Following User Says Thank You to josvdv For This Useful Post: | ||
 |
|
2010-02-19
, 06:57
|
|
Posts: 98 |
Thanked: 26 times |
Joined on Sep 2009
|
#174
|
Originally Posted by egoshin
I am not sure if you are trying to be sarcastic about what I said or you simply asking for real.
Thank you, I know now why I can't install a package named 'perl' on my N900. It is an exactly the same - missing 'perl-modules'.
But wait... it is DEB, not RPM, right?
If you added repositories that contain perl-modules then it will eventually will install all it dependencies as it is existed or simply compile it (you will need to check perl for requirements). While RPM hell is existed when you want to install X that is requiring Y and Y won't be installed unless A,B,C installed first and you won't be able to find one or more of these requirements because of its either not existed or conflict with D or for any similar reasons ,so here is a no go for install X and you should forget it. --Hopefully, I explained it better this time.
__________________
Please don't consider any given "Thanks" by this user as a positive sign of grateful; as a leak of giving "-Thanks" is a leaked feature here. You might be rewarded by meaningless "Thanks" by this user.
-Thanks for your understanding
Please don't consider any given "Thanks" by this user as a positive sign of grateful; as a leak of giving "-Thanks" is a leaked feature here. You might be rewarded by meaningless "Thanks" by this user.
-Thanks for your understanding
|
|
2010-02-19
, 09:24
|
|
Posts: 3,617 |
Thanked: 2,412 times |
Joined on Nov 2009
@ Cambridge, UK
|
#175
|
Originally Posted by f(x)
No, because that situation is no different for DEBs - in either case, if you have a consistent repository then all the dependencies will sort themselves out. If your repositories are not consistent then you end up with conflicts. The problem does appear more often with RPMs because there's far more distributions using them (and they're not all just derivatives of the same core system), so people are more likely to grab an RPM built for another distribution. The problem has nothing to do with RPM or DEB themselves though.
I am not sure if you are trying to be sarcastic about what I said or you simply asking for real.
If you added repositories that contain perl-modules then it will eventually will install all it dependencies as it is existed or simply compile it (you will need to check perl for requirements). While RPM hell is existed when you want to install X that is requiring Y and Y won't be installed unless A,B,C installed first and you won't be able to find one or more of these requirements because of its either not existed or conflict with D or for any similar reasons ,so here is a no go for install X and you should forget it. --Hopefully, I explained it better this time.
|
|
2010-02-19
, 10:17
|
|
Posts: 3,319 |
Thanked: 5,610 times |
Joined on Aug 2008
@ Finland
|
#176
|
Originally Posted by egoshin
Definitely NO
I better to give you an example - consider the possibility of ABSENCE of any repository package management. Would Nokia chose a different policy? - definitely YES.
The policy is that no external source shall replace system libs/components because that would make QA pointless. RPM, DEB, tar.gz, .bin, apt, yum, cp+mv, doesn't matter.PS obviously WE can avoid these policies with things like fmtxfaker, custom kernels, etc, but Nokia won't, and on things of this caliber, that's what counts.
__________________
Blogging about mobile linux - The Penguin Moves!
Maintainer of PyQt (see introduction and docs), AppWatch, QuickBrownFox, etc
Blogging about mobile linux - The Penguin Moves!
Maintainer of PyQt (see introduction and docs), AppWatch, QuickBrownFox, etc
 |
|
2010-02-19
, 13:07
|
|
Posts: 52 |
Thanked: 45 times |
Joined on Dec 2009
|
#177
|
Originally Posted by Rob1n
It's not so much that there are far more distributions using RPMs, it's more that most if not all RPM distros support far fewer packages than Debian does. That of course forces users wishing to use programs not in the central RPM repository to install unofficial and untested packages.
No, because that situation is no different for DEBs - in either case, if you have a consistent repository then all the dependencies will sort themselves out. If your repositories are not consistent then you end up with conflicts. The problem does appear more often with RPMs because there's far more distributions using them (and they're not all just derivatives of the same core system), so people are more likely to grab an RPM built for another distribution. The problem has nothing to do with RPM or DEB themselves though.
|
|
2010-02-19
, 19:07
|
|
Posts: 992 |
Thanked: 995 times |
Joined on Dec 2009
@ California
|
#178
|
Originally Posted by attila77
We are speaking on different things. Sorry.
Definitely NO
PS obviously WE can avoid these policies with things like fmtxfaker, custom kernels, etc, but Nokia won't, and on things of this caliber, that's what counts.
| The Following User Says Thank You to egoshin For This Useful Post: | ||
|
|
2010-02-19
, 19:12
|
|
Posts: 992 |
Thanked: 995 times |
Joined on Dec 2009
@ California
|
#179
|
Originally Posted by EzInKy
Hm-m. Can you remind me the usual warning which is given each time in different threads of this forum about extras-devel repository?
It's not so much that there are far more distributions using RPMs, it's more that most if not all RPM distros support far fewer packages than Debian does. That of course forces users wishing to use programs not in the central RPM repository to install unofficial and untested packages.
For some strange reason it says something about "your own risk" and "be prepared to reflash your device because of untested packages".
And I noted that 90% (or even more) threads in this forum are about packages in 'extra-devel' repository.
What is going on - Maemo 5 is DEB but not RPM, right?
| The Following User Says Thank You to egoshin For This Useful Post: | ||
 |
|
2010-02-19
, 19:50
|
|
Posts: 850 |
Thanked: 626 times |
Joined on Sep 2009
@ Vienna, Austria
|
#180
|
Originally Posted by egoshin
having access to big debian repositories isn't supposed to be immediately beneficial to end-users.
For some strange reason it says something about "your own risk" and "be prepared to reflash your device because of untested packages".
it makes porting popular OSS applications a hell of a lot easier, resulting in more available software.
if a program depends on a lot of libraries that can't be ported as easy as "apt-get source program && dpkg-buildpackage" inside the armel target, it just results in more work and fewer ports.
__________________
"What we perceive is not nature itself, but nature exposed to our method of questioning."
-- Werner Karl Heisenberg
"What we perceive is not nature itself, but nature exposed to our method of questioning."
-- Werner Karl Heisenberg
Last edited by SubCore; 2010-02-19 at 20:35. Reason: vocab
 |
| Tags |
| rabble-rousing, rpm vs. deb war, rpmligion vs debligion, vote attila77 |
«
Previous Thread
|
Next Thread
»
|
All times are GMT. The time now is 07:37.
And the same is RPM vs DEB. For details, please turn back to my original post.