Software Management call for RFEs

Jan Zelený jzeleny at redhat.com
Thu May 23 11:47:26 UTC 2013


May I ask what is the use case for this? I'm not sure why would you need to 
deal with individual files instead of the entire packages.

Thanks
Jan

On 23. 5. 2013 at 08:07:21, Dan Fruehauf wrote:
> Reverting changes to files handled by RPM (or installing a single file out
> of the package), for instance:
> rpm -qp some-rpm.rpm --revert/--extract /etc/some-rpm.conf
> /etc/another-file.conf
> 
> I know it can be done with rpm2cpio, just a suggestion to implement it
> natively and extract the files to their correct location.
> 
> On Thu, May 23, 2013 at 7:52 AM, Orion Poplawski <orion at cora.nwra.com>wrote:
> > On 05/22/2013 07:43 AM, Jan Zelený wrote:
> >> Dear Fedora community,
> >> several months ago, at the Developer conference in Brno, Software
> >> Management
> >> team received a whole bunch of proposals for new functionality in RPM and
> >> related software stack.
> >> 
> >> We acknowledge the need for some changes in Software Management stack in
> >> Fedora but we don't want to make changes just by guessing what our
> >> users want. Therefore I call to you, consumers of our products (dnf, yum
> >> and
> >> rpm): what are the changes that you would like to see in the foreseeable
> >> future (say 2-3 years) and why would you like to see them (what would
> >> they
> >> help you with)?
> >> 
> >> There is already a list of some RFEs on rpm.org wiki, you can use it as
> >> an
> >> inspiration, to see what RFEs we have already received:
> >> http://rpm.org/wiki/**FeaturePlanning<http://rpm.org/wiki/FeaturePlanning
> >> >
> >> 
> >> The only limitation for your requests is our manifest which defines the
> >> scope
> >> of SW management stack for the future. It is attached to this email (note
> >> that
> >> it's quite extensive but the first part should give you a good image of
> >> what is
> >> the planned scope of SW management stack).
> >> 
> >> Please send your requests as replies to this email so they can be
> >> properly
> >> discussed.
> >> After your proposals are filed and discussed, all will be evaluated by
> >> our
> >> team and a roadmap with priorities will be created with those selected as
> >> doable and meaningful.
> >> 
> >> Thank you in advance for your participation
> >> Jan
> > 
> > Something I'm just now running into - I have a package that can make use
> > of one of two different backends, but it definitely needs one of them.  I
> > don't want to pick which one in the package.  Also, it is explicitly
> > referencing specific implementations, not a generic interface, so a
> > generic
> > Provides in the backend packages is not appropriate.  But something like:
> > 
> > Requires: ( pkgA || pkgB )
> > 
> > might do the trick.


More information about the devel mailing list