[hipl-dev] Re: binary packaging
- From: Diego Biurrun <diego@xxxxxxxxxx>
- To: hipl-dev@xxxxxxxxxxxxx
- Date: Fri, 05 Nov 2010 18:17:44 +0100
On Fri, Nov 05, 2010 at 07:01:32PM +0200, Miika Komu wrote:
>
> On 11/05/2010 03:36 PM, Diego Biurrun wrote:
>> On Fri, Oct 29, 2010 at 05:11:31PM +0300, Miika Komu wrote:
>>>
>>> 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.
>
> please elaborate? What is wrong with the crypto in HIPL?
Hopefully nothing, but I would not bet :)
>>>>> 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.
>
> Will do :)
Actually it is called
Obsoletes:
I was wondering for a moment there...
Diego
Other related posts:
