Hi,
Le 2012-06-09 15:01, intrigeri a écrit :
quid...@poivron.org wrote (08 Jun 2012 22:35:21 GMT) :
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?
This was not a question of time. Here is the new version:
http://mentors.debian.net/debian/pool/main/b/bilibop/bilibop_0.3.0.dsc
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.
Some tests with other distributions and some investigations in the udev
source package have shown that bilibop-rules is distribution dependant
too: for example, with CentOS or OpenSUSE, usb drives are owned by the
'disk' group.
Bilibop-common is the result of the split of bilibop into
bilibop-rules and bilibop-lockfs (because the first one can be used
only on removable devices, including LiveUSB; and the second one can
be used on any internal or external system except Live). So, I don't
understand the interest/benefit to build a non-native source package
that would be used only on Debian. Surely it is entirely possible,
but I don't think everything possible must be done.
Cheers,
quidame
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/9f984bcbedb01e9a0c2a4b57fcaaf...@poivron.org
