Consistency info usage and user interface
on
Is RPM Doomed?
·
· Score: 1
It is not so much RPM that is to blame for installation problems, it is the level of consistency of package information and its use, which is a function of creator and community meticulousness not so much of the package standard. And the user interface to that could do some improvement on existing ones. I know Slashdot != Santa, but choose not to believe that now:)
A key is how to fully use all dependency and configuration info in a trivial UI, for a generic package manager from all RPM vendors and even others. There should be a globally upgradable distributed database to resolve consistency dependencies among all RPMs etc. ever published. Way too many distros today to converge.
Trying to set more rigorous standard there won't hurt but the database would be more short term solution. Compilation option data should be standardized, dynamic download location pickup, and all data needed from rpmfind etc. to figure out things for non-default-distro packages would need to be built in.
Systems like Ximian's Red Carpet are a good start to show what the UI could look like. I'd still simplify the default a bit. I used Debian dselect around -96 when it was new but moved away due to then continuous inconsistency issues. Stepping backwards to RPMs was a time saving issue tho I lost dselect benefits for some time.
InstallShield -like simplicity, reliable global dependency checking, alternative ascii UI, easy batch-mode with system- and category wide upgradability, and the sharing and parameterizable multi platform support are a must for a future RPM UI. Whatever I have considered, all pieces are not yet there. Such a front should actually handle dpkg, rpm, and whatever else there are, all simultaneously. One should be able to choose source vs binary upgrading with params setup for both, whether upgrade is for the running system or some other target (pull/nfsmount that arm/old i386 sys disk from that slow/old box and go). Verification is also important for not to make it a trojan install system. I would not mind privacy for snoopers not to know my setups.. Users should be able to upgrade consistency info in that database and kernel (driver) configuration should be made available thru it also. Generating a bootable default install CD/DVD image that would (meta)install the chosen system either from network or by local copy from stuff on the CD/DVD would be a plus. Yes, and my granny would need to be able to do some install with the UI (not necessarily the one with the right global compilation optimization params through all packages, though).. And put the same UI to be available as a standard tool for newinstall disks, like the/stand/sysinstall is in FreeBSD. So it'd more need an interesting project effort rather than abandoning the RPM.
Yes, and a nice blonde shaking her.. head as a default UI skin when the UI does its job would not hurt, either:o]
Slashdot Mirror
It is not so much RPM that is to blame for installation problems, it is the level of consistency of package information and its use, which is a function of creator and community meticulousness not so much of the package standard. And the user interface to that could do some improvement on existing ones. I know Slashdot != Santa, but choose not to believe that now :)
/stand/sysinstall is in FreeBSD. So it'd more need an interesting project effort rather than abandoning the RPM.
.. head as a default UI skin when the UI does its job would not hurt, either :o]
A key is how to fully use all dependency and configuration info in a trivial UI, for a generic package manager from all RPM vendors and even others. There should be a globally upgradable distributed database to resolve consistency dependencies among all RPMs etc. ever published. Way too many distros today to converge.
Trying to set more rigorous standard there won't hurt but the database would be more short term solution. Compilation option data should be standardized, dynamic download location pickup, and all data needed from rpmfind etc. to figure out things for non-default-distro packages would need to be built in.
Systems like Ximian's Red Carpet are a good start to show what the UI could look like. I'd still simplify the default a bit. I used Debian dselect around -96 when it was new but moved away due to then continuous inconsistency issues. Stepping backwards to RPMs was a time saving issue tho I lost dselect benefits for some time.
InstallShield -like simplicity, reliable global dependency checking, alternative ascii UI, easy batch-mode with system- and category wide upgradability, and the sharing and parameterizable multi platform support are a must for a future RPM UI. Whatever I have considered, all pieces are not yet there. Such a front should actually handle dpkg, rpm, and whatever else there are, all simultaneously. One should be able to choose source vs binary upgrading with params setup for both, whether upgrade is for the running system or some other target (pull/nfsmount that arm/old i386 sys disk from that slow/old box and go). Verification is also important for not to make it a trojan install system. I would not mind privacy for snoopers not to know my setups.. Users should be able to upgrade consistency info in that database and kernel (driver) configuration should be made available thru it also. Generating a bootable default install CD/DVD image that would (meta)install the chosen system either from network or by local copy from stuff on the CD/DVD would be a plus. Yes, and my granny would need to be able to do some install with the UI (not necessarily the one with the right global compilation optimization params through all packages, though).. And put the same UI to be available as a standard tool for newinstall disks, like the
Yes, and a nice blonde shaking her
That's all, Santa.