On Sunday 26 October 2008 12:38:22 Timo Neuvonen wrote:
> "Kern Sibbald" <kern AT sibbald DOT com> kirjoitti viestissä
> news:200810260903.29174.kern AT sibbald DOT com...
>
> > On Saturday 25 October 2008 21:53:00 Ulrich Leodolter wrote:
> >> On Sat, 2008-10-25 at 21:11 +0200, Eric Bollengier wrote:
> >> > Le Saturday 25 October 2008 13:41:15 Ulrich Leodolter, vous avez écrit
> >> >
> >> > > On Sat, 2008-10-25 at 11:32 +0200, Kern Sibbald wrote:
> >> > > > Hello,
> >> > > >
> >> > > > For some time now, I haven't really been happy with the Bacula
> >> > > > patch
> >> > > > procedure. Basically, when we fix a bug (either from a bug report
> >> > > > or
> >> > > > ourselves), we usually generate a patch, post it to the bug
> >> > > > report, if any, and upload it to the Bacula patches area of Source
> >> > > > Forge.
> >> > > >
> >> > > > Providing you are subscribed to the bugs database and to the
> >> > > > bacula-patches release notification on Source Forge, you will see
> >> > > > these patches and can apply them if you deem necessary.
> >> > > >
> >> > > > The problems I have with this is that some people may not know
> >> > > > about
> >> > > > patches (we see this in bug reports where a problem is already
> >> > > > resolved with a patch), and there is no formal mechanism for
> >> > > > developers when generating a patch.
> >> > > >
> >> > > > We already have more work than we can handle, so any change needs
> >> > > > to
> >> > > > be simple and not time consuming for developers, but I am
> >> > > > wondering if anyone has suggestions how to improve this. I can
> >> > > > think of a few:
> >> > > >
> >> > > > 1. Change nothing (signing up for bugs and patch notification is
> >> > > > already not bad).
> >> > > > 2. Announce patches to the bacula-devel list
> >> > > > 3. Announce patches to the bacula-devel list and the bacula-users
> >> > > > list 4. Announce patches to the bacula-announce list as well as
> >> > > > the other two lists.
> >> > > > 5. Put patches in the news (time consuming and I doubt that many
> >> > > > read
> >> > > > news). 6. Create an rss feed (I doubt that many users use rss, and
> >> > > > this also could be time consuming).
> >> > >
> >> > > Hello,
> >> > >
> >> > > One thing i am missing are patched packages, rpm and also deb
> >> > > packages
> >> > > have a mechanism to include patch files an apply during build
> >> > > process.
> >> > >
> >> > > For most bacula users it would be much easier to apply patches by
> >> > > "rpm
> >> > > -U ..." or "dpkg install ...".
> >> >
> >> > Yes, but you have to build, test and release a package for each disto
> >> > after each patch, this is a *huge* amount of work, we have something
> >> > like
> >> > 10 patches between two releases.
> >> >
> >> > If someone want to build, test and package 10 more often than before
> >> > for
> >> > free, no problem, but i prefere spend my time with new features and
> >> > bugs
> >> > hunting.
> >> >
> >> > > Operating systems like RedHat, CentOS, SLES, Debian, ... are always
> >> > > at
> >> > > least one step behind last official version.
> >> > >
> >> > > An official bacula package repository (yum, apt) would be great.
> >> >
> >> > Fedora, debian and ubuntu already provide this kind of repositor, and
> >> > often, they have a backport branch.
> >
> > I was out yesterday, so will answer here in your second email.
> >
> > Yes, I think having full packages available is the best way to get
> > "patches".
> > We already sometimes do that. However, as Eric pointed out, it is a lot
> > of
> > work. The packaging is done by the community. I release a new source
> > tar file and (with the exception of Win32), the community creates new
> > packages if
> > they want. They always do so for new releases, and for what I designate
> > as
> > critical fixes, but possibly not for all the more minor patches.
>
> I guess there are a number of users who are not familiar with the packaging
> process, partially that includes me, although I'm rather used to build many
> binaries from source rpms.
>
> One reasonable way to reduce the burden to the packagers might be, if they
> mostly concentrated (now I'm talking only about rpm packages, I don't know
> eg. debian) in building the source packages that could be expected to
> succesfully build into binaries. I understand that there is a lot of work
> after building the source package that somehow seriously can be expected to
> work, since the various final binaries preferably should also be installed
> in the target systems and tested there -at least to the point they start
> nicely. But when it's about "small" minor patches, it might be reasonable
> that an experienced packager views the patch and the spec file, and if it
> were expected that all this could result in a working binary package,
> building the binaries could be left to the end users -at least when it
> comes to the very minor patches.
>
> Currently, at least I am a little bit scared about the idea of building and
> installing into a "production environment" an application that was shipped
> as a source tarball, since it may conflict with the existing system, and I
> have some bad experiencies from the past how to uninstall some tarball
> installations (not speaking of Bacula now), though a bad rpm binary may be
> hard to uninstall as well.
>
> So, could a reasonable middle-way be releasing more source rpms, and
> include in the release notes an example how to build the binary rpm? Or, if
> a supposed-to-be-perfect spec file that can handle the patches is already
> included in the tarball, just include an example command sequence how to
> build a binary rpm all the way from the source tarball? This would reduce
> some raw shovel-level work from the packagers. Then, if the binary could
> not be built eg. due to some bug in the spec file, it would be up to the
> official packager again if he/she has resources to fix it at that point, or
> decides to wait until the next release.
The instructions for building rpms already exist in the Bacula document (or
possibly the Developers document). For other packages (Solaris, Debian, Mac)
the project has never packaged them, nor had official packagers, so we have
no instructions. One of the fall-outs of having Bacula Systems is that we
will be building packages for as many systems as possible, so we will
naturally document it.
I think you all need to talk to the current packagers about the issues of when
and who packages -- they are all volunteers, so you will need to discuss with
them whether or not they could increase the number of packages released.
Finally, as I mentioned, with Bacula Systems needing to build "certified"
binaries, some of that will surely flow back into the community -- or I
should say as much as is possible will flow back into the community.
Best regards,
Kern
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users
|
