7:38 a.m.
Hello again,
I have updated the MPI draft at
https://fedoraproject.org/wiki/PackagingDrafts/MPI
to take into account the comments that araised in discussion on the
list.
As I have been dealing with quite a few Fortran packages I have realized
that the current laissez-faire mentality may not be enough and a
standard is needed for file placement.
https://fedoraproject.org/wiki/PackagingDrafts/Fortran
As before, comments are welcome.
--
Jussi Lehtola
Fedora Project Contributor
jussilehtola(a)fedoraproject.org
10:22 a.m.
On 26.7.2009 14:38, Jussi Lehtola wrote:
Hello again,
I have updated the MPI draft at
https://fedoraproject.org/wiki/PackagingDrafts/MPI
to take into account the comments that araised in discussion on the
list.
Looks great, just three minor comments:
1) Shouldn't the suffix for OpenMPI be just "openmpi" instead of
"mpi"?
It would be consistent with other suffixes (simply the %{name} of the
compiler package) and self-explanatory what implementation it is.
2) With the current directory layout (i.e. a FHS-friendly one), the
suffixes for binaries and libraries are not necessary anymore, am I
right? In that case I think they are even not desirable (what MPI
implementation (or no MPI) is used will be controlled by the
environment-modules so this would be just annoying when writing e.g.
scripts using MPI software etc.)
3) I've modified the draft with a SHOULD: split headers into
%{name}-headers. In this case %{name}-%{mpi}-devel needs to require only
%{name}-headers (otherwise %{name}-devel will pull in %{name}
unnecessarily). In my POV this could be even a MUST (the depedency on
the non-MPI build is really not needed). Please review the wiki diff
from its history!
Thanks for your effort!
Milos
11:19 a.m.
On Sun, Jul 26, 2009 at 03:38:57PM +0300, Jussi Lehtola wrote:
Hello again,
As I have been dealing with quite a few Fortran packages I have realized
that the current laissez-faire mentality may not be enough and a
standard is needed for file placement.
https://fedoraproject.org/wiki/PackagingDrafts/Fortran
Unless I don't recall well,
https://fedoraproject.org/wiki/PackagingDrafts/FortranModulesDir
was accepted as a guideline.
I think that instead of a new guideline, the current should be improved.
More precisely I think that the placement of .mod files should always be
below %_fmoddir, and putting them right in %_fmoddir or below a subdirectory
should be left to the packager, with a word telling that a subdirectory
should be used if one of the a .mod file installed name is too generic.
That way, .mod files rightly named will be used without adding any flag
while those that can clash (or those that are to be installed in parallel)
can be below a subdirectory.
--
Pat
11:34 a.m.
Quoting "Patrice Dumas" <pertusus(a)free.fr>:
On Sun, Jul 26, 2009 at 03:38:57PM +0300, Jussi Lehtola wrote:
> As I have been dealing with quite a few Fortran packages I have realized
> that the current laissez-faire mentality may not be enough and a
> standard is needed for file placement.
> https://fedoraproject.org/wiki/PackagingDrafts/Fortran
Unless I don't recall well,
https://fedoraproject.org/wiki/PackagingDrafts/FortranModulesDir
was accepted as a guideline.
That would explain the existence of %{_fmoddir} in RPM and %configure.
But why is it still in PackagingDrafts?
I think that instead of a new guideline, the current should be
improved.
More precisely I think that the placement of .mod files should always be
below %_fmoddir, and putting them right in %_fmoddir or below a subdirectory
should be left to the packager, with a word telling that a subdirectory
should be used if one of the a .mod file installed name is too generic.
That way, .mod files rightly named will be used without adding any flag
while those that can clash (or those that are to be installed in parallel)
can be below a subdirectory.
Yes. However, there is still the issue about the include files - where
should they be placed? %{_fmoddir} could be also used for this.
--
Jussi Lehtola
Fedora Project Contributor
jussilehtola(a)fedoraproject.org
11:40 a.m.
On Sun, Jul 26, 2009 at 07:34:41PM +0300, Jussi Lehtola wrote:
Quoting "Patrice Dumas" <pertusus(a)free.fr>:
That would explain the existence of %{_fmoddir} in RPM and %configure.
But why is it still in PackagingDrafts?
I don't know.
Yes. However, there is still the issue about the include files -
where
should they be placed? %{_fmoddir} could be also used for this.
No, _fmoddir is arch specific while include files are not. I think that
they should simply be placed below %_includedir. I am not sure that
it would be right to have them in a specific location since c++ files
are also in %_includedir.
--
Pat
noon
Quoting "Milos Jakubicek" <xjakub(a)fi.muni.cz>:
On 26.7.2009 14:38, Jussi Lehtola wrote:
> Hello again,
>
>
> I have updated the MPI draft at
> https://fedoraproject.org/wiki/PackagingDrafts/MPI
> to take into account the comments that araised in discussion on the
> list.
Looks great, just three minor comments:
1) Shouldn't the suffix for OpenMPI be just "openmpi" instead of
"mpi"? It would be consistent with other suffixes (simply the
%{name} of the compiler package) and self-explanatory what
implementation it is.
Yes, that would be more consistent. However, it would break
compatibility with the current naming of apps and users would have to
re-learn the names of the binaries :)
Also, I'd like to stress OpenMPI since AFAIK it is, all in all, the
best implementation out there.
But, as the interface to the whole MPI stack is going to change
anyway, it is maybe better to change to a consistent naming right
away. Changed.
2) With the current directory layout (i.e. a FHS-friendly one), the
suffixes for binaries and libraries are not necessary anymore, am I
right? In that case I think they are even not desirable (what MPI
implementation (or no MPI) is used will be controlled by the
environment-modules so this would be just annoying when writing e.g.
scripts using MPI software etc.)
IMHO having the suffix is still better, that way you can run the
serial version as well if you need it for something.
In scripts this is very easy, as you can use ${MPI_SUFFIX} e.g.
#!/bin/bash
# Load LAM
#module load lam-x86_64
# Load Open MPI
module load openmpi-x86_64
# Load MPICH2
#module load mpich2-x86_64
# Preprocess in serial mode
foo < foo.in
# Run calculation
mpirun -np 4 foo${MPI_SUFFIX}
# Run more processing
mpirun -np 4 bar${MPI_SUFFIX}
3) I've modified the draft with a SHOULD: split headers into
%{name}-headers. In this case %{name}-%{mpi}-devel needs to require
only %{name}-headers (otherwise %{name}-devel will pull in %{name}
unnecessarily). In my POV this could be even a MUST (the depedency
on the non-MPI build is really not needed). Please review the wiki
diff from its history!
OK, this is in case the headers are the same in all of the cases.
--
Jussi Lehtola
Fedora Project Contributor
jussilehtola(a)fedoraproject.org
2:12 p.m.
On 26.7.2009 18:40, Patrice Dumas wrote:
On Sun, Jul 26, 2009 at 07:34:41PM +0300, Jussi Lehtola wrote:
> Quoting "Patrice Dumas"<pertusus(a)free.fr>:
>
> That would explain the existence of %{_fmoddir} in RPM and %configure.
> But why is it still in PackagingDrafts?
I don't know.
It's a pain that this happens pretty often. I accidentally started a
long flame some time ago when I just asked about the status of The Flags
Draft, most people did not know it has been already approved.
Would it be possible for somebody from the Packaging Committee to check
all the current content of PackagingDrafts/* for drafts that have been
already approved? (And move them of course.)
Thanks in advance for taking time for this, I know its annoying but I
think that it will take much less time for members of the Packaging
Committee than for anybody else to do this!
Milos
2:22 p.m.
On 07/26/2009 02:12 PM, Milos Jakubicek wrote:
Would it be possible for somebody from the Packaging Committee to
check
all the current content of PackagingDrafts/* for drafts that have been
already approved? (And move them of course.)
To be clear (and as I understand things), the mere presence of something
in PackagingDrafts in no way speaks to whether something has been
approved or not.
However, in a perfect world, ratified proposals could be marked as such
or moved from PackagingDrafts, agreed.
-- Rex
11:18 a.m.
On Sun, 2009-07-26 at 18:19 +0200, Patrice Dumas wrote:
On Sun, Jul 26, 2009 at 03:38:57PM +0300, Jussi Lehtola wrote:
> Hello again,
>
>
> As I have been dealing with quite a few Fortran packages I have realized
> that the current laissez-faire mentality may not be enough and a
> standard is needed for file placement.
> https://fedoraproject.org/wiki/PackagingDrafts/Fortran
Unless I don't recall well,
https://fedoraproject.org/wiki/PackagingDrafts/FortranModulesDir
was accepted as a guideline.
Actually, this guideline is broken [1], the directory has to be
versioned [2].
[1] https://bugzilla.redhat.com/show_bug.cgi?id=513985
[2] https://bugzilla.redhat.com/show_bug.cgi?id=483765
--
Jussi Lehtola
Fedora Project Contributor
jussilehtola(a)fedoraproject.org
2:15 p.m.
On Mon, Jul 27, 2009 at 07:18:33PM +0300, Jussi Lehtola wrote:
On Sun, 2009-07-26 at 18:19 +0200, Patrice Dumas wrote:
> On Sun, Jul 26, 2009 at 03:38:57PM +0300, Jussi Lehtola wrote:
> > Hello again,
> >
> >
> > As I have been dealing with quite a few Fortran packages I have realized
> > that the current laissez-faire mentality may not be enough and a
> > standard is needed for file placement.
> > https://fedoraproject.org/wiki/PackagingDrafts/Fortran
>
> Unless I don't recall well,
> https://fedoraproject.org/wiki/PackagingDrafts/FortranModulesDir
> was accepted as a guideline.
Actually, this guideline is broken [1], the directory has to be
versioned [2].
[1] https://bugzilla.redhat.com/show_bug.cgi?id=513985
[2] https://bugzilla.redhat.com/show_bug.cgi?id=483765
This was discussed afterwards, if I recall well, it was said that it was
not necessarily broken at each gfortran release, such that we would do
rebuild only when we notice a change. In fact it is said as such in the
guideline:
Each gfortran release (from 4.1 to 4.2) may lead to an incompatible change in the .mod
files. Therefore for each such gfortran update, this issue should be investigated, and a
rebuild of the package that provide the .mod asked for on the devel announce file and done
by the maintainers if needed.
Are you unhappy with that? The problem with a versionned directory is
that it would lead to many unneeded rebuilds since most of the minor gcc
don't break the .mod formats and there are many minor gcc releases.
Personnally, I am not opposed to having a versionned directory. In fact
this would only mean a change in the _fmoddir macro definition, and maybe
somebody willing to organize an automatic rebuild of all the packages
installing .mod files.
--
Pat
3:04 p.m.
On Mon, 2009-07-27 at 21:15 +0200, Patrice Dumas wrote:
On Mon, Jul 27, 2009 at 07:18:33PM +0300, Jussi Lehtola wrote:
> On Sun, 2009-07-26 at 18:19 +0200, Patrice Dumas wrote:
> > Unless I don't recall well,
> > https://fedoraproject.org/wiki/PackagingDrafts/FortranModulesDir
> > was accepted as a guideline.
>
> Actually, this guideline is broken [1], the directory has to be
> versioned [2].
>
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=513985
> [2] https://bugzilla.redhat.com/show_bug.cgi?id=483765
This was discussed afterwards, if I recall well, it was said that it was
not necessarily broken at each gfortran release, such that we would do
rebuild only when we notice a change. In fact it is said as such in the
guideline:
Each gfortran release (from 4.1 to 4.2) may lead to an incompatible change in the .mod
files. Therefore for each such gfortran update, this issue should be investigated, and a
rebuild of the package that provide the .mod asked for on the devel announce file and done
by the maintainers if needed.
Are you unhappy with that? The problem with a versionned directory is
that it would lead to many unneeded rebuilds since most of the minor gcc
don't break the .mod formats and there are many minor gcc releases.
Personnally, I am not opposed to having a versionned directory. In fact
this would only mean a change in the _fmoddir macro definition, and maybe
somebody willing to organize an automatic rebuild of all the packages
installing .mod files.
That was the opinion of Jakub Jelinek, one of the gcc maintainers.
I agree with you that normally that shouldn't have any effect as
rebuilds of all packages take place when gfortran is upgraded, but given
that on RHEL 5.3 there are two versions of gfortran (the default 4.1
series and the tech preview, gcc43-gfortran, to be updated to
gcc44-gfortran in 5.4), this might have an effect.
And, as you said, it would only require the redefinition of the _fmoddir
macro and a couple of rebuilds.
I have modified my proposal to account for the versioned directory.
https://fedoraproject.org/wiki/PackagingDrafts/Fortran
--
Jussi Lehtola
Fedora Project Contributor
jussilehtola(a)fedoraproject.org
4:30 p.m.
On Mon, Jul 27, 2009 at 11:04:54PM +0300, Jussi Lehtola wrote:
That was the opinion of Jakub Jelinek, one of the gcc maintainers.
But it stirred more conversation, the whole thread started at
https://www.redhat.com/archives/fedora-packaging/2007-October/msg00006.html
I have reread it, gfortran developpers, in general didn't thought
that it should be version specific.
I agree with you that normally that shouldn't have any effect as
rebuilds of all packages take place when gfortran is upgraded, but given
that on RHEL 5.3 there are two versions of gfortran (the default 4.1
series and the tech preview, gcc43-gfortran, to be updated to
gcc44-gfortran in 5.4), this might have an effect.
That doesn't necessarily call for a versionned directory for %_fmoddir.
The %_fmoddir of the main compiler may still not be versionned.
It calls for a specific subdirectory for gcc43-gfortran .mod files,
though normally it should not be used by EPEL/RHEL packages. But this is
not really needed for packaging, it is something users could even set
on their own -- unless some packages require the tech preview, in that
case they should not use _fmoddir anyway.
--
Pat
5:07 p.m.
On Mon, 2009-07-27 at 23:30 +0200, Patrice Dumas wrote:
On Mon, Jul 27, 2009 at 11:04:54PM +0300, Jussi Lehtola wrote:
>
> That was the opinion of Jakub Jelinek, one of the gcc maintainers.
But it stirred more conversation, the whole thread started at
https://www.redhat.com/archives/fedora-packaging/2007-October/msg00006.html
I have reread it, gfortran developpers, in general didn't thought
that it should be version specific.
Thanks for the link, I came to the same conclusion.
I've asked Jakub for more explanation at
https://bugzilla.redhat.com/show_bug.cgi?id=513985
--
Jussi Lehtola
Fedora Project Contributor
jussilehtola(a)fedoraproject.org
5:40 p.m.
The drafts have been approved both by FPC and FESCo, could someone
please proceed with the following changes on the wiki? I've also want
through other drafts and listed some more such cases -- there will be
for sure many more, that's just what I remembered...and I'm running
short on memory:).
(Quoting from
https://fedoraproject.org/wiki/Category:Packaging_guidelines_drafts:)
[TO BE MOVED]
* An approved new guideline will be moved to Packaging: (renamed as
needed) and the category changed to Category:Packaging guidelines
PackagingDrafts/EnvironmentModules
PackagingDrafts/MPI
PackagingDrafts/Fortran
(a link to the "Application Specific Guidelines" section on the main
Guidelines page should be imo added too)
[TO BE MERGED & ARCHIVED]
* An approved modification will be merged into existing guidelines and
the draft will be moved to Archive: and the category changed to
Category:Archived packaging guideline drafts
PackagingDrafts/global_preferred_over_define
PackagingDrafts/PatchUpstreamStatus
PackagingDrafts/Epoch
PackagingDrafts/ExplicitRequires
PackagingDrafts/Haskell
(all of them have been already merged into the main guidelines, Haskell
has another page linked from there, so just archive)
+
PackagingDrafts/FortranModulesDir
PackagingDrafts/FortranLibraries
(invalidated by PackagingDrafts/Fortran, archive)
+
PackagingDrafts/DropScrollkeeperUpdate
PackagingDrafts/JavaAntSampleSpec
ProposalUpdateRGuidelines
(not merged yet! there are more changes that need to be done -- read the
drafts)
Thanks,
Milos
6:19 p.m.
PackagingDrafts/global_preferred_over_define
PackagingDrafts/PatchUpstreamStatus
PackagingDrafts/Epoch
PackagingDrafts/ExplicitRequires
PackagingDrafts/Haskell
(all of them have been already merged into the main guidelines,
Haskell has
another page linked from there, so just archive)
+
PackagingDrafts/Symlinks to this group
--
Milos
5357
days inactive
5388
days old
packaging@lists.fedoraproject.org
14 comments
4 participants
participants (4)
-
Milos Jakubicek -
Patrice Dumas -
Rex Dieter -
Susi Lehtola