gnucash files for SuSE 8.1 on sf

[Matthew Vanecek]

If we have space on sourceforge, we ought to use it.  Take a little of
the burden off of Linas for package download/storage purposes.

I don't know how you would go about verifying that package integrity. 
MD5 checksums and gpg signing, certainly, for file integrity (these
should be required for package formats that support them--everything
supports md5sum. ;-P ).  There would need to be a certain amount of
trust involved, as well as clear and solid communication avenues, for
other system packages.

I like Chris's package naming convention.

Also, we should make a requirement that donated packages conform to the 
File-system Hierarchy Standard (http://www.pathname.com/fhs/ or
http://www.linuxman.com.cy/rute/node38.html).  This shouldn't be an
issue, really, and it will ensure that donated packages are installable
on any standard system.  Packages shouldn't be built to any one person's
personal predilections, but rather should be as standard as possible.

One of the testing parameters needs to be that the package gets
installed on a clean system--i.e., a system that doesn't have Gnucash
installed already.  I've installed too many packages over the years
where the packager munged the package but didn't realize it, because
he/she built/created/tested the package on the same machine.  Ximian was
notorious about that for a while.

That's my $0.02.  I'm not sure what to do about man-power, WRT
maintaining the sourceforge download/donation area.

On Sat, 2003-02-15 at 16:52, Chris Lyttle wrote:
> On Fri, 2003-02-14 at 02:28, Soeren Mindorf wrote:
> > Hi Chris,
> > 
> > I have talked to Christian Stimming how can I release my rpm-packages 
> > from gnucash for SuSE 8.1, he told me you can help.
> > 
> > I have build the following packages for SuSE 8.1 with hbci support:
> > 
> > - gnucash 1.7.8
> > - gnucash 1.8.0
> > - gnucash 1.8.1
> > - g-wrap-1.3.4
> > - openhbci-sm-0.9.5
> > 
> > Can I upload this files to sf?
> > Christian thinks that is a good idear when you add me as developer in sf 
> > and give me dir permissions that I can release my files.
> > 
> 
> I'm widening this to the general GnuCash community because it brings up
> some questions that probably should be answered as we go ahead with
> stable releases and even when we decide to start doing unstable ones
> again.
> 
> I have been releasing RedHat RPM's mainly because that's what I'm using
> here. I've been considering changing my workstation to Gentoo. I could
> still do RH releases by booting to another disk or using VMware. The
> questions that have come up lately have been about packaging for other
> distro's, mainly debian, mandrake and suse.
> 
> My normal release process up till now with the unstable series was just
> to make sure the tarballs passed make distcheck on RH 7.3 then to build
> RH rpms for 7.x and 8.x. As this needed to be done pretty quickly due to
> a release every 2 weeks, I didn't have time to consult people building
> on other distro's to see if things worked ok there.
> 
> For the stable series releases, we now have the opportunity to slow down
> the release process so people who wish to contribute packages built for
> other distro's can test and get the package's done for release.
> 
> The first thing that comes up with this is that the gnucash.org ftp site
> is not reachable with an ftp client, only with a web browser or ssh.
> This is mainly for Linas as the owner of that server, how would you like
> to have it so people contributing packages for other distro's can upload
> it to gnucash.org? We have currently also some extra packages for
> gnucash, libofx, openhbci and g-wrap mainly. Do we want to store distro
> specific packages of these also on the ftp server and if so what process
> do we use to validate the packages will work and upload them to the
> server? (BTW the sourceforge site is just a mirror for packages, what we
> decide here would also mean uploading to sf as well for just the gnucash
> packages)
> 
> Secondly, the release process itself. I would prefer, as the one doing
> the releases, to not spend lots of time in getting packages from people
> who are contributing and making sure they get to the right place on the
> server. I would like to have it that one person takes responsibility to
> make sure the package works for each distro that wants to put packages
> on the gnucash.org servers. This would involve not only testing the
> package before you put it on the server, but also working on resolving
> any problems with the package you release once they are on the
> gnucash.org server. The package names I have been using include the
> platform it was built on due to some previous confusion of what was
> being installed. I would like people to use the following format;
> 
> gnucash-<release version>.<distro><distro version>.<pkg>
> 
> for eg, gnucash-1.8.1-1.RH8.0.i386.rpm
> 
> My suggestion for the co-ordination of releases is as follows (all times
> PST);
> 
> 1) Decide on release date (a sunday evening)
> 2) Tag CVS with gnucash-<version>-rc (eg gnucash-1-8-1-rc)
> 3) Make tarball from that tag, release as a rc a week before the general
> release date. 
> 4) People making packages build from that tarball, feeding back any
> problems to the gnucash-devel list. NOTE: If the problem is major enough
> that it needs testing after committing to CVS then I will delay the
> release date another week to go through the release rc, test process
> again.
> 5) The friday evening before release I will make the final tarball and
> tag CVS with gnucash-<version> (eg gnucash-1-8-1).
> 6) I would upload the tarball to an area on the gnucash-org ftp server
> that the package makers can access to get.
> 7) People make packages, upload them before sunday evening
> 8) The release is generally announced Sunday evening
> 
> As to the packages people are making, there needs to be some thought put
> into how the packages are being made. As I have demonstrated with the RH
> packages, it is possible to make a main gnucash package and have addon
> packages for optional features like libofx, hbci and sql. At the very
> least your package must only require g-wrap for users to install. If you
> want to add openhbci support, for eg, you need to have a separate rpm,
> deb or whatever for this. This is to minimize problems for people
> installing that dont want/need those addon features. (The above packages
> wouldn't be acceptable for this reason, they need openhbci to install).



-- 
Matthew Vanecek
perl -e 'print $i=pack(c5,(41*2),sqrt(7056),(unpack(c,H)-2),oct(115),10);'
********************************************************************************
For 93 million miles, there is nothing between the sun and my shadow except me.
I'm always getting in the way of something...