Hi,
I would like better integration with domain-specific package managers.
By which I mean npm (for node.js), gem (for ruby), pip (for python),
cpan (for perl), pecl/pear (for PHP), CRAN (for R), CTAN (for TeX), and
many more I'm sure.
By integrating RPM with these package managers, I feel it
On 05/22/2013 11:18 PM, Richard W.M. Jones wrote:
(5) Almost all %pre/%post scripts need to be eliminated. There's no
reason that RPM can't detect when a shared library is being installed.
I'd like to see this for the configuration of the source tree during the
build process (up to and
On 22. 5. 2013 at 23:16:16, Christopher Meng wrote:
What about speeding up the yum running?
It's a bit slow now.
Have you tried using dnf instead of yum? It is much faster.
To be perfectly honest we don't plan to invest much effort in developing new
things for yum, it will more and more
On 22. 5. 2013 at 08:38:35, John Reiser wrote:
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)?
Feature:
On 22. 5. 2013 at 12:47:58, Paulo César Pereira de Andrade wrote:
2013/5/22 Jan Zelený jzel...@redhat.com:
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
On 05/22/2013 08:22 PM, Nicolas Mailhot wrote:
Hi,
Please clean up the distaster package verification is.
rpm -Va is so incomplete it spawned rpmlint, package-cleanup and not doubt
others I forget about.
There's probably some overlap in what those utilities do but generally I
see them as
On 22. 5. 2013 at 10:55:14, Michael Ekstrand wrote:
Performance improvement: improve scaling to 5K+ installed packages.
Since the TeXLive repackaging, my laptop several thousand packages,
about half of which are TeX-related (I like to have a fairly full TeX
install with all the docs). There
On 22. 5. 2013 at 11:17:16, Ravindra Kumar wrote:
I don't know if this feature already exists, so forgive my
ignorance if it is already there.
I think having an RPM equivalent of Systemd's
ConditionVirtualization will be very useful
for controlling packages that are intended for
On 22. 5. 2013 at 21:06:53, Björn Persson wrote:
Jan Zelený wrote:
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)?
Dare I say ... (puts on a helmet) ... Recommends and Suggests?
Hello,
On 22 May 2013 23:18, Richard W.M. Jones rjo...@redhat.com wrote:
(10) Get rid of multilib, /usr/lib64 etc and copy what Debian/Ubuntu
are doing.
might I ask the reasoning behind this? I found the current RHEL/Fedora
approach much better.
For example; at work we use IBM Lotus Notes,
Since you have already sent the email, all those requests that make sense are
in one way or another on the list of RFEs I referred to. If you are missing
something there, feel free to let me know.
Thanks
Jan
On 22. 5. 2013 at 22:18:58, Richard W.M. Jones wrote:
[This is a copy of an email I
On 22. 5. 2013 at 17:08:33, Rahul Sundaram wrote:
Hi
On Wed, May 22, 2013 at 9:43 AM, Jan Zelený wrote:
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,
On 23. 5. 2013 at 13:33:37, Simone Caronni wrote:
Hello,
On 22 May 2013 23:18, Richard W.M. Jones rjo...@redhat.com wrote:
(10) Get rid of multilib, /usr/lib64 etc and copy what Debian/Ubuntu
are doing.
might I ask the reasoning behind this? I found the current RHEL/Fedora
approach
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
On 22. 5. 2013 at 16:55:50, Orion Poplawski wrote:
On 05/22/2013 04:44 PM, Adam Williamson wrote:
On Wed, 2013-05-22 at 23:30 +0100, Richard W.M. Jones wrote:
different set of dependent packages, leading to some sort of
combinatorial explosion of QA.
Right now we have approximately
On 23 May 2013 13:47, Jan Zelený jzel...@redhat.com wrote:
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.
Maybe to reinstall one default config file out of a package that contains
some? I found it useful.
On 23 May 2013 13:44, Jan Zelený jzel...@redhat.com wrote:
+1 for this, the dependency hell for 32 bit applications is really a major
pain in the new versions of Ubuntu. I have dealt with that multiple times
and
I wasn't able to resolve all the problems (e.g. Google Earth still doesn't
work
On 23. 5. 2013 at 10:53:10, Stijn Hoop wrote:
Hi,
I would like better integration with domain-specific package managers.
By which I mean npm (for node.js), gem (for ruby), pip (for python),
cpan (for perl), pecl/pear (for PHP), CRAN (for R), CTAN (for TeX), and
many more I'm sure.
The
On 05/23/2013 01:33 PM, Simone Caronni wrote:
On 22 May 2013 23:18, Richard W.M. Jones wrote:
(10) Get rid of multilib, /usr/lib64 etc and copy what Debian/Ubuntu
are doing.
might I ask the reasoning behind this? I found the current RHEL/Fedora
approach much better.
For example; at
On 05/23/2013 01:44 PM, Jan Zelený wrote:
+1 for this, the dependency hell for 32 bit applications is really a major
pain in the new versions of Ubuntu. I have dealt with that multiple times and
I wasn't able to resolve all the problems (e.g. Google Earth still doesn't
work on Ubuntu for me)
On Thu, May 23, 2013 at 01:33:37PM +0200, Simone Caronni wrote:
might I ask the reasoning behind this? I found the current RHEL/Fedora
approach much better.
Debian (since 7?) has settled on using subdirectories of /usr/lib for
different architectures. See:
http://wiki.debian.org/Multiarch
It
On 23. 5. 2013 at 14:23:30, Michal Schmidt wrote:
On 05/23/2013 01:44 PM, Jan Zelený wrote:
+1 for this, the dependency hell for 32 bit applications is really a major
pain in the new versions of Ubuntu. I have dealt with that multiple times
and I wasn't able to resolve all the problems
On 23. 5. 2013 at 13:52:39, Simone Caronni wrote:
On 23 May 2013 13:47, Jan Zelený jzel...@redhat.com wrote:
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.
Maybe to reinstall one default config file
On 05/23/2013 06:21 AM, Jan Zelený wrote:
On 22. 5. 2013 at 10:55:14, Michael Ekstrand wrote:
Performance improvement: improve scaling to 5K+ installed packages.
Since the TeXLive repackaging, my laptop several thousand packages,
about half of which are TeX-related (I like to have a fairly
On 05/23/2013 03:10 PM, Jan Zelený wrote:
On 23. 5. 2013 at 14:23:30, Michal Schmidt wrote:
On 05/23/2013 01:44 PM, Jan Zelený wrote:
+1 for this, the dependency hell for 32 bit applications is really a major
pain in the new versions of Ubuntu. I have dealt with that multiple times
and I
On 23. 5. 2013 at 15:25:23, Michal Schmidt wrote:
On 05/23/2013 03:10 PM, Jan Zelený wrote:
On 23. 5. 2013 at 14:23:30, Michal Schmidt wrote:
On 05/23/2013 01:44 PM, Jan Zelený wrote:
+1 for this, the dependency hell for 32 bit applications is really a
major
pain in the new versions of
On 23 May 2013 14:58, Richard W.M. Jones rjo...@redhat.com wrote:
Debian (since 7?) has settled on using subdirectories of /usr/lib for
different architectures. See:
http://wiki.debian.org/Multiarch
It supports more than just 64 bit or not, such as different kernels,
different endianness,
On Thu, 23 May 2013 14:02:34 +0200
Jan Zelený jzel...@redhat.com wrote:
On 23. 5. 2013 at 10:53:10, Stijn Hoop wrote:
I would like better integration with domain-specific package
managers. By which I mean npm (for node.js), gem (for ruby), pip
(for python), cpan (for perl), pecl/pear (for
Le Jeu 23 mai 2013 13:20, Panu Matilainen a écrit :
On 05/22/2013 08:22 PM, Nicolas Mailhot wrote:
Hi,
Please clean up the distaster package verification is.
rpm -Va is so incomplete it spawned rpmlint, package-cleanup and not
doubt
others I forget about.
There's probably some overlap
Le Jeu 23 mai 2013 01:28, Ravindra Kumar a écrit :
Having a fake package in DB makes it very static. I think a
dynamic (evaluated each time rpm commands are run) implementation
will be more useful for the cases like P2V and V2V.
The problem I see here is that you can boot the same OS on
Hi,
I would also like solid proxy support in the software management stack.
Metadata that is designed (as per the HTTP RFCS) to be cached cleanly and
an updater that does not assume all repository mirrors are perfectly in
sync at any given point in time
Regards,
--
Nicolas Mailhot
--
devel
From: Rahul Sundaram methe...@gmail.com
What I would like to see is
solid git integration. Git has become the standard distributed vcs
and github and google code etc have stopped hosting tarballs and/or
discouraging it and GNOME is planning to do that as well. If Source
URL could point
On Thu, May 23, 2013 at 03:29:16PM +0200, Simone Caronni wrote:
I'm not the best person to judge, but it looks overcomplicated to me. For
sure existing commercial binary packages shipped in RPM format will have a
lot of problems.
For the vast majority of packages, it simply means the library
On 23. 5. 2013 at 15:30:55, Stijn Hoop wrote:
On Thu, 23 May 2013 14:02:34 +0200
Jan Zelený jzel...@redhat.com wrote:
On 23. 5. 2013 at 10:53:10, Stijn Hoop wrote:
I would like better integration with domain-specific package
managers. By which I mean npm (for node.js), gem (for ruby),
Hi,
I'd also like support for tuple provides, to expose font font facets to
the software updater.
For example, a font file can provide a 'bold' variant with support for a
list of locales.
Right now if I ask rpm to install a bold sans-serif font for russian for
example, it will happily install a
AIUI it would mainly involve *removing* the big hack that is
multilib from rpm.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into
On 05/23/2013 02:58 PM, Richard W.M. Jones wrote:
The reason I specifically said:
On 22 May 2013 23:18, Richard W.M. Jones rjo...@redhat.com wrote:
(10) Get rid of multilib, /usr/lib64 etc and copy what Debian/Ubuntu
are doing.
is that Debian and derivatives are more popular than Fedora and
On Thu, May 23, 2013 at 4:23 PM, Vít Ondruch vondr...@redhat.com wrote:
*It is not possible to convert the packages technically nor
philosophically*
You might think million times that the sentence is not truth, but that is
as it is. I'll give you several examples:
* Gems cannot express
On 05/23/2013 03:30 PM, Stijn Hoop wrote:
On Thu, 23 May 2013 14:02:34 +0200
Jan Zelený jzel...@redhat.com wrote:
The problem is that some of these languages have fundamentally
different philosophy than Fedora and unfortunatelly it's not a
mix-and-match situation. That being said, there
On Thu, May 23, 2013 at 04:24:01PM +0200, Florian Weimer wrote:
Some of the rationale for multiarch doesn't make much sense anymore.
For example, you can now use IFUNCs to select specialized functions
at run time and don't have to ship separate DSOs anymore.
IFUNCs are indeed interesting. An
Dne 23.5.2013 16:29, Miloslav Trmač napsal(a):
On Thu, May 23, 2013 at 4:23 PM, Vít Ondruch vondr...@redhat.com
mailto:vondr...@redhat.com wrote:
*It is not possible to convert the packages technically nor
philosophically*
You might think million times that the sentence is not
john.flor...@dart.biz wrote:
From: Rahul Sundaram methe...@gmail.com
What I would like to see is
solid git integration. Git has become the standard distributed vcs
and github and google code etc have stopped hosting tarballs and/or
discouraging it and GNOME is planning to do that as well. If
On 05/23/2013 04:47 PM, Paul Flo Williams wrote:
john.flor...@dart.biz wrote:
From: Rahul Sundaram methe...@gmail.com
What I would like to see is
solid git integration. Git has become the standard distributed vcs
and github and google code etc have stopped hosting tarballs and/or
discouraging
From: pknir...@redhat.com
On 05/23/2013 04:47 PM, Paul Flo Williams wrote:
john.flor...@dart.biz wrote:
From: Rahul Sundaram methe...@gmail.com
What I would like to see is
solid git integration. Git has become the standard distributed vcs
and github and google code etc have stopped
On Thu, 2013-05-23 at 16:54 +0200, Phil Knirsch wrote:
But rpm could just do a git-tar-tree behind the scenes, which sounds
easy enough.
It's not quite that easy, given the possible presence of git
submodules.
On 05/23/2013 06:09 PM, john.flor...@dart.biz wrote:
From: pknir...@redhat.com
On 05/23/2013 04:47 PM, Paul Flo Williams wrote:
john.flor...@dart.biz wrote:
From: Rahul Sundaram methe...@gmail.com
What I would like to see is
solid git integration. Git has become the standard
On Wed, 2013-05-22 at 16:55 -0600, Orion Poplawski wrote:
I'll get more specific then:
python-pyface can use two different graphics backends - either wxPython or
pyQt4. In no way do these two packages provide the same thing in any
meaningful way other than to pyface. So, while one could
On Thu, 2013-05-23 at 13:52 +0200, Simone Caronni wrote:
On 23 May 2013 13:47, Jan Zelený jzel...@redhat.com wrote:
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.
Maybe to reinstall one default
Am 22.05.2013 20:17, schrieb Ravindra Kumar:
I don't know if this feature already exists, so forgive my
ignorance if it is already there.
I think having an RPM equivalent of Systemd's
ConditionVirtualization will be very useful
for controlling packages that are intended for
virtualized
From: pmati...@laiskiainen.org
On 05/23/2013 06:09 PM, john.flor...@dart.biz wrote:
And even though I have to give rpmbuild a tarball, I don't
believe it ever reuses it as is. My understanding is that the
content
gets extracted, processed and tarballed again.
I dont know what gave you
or skip manpages/docfiles as default or at least
controlled by a option in yum.conf
tsflags=nodocs in yum.conf should do the job. Though apparently, if enabled
after packages already installed files in doc, the files in doc won't be
removed anymore when uninstalling the package.
--
devel
On 23 May 2013 17:38, James Antill ja...@fedoraproject.org wrote:
On Thu, 2013-05-23 at 13:52 +0200, Simone Caronni wrote:
mv /etc/nagios/nagios.cfg /etc/nagios/nagios.cfg.mine
yum reinstall nagios --onlyfile /etc/nagios/nagios.cfg
How is this functionally different from yum reinstall
On Thu, May 23, 2013 at 03:13:30PM +0200, Jan Zelený wrote:
On 23. 5. 2013 at 13:52:39, Simone Caronni wrote:
I fiddle around with a new Nagios installation, then something stops
working. I'm pretty sure it is some modifications in /etc/nagios/nagios.cfg
but I cannot track it down.
As an
2013-05-23 00:30, Richard W.M. Jones skrev:
On Wed, May 22, 2013 at 03:52:22PM -0600, Orion Poplawski wrote:
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
On 23 May 2013, at 01:27, Björn Persson wrote:
Adam Williamson wrote:
On Thu, 2013-05-23 at 02:20 +0300, Oron Peled wrote:
Thinking about it, the terminology adopted by comps is clearer
and provides a generalization of this -- if someone select something
they get:
- Mandatory packages
Am 23.05.2013 18:05, schrieb Sandro Mani:
or skip manpages/docfiles as default or at least
controlled by a option in yum.conf
tsflags=nodocs in yum.conf should do the job. Though apparently, if enabled
after packages already installed files
in doc, the files in doc won't be
No, I was not thinking of reboot/RPM changing anything already
installed. I was referring to DB solution as static because
it would stick one configuration forever. Instead, I was
thinking of RPM to always base its decision on the environment
where it is running at that point of time and
On 05/23/2013 08:32 PM, Reindl Harald wrote:
Am 23.05.2013 18:05, schrieb Sandro Mani:
or skip manpages/docfiles as default or at least
controlled by a option in yum.conf
tsflags=nodocs in yum.conf should do the job. Though apparently, if enabled
after packages already installed
Yum's tsflags=nodocs aka --excludedocs on rpm cli only applies to
package installation. I fail to see how it could cause files to be
left behind on erasure/update (reinstall might be a bit, uh, special
though), but if it does then please file a bug on rpm with exact
reproducer steps.
-
2013/5/22 Björn Persson bj...@xn--rombobjrn-67a.se:
Jan Zelený wrote:
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)?
Dare I say ... (puts on a helmet) ... Recommends and Suggests?
and apparently also not at updates and also not by yum reinstall
which leaves no clean way to get rid if it and additionally
i am not sure if tsflags=nodocs also avoids /usr/share/man
and not only /usr/share/doc
No it does not avoid man, but you could mount a null-filesystem such as
[1] to
On 05/23/2013 09:51 PM, Sandro Mani wrote:
and apparently also not at updates and also not by yum reinstall
which leaves no clean way to get rid if it and additionally
i am not sure if tsflags=nodocs also avoids /usr/share/man
and not only /usr/share/doc
No it does not avoid man, but you
On 23.05.2013 20:59, Panu Matilainen wrote:
On 05/23/2013 09:51 PM, Sandro Mani wrote:
and apparently also not at updates and also not by yum reinstall
which leaves no clean way to get rid if it and additionally
i am not sure if tsflags=nodocs also avoids /usr/share/man
and not only
Am 23.05.2013 19:48, schrieb Panu Matilainen:
On 05/23/2013 08:32 PM, Reindl Harald wrote:
Am 23.05.2013 18:05, schrieb Sandro Mani:
or skip manpages/docfiles as default or at least
controlled by a option in yum.conf
tsflags=nodocs in yum.conf should do the job. Though
Am 23.05.2013 20:32, schrieb Sandro Mani:
Yum's tsflags=nodocs aka --excludedocs on rpm cli only applies to package
installation. I fail to see how it
could cause files to be left behind on erasure/update (reinstall might be a
bit, uh, special though), but if it
does then please file a
Am 23.05.2013 20:51, schrieb Sandro Mani:
and apparently also not at updates and also not by yum reinstall
which leaves no clean way to get rid if it and additionally
i am not sure if tsflags=nodocs also avoids /usr/share/man
and not only /usr/share/doc
No it does not avoid man, but you
On 05/23/2013 09:34 AM, James Antill wrote:
On Wed, 2013-05-22 at 16:55 -0600, Orion Poplawski wrote:
I'll get more specific then:
python-pyface can use two different graphics backends - either wxPython or
pyQt4. In no way do these two packages provide the same thing in any
meaningful way
On 05/23/2013 06:05 PM, Simone Caronni wrote:
On 23 May 2013 17:38, James Antill ja...@fedoraproject.org
mailto:ja...@fedoraproject.org wrote:
On Thu, 2013-05-23 at 13:52 +0200, Simone Caronni wrote:
mv /etc/nagios/nagios.cfg /etc/nagios/nagios.cfg.mine
yum reinstall nagios
I'd definitely add a big +1 to Dependency cleaner!
Thanks,
Sandro
On Wed, May 22, 2013 at 3:43 PM, Jan Zelený jzel...@redhat.com wrote:
Dear Fedora community,
several months ago, at the Developer conference in Brno, Software
Management
team received a whole bunch of proposals for new
What about speeding up the yum running?
It's a bit slow now.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
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)?
Feature: facility for atomic upgrade of an entire set of
2013/5/22 Jan Zelený jzel...@redhat.com:
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.
As a packager, some way to transparently handle an
Performance improvement: improve scaling to 5K+ installed packages.
Since the TeXLive repackaging, my laptop several thousand packages,
about half of which are TeX-related (I like to have a fairly full TeX
install with all the docs). There are two noticable problems: yum slows
down considerably
On 05/22/2013 11:16 AM, Christopher Meng wrote:
What about speeding up the yum running?
It's a bit slow now.
+1, and what's worse it tends to significantly degrade as it collects
more history in its databases. Most of my systems have multiple repos:
fedora, rpmfusion-{free,nonfree} and their
Hi,
Please clean up the distaster package verification is.
rpm -Va is so incomplete it spawned rpmlint, package-cleanup and not doubt
others I forget about.
Even for the most basic checks its output is so useless and difficul to
parse we've seen a critical path package like gdm shipped with the
I don't know if this feature already exists, so forgive my
ignorance if it is already there.
I think having an RPM equivalent of Systemd's
ConditionVirtualization will be very useful
for controlling packages that are intended for
virtualized environments. It could gracefully
warn users about
Paulo César Pereira de Andrade wrote:
As an user, some way to, but mostly adding some policy, to have multiple
sonames of a library installed. Usually only useful to avoid a window of time
with broken dependencies, but sometimes useful to have some package
that only works with an older
On Wed, 2013-05-22 at 20:33 +0200, Björn Persson wrote:
Paulo César Pereira de Andrade wrote:
As an user, some way to, but mostly adding some policy, to have multiple
sonames of a library installed. Usually only useful to avoid a window of
time
with broken dependencies, but sometimes
Jan Zelený wrote:
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)?
Dare I say ... (puts on a helmet) ... Recommends and Suggests?
We really should have a way for Yum and Packagekit
Hi
On Wed, May 22, 2013 at 9:43 AM, Jan Zelený wrote:
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
[This is a copy of an email I sent to an internal Red Hat list last month]
In no particular order:
(1) Yum should not be so slow. In particular yum install takes ages
compared to apt-get install. I don't want to argue about how yum
has to download metadata or whatever, the fact of the matter
On Wed, 2013-05-22 at 22:18 +0100, Richard W.M. Jones wrote:
[...snip various points I agree with...]
(3) RPM's spec file format needs to be redone using a Real Parser. At
the moment it has all sorts of strange corner cases (for example, how
to define a macro containing an arch-dependent
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
Le mercredi 22 mai 2013 à 22:18 +0100, Richard W.M. Jones a écrit :
(3) RPM's spec file format needs to be redone using a Real Parser. At
the moment it has all sorts of strange corner cases (for example, how
to define a macro containing an arch-dependent list?). It'd be a good
opportunity to
Le mercredi 22 mai 2013 à 11:17 -0700, Ravindra Kumar a écrit :
I don't know if this feature already exists, so forgive my
ignorance if it is already there.
I think having an RPM equivalent of Systemd's
ConditionVirtualization will be very useful
for controlling packages that are intended
Le mercredi 22 mai 2013 à 21:06 +0200, Björn Persson a écrit :
Jan Zelený wrote:
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)?
Dare I say ... (puts on a helmet) ...
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
libsolv/yast does it ( if I understood correctly ).You can have some
virtual provides that exist as fake packages in the db, and then have a
package have a requires on it. So it cannot be installed if the hardware
is not here.
Having a fake package in DB makes it very static. I think a
On Wed, May 22, 2013 at 03:16:55PM -0700, Ravindra Kumar wrote:
libsolv/yast does it ( if I understood correctly ).You can have some
virtual provides that exist as fake packages in the db, and then have a
package have a requires on it. So it cannot be installed if the hardware
is not here.
On Wed, May 22, 2013 at 11:55:43PM +0200, Michael Scherer wrote:
Le mercredi 22 mai 2013 à 21:06 +0200, Björn Persson a écrit :
Jan Zelený wrote:
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
On Wed, May 22, 2013 at 03:52:22PM -0600, Orion Poplawski wrote:
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
On Wed, 2013-05-22 at 23:30 +0100, Richard W.M. Jones wrote:
different set of dependent packages, leading to some sort of
combinatorial explosion of QA.
Right now we have approximately seven zillion combinatorial explosions
of QA, so one more on the pile is not going to make much of an
On 05/22/2013 04:44 PM, Adam Williamson wrote:
On Wed, 2013-05-22 at 23:30 +0100, Richard W.M. Jones wrote:
different set of dependent packages, leading to some sort of
combinatorial explosion of QA.
Right now we have approximately seven zillion combinatorial explosions
of QA, so one more on
On 23.05.2013 00:55, Orion Poplawski wrote:
I'll get more specific then:
python-pyface can use two different graphics backends - either
wxPython or pyQt4. In no way do these two packages provide the same
thing in any meaningful way other than to pyface. So, while one could
go the provides
On Wednesday 22 May 2013 23:33:05 Richard W.M. Jones wrote:
TBH I don't think we need Suggests AND Recommends. I can never
remember the difference on Debian. Wouldn't most people would be
satisfied with a single way to suggest useful packages?
Thinking about it, the terminology adopted by
On Thu, 2013-05-23 at 02:20 +0300, Oron Peled wrote:
On Wednesday 22 May 2013 23:33:05 Richard W.M. Jones wrote:
TBH I don't think we need Suggests AND Recommends. I can never
remember the difference on Debian. Wouldn't most people would be
satisfied with a single way to suggest useful
Having a fake package in DB makes it very static. I think a
dynamic (evaluated each time rpm commands are run) implementation
will be more useful for the cases like P2V and V2V.
The problem I see here is that you can boot the same OS on different
hypervisors or (with P2V) transfer it from
Adam Williamson wrote:
On Thu, 2013-05-23 at 02:20 +0300, Oron Peled wrote:
Thinking about it, the terminology adopted by comps is clearer
and provides a generalization of this -- if someone select something
they get:
- Mandatory packages (cannot be deselected)
- Default packages
Michael Scherer wrote:
Without explaining why a package is suggested or recommended, people
cannot make informed choice on it.
In all of the examples I mentioned the reason would be pretty obvious
once you know that the recommended package exists. If you're not sure
whether you want a
101 - 199 of 199 matches
Mail list logo
