quid...@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. -- 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/8562b063me....@boum.org
