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

Bug#961738: RFS: dragengine/1.1 -- Drag[en]gine Game Engine

Control: tag -1 moreinfo

Hi Roland,

On Fri, May 29, 2020 at 03:13:34PM +0200, Roland Plüss wrote:
> On Fri, 29 May 2020 14:21:03 +0200 Tobias Frost <tobi@debian.org> wrote:
> > On Thu, May 28, 2020 at 11:16:18AM -0400, Boyuan Yang wrote:
> >
> > (..)
> >
> > > There are other issues but I'd rather stop here. Since you yourself is
> > > also the upstream,
> > > it could be possible for you to actually review the software
> > > buildsystem (scons scripts) since it seems
> > > to have diverted from traditional software installation procedures on
> > > UNIX-like platforms. In any case,
> > > the source repository and packaging scripts your provided need
> improvement.
> >
> > It is discouraged to use scons as build system [1]. If you see the
> possiblity
> > please change it to something else, (e.g. cmake)
> >
> > [1] https://wiki.debian.org/UpstreamGuide#SCons
> >
> >
> >
> Switching away from SCons is not an option. As I mentioned on IRC the
> cons against SCons in that article are no cons but incorrectly using
> SCons or not understanding SCons at all. 

I'm not aware of this discussion.

> Like many things in live SCons
> is like a bazooka: if you handle it correctly it gives you a punch like
> nothing else but it doesn't prevent you from pointing it at your own feet.

It is incredible difficult to use scons correctly, as it sometimes lacks proper
default behaviour. Especially in multiarch and crosscompilations scenarios
(which is relevant for Debian). But if you say you can handle it, go ahead.

> If for the debian package improvements are required please tell me

I do not sponsor scons based packages. 

However here's something:
- take a look at the mentors page for your package: there are many lintian
  reportings to fix. Some of them also indicates that your buildsystem is not
  properly building or configured.
- libraries are not built for  Multiarch
- dev-pkg-without-shlib-symlink
- hardening.
- debug-file-with-no-debug-symbols
- dont hardcoding the number of CPUS d/rules, scons _-j8_ )
(- there mihgt be more lintian stuff)

More hints:
- Section X11 is likely wrong. You maybe want games?
- Spelling errors in binary.
- new-package-should-close-itp-bug
- no watch file.
- A game (engine) should not need a postinst. As said, /opt is off limit for packages. Don't addgroup games.
- What is about those extern/ directory? There are tarballs… e.g fox*.tar.bz.
  You can't have embedded code copies, if they are not in Debian they need to
  be packaged. You should remove the complete extern folder using Files-Exclude, if
  possible. (The source package is 46MiB…)
- Where are the fonts in e.g deige/shared/data/data/fonts from? What is the copyright?
  Same for the icons?
- You package does not build in a pbuilder enviornment. Missing
  Build-Dependencies (B-D) e.g on scons.
- A ton of other B-Ds are also missing (assuming extern lists the libraries you

Looking at your repo:
https://github.com/LordOfDragons/dragengine/blob/debian/debian/rules lines 34-41
(you maybe want a install target? It should honour $DESTDIR, though)
looks quite weird. Also lines 27-29 are weird (clean target not working?)
Line 53-58 looks fishy to me.

> and I'll apply the required changes but I will not go back to makefiles.

For sure you know that cmake is a buildsystem generator. It can
to create Makefiles, but it does not need to.

Ok, I found many issues by only barley looking, so I marked the RFS as "moreinfo".
Please fix the issues and then remove the "moreinfo" tag to have the indication for
sponsors to take a look again. Please read also the "upstream guide" I posted earlier,
it contains important information who to package software distribution friendly.


> -- 
> Mit freundlichen Grüssen
> Plüss Roland
> Game Development and Game Engine Technologies https://dragondreams.ch

Reply to: