Re: developing .deb packages for embedded systems
thanks for all your replies,
currently i m a newbee in packaging.
Some of the things you guys discussed bounced over me.
But i will read those replies again and again as i start understanding the
details hidden.
i have gone through dpkg_packaging_manual.pdf and presently going through
policy manual and man pages related to dpkg. As it is really important to
understand the usage.
Also i will go through emdebian documentation.
Will get back to you through the very same post, looking forward to a great
discussion ahead.
thanks and regards
varun
Neil Williams-4 wrote:
>
> On Wed, 26 Sep 2007 16:41:32 +0100
> Neil Williams <codehelp@debian.org> wrote:
>
>> On Wed, 26 Sep 2007 15:49:50 +0100
>> Wookey <wookey@wookware.org> wrote:
>>
>> > > Yes - if those changes are to files in debian/* then emdebian-tools
>> > > will pick up those changes. If you mean patches to the upstream
>> source,
>> > > you should use whatever patch system is used by the package and
>> > > implement a patch in debian/patches (or wherever else the package
>> > > stores patches).
>> >
>> > This is an area we need to think about. Nearly every embedded
>> > developer needs to modify a subset of packages, uusally in minor ways,
>> > but sometimes extensively. For emdebian to be really useful it needs
>> > to make this as easy as possible.
>>
>> My first reaction is to consider ways to have the same binary package
>> in the repository for all users to have available for the next upgrade
>> (which may well involve changes in areas unaffected by the embedded
>> changes) and some way to modify the behaviour of that package -
>> preferably upon installation so that the package doesn't have to do
>> lots of configuration stuff every time it runs.
>
> Another problem with that method is a tendency for packages themselves
> to get bigger and bigger. By sticking with one base package from Debian
> and our changes overlaid on top, what we gain from easier builds we may
> lose in increased download times. If the solution to that is just to
> split the device-specific stuff into more and more sub packages, that
> only compounds problems around the size of the apt-cache and dpkg
> status files.
>
> Still, I think (IMHO) that this is preferable to having a dozen or more
> device-specific versions of libgtk+2.0-0 because we would still have
> the problem of the size of the apt-cache and dpkg files but with the
> additional burden of transitions that would become truly scary when
> libfoo depends on libbar but libfoo only has 6 versions and libbar has
> 12.
>
> --
>
>
> Neil Williams
> =============
> http://www.data-freedom.org/
> http://www.nosoftwarepatents.com/
> http://www.linux.codehelp.co.uk/
>
>
>
>
--
View this message in context: http://www.nabble.com/developing-.deb-packages-for-embedded-systems-tf4522170.html#a12914897
Sent from the Debian Embedded mailing list archive at Nabble.com.
Reply to: