[ClusterLabs] @ClusterLabs/devel COPR with new libqb (Was: libqb 1.0.1 release)
jpokorny at redhat.com
Thu Nov 24 17:45:09 CET 2016
On 24/11/16 10:42 +0000, Christine Caulfield wrote:
> I am very pleased to announce the 1.0.1 release of libqb
For instant tryout on Fedora/EL-based distros, there is already
a habitual COPR build. But this time around, I'd like to introduce
some advancements in the process...
* * *
First, we now have a dedicated ClusterLabs group established in COPR,
and so far the only, devel, repository underneath, see:
The page hopefully states clearly what to expect, it's by no mean
intended to eclipse fine tuned downstream packages[*]. The packages
are provided AS ARE and the distros themselves have no liabilities,
so please do not file bugs at downstream trackers -- any feedback
at upstream level is still appreciated (as detailed), though.
[*] that being said, Fedora is receiving an update soonish
* * *
Second, new packages are generated once new push of changesets
occurs at respective upstream repositories, so it's always at
one's discretion whether to pick particular tagged version of
the component, or whichever else (usually the newest one).
So to update strictly to 1.0.1 version of libqb from here and
supposing you have dnf available + your distro is directly covered
with the builds, you would have to do as root:
# dnf copr enable @ClusterLabs/devel
# dnf update libqb-1.0.1-1$(rpm -E %dist)
as mere "dnf update libqb" would currently update even higher,
up to 1.0.1-1.2.d03b7 (2 commits pass the 1.0.1 version)
as of writing this email.
In other words, not specifying the particular version will provide
you with the latest greatest version, which is only useful if you
want to push living on the bleeding edge to the extreme (and this
COPR setup is hence a means of "continuous delivery" to shout a first
buzzword here). It's good to be aware of this.
* * *
[now especially for developers ML readers]
Third, the coverage of the ClusterLabs-associated packages is
going to grow. So far, there's pacemaker in the pipeline[**].
There's also an immediate benefit for developers of these packages,
as the cross-dependencies are primarily satisfied within the same
COPR repository, which means that here, latest development version
of pacemaker will get built against the latest version of libqb at
that moment, and thanks to the pacemaker's unit tests (as hook in
%check scriptlet when building the RPM package), there's also
realy a notion of integration testing (finally a "continous
integration" in a proper sense, IMHO; the other term to mention here).
That being said, if you work on a fellow project and want it to join
this club (and you are not a priori against Fedora affiliation as that
requires you obtaining an account in Fedora Account System), please
contact me off-list and we'll work it out.
* * *
Hope you'll find this useful.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 819 bytes
Desc: not available
More information about the Users