Re: ddebs
Le samedi 26 mars 2011 à 08:38 +, Emilio Pozuelo Monfort a écrit : > I have just skimmed over the dicussions from 2009 where we decided that it > should be one ddeb per source package, and it seems that everyone preferred > one > ddeb per binary package except the ftpmasters :) So that's fine with me. You already know that, but for those who haven’t followed the discussions: several binaries built from the same source package can share the same build ID (which cannot happen in different source packages). Hence the need for what follows. > I'd also mandate the use of build-ids for .ddebs and add refcounting support > (like has been done for multiarch AFAIK) to dpkg for them, so we don't need to > worry about Conflicts / Replaces. -- .''`. : :' : “You would need to ask a lawyer if you don't know `. `' that a handshake of course makes a valid contract.” `--- J???rg Schilling -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1301175428.6724.107.camel@pi0307572
Re: ddebs
On 26/03/11 09:10, Raphael Hertzog wrote: > On Sat, 26 Mar 2011, Emilio Pozuelo Monfort wrote: >> I'd also mandate the use of build-ids for .ddebs and add refcounting support >> (like has been done for multiarch AFAIK) to dpkg for them, so we don't need >> to >> worry about Conflicts / Replaces. > > For multi-arch, it's the _same_ package (but just another architecture of it) > that > can share _identical_ files and where we have refcounting. > > This can't be generalized to just any package, it's just contrary to the > logic of our packaging tools. > > When do you have such conflicts? I hear when you have the same binary in > multiple package... but in that case both packages already conflict and > you can just copy the existing conlict field and add the -ddeb suffix. Not necessarily, e.g. you can have the same binary in different paths, or with different names. > Otherwise maybe there's a way to include the package name in the path > to avoid such conflicts? I don't think so. Otherwise gdb wouldn't know where to look for it. Emilio -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d8db383.7010...@debian.org
Re: ddebs
On Sat, 26 Mar 2011, Emilio Pozuelo Monfort wrote: > I'd also mandate the use of build-ids for .ddebs and add refcounting support > (like has been done for multiarch AFAIK) to dpkg for them, so we don't need to > worry about Conflicts / Replaces. For multi-arch, it's the _same_ package (but just another architecture of it) that can share _identical_ files and where we have refcounting. This can't be generalized to just any package, it's just contrary to the logic of our packaging tools. When do you have such conflicts? I hear when you have the same binary in multiple package... but in that case both packages already conflict and you can just copy the existing conlict field and add the -ddeb suffix. Otherwise maybe there's a way to include the package name in the path to avoid such conflicts? Cheers, -- Raphaël Hertzog ◈ Debian Developer Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110326091057.gb32...@rivendell.home.ouaza.com
Re: ddebs
On 26/03/11 08:07, Torsten Werner wrote:
> On Fri, Mar 25, 2011 at 11:43 PM, Emilio Pozuelo Monfort
> wrote:
>> The way I did it was one .ddeb per source package, not per binary. So it is
>> $src-ddeb. You can reject them if they are not for $src package (or if $src
>> package doesn't exist in the archive).
>
> To simplify the archive processes i would prefer having a ddeb per
> binary package instead of source package. It must have the name
> $binary-ddeb and must have the same version as $binary. The ddebs will
> get separate Packages files similar to the udebs. It is even easier
> for our users that they don't need to find out the source package
> name. Can we agree on that?
I have just skimmed over the dicussions from 2009 where we decided that it
should be one ddeb per source package, and it seems that everyone preferred one
ddeb per binary package except the ftpmasters :) So that's fine with me.
I'd add to the requirements that foo-ddeb needs to Depend on foo (=
${binary:Version}).
I'd also mandate the use of build-ids for .ddebs and add refcounting support
(like has been done for multiarch AFAIK) to dpkg for them, so we don't need to
worry about Conflicts / Replaces.
Cheers,
Emilio
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4d8da614.30...@debian.org
Re: ddebs
On Fri, Mar 25, 2011 at 11:43 PM, Emilio Pozuelo Monfort wrote: > The way I did it was one .ddeb per source package, not per binary. So it is > $src-ddeb. You can reject them if they are not for $src package (or if $src > package doesn't exist in the archive). To simplify the archive processes i would prefer having a ddeb per binary package instead of source package. It must have the name $binary-ddeb and must have the same version as $binary. The ddebs will get separate Packages files similar to the udebs. It is even easier for our users that they don't need to find out the source package name. Can we agree on that? Cheers, Torsten -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/AANLkTinQanOtm_Ua_=usmudt9mpfuttykggr6d_ih...@mail.gmail.com
Re: ddebs
On 25/03/11 23:13, Philipp Kern wrote:
> Are there dependencies from the -ddeb to the binary? Because you'd want to
> update/upgrade your ddeb when you update the library, otherwise it becomes
> useless. I imagine there can't be given that the binaries of our source
> package might not be co-installable.
This is handled by
# If the ddeb appears in the control file, we let the
# packager override our defaults there.
my $arch=package_arch($package);
my $srcpackage=sourcepackage();
my $depends="";
foreach my $pkg (getpackages("same")) {
if ($pkg ne $package) {
addsubstvar($package,"ddeb:Conflicts","$pkg","<<
\${binary:Version}");
addsubstvar($package,"ddeb:Conflicts","$pkg",">>
\${binary:Version}");
$depends="$depends | $pkg (= \${binary:Version})";
}
}
$depends=~s/^ \| //;
addsubstvar($package,"ddeb:Depends","$depends","");
> Is there a rationale why this was done differently from Ubuntu?
There probably was, though I don't remember it. You can search in the
debian-devel archives on July and August 2009.
Cheers,
Emilio
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4d8d26d3.6080...@debian.org
Re: ddebs
On 2011-03-25, Emilio Pozuelo Monfort wrote: > On 25/03/11 22:24, Torsten Werner wrote: >> On Fri, Mar 25, 2011 at 10:54 PM, Emilio Pozuelo Monfort >> wrote: >>> http://people.debian.org/~pochu/debhelper_8.1.2+nmu1_all.deb >> Thanks. The name of the ddeb for gzip is gzip-ddeb. Can we rely on >> that schema or is there another way to find the name of a deb package >> from its ddeb package? Rationale: whenever a ddeb gets uploaded we >> need to check if there is already a matching deb in the archive (or at >> least in the same upload). If not we will reject the upload. > The way I did it was one .ddeb per source package, not per binary. So it is > $src-ddeb. You can reject them if they are not for $src package (or if $src > package doesn't exist in the archive). Are there dependencies from the -ddeb to the binary? Because you'd want to update/upgrade your ddeb when you update the library, otherwise it becomes useless. I imagine there can't be given that the binaries of our source package might not be co-installable. Is there a rationale why this was done differently from Ubuntu? Kind regards Philipp Kern -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrnioq8dg.2ji.tr...@kelgar.0x539.de
Re: ddebs
On 25/03/11 22:24, Torsten Werner wrote: > On Fri, Mar 25, 2011 at 10:54 PM, Emilio Pozuelo Monfort > wrote: >> http://people.debian.org/~pochu/debhelper_8.1.2+nmu1_all.deb > > Thanks. The name of the ddeb for gzip is gzip-ddeb. Can we rely on > that schema or is there another way to find the name of a deb package > from its ddeb package? Rationale: whenever a ddeb gets uploaded we > need to check if there is already a matching deb in the archive (or at > least in the same upload). If not we will reject the upload. The way I did it was one .ddeb per source package, not per binary. So it is $src-ddeb. You can reject them if they are not for $src package (or if $src package doesn't exist in the archive). Cheers, Emilio -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d8d1a9f.5030...@debian.org
Re: ddebs
On Fri, Mar 25, 2011 at 10:54 PM, Emilio Pozuelo Monfort wrote: > http://people.debian.org/~pochu/debhelper_8.1.2+nmu1_all.deb Thanks. The name of the ddeb for gzip is gzip-ddeb. Can we rely on that schema or is there another way to find the name of a deb package from its ddeb package? Rationale: whenever a ddeb gets uploaded we need to check if there is already a matching deb in the archive (or at least in the same upload). If not we will reject the upload. Torsten -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/AANLkTimoQQoD6M5qT8CFU908fJF4st=rtpygmcznk...@mail.gmail.com
Re: ddebs
On 25/03/11 21:46, Torsten Werner wrote: > Thanks for the explaination. > > On Fri, Mar 25, 2011 at 10:38 PM, Emilio Pozuelo Monfort > wrote: >> Apply the attached patch to debhelper (applies cleanly on debhelper 8.1.2). > > May I download a pre-built debhelper from somewhere? http://people.debian.org/~pochu/debhelper_8.1.2+nmu1_all.deb And you'll also need http://people.debian.org/~pochu/ptools/ptools_0.1-1_amd64.deb Cheers, Emilio -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d8d0ef9.7090...@debian.org
Re: ddebs
Thanks for the explaination. On Fri, Mar 25, 2011 at 10:38 PM, Emilio Pozuelo Monfort wrote: > Apply the attached patch to debhelper (applies cleanly on debhelper 8.1.2). May I download a pre-built debhelper from somewhere? Thanks, Torsten -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktikc_stw4rkp6etvqqomzyh-o+6phf8z1j6ax...@mail.gmail.com
Re: ddebs
On 25/03/11 18:22, Torsten Werner wrote:
> are there any example packages that build ddebs? That we can use for
> testing dak?
It should happen automatically if you patch debhelper (and CDBS to automatically
get .ddebs out of CDBS-using packages) with my patches. I have just refreshed my
debhelper patch so it applies cleanly again, and I've tested it.
What you need:
ptools (for build-id support, should be easy to remove that part from my patch,
see the pbuildid call in dh_strip). I've put it in [1].
Apply the attached patch to debhelper (applies cleanly on debhelper 8.1.2).
Install the resulting debhelper and build any package that
- produces at least one arch:any package
- doesn't have a -dbg package
E.g. I've tested it with gzip. Just dpkg-buildpackage it with the new debhelper
installed and you'll get:
[...]
dpkg-deb: building package `gzip-ddeb' in `../gzip-ddeb_1.3.12-9_amd64.ddeb'.
$ dpkg --contents gzip-ddeb_1.3.12-9_amd64.ddeb
drwxr-xr-x root/root 0 2011-03-25 21:21 ./
drwxr-xr-x root/root 0 2011-03-25 21:21 ./usr/
drwxr-xr-x root/root 0 2011-03-25 21:21 ./usr/share/
drwxr-xr-x root/root 0 2011-03-25 21:21 ./usr/share/doc/
drwxr-xr-x root/root 0 2011-03-25 21:21 ./usr/share/doc/gzip-ddeb/
-rw-r--r-- root/root 24028 2007-04-13 22:41
./usr/share/doc/gzip-ddeb/changelog.gz
-rw-r--r-- root/root 1101 2011-03-25 20:54
./usr/share/doc/gzip-ddeb/copyright
-rw-r--r-- root/root 6637 2011-03-25 20:54
./usr/share/doc/gzip-ddeb/changelog.Debian.gz
drwxr-xr-x root/root 0 2011-03-25 21:21 ./usr/lib/
drwxr-xr-x root/root 0 2011-03-25 21:21 ./usr/lib/debug/
drwxr-xr-x root/root 0 2011-03-25 21:21 ./usr/lib/debug/.build-id/
drwxr-xr-x root/root 0 2011-03-25 21:21 ./usr/lib/debug/.build-id/93/
-rw-r--r-- root/root151197 2011-03-25 21:21
./usr/lib/debug/.build-id/93/6c3dda20627d866fd42cb8a7b05247d7707367.debug
FWIW, build-id and .ddebs don't need to be done at the same time. The only
problem with build-id is that we could get file conflicts if two packages have
*exactly* the same ELF binary. May happen if you build two flavours of the same
package and one binary isn't affected by the different build flags / options. We
could solve this by making dpkg not complain if this happens, ref-counting the
files so it doesn't remove it until all the packages that shipped that file are
removed. Note that this is hypothetical, and if it happened, it would be the
exception.
Also see http://wiki.debian.org/AutomaticDebugPackages
Let me know if you any questions.
Cheers,
Emilio
[1] http://people.debian.org/~pochu/ptools/ptools_0.1-1.dsc
diff -Nru debhelper-8.1.2/debian/changelog debhelper-8.1.2+nmu1/debian/changelog
--- debhelper-8.1.2/debian/changelog2011-02-14 18:22:19.0 +
+++ debhelper-8.1.2+nmu1/debian/changelog 2011-03-25 20:52:21.0
+
@@ -1,3 +1,10 @@
+debhelper (8.1.2+nmu1) UNRELEASED; urgency=low
+
+ * Non-maintainer upload.
+ * Add ddebs support.
+
+ -- Emilio Pozuelo Monfort Fri, 25 Mar 2011 20:52:10 +
+
debhelper (8.1.2) unstable; urgency=low
* Fix logging at end of an override target that never actually runs
diff -Nru debhelper-8.1.2/debian/control debhelper-8.1.2+nmu1/debian/control
--- debhelper-8.1.2/debian/control 2011-02-10 23:51:37.0 +
+++ debhelper-8.1.2+nmu1/debian/control 2011-03-25 20:50:47.0 +
@@ -10,7 +10,7 @@
Package: debhelper
Architecture: all
-Depends: ${perl:Depends}, ${misc:Depends}, perl-base (>= 5.10), file (>=
3.23), dpkg-dev (>= 1.14.19), html2text, binutils, po-debconf, man-db (>=
2.5.1-1)
+Depends: ${perl:Depends}, ${misc:Depends}, perl-base (>= 5.10), file (>=
3.23), dpkg-dev (>= 1.14.19), html2text, binutils, po-debconf, man-db (>=
2.5.1-1), ptools
Suggests: dh-make
Conflicts: dpkg-cross (<< 1.18), python-support (<< 0.5.3), python-central (<<
0.5.6)
Description: helper programs for debian/rules
diff -Nru debhelper-8.1.2/Debian/Debhelper/Dh_Lib.pm
debhelper-8.1.2+nmu1/Debian/Debhelper/Dh_Lib.pm
--- debhelper-8.1.2/Debian/Debhelper/Dh_Lib.pm 2011-02-10 23:53:58.0
+
+++ debhelper-8.1.2+nmu1/Debian/Debhelper/Dh_Lib.pm 2011-03-25
20:50:12.0 +
@@ -18,7 +18,8 @@
&inhibit_log &load_log &write_log &commit_override_log
&dpkg_architecture_value &sourcepackage
&is_make_jobserver_unavailable &clean_jobserver_makeflags
- &cross_command);
+ &cross_command &is_ddeb &ddeb_filename &ddeb_in_control
+ &ddeb_is_empty &ddebpackage);
my $max_compat=8;
@@ -749,6 +750,9 @@
my $package="";
my $arch="";
my $package_type;
+ my $has_arch_dep=0;
+ my $has_ddeb_pkg=0;
+ my $has_dbg_pkg=0;
my @list=();
ddebs (was: Upcoming FTPMaster meeting)
Hi Josselin, Am -10.01.-28163 20:59, schrieb Josselin Mouette: > Would it be possible to add support for ddebs? are there any example packages that build ddebs? That we can use for testing dak? Cheers, Torsten -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d8cdd7d.1000...@debian.org
