Backup Central

On 17 Jun 2007 at 12:28, Scott Barninger wrote:

But the entire doc source tarball is still a source in the packages. So
I'm thinking about changing that and making only the pdf manuals (user
and developer) actual sources in the RPM package.

I see no reason for the source files to be in the packages for the
documentation. My suggestion: split the docs into source and
"binary".

--
Dan Langille
two conferences, one trip, great value: May 2007
BSDCan - The BSD Conference - http://www.bsdcan.org/
PGCon - The PostgreSQL Conference - http://www.pgcon.org/

On Sun, 2007-06-17 at 12:32 -0400, Dan Langille wrote:
On 17 Jun 2007 at 12:28, Scott Barninger wrote:

But the entire doc source tarball is still a source in the packages. So
I'm thinking about changing that and making only the pdf manuals (user
and developer) actual sources in the RPM package.

I see no reason for the source files to be in the packages for the
documentation. My suggestion: split the docs into source and
"binary".

To be a bit more explicit, the bacula-docs tarball we publish has
actually been build before releasing it. I have always included that
tarball as a source and then installed a few pieces. I'm suggesting to
just install the pdf manuals and skip the html manual if that doesn't
cause anyone grief. I think pdf is universal enough at this point.

On 17 Jun 2007 at 12:42, Scott Barninger wrote:

On Sun, 2007-06-17 at 12:32 -0400, Dan Langille wrote:
On 17 Jun 2007 at 12:28, Scott Barninger wrote:

But the entire doc source tarball is still a source in the
packages. So I'm thinking about changing that and making only the
pdf manuals (user and developer) actual sources in the RPM
package.

I see no reason for the source files to be in the packages for the
documentation. My suggestion: split the docs into source and
"binary".

To be a bit more explicit, the bacula-docs tarball we publish has
actually been build before releasing it. I have always included that
tarball as a source and then installed a few pieces. I'm suggesting to
just install the pdf manuals and skip the html manual if that doesn't
cause anyone grief. I think pdf is universal enough at this point.

What about two tarballs? PDF. HTML.

--
Dan Langille
two conferences, one trip, great value: May 2007
BSDCan - The BSD Conference - http://www.bsdcan.org/
PGCon - The PostgreSQL Conference - http://www.pgcon.org/

On Sun, 2007-06-17 at 12:56 -0400, Dan Langille wrote:
On 17 Jun 2007 at 12:42, Scott Barninger wrote:

On Sun, 2007-06-17 at 12:32 -0400, Dan Langille wrote:
On 17 Jun 2007 at 12:28, Scott Barninger wrote:

But the entire doc source tarball is still a source in the
packages. So I'm thinking about changing that and making only the
pdf manuals (user and developer) actual sources in the RPM
package.

I see no reason for the source files to be in the packages for the
documentation. My suggestion: split the docs into source and
"binary".

To be a bit more explicit, the bacula-docs tarball we publish has
actually been build before releasing it. I have always included that
tarball as a source and then installed a few pieces. I'm suggesting to
just install the pdf manuals and skip the html manual if that doesn't
cause anyone grief. I think pdf is universal enough at this point.

What about two tarballs? PDF. HTML.


Well, yes, I suppose I could build my own but I was sort of looking to
avoid that.

On Sunday 17 June 2007 18:28, Scott Barninger wrote:
Good Afternoon,

As I sat here earlier watching the 39 MB SRPM (30 MB of which is the
docs tarball) for 2.1.18 crawl it's way up to sourceforge I began to
wonder if it is not time for a change. The documentation package has
grown substantially since the change to latex and I'm only packaging the
pdf manuals and the html manual. But the entire doc source tarball is
still a source in the packages. So I'm thinking about changing that and
making only the pdf manuals (user and developer) actual sources in the
RPM package.

I believe that is more or less the case with the file that I am releasing. By
the way, the docs will probably no longer be released to Source Forge. Their
FTP upload is broken and they refuse to fix it, so until we find a better
solution, they will be released as I did for the beta, because I've waste an
enormous amount of time trying to release the docs. If I could find another
release site with similar features to Source Forge, I would switch in a
flash. Please don't send me a list of sites, unless it is *really* something
new and *really* good. I have looked at them all, and all have more serious
problems than Source Forge :-(

Regards,

Kern

On Sunday 17 June 2007 18:42, Scott Barninger wrote:
On Sun, 2007-06-17 at 12:32 -0400, Dan Langille wrote:
On 17 Jun 2007 at 12:28, Scott Barninger wrote:

But the entire doc source tarball is still a source in the packages. So
I'm thinking about changing that and making only the pdf manuals (user
and developer) actual sources in the RPM package.

I see no reason for the source files to be in the packages for the
documentation. My suggestion: split the docs into source and
"binary".

To be a bit more explicit, the bacula-docs tarball we publish has
actually been build before releasing it. I have always included that
tarball as a source and then installed a few pieces. I'm suggesting to
just install the pdf manuals and skip the html manual if that doesn't
cause anyone grief. I think pdf is universal enough at this point.


In the binary rpms, I think what you are suggesting is perfectly fine -- it is
in fact, what we do for Win32.

Regards,

Kern

On Sunday 17 June 2007 18:56, Dan Langille wrote:
On 17 Jun 2007 at 12:42, Scott Barninger wrote:

On Sun, 2007-06-17 at 12:32 -0400, Dan Langille wrote:
On 17 Jun 2007 at 12:28, Scott Barninger wrote:

But the entire doc source tarball is still a source in the
packages. So I'm thinking about changing that and making only the
pdf manuals (user and developer) actual sources in the RPM
package.

I see no reason for the source files to be in the packages for the
documentation. My suggestion: split the docs into source and
"binary".

To be a bit more explicit, the bacula-docs tarball we publish has
actually been build before releasing it. I have always included that
tarball as a source and then installed a few pieces. I'm suggesting to
just install the pdf manuals and skip the html manual if that doesn't
cause anyone grief. I think pdf is universal enough at this point.

What about two tarballs? PDF. HTML.

The tar file will contain everything for the manual -- the source and the
binaries, unless you can convince all the packagers to take only the source,
in which case the tar file will contain only the source as I believe it
should. Some packagers complained (I forget which ones) and said that they
could only release what was actually built, which seems a bit odd to me,
because they also package the binaries for Bacula which are not built in the
tar file.

I would really love to get out of the business of supplying binaries, but I've
tried to take the path of least resistance ...

On Sunday 17 June 2007 19:09, Scott Barninger wrote:
On Sun, 2007-06-17 at 12:56 -0400, Dan Langille wrote:
On 17 Jun 2007 at 12:42, Scott Barninger wrote:

On Sun, 2007-06-17 at 12:32 -0400, Dan Langille wrote:
On 17 Jun 2007 at 12:28, Scott Barninger wrote:

But the entire doc source tarball is still a source in the
packages. So I'm thinking about changing that and making only the
pdf manuals (user and developer) actual sources in the RPM
package.

I see no reason for the source files to be in the packages for the
documentation. My suggestion: split the docs into source and
"binary".

To be a bit more explicit, the bacula-docs tarball we publish has
actually been build before releasing it. I have always included that
tarball as a source and then installed a few pieces. I'm suggesting to
just install the pdf manuals and skip the html manual if that doesn't
cause anyone grief. I think pdf is universal enough at this point.

What about two tarballs? PDF. HTML.


Well, yes, I suppose I could build my own but I was sort of looking to
avoid that.

Well, you are not the only one, so I'll continue supplying them since it is
not really hard. The only hard part is trying to get them up on Source
Forge, which I have given up on.

Scott Barninger wrote:
On Sun, 2007-06-17 at 12:56 -0400, Dan Langille wrote:

On 17 Jun 2007 at 12:42, Scott Barninger wrote:


What about two tarballs? PDF. HTML.


Well, yes, I suppose I could build my own but I was sort of looking to
avoid that.


Depending on the platform I'd prefer the one or the other. For example,
on my workstation I got a graphical working environment so the PDF works
fine for me. Three weeks ago, however, I sat in a very noise server room
telling a NAS to get a grip and had to completely reconfigure the whole
server. Because we we're waiting for a restore I had to do in in there
and was pretty darn happy with the HTML guide on links2. I'm not even
sure how to display a PDF on a console...

Just one of many situations that might benefit from seperate packages...

Just my 2 cents

Berend

P.S. My mail server and me are in an argument - I might have sent this twice

On Sun, 2007-06-17 at 12:56 -0400, Dan Langille wrote:
On 17 Jun 2007 at 12:42, Scott Barninger wrote:

On Sun, 2007-06-17 at 12:32 -0400, Dan Langille wrote:
On 17 Jun 2007 at 12:28, Scott Barninger wrote:

But the entire doc source tarball is still a source in the
packages. So I'm thinking about changing that and making only the
pdf manuals (user and developer) actual sources in the RPM
package.

I see no reason for the source files to be in the packages for the
documentation. My suggestion: split the docs into source and
"binary".

To be a bit more explicit, the bacula-docs tarball we publish has
actually been build before releasing it. I have always included that
tarball as a source and then installed a few pieces. I'm suggesting to
just install the pdf manuals and skip the html manual if that doesn't
cause anyone grief. I think pdf is universal enough at this point.

What about two tarballs? PDF. HTML.


I stripped the docs tarball leaving only the html manual and the pdf ones.
That reduced the size of the SRPM to 11 MB but sourceforge is still not
cooperating. I've tried 3 times today to get the 2.1.18 release up and I
keep getting aborted uploads. Perhaps it will work better tomorrow.

On Sunday 17 June 2007 23:47, Scott Barninger wrote:
On Sun, 2007-06-17 at 12:56 -0400, Dan Langille wrote:
On 17 Jun 2007 at 12:42, Scott Barninger wrote:

On Sun, 2007-06-17 at 12:32 -0400, Dan Langille wrote:
On 17 Jun 2007 at 12:28, Scott Barninger wrote:

But the entire doc source tarball is still a source in the
packages. So I'm thinking about changing that and making only the
pdf manuals (user and developer) actual sources in the RPM
package.

I see no reason for the source files to be in the packages for the
documentation. My suggestion: split the docs into source and
"binary".

To be a bit more explicit, the bacula-docs tarball we publish has
actually been build before releasing it. I have always included that
tarball as a source and then installed a few pieces. I'm suggesting to
just install the pdf manuals and skip the html manual if that doesn't
cause anyone grief. I think pdf is universal enough at this point.

What about two tarballs? PDF. HTML.


I stripped the docs tarball leaving only the html manual and the pdf ones.
That reduced the size of the SRPM to 11 MB but sourceforge is still not
cooperating. I've tried 3 times today to get the 2.1.18 release up and I
keep getting aborted uploads. Perhaps it will work better tomorrow.


The told me to upload it to the shell area then to ftp it from there. I
consider that a total waste of time for the docs, but I'll let you decide if
you want to use it for the srpms.

I've given you access to the shell area, but don't remember how to use it -- I
logged in once. There is documentation on the site for how to get into it.
I think you just ssh in, but you need to know the right address.

The only thing I ask is that if you do upload files to the shell area, please
delete them once you get them in the upload area, otherwise they start
sending me email messages about the space usage which we are supposed to keep
to a minimum.

If you find that technique useful, please let me know how you did it, and also
let me know if any of the other packagers need shell access.

Best regards,

Kern

On Mon, 2007-06-18 at 08:23 +0200, Kern Sibbald wrote:
The told me to upload it to the shell area then to ftp it from there. I
consider that a total waste of time for the docs, but I'll let you decide if
you want to use it for the srpms.

I've given you access to the shell area, but don't remember how to use it -- I
logged in once. There is documentation on the site for how to get into it.
I think you just ssh in, but you need to know the right address.

The only thing I ask is that if you do upload files to the shell area, please
delete them once you get them in the upload area, otherwise they start
sending me email messages about the space usage which we are supposed to keep
to a minimum.

If you find that technique useful, please let me know how you did it, and also
let me know if any of the other packagers need shell access.


I will look at this this coming weekend as I don't have time at the
moment. I tried just now to upload the 2.1.18 srpm by regular ftp and
failed again after a partial upload. If you log in you will see it there
in the upload area. So no 2.1.18 rpm for now, but for anyone interested
it built without changes to the spec file from my previous beta release
other than version information (I used my previous 2.1.10 docs file).