egoshin | # 171 | 2010-02-19, 02:44 | Report

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.

And the same is RPM vs DEB. For details, please turn back to my original post.

egoshin | # 172 | 2010-02-19, 02:47 | Report

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?

josvdv | # 173 | 2010-02-19, 04:51 | Report

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)...

f(x) | # 174 | 2010-02-19, 06:57 | Report

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.

Rob1n | # 175 | 2010-02-19, 09:24 | Report

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.

attila77 | # 176 | 2010-02-19, 10:17 | Report

Definitely NO 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.

EzInKy | # 177 | 2010-02-19, 13:07 | Report

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.

egoshin | # 178 | 2010-02-19, 19:07 | Report

We are speaking on different things. Sorry.

egoshin | # 179 | 2010-02-19, 19:12 | Report

Hm-m. Can you remind me the usual warning which is given each time in different threads of this forum about extras-devel repository?

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?

SubCore | # 180 | 2010-02-19, 19:50 | Report

having access to big debian repositories isn't supposed to be immediately beneficial to end-users.
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.

---

Last edited by SubCore; 2010-02-19 at 20:35. Reason: vocab