[hipl-dev] Re: binary packaging
- From: Diego Biurrun <diego@xxxxxxxxxx>
- To: hipl-dev@xxxxxxxxxxxxx
- Date: Fri, 05 Nov 2010 14:36:47 +0100
On Fri, Oct 29, 2010 at 05:11:31PM +0300, Miika Komu wrote:
>
> (sorry for late reply due to the Nordsec 2010 conference which I was
> attending)
np
> On 10/27/2010 01:51 PM, Diego Biurrun wrote:
>> What's with the top-posting all of a sudden?
>>
>> On Tue, Oct 26, 2010 at 10:30:23PM +0300, Miika Komu wrote:
>>>
>>> On 26/10/10 20:57, Diego Biurrun wrote:
>> This thing is supposed to be infrastructure software that touches every
>> single packet passing through a machine. For that it needs to become
>> ultrafast and very reliable. At the moment it is neither.
>
> Not really all packets, just the HIP-related ones. Ultrafast and
> reliable calls for testing and performance optimization, not just
> polishing the code base.
Precisely my point, HIPL still has a long way to go there. Let's not
forget that it dabbles in cryptography, a field where it is frightfully
easy to make important mistakes.
>>>> I suggest we rethink if and how we split the HIPL binary packages.
>>>> Is one monolithic package enough? Are hipd and hipfw independent
>>>> enough to be separated?
>>>
>>> I think we should keep the current split with the packages because this
>>> is the way it works in most other standard packages and I assume we want
>>> HIPL to go into a mainstream linux distribution at some point.
>>
>> The thought of HIPL in widespread use scares me ;)
>>
>> Trolling aside, split packages make sense for large software packages
>> or for minimal systems. Standard RPM/DEB packages of HIPL fall in
>> neither category IMO.
>
> HIPL is not large, but we have needed just partial functionality of HIPL
> earlier. Splitting the packages was the most sensible way to me to avoid
> activating some parts of the software. The idea behind the minimal
> package is to provide minimal HIP functionality for the following cases:
>
> 1. Servers that don't need DNS proxy and hipfw
> 2. P2P-SIP over HIP prototype has it's own way of resolving HIs, no need
> for DNS proxy or the LSI support provided by hipfw
OK
>>> Also, P2P-SIP over HIP prototype used just a minimal installation of
>>> HIPL (libs + hipd), so there has been a prior need to select only
>>> certain parts of the software.
>>
>> But the "minimal" package is nonsense. It just depends on hipd and the
>> tools, but the tools are hardly necessary for any installation, much
>> less a minimal one.
>
> "hipconf" is the one really needed from tools. Virtual packages are
> quite common.
So would it make sense to keep hipconf in the hipd package?
>>> I think there's not much benefit of merging the packages. For example, I
>>> see more benefit in migrating from the brittle debbuild script to a
>>> better way of handling the packaging (perhaps on a new branch). After
>>> all, it does not even work on Debian at moment...
>>
>> We should get rid of debbuild, yes. We already have Debian packaging in
>> place, it just needs to be extended. But since we're overhauling the
>> binary packaging infrastructure anyway, it makes sense to rethink now
>> which parts of it are good and which need to be changed.
>>
>> Once we have the RPM infrastructure properly cleaned up, I will tackle
>> the Debian packaging issue. Right now real Debian packaging stuff
>> exists in the debian/ subdirectory, but it builds a single monolithic
>> package.
>
> Go ahead with the monolithic package if you really believe it's the best
> way to go. However, you should then make sure to modify packaging
> correctly so that there is "Replaces: hipl-all, hipl-daemon, .."
> dependency included in the rpm and deb packaging. This way, we can
> ensure a flawless upgrade path from current split packages to the
> monolithic version. If there's naming changes in packaging, please
> remind me to update the installation instructions at hipl.hiit.fi.
Good point, a smooth upgrade path is always nice. Please remind me of
this should my scatterbrained self forget it.
Diego
Other related posts: