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

Re: Debian and GNOME, partnership with Helixcode?



[redirected to debian-devel]

On Wed, 15 Mar 2000, Fabien Ninoles wrote:

> On Tue, Mar 14, 2000 at 06:29:06PM -0500, Jaldhar H. Vyas wrote:

> > The KDE packages in CVS contain Debian directories.  They are not always
> > perfect but allow anyone tracking KDE development to build packages.  So
> > for me it doesn't matter that KDE snapshots aren't available directly from
> > Debian.  I can make my own.
> 
> No, that's clearly not enough!
> Packaging for a distribution is not as simple as it seems.
> I always prefer to keep the debian directory separate from
> the original package, which permits me to make debian revisions
> without affecting the release cycle of the program itself.

The great thing about all our stuff being in a seperate directory is that
non-Debian users need not be concerned about it.  It's just a little extra
baggage in the tarball for them.  I don't see why the functionality or
non-functionality of the Debian directory would affect them at all.  For
Debian users synching the upstream and Debian releases is more important.  
But remember Debian, KDE, and GNOME are all public projects.  You can
belong to and contribute to more than one if you like.  A single person
can speak out about Debian issues during the Gnome/KDE release cycles and
Gnome issues during the Debian release cycle.

> Also,
> as Jason pointed out, having the debian tree is not enough to
> for a source to be considered a debian package;

Yes but it's a big start.  Many times we find Debian packages that are not
perfect in their initial release.  It's only after several bug
reports/release that they reach "Debian quality."  They usually do this
pretty quickly because we have lots of vocal users to give input.  I don't
see why other projects cannot take advantage of those same people.

> it should also
> well integrated into a Debian environment. For example, I try
> KDevelop not a long time ago. When I run it, it asked me a lot
> of questions about where *its* files (like documentation) are
> installed, then try to install things under /usr/local then stop
> functionning properly.

Did you report this to the maintainer?  Was he interested in replying?

> Yes, I could surely repair it

repair it and contribute the changes back upstream.

> but a well-behave debian package should mostly be ready to be
> used after installations, with only system and user specific
> configuration needed to be done (good default should be
> provided when possible). So for me, KDevelop wasn't debianized.
> It simply used the Debian tools to compile itself and create
> a compatible binary archives, not a true .deb files.
> 

True but this is still a win for the user.  Kdevelop doesn't get
everything right but at least it follows the Debian file system structure.  
It has the right dependencies.  It registers with the menu system.  
That's at least a little less work that the user has to do than if he is
installing a tarball into /usr/local.

> > There seems to be a lack of communication.  Either the Debian packagers
> > are not contributing their work upstream or the Gnome hackers are refusing
> > to take it.  I'm sure neither group really wants that.
> 
> See my comment previously. I really think that if a developer can't
> follow closely a distribution, she should let the distribution maintainers
> do the work.

Miguel said they didn't make .debs because it was too hard.  What is so
hard that intelligent people can't follow?  We have lots of documentation.  
development tools like dh_make and debhelper, QA tools like Lintian, lot's
and lots of prior art.

Somehow I think the problem is not wanting to do the work not finding it
too difficult.

> However, I'ld like to see a standard meta-info files about
> the package, which had informations necessary to create a packages, like
> compilation commands, files (including informations like documentation,
> binary or data), menu entries (means execution), name, author, copyright
> file, changelog files, daemon, etc... This will really help to create more
> package and even an automated tools (just like autoconf) that generate
> everything needed according to your installation. I'm not sure if it's
> feasible but I'ld thought that a tool like autoconf wasn't possible too
> if I doesn't use it so often ;)
> 

Didn't someone recently do an ITP for a program that let you create
packages in different formats?  If it works well it would be cool.

> > Bad idea.  Individual developers can and probably should work with Helix
> > etc. but Debian as a project should not take a stand for or against any
> > desktop until one clearly emerges as the winner.  (and when and if it
> > does, it will be KDE ha ha.)
> 
> Sorry, I don't see the point to have only one winner?
> 

Say what you like about Windows but having everything use COM as the
underlying architecture is a big plus.  Having two seperate component
architectures (three if I have understood Mozillas XPCOM correctly) is
wasteful and unnecessarily slows the progress of Linux.

-- 
Jaldhar H. Vyas <jaldhar@debian.org>


Reply to: