[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Wiki changes and discussions at LinuxWorld Expo



On Tue, 2006-10-31 at 14:01 +0000, ext Neil Williams wrote:
> Whilst Wookey and I were at LinuxWorld Expo this year, various emdebian  
> tasks and problems were discussed with other Debian developers. I've  
> tried to document an overview of the consensus reached during those  
> discussions on the Wiki and now's probably a good time to take the  
> ideas to pieces.
> :-)
> 
> Both documents are quite long so I hesitate to post them here in their  
> entirety. The summaries here are not intended to be complete.
> 
> http://wiki.debian.org/NeilWilliams
> My own plans for what I want to achieve from the cross-get script and  
> other associated scripting tasks.
> 
> Summary:
> $ apt-get source foo
> $ cd foo-1.2.3/ && empbuild
> <!--
> 	patch debian/ from emdebian svn,
> 	get dependencies: apt-cross (cross-get using dpkg-cross)
> 	debuild (note: patch is run before debian/rules)
> -->
> $ cd /opt/pbuilder/emdebian/
> $ dput emdebian foo_1.2.3-1em1_arm.changes
> 
> http://wiki.debian.org/EmdebianMetaData

I've just read this document and I have a couple of comments about
DEBIAN_DIR chapter:

con: 

      * Needs updated tools (dpkg, debhelper, etc). This has been
        implemented (June 2006) but there is serious resistance to the
        concept from the maintainers of the existing Debian packages
        (dpkg, devscripts). Having to maintain these packages separately
        is a real disadvantage.
Mentioned resistance is the main reason why this scheme isn't accepted,
I think. I'm not surprised, because we had the same resistance from
Debian developers here in Nokia. I don't see any technical reason for
that, and nobody explained me why it's so, but anyway this is what we
have.
Maintaining changes in packaging tools is not a problem at all from my
point of view. It's just about 2-10 packages and changes are very
simple. The main advantage of this approach that it works already and it
allows developers to have full control on packaging.

      * Repetition of info in two or more places 
Not much, I beleive. Only rules and control files in most cases. I don't
think it matters.

      * Generates packages with same names as standard packages but
        different files/functionality/interface - will cause problems if
        mixed with Debian proper, or with different distros using the
        same mechanism.
Not true. It's possible to use any naming scheme because we have our own
control/rules/changelog.
        
      * Debian packages will install, but may not work due to missing
        files.
If different names are used for embedded packages Debian packages will
not install. It's up to emdebian to decide which names to use.

      * Easy for package maintainers to ignore so will get bitrot 
As far as I remember it supposed to be emdebian maintainers who should
keep emdebian changes in synch with Debian ones.


-- 
Ed Bartosh <eduard.bartosh@nokia.com>
Nokia-M/Helsinki



Reply to: