Bug#675532: RFS: bilibop/0.1 (ITP #675467)

[quidame@poivron.org]

Hi,

Le 2012-06-08 14:14, intrigeri a écrit :
> quidame@poivron.org wrote (08 Jun 2012 10:46:14 GMT) :
> > 2. Fix typos and other things, add a new changelog entry and 
> > increment
> >    the version number (0.2.1) ?
>
> Yes.
>
> >    In that case, how to deal with the irrelevant or useless
> >    informations of the actual changelog ?
>
> Forget it :)

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.

I am waiting:
- for new comments from you or another DD
- to find by myself something to optimize in the code

> 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 ?

Cheers,
quidame