Attention Packagers

[Neal ManBear]

I have just a few items to cover ---    

First, please note that if I PM or email you about one of your SRPMs, it is about the package and about PCLinuxOS. Please do not take it personally. Do please reply; ignoring me does not help. If I run into a problem in processing your package, we will need  to talk about it.    

Test your packages before uploading them.

If you package beta software, be sure you put a note with it saying so. We will want to add it to testing first.    

Do not package alpha software. Period!    

Periodically check to see if a package you have submitted has an update available. If it does, create a new package, test and submit it.    

edit 02Aug2012: If you are submitting a security update or a bugfix update, leave a note with your package.     

Thank you for your cooperation in these things. As most of you know, I'm new at processing packages. I believe that we can work together to continue to produce the finest RPMs available. I may never reach Texstar's speed and all, but I believe that keeping up the quality is possible, if we work together.    

Also, I wish to thank those who have already worked with me on their packages. You guys are great!    

[daniel]

You are the boss...

[menotu]

Additionally, if any Packagers would like their package(s) tested prior to sending them "upstream", please PM me and I'll be happy to install/test them and provide any feedback I can.

[Neal ManBear]

Additionally, if any Packagers would like their package(s) tested prior to sending them "upstream", please PM me and I'll be happy to install/test them and provide any feedback I can.

     
Additionally, you can post a topic here and request testing.     

[Neal ManBear]

One more thing ---    
If you are repackaging an app and not upgrading the version but making some other change, please up the release by one number.    

Example:    
%Mkrel     1    
would become ---    
%Mkrel     2    

[MBantz]

One more thing ---    
If you are repackaging an app and not upgrading the version but making some other change, please up the release by one number.    

Example:    
%Mkrel     1    
would become ---    
%Mkrel     2    

ah, I think you mean:
Release:        %mkrel 1
become
Release:        %mkrel 2

the %mkrel is important at it expands to our correct way of naming releases (especially when a spec is taken from another distro),

let me know if I can help out with anything,

cheers,
MBantz

[Neal ManBear]

Thanks, Martin.     
This is what I need -- Pay attention to your release numbers plus the other things in my original post here, please.

And to all packagers ---     
Update the packages you know need updating, please. We have 2 repositories now, 32bit and 64bit, so your help is needed to keep everything updated.     

Thank You!     

[Archie]

In addition, it should be a priority that the package sent upstream should build both on 32 and 64 ... but not always the case. If a package can only build on 32 and not on 64 (or vice versa), a note should be added so the main build server would know it's futile to build the package on the other BuildArch:

[Neal ManBear]

Thanks, Archie!     

On your BuildRequires and Requires entries, use %{_lib}name rather than libname. This will remove the need to edit your specs when processing for the other architecture.     

[Archie]

Thanks, Archie!     

On your BuildRequires and Requires entries, use %{_lib}name rather than libname. This will remove the need to edit your specs when processing for the other architecture.     

My pleasure, Neal.

Yes, let's do this to be on the safe side ... however, there are some libraries that will pull in their 64-bit equivalent even without the appended "64".

[Neal ManBear]

Thanks, Archie!     

On your BuildRequires and Requires entries, use %{_lib}name rather than libname. This will remove the need to edit your specs when processing for the other architecture.     

My pleasure, Neal.

Yes, let's do this to be on the safe side ... however, there are some libraries that will pull in their 64-bit equivalent even without the appended "64".

     
When %{_lib} is used, there is no need to append the '64.'     

[Archie]

Thanks, Archie!     

On your BuildRequires and Requires entries, use %{_lib}name rather than libname. This will remove the need to edit your specs when processing for the other architecture.     

My pleasure, Neal.

Yes, let's do this to be on the safe side ... however, there are some libraries that will pull in their 64-bit equivalent even without the appended "64".

     
When %{_lib} is used, there is no need to append the '64.'     

I know that, Neal. But for some unknown reason, on a specfile if you have for example, BuildRequire: libboost-devel and you have lib64boost-devel already installed, it is OK. Of course, it would be better to change it to BuildRequire: %{_lib}boost-devel.

[Neal ManBear]

Thanks, Archie!     

On your BuildRequires and Requires entries, use %{_lib}name rather than libname. This will remove the need to edit your specs when processing for the other architecture.     

My pleasure, Neal.

Yes, let's do this to be on the safe side ... however, there are some libraries that will pull in their 64-bit equivalent even without the appended "64".

     
When %{_lib} is used, there is no need to append the '64.'     

I know that, Neal. But for some unknown reason, on a specfile if you have for example, BuildRequire: libboost-devel and you have lib64boost-devel already installed, it is OK. Of course, it would be better to change it to BuildRequire: %{_lib}boost-devel.

     
If you have libboost-devel in your spec, change it to %{_lib}boost-devel, please. Then the spec can be used twice - 64 and 32bit. That was my point.      

[Archie]

Thanks, Archie!     

On your BuildRequires and Requires entries, use %{_lib}name rather than libname. This will remove the need to edit your specs when processing for the other architecture.     

My pleasure, Neal.

Yes, let's do this to be on the safe side ... however, there are some libraries that will pull in their 64-bit equivalent even without the appended "64".

     
When %{_lib} is used, there is no need to append the '64.'     

I know that, Neal. But for some unknown reason, on a specfile if you have for example, BuildRequire: libboost-devel and you have lib64boost-devel already installed, it is OK. Of course, it would be better to change it to BuildRequire: %{_lib}boost-devel.

     
If you have libboost-devel in your spec, change it to %{_lib}boost-devel, please. Then the spec can be used twice - 64 and 32bit. That was my point.      

I understand, Neal. And I'm not arguing with you on this. Changing to %{_lib} is what we should do.

I was just pointing out that some (not all) libraries are OK with both 32 and 64 even if they aren't changed and we'd forget or even neglect to change them because they're already OK. I'm almost certain some of us will forget (or neglect) to change to %{_lib}.

%{_lib} should be the standard that we should write our BuildRequires and Requires.

Peace and much respect,
Archie

[Neal ManBear]

I was just emphasizing the point. Others are reading this, too. I knew that you knew.