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

Doubt about using a forked version for a new package release



Hi!

I would like to have some opinions and suggestions about the best
action when updating a package that has a forked version.
The forked version is better updated, maintained and has improvements
over the original version.

Debian has pngnq at version 1.0 with the latest upstream version at 1.1
The fork https://sf.net/projects/pngnqs9 is at version 2.0.2

The best option seems, indeed, to offer the forked version (as
https://bugs.debian.org/862077 also says)

Options that I see are:

1) ask for removal of pngnq and upload the new pngnqs9

But then users will lose the "pngnq" binary, affecting scripts, etc.
I could create a symlink or use alternatives to have "pngnq" available
to the user (pointing it to the new pngnq-s9 binary).
A possible problem here is if one day pngnq gets back to life.

2) pack pngnqs9 as pngnq

Just ship pngnqs9 as pngnq.

Problem here is if pngnq's upstream releases a new version too, like
on 1 (possible problem with version numbers, with incompatible
features, diverging the program and making it completely different,
etc) or if somebody else packs and uploads pngnqs9 (then we will have
pngnq = pngnqs9 in the archive)

3) update pngnq to the latest version + some patches backported from pngnqs9

Simple option, but we won't have a version with all improvements

4) implement option 3 and also upload the new pngnqs9 package

But then I am unsure if we need the 2 versions as they are right now
(since pngnqs9 can replace pngnq for now)
Most probably this is the right option to do.

Does anybody have a good idea on how to provide the forked version and
still keep a "pngnq" available for the user, if possible, please?

Thank you!

Best regards,
Nelson


Reply to: