From Mandriva Community Wiki

Here's some ramblings started on various issues, planned features and a wishlist for people to contribute to..

Contents 1 Features 1.1 Planned 1.2 To be considered 2 Issues 3 Ideas

Features

Planned

• Improved loop elimination

Proper ordering is currently not achieved, with a misunderstood policy on the use of Requires(pre,...) for the purpose..

• • Possible options
    • Prioritized removal of packages from loops based on such dependency attributes

• Improved "native" rpm file triggers

%trigger currently lacks two features for it to completely replace the legacy mandriva implementation.

• • Regexp matching

%trigger currently does matching on wildcards and directories only..

• • Passing of matched results to trigger script

The legacy Mandriva file triggers passes all matches as arguments fed through STDIN, while firing trigger just once. %trigger on OTOH lacks a way to pass the matched files/directories, while the designed mechanism is to fire once per item matching an expression. For Mandriva Linux 2011 a hack was added to prevent firing file triggers multiple times.

• Merging of rpm-helper, spec-helper, rpm-manbo-setup, rpm-mandriva-setup etc. into rpm

These macros, scripts etc. needs to be cleaned up, streamlined and merged into rpm in a generic way.

• Provide more regression tests for new features

• Review vendor conditional #ifdefs

• Dependency generator
  • Adopt internal dependency generator
  • Implement a new perl dependency generator

Currently dependencies are generated automatically from the perl files, leading to tons of perl() provides. As perl's CPAN metadata has it's own set of dependencies etc. defined, it should be possible to use this in stead to generate it from, which should result in a drastic reduction of dependencies generated. Similar has already been implemented for both python eggs and ruby gems.

• Simulated install --justdb equivalent install from hdlists (TODO: describe later)

To be considered

• native rpmlib implementation for rpm(5) packagekit backend for use with smart and/or urpmi (look at zif for inspiration)
  • switch to packagekit backend for MPM

• Native 'alternatives' support
  • 'update-alternatives' replacement within RPM

Currently alternatives is handled by a separate 'update-alternatives' tool, ~equivalent mechanism implemented in RPM itself would be nice.

• • Dependency priority

As alternatives are handled by 'update-alternatives', priority of alternatives are maintained outside of RPM. This gives difficulty to dependency solvers such as ie. urpmi which asks for what dependency to select in cases where there are multiple packages providing a dependency. Currently this is left to user to decide, or if --auto is used, there's no way of instructing urpmi to prefer one package over another to satisfy a dependency, leading to urpmi potentially selecting undesired dependencies. Feeding provides with some priority attribute for the dependency solver to base it's automatic selection on, while used for sorting order of packages presented for user choice is one potential idea..

• Epoch deprecation

Epoch in packages gives headaches as there's currently no convenient way of eliminating them once introduced.. Possible options has yet to be properly researched.

• Metadata
  • Synthesis
    • Metadata

The synthesis format used which contains the necessary metadata about packages for dependency solving lacks metadata about itself.

• • • Signing?
  • Files

Resolving parent directory and symlink dependencies.. Bloom filter? (TODO: add details on this one)

Issues

• Distepoch pattern matching (the extra '-' in pkg file names
  • the Nvra index lacking Epoch/Distpoch/Disttag
• revisiting concurrent vs transactional behavior

Ideas

Contribute your ideas here..

Features:

• MANDATORY signed package policy
• multithreading (whatever that means)
• Implement a metadata format for CMake, which ie. rpm could make use of during building of packages, generating dependencies etc.