Bug#155676: md5sums files
On Sun, Mar 7, 2010 at 10:28, Goswin von Brederlow goswin-...@web.de wrote:
Anthony Towns a...@erisian.com.au writes:
Advantages of doing it when uploading:
- provides some sort of double check of what's being uploaded
- saves CPU time on users' machines
- avoids having bad checksums due to the user having bad hardware
(which is one big use case of the files)
Big? It only makes a difference if:
a) the corruption happens as soon as it's written, not after some time
b) the file is too big/the system is too loaded to keep the file in
the page cache
c) the system memory is corrupted just enough to screw the file but
not everything else
Compared to random make install invocations changing files in the
system and similar, that doesn't strike me as a big use case.
In any event, it's fairly easy to generate the checksum in the same
pass as generating the file, see the attached patch. (It's not as easy
to generalise to other hashes as the previous one, unfortunately)
If you're still worried, perhaps about having read() return bogus data
from the .deb that happens to still be valid when passed through
ungzip and untar and after you've already verified the entire file by
md5/sha1/sha256 when downloading, you're getting to the point of
trying to safely install on an actively malicious system, and
nothing's going to make that work.
Cheers,
aj
--
Anthony Towns a...@erisian.com.au
diff -x configure -x '*.m4' -x Makefile.in -urbN dpkg-1.15.5.6/configure.ac dpkg-1.15.5.6-aj/configure.ac
--- dpkg-1.15.5.6/configure.ac 2010-01-08 18:00:34.0 +1000
+++ dpkg-1.15.5.6-aj/configure.ac 2010-03-07 04:38:32.547372468 +1000
@@ -51,6 +51,16 @@
esac])
AC_SUBST(admindir)
+# Allow alternative default hash function
+hashtype=md5
+AC_ARG_WITH(hashtype,
+ AS_HELP_STRING([--with-hashtype=HASH],
+ [hash function to use for .hashes files]),
+[case $with_hashtype in
+ md5|none) hashtype=$with_hashtype ;;
+ *) AC_MSG_ERROR([invalid hashtype specified]) ;;
+esac])
+AC_SUBST(hashtype)
# Checks for programs.
AC_PROG_CC
diff -x configure -x '*.m4' -x Makefile.in -urbN dpkg-1.15.5.6/debian/changelog dpkg-1.15.5.6-aj/debian/changelog
--- dpkg-1.15.5.6/debian/changelog 2010-01-09 04:02:03.0 +1000
+++ dpkg-1.15.5.6-aj/debian/changelog 2010-03-07 04:13:03.171356041 +1000
@@ -1,3 +1,11 @@
+dpkg (1.15.5.6+aj) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * Automatically create /var/lib/dpkg/info/pkg.hashes containing MD5 hashes
+for unpacked files.
+
+ -- Anthony Towns a...@lazuline Sun, 07 Mar 2010 04:12:32 +1000
+
dpkg (1.15.5.6) unstable; urgency=low
* dpkg-source: with format 3.0 (quilt) ensure quilt's .pc directory is
diff -x configure -x '*.m4' -x Makefile.in -urbN dpkg-1.15.5.6/lib/dpkg/buffer.c dpkg-1.15.5.6-aj/lib/dpkg/buffer.c
--- dpkg-1.15.5.6/lib/dpkg/buffer.c 2010-01-09 03:23:06.0 +1000
+++ dpkg-1.15.5.6-aj/lib/dpkg/buffer.c 2010-03-07 15:50:33.379710844 +1000
@@ -60,6 +60,13 @@
case BUFFER_WRITE_MD5:
buffer_md5_init(write_data);
break;
+ case BUFFER_WRITE_DUP:
+ {
+ struct buffer_data *bddup = write_data-arg.ptr;
+ buffer_init(NULL, bddup[0]);
+ buffer_init(NULL, bddup[1]);
+ }
+ break;
}
return 0;
}
@@ -90,6 +97,13 @@
case BUFFER_WRITE_MD5:
buffer_md5_done(write_data);
break;
+ case BUFFER_WRITE_DUP:
+ {
+ struct buffer_data *bddup = write_data-arg.ptr;
+ buffer_done(NULL, bddup[0]);
+ buffer_done(NULL, bddup[1]);
+ }
+ break;
}
return 0;
}
@@ -126,6 +140,14 @@
case BUFFER_WRITE_MD5:
MD5Updatestruct buffer_write_md5ctx *)data-arg.ptr)-ctx), buf, length);
break;
+ case BUFFER_WRITE_DUP:
+ {
+ struct buffer_data *bddup = data-arg.ptr;
+ ret = buffer_write(bddup[0], buf, length, desc);
+ if (ret != length) return ret;
+ ret = buffer_write(bddup[1], buf, length, desc);
+ }
+ break;
default:
internerr(unknown data type '%i' in buffer_write,
data-type);
diff -x configure -x '*.m4' -x Makefile.in -urbN dpkg-1.15.5.6/lib/dpkg/buffer.h dpkg-1.15.5.6-aj/lib/dpkg/buffer.h
--- dpkg-1.15.5.6/lib/dpkg/buffer.h 2010-01-08 18:00:34.0 +1000
+++ dpkg-1.15.5.6-aj/lib/dpkg/buffer.h 2010-03-07 15:53:23.319707965 +1000
@@ -36,6 +36,7 @@
#define BUFFER_WRITE_NULL 3
#define BUFFER_WRITE_STREAM 4
#define BUFFER_WRITE_MD5 5
+#define BUFFER_WRITE_DUP 6
#define BUFFER_READ_FD 0
#define BUFFER_READ_STREAM 1
@@ -52,6 +53,14 @@
buffer_hash(buf, hash, BUFFER_WRITE_MD5, limit)
#if HAVE_C99
+# define fd_fdmd5(fd1, fd2, hash, limit, ...) \
+ do { \
+ struct buffer_data fdhash[2]; \
+fdhash[0].arg.i = fd2; fdhash[0].type = BUFFER_WRITE_FD; \
+fdhash[1].arg.ptr = hash; fdhash[1].type = BUFFER_WRITE_MD5; \
+buffer_copy_IntPtr(fd1, BUFFER_READ_FD, fdhash, BUFFER_WRITE_DUP, \
+ limit, __VA_ARGS__); \
+} while(0)
# define fd_md5(fd, hash, limit
Bug#155676: md5sums files
(I'm not subscribed to this list, so go ahead and Cc me)
On Thu, Mar 4, 2010 at 02:05, Peter Samuelson pe...@p12n.org wrote:
[Wouter Verhelst]
I must say I was somewhat surprised by these numbers. Out of 2483
packages installed on my laptop, 2340 install md5sums.
The surprising part, perhaps, is that dpkg itself didn't just generate
the other 143 md5sums files at installation time.
The easy (and usually correct) reason for things like that is dpkg's
source is scary.
I suggested this a long time ago and of course was met with so where's
your patch? Of course I was not willing to do the work.
See? Anyway, my patch is attached. It makes dpkg create a foo.hashes
when unpacking foo, whose contents looks like:
MD5:32b5e22f8e336b2f34e0dd87652e6dfc usr/share/doc/mawk/changelog.gz
MD5:87a34f1f55ac3f7fec2c7fc82565e8eb usr/share/doc/mawk/changelog.Debian.gz
...
Verification is a matter of something like:
$ cat /var/lib/dpkg/info/*.hashes | sed -n 's/^MD5://p' | (cd /;
md5sum -c) | grep -v ': OK$'
There's an option (--hash) that you can set to none to avoid
spending time calculating md5s if you so choose. Adding support for
sha1/sha256/whatever should be straightforward; afaik dpkg only has
code for md5 already built in though (though just invoking
/usr/bin/sha1sum etc would be an option of course).
Of course another option is just to pull the md5sums directly from the deb:
$ ar p /var/cache/apt/archives/ifupdown_0.6.9_i386.deb data.tar.gz |
tar --to-command='printf %s%s\n $(md5sum - | sed s/-$//)
${TAR_FILENAME#./}' -xzf - |
diff - /var/lib/dpkg/info/ifupdown.md5sums
1,3d0
346208729633adf45e2fa3f2bd3b19c6 etc/init.d/ifupdown
c6fffaae03271f1641920105ce68796b etc/init.d/ifupdown-clean
fab851ca87c5deb9d6f665e610184648 etc/default/ifupdown
4a2
a0f11cf1809a468c49b72e0aa0a8e26b sbin/ifup
(md5sums doesn't normally list conffiles, but does list hardlinks; the
above command does the opposite)
But
fundamentally, shipping a md5sums file is really just a tradeoff in
download size vs. installation speed, not unlike gzip vs. bzip2.
Advantages of doing in when unpacking:
- choice of checksum is the admin's decision
- we can quickly roll out support for sha1/sha256/crc/... checksums
by just changing one package
- admin has hashes of exactly what was unpacked, no matter the source
- no concerns about bugs in dh_md5sums or similar resulting in bad checksums
Advantages of doing it when uploading:
- provides some sort of double check of what's being uploaded
- saves CPU time on users' machines
For me, I'd rather have dpkg generate the hashes.
Cheers,
aj
--
Anthony Towns a...@erisian.com.au
diff -urb dpkg-1.15.5.6/debian/changelog dpkg-1.15.5.6-aj/debian/changelog
--- dpkg-1.15.5.6/debian/changelog 2010-01-09 04:02:03.0 +1000
+++ dpkg-1.15.5.6-aj/debian/changelog 2010-03-07 04:13:03.171356041 +1000
@@ -1,3 +1,11 @@
+dpkg (1.15.5.6+aj) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * Automatically create /var/lib/dpkg/info/pkg.hashes containing MD5 hashes
+for unpacked files.
+
+ -- Anthony Towns a...@lazuline Sun, 07 Mar 2010 04:12:32 +1000
+
dpkg (1.15.5.6) unstable; urgency=low
* dpkg-source: with format 3.0 (quilt) ensure quilt's .pc directory is
diff -urb dpkg-1.15.5.6/configure.ac dpkg-1.15.5.6-aj/configure.ac
--- dpkg-1.15.5.6/configure.ac 2010-01-08 18:00:34.0 +1000
+++ dpkg-1.15.5.6-aj/configure.ac 2010-03-07 04:38:32.547372468 +1000
@@ -51,6 +51,16 @@
esac])
AC_SUBST(admindir)
+# Allow alternative default hash function
+hashtype=md5
+AC_ARG_WITH(hashtype,
+ AS_HELP_STRING([--with-hashtype=HASH],
+ [hash function to use for .hashes files]),
+[case $with_hashtype in
+ md5|none) hashtype=$with_hashtype ;;
+ *) AC_MSG_ERROR([invalid hashtype specified]) ;;
+esac])
+AC_SUBST(hashtype)
# Checks for programs.
AC_PROG_CC
diff -urb dpkg-1.15.5.6/src/Makefile.am dpkg-1.15.5.6-aj/src/Makefile.am
--- dpkg-1.15.5.6/src/Makefile.am 2010-01-09 03:23:06.0 +1000
+++ dpkg-1.15.5.6-aj/src/Makefile.am 2010-03-07 04:28:18.771356095 +1000
@@ -6,6 +6,7 @@
AM_CPPFLAGS = \
-DLOCALEDIR=\$(localedir)\ \
-DADMINDIR=\$(admindir)\ \
+ -DHASHTYPE=\$(hashtype)\ \
-idirafter $(top_srcdir)/lib/compat \
-I$(top_builddir) \
-I$(top_srcdir)/lib
diff -urb dpkg-1.15.5.6/src/main.c dpkg-1.15.5.6-aj/src/main.c
--- dpkg-1.15.5.6/src/main.c 2010-01-09 03:23:06.0 +1000
+++ dpkg-1.15.5.6-aj/src/main.c 2010-03-07 04:29:59.271360858 +1000
@@ -187,6 +187,7 @@
const char *admindir= ADMINDIR;
const char *instdir= ;
struct pkg_list *ignoredependss = NULL;
+const char *hashtype= HASHTYPE;
static const struct forceinfo {
const char *name;
@@ -516,6 +517,7 @@
{ admindir, 0, 1, NULL, admindir, NULL, 0 },
{ instdir, 0, 1, NULL, instdir, NULL, 0 },
{ ignore-depends,0, 1, NULL, NULL, ignoredepends, 0 },
+ { hash, 0, 1, NULL
Re: 3.0 (git) experimental
On Mon, Apr 14, 2008 at 03:10:08PM +0200, Raphael Hertzog wrote: The custom format in particular is unlikely to ever be accepted, it seems to me; The custom format is not a format. From the manpage: SOURCE PACKAGE FORMATS Format: 1.0 ... Format: 2.0 ... Format: 3.0 ... ... Format: 3.0 (custom) If it's not a format, it shouldn't be under the SOURCE PACKAGE FORMATS section... I suspect 2.0 is entirely obsolete at this point; It is. The manual page says This format is not recommended for wide-spread usage, the format 3.0 (quilt) replaces it. not recommended is a fair bit short of obsolete. 3.0 (native) used with gzip compression will result in Format: 1.0 packages as they are exactly the same than native packages that we know right now. Augh. This is really badly structured then -- you're conflating the source package format (ie, what goes on the archive, and what you unpack) with the dpkg internals of how to generate them *when they don't even work the same way*. Urgh. I'm not promoting it as version control format/system. I just promote it as a good source package format: ie a snapshot of a software that has been debianized. As I think I've already said, I consider a source package format to *be* a version control system. If you don't agree, that's fine; but you still shouldn't be promoting one source format over another. I don't see any win over the current situation [...] Yet we have enumerated quite a few drawbacks: [...] It's great you've got an opinion; but that's all it is -- dpkg supports them all, various archives will support whatever their admins decide is reasonable, and developers will choose whichever they thing's best for their packages. Cheers, aj signature.asc Description: Digital signature
Re: 3.0 (git) experimental
On Sat, Apr 12, 2008 at 10:04:03AM +0200, Raphael Hertzog wrote: On Fri, 11 Apr 2008, Joey Hess wrote: Could the maintainers clarify what criteria are used to mark a given source format such as 3.0 (git) as experimental? I hope it doesn't come down to one member of the dpkg team's personal preference. Well, I wrote the manual page, so it was my decision but I believe it's backed up by my opinion and the one expressed by Guillem: Instead I chose to mark them as experimental to show that we don't believe that they are ready to be used in large-scale (like, say, on ftp-master). Uh, whether they're ready to use on ftp-master isn't up to just the dpkg team. And if that were the reason to mark them experimental, then Format: 2.0, Format: 3.0 (native), Format: 3.0 (quilt) and Format: 3.0 (custom) should all have been marked experimental too. The custom format in particular is unlikely to ever be accepted, it seems to me; I suspect 2.0 is entirely obsolete at this point; and for most packages, it's better to choose 1.0 over 3.0 (native) because it can be unpacked by more people; which mostly leaves the manpage promoting quilt as the bestest version control format over git and bzr. Not impressive. Heck, in /my/ opinion, all of 2.0, native, quilt and custom are less likely to be accepted on ftp-master as they currently stand -- native git and bzr support is a much bigger win than any of the others over what we can currently do. A fairer summary would seem to be: Format: 1.0 Default format. (native and orig+diff) Format: 2.0 Obsolete experimental format. Format: 3.0 (git), (bzr), (quilt) Native support for the git, bzr and quilt version control systems. Format: 3.0 (native) Expansion of 1.0 native format to support more compression types. Format: 3.0 (custom) For experimentation with new formats. Cheers, aj signature.asc Description: Digital signature
Re: dpkg semi-hijack - an announcement (also, triggers)
On Sun, Mar 09, 2008 at 07:52:28PM +0100, Raphael Hertzog wrote: On Sun, 09 Mar 2008, Raphael Hertzog wrote: On Sun, 09 Mar 2008, Ian Jackson wrote: With this message I am unilaterally declaring myself a maintainer of dpkg, and also declaring that Guillem is no longer a maintainer. For the record, Ian has been removed from the dpkg group on Alioth and we asked for an UNACCEPT of his upload, but I'm not sure it will be done on time as none of the ftpmasters responded yet to my queries on IRC. The package got unaccepted by Anthony Towns. Beyond that, any additional uploads of dpkg will be REJECTed until you guys resolve this nonsense. Flamewars on -devel, ignoring functional patches for months on end, package hijacks and requests for UNACCEPTs aren't the way to maintain dpkg. Cheers, aj signature.asc Description: Digital signature
Re: dpkg semi-hijack - an announcement (also, triggers)
On Sun, Mar 09, 2008 at 10:38:44PM -0500, Steve Greenland wrote: On 09-Mar-08, 19:30 (CDT), Daniel Stone [EMAIL PROTECTED] wrote: I was going to ask on which grounds exactly you were judging the dpkg team's competence (and that of iwj's: have you reviewed the branch yourself? can you confidently say that it's all fine?), The problem is not the dpkg team has reviewed the patch and had problems with it, it's that they've ignored it for 6 months. That's not the full picture. Ian's been trying to be involved in the dpkg team for longer than six months, and not been incredibly effective at that; eg from July: I will of course be careful about controversial changes. For example, I'll refrain from committing my formatting fixup from #375711 until we've come to a conclusion. I hope you can trust my judgement about what would be a controversial change. -- http://lists.debian.org/debian-dpkg/2007/07/msg00013.html Ian then reposted the triggers spec and published a git tree for the patch, with the following comment: I'd appreciate it if no-one reformatted it or change the style. If you have disagreements with the code please discuss it here on the list before making any changes. Checking a significantly changed version into the main Debian git will cause snarl-ups because our merges will constantly need resolving. -- http://lists.debian.org/debian-dpkg/2007/08/msg00014.html -- http://lists.debian.org/debian-dpkg/2007/08/msg9.html Ian then reimplemented the status file parsing using flex, in a way he reported was faster, but hadn't tested, and suggested it get included in sid. I have written over the weekend a replacement for lib/fields.c and most of lib/parse.c, which uses flex (and flex start conditions) to generate a table-driven scanner-cum-parser. I haven't tested this fully for correctness yet, but I have done basic functionality tests and some performance tests. ... The downside is that it's 100K longer in code size. ... Anyway, I think we should deploy the flex-based scanner in sid (after I've tested it a bit more) and then think at our leisure about how to improve the shared code situation. -- http://lists.debian.org/debian-dpkg/2007/08/msg00028.html Guillem replied to that patch within about four days, but the git tree Ian developed it in was based on the triggers tree, so can't be easily merged independently. In October, Joey proposed his v3 source package format, which is one of the other major outstanding patches. I don't believe it has any stylistic problems, but it still seems to be being reinvented/redisgned, rather than being applied. -- http://lists.debian.org/debian-dpkg/2007/10/msg9.html -- http://lists.debian.org/debian-dpkg/2008/02/msg00012.html http://lists.debian.org/debian-dpkg/2008/02/msg00079.html http://lists.debian.org/debian-dpkg/2008/02/msg00131.html Also in October, Colin Watson asked what the status of triggers was. Ian replied: The implementation of triggers is not going to change incompatibly. It's well-tested now in Ubuntu and should just be merged into Debian's dpkg. -- http://lists.debian.org/debian-dpkg/2007/10/msg00107.html Guillem replied to that: Err, well of course it's highly desirable to not do such kind of changes without good reason, but I don't think the fact that it has been deployed in a derivative distro means that we should blindly merge any such code drops without review and/or possible changes. -- http://lists.debian.org/debian-dpkg/2007/10/msg00132.html Ian replied to that: Don't be ridiculous. This is offensive to me personally. This code has been * designed with extensive input from this mailing list in Debian fora * written by dpkg's original maintainer * tested extensively * available for merging for several months -- http://lists.debian.org/debian-dpkg/2007/10/msg00138.html Guillem didn't reply to that; his next comment on triggers a couple of weeks later was, in response to Ian: This isn't a matter of preference, I'm afraid. I reverted this because the change was wrong. NULL is incorrect in that context (a stdarg function expecting a char*), because it may be #define'd to 0. That's true, but then I agree with others [0] that an environment that defines NULL to 0 (even if the standard allows that) is not sane. Such ancient environment will also not be able to cope with modern software like gtk, anyway. [0] http://lwn.net/Articles/93577/ -- http://lists.debian.org/debian-dpkg/2007/10/msg00228.html There were a couple of messages that sounded promising in regards to a productive conclusion at the end of that month: -- http://lists.debian.org/debian-dpkg/2007/10/msg00230.html -- http://lists.debian.org/debian-dpkg/2007/10/msg00231.html Nothing much happened in Nov or Dec; both Ian and Guillem posted about random other stuff, a
Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
On Tue, Mar 04, 2008 at 11:46:53AM -0800, Mike Bird wrote: On Tue March 4 2008 10:44:22 Ian Jackson wrote: Of course this triggers feature has a proper specification. It was discussed and agreed on debian-dpkg and now resides in the doc/ subdirectory of my dpkg triggers tree, which is what Raphael is refusing to allow me to merge. Raphael seems to have the power to block your packages but he has no rational excuse. Can the tech committee overrule Raphael or does Debian need to fork a dpkg under more sensible maintainers? Well, I guess the tech ctte has been asked to deal with a developer creating tediously long threads about joining another team while not wanting to follow their guidelines before... Cheers, aj signature.asc Description: Digital signature
Re: [sourcev3] Mapping between Format and Dpkg::Source::Package object
On Fri, Feb 29, 2008 at 06:23:03PM +0100, Raphael Hertzog wrote:
The logic of the mapping is quite simple, explanation by example:
Format: 1.0 = Dpkg::Source::Package::V1_0
Format: 3.0 (git) = Dpkg::Source::Package::V3_0::git
Ideally I'd like each object to implement a single logic of
extraction/build of the source package. However Format: 1.0 contains
two logics: native (single tar) and non-native (orig.tar + diff)
and it's restrained to gzip compression for everything.
Sounds like you shouldn't be naming them after the version number then.
Having Dpkg::Source::Package include `native', `origdiff', `wignpen',
`git', `bzr', would seem more sensible; then you'd just need to delegate
to them directly.
Personally, I'd be inclined to go with something asking each known format
if they can extract the package, with something like:
package Dpkg::Source::Package::wignpen;
sub can_extract {
my $dsc = shift;
my $src = $dsc-{Source};
my $ver = $dsc-{Version};
my $up;
my $formats = tar\.bz2|tar\.gz|zip;
$up = $ver;
$up = s/-[^-]*$//;
return 0 if (format_at_least($dsc-{Format}, 2, 0));
# Valid file formats for foo 1.0-2 are:
# foo_1.0.orig.tar.gz
# foo_1.0.orig-blah.tar.gz
# foo_1.0-2.debian.tar.gz
my $foundfile = 0;
foreach my $f ($dsc-{Files}) {
$f =~ s/^.* //;
$foundfile = 1;
next if ($f !~ m/^\Q$src\E_\Q$up\E\.orig\.($format)$/);
next
if ($f !~ m/^\Q$src\E_\Q$up\E\.orig-[a-z0-9]+\.($format)$/);
next if ($f !~ m/^\Q$src\E_\Q$ver\E\.debian\.($format)$/);
return 0; # invalid filename
}
return $foundfile;
}
Putting the logic in the format like that, rather than in the dispatcher
means you can have your origdiff unpacker have the logic:
if Format == 1.0
extensions = (tar.gz, gz)
else if Format == 3.0
extensions = (tar.gz|tar.bz2|zip, gz|bz2)
and then use a single bit of code to decode 1.0 .orig.tar.gz+diff.gz
packages and 3.0 .zip+.diff.bz2 packages, eg.
Then by default the stack of formats to try would contain (DSP::V1_0,
DSP::V1_0::native) and the user could push other format on top of the
stack (dpkg-source --format 3.0 (git) ...). The can_build() method of
V3_0::git would check for example if there's a .git in the directory.
AFAICS, there are only two questions for a source format to answer:
can_extract and can_create; with native always able to create (since
it just involves tarring everything up), origdiff only being able to
if there's an orig.tgz in ../, git only being able to if there's a
./.git, etc.
I'd be satisfied with that but I'm wondering if we have to handle
native packages in Format: 2.0 too ...
Hrm, I can't find any indication what the minor part of the Format: is
meant to mean, even historically. I thought I remembered it being pretty
pointless -- ie, if you can unpack X.y, you can unpack X.z for all y,
z; which means there's not actually any value to having it in the .dsc
at all.
Note that there's a conflict between native wignpen formats, in that:
foo_1.0.orig-debian.tar.gz
could be foo version 1.0 with all its source in a debian directory,
or foo version 1.0.orig-debian in native format. That is, if that was
the only thing present in Files:, both could reasonably think they
could extract it, but if they did so, they'd end up with different
results. Looking at either the Format: field (2.0 for wignpen, 1.0 or
3.0 for native), or the Version: field could disambiguate it though.
Cheers,
aj
signature.asc
Description: Digital signature
Re: [sourcev3] Mapping between Format and Dpkg::Source::Package object
On Sat, Mar 01, 2008 at 06:19:47PM +0100, Raphael Hertzog wrote: Sounds like you shouldn't be naming them after the version number then. Having Dpkg::Source::Package include `native', `origdiff', `wignpen', `git', `bzr', would seem more sensible; then you'd just need to delegate to them directly. Yeah, this crossed my mind too. On the other hand, there's quite some code to handle the various -s* options that I' like to mostly deprecate for newer Formats (partly because they are useless, and partly because their meaning is not very clear when we have multiple orig tarballs). It seems pretty simple for dpkg: if it's of the form src_upstream.*, treat it as .orig, if it's of the form src_upstream-debrev.*, treat it as the diff. For the archive, you might want to ensure a -2 upload doesn't introduce more/different .orig sources than the -1 upload; but we already do that anyway, in the form of ensuring that we don't get a new .orig with different contents. But that's not dpkg's problem, afaics. Currently this compatibility code is restrained within V1_0.pm and with such a solution we'd have to put it in all modules that handle Format: 1.0 source packages and make it conditional on the announced format. Limiting the code to the native and origdiff formats would work just as well, afaics. I would've expected it to already be present in V2_0.pm/wignpen as well though. I'd be satisfied with that but I'm wondering if we have to handle native packages in Format: 2.0 too ... Hrm, I can't find any indication what the minor part of the Format: is meant to mean, even historically. I thought I remembered it being pretty pointless -- ie, if you can unpack X.y, you can unpack X.z for all y, z; which means there's not actually any value to having it in the .dsc at all. You don't give your opinion on my precise question. It depends what the Format: field means. You could have it be supersetting, ie anything Format: x.0 can do, Format: x+1.0 can also do. That's the behaviour I'd expect, personally. But you could also have it be mutually exclusive -- so that taking any format source package, with Format: x.0 and changing it to Format: y.0 (without changing anything else) will always break. Or you could have it somewhere in between, so that it sometimes breaks, and sometimes doesn't. There's two sorts of changes you can make of course -- ones that add new information that couldn't previously be expressed or interpreted (eg, a new file that doesn't match src_ver.tar.gz, srv_upver.orig.tar.gz, src_ver.diff.gz, or a new field like Apply-Patches-From: debian/patches), or ones that change the interpretation of previously valid sources (eg automatically applying patches found in debian/patches as part of unpacking). As best I understand it, taking a regular source package and changing Format: 1.0 to Format: 1.5 shouldn't break anything (it should still unpack and work), whereas changing Format: 1.0 to Format: 4.0 obviously will. You could just as easily have the Format: field express new interpretation as a minor increase (1.1 - 1.2), and changed interpretation as a major increase (2.0 - 3.0). In that case, wignpen might be a major increase because it automatically applies patches, while git/bzr are actually only a minor increase, because they just introduce new functionality that previous dpkg-source's would error out on anyway. Does it make sense to have a native package (a single .tar) with debian/patches/ auto-applied at extraction time? That's how the wignpen format's defined, so yes -- though you could arbitrarily restrict that by: - requiring Format: 2.0 to distinguish from old-style native - requiring a different name for the source file (.orig.tar.gz with no .diff.gz) - requiring all wignpen packages to include at least two source files (foo_1.0.orig.*, foo_1.0-1.debian.*) Having each method supply a can_extract just means making sure that you don't have two methods claiming they can extract the same archive (or at least, that they wouldn't end up with different results if they did). Another question, are there some users of source packages with Format: 2.0 and do we need to support such packages currently or can we decide for example that Format: 2.0 comes with a component in parenthesis too ? I'm not terribly convinced that adding a parenthetical component to the Format: field is a good idea in the first place (and it's easy enough to avoid if you have a file naming convention and a can_unpack function), but if you do introduce it, you definitely should be bumping the Format: number, and 2.* is already claimed... Heh. If the value after the dot really isn't useful, you could also call it Format: 3.git etc, without changing the specification of the field, or introducing a new field. :) Cheers, aj signature.asc Description: Digital signature
Re: dpkg-source's future and relation with VCS
On Sun, Feb 24, 2008 at 11:48:44AM +0200, Guillem Jover wrote: So I don't quite like Joey's idea in its current form, for the reasons other people have stated on the thread: *sigh* So dpkg isn't going to support it then? Cheers, aj signature.asc Description: Digital signature
Re: dpkg-source's future and relation with VCS
On Tue, Feb 12, 2008 at 12:51:12AM -0800, Russ Allbery wrote: Anthony Towns [EMAIL PROTECTED] writes: My point is precisely that it's *NOT* useful now. No software is useful until it is implemented. wigpen is far from unique in that regard. Right, but the git/bzr stuff _is_ implemented... Skipping to the end: I'd love to see both those things fixed so we can upload packages in any format after lenny's released; but I'd hate to see git/bzr format get blocked on WigPen, and then miss out on lenny because WigPen just isn't up to snuff and have us end up with neither for another cycle. On this we agree -- I see no reason why adopting the VCS format should be in any way dependent on wigpen. Good -- that's the only thing I'm saying here. AFAICS where we're at is: - we've got a new plugin architecture for supporting source package formats, which will at least cover v3 source formats for git/bzr tarballs. It needs some minor finalisation (behaviour when there are uncommitted changes, Source-Depends), but that's it. - the dpkg-source code might be cleaned up, to have a Dpkg::Source API (Raphael) and to use the plugin architecture for the v1 and v2 source formats too (Frank). - Raphael's looking at enhancing the wigpen format (eg, adding a file explicitly listing patches to apply), and making dpkg-source able to generate a wigpen format package; Russ may be looking at automating the process of generating wigpen format packages for packages maintained using quilt - none of the new formats are accepted by the archive; to become accepted, any particular format needs: - a demo of the format working effectively, so we can see what it takes to maintain a package with it, and what the actual output is, and to use as a test case - the format to be supported in dpkg mainline - the format to be unpackable by users running stable (ideally with apt-get and dpkg-source -x; but possibly by hand, or with a backported package) as well as an appropriate patch to dak. This, however: I haven't used quilt, but I don't believe there's anything that would make it difficult to port Joey's git plugin to being a quilt plugin. sounds like convergence towards exactly what Raphael was talking about, no? That's not what I got from: ] - dpkg-dev (or dpkg-dev-vcs) provides VCS-specific scripts in ] /usr/share/dpkg-dev/ that can be used to generate a wigpen source ] package from a VCS repository and more particularly: ] However I'm also convinced that: ] - a source package should be unpackable without a VCS. This means that ] somehow it should contain a checkout that can be extracted with basic ] tools. [1] ] - it will take several years until we can standardize on VCS-based source ] package whereas the switch to wigpen can be quick. In the mean time, a ] nice intermediary solution is to generate the wigpen source package ] from the VCS. I don't think standardising on a VCS is an option, be it git or quilt or anything else; and I do think standardising on a format, at least with the technology we have now or are likely to have soon will require that. We've got a bunch of requirements: - dpkg-source -x can unpack to the bare code - can manage a large number of Debian specific patches - can easily merge with upstream changes - can easily merge with downstream changes (Ubuntu, local admin, etc) - doesn't require any learning on behalf of maintainers - doesn't require any learning on behalf of NMUers - doesn't require any learning on behalf of admins/users - doesn't requires lots of dependencies on other code - doesn't become obsolete and block you from unpacking old source packages Standardising on a single source format isn't that important, and afaics avoiding making people install git-core, bzr, darcs, quilt, etc isn't either -- getting all the above right is though. So maybe this is a good way forward. A quilt plugin to that framework that also has hooks to unpack multiple tarballs ends up looking remarkably like wigpen, and then the argument about whether we can or should convert to and from that format can be decoupled from the issues around the availability of the format itself. In fact, that would largely reduce all issues of conversion to a simple technical implementation detail that people could work on or not as it felt useful, which seems like exactly where we'd want to be. So way back in the day, I did try writing a conversion tool from darcs to wigpen and back -- the problems I had were that it was kludgy to manage because of the way the patches weren't separated from everything else (eg, there's nothing stopping
Re: dpkg-source's future and relation with VCS
On Mon, Feb 11, 2008 at 02:46:33PM +0100, Raphael Hertzog wrote: However I'm also convinced that: - a source package should be unpackable without a VCS. This means that somehow it should contain a checkout that can be extracted with basic tools. [1] I don't think it's feasible to require that. It's a great goal, but we're not there, and may not be there by lenny; and having a better source format for lenny+1 is more important than that goal. - it will take several years until we can standardize on VCS-based source I don't think we have a VCS-equilvaent source package format that's worth considering standardising on: .tgz and .orig/.diff aren't powerful enough, git and bzr are too system specific, and wigpen is too unimplemented. So while I'm not exactly disagreeing with either premise, I don't think it makes sense to consider them atm. If they do eventually work out, to the point that dpkg will auto convert VCS-managed repos to tar+patches and back again in useful and convenient ways, then we can start REJECTing .git/.bzr/.hg/whatever uploads that we will have been accepting in the meantime, and expect maintainers to do that. Cheers, aj signature.asc Description: Digital signature
Re: [RFC] Enhance checksum support
On Mon, Feb 11, 2008 at 01:03:18PM +0100, Frank Lichtenheld wrote: The whole thing honestly doesn't do much for security anyway until the gpg support of dpkg-source is largely improved. For that I have no real concept yet, though. Well, apt verifies them when it downloads the source before passing it to dpkg to unpack; and there's also verification when entering the That would be news to me. And I can't seem to find that in the code, either. $ apt-get source dpkg Failed to fetch http://blah/debian/pool/main/d/dpkg/dpkg_1.13.25.dsc MD5Sum mismatch I was talking about the GPG signature of the .dsc Ah, right. No, that's not done; the chain of trust is: dak: .changes - .dsc/etc (maintainer gpg, md5) apt: Release - Sources - .dsc/etc (archive gpg, sha1/sha256, md5) Switching the .changes/.dsc/Sources checksum from md5 to sha1/sha256 still gets you the same benefit though. Cheers, aj signature.asc Description: Digital signature
Re: [RFC] Enhance checksum support
On Sun, Feb 10, 2008 at 06:46:55PM +0100, Frank Lichtenheld wrote: On Tue, Jan 29, 2008 at 04:06:12PM +1100, Anthony Towns wrote: On Sat, Jan 26, 2008 at 10:14:56PM +0100, Frank Lichtenheld wrote: The whole thing honestly doesn't do much for security anyway until the gpg support of dpkg-source is largely improved. For that I have no real concept yet, though. Well, apt verifies them when it downloads the source before passing it to dpkg to unpack; and there's also verification when entering the That would be news to me. And I can't seem to find that in the code, either. $ apt-get source dpkg Reading package lists... Done Building dependency tree... Done Need to get 3385kB of source archives. Get:1 http://blah stable/main dpkg 1.13.25 (dsc) [853B] Get:2 http://blah stable/main dpkg 1.13.25 (tar) [3385kB] Fetched 3385kB in 10s (334kB/s) Failed to fetch http://blah/debian/pool/main/d/dpkg/dpkg_1.13.25.dsc MD5Sum mismatch E: Failed to fetch some archives. Cheers, aj signature.asc Description: Digital signature
Re: [RFC] Enhance checksum support
On Sat, Jan 26, 2008 at 10:14:56PM +0100, Frank Lichtenheld wrote: The whole thing honestly doesn't do much for security anyway until the gpg support of dpkg-source is largely improved. For that I have no real concept yet, though. Well, apt verifies them when it downloads the source before passing it to dpkg to unpack; and there's also verification when entering the archive in the first place, and manual verification at other times (eg, when the archive gets compromised). Cheers, aj signature.asc Description: Digital signature
Re: [RFC] Enhance checksum support
On Mon, Jan 14, 2008 at 08:53:13AM +0100, Raphael Hertzog wrote:
There's also a possibility of not breaking the compatibility by simply
adding a new field and leaving Files untouched:
Checksums:
kind-of-checksum checksum name
I think it would be best that way. The size of the file then stay in the
Files field as would the md5sum. If the user enables additional checksums,
they end up in this new field.
It'd actually be good to be able to break Files in future, so that we're
forced to verify something other than md5sum. Otherwise there will
be code that doesn't check it properly, and that will end up being a
security problem.
Having it be:
Contents: sha256
28ee6a10eb280ede4b19c1b975aff5533016a26de67ba9212d51ffaea020ce34 355 foo
Files:
4bf7ff17bd9ddf3846d9065b3c594fb4 355 foo
or similar would be nice and non-redundant, and make it possible to drop
the Files: stanza at some point. I guess Contents-sha256: might be easier
to parse. Or call it Checksum or whatever.
I guess that means changing:
+foreach my $alg (sort keys %sums) {
+ $fields-{'Checksums'} .= \n $alg\t$sums{$alg} $filename;
+}
to:
+foreach my $alg (sort keys %sums) {
+ $fields-{'Checksum-$alg'} .= \n $sums{$alg} $size $filename;
+}
and something similar for parsing. Is there a git branch/repo with these
changes somewhere?
Cheers,
aj
signature.asc
Description: Digital signature
Re: Triggers status?
On Tue, Oct 23, 2007 at 03:58:00PM +0100, Ian Jackson wrote: Raphael Hertzog writes (Re: Triggers status?): You should have called git-update-server-info before the rsync! :-) Oh! Well, I've done that now. Hopefully that's better. \o/ git clone http://www.chiark.greenend.org.uk/~ian/git/dpkg/dpkg.triggers/.git/ now works. Cheers, aj signature.asc Description: Digital signature
Re: Triggers status?
On Sun, Oct 21, 2007 at 11:30:08PM -0500, Manoj Srivastava wrote: On Mon, 22 Oct 2007 07:01:33 +1000, Anthony Towns wrote: This is because the default is to deny by default -- and thus security policy modules _add_ the permissions for special tasks that packages need to do. Lacking security policy does not mean you have a security hole -- Oh, well in that case you only need it to happen before the postinst, not before the preinst. That's much closer to something triggers could do -- for instance, if you hacked libc6 to be interested in a file trigger for /, then anytime you installed an arch:any package, you'd have: libc6 installed, foo-any uninstalled foo-any unpack libc6 trigger-await, foo-any unpacked libc6.postinst triggered / libc6 installed, foo-any unpacked foo-any.postinst configure libc6 installed, foo-any installed The foo-any Depends: libc6 relationship is required for that ordering to be guaranteed, afaics though. Generalising that to some sort of Ensure-Always-Configured: yes header that the selinux-policy package could use might be feasible though. (All of the above assumes my understanding of triggers is accurate; I haven't looked at the code) Cheers, aj signature.asc Description: Digital signature
Re: Triggers status?
On Mon, Oct 22, 2007 at 05:43:45PM +0100, Ian Jackson wrote: * The dpkg triggers code should be merged from http://www.chiark.greenend.org.uk/~ian/git/dpkg/dpkg.triggers/ ] $ git clone http://www.chiark.greenend.org.uk/~ian/git/dpkg/dpkg.triggers ] Initialized empty Git repository in /home/aj/H/dpkg/dpkg.triggers/.git/ ] Cannot get remote repository information. ] Perhaps git-update-server-info needs to be run there? git:// doesn't work either (Connection refused). Cheers, aj signature.asc Description: Digital signature
Re: Triggers status?
On Fri, Oct 19, 2007 at 08:56:57AM +, Colin Watson wrote: I would understand the delay if there were some major problem that had been identified - but it all seems to work and it's a substantial advance that would let me simplify a bunch of stuff, so please forgive my impatience. :-) Is there a quick intro to using the triggers implementation anywhere around (this list's archives, maybe)? Or would you care to give a quick intro? Cheers, aj signature.asc Description: Digital signature
Re: Triggers status?
On Wed, Oct 10, 2007 at 12:44:07AM -0500, Manoj Srivastava wrote: Manoj Srivastava writes (Re: Triggers status?): I also would love to have a pre-install trigger [...] to ensure that a SELinux policy for a package is loaded before the package is unpacked; Well, when one or more packages are going to be installed a not trigger but something that walks like a trigger, sounds like a trigger goes off, So, afaics, Ian's triggers provide fairly weak ordering by time -- they'll delay marking a package as installed a little bit, and consequent postinst runs, but that's it. Delaying the unpack phase is a bigger step. The above also seems different in that triggers are mostly about aggregating similar tasks (update-menus for foo, update-menus for bar) so they can all be run at once, substantially quicker. That doesn't seem to be the case for SELinux policies either, which I presume would get lost in the noise of unpacking anyway. I'll be happy to call it a pre-install hook. That sounds sensible. I wonder if it'd be possible to setup an SELinux policy so that dpkg is only able to unpack files that are already known about by SELinux -- at least that way you'd get an error on unpack, with dpkg's usual bail-out attempts, rather than a possible hole introduced into your system. Cheers, aj signature.asc Description: Digital signature
Re: Triggers status?
On Sun, Oct 21, 2007 at 02:13:59PM +0100, Colin Watson wrote: Is there a quick intro to using the triggers implementation anywhere around (this list's archives, maybe)? Or would you care to give a quick intro? Ian's final design is here and has a worked example: http://lists.debian.org/debian-dpkg/2007/04/msg00076.html I've attached my patch for man-db to make it use triggers, [...] Heh, neither of which are really terribly /quick/... minus the changes to debian/po/*. Basically, I install a 'triggers' control file registering interest in all the manual page directory hierarchies, and make the postinst run mandb when run with the 'triggered' argument So, two sorts of packages -- ones that activate a trigger, and ones that implement it (aka are interested in it). Packages activate a trigger by (a) just installing a file, no postinst needed, or (b) invoking dpkg-trigger from a maintainer script, or (c) having an activate entry in the triggers control file. AFAICT this puts the package into a triggers-awaited state and means it doesn't satisfy Depends:. When the trigger is eventually undertaken by the implementing package, it'll switch from triggers-awaited to installed. Packages implement a trigger by having an interest entry in the triggers control file, and having their postinst implement the trigger when invoked with triggered as the first argument, and all the trigger names, separated by spaces, as the second argument. When a trigger is activated, the implementing package will go from the installed state to trigger-pending, but continue to satisfy Depends:. AFAICS, this means that if you have three packages: I - implements trigger foo A - activates trigger foo B - depends: A, activates trigger foo in postinst then dpkg will: unpack I, A, B configure I, I = installed configure A, activate foo, A = trigger-await, I = trigger-pending can't configure B because A doesn't satisfy Depends I.postinst triggered foo, A = installed, I = installed configure B, activate foo, B = trigger-await, I = trigger-pending I.postinst triggered foo, B = installed, I = installed done But if B had activated foo by just installing a file or just an entry in its triggers control file, it would have been: unpack I, A, B configure I, I = installed configure A, activate foo, A = trigger-await, I = trigger-pending configure B, activate foo, A,B = trigger-await, I = trigger-pending I.postinst triggered foo, A,B,I = installed done If you have dependency chains of packages with postinsts and a common trigger, it seems like you devolve to the current case of running the triggered code once per-package, which seems a shame. I would have thought the common case would have been for B's postinst to be able to be run prior to the trigger happening for its dependency, A, but afaics there's no way that A can indicate that -- basically to say this trigger is relevant, but if it fails, I don't break at all, so that A can be installed immediately and stay that way, even if the I package later ends up in config-failed if the trigger doesn't end up working. Maybe invoking the trigger from B's preinst could work as a hack, but I don't see any indication you could rely on a trigger activated in preinst not being run prior to unpacking. In any event, that means that conceptually, triggers are the very last part of a package's postinst. dpkg uses the /var/lib/dpkg/triggers/ directory to manage state, with File - being a list of file/dir triggers, of the form $path $pkg\n Deferred - is a queue for trigger activations that haven't yet been put in /var/lib/dpkg/status Lock - is a lockfile Other files in that directory are named after explicit triggers directly, and are a list of interested packages, one perline. Explicit triggers follow the package name convention so are limited to lower case letters, digits, plus, minus and dot. Presumably this is hardcoded to prevent conflicts with the File/Deferred/Lock files in the same directoy. So the worst I could say about this is: a) there's no way of indicating triggers are optional to an activating package b) interested seems a confusing way to describe the packages that end up doing all the actual work to implement a trigger Obviously I haven't looked at the code, but I presume the worst thing there would be the indentation choices... :-P (a) could be fixed in the future just by changing the code, so doesn't seem a major issue. (b) is just an explanation issue. If the design is right, then it's just a matter of fixing any problems with the code, which can also happen over time afaics, so given this: a) speeds up installations/upgrades significantly by not duplicating work; and b) simplifies packaging by removing lots
Re: [PATCH] proposed v3 source format using .git.tar.gz
On Tue, Oct 09, 2007 at 06:58:19PM +0100, Ian Jackson wrote: [...] Goals I would suggest: * Abolish dpatch (and similar excresences) and specifically to get back to the point where a Debian source package can be unpacked to the point of seeing the source code without having to execute any of it. Really, that's probably the most valuable part of this, even if not the most interesting -- having a sane way to unpack source packages to the *actual* working tree makes it much more sane to do analysis of the source, hack on it, whatever. And something that works for a pure tarball of a .git directory all the way to unpacked .c files seems like it should certainly be general enough to achieve that. That seems (to me) like it means: - keep the perl module structure Joey's created and expect to use it with other ways of dealing with patches internally to a source package (quilt, bzr, darcs, whatever) - finalise the remaining tweaks: drop the bracketed (git) from the Format: field and handle it some other way? add a Source-Depends: field? * Make it possible (once more) for NMUers to make a change to a to acquire the source, inspect it, edit it, build it, test it, and upload it, using only tools which either do not depend on the RCS or which entirely hide it, without disrupting or being disrupted by the revision control system. It seems... remarkable that making the source package format more dependent on the revision control system would make NMUers and others more able to ignore it. The remaining big question seems to be whether to have Debian source packages include the working tree directly so people don't need git to get at it; but that seems to me something that can be decided by policy mechanisms outside dpkg. So, afaics, the dpkg maintainers should: - add Source-Depends: (I'm biassed :) - upload dpkg with modular support to unstable - upload git/bzr support as part of either dpkg or the git/bzr packages, with appropriate autogenerated Source-Depends: and ftpmaster should start accepting git/bzr source packages to experimental so we can get some practical experience with the format, and decide whether to have .git.tgz or .git+.orig+.xdelta .tgz's or whatever to unstable. I'd expect we'd either wait for lenny to release, or an updated dpkg with Format:3.0 support to be in an etch point release before accepting such packages in unstable either way, but better to get started sooner, afaics. Cheers, aj signature.asc Description: Digital signature
Re: [PATCH] proposed v3 source format using .git.tar.gz
On Mon, Oct 08, 2007 at 09:16:52AM -0500, Manoj Srivastava wrote:
In any case, I think the kinds of actions taken by joey's and
Colin's patches are probably not things that we'll have to do to
support shipping an arh working directory in the source packagel if we
have {arch} and .arch-id dirs in the source, the end user has access
to the distributed version control system;
Joey's thing lets you do a clean tarball that only contains the git
(or bzr, or darcs) information, and recreates the working directory by
a checkout.
For CVS the equivalent would be shipping the CVSROOT, for rcs the
equivalent would be shipping only the ,v files. If you don't have git,
you can't do *anything* with a .git.tar.gz source package. If you unpack
it by hand, all you get is the .git directory -- no debian/control,
no debian/rules, nothing.
You could do something similar with darcs/git/bzr atm simply by shipping
the .git, _darcs or .bzr directories as part of your source package --
that's discouraged atm because it's duplicate information that bloats the
source package, but it's entirely possible -- some ifupdown uploads have
included the _darcs directory, eg.
Ultimately, it turns the source package into a snapshot of not just the
current codebase, but the history as well -- or in the case of a shallow
tree, the recent history.
What's the point of that?
There may not be any -- if you're just packaging something that's
completely straightforward, just adding a pointer to the official
repository is probably the most sensible thing to do anyway; whether
that be a subversion url or a tla grab file, or something else, and
you can already do that.
Where it starts becoming relevant (afaics) is when there's a
Debian-specific patch history (either due to it being a native package,
complicated packaging, or significant patches against upstream) and
we want the archive, as the primary way we distribute the source, to
include a real change history rather than a simple snapshot.
You can do that to some extent via all the dpatch tools, but they're
kludgy in various ways; having the source format allow for an actual
repository from a real VCS solves that in a really powerful way.
I am not sure how the pritine-tar bit fits in into the picture
yet.
I don't think it really does; though it makes it possible to confirm
that the point in the repo that claims to match some upstream release,
really does match the official tarball of that release from upstream,
which might have some use.
pristine-tar seems mostly useful for generating a v1 source package
purely from a remote repository; this allows you to turn a repository
_into_ a (v3) source package.
Cheers,
aj
signature.asc
Description: Digital signature
Re: [PATCH] proposed v3 source format using .git.tar.gz
On Mon, Oct 08, 2007 at 03:59:05PM -0500, Manoj Srivastava wrote: Where it starts becoming relevant (afaics) is when there's a Debian-specific patch history (either due to it being a native package, complicated packaging, or significant patches against upstream) and we want the archive, as the primary way we distribute the source, to include a real change history rather than a simple snapshot. This seems to fit my use case; I have often large feature branches that only sporadically get merged back upstream. Right, but the caveat is important too -- we have to _also_ want the archive to include the real change history. Maybe when things get complicated enough that there are often large branches that sporadically get merged back, that part's no longer worth the hassle: This is almost an order of magnitude increase in size, which I find hard to justify. As far as cases where there are enough changes to make a repo interesting, but not so many that shipping a repo as the standard source becomes huge and clunky, it's possible that arch just isn't a useful tool for the job -- repo registration alone would be pretty annoying, and it's not like there aren't plenty of other VCS options for that case anyway. Subversion (or SVK) isn't an option either, afaics, eg, and I doubt CVS or RCS would work well either. So that leaves: I still think that shipping a full working dir, with no dpkg changes, seem to be the way to go, along with a tla grab file, which I think I should consider putting into the package itself (If I can work around the chicken and egg issue of adding a grab file changes the source revision which means the grab file should change which means a new revision is needed ) If you're just distributing a snapshot, rather than a full repository as Joey's basically proposing, why can't your grab file be autogenerated? ie, 1. hack on the source, merge changes, blahblah, finish, tag 2. do a checkout from version control 3. autogenerate anything necessary 4. create source package 5. build 6. upload If you're using pristine-tar to create a pristine .orig.tgz from your repo (rather than keeping one around), that needs to be autogenerated at step 3 too, afaics. Worst case you could check the autogenerated files into a parallel repository and use a config or something, afaics. Cheers, aj signature.asc Description: Digital signature
Re: [PATCH] proposed v3 source format using .git.tar.gz
On Fri, Oct 05, 2007 at 07:16:13PM -0400, Joey Hess wrote: I've been working on making dpkg-source support a new source package format based upon git. Oh, one question that comes to mind: how does this affect checking for non-free stuff in past revisions? If 3.1-4 had some non-free files that get reimplemented for 3.2-1, do we (a) expect the maintainer to do a no-history upload for 3.2-1; (b) check that this happens somehow; (c) not worry about it as long as it's only in the history; (d) something else? Verifying that not just the current tree is DFSG-free, but all the history is too seems potentially difficult. Cheers, aj signature.asc Description: Digital signature
Re: [PATCH] proposed v3 source format using .git.tar.gz
On Sun, Oct 07, 2007 at 08:45:08AM +, Colin Watson wrote: I'm quite attached to being able to peek inside source packages quickly by sshing over to the local mirror I keep at home which grabs everything overnight so that I don't have to wait for it to download; particularly so for large source packages. How is that better than running apt-get source against your local mirror, though? Alternatively, is it really a problem to have your local mirror autogenerate v1 source packages in the same way v1source.qa.d.o presumably would? (I have a strong adverse reaction to duplicated information, so shipping the working tree in .git format and .orig.tar.gz format irks me, particularly if it's required) * Derivative distributions who are slow to upgrade their dpkg-source could still interoperate to some degree. They'd need to pull sources from the autogenerated url; though they'd still probably have Build-Depends: issues if they're not updating packages generally. Oh, I was referring more to the buildd base system and archive maintenance code too; dak needs to be updated in order to accept format 3.0 source packages, for instance. Well, you'd need an entirely new .dsc to use a v3 source package with an un-updated dak (or launchpad or whatever), that didn't contain the .git.tar.gz (or whatever) elements at all, so I don't personally see a lot of difference between just generating a new .dsc and generating a new .dsc and .tar.gz. (It might be just me, but I'm getting the feeling that implementing WigPen via this v3 format is probably easier than implementing it via the v2 format...) I might be off my rocker, but I'm not seeing any reason why we couldn't allow uploads of v3 format packages to experimental while blocking them for unstable etc, presuming dpkg somewhere supported them. Cheers, aj signature.asc Description: Digital signature
Re: [PATCH] proposed v3 source format using .git.tar.gz
On Sun, Oct 07, 2007 at 09:45:20AM -0400, Joey Hess wrote: Anthony Towns wrote: So the logic there would be: if there's an upstream tag, then generate an .orig.tgz if there's a pristine-tar info, hax0r it to be pristine generate a .diff.gz if the .diff failed goto bailout generate a .dsc containing the orig and diff It's not generally possible to generate a .diff.gz that expresses all the changes that might be in a git repository. Right, but it is possible to detect that, and bailout to generating a .tar.gz, no? Repo formats that bzr in etch can unpack could be denoted by Source-Depends: dpkg-bzr (= 0.11) I was thinking about Source-Depends too, the main problem seems to be that it would need to be supported in apt-get source too. I wonder if we could just use build-depends. apt-get source support could just be a warning This package cannot be unpacked without installed. Using Build-Depends: would make it pretty complicated to know which bits were needed for unpacking, if that's all you're trying to do. Cheers, aj signature.asc Description: Digital signature
Re: [PATCH] proposed v3 source format using .git.tar.gz
On Fri, Oct 05, 2007 at 07:16:13PM -0400, Joey Hess wrote: I've been working on making dpkg-source support a new source package format based upon git. The idea is that a source package has only a .dsc and a .git.tar.gz, which is just a git repo. Is a .gitdiff.tar.gz possible, so the archive doesn't need to have the full git repo replaced by each upload? ie, something like Files: foo_1.0-1.git.tar.gz foo_1.0-2.gitdiff.tar.gz so that a small patch only adds a small file to the archive rather than replacing a large one? This means you can't build the package by hand with standard unix tools -- at the very least you need git installed, and if other VC systems are to be supported, you need them too. Changes in repository formats will presumably result in versioned dependencies too. This is slightly worse than the case for existing patch management tools in that most of those can be dealt with by hand; though cdbs and to a lesser extent debhelper can't be quite as easily replicated I guess. Once the unpack is done, I don't see any reason why you can't do an NMU in the traditional way, so presuming dpkg-source -x or apt-get source handles the unpack automatically, I don't think it necessarily imposes any new requirements on NMUers. Maybe providing a feature on packages.debian.org (or similar) to download sources in simple, non-VC, tarball format would make this a complete non-issue though? Would it make sense to have the source format look more like: Format: 3.0 Source: dpkg ... Source-Depends: git-dpkg (= 3.14159) Source-Hooks: /usr/bin/git-dpkg ... Files: ... foo_1.2.git.tar.gz and have the git specific functionality be provided by a /usr/bin/git-dpkg binary (with standardised arguments) from the git-dpkg package? That would let you smoothly deal with repository changes and implementing new interfaces, and also let us limit the allowable formats for the archive reasonably simply. You could drop the Source-Hooks: line, and just have dpkg-source know to associate *.git.tar.gz with /usr/lib/dpkg/source/git, and trust the package will provide it. Bonus points: rather than debian/rules clean, create a diff, build, have dpkg do debian/rules clean, commit any uncommitted changes with the commit message being the changes from the changelog, create a .git.tgz, build for git-source-format packages. Cheers, aj signature.asc Description: Digital signature
Re: [PATCH] proposed v3 source format using .git.tar.gz
On Sat, Oct 06, 2007 at 11:19:43AM -0400, Joey Hess wrote: Anthony Towns wrote: Changes in repository formats will presumably result in versioned dependencies too. I don't think that dpkg should add vcs formats that we don't have a good expectation of remaining supported by newer versions of the tools going forward (so svn repos are out). It's more that newer versions of the tools will create more optimised repo formats, that older versions don't support -- bzr has done this between etch and lenny, eg. My inclination would be to have dpkg support it, but have it generate a REJECT at upload time if we don't want to support the new format (yet). If the format changes in a non-backwards compatible way, we could have source packages built on unstable that cannot be extracted on stable, which I also think is suboptimal, but hard to completly avoid. Well, that's true of any Version: 3 format already anyway. Once the unpack is done, I don't see any reason why you can't do an NMU in the traditional way, so presuming dpkg-source -x or apt-get source handles the unpack automatically, I don't think it necessarily imposes any new requirements on NMUers. Basically, you have to know how to git commit your changes before building the NMU, and that's all. As a bonus, it's rather easier to generate NMU patchsets. :-) Well, there's two options: - dpkg-source knows it's meant to be a git package, and can either warn you you have uncommitted changes (and tell you what to do) or just auto commit them for you - dpkg-source doesn't know what sort of package it's meant to be and just builds a v1 source package Both of which sound pretty trivial for an NMUer to deal with... Maybe providing a feature on packages.debian.org (or similar) to download sources in simple, non-VC, tarball format would make this a complete non-issue though? pristine-tar could be used for this, it would just need source packages to put the delta somewhere standaised (under debian/), and would need some standarised way to get to the upstream source branch in git. So the logic there would be: if there's an upstream tag, then generate an .orig.tgz if there's a pristine-tar info, hax0r it to be pristine generate a .diff.gz if the .diff failed goto bailout generate a .dsc containing the orig and diff publish all three else: (bailout:) generate a .tar.gz generate a .dsc containing the tar publish both Would it make sense to have the source format look more like: Format: 3.0 Source: dpkg ... Source-Depends: git-dpkg (= 3.14159) Source-Hooks: /usr/bin/git-dpkg ... Files: ... foo_1.2.git.tar.gz You could drop the Source-Hooks: line, and just have dpkg-source know to associate *.git.tar.gz with /usr/lib/dpkg/source/git, and trust the package will provide it. Not sure if this buys anything that using perl modules for the vcses can't do, really. It doesn't buy anything extra, so forget the Source-Hooks: and just consider it to be a different package providing the VCS-specific perl module. That buys you: - no changes to dpkg to support new source formats - easy for other distros to support more or fewer VCS formats - version info to deal with new repo formats - explicit dependency info that can be checked at upload time to block source formats we don't want to support How do you envision this helping deal with repository format changes? Repo formats that bzr in etch can unpack could be denoted by Source-Depends: dpkg-bzr (= 0.11) while repo formats that require bzr from lenny or later could be denoted by: Source-Depends: dpkg-bzr (= 0.18) (Or you could have a versioning scheme that matches the repo format directly, rather than the program being used. Or you could use virtual packages and say dpkg-bzr-v3 and have that be Provided: by some package/s, etc) It'd be straightforward to make a policy decision to only ACCEPT uploads with given Source-Depends: lines, eg ones that can be satisfied using packages from stable, while letting third party repos experiment with new repo formats without needing to use a different dpkg than Debian does. Cheers, aj signature.asc Description: Digital signature
Re: [PATCH] proposed v3 source format using .git.tar.gz
On Sat, Oct 06, 2007 at 10:37:48PM +, Colin Watson wrote: The second possibility seems to me to be more flexible, though, and probably not all that hard to implement: build both a .tar.gz (containing the working tree) and a .$VCS.tar.gz, and teach 'dpkg-source -x' to unpack the tree given at least one of these. This would allow various interesting possibilities such as: Would this be better in any way than having a web interface that provides an autogenerated version-1 source package? Presume it's a url like: http://v1source.qa.debian.org/i/ifupdown/ifupdown_0.6.8.dsc * Buildds could just fetch the .tar.gz; they have no need of the VCS data. Users who just want to inspect the current version of the source and not change it might want to do this too, using (say) 'apt-get source --no-vcs package'. dget -x http://v1source.qa.debian.org/i/ifupdown/ifupdown_0.6.8.dsc * Developers on slow connections could say 'apt-get source --vcs-only package' to fetch just the .$VCS.tar.gz, with the documented caveat that it would be just like checking the source out of a VCS in that you might have to recreate some autogenerated files. That happens automatically. * Space-constrained mirrors could conceivably exclude the VCS data if they had to, though we probably wouldn't encourage this. Mirrors wouldn't mirror the autogenerated stuff, so not an issue. * Derivative distributions who are slow to upgrade their dpkg-source could still interoperate to some degree. They'd need to pull sources from the autogenerated url; though they'd still probably have Build-Depends: issues if they're not updating packages generally. * Tools like mc, vim's tar plugin, or http://www.mirrorservice.org/sites/ftp.debian.org/debian/ could still be used straightforwardly and without modifications to look inside source packages on mirrors. Again, you'd have to go to the autogenerating url rather than a mirror. Cheers, aj signature.asc Description: Digital signature
Bug#62529: [DPKG-GENCHANGES] [DPKG-GENCONTROL] Support binary recompilations with different version
reopen 62529 thanks I consider this bug closed with the following past changes: dpkg (1.13.19) unstable; urgency=low ... [ Guillem Jover ] * Add new substvars source:Version, source:Upstream-Version and binary:Version so packages will be able to avoid breaking on binNMUs. Based on a patch by Ken Bloom and Jeroen van Wolffelaar. Closes: #358530 * Support binNMU safe packages even when source and binary differ in version. ... Uh, that helps for doing NMUs and dependencies, but still makes it awkward actually associating the source and the binary package. They're separate problems. Cheers, aj -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Create a project on Alioth and choose a RCS?
On Sun, Jan 15, 2006 at 08:37:05AM +1100, Brendan O'Dea wrote: On Sat, Jan 14, 2006 at 07:33:56AM +0100, Christian Perrier wrote: -import the current sources in the trunk of this SVN I take it that this could be done in such a was as to retain the history in Scott's arch repositories? Why the change to subversion? Seems very gratuitous? Cheers, aj -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Create a project on Alioth and choose a RCS?
On Tue, Jan 17, 2006 at 07:12:26AM +0100, Christian Perrier wrote: Quoting Anthony Towns (aj@azure.humbug.org.au): Why the change to subversion? Seems very gratuitous? From what? From arch or from the CVS? From what Scott was using, which is arch, aiui. But apparently tailor does support converting from bazaar and tla to subversion, so it shouldn't much matter anyway. (Someone posted otherwise earlier; but the tailor wiki page seems pretty definitive: http://www.darcs.net/DarcsWiki/Tailor) I think we probably do no need a min is better than yours RSC discussion right now...but I now this wasn't your intent, Anthony. Yeah, it's more just losing history for no apparent reason that bothered me; but if that's avoidable then I'm not worried at all. Cheers, aj signature.asc Description: Digital signature
Bug#313400: dpkg: Please remove /usr/sbin/start-stop-daemon
Package: dpkg Version: 1.13.0 Severity: serious Hey, dpkg is now shipping both /sbin/s-s-d and /usr/sbin/s-s-d; only /sbin/s-s-d is required. Having both breaks bootstrapping since daemons get randomly started when they're not supposed to, because only /sbin/s-s-d is diverted. Presumably this is a still-glowing scar from: * Scorched-earth reimplementation of the build process and control files with debhelper and automake. Also, * Remove /usr/sbin/start-stop-daemon. Closes: #156437. -- Adam Heath [EMAIL PROTECTED] Thu, 29 Aug 2002 16:43:15 -0500 Advantage: doogie. Cheers, aj -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#62529: On dpkg support for binary recompilations
Scott James Remnant wrote:
Source: banana
Package: banana
Architecture: any
Depends: libbanana0 (= ${Source-Version})
Package: libbanana0
Architecture: any
Depends: libbanana-common (= ${Source-Version})
Package: libbanana-common
Architecture: all
Any packages that do that are already broken for binNMUs -- since
banana/$ARCH will depend on the wrong version of libbanana0/$ARCH. So I
don't think this is an issue.
We could address substvars by ensuring ${Source-Version} is the version
of the source, not the binary, and we therefore get: [...]
The binary version is available in the ${Version} substvar, developers
would have to be extremely careful to ensure that dependencies on
arch-any packages are done with ${Version} and arch-all packages with
${Source-Version}; and that they only do binary-arch when preforming
binary recompilations.
That seems straightforward to me...
This is in breach of current policy ( 8.5) which says library
development packages should have an exact version dependency on an
arch-any package using ${Source-Version} .
Err, policy says The ${Source-Version} subsitution variable can be
useful for this purpose -- it's not a policy violation if it turns out
something else is more useful. It also doesn't say it must/should have
an exact dependency, just that it typically does.
So this would require a policy change, and an extraordinary amount of
care by both the original developers and binary recompilers. I doubt
most people would get it right, leaving us with the same problems we
have today.
The only problem we have today is that you have to use heuristics to
work out what binary versions match what source versions...
Cheers,
aj
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: binary NMUs and version numbers
Goswin von Brederlow wrote: Anthony Towns aj@azure.humbug.org.au writes: Goswin von Brederlow wrote: 1.rc 1.rc2 1.rc+b1 1.2-1~beta 1.2-1~beta2 1.2-1~beta+b1 1.2~beta-1 1.2~beta-1+b1 1.2~beta2-1 Adding the implicit '0' that dpkg assumes on versions ending in alpha chars would solve both cases: That is, 1.2-1~beta == 1.2-1~beta0 1.2-1~beta0+b1 1.2-1~beta1 That'd mean REJECTing uploads whose versions match [^0-9]+[a-z][0-9]+$ presumably. ^ ^ First + is literal, second + is one or more. One should be escaped. Which one? Depends whether it's a regexp or an eregexp... :-/ No, why? Because 1.2-1~beta+b1 1.2-1~beta1. That regexp is rejecting uploads where there *isn't* a number before the +. '[^0-9]\+[a-z0-9]+$' (as an eregexp) might be better. A version matching [a-z]$ has an implicit trailing 0 in dpkg version terms. Not really; it just compares equally to the same string with any number of trailing zeroes. Versions without an epoch don't have an epoch, but they do compare equally to the same version with an epoch of zero. Try: ] dpkg --compare-versions 'beta' eq '00:beta-000'; echo $? for those playing along at home. Or ] dpkg --compare-versions '10' eq '010'; echo $? When adding a + that implicit 0 must be added explicitly to preserve the ordering. With that rule there is no reason to rstrict the version to exclude [a-z]$. Err, the above regexp didn't match anything ending in a-z, no matter how you construe it... Cheers, aj
Re: binary NMUs and version numbers
Goswin von Brederlow wrote: 1.rc 1.rc2 1.rc+b1 1.2-1~beta 1.2-1~beta2 1.2-1~beta+b1 1.2~beta-1 1.2~beta-1+b1 1.2~beta2-1 Keeping the Debian revision simple is a Good Thing. Adding the implicit '0' that dpkg assumes on versions ending in alpha chars would solve both cases: That'd mean REJECTing uploads whose versions match [^0-9]+[a-z][0-9]+$ presumably. Another case that should be considered is the existing use of + for revisions of a cvs snapshot (e.g. mutt uses a + but always does so): 1.2-20041208 1.2-20041208+2 1.2-20041208+b1 Hrm, why isn't this 1.2+20041208-1 ? Isn't the date describing the upstream version? Or 1.2-20041208-1, or 1.2+cvs20041208-1 or whatever. -rw-rw-r-- 16 katiedebadmin 2908273 May 2 2004 pool/main/m/mutt/mutt_1.5.6.orig.tar.gz -rw-rw-r-- 16 katiedebadmin 412082 Nov 17 10:17 pool/main/m/mutt/mutt_1.5.6-20040907+2.diff.gz It seems to result in rather large diffs, and I can't really see the benefit? There are 3 simple solutions to this: 1. forbid + in debian versions and think of another character instead doing the same (must be '.') Actually, that doesn't work either -- otherwise a new maintainer version (x-y#1) compares less than an old NMU (x-y.1). For the same reason = . doesn't work. Cheers, aj
Re: binary NMUs and version numbers
Scott James Remnant wrote: On Fri, 2004-11-26 at 08:58 +1000, Anthony Towns wrote: Andreas Barth wrote: One idea was to use for binary-only NMU as 1.2-3b1. Actually, it was 1.2-3+b1, iirc. Maybe I missed some later discussion. Yes, it was +b1 ... for the following reason: This has the advantage that current dpkg can handle it, and also that britney doesn't get confused any more. However, it doesn't solve the second issue. Changing the security update policy to call packages 1.2-3+sec-woody1 as well would solve it though. The theory for using '+' was that it sorts *lower* than '.', Oh, well, /my/ theory for using it was that it was visually distinguishable from the normal . separated versions we're used to. so we could use 1.2-3.woody.1 or similar. The reason we don't use that form today, iirc, is that it confuses the current is it a Bin-NMU? check. Nah, the reason we don't use that form today is that we use the 1.2-3woody1 form instead. I don't think the -1.woody.1 form is all that good though, since it compares greater than a possible -1.5 version in sarge -- also unhelpful is that it'd be a higher version that -1.sarge.1. Using +secN, and not including the distribution codename at all would be reliable in all cases, I think (except for the existing -N.0.1 binNMUs of course). (That leaves backports out in the cold still though, but -XwoodyY is probably fine for them anyway) Cheers, aj signature.asc Description: OpenPGP digital signature
Re: binary NMUs and version numbers
Andreas Barth wrote: - Britney gets confused if a package with a version like 1.2-3.sarge.0 and 1.2-3.sarge.1 is uploaded. - In that binary package, the source version is used as 1.2-3.0.1 which is not really true (at least, no source with that version exists in the archive). So, katie needs to do special handling there. The last issue could be solved with any handling, even with the current one, so I will ignore it in the rest of this mail. The last issue and the first one are the same -- the reason britney gets confused is the heuristics used to work out if two packages are from the same source get it wrong for versions that look like binNMUs. Those heuristics are necessarily because the binary package doesn't list it's true source version. One idea was to use for binary-only NMU as 1.2-3b1. Actually, it was 1.2-3+b1, iirc. Maybe I missed some later discussion. This has the advantage that current dpkg can handle it, and also that britney doesn't get confused any more. However, it doesn't solve the second issue. Changing the security update policy to call packages 1.2-3+sec-woody1 as well would solve it though. The advantage is that this solution is the nicest one from the theoretical point of view. It solves both problems with britney and the security uploads, but the disadvantage is that we need to teach dpkg first how to handle that new character before we can use it. So, we probably should fix that in sarge, so that we can use the new character in etch than. Changing the version format really strikes me as overkill for this problem, personally. Cheers, aj signature.asc Description: OpenPGP digital signature
Bug#232025: dpkg unpack failure
On Tue, Mar 02, 2004 at 10:59:41PM +, Scott James Remnant wrote: On Tue, Mar 02, 2004 at 10:41:22PM +0100, Ingo Saitz wrote: It is tar which needs a workaround for sarge, I agree. But I believe dpkg must be fixed, too, so that sarge+1 can include a tar without this ugly workaround for dpkg. If doogie can do an upload, or is happy for me to do one, we've still got time to get this into sarge. tar certainly needs to be worked around for sarge (and ideally it should nul terminate the names permanently; there doesn't seem any cost to doing so); but better to have dpkg fixed in sarge than later: that's the only way a changed tar can be uploaded before sarge+1 is released. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. Linux.conf.au 2004 -- Because we could. http://conf.linux.org.au/ -- Jan 12-17, 2004 signature.asc Description: Digital signature
Bug#222047: --configure should process essential packages first
On Sun, Nov 23, 2003 at 04:44:37PM +0100, Koblinger Egmont wrote: Currently if more unconfigured packages are being configured, their ordered is determined by the Depends fields of the packages, however, the Essential field is not taken into account, That's correct. As far as dpkg is concerned the Essential field just means do not remove this package. This behaviour is against the policy that AFAIK essential packages required by a certain package do not need to be explicitely mentioned in the Depends field. That's also correct. This is achieved by ensuring that Essential: yes packages don't need to be configured to be functional. On a dpkg based (but not Debian) system I have a script that builds up a chroot system: You'll need to either specify dependencies explicitly, or do as Debian does and ensure that Essential: yes packages work even without being configured. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. Australian DMCA (the Digital Agenda Amendments) Under Review! -- http://azure.humbug.org.au/~aj/blog/copyright/digitalagenda
Re: Bug#217945: dpkg-dev: should depend on build-essential
Err, looks like Adam sent his message to -dpkg and -bugs-dist, instead of to the bug number. Yick. :-/ On Thu, Nov 06, 2003 at 11:54:32AM -0600, Adam Heath wrote: On Thu, 6 Nov 2003, Anthony Towns wrote: Mmm. That doesn't really help *our* users very much though, does it? Well, it's never been dpkg's design to enforce *debian* policy. Otherwise, tools like lintian and linda wouldn't be nescessary. Mmmm. Having dpkg-checkbuilddeps behave differently on on Debian systems than it potentially might on non-Debian systems wouldn't be a major problem, and would be a boon for our users, assuming the different behaviour (checking for build-essential) is actually possible. I'm not sure what can be done about this anyway though -- if we add a check for libc6-dev by whatever means, how do we cope with packages that Build-Conflicts: libc6-dev? There is the libc6.1 issue as well. And hurd, *bsd, etc. You know at build time whether it's libc6, libc6.1 or libc0.2 -- that only depends on the arch. So that's easy to deal with -- at worst, just hardcode some if/switch/case block. But dealing with stuff that Build-Conflicts: on build-essential stuff seems impossible to deal with. Can anyone see a way out of that? But if there /is/ something that can be done, we should work out a way of doing it. As far as dpkg is concerned, there isn't a problem(I'm sorry to say it like that, but that's how Wichert and I feel, when wearing our dpkg hats for this issue). No offence, but the social contract says you're wrong. Certainly, I agree that we want to keep a separation between policies like build-essential and protocols like Build-Depends:, but if it makes the most sense to check one of the former policies in a tool in dpkg-dev.deb, that's the way it needs to be done. But that's irrelevant if it's just not possible to check that policy at all, which is the way it seems to be to me. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. Australian DMCA (the Digital Agenda Amendments) Under Review! -- http://azure.humbug.org.au/~aj/blog/copyright/digitalagenda
Bug#217945: dpkg-dev: should depend on build-essential
On Wed, Nov 05, 2003 at 12:56:08PM -0600, Adam Heath wrote: On Wed, 5 Nov 2003, Julian Gilbey wrote: I'm confused: policy talks about build-essential packages and Build-Depends etc. in the same breath, if I'm not very much mistaken. (Sections 4.2 and 7.6.) I just don't understand the distinctions you and Wichert are making. Build-Depends is a field, that lists the build-time dependencies for a package. dpkg-checkbuilddeps enforces this. debian-policy has decided to not list build-essential packages in this field. This was a policy descision. Other systems that use dpkg may not make this same descision. Mmm. That doesn't really help *our* users very much though, does it? I'm not sure what can be done about this anyway though -- if we add a check for libc6-dev by whatever means, how do we cope with packages that Build-Conflicts: libc6-dev? But if there /is/ something that can be done, we should work out a way of doing it. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. Australian DMCA (the Digital Agenda Amendments) Under Review! -- http://azure.humbug.org.au/~aj/blog/copyright/digitalagenda
Bug#184635: dpkg and Replaces:
tag 184635 patch
thanks
Suppose I have two packages A and B. B Replaces: A but does not provide
or conflict with A, it merely replaces a few files from A. If I install
A first and then B, it works. If I install B first and then A, dpkg
complains that files from A already exist in B and aborts installation.
archive.c needs to be changed to support this behaviour. The following
patch does so. It works by checking replaces in both directions, rather
than just one, and if the package that owns the conflicting file does
replace us, it removes the current file from the filelist (the oldnifd
stuff), and just copies the file we're working on to /dev/null.
Hrm, actually that's probably a bug: there probably needs to be
a check for ti-type == NormalFile0 or NormalFile1 around the
fd_null_copy/safe_read in the if (alreadyreplaced) block. Test by
having a symlink in common between the replaced packages rather than a
regular file.
(It's weird. I'm sure I did this patch before already. I must've never
gotten it to work though.)
I've given it some minimal testing, and I think it's basically sound. The
oldnifd stuff is a memory leak, unfortunately, but trying to avoid that
seems a lot riskier than just leaving it.
diff -urb dpkg-1.10.18/main/archives.c dpkg-1.10.18-aj/main/archives.c
--- dpkg-1.10.18/main/archives.c2003-10-26 06:03:20.0 +1000
+++ dpkg-1.10.18-aj/main/archives.c 2003-11-03 04:40:27.0 +1000
@@ -314,11 +314,11 @@
const char *usename;
struct tarcontext *tc= (struct tarcontext*)ti-UserData;
- int statr, fd, i, existingdirectory;
+ int statr, fd, i, existingdirectory, alreadyreplaced;
size_t r;
struct stat stab, stabd;
char databuf[TARBLKSZ];
- struct fileinlist *nifd;
+ struct fileinlist *nifd, **oldnifd;
struct pkginfo *divpkg, *otherpkg;
struct filepackages *packageslump;
mode_t am;
@@ -331,6 +331,7 @@
*/
nifd= obstack_alloc(tar_obs, sizeof(struct fileinlist));
nifd-namenode= findnamenode(ti-Name, 0);
+ oldnifd= tc-newfilesp; /* in case we don't want this file after all :( */
nifd-next= 0; *tc-newfilesp= nifd; tc-newfilesp= nifd-next;
nifd-namenode-flags |= fnnf_new_inarchive;
@@ -423,6 +424,7 @@
ohshit(_(archive contained object `%.255s' of unknown type
0x%x),ti-Name,ti-Type);
}
+ alreadyreplaced= 0;
if (!existingdirectory) {
for (packageslump= nifd-namenode-packages;
packageslump;
@@ -441,19 +443,40 @@
divpkg ? divpkg-name : none);
if (otherpkg == divpkg || tc-pkg == divpkg) continue;
}
+
/* Nope ? Hmm, file conflict, perhaps. Check Replaces. */
-if (otherpkg-clientdata-replacingfilesandsaid) continue;
+
+/* Already noticed this package is replacing us or being replaced? */
+if (otherpkg-clientdata-replacingfilesandsaid == 1) continue;
+if (otherpkg-clientdata-replacingfilesandsaid == 2) {
+ alreadyreplaced= 1;
+ continue;
+ }
+
/* Is the package with the conflicting file in the `config files
* only' state ? If so it must be a config file and we can
* silenty take it over.
*/
if (otherpkg-status == stat_configfiles) continue;
+
/* Perhaps we're removing a conflicting package ? */
if (otherpkg-clientdata-istobe == itb_remove) continue;
+
if (does_replace(tc-pkg,tc-pkg-available,otherpkg)) {
printf(_(Replacing files in old package %s ...\n),otherpkg-name);
otherpkg-clientdata-replacingfilesandsaid= 1;
-} else {
+ continue;
+}
+
+ /* Maybe we're being replaced? */
+ if (does_replace(otherpkg,otherpkg-installed,tc-pkg)) {
+ printf(_(Replacing files using old package %s
...\n),otherpkg-name);
+ otherpkg-clientdata-replacingfilesandsaid= 2;
+ alreadyreplaced= 1;
+ continue;
+ }
+
+{
if (!statr S_ISDIR(stab.st_mode)) {
forcibleerr(fc_overwritedir, _(trying to overwrite directory
`%.250s'
in package %.250s with nondirectory),
@@ -481,6 +504,18 @@
if (existingdirectory) return 0;
+ if (alreadyreplaced) {
+{ char fnamebuf[256];
+fd_null_copy(tc-backendpipe,ti-Size,_(zap already replaced file
`%.255s'),quote_filename(fnamebuf,256,ti-Name));
+}
+r= ti-Size % TARBLKSZ;
+if (r 0) r= safe_read(tc-backendpipe,databuf,TARBLKSZ - r);
+
+tc-newfilesp= oldnifd;
+*oldnifd= 0;
+return 0;
+ }
+
/* Now we start to do things that we need to be able to undo
* if something goes wrong.
*/
Anyway, FWIW, HTH, etc.
Cheers,
aj
--
Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/
I don't speak for anyone save myself. GPG signed mail preferred.
Australian DMCA (the Digital Agenda Amendments) Under Review!
-- http://azure.humbug.org.au/~aj/blog/copyright/digitalagenda
Re: Bug#213524: automake: serious breakage with new install-info behaviour
reassign 213524 dpkg thanks Hi dpkg guys as a rule it's a bad idea to change behaviours that other packages rely on when we're trying to release. Please revert this change ASAP. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. Australian DMCA (the Digital Agenda Amendments) Under Review! -- http://azure.humbug.org.au/~aj/blog/copyright/digitalagenda
Re: Use of pseudo-tags to mark translation issues
On Fri, Sep 19, 2003 at 08:23:17AM +0200, Philippe Faes wrote: I am not convinced that the first option is better. Well, note that you're not really the one that needs to be convinced. There are about three ways of tagging bugs in the BTS at the moment. One is the obvious tag command. It's largely limited to things that are useful to everyone and every package; and the exceptions to that rule will probably go away. Another is the subject tagging that Adam's started using on dpkg; it's there to allow the package maintainer to better manage his/her bugs, and for no other reason. Appropriate tags for that are whatever is helpful for the maintainer. The third way are separately maintained databases of tags that are passed to the BTS, such as is being used by the LSB team and for the Bugsquash pages [0]. This is a pretty new feature, and we haven't quite worked out the best way for people to use it yet, but it's much more generalisable than either of the others. Cheers, aj [0] http://bugs.debian.org/cgi-bin/lsb.cgi http://bugs.debian.org/cgi-bin/claims.cgi -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. Australian DMCA (the Digital Agenda Amendments) Under Review! -- http://azure.humbug.org.au/~aj/blog/copyright/digitalagenda pgpwPoNFXG87d.pgp Description: PGP signature
Re: New package dependency field format
On Thu, Sep 04, 2003 at 06:43:55PM +0200, Josip Rodin wrote: On Wed, Sep 03, 2003 at 05:13:25PM +0100, Andrew Suffield wrote: Depends: foo | ! bar That can be read as If bar is installed, then foo must also be installed. That still sounds redundant, and can be currently expressed with Depends: foo, foo | bar That's not equivalent: in the original case you can have neither foo nor bar installed. What is equivalent is: foo Depends: foo | foobar-dummy foobar-dummy Conflicts: bar Note that it would require a major rewrite of the logic of the testing scripts to cope with syntax like foo | !bar. And given the total lack of gain, it's not something that I'm willing to do or to support. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``Is this some kind of psych test? Am I getting paid for this?'' pgp0Y8dpHzUrJ.pgp Description: PGP signature
Bug#173205: dpkg-dev: dpkg-architecture revert to i386
severity 173205 normal thanks There is nothing in this report to warrant a serious severity. -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``Is this some kind of psych test? Am I getting paid for this?''
Bug#206416: dpkg package hash table insufficient
On Wed, Aug 20, 2003 at 10:04:07PM +0100, Daniel Silverstone wrote:
Let's have a look...
*hauls out...
(c) Introduction to algorithms, Cormen, Leiserson Rivest
and opens them up*
(c) Page 228 The division method
When using the division method, we usually avoid certain values of m.
For example, m should not be a power of 2...
...good values for m are primes, not too close to exact powers of 2.
Reading further:
---
The multiplication method
The /multiplication method/ for creating hash functions operates in two
steps. First, we multiply the key /k/ by a constant /A/ in the range 0 A
1 and extract the fractional part of /kA/. Then, we multiply this value
by /m/ and take the floor of the result. In short, the hash function is:
h(k) = |_ m(kA mod 1) _|
where hA mod 1 means the fractional part of kA, that is kA - |_ kA _|.
An advantage of the multiplication method is that the value of /m/ is not
critical. We typically choose it to be a power of 2 -- m = 2^p for some integer
/p/ -- since we can then easily implement the function on most computers as
follows. [...]
---
Apparently Knuth suggests A = (sqrt(5) - 1) / 2 ~= 0.6180339887...,
so if the word size is w (32 bits, eg), then 0 = k 2^w, then
s * 2^w + r = k |_ A * 2^w _|
(note 0 = s,r 2^w), and the hash value is the p most significant
bits of r.
For comparison, britney uses:
long strhash(const char *x, unsigned char pow) {
unsigned long i = 0;
while (*x) {
i = (i * 39 + *x) % (1UL pow);
x++;
}
return i;
}
to generate an index into an array of 2^pow elements from package
names. It works pretty well. pow is generally 14 (ie, a hash size
of 16,384).
Cheers,
aj
--
Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/
I don't speak for anyone save myself. GPG signed mail preferred.
``Is this some kind of psych test?
Am I getting paid for this?''
pgpABAeiSTlkK.pgp
Description: PGP signature
Bug#183195: dpkg: Replaces is not properly handled for Replaced packages
On Sun, Mar 02, 2003 at 09:30:01PM -0800, Brian Nelson wrote: Right now, coreutils replaces debianutils (= 2.3.1). However, if I try to install both packages simultaneously (e.g. using debootstrap), or try to reinstall debianutils, I get: dpkg: error processing /var/cache/apt/archives/debianutils_2.3.1_i386.deb (--unpack): trying to overwrite `/bin/readlink', which is also in package coreutils Replaces is (unfortunately) a one way relationship -- you have to install the replacing package after the replaced package. Doing this with essential packages seems a bit odd; not having a fixed debianutils yet seems quite wrong. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``Dear Anthony Towns: [...] Congratulations -- you are now certified as a Red Hat Certified Engineer!''
Bug#112386: patch
Hi,
The removal code's not actually all that bad, just not broken up
into chunks all that well. I believe the following three patches are
legitimate. The first two split the ridiculously long removal_bulk() into
slightly more reasonably sized pieces (one that handles the details of
--remove aspect, the other than handles the details of the --purge aspect)
and should be obviously correct. The third adds a new function based on
the first one split out that just goes through retrying all the empty
directories.
The empty directory removal happens in a different place to the original
comment so that --purge will consistently delete empty directories that
weren't deleted on --remove because the admin put something in there,
rather than doing it sometimes bug not others (specifically when the
package didn't have conffiles or a postrm, and the file was removed by
the admin or possibly another package between --remove and --purge).
I've done some limited testing, and it seems to work as desired.
Attached. HTH.
Cheers,
aj
--
Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/
I don't speak for anyone save myself. GPG signed mail preferred.
``Australian Linux Lovefest Heads West''
-- linux.conf.au, Perth W.A., 22nd-25th January 2003
--- remove.c.0 2002-12-17 20:26:17.0 +1000
+++ remove.c.1 2002-12-17 20:26:17.0 +1000
@@ -1,3 +1,9 @@
+/* Change: separate removal_bulk handling of halfinstalled or unpacked pkgs
+ * (ie, remove the real files in the .deb) into its own function.
+ * Note that installed state is converted to unpacked by
+ * deferred_remove() or halfinstalled by process_archive())
+ */
+
/*
* dpkg - main program for package management
* remove.c - functionality for removing packages
@@ -173,32 +179,20 @@
*leftoverp= newentry;
}
-void removal_bulk(struct pkginfo *pkg) {
- /* This is used both by deferred_remove in this file, and at
- * the end of process_archive in archives.c if it needs to finish
- * removing a conflicting package.
- */
- static const char *const removeconffexts[]= { REMOVECONFFEXTS, 0 };
-
- static struct varbuf fnvb, removevb;
-
- int before, r, foundpostrm= 0, removevbbase;
- int infodirbaseused, conffnameused, conffbasenamelen, pkgnameused;
- char *conffbasename;
+static void removal_bulk_remove_files(
+struct pkginfo *pkg,
+int *out_foundpostrm)
+{
+ int before;
+ int infodirbaseused;
struct reversefilelistiter rlistit;
- struct conffile *conff, **lconffp;
- struct fileinlist *searchfile, *leftover;
- struct stat stab;
+ struct fileinlist *leftover;
+ struct filenamenode *namenode;
+ static struct varbuf fnvb;
DIR *dsd;
struct dirent *de;
- char *p;
- const char *const *ext;
- const char *postrmfilename;
- struct filenamenode *namenode;
-
- debug(dbg_general,removal_bulk package %s,pkg-name);
+ struct stat stab;
- if (pkg-status == stat_halfinstalled || pkg-status == stat_unpacked) {
pkg-status= stat_halfinstalled;
modstatdb_note(pkg);
push_checkpoint(~ehflag_bombout, ehflag_normaltidy);
@@ -286,11 +280,13 @@
varbufaddc(fnvb,0);
dsd= opendir(fnvb.buf); if (!dsd) ohshite(_(cannot read info directory));
push_cleanup(cu_closedir,~0, 0,0, 1,(void*)dsd);
-foundpostrm= 0;
+ *out_foundpostrm= 0;
debug(dbg_general, removal_bulk cleaning info directory);
while ((de= readdir(dsd)) != 0) {
+char *p;
+
debug(dbg_veryverbose, removal_bulk info file `%s', de-d_name);
if (de-d_name[0] == '.') continue;
p= strrchr(de-d_name,'.'); if (!p) continue;
@@ -299,7 +295,7 @@
debug(dbg_stupidlyverbose, removal_bulk info this pkg);
/* We need the postrm and list files for --purge. */
if (!strcmp(p+1,LISTFILE)) continue;
- if (!strcmp(p+1,POSTRMFILE)) { foundpostrm=1; continue; }
+if (!strcmp(p+1,POSTRMFILE)) { *out_foundpostrm=1; continue; }
debug(dbg_stupidlyverbose, removal_bulk info not postrm or list);
fnvb.used= infodirbaseused;
varbufaddstr(fnvb,de-d_name);
@@ -314,8 +310,36 @@
pkg-installed.essential= 0;
modstatdb_note(pkg);
push_checkpoint(~ehflag_bombout, ehflag_normaltidy);
+}
+
+void removal_bulk(struct pkginfo *pkg) {
+ /* This is used both by deferred_remove in this file, and at
+ * the end of process_archive in archives.c if it needs to finish
+ * removing a conflicting package.
+ */
+ static const char *const removeconffexts[]= { REMOVECONFFEXTS, 0 };
+
+ static struct varbuf fnvb, removevb;
+
+ int r, foundpostrm= 0, removevbbase;
+ int conffnameused, conffbasenamelen, pkgnameused;
+ char *conffbasename;
+ struct conffile *conff, **lconffp;
+ struct fileinlist *searchfile;
+ DIR *dsd;
+ struct dirent *de;
+ char *p;
+ const char *const *ext;
+ const char *postrmfilename;
+
+ debug(dbg_general,removal_bulk package %s,pkg-name);
+
+ if (pkg-status == stat_halfinstalled || pkg-status
Re: [devel-ref] author/homepage in description
On Mon, Dec 16, 2002 at 12:12:08PM +0100, Wichert Akkerman wrote: Previously Adam DiCarlo wrote: Well, before I venture on this, is there a way we can store certain data in control.tar.gz or something but without bloating the Packages file? No. Well, strictly, there obviously is: postinsts don't end up in Packages.gz after all. It doesn't make any sense for this though. It is relevant to the discusison though.. do we want to bloat the Packages file with usptream author homepage information as well? The Packages file is mainly meant to be all the information you should need to work out whether you want to install a package or not: description, what other packages you need, a file name to download, etc. A More-Info-URL: field might make sense here in that it'd let you find out more about the package, see screeenshots and so forth. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``Australian Linux Lovefest Heads West'' -- linux.conf.au, Perth W.A., 22nd-25th January 2003
Re: Bug#160424: dpkg lock file should be in /var/lock
On Fri, Nov 15, 2002 at 05:48:55PM -0600, Steve Greenland wrote:
If they are to have the exact same files installed, then you can't
run any dpkg command that modifies the system (because they'll be out
of sync), so what needs to be locked? Or, more to point, if you run a
dpkg in a way that requires the lock, you're screwing up the system
anyway; all that having the lock shared would do is prevent you from
from screwing up both systems at the same time.
Or am I, as usual, missing your point?
If you've got /var mounted over NFS, you might as well have /usr mounted
over NFS too -- so dpkg will still keep most of your files in sync. I'm
ignoring /etc and /{lib,bin,...} presuming that they're magically handled
specially somehow.
Cheers,
aj
--
Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/
I don't speak for anyone save myself. GPG signed mail preferred.
``If you don't do it now, you'll be one year older when you do.''
Bug#160424: dpkg lock file should be in /var/lock
] The FHS says: ] ] 5.6 /var/lock : Lock files ] ] Lock files should be stored within the /var/lock directory ] structure. While it does say this, that section mainly goes on to discuss device locking (for the serial port, and suchlike). Elsewhere it explains: ]Editor-specific lock files are usually quite different from the device ]or resource lock files that are stored in /var/lock and, hence, are ]stored under /var/lib. I'm not sure it's fair to say that dpkg's locks (on /var/lib/dpkg/status) are more like device locks than those made by editors. The FHS also indicates that /var/lock can't be shared between machines. Is it plausible to share /var/lib/dpkg amongst machines? It seems like it could be, as long as they have the exact same files installed. In that case it would probably be better to have the dpkg lock shared too, so you don't accidently start two dpkg's on different machines just as you wouldn't on a single machine. FWIW, etc. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``If you don't do it now, you'll be one year older when you do.'' pgpRRfOoeJgzN.pgp Description: PGP signature
Re: dpkg enhancements for better debconf support
On Mon, Sep 09, 2002 at 06:33:41PM -0400, Joey Hess wrote: 2. Somehow work out which regular maintainer scripts expect to communicate with debconf, and run them under /usr/bin/debconf. How about just having something like #!/usr/lib/debconf/script /bin/sh ? Benefits: easy to make work, doesn't break backwards compatability, possibly others. Drawbacks? Cheers, aj, who still thinks Bug#50595 is the real problem -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``If you don't do it now, you'll be one year older when you do.'' pgp70lWNSnmre.pgp Description: PGP signature
Re: dpkg should recommend dselect
On Sat, Aug 10, 2002 at 07:16:30AM +1000, Glenn McGrath wrote: I think we should be reduceing the number of required packages, not increasing them. Isn't it great how everyone starts whining about things like this, when there's nothing to be done, beyond what's being done? It gets even more fun and enlightening after a year's worth of moaning, too! Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``If you don't do it now, you'll be one year older when you do.''
Re: thoughts on signature verification
On Thu, Aug 08, 2002 at 01:04:34AM -0400, Colin Walters wrote: Also, I do think that we could create a good default policy which would provide a reasonable amount of additional security, and not be too intrusive. Basically, the policy should default to verifying against the Debian keyring, or /etc/dpkg/local-keys.gpg or something. That way someone applying to NM could just drop their key in that file, and tell their sponsor to do the same. ] $ cat /etc/dpkg/sourcekeys.conf ] /usr/share/keyrings/debian-keyring.pgp ] /usr/share/keyrings/debian-keyring.gpg ] /home/newbie/.gnupg/trustedkeys.gpg could work. Of course, we really need to make apt verify the Release signature too... Apt can/should handle things in a more complicated way; in particular if it's downloading packages from Debian it should expect a Debian signature, while downloading Blackdown Java or OpenOffice.org stuff should have a signature from a Blackdown or OpenOffice.org key. Dpkg, OTOH, can't tell where a package is meant to have come from, so can only do: a) Check the signature's valid, and report who signed it b) Expect the user to tell it which keyring to use, and check that the key's in that keyring (dpkg-source --from=debian -x *.dsc) c) Check that the signature is from the Maintainer: Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``If you don't do it now, you'll be one year older when you do.''
Bug#155676: patch] dynamic sha1sums generation
On Wed, Aug 07, 2002 at 01:56:36PM -0400, Colin Walters wrote: On Wed, 2002-08-07 at 02:42, Anthony Towns wrote: True. And actually any weaknesses in MD5 are rather irrelevant for this particular case, because a hostile attacker will be able to simply replace any of the checksum files they want. Well, unless you backup /var/lib/dpkg/checksums/ to WORM media, like a CD ROM or paper. I had the coolest little hack that'd let you verify large numbers of md5sums by hand from paper once... (think binary-trees, and md5sums of md5sums) But the key part of this is to have dpkg generate the md5sums at install time. I suppose it'd actually be handy if you could generate the md5sums just from the .deb without having to unpack it, too. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``If you don't do it now, you'll be one year older when you do.''
Re: thoughts on signature verification
On Thu, Aug 08, 2002 at 01:51:50PM -0400, Ben Collins wrote: Dpkg, OTOH, can't tell where a package is meant to have come from, so can only do: a) Check the signature's valid, and report who signed it b) Expect the user to tell it which keyring to use, and check that the key's in that keyring (dpkg-source --from=debian -x *.dsc) c) Check that the signature is from the Maintainer: You really need the read the debsig-verify package signing docs. And you need to get a clue. Oh wait, I've already read them, and you already have a clue. Why're we insulting each other, again? In fact, anything can tell with a good bit of security, just where a package came from. No, it can't. When you've got something that's both feasible and secure *at the same time* this might be worth discussing, but you don't, so it's not. We've been over this again, and again, and again. The signing policy included in the debsigs package is *completely irrelevant* for Debian. (note, the URL you download it from is not a security measure, especially considering lots of people have local mirrors, or hand-downloaded packages). The URL you download it from *is* a security measure: if you're downloading something from Blackdown you expect it to be Java related and to have been signed by Blackdown -- and if it's not you probably should start wondering what someone's trying to do. Dpkg has no possibility of automatically checking this (since you might've downloaded it using wget, eg), Apt does (since it does the downloading itself). This isn't a flaw that needs a spirited defense, it's just a fact. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``If you don't do it now, you'll be one year older when you do.'' pgpRDVIyNkZzp.pgp Description: PGP signature
Bug#155676: patch] dynamic sha1sums generation
On Tue, Aug 06, 2002 at 01:04:23AM -0400, Colin Walters wrote: I chose SHA1 over using MD5 because I've heard word going around that while MD5 isn't insecure, it is less secure than previously thought. Specifically that if you can control the size of the file as well, it's easier to find a matching MD5 sum. AIUI, that's usually avoided by listing the file size as well as the md5sum. At the very least listing the expected file size gives you a very easy check for a lot of accidental corruption. Plus, using /var/lib/dpkg/info/foo.sha1sums avoids a naming conflict with the foo.md5sums file. Wouldn't it be more sensible to put it in /var/lib/dpkg/checksums/foo.sha1 or similar? Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``If you don't do it now, you'll be one year older when you do.''
Re: Bug#149974: debootstrap should download aptitude
On Sat, Jun 15, 2002 at 01:35:24AM -0500, Adam Heath wrote: We've done it correctly. dpkg 1.10 predepends on dselect. dselect 1.10 replaces dpkg ( 1.10). This will ensure upgrades, and no loss of functionality. Any new dependencies from base packages to non-base packages need to a new debootstrap. Please file a bug against debootstrap either before or at least concurrent with the upload. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``BAM! Science triumphs again!'' -- http://www.angryflower.com/vegeta.gif -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#149974: debootstrap should download aptitude
tag 149974 - patch thanks On Fri, Jun 14, 2002 at 04:02:11PM +0200, Ivo Timmermans wrote: The new base-config package in sid depends on aptitude, so debootstrap should download it. Bleh. Guys, please file the bug on debootstrap *before* adding new dependencies to base packages and breaking it completely. Joey, are you sure it wouldn't have been better to make base-config use aptitude if present, and file a wishlist bug on debootstrap to ensure its presence on normal installs? -dpkg guys, cc'ed so we don't get the same thing happening with the presumably forthcoming dselect package. -boot guys, cc'ed in the probably vain hope that anyone else likely to do this in future will notice too. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``BAM! Science triumphs again!'' -- http://www.angryflower.com/vegeta.gif -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#148221: dpkg: Small off by one error in parseversion()
On Sun, May 26, 2002 at 11:42:39PM -0500, Adam Heath wrote:
--- lib/parsehelp.c.origSun May 26 19:24:23 2002
+++ lib/parsehelp.c Sun May 26 19:22:34 2002
@@ -214,7 +214,7 @@
} else {
rversion-epoch= 0;
}
- rversion-version= nfstrnsave(string,end-string+1);
+ rversion-version= nfstrnsave(string,end-string);
hyphen= strrchr(rversion-version,'-');
if (hyphen) *hyphen++= 0;
rversion-revision= hyphen ? hyphen : ;
This is a problem, but this is not the proper fix.
Let's say string == 0x5, and end = 0x6. This means we need to copy 2
chars(0x5 and 0x6, or 0x6 - 0x5 + 1). So, your buffer overrun does not occur
in this code.
Erm, while that's strictly correct, I don't think it's what's intended. If
you start with:
1.2.3
you end up with:
x12345678
1.2.3
^^
||
|end
string
...in which case end - string is ((x+8) - (x+3)) = 5 which is the number
of characters you want to save -- no +1 needed. The extra space or \0
or tab that end points to presumably isn't interesting, and could result
in incorrect behaviour if you compare 1.2.3-1 against 1.2.3-1.
The solution, is to use obstack_copy0, instead of obstack_copy, and not add 1
to l.
In which case you still end up with 1.2.3 instead of 1.2.3, which
still seems like a bug, although it won't cause a segfault anymore.
Cheers,
aj
--
Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/
I don't speak for anyone save myself. GPG signed mail preferred.
``BAM! Science triumphs again!''
-- http://www.angryflower.com/vegeta.gif
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#145595: dpkg: --force-overwrite is supposed to be on for releases
On Thu, May 09, 2002 at 10:46:31PM -0500, Adam Heath wrote: On another note(not for woody), would it be beneficial to have this file not be a conffile? That'd let boot-floppies or base-config mess with it if they thought they could choose better defaults (eg, people who install testing or unstable might default to not having --force-overwrite). My direct question to you, Anthony, is whether you would accept this disk space fix. I like to leave such things up to the maintainer where possible. Avoid doing anything remotely risky, make sure it's tested in all the common cases as well as whatever you're fixing, don't change the behaviour for any situation where it used to work, and so on. Run it by Wichert. Post it here with an explanation of what's going on if you still have any doubts. If after all that, you and Wichert (as dpkg maintainers) think it's appropriate to upload that along with the dpkg.cfg fix, I'm happy to go with it. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``BAM! Science triumphs again!'' -- http://www.angryflower.com/vegeta.gif pgps0owcVgUtV.pgp Description: PGP signature
Bug#145595: dpkg: --force-overwrite is supposed to be on for releases
On Sat, May 04, 2002 at 10:09:47PM -0400, Joey Hess wrote: That's a valid POV I suppose, but base-config is still not the place. Whatever turns force-overwrite on needs to be an essential package, so it is upgraded quite early, and so it is guaranteed to be installed in the first place. Base-config doesn't meet the criteria. The package that comes closest, in my mind, is dpkg... I think you missed Wichert's point. Suppose you have a relatively ignorant user running testing, and a developer running unstable. The former shouldn't have to worry about file clashes, the latter should. If whether this happens depends on whether you've got dpkg A or dpkg B installed, there'll be a problem when dpkg B migrates from unstable to testing and replaces dpkg A. Thus, having it done in dpkg (or any package) as part of an upgrade isn't a working solution. If you want force-overwrite turned off only on request, why not default it to on in dpkg and then tell developers to edit dpkg.cfg and turn it off? That's a good question. Maybe we should change our answer. The easiest way to do so is by uploading a new base-config. Joey, would you object to an NMU to do so? Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``BAM! Science triumphs again!'' -- http://www.angryflower.com/vegeta.gif pgpi9pxOBdu2B.pgp Description: PGP signature
Bug#145595: dpkg: --force-overwrite is supposed to be on for releases
On Mon, May 06, 2002 at 03:31:56AM -0600, Adam Conrad wrote: If we can all agree that the default for normal users (and I'm not sure there's even close to a consensus here, but let's pretend for the moment that there is) should be --force-overwrite, then dpkg should be shipping this conffile in THAT state, That's nice. It's a shame we didn't think of it earlier. But we didn't. It's far easier to make base-config handle it for woody. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``BAM! Science triumphs again!'' -- http://www.angryflower.com/vegeta.gif -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#145595: dpkg: --force-overwrite is supposed to be on for releases
On Fri, May 03, 2002 at 12:39:26PM -0400, Joey Hess wrote: Anthony Towns wrote: It'd be relatively straightforward to have the installer enable force-overwrite on stable installs and disable it on testing installs. But for woody, surely the best thing is to just have base-config munge it (editing /var/lib/dpkg/status if you like) and be done with it? Worrying about changing it from a conffile to something maintained in the maintainer scripts can be done when 1.10.x comes out. I don't really want to make base-config mess with this for woody, the damn thing has broken enough recently. Well, our choices are: * new dpkg release * new boot-floppies for all architectures that munge it (maybe via debootstrap) * new base-config that munges it * don't fix the problem A new base-config seems by far the easiest to get right, doesn't need people to spend a few days building it, and since it's needed anyway... Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``BAM! Science triumphs again!'' -- http://www.angryflower.com/vegeta.gif -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#142324: ER] Should add homepage URL in package description
On Thu, Apr 25, 2002 at 05:55:03PM +0200, Wichert Akkerman wrote: Previously Josip Rodin wrote: PTS is useless for dpkg, just subscribe to the mailing list... Esp. since the BTS isn't aware of it and that is what generates the Reply-To address I send my replies to. What do you mean? Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``BAM! Science triumphs again!'' -- http://www.angryflower.com/vegeta.gif -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg triggers
On Sun, Mar 31, 2002 at 12:40:10PM +0100, Russell Coker wrote: On Sun, 31 Mar 2002 12:36, Colin Watson wrote: On Fri, Mar 29, 2002 at 04:04:10PM +1000, Anthony Towns wrote: Other applications are for update-menus and for things like texhash, which really only need to be run once after a complete apt-get dist-upgrade (or maybe not at all if none of the applicable packages got upgraded). It might make sense for mandb, too. This sounds different to what I want. I want a script to be run after every package is installed. But running a script after the completion of apt-get would be handy too. A way of doing both would be to add a simple database, which maps an event to a script to be run. Possible events could be dpkg run, or postinst of package name glob. It'd seem like a more flexible infrastructure than having 8 directories to run-parts over for every package that's changed, at least. (iirc, run-parts is also pretty horrible at passing information to and from the scripts) Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. Vote [1] Bdale! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg triggers
On Fri, Mar 29, 2002 at 12:18:38AM +0100, Russell Coker wrote: On Fri, 29 Mar 2002 00:13, Brian May wrote: On Thu, Mar 28, 2002 at 02:18:37AM +0100, Russell Coker wrote: I'm working on a hack for dpkg to allow equivalent functionality to rpm triggers. What applications does this have? What I want to do is relabel files with the SE Linux context after each package is installed. More generically any time you need to have your script be run after another package is installed you can have a trigger do it. Other applications are for update-menus and for things like texhash, which really only need to be run once after a complete apt-get dist-upgrade (or maybe not at all if none of the applicable packages got upgraded). Running a bunch of scripts after every single postinst would seem pretty hideous for an upgrade between stable releases. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. Vote [1] Bdale! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#139320: marked as done (dpkg: dpkg-deb does not dynamically link libz)
On Fri, Mar 22, 2002 at 02:50:47PM +1000, Wichert Akkerman wrote: Err? WTF happened there? I wrote that, as the Sender: and signature indicate, not Wichert. How fucked up. Wichert wrote: Previously Daniel Quinlan wrote: Also, given the dependencies on c++ and ncurses already, adding libz which dozens of packages depend on seems like a trivial addition. The dependencies of dpkg itself are minimal and do not include c++ and ncurses. [...] This change was made on purpose to make sure that dpkg will be useable on broken systems where libz might not be working correctly and to make it easier to bootstrap a system. Not depending on libz doesn't make it any easier to bootstrap a system, you already get all the complexity just by needing libc. (Either by requiring you to unpack the libs without dpkg first somehow, or by requiring you to have appropriate libraries in the host system) Cheers, aj, debootstrap author pgpNV4fI6OsvY.pgp Description: PGP signature
Bug#139320: dpkg: dpkg-deb does not dynamically link libz
On Fri, Mar 22, 2002 at 11:49:29AM +1100, Glenn McGrath wrote: If dpkg depends on libz and libz becomes unusable (deleted broken whater) then it could be a major hasle to fixed. Likewise if libc6 becomes deleted or broken or whatever. Or if dpkg does. Or if something in /var/lib/dpkg gets deleted. Or if /etc/passwd goes byebye. libz isn't particularly more likely than any of these to break. If apt is installed (and it is statically linked against libz) then it could used to fix libz by doing apt-get install libz, but dpkg is Essential: yes, apt isnt so dpkg should be more solid. If Priority: required packages are broken (ie, things marked Essential: yes, or things which they depend on), then you can't use the package tools to fix them when they break. We've already got a whole bunch of packages in priority required (perl-base, awk, sed, etc) that could end up broken just as easily as libz, so this is pretty much a null argument. If apt wasnt around and dpkg was broken If dpkg is broken, apt is too. the user would have to extract the libz by hand, using ar and gzip and tar, which a lot of users wouldnt know how to do. And, like I said, this is, by definition, the case for all required and essential packages. That people don't have to know how to use ar, gzip and tar is a testament to how little most of these packages break. There's no evidence that libz breaks more frequently than anything else. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``Debian: giving you the power to shoot yourself in each toe individually.'' -- with kudos to Greg Lehey pgpBrzzkROM6B.pgp Description: PGP signature
Re: pending dpkg 1.10 release
On Sat, Jul 28, 2001 at 12:59:28PM +1000, Anthony Towns wrote: dselect Pre-Depends: dpkg dpkg Replaces: dselect ? That could be made to work... What could also probably be made to work is something like: Package: dselect Priority: important Section: base Replaces: dpkg Package: dpkg Recommends: dselect Possibly with some preinst trickery like Ben's libc6 trickery to ensure dselect doesn't get broken during the upgrade. Which would allow you to remove dselect whenever you wanted. An obvious problem with adding a package that dpkg depends on is that it will completely break all current boot-floppies; and splitting dselect into a new package will break the install when it gets to tasksel. It's really way too late to be considering this. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``_Any_ increase in interface difficulty, in exchange for a benefit you do not understand, cannot perceive, or don't care about, is too much.'' -- John S. Novak, III (The Humblest Man on the Net) pgpAfGPCg7u8m.pgp Description: PGP signature
Re: pending dpkg 1.10 release
On Fri, Jul 27, 2001 at 01:01:32PM +0200, Wichert Akkerman wrote: Previously Anthony Towns wrote: I've heard rumours this breaks things. How's it implemented, dependency-wise? Pre-Depends and Replaces, tested with manual, apt-get ugprade and dselect upgrades. dselect Pre-Depends: dpkg dpkg Replaces: dselect ? That could be made to work... How *exactly* is it implemented? Cheers, aj, who notes the given deadline for new base packages passed about a week ago now -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``_Any_ increase in interface difficulty, in exchange for a benefit you do not understand, cannot perceive, or don't care about, is too much.'' -- John S. Novak, III (The Humblest Man on the Net) pgpg4mMdw3Od0.pgp Description: PGP signature
Re: Bug#95921: superformat isn't on root.bin or installed by debootstrap
On Tue, May 01, 2001 at 12:23:37AM -0700, David Whedon wrote: dbootstrap attempts to execute /target/bin/superformat. debootstrap has not installed the package fdutils where superformat would be found. One of the following is probably a good idea: 1. have debootstrap install fdutils, but since it is priority optional that probably doesn't make sense unless it is conditional on the --boot-floppies command line switch. Interestingly slink and potato versions of debootstrap install fdutils. I've added it. I'll look into making debootstrap's base [required+optional]+/-[random other stuff] soon, so that it's more work-with-able. But for now, just hacking around seems fine. Unfortunately, fdutils has an interactive install, so you'll need to hit enter (assuming you can) to use debootstrap now. :( Someone should probably do an NMU, or at least file a bug... Anyway, debootstrap 0.1.7 is in incoming now, fixing this and a handful of other bugs. It kind-of works with sid (assuming you have a mirror that's not half out of date like ftp.d.o...), except that the dpkg segfault bug has gotten worse, so it doesn't get anywhere at all anymore. debootstrap sid sid-chroot http://ftp.kernel.org/debian /usr/lib/debootstrap/scripts/woody with dpkg 0.9.2 segfaults at the first attempt to invoke dpkg. :( Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``_Any_ increase in interface difficulty, in exchange for a benefit you do not understand, cannot perceive, or don't care about, is too much.'' -- John S. Novak, III (The Humblest Man on the Net)
Re: Bug#95921: superformat isn't on root.bin or installed by debootstrap
On Tue, May 01, 2001 at 03:14:17AM -0500, Adam Heath wrote: On Wed, 2 May 2001, Anthony Towns wrote: Anyway, debootstrap 0.1.7 is in incoming now, fixing this and a handful of other bugs. It kind-of works with sid (assuming you have a mirror that's not half out of date like ftp.d.o...), except that the dpkg segfault bug has gotten worse, so it doesn't get anywhere at all anymore. debootstrap sid sid-chroot http://ftp.kernel.org/debian /usr/lib/debootstrap/scripts/woody I can't duplicate this. The only suites avaiable to 0.1.7 are slink, potato, and woody. There is no sid. So use the command you quoted just above, which'll use the woody script to build a sid chroot. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``_Any_ increase in interface difficulty, in exchange for a benefit you do not understand, cannot perceive, or don't care about, is too much.'' -- John S. Novak, III (The Humblest Man on the Net)
Re: PATCH: package verification in dpkg
On Sun, Mar 11, 2001 at 09:53:37PM -0500, Ben Collins wrote: That's why the package should also get signed by the same dinstall key that signs the release sig :P Oh, btw, for people using dselect, apt and apt frontends, signing just the .debs isn't enough. Consider somewhen leaving all the .debs exactly as is, and hax0ring the Packages.gz file to make dpkg appear to conflict with some security fixes, or to depend on some buggy package, or changing the md5sums on some packages so apt'll refuse to install them, or similar. This applies whether you have a `progeny' signature on each .deb or not, too, note. Can we stop the battle of the sigs now please? Sure, I just mean it's probably something Progeny and co want to be aware of. Here seemed as good a place as any to mention it. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``_Any_ increase in interface difficulty, in exchange for a benefit you do not understand, cannot perceive, or don't care about, is too much.'' -- John S. Novak, III (The Humblest Man on the Net)
Re: PATCH: package verification in dpkg
On Fri, Mar 09, 2001 at 10:36:21PM -0500, Ben Collins wrote: Then IMHO they are not very worthwhile. When the best Debian can do is say 'all packages are signed by one of these 800 keys' :P That's why the package should also get signed by the same dinstall key that signs the release sig :P Oh, btw, for people using dselect, apt and apt frontends, signing just the .debs isn't enough. Consider somewhen leaving all the .debs exactly as is, and hax0ring the Packages.gz file to make dpkg appear to conflict with some security fixes, or to depend on some buggy package, or changing the md5sums on some packages so apt'll refuse to install them, or similar. This applies whether you have a `progeny' signature on each .deb or not, too, note. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``_Any_ increase in interface difficulty, in exchange for a benefit you do not understand, cannot perceive, or don't care about, is too much.'' -- John S. Novak, III (The Humblest Man on the Net) pgp9rS8jMz1yW.pgp Description: PGP signature
Re: Installing from scratch with debs
On Sun, Mar 11, 2001 at 11:14:51AM -0800, Zack Weinberg wrote: I ran this script for all the Essential packages and the transitive closure of their dependencies. In case you're curious, these are all the packages which are not Essential but included in the transitive closure: libc6 libcap1 libdb2 libncurses5 libpam-modules libpam-runtime libpam0g libreadline4 libstdc++2.10-glibc2.2 mawk lib* packages aren't allowed to be essential (see policy) since that would make it impossible for us to move to new versions (libc5 - libc6). mawk isn't essential since it uses alternatives and gawk works just as well if you want to swap them. More interesting is the set of packages in required that aren't in the transitive closure of essential. Probably they shouldn't be there... Packages providing daemons tend to start them in their postinst. That's fine in most cases, but not when you're installing into a chroot tree and the same daemon is already running outside. They try to bind their TCP socket(s), fail, and die. Fortunately most postinsts don't consider this a fatal error. boot-floppies and debootstrap link start-stop-daemon to /bin/true to stop this from happening. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``_Any_ increase in interface difficulty, in exchange for a benefit you do not understand, cannot perceive, or don't care about, is too much.'' -- John S. Novak, III (The Humblest Man on the Net) pgpUCbCjsgBKC.pgp Description: PGP signature
Re: Dynamic registration of files to packages
On Mon, Nov 20, 2000 at 11:15:54AM -0600, Steve Greenland wrote: On 20-Nov-00, 09:06 (CST), Anthony Towns aj@azure.humbug.org.au wrote: Mirror as in duplicate, separately. Something like: /var/lib/dpkg/info/ base-passwd.extrafiles: /etc/passwd dpkg.extrafiles: /etc/alternatives/* nvi.extrafiles: /usr/bin/vi vim.extrafiles: /usr/bin/vi So if I had both vim and nvi installed, what does dpkg -S /usr/bin/vi return? All the packages involved in the vi alternatives. Compare and contrast with `dpkg -S /usr/lib', say. The advantage of a dpkg-register is that update-alternatives could call it too. It'd have to do something like: PKG=`dpkg -S /usr/bin/vim | sed 's/:.*//'` dpkg-register /usr/bin/vi $PKG to deal with that, and it probably wouldn't cope well if you manually changed which alternative was being used (which is done by manually ln -sf'ing over the /etc/alternatives link, iirc). Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``We reject: kings, presidents, and voting. We believe in: rough consensus and working code.'' -- Dave Clark pgpeO6nKkwcsU.pgp Description: PGP signature
Re: Dynamic registration of files to packages
On Mon, Nov 20, 2000 at 01:36:38PM +, Martin Michlmayr wrote: * Anthony Towns aj@azure.humbug.org.au [20001120 15:12]: Another thing to consider is whether its desirable for this to be dynamic, or whether it would be better to just mirror the debian/conffiles in some way. This wouldn't work because e.g. /etc/passwd is no conffile. Furthermore, it wouldn't work for files using update-alternatives. Mirror as in duplicate, separately. Something like: /var/lib/dpkg/info/ base-passwd.extrafiles: /etc/passwd dpkg.extrafiles: /etc/alternatives/* nvi.extrafiles: /usr/bin/vi vim.extrafiles: /usr/bin/vi for example. I didn't mean to imply there was any stronger analogy between conffiles and other things to be registered than that they could be recorded in similar files. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``We reject: kings, presidents, and voting. We believe in: rough consensus and working code.'' -- Dave Clark pgpa8uZwKTaFA.pgp Description: PGP signature
close dpkg-iwj bugs
reassign 1526 dpkg close 1526 reassign 1642 dpkg close 1642 reassign 1797 dpkg close 1797 reassign 1818 dpkg close 1818 reassign 1921 dpkg close 1921 reassign 2701 dpkg close 2701 reassign 2828 dpkg close 2828 reassign 2863 dpkg close 2863 reassign 2911 dpkg close 2911 reassign 2973 dpkg close 2973 reassign 3125 dpkg close 3125 reassign 3170 dpkg close 3170 reassign 3218 dpkg close 3218 reassign 3233 dpkg close 3233 reassign 3704 dpkg close 3704 reassign 4195 dpkg close 4195 reassign 4319 dpkg close 4319 reassign 4398 dpkg close 4398 reassign 4450 dpkg close 4450 reassign 4468 dpkg close 4468 reassign 4524 dpkg close 4524 reassign 4641 dpkg close 4641 reassign 4681 dpkg close 4681 reassign 4801 dpkg close 4801 reassign 4863 dpkg close 4863 reassign 4901 dpkg close 4901 reassign 4950 dpkg close 4950 reassign 5044 dpkg close 5044 reassign 5355 dpkg close 5355 reassign 5536 dpkg close 5536 reassign 5639 dpkg close 5639 reassign 5807 dpkg close 5807 reassign 5983 dpkg close 5983 reassign 6006 dpkg close 6006 reassign 6052 dpkg close 6052 reassign 6116 dpkg close 6116 reassign 6842 dpkg close 6842 reassign 6843 dpkg close 6843 reassign 7012 dpkg close 7012 reassign 7057 dpkg close 7057 reassign 7137 dpkg close 7137 reassign 7182 dpkg close 7182 reassign 7326 dpkg close 7326 reassign 7400 dpkg close 7400 reassign 7522 dpkg close 7522 reassign 7564 dpkg close 7564 reassign 7582 dpkg close 7582 reassign 7610 dpkg close 7610 reassign 7638 dpkg close 7638 reassign 7714 dpkg close 7714 reassign 7956 dpkg close 7956 reassign 8389 dpkg close 8389 reassign 8391 dpkg close 8391 reassign 9869 dpkg close 9869 reassign 9893 dpkg close 9893 reassign 9894 dpkg close 9894 reassign 10253 dpkg close 10253 reassign 10825 dpkg close 10825 reassign 11018 dpkg close 11018 reassign 11033 dpkg close 11033 reassign 11047 dpkg close 11047 reassign 11073 dpkg close 11073 reassign 11154 dpkg close 11154 reassign 11246 dpkg close 11246 reassign 11341 dpkg close 11341 reassign 11385 dpkg close 11385 reassign 11601 dpkg close 11601 reassign 11887 dpkg close 11887 reassign 11984 dpkg close 11984 reassign 12187 dpkg close 12187 reassign 12232 dpkg close 12232 reassign 12260 dpkg close 12260 reassign 12440 dpkg close 12440 reassign 13108 dpkg close 13108 reassign 13140 dpkg close 13140 reassign 13283 dpkg close 13283 reassign 13295 dpkg close 13295 reassign 13348 dpkg close 13348 reassign 13432 dpkg close 13432 reassign 13730 dpkg close 13730 reassign 13810 dpkg close 13810 reassign 13929 dpkg close 13929 reassign 14059 dpkg close 14059 reassign 14189 dpkg close 14189 reassign 14341 dpkg close 14341 reassign 14636 dpkg close 14636 reassign 14655 dpkg close 14655 reassign 14663 dpkg close 14663 reassign 14696 dpkg close 14696 reassign 14949 dpkg close 14949 reassign 15017 dpkg close 15017 reassign 15157 dpkg close 15157 reassign 15192 dpkg close 15192 reassign 15332 dpkg close 15332 reassign 15761 dpkg close 15761 reassign 15786 dpkg close 15786 reassign 15912 dpkg close 15912 reassign 15913 dpkg close 15913 reassign 16021 dpkg close 16021 reassign 16415 dpkg close 16415 reassign 16443 dpkg close 16443 reassign 16970 dpkg close 16970 reassign 17125 dpkg close 17125 reassign 17238 dpkg close 17238 reassign 17260 dpkg close 17260 reassign 17283 dpkg close 17283 reassign 17367 dpkg close 17367 reassign 17624 dpkg close 17624 reassign 17732 dpkg close 17732 reassign 17748 dpkg close 17748 reassign 17780 dpkg close 17780 reassign 18147 dpkg close 18147 reassign 18575 dpkg close 18575 reassign 19038 dpkg close 19038 reassign 19146 dpkg close 19146 reassign 19494 dpkg close 19494 reassign 19531 dpkg close 19531 reassign 19618 dpkg close 19618 reassign 19712 dpkg close 19712 reassign 19716 dpkg close 19716 reassign 20192 dpkg close 20192 reassign 20353 dpkg close 20353 reassign 20401 dpkg close 20401 reassign 20776 dpkg close 20776 reassign 20849 dpkg close 20849 reassign 21000 dpkg close 21000 reassign 21061 dpkg close 21061 reassign 21186 dpkg close 21186 reassign 21188 dpkg close 21188 reassign 21399 dpkg close 21399 reassign 21581 dpkg close 21581 reassign 22106 dpkg close 22106 reassign 22115 dpkg close 22115 reassign 22351 dpkg close 22351 reassign 22516 dpkg close 22516 reassign 22690 dpkg close 22690 reassign 22698 dpkg close 22698 reassign 22748 dpkg close 22748 reassign 22804 dpkg close 22804 reassign 22880 dpkg close 22880 reassign 22940 dpkg close 22940 reassign 22999 dpkg close 22999 reassign 23342 dpkg close 23342 reassign 23344 dpkg close 23344 reassign 23469 dpkg close 23469 reassign 23488 dpkg close 23488 reassign 23542 dpkg close 23542 reassign 23611 dpkg close 23611 reassign 23902 dpkg close 23902 reassign 23906 dpkg close 23906 reassign 24035 dpkg close 24035 reassign 24150 dpkg close 24150 reassign 24224 dpkg close 24224 reassign 24309 dpkg close 24309 reassign 24472 dpkg close 24472 reassign 24606 dpkg close 24606 reassign 24613 dpkg close 24613 reassign 24621 dpkg close 24621 reassign 24626 dpkg close 24626 reassign 24690 dpkg
dpkg-iwj bugs
Is there any reason the bugs against dpkg-iwj haven't been reassigned back to dpkg and closed? Is it not the case that dpkg-iwj is officially a dead tree and the bugs being open serve no purpose but to inflate the bug count and make the various bug processing scripts take longer? Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``We reject: kings, presidents, and voting. We believe in: rough consensus and working code.'' -- Dave Clark pgpQwQNDqZXTO.pgp Description: PGP signature
Re: another one removed from the TODO list
On Sat, Jun 17, 2000 at 03:02:44PM -0600, Jason Gunthorpe wrote: On Sat, 17 Jun 2000, Wichert Akkerman wrote: Previously Jason Gunthorpe wrote: Old behavior: Allow A+B, New behavior: Fail. slink apt+dpkg will happily upgrade to potato, we just recommend new tools for some corner cases. I think you'll find that versioned provides will be a corner case as well. A practical one at times though. Uh, not being able to use slink/potato APT to install woody APT/dpkg/libc is not a 'corner case'. Well, one easy solution to this is just to release woody before anyone realises that versioned provides are available. A more general solution would be to add a lintian check and file RC bugs for them until woody's released. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``We reject: kings, presidents, and voting. We believe in: rough consensus and working code.'' -- Dave Clark pgpaJkPZvHFCl.pgp Description: PGP signature
Re: statoverride implemented
On Tue, Jun 13, 2000 at 04:35:05PM +0200, Wichert Akkerman wrote: This has an advantage over suidmanager: there is no longer a delay between when a file is created, and when its status can be changed in the postinst. No more ping not suid bugs! Please excuse me while I squeal with delight. It can of course also be done in the postinst, but then you will still have a delay between extraction of the file and changing the ownership/filemode. This doesn't need to be done by the .deb itself though, does it? We just distribute the binaries suid, and leave the admin to change the mode when s/he feels inclined. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``We reject: kings, presidents, and voting. We believe in: rough consensus and working code.'' -- Dave Clark pgpZVvvrWsEt4.pgp Description: PGP signature
Re: Proposal new source archive format
are reversed. Any patches that remain are will be the debian-ization patch. This isn't necessarily possible, is it? Given a.tar, ab.diff, bc.diff and d/, you can go from a to b to c, and then diff c and d, but you can't necessarily go from d to b+(d-c) to a+(d-b-c) and diff that against a and declare that it's the same as cd.diff? What's wrong with just unpacking the original source, applying the diffs you've got and then working out the debianization patch in essentially the same way we do now? dir|directory dir rev|reverse (only for patches) fuzz level (only for patches) You probably need a prune level number of leading `[^/]*/' things to prune off. Definitely for patches, and ideally for tarballs too, really. upstream tar vim-src-5.5.tar.gz upstream tar vim-rt-5.5.tar.gz upstream patch vim-5.5/debian/patches/5.5.001 upstream patch vim-5.5/debian/patches/5.5.002 upstream patch vim-5.5/debian/patches/5.5.003 upstream patch vim-5.5/debian/patches/5.5.004 debian patch vim-5.5/debian/patches/deb-pixmapbg debian patch vim-5.5/debian/patches/deb-newxterm For netbase this would presumably look more like: upstream tar net-tools-1.54.tar.gz dir netbase-3.18/net-tools prune 1 upstream tar ifupdown-0.5.5.tar.gz dir netbase-3.18/ifupdown prune 1 upstream tar ipfwadm-2.3.0.tar.gzdir netbase-3.18/ipfwadm prune 1 upstream tar ipchains-1.3.9.tar.gz dir netbase-3.18/ipchains prune 1 upstream tar ipchains-scripts-1.3.9.tar.gz \ dir netbase-3.18/ipchains-scripts prune 1 upstream tar ipautofw-980511.tar.gz dir netbase-3.18/ipautofw prune 1 upstream tar ipamasqadm-0.4.2.tar.gz dir netbase-3.18/ipautofw prune 1 upstream tar iputils-990107.tar.gz dir netbase-3.18/iputils prune 1 upstream tar netkit-base-0.10.tar.gz \ dir netbase-3.18/netkit-base prune 1 upstream tar portmap-5.tar.gzdir netbase-3.18/portmap prune 1 Without the prune 1 I'd have to go back to hax0ring the debian/rules to cope with every version change in every package, which gets irritating. Really, I'd rather not have to worry about the netbase-3.18 either. Why are the tarball's in ../, and the patches in debian/patches? Won't that make the patches get included twice? If not, doesn't something like: netbase-3.18/ ifupdown/ ifupdown-0.5.5.tar.gz ... and a debian/sources with: upstream tar ifupdown/ifupdown-0.5.5.tar.gz prune 1 seem more convenient and easier to construct? (or netbase-3.18/ifupdown-0.5.5.tar.gz if you don't do the pruning, and just cope with the version in the directory instead) Constructing the Debianization diff would then be done with something like: (as proof of concept) TMP=`tempfile` || exit 1 cat debian/sources $TMP cp -a . ../debianized mkdir ../undebianized cat $TMP | while read updeb type file opts; do mkdir -p ../undebianized/`dirname $file` cp $file ../undebianized/$file done ( OWD=`/bin/pwd` cd ../undebianized dpkg-patch --apply --sources=$OWD/debian/sources ) cat $TMP | while read updeb type file opts; do rm -f ../undebianized/$file rm -f ../debianized/$file done diff -urb ../undebianized ../debianized ../debianization.diff rm -f $TMP rm -rf ../debianized ../undebianized mv'ing the tarballs and patches about rather than making a new tree containing everything but the tarballs would obviously be a nicer implementation. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG encrypted mail preferred. ``We reject: kings, presidents, and voting. We believe in: rough consensus and working code.'' -- Dave Clark pgpvN4uFOnNGc.pgp Description: PGP signature
Binary only Recompilations
Hello world,
Background: every now and then, libraries get updated or bugs in gcc get
fixed, and packages get reuploaded without any source changes, and with
their debian revision bumped by 0.0.1. At the moment, there's no obvious
way of automatically associating these things with their source.
What would, IMO, be nice is having:
Package: foo
Version: 1.2-2.0.1
...
source: foo (1.2-2)
appear in Packages files.
I *believe* this can be obtained by having dpkg-gencontrol generate a
DEBIAN/control file including:
Package: foo
Version: 1.2-2.0.1
...
Source: foo
Source-Version: 1.2-2
.
The real question is when dpkg-gencontrol should do this.
One way, would be to change the various dpkg scripts to treat a changelog
version of 1.2-2.0.1 as though it were 1.2-2 for the source, and 1.2-2.0.1
for any binaries.
I think the easiest way of getting this to happen would be just making a
change to dpkg-genchanges and dpkg-gencontrol like:
diff -ur ../dpkg-1.4.1.11-real/scripts/dpkg-genchanges.pl scripts/dpkg-genchange
s.pl
--- ../dpkg-1.4.1.11-real/scripts/dpkg-genchanges.plWed May 26 23:38:15 1999
+++ scripts/dpkg-genchanges.pl Sat Dec 11 17:00:55 1999
@@ -214,6 +214,11 @@
file but $f2pri{$f} in files list);
}
+if ($f{'Version'} =~ m/^(.*-[0-9]+)\.([0-9]+)\.[0-9]+$/) {
+$f{'Version'}= $1;
+$f{'Version'}.= .$2 if ($2 ne 0);
+}
+
if (!$binaryonly) {
$version= $f{'Version'};
$origversion= $version; $origversion =~ s/-[^-]+$//;
diff -ur ../dpkg-1.4.1.11-real/scripts/dpkg-gencontrol.pl scripts/dpkg-gencontro
l.pl
--- ../dpkg-1.4.1.11-real/scripts/dpkg-gencontrol.plTue Jul 6 04:18:22 1999
+++ scripts/dpkg-gencontrol.pl Sat Dec 11 16:43:51 1999
@@ -154,6 +154,10 @@
setsourcepackage;
} elsif (m/^Version$/) {
$sourceversion= $v;
+if ($sourceversion =~ m/^(.*-[0-9]+)\.([0-9]+)\.[0-9]+$/) {
+$sourceversion= $1;
+$sourceversion.= .$2 if ($2 ne 0);
+}
$f{$_}= $v unless length($forceversion);
} elsif (m/^(Maintainer|Changes|Urgency|Distribution|Date|Closes)$/) {
} elsif (s/^X[CS]*B[CS]*-//i) {
Another way of doing would be to add a --recompile=n option to
debuild, and have that be passed down to dpkg-gencontrol, so that
dpkg-gencontrol behaves as though `-vXYX-A.B.n' option is added to
all the binary packages.
Having dpkg-buildpackage set an environment variable DEB_RECOMPILE=n
and adding something like:
if (defined $ENV{DEB_RECOMPILE}) {
$n = $ENV{DEB_RECOMPILE};
if ($f{'Version'} =~ m/^.*-[0-9]$/) {
$f{'Version'}.= .0.$n;
} elsif ($f{'Version'} =~ m/^.*-[0-9]\.[0-9]$/ {
$f{'Version'}.= .$n;
} else {
# Debian native package?
$f{'Version'}.= .recompile.$n;
}
}
after:
$f{'Version'}= $forceversion if length($forceversion);
in dpkg-gencontrol.
This would change the way recompiles are done, in that instead of changing
the changelog and recompiling, you'd add a different argument to debuild.
Also, there doesn't seem to be any predictable way of discerning recompiles
on Debian-native packages.
So, could something to this effect be applied to dpkg soonish, please?
Cheers,
aj
--
Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/
I don't speak for anyone save myself. GPG encrypted mail preferred.
``The thing is: trying to be too generic is EVIL. It's stupid, it
results in slower code, and it results in more bugs.''
-- Linus Torvalds
pgpbTAiEdZVa8.pgp
Description: PGP signature
Re: Binary only Recompilations
On Sat, Dec 11, 1999 at 02:43:22PM +0100, Wichert Akkerman wrote: Previously Anthony Towns wrote: Background: every now and then, libraries get updated or bugs in gcc get fixed, and packages get reuploaded without any source changes, and with their debian revision bumped by 0.0.1. At the moment, there's no obvious way of automatically associating these things with their source. What I plan to do for woody is add a new Build-Version field. So you get: Package: foo Version: 1.2-2 Build-Version: 199912111340 Hmmm. Some problems with this: Making sure Apt/dselect/whatever considers upgrading packages whose version number hasn't changed. (This would be necessary if a new libfoo has been installed with a new soname, and bar has been recompiled to use the new libfoo --- bar and libfoo have to be upgraded at the same time, otherwise bar'll break) Making sure the mirrors update when only the file contents have changed, not necessarily the filename. On the upside, this may help fix mirrors that corrupt an archive: when they check md5sums the next day, they'll try again. Making sure local proxies and apt-caches and so on update when the file contents change, and not just the filename. At the moment, for example, Packages.gz files ocassionally get stuck in my squid cache for a day longer than they ought to; having .deb's get stuck their too could confuse Apt much more (Okay, this .deb should definitely install properly; let's download it... okay, install. WTF? Dependency conflicts?). Similar problems with the /var/cache/apt/archives/*. Are there any particular benefits it has, over bumping the binary version number? So, could something to this effect be applied to dpkg soonish, please? I have a whole slew of changes I want to make to the various formats (.changes, .dsc and .deb). However I don't want to make them in potato this close to the freeze, so I'm polishing them up a bit and do them all in woody. Note that this patch doesn't actually change the format of any of these, so it doesn't have quite the same fragility wrt freezing. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG encrypted mail preferred. ``The thing is: trying to be too generic is EVIL. It's stupid, it results in slower code, and it results in more bugs.'' -- Linus Torvalds pgplyCsBav9J6.pgp Description: PGP signature
recommends/suggests patch
Okay. I'm sure this is going to be buggy. But it seems to work. :-/
Basically, when constructing the dependency/conflict resolution screen,
instead of just immediately saying `hey, foo recommends bar', we don't
instead don't say anything about it until we've gone through and found
something to satisfy that recommendation.
Ditto for suggestions.
So if you have a package in main that recommends a non-free package,
but you don't put non-free in your sources.list, with this patch
dselect will let you select the main package without stopping and
mentioning the non-free thing at all.
I'd really appreciate it if someone could work through the logic, though.
It seems to make sense, but I'm not really clear on how other bits of
dselect work :(
diff -ur ../dpkg-1.4.1.11-real/dselect/pkgdepcon.cc dselect/pkgdepcon.cc
--- ../dpkg-1.4.1.11-real/dselect/pkgdepcon.cc Mon Nov 2 02:04:48 1998
+++ dselect/pkgdepcon.ccSat Dec 4 15:00:05 1999
@@ -202,6 +202,7 @@
perpackagestate *best, *fixbyupgrade;
deppossi *possi, *provider;
int r, foundany;
+ int rdone;
if (depdebug debug) {
fprintf(debug,packagelist[%p]::resolvedepcon([%p] %s --%s--,
@@ -244,9 +245,12 @@
if (possi) return 0;
// Ensures all in the recursive list; adds info strings; ups priorities
-r= add(depends, depends-type == dep_suggests ? dp_may : dp_must);
-
-if (depends-type == dep_suggests) return r;
+if (depends-type == dep_suggests) {
+ rdone = 0;
+} else {
+ r= add(depends, depends-type == dep_suggests ? dp_may : dp_must);
+ rdone = 1;
+}
if (fixbyupgrade) {
if (depdebug debug)
fprintf(debug,packagelist[%p]::resolvedepcon([%p]):
@@ -259,29 +263,44 @@
possi= possi-next) {
foundany= 0;
if (possi-ed-clientdata) foundany= 1;
-if (dep_update_best_to_change_stop(best, possi-ed)) goto mustdeselect;
+if (depends-type != dep_suggests
+dep_update_best_to_change_stop(best, possi-ed))
+{
+ goto mustdeselect;
+}
for (provider= possi-ed-available.valid ?
possi-ed-available.depended : 0;
provider;
provider= provider-nextrev) {
if (provider-up-type != dep_provides) continue;
if (provider-up-up-clientdata) foundany= 1;
+ if (depends-type == dep_suggests) continue;
if (dep_update_best_to_change_stop(best, provider-up-up)) goto
mustdeselect;
}
-if (!foundany) addunavailable(possi);
+if (!foundany depends-type != dep_suggests) addunavailable(possi);
+if (foundany !rdone) {
+ r= add(depends, depends-type == dep_suggests ? dp_may : dp_must);
+ rdone = 1;
+}
+
+
}
if (!best) {
if (depdebug debug)
fprintf(debug,packagelist[%p]::resolvedepcon([%p]):
mustdeselect nobest\n, this,depends);
-return r;
+return rdone ? r : 0;
}
}
if (depdebug debug)
fprintf(debug,packagelist[%p]::resolvedepcon([%p]): select
best=%s{%d}\n,
this,depends, best-pkg-name, best-spriority);
-if (best-spriority = sp_selecting) return r;
-best-selected= best-suggested= pkginfo::want_install;
-best-spriority= sp_selecting;
-return 2;
+if (depends-type == dep_suggests) {
+ return rdone ? r : 0;
+} else {
+ if (best-spriority = sp_selecting) return r;
+ best-selected= best-suggested= pkginfo::want_install;
+ best-spriority= sp_selecting;
+ return 2;
+}
mustdeselect:
best= depends-up-clientdata;
Cheers,
aj
--
Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/
I don't speak for anyone save myself. GPG encrypted mail preferred.
``The thing is: trying to be too generic is EVIL. It's stupid, it
results in slower code, and it results in more bugs.''
-- Linus Torvalds
pgpwIstKXvR7F.pgp
Description: PGP signature
Bug#35117: --daemonize option for start-stop-daemon [PATCH]
Package: dpkg
Severity: wishlist
Hello world,
I've been having some problems recently trying to get the pcmcia utilities
to do something I wanted, and ended up needing some way of daemonizing
a program that wasn't written to be a daemon (ie, a more thorough version
of ./foo ).
start-stop-daemon seemed the obvious thing to use, but unfortunately it
didn't do anything of the sort. So I added the following:
diff -rub dpkg-1.4.0.33/scripts/start-stop-daemon.c
dpkg-1.4.0.33.new/scripts/start-stop-daemon.c
--- dpkg-1.4.0.33/scripts/start-stop-daemon.c Tue Sep 15 02:45:49 1998
+++ dpkg-1.4.0.33.new/scripts/start-stop-daemon.c Sat Mar 27 12:20:53 1999
@@ -30,6 +30,7 @@
static int exitnodo = 1;
static int start = 0;
static int stop = 0;
+static int daemonize = 0;
static int signal_nr = 15;
static const char *signal_str = NULL;
static int user_id = -1;
@@ -133,6 +134,7 @@
-a|--startas pathname program to start (default is executable)\n\
-t|--test test mode, don't do anything\n\
-o|--oknodo exit status 0 (not 1) if nothing done\n\
+ -d|--daemonizedaemonize program\n\
-q|--quietbe more quiet\n\
-v|--verbose be more verbose\n\
\n\
@@ -204,6 +206,7 @@
{ signal, 1, NULL, 's'},
{ test, 0, NULL, 't'},
{ user, 1, NULL, 'u'},
+ { daemonize, 0, NULL, 'd'},
{ verbose,0, NULL, 'v'},
{ exec, 1, NULL, 'x'},
{ NULL, 0, NULL, 0}
@@ -211,7 +214,7 @@
int c;
for (;;) {
- c = getopt_long(argc, argv, HKSVa:n:op:qs:tu:vx:,
+ c = getopt_long(argc, argv, HKSVa:n:op:qs:tu:dvx:,
longopts, (int *) 0);
if (c == -1)
break;
@@ -252,6 +255,9 @@
case 'u': /* --user username|uid */
userspec = optarg;
break;
+ case 'd': /* --daemonize */
+ daemonize = 1;
+ break;
case 'v': /* --verbose */
quietmode = -1;
break;
@@ -476,6 +482,47 @@
if (quietmode 0)
printf(Starting %s...\n, startas);
*--argv = startas;
+
+ if (daemonize) {
+ int child, child2;
+ switch(child = fork()) {
+ case -1: /* failed */
+ fatal(fork() failed);
+ case 0: /* child */
+ {
+ int i;
+ waitpid( getppid(), NULL, 0 );
+ setsid();
+ chdir(/);
+ for ( i = 0; i 256; i++ ) close(i);
+ switch(child2 = fork()) {
+ case -1: /* failed */
+ kill(child, 9);
+ fatal(fork() failed);
+ case 0: /* child */
+ break;
+ default:
+ {
+ if (pidfile) {
+ FILE *pf = fopen(pidfile, w);
+ fprintf(pf, %d\n, child2);
+ fclose(pf);
+ }
+ wait(NULL);
+ if (pidfile) {
+ remove(pidfile);
+ }
+ exit(0);
+ }
+ }
+
+ break;
+ }
+ default:
+ exit(0);
+ }
+ }
+
execv(startas, argv);
fatal(Unable to start %s: %s, startas, strerror(errno));
}
The executive summary is that this adds a --daemonize option so you can
say:
start-stop-daemon --daemonize --start ./foo -- args
and have the program ./foo which doesn't normally detach itself or
anything, become properly daemonized.
In a pstree it looks like:
init-+-...
|-start-stop-daem---foo
...
Killing foo causes start-stop-daemon to die also. (see the wait() above)
If you add a --pidfile option, start-stop-daemon will create a pidfile
containing the process id of foo, which will get rm'ed when foo dies.
It will also get rm'ed when foo is killed with extreme prejudice (-9'ed)
which isn't what would normally happen. C'est la vie.
Anyway. This seems appropriate for start-stop-daemon (since the whole idea
of it is to start a daemon), it works, it's useful, and it's not too
complicated. If this could be officially incorporated into dpkg it'd be
cool.
Thanks in advance.
Cheers,
aj
--
Anthony Towns [EMAIL PROTECTED] http
