Hi Ritesh,
Thank you for your remarks,
On Mon, 05 Sep 2016 17:28:21 +0530, Ritesh Raj Sarraf wrote :
You can keep a generic debian/ packaging folder if you want. But
you'd want to
have it as generic as possible. So that all .deb distributions could use it. It
would have nothing much to do with Debian distribution in particular. And you
may still have some Debian packager requesting for its removal.
I had mentioned the same to Jerome earlier.
I am not necessarily in favor of keeping a debian/ packaging folder
upstream. We have some people that want to install targetcli-fb as a
Debian package. Since targetcli-fb is not part of Debian testing/stable
yet, we maintain a debian/ folder upstream so that they can build the
package themself.
But once targetcli-fb will be part of the Debian repository, people
will naturally install it from Debian with `apt`. At this time, we may
remove (or rename) the debian/ directory upstream.
In the upstream README.md, we may emphasize that packages for
targetcli-fb exist for Fedora, Suse and (soon) Debian and that this is
the preferred way to install targetcli-fb.
Note: What you do with the debian/ packaging in the upstream
repository will be
independent and unrelated of the packaging in Debian itself.
I understand. I hope that packaging in Debian can leverage my patches
upstream. After that, I would like to help you and Christian with
packaging in Debian.
This thread's intent is to replace the Datera LIO stack with that
of -fb ones,
for Debian. It is taking time, on my part, for personal reasons. And since I've
been maintaining it alone, the progress is slow. I'm hoping I'll have more
Debian contributors working on it soon, until then it'll have to wait.
The current version in Unstable (Datera one) took some time before it became
quite bug free. And that's why I'm not hurrying much. Lots of people are using
it as a stand-by target for most of their software testing.
The rest of the changes in your pull request look fine, except for the
versioning one.
Currently, in Debian, we have:
python-rtslib-fb:
Installed: (none)
Candidate: 2.1.57+debian-3
and
python-rtslib:
Installed: (none)
Candidate: 1:3.0~pre4.1~g1b33ceb-3
And Thomas did that because Openstack added a dependency on rtslib-fb.
So, I'd suggest you keep your (upstream) packaging as generic as possible. And
push the onus on the user to ensure there is no other copy installed, from
elsewhere.
I am confused by what "versioning" means here. Is that version number
(i.e. "2.1.57" or "2.1.fb57"), package name
("python-configshell" or
"python-configshell-fb"), or conflicts?
BTW, Are you doing the same with Fedora ?
I see your spec file and it looks outdated to me.
No. Andy Grover maintains packages for Fedora, so packaging work for
Fedora happens in Fedora (same for Suse I think). That's why the spec
file upstream has been left behind.
http://pkgs.fedoraproject.org/cgit/rpms/targetcli.git/
And likewise, I think that packaging work for Debian should happen in
Debian.
With best regards,
--
Christophe Vu-Brugier