package.readme

package.readme

On a suitably setup machine, eg
apt install devscripts rpm rpmlint 

Pull down the code from gitlab,
cd cbindings
refresh source (use a script that gets only relevent files from Lazarus -
	$> bash ./refresh.bash
	$> cd cbindings; 
	## remove any existing library and symlinks
	$> qmake -qt=qt5;  make   (wait ....)
	$> cd package; 
	## update the whatsnew file, maybe from Z's commits.
	## remove any existing packages
	$> DEBEMAIL=YOUR-EMAIL-ADDRESS bash ./package-lib	

Then do a git add, commit and push as necessary.
From github page, make new release, upload as necessary, release.


----------- Package Naming Conventions -------------

RPM <Name>-<version no>-<release no>.<arch>.rpm - widely ignored.

32bit arm RPMs should have armv7l or maybe armv7hl ('h' for hard float ?) in filename
32bit arm debs use armhf - Libraries /usr/lib/arm-linux-gnueabihf 

64bit arm RPMs say aarch65   libraries in /usr/lib64
64bit arm debs say arm64.deb libraries in /usr/lib/aarch64-linux-gnu   ??

32bit x86 RPMs say i386, i586, i686 apparently at random. Libraries in /usr/lib
32bit x86 debs all use i386

(i386 being lowest common denominator, i686 is compiled for i686 cpu and will not run on the very old i386 cpu ?)

Very, very non-authorative.

---------- Legacy Methods, disregard ---------------- 


make <enter>
(wait awhile)
strip libQt5Pas.so.1.2.8

update the version file

cd package
bash ./deb-package
bash ./rpm-package

test

Easy to let github tag the release, create the Release Page, assign an 
appropriate tag and it will be created when Release is released.
 
# back in the top level dir _
# git tag -a v1.2.8
# git push --tags

In the github page, 'releases', 'draft new release'.
Some text, add the generated packages, 'publish'.
back in packages :
rm *.deb *.rpm *.gz
Maybe clean up the working directories ...


rm -Rf tmp

Must update every 60 days to keep workflow running.