Bug#675532: RFS: bilibop/0.1 (ITP #675467)
quidame@poivron.org wrote (08 Jun 2012 22:35:21 GMT) :
> OK. But packaging is not a goal in itself, so I think I will
> not send a new version with just (in the changelog):
> * Fix typos, unclear sentences and language errors in
> debian/control, in the documentation and in the comments
> of the scripts and functions.
Well, as you see fit.
> I am waiting:
> - for new comments from you or another DD
> - to find by myself something to optimize in the code
How long do you intend to wait?
>> Another possibility would be to move to non-native and increment the
>> Debian revision number only. In the present case, we would move from
>> 0.2-1 to 0.2-2, which would reflect the actual changes quite better.
> For me, this solution, if it is one, implies a lot of issues:
> For bilibop-common, of course, no problem. With some minor changes,
> maybe bilibop-rules could be fully portable too. But bilibop-lockfs,
> in its actual state, is distribution dependent; it depends on
> initramfs-tools, which is a Debian native source package. If I rewrite
> bilibop-lockfs to make it more portable (i.e to integrate it in the
> 'dracut' infrastructure) it will never be installed on Debian, because
> the default initramdisk builder is initramfs-tools, which conflicts
> with dracut. But maybe I'm wrong and I have a bad overview on this
> issue. Maybe bilibop-lockfs could be only a debian patch. Or what ?
I think it is entirely possible, even though not perfectly elegant, to
turn the package into a non-native one without immediately making the
code distro-independent and well separated between the Debian patch
and the upstream code.
Reply to: