Re: How to handle software which needs huge modification when packaging for Debian
Hi! Am 17.01.2012 02:55, schrieb Adam Borowski: Even binaries that don't have their sources in this package but are shipped somewhere else in Debian are ok. Sorry, but written that way it is wrong.. Or at least could be interpreted wrong. For _everything_ Debian ships in main we must have the corresponding source code. That means unless you are really, really, really sure, that your binary in package a is really build with sources from package b it's not okay. (Some packages build on a specific foo-source package and therefore use an other packages sources, that's tricky but okay.) Best regards, Alexander -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f1548d6.8030...@debian.org
How to handle software which needs huge modification when packaging for Debian
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi there! How shall software be handled, when it needs - huge modifactions - scripts to be replaced by 'debianized' ones - to be extended by custom scripts or progs when packaging it for debian? Shall the custom / replaced stuff be placed inside debian/source/include-binaries? Or should it be forked from upstream and seperately developed as debian-native? BR, Björn -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAk8UjPIACgkQ3u1SIc8s7PUFXAD/dlexMpz32mX7x//rv7/G4r7P kCoD3EAvpZDdT8yqYGEBAJMNGjPHALsBlDVVlcvCwKSIp8QJ0nZodMtYPYLIRkVk =YXpU -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f148cf7.4040...@googlemail.com
Re: How to handle software which needs huge modification when packaging for Debian
2012/1/17 Björn Esser: - huge modifactions Get those included upstream. - scripts to be replaced by 'debianized' ones Make those scripts generic but configurable, send the required changes upstream and drop in a second configuration file overriding the defaults. - to be extended by custom scripts or progs Not sure what you mean here. Shall the custom / replaced stuff be placed inside debian/source/include-binaries? No, patch the source. Or should it be forked from upstream and seperately developed as debian-native? Here you miss out on future updates from upstream so I would discourage that. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caktje6fo9ieqh4fbdcwxr71swujjcpnyneysrayxreumqce...@mail.gmail.com
Re: How to handle software which needs huge modification when packaging for Debian
2012/1/16 Björn Esser bjoern.es...@googlemail.com: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi there! How shall software be handled, when it needs - huge modifactions Modify original sources in Debian. - scripts to be replaced by 'debianized' ones - to be extended by custom scripts or progs when packaging it for debian? Shall the custom / replaced stuff be placed inside debian/source/include-binaries? Yes, you should replace inside sources, and call it ~dfsg. Let's analyze VirtualBox sources a bit -- a *HUGE* Open-Source project, that was Debianized. (only a bit smaller than Linux-kernel/GCC/LibreOffice) Debian 6: Upstream 3.2.10_OSE = 58 MB Debianized 3.2.10_OSE = 28 MB (DFSG version) This is a *huge* reduction cut by more than one-half of the original. So... what was removed ? A. Windows compatibility -- both binaries and source code were removed. * sources seems to have some Microsoft headers, which is necessary to build it on Windows at all. B. Build tools: Original VBox is cross-platform, so they include a lot of useless-for-Debian and duplicate stuff, such as common libraries: 1. binaries for WIndows to build there: as86, bcc, glib, libxidl, zlib, iconv *Debian doesn't need it. 2. Linux libraries (in source form): libpng, libxml, libxslt, zlib -- they were included in original source code Original: root@xrig:/tmp/virtualbox-ose/VirtualBox-3.2.10_OSE# ls src/libs/ boost-1.37.0 liblzf-3.4libxml2-2.6.30 Makefile.kmk zlib-1.2.1 kStufflibpng-1.2.8 libxslt-1.1.22 xpcom18a4 Debianized: root@xrig:/tmp/virtualbox-ose/virtualbox-ose-3.2.10-dfsg# ls src/libs/ boost-1.37.0 kStuff liblzf-3.4 Makefile.kmk xpcom18a4 *Debian's kmk was patched to use Debian's libs instead. 3. extra source code: (VBoxAdditions) for Windows: was removed. for irrelevant Linux versions was also removed. For example original have files which are only relevant for XFree86 systems. Original: root@xrig:/tmp/virtualbox-ose/VirtualBox-3.2.10_OSE# ls src/VBox/Additions/x11/x11include/ 1.3 fixesproto-4.0 libXcomposite-0.4.0 xf86driproto-2.1.0 1.4 fontsproto-2.1.0 libXdamage-1.1 xorg-server-1.3.0.0 1.5 glproto-1.4.10 libXfixes-4.0.3 xorg-server-1.5.3 1.6 inputproto-1.4.4 mesa-7.2 xorg-server-1.6.0 4.3 inputproto-1.9.99.902 Mesa-7.5 xorg-server-1.6.0-local 7.0 libdrm-2.0.1 pixman-0.16.0 xorg-server-1.6.99-20090831 7.1 libdrm-2.4.13 randrproto-1.3.0 xorg-server-1.8.0 compositeproto-0.4 libpciaccess-0.10.8renderproto-0.11 xorg-server-1.9.0 damageproto-1.1.0 libx11-1.1.5-other xextproto-7.1.1 xproto-7.0.18 Debianized: root@xrig:/tmp/virtualbox-ose/virtualbox-ose-3.2.10-dfsg# ls src/VBox/Additions/x11/x11include/ 1.4 mesa-7.2 In short, you see: 1. binaries must be dropped 2. support for old libraries can be dropped (at your choice, XFree86 case) 3. support for duplicate libraries, that are included in Debian NOTE: * You cannot force upstream to drop support for Windows, or binary tools that help them build their tree on Windows. (although you can ask them to separate some Windows build binaries into a separate package) * You cannot force upstream to drop support for old Linux systems, including those that use XFree86. * No need to fork in most cases. It can be done without forking, but it's difficult task. I suggest you to download virtualbox-ose-3.2.10-dfsg source from Debian 6, compare it to upstream, and learn from this extreme case of Debianization. Upstream sources: http://download.virtualbox.org/virtualbox/3.2.10/VirtualBox-3.2.10-OSE.tar.bz2 Makefiles were patched heavily. Basically if you remove stuff from upstream, then you do it in original file, like: virtualbox-ose_3.2.10-dfsg.orig.tar.gz But if you add or modify stuff, you do it via patch, like: virtualbox-ose_3.2.10-dfsg-1.diff.gz I hope this example was helpful. Best wishes, -- -Alexey Eromenko Technologov -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAOJ6w�t3cgwv-pk5z-an7e3jg0ot6eqvezdwrpatqebyg...@mail.gmail.com
Re: How to handle software which needs huge modification when packaging for Debian
On Tue, Jan 17, 2012 at 8:28 AM, Alexey Eromenko wrote: Yes, you should replace inside sources, and call it ~dfsg. In general it should be +dfsg not ~dfsg. ~dfsg/+dfsg should only be added when repacking for DFSG-related reasons, so not in this case. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caktje6eqr2w-fyvdgjyshmi9xn+jmfzdt8j5mieau4bce+z...@mail.gmail.com
Re: How to handle software which needs huge modification when packaging for Debian
Alexey Eromenko al4...@gmail.com writes: Yes, you should replace inside sources, and call it ~dfsg. Is the source being repackaged for DFSG reasons? If not, ‘~dfsg’ is a confusing choice. -- \ “Religious faith is the one species of human ignorance that | `\ will not admit of even the *possibility* of correction.” —Sam | _o__) Harris, _The End of Faith_, 2004 | Ben Finney -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87hazv41a4@benfinney.id.au
Re: How to handle software which needs huge modification when packaging for Debian
Is the source being repackaged for DFSG reasons? If not, ‘~dfsg’ is a confusing choice. VirtualBox src ships with binary *.exe, which are forbidden in Debian. I don't know specific paragraphs of violations. But I'm just a Debian-student, not mentor (@_@) -- -Alexey Eromenko Technologov -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAOJ6w=euu1et4vhek5r0+nzyrxguuyguvhtr5ywdnvuesmw...@mail.gmail.com
Re: How to handle software which needs huge modification when packaging for Debian
On Tue, Jan 17, 2012 at 03:00:04AM +0200, Alexey Eromenko wrote: Is the source being repackaged for DFSG reasons? If not, ‘~dfsg’ is a confusing choice. VirtualBox src ships with binary *.exe, which are forbidden in Debian. .exe file are fine, as long as they can be rebuilt with free tools. Even binaries that don't have their sources in this package but are shipped somewhere else in Debian are ok. On the other hand, removing bloat is a good idea, especially if it takes a lot of space. Object code in a (free) source package is by definition bloat. -- 1KB // Yo momma uses IPv4! signature.asc Description: Digital signature
