On 19.06.2015 01:26, Sandro Mani wrote:
On 19.06.2015 01:10, T.C. Hollingsworth wrote:
You should instead use the new depdendency generator hooks, which are
also quite a bit nicer to work with. All you have to do is create a
file %{_rpmconfigdir}/fileattrs/openmpi.attrs with something like:
#
On Wed, Jun 17, 2015 at 12:44:29AM +0200, Sandro Mani wrote:
>
>
> On 16.06.2015 17:02, Miloslav Trmač wrote:
> >>On 16.06.2015 00:30, Susi Lehtola wrote:
> >>>On 06/14/2015 03:02 PM, Sandro Mani wrote:
> On 14.06.2015 16:28, Sandro Mani wrote:
> >Rules to generate such requires/provides:
On Fri, Jun 19, 2015 at 2:43 AM, Dominik 'Rathann' Mierzejewski
wrote:
> On Friday, 19 June 2015 at 01:10, T.C. Hollingsworth wrote:
>> # a regular expression that paths in an RPM
>> # must match to trigger the generator
>> %__openmpi_path ^%{_prefix}/lib(64)/(openmpi|mpich)/.*$
>
> Isn't the '.*$
On Friday, 19 June 2015 at 01:10, T.C. Hollingsworth wrote:
[...]
> You should instead use the new depdendency generator hooks, which are
> also quite a bit nicer to work with. All you have to do is create a
> file %{_rpmconfigdir}/fileattrs/openmpi.attrs with something like:
>
> # the path to you
On 19.06.2015 01:10, T.C. Hollingsworth wrote:
You don't have to override the internal dependency generator. In
fact, you really shouldn't because overriding it also overrides
portions of rpm's multilib handling. :-(
Patching find-(requires|provides) in /usr/lib/rpm is also useless, as
mode
On Sun, Jun 14, 2015 at 7:28 AM, Sandro Mani wrote:
> Having had a go at this: if bar{-openmpi} requires foo-{openmpi}, filtering
> the provides from foo-openmpi and adding an explicit requires to bar-openmpi
> on foo-openmpi, this all will result in bar-openmpi depending both on
> foo-openmpi as
- Original Message -
> From: "James Antill"
> To: "Development discussions related to Fedora"
>
> Sent: Tuesday, June 16, 2015 9:16:27 PM
> Subject: Re: DNF vs YUM, $pkg, $pkg-mpi, $pkg-openmpi having same provides
>
> On Fri, 2015-06-12 at 1
On 16.06.2015 17:02, Miloslav Trmač wrote:
On 16.06.2015 00:30, Susi Lehtola wrote:
On 06/14/2015 03:02 PM, Sandro Mani wrote:
On 14.06.2015 16:28, Sandro Mani wrote:
Rules to generate such requires/provides:
* Provides: if the path of the library starts with $MPI_LIB, append
the (openmpi) r
On Fri, 2015-06-12 at 15:09 +0200, Kalev Lember wrote:
> On 06/12/2015 10:28 AM, Radek Holy wrote:
> > If a package "Requires: foo" and both "bar" and "barbaz" "Provides:
> > foo", they are handled as being equally suitable. DNF/libsolv is not
> > going to prefer packages with shorter names.
>
> Y
> On 16.06.2015 00:30, Susi Lehtola wrote:
> > On 06/14/2015 03:02 PM, Sandro Mani wrote:
> >> On 14.06.2015 16:28, Sandro Mani wrote:
> >>> Rules to generate such requires/provides:
> >>> * Provides: if the path of the library starts with $MPI_LIB, append
> >>> the (openmpi) resp (mpich) to the pr
On 16.06.2015 00:30, Susi Lehtola wrote:
On 06/14/2015 03:02 PM, Sandro Mani wrote:
On 14.06.2015 16:28, Sandro Mani wrote:
Rules to generate such requires/provides:
* Provides: if the path of the library starts with $MPI_LIB, append
the (openmpi) resp (mpich) to the provides string
* Require
On 06/14/2015 03:02 PM, Sandro Mani wrote:
On 14.06.2015 16:28, Sandro Mani wrote:
Rules to generate such requires/provides:
* Provides: if the path of the library starts with $MPI_LIB, append
the (openmpi) resp (mpich) to the provides string
* Requires: if the path of the scanned object starts
On 06/12/2015 06:34 AM, Orion Poplawski wrote:
On 06/11/2015 10:01 AM, Sandro Mani wrote:
So, whose fault is this? Packaging of dnf? Nothing relevant for this
caught my eye skimming through the packaging guidelines.
And related: trying to install some $pkg-openmpi package, I don't
generally see
- Original Message -
> From: "Dennis Jacobfeuerborn"
> To: devel@lists.fedoraproject.org
> Sent: Saturday, June 13, 2015 12:30:39 PM
> Subject: Re: DNF vs YUM, $pkg, $pkg-mpi, $pkg-openmpi having same provides
>
> On 12.06.2015 15:25, Radek Holy wrote:
W dniu 13.06.2015 o 12:30, Dennis Jacobfeuerborn pisze:
On 12.06.2015 15:25, Radek Holy wrote:
What I feel would be a good solution to the problem above would be to
have a way to specify the default. I believe this problem is already
solved in apt-get with a very nice syntax: the OR syntax:
R
On 14.06.2015 16:28, Sandro Mani wrote:
I was rather thinking, is there an obvious disadvantage in having a
{mpich,openmpi}-find-requires.sh script which encodes the mpi flavour
in the provides/requires? I.e.
libfoo.so.0()(64bit)(openmpi)
Rules to generate such requires/provides:
* Provid
On 12.06.2015 15:34, Orion Poplawski wrote:
On 06/11/2015 10:01 AM, Sandro Mani wrote:
Hello,
Investigating bug #1230838, I noticed that when installing mmg3d-libs,
dnf installs Konsole output ptscotch-mpich, whereas yum-deprecated
installs scotch. Both scotch and ptscotch-mpich provide the
On 12.06.2015 15:25, Radek Holy wrote:
>
>
> - Original Message -
>> From: "Kalev Lember"
>> To: "Development discussions related to Fedora"
>>
>> Sent: Friday, June 12, 2015 3:09:50 PM
>> Subject: Re: DNF vs YUM, $pkg, $pkg
On 12.06.2015 15:34, Orion Poplawski wrote:
On 06/11/2015 10:01 AM, Sandro Mani wrote:
Hello,
Investigating bug #1230838, I noticed that when installing mmg3d-libs,
dnf installs Konsole output ptscotch-mpich, whereas yum-deprecated
installs scotch. Both scotch and ptscotch-mpich provide the
On 06/11/2015 10:01 AM, Sandro Mani wrote:
Hello,
Investigating bug #1230838, I noticed that when installing mmg3d-libs,
dnf installs Konsole output ptscotch-mpich, whereas yum-deprecated
installs scotch. Both scotch and ptscotch-mpich provide the required
libscotch.so.0()(64bit), albeit one in
- Original Message -
> From: "Kalev Lember"
> To: "Development discussions related to Fedora"
>
> Sent: Friday, June 12, 2015 3:09:50 PM
> Subject: Re: DNF vs YUM, $pkg, $pkg-mpi, $pkg-openmpi having same provides
>
> On 06/12/2015 10:
On 06/12/2015 10:28 AM, Radek Holy wrote:
If a package "Requires: foo" and both "bar" and "barbaz" "Provides:
foo", they are handled as being equally suitable. DNF/libsolv is not
going to prefer packages with shorter names.
Yes, very much agreed here. Please don't add the yum shortest name hack
On 11.06.2015 22:15, Susi Lehtola wrote:
On 06/11/2015 09:01 AM, Sandro Mani wrote:
So, whose fault is this? Packaging of dnf? Nothing relevant for this
caught my eye skimming through the packaging guidelines.
I think this is dnf's fault. YUm didn't have the same problem, since
if multiple
- Original Message -
> From: "Sandro Mani"
> To: "Development discussions related to Fedora"
>
> Sent: Friday, June 12, 2015 10:40:40 AM
> Subject: Re: DNF vs YUM, $pkg, $pkg-mpi, $pkg-openmpi having same provides
> On 12.06.2015 10:28, Radek H
On 12.06.2015 10:28, Radek Holy wrote:
*From: *"Sandro Mani"
*To: *"Development discussions related to Fedora"
*Sent: *Thursday, June 11, 2015 6:01:12 PM
*Subject: *DNF vs
- Original Message -
> From: "Sandro Mani"
> To: "Development discussions related to Fedora"
>
> Sent: Thursday, June 11, 2015 6:01:12 PM
> Subject: DNF vs YUM, $pkg, $pkg-mpi, $pkg-openmpi having same provides
> Hello,
> Investigating bug
On 06/11/2015 09:01 AM, Sandro Mani wrote:
So, whose fault is this? Packaging of dnf? Nothing relevant for this
caught my eye skimming through the packaging guidelines.
I think this is dnf's fault. YUm didn't have the same problem, since if
multiple packages provided the necessary library, yum
Hello,
Investigating bug #1230838, I noticed that when installing mmg3d-libs,
dnf installs Konsole output ptscotch-mpich, whereas yum-deprecated
installs scotch. Both scotch and ptscotch-mpich provide the required
libscotch.so.0()(64bit), albeit one in /usr/lib64/ and the other one in
/usr/l
28 matches
Mail list logo
