rpms/opencdk/devel opencdk.spec,1.2,1.3

Author: thias

Update of /cvs/extras/rpms/opencdk/devel
In directory cvs.fedora.redhat.com:/tmp/cvs-serv705

Modified Files:
	opencdk.spec 
Log Message:
Fix release, drop epoch and separators that can be nasty sometimes.



Index: opencdk.spec
===================================================================
RCS file: /cvs/extras/rpms/opencdk/devel/opencdk.spec,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- opencdk.spec	8 Nov 2004 04:55:55 -0000	1.2
+++ opencdk.spec	2 Feb 2005 14:07:46 -0000	1.3
@@ -1,8 +1,7 @@
 Summary:	Provides basic parts of the OpenPGP message format
 Name:		opencdk
 Version:	0.4.5
-Release:	0.fdr.1.1
-Epoch:		0
+Release:	1
 License:	GPL
 Group:		System Environment/Libraries
 URL:		http://www.gnu.org/software/gnutls/download.html
@@ -13,7 +12,7 @@
 %package devel
 Summary:	Files which are needed to develop applications using opencdk
 Group:		Development/Libraries
-Requires:	%{name} = 0:%{version}-%{release}
+Requires:	%{name} = %{version}-%{release}
 Requires:	libgcrypt-devel zlib-devel
 
 
@@ -38,12 +37,10 @@
 This package contains headerfiles and libraries which are needed to
 develop applications based on opencdk.
 
-#----------------------------------------
 
 %prep
 %setup -q
 
-#----------------------------------------
 
 %build
 %configure
@@ -52,12 +49,10 @@
 perl -pi -e 's!^(\S.*[\s"])-L/usr/lib([\s"])!\1\2!g;
              s!^(\S.*[\s"])-I/usr/include([\s"])!\1\2!g'
src/opencdk-config
 
-#----------------------------------------
 
 %check
 %{__make} check
 
-#----------------------------------------
 
 %install
 rm -rf "$RPM_BUILD_ROOT"
@@ -65,12 +60,10 @@
 
 rm -f $RPM_BUILD_ROOT%{_libdir}/*.la
 
-#----------------------------------------
 
 %clean
 rm -rf "$RPM_BUILD_ROOT"
 
-#----------------------------------------
 
 %post   -p /sbin/ldconfig
 %postun -p /sbin/ldconfig

[Michael Schwendt]

On Wed, 2 Feb 2005 09:07:48 -0500, Matthias Saou (thias) wrote:

>  Author: thias
>  
>  Update of /cvs/extras/rpms/opencdk/devel
>  In directory cvs.fedora.redhat.com:/tmp/cvs-serv705
>  
>  Modified Files:
>  	opencdk.spec 
>  Log Message:
>  Fix release, drop epoch and separators that can be nasty sometimes. 
Hmm, all of these still have 0.fdr prefix on purpose, because they were
failed rebuilds for FC2/FC3 and not updated since then. See 

  http://fedoraproject.org/wiki/Extras/FC3Status

Except uqm-content which is a very large data package and would be 
an unnecessary upgrade for users. It can be shared between FC3 and
older.

[Matthias Saou]

Michael Schwendt wrote :

>  On Wed, 2 Feb 2005 09:07:48 -0500, Matthias Saou (thias) wrote:
>  
>  > Author: thias
>  > 
>  > Update of /cvs/extras/rpms/opencdk/devel
>  > In directory cvs.fedora.redhat.com:/tmp/cvs-serv705
>  > 
>  > Modified Files:
>  > 	opencdk.spec 
>  > Log Message:
>  > Fix release, drop epoch and separators that can be nasty sometimes.
>  
>  Hmm, all of these still have 0.fdr prefix on purpose, because they were
>  failed rebuilds for FC2/FC3 and not updated since then. See 
>  
>    http://fedoraproject.org/wiki/Extras/FC3Status
>  
>  Except uqm-content which is a very large data package and would be 
>  an unnecessary upgrade for users. It can be shared between FC3 and
>  older. 
Errr... then I'm sorry, but also very confused : I changed those release
tags because all of these packages are already built in FC3 pre-Extras. :-/

http://fedoraproject.org/pre-extras/3/

Cheers,
Matthias

-- 
Clean custom Red Hat Linux rpm packages : http://freshrpms.net/
Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.10-1.753_FC3
Load : 0.19 0.34 0.39

[Michael Schwendt]

On Wed, 2 Feb 2005 16:17:23 +0100, Matthias Saou wrote:

>  > > Modified Files:
>  > > 	opencdk.spec 
>  > > Log Message:
>  > > Fix release, drop epoch and separators that can be nasty sometimes.
>  > 
>  > Hmm, all of these still have 0.fdr prefix on purpose, because they were
>  > failed rebuilds for FC2/FC3 and not updated since then. See 
>  > 
>  >   http://fedoraproject.org/wiki/Extras/FC3Status
>  > 
>  > Except uqm-content which is a very large data package and would be 
>  > an unnecessary upgrade for users. It can be shared between FC3 and
>  > older.
>  
>  Errr... then I'm sorry, but also very confused : I changed those release
>  tags because all of these packages are already built in FC3 pre-Extras. :-/
>  
>  http://fedoraproject.org/pre-extras/3/ 
Remember that the sudden first mass-rebuild of everything in CVS happened
while cleanup of the imported packages was not complete. Many old packages
had a "devel" branch, but had not been rebuilt or updated since FC1 or
older. With these exceptions:

'uqm-content'
   (release not touched, so common package is shared for all dists)

'gnome-themes-extras'
   (0.fdr.1 was imported after mass release-bump, good to bump it now)

The other packages with 0.fdr.1.1 (or so) were last built for FC1 and need
investigation and are tracked since FC2Status page, when they failed to
build for FC2. The FC3Status page contains a copy of the old FC2Status
page.

[Matthias Saou]

Michael Schwendt wrote :

>  Remember that the sudden first mass-rebuild of everything in CVS
> happened
>  while cleanup of the imported packages was not complete. Many old 
packages
>  had a "devel" branch, but had not been rebuilt or updated
> since FC1 or
>  older. With these exceptions:
>  
>  'uqm-content'
>     (release not touched, so common package is shared for all dists) 
Hmmm, for me, this one should not escape the renaming just for that reason,
especially since there have been no FC3 packages from fedora.us, Fedora
Extras should IMHO introduce only new clean packages (not to mention that
two different released builds should never share the same N-E-V-R since
there are no guarantees that they will be identical, especially when coming
from two different build systems), and eventually keep it as-is from there
on for future Core releases as you want to do now.

>  'gnome-themes-extras'
>     (0.fdr.1 was imported after mass release-bump, good to bump it now) 
OK.

>  The other packages with 0.fdr.1.1 (or so) were last built for FC1 and
need
>  investigation and are tracked since FC2Status page, when they failed
> to
>  build for FC2. The FC3Status page contains a copy of the old FC2Status
>  page. 
So the proper fix would be to remove them from the built pre-Extras, then?
And either remove their devel branch or "blacklist" them so that they don't
get rebuilt until someone actually decides to fix them up...

Matthias

-- 
Clean custom Red Hat Linux rpm packages : http://freshrpms.net/
Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.10-1.753_FC3
Load : 0.21 0.29 0.28

[Michael Schwendt]

On Wed, 2 Feb 2005 17:02:58 +0100, Matthias Saou wrote:

>  > 'uqm-content'
>  >    (release not touched, so common package is shared for all dists)
>  
>  Hmmm, for me, this one should not escape the renaming just for that reason,
>  especially since there have been no FC3 packages from fedora.us, Fedora
>  Extras should IMHO introduce only new clean packages (not to mention that
>  two different released builds should never share the same N-E-V-R since
>  there are no guarantees that they will be identical, especially when coming
>  from two different build systems), and eventually keep it as-is from there
>  on for future Core releases as you want to do now. 
Raw data packages (e.g. containing 100 MiB of .ogg music files) will be
identical, provided that there are no important changes in RPM. Whether
and when to bump the release was also a decision as when Ville would
update uqm anyway.
 
>  > The other packages with 0.fdr.1.1 (or so) were last built for
> FC1 and
>  need
>  > investigation and are tracked since FC2Status page, when they failed to
>  > build for FC2. The FC3Status page contains a copy of the old FC2Status
>  > page.
>  
>  So the proper fix would be to remove them from the built pre-Extras, then?
>  And either remove their devel branch or "blacklist" them so that they
> don't
>  get rebuilt until someone actually decides to fix them up... 
Disabling build in %prep (e.g. as done in openbox) would work.

[Ville Skyttä]

On Wed, 2005-02-02 at 17:27 +0100, Michael Schwendt wrote:

>  Disabling build in %prep (e.g. as done in openbox) would work.
Or "ExclusiveArch: NONE" to save a few buildsys CPU cycles if someone
cares.  I'm sure people will find many funny replacements for NONE that
aren't valid archs...

uqm-content (was: Re: rpms/opencdk/devel opencdk.spec,1.2,1.3)

[Ville Skyttä]

On Wed, 2005-02-02 at 17:02 +0100, Matthias Saou wrote:
>  Michael Schwendt wrote :
>
>  > 'uqm-content'
>  >    (release not touched, so common package is shared for all dists)
>  
>  Hmmm, for me, this one should not escape the renaming just for that reason,
>  especially since there have been no FC3 packages from fedora.us, Fedora
>  Extras should IMHO introduce only new clean packages (not to mention that
>  two different released builds should never share the same N-E-V-R since
>  there are no guarantees that they will be identical, especially when coming
>  from two different build systems), and eventually keep it as-is from there
>  on for future Core releases as you want to do now. 
I tend to agree in general, but it's not entrely black and white, this
is a special case.  If you look into the specfile, it is nothing more
than copying 3 big zipfiles into place.  That cannot cause much
differences in the results no matter where it's built.  One could also
argue that this package should not exist in the first place... (but IIRC
in the first release, it was a bit more than just copying the zips, and
things may change again in the future).

But it's not that big a deal.  We still have the option not to build a
new one from CVS for Real-Extras (or drop the package) if that's what's
considered best.  I don't have strong opinions here; perhaps leaning
slightly towards what you suggest above though.  And if there will be a
new build just for the no-op fdr+0epoch changes, I'll gladly reassign
all possibly forthcoming, related bug reports to you because my opinion
is not strong enough here so I'd committed this change myself ;)