| |||||||||||||
|
| |||||||||||||
RPM -- plans, goals, etc.RPM -- plans, goals, etc.Posted Dec 15, 2006 22:37 UTC (Fri) by GMCL2 (guest, #42253)Parent article: RPM -- plans, goals, etc.
Hello everybody,
I've used during several years rpm and deb technology, I've several real
- Why the performances are bad with rpm compar to deb ?
- I haven't seen a same mechanism of dpkg-reconfigure (
- Why the dependencies packages are on files, not on packages, same as
- Possible to compile some part of the system WITH automatically
Moreover, some features aren't present into deb and rpm :
- install easily a software same as that on windows (
It's maybe the time to refactor all good ideas around software management
(Log in to post comments)
RPM -- plans, goals, etc. Posted Dec 16, 2006 22:57 UTC (Sat) by seyman (subscriber, #1172) [Link] > - Why recommended and suggested packages doesn't exists into rpm ?
It was included recently in JBJ's fork.
> - Why the performances are bad with rpm compar to deb ?
I've never actually seen this.
> - Why the dependencies packages are on files, not on packages, same as deb ?
Because the packages depend on files, not on other packages.
> - to have the same software with different versions (possible with gentoo)
Provided there are no file conflicts, rpm should allow you to install any number of versions of a given software.
RPM -- plans, goals, etc. Posted Dec 18, 2006 22:05 UTC (Mon) by cortana (subscriber, #24596) [Link] > > - Why the dependencies packages are on files, not on packages, same as deb ?
> Because the packages depend on files, not on other packages. Dpkg is doing it wrong, in this case.
At the risk of starting a huge OT discussion... why?
Say you have the package 'foo' that contains an executable that links against libbar.so.3. How does 'foo depends on /usr/lib/libbar.so.3' express the fact that foo uses symbols that were introduced into libbar.so.3 in version 4.2? I may only have libbar version 4.1 installed, and so even though the dependency is satisfied I am unable to run foo.
RPM -- plans, goals, etc. Posted Dec 19, 2006 11:52 UTC (Tue) by seyman (subscriber, #1172) [Link] > At the risk of starting a huge OT discussion... why?
Because the dependencies for a package can be in any number of packages, all of which would resolve them.
> How does 'foo depends on /usr/lib/libbar.so.3' express the fact that foo uses symbols that were introduced into libbar.so.3 in version 4.2?
Package dependencies should be used for symbol versioning but these should compliment file dependencies, not replace them (IMHO, of course).
RPM -- plans, goals, etc. Posted Dec 21, 2006 13:42 UTC (Thu) by cortana (subscriber, #24596) [Link] This only seems to be an issue because of the lack of a standardised method for determining the proper dependencies that a package should end up with. In Debian, if I was packaging a program that links against libmysqlclient.so.15, during the package build process I would use the dpkg-shlibdeps program which basically does this: cat /var/lib/dpkg/info/*.shlibs | awk '$1 == "libmysqlclient" && $2 == "15" {print $3, $4, $5, $6, $7, $8, $9}'. (Does anyone know a better way to tell awk to 'print the rest of the line', BTW?) The output is libmysqlclient15off (>= 5.0.24-2), which I would use directly in the package's Depends field. Here's a more typical example: $ dpkg-shlibdeps -O /usr/bin/mysql
RPM -- plans, goals, etc. Posted Dec 21, 2006 13:49 UTC (Thu) by Randakar (guest, #27808) [Link] > Because the dependencies for a package can be in any number of packages,> all of which would resolve them.
That's bogus. It's easily possible for different packages to provide the same file with -different- contents. deb packages simply say 'Provides: foo' in their package headers if they want to give users a choice of packages.
File dependencies however plainly don't cover a number of cases, like kernel versions with or without certain features, udev revisions (which can 'add files' in /dev without actually packaging them), certain types of library conflicts..
Personally I think all those RPM people just have no idea what they're missing out on with .deb.
Worse, instead of just saying 'argh, this project was abandoned, but hey look, we have a great alternative with DPKG' they embark on something that can only lead to massive duplication of effort.
|
|
||||||||||||