[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: GraphBLAS and SuiteSparse



Le samedi 02 octobre 2021 à 14:06 +0200, Vincent Prat a écrit :
> Le 02/10/2021 à 13:17, Sébastien Villemot a écrit :
> > Le samedi 02 octobre 2021 à 11:06 +0200, Vincent Prat a écrit :
> > > Le 27/09/2021 à 17:26, Sébastien Villemot a écrit :
> > > > Le samedi 25 septembre 2021 à 17:57 +0200, Vincent Prat a écrit :
> > > > > I recently started packaging python-suitesparse-graphblas [1], which is
> > > > > a Python binding of SuiteSparse:GraphBLAS [2].
> > > > > The version of GraphBLAS packaged in Debian comes from a different
> > > > > repository that includes many other pieces of software, SuiteSparse [3].
> > > > > My problem is that the version included in SuiteSparse (currently 5.0.5)
> > > > > is out of date compared to the standalone version (currently 5.1.7) used
> > > > > by python-suitesparse-graphblas.
> > > > > 
> > > > > What is the best option?
> > > > > a) packaging the standalone version with a different name
> > > > > b) packaging the standalone version instead of the one included in
> > > > > SuiteSparse
> > > > > c) packaging an outdated version of python-suitesparse-graphblas to fit
> > > > > the version of GraphBLAS included in SuiteSparse
> > > > > 
> > > > > As far as I know, other pieces included in SuiteSparse do not depend on
> > > > > GraphBLAS, so I would rather go for option b.
> > > > > Sébastien, can you confirm this ?
> > > > I was not aware that GraphBLAS was also distributed independently of
> > > > SuiteSparse.
> > > > 
> > > > I am perfectly fine with option b.
> > > > 
> > > > Just note that you will have to be careful with version numbers,
> > > > especially since suitesparse currently has an epoch. The libgraphblas5
> > > > binary package that will be produced by your new source package must
> > > > have a greater version number than the current one.
> > > > 
> > > > What I would suggest is to not put the epoch in the new source package
> > > > version, and to only add the epoch on the libgraphblas5 binary package
> > > > (this is technically possible, see e.g. gcc-defaults).
> > > > 
> > > > And when libgraphblas bumps its SOVERSION (whichs happens quite
> > > > frequently), then you will be able to drop the epoch and revert to a
> > > > standard versioning scheme.
> > > > 
> > > Thank you for your reply.
> > > I think I understand how to do this.
> > > Besides, the Debian policy states that before increasing the epoch, one
> > > should get a consensus on devian-devel, so I guess the discussion has to
> > > move there.
> > Actually there is no need to increase an epoch. There is already one on
> > libgraphblas5, and we’re just talking about moving that binary package
> > to a new source package, so it’s inevitable that the epoch has to stay.
> > I don’t think that requires a discussion on debian-devel@.
> > 
> What should be the version of the new binary package, then?
> The version of SuiteSparse itself (5.10.1) is higher than that of
> standalone GraphBLAS (5.1.7).
> Do you suggest something like 1:5.10.1+really5.1.7+dfsg-1?

Sorry, I had overlooked the fact that the version number of GraphBLAS
itself is currently lower than GraphBLAS.

Maybe this case indeed warrants an epoch bump (which would be only a
temporary one until the SOVERSION is bumped to 6). Alternatively, the
+really trick could also be a solution.

-- 
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  https://sebastien.villemot.name
⠈⠳⣄⠀⠀⠀⠀  https://www.debian.org

Attachment: signature.asc
Description: This is a digitally signed message part


Reply to: