Re: Confused about libnuma1 naming
"J.J. Martzki" writes: > Package 'libnuma1' is built from numactl, and there seems no 'libnuma' > exists. Why does it named as 'libnuma1' rather than 'libnuma'? Shared library packages should be named after the library SONAME, which generally includes a version (as it does here). See: https://www.debian.org/doc/debian-policy/ch-sharedlibs.html#run-time-shared-libraries -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Re: DEP 17: Improve support for directory aliasing in dpkg
Ansgar writes: > On Wed, 2023-05-10 at 13:50 -0700, Russ Allbery wrote: >> Caring about them isn't the same thing as doing everything they want. >> We can both try to make things as smooth for them as possible and still >> make design decisions about Debian that they may disagree with or that >> may make some property they want to maintain difficult or impossible. >> It's the sort of decision we have to make on a case-by-case basis. > Debian going out of its way to tell derivative users to switch back from > merged-/usr to split-/usr is the *opposite* of trying to make things as > smooth for them as possible. Yes, I agree with that part and I think I objected to that at the time. Nonetheless, one bad decision doesn't mean that it is Debian policy that we don't care about derivatives or their users. I think we made a mistake there which is not in alignment with our ideals or our goals. We should try to reverse that mistake, not double down on it. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Re: DEP 17: Improve support for directory aliasing in dpkg
Ansgar writes: > So why do we allow changes that require listing all reverse dependencies > in Breaks then? This is known to be wrong for all non- listed packages, > e.g., all local/vendor/derivative-specific packages. Because it's a balance; we don't want to stop making changes, and never making a backward-compatible change doesn't work, so we do the best we can with the tools we have. However, if someone with an out-of-Debian package tells us that a change breaks it, historically we did add them to Breaks. We just don't have a good way of discovering this. > As far as I understand, we do explicitly *not* care about our > derivatives with regard to merged-/usr as some packages in Debian > recommend users to move *away* from merged-/usr to split-/usr on > derivatives, i.e., to an unsupported fs layout. Caring about them isn't the same thing as doing everything they want. We can both try to make things as smooth for them as possible and still make design decisions about Debian that they may disagree with or that may make some property they want to maintain difficult or impossible. It's the sort of decision we have to make on a case-by-case basis. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Re: Terminology changes for update-alternatives
Justin B Rye writes: > if "primary/secondary" is no good there are variants like "major/minor", > but I think the one I'd have expected to be a front-runner is "main > link" and "subsidiary link", with the latter abbreviating to "Sublinks:" > and "--sub". leader/follower is the other option that came to my mind, and that I think captures the nature of the secondary links (that they follow the configuration of the primary link). That's what I think tow is trying to get at (and I agree that tow reads oddly in English, as a word that I wouldn't expect to see in a technical context and for which the analogy is not immediately obvious). -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Re: Bug#967857: debian-policy: [Files/Permissions and owners] files installed by package manager should not be writable
Guillem Jover writes: > On Tue, 2020-08-04 at 13:56:45 -0700, Russ Allbery wrote: >> I assume this is in support of systems, containers, or jails where UID >> 0 may not have CAP_FOWNER? > If that's the reason, it certainly was not clear from the original > report. :) It seems like the context in which this change would be meaningful. That said, in the situations where I'm dropping capabilities, I would also generally remount file systems like /usr read-only (systemd's ProtectSystem, for example), so I'm having some trouble generating a scenario in which the file permission changes matter. I think a concrete use case would be useful for analysis. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Re: Bug#967857: debian-policy: [Files/Permissions and owners] files installed by package manager should not be writable
Ansgar writes: > 10.9 Permissions and owners currently says > | Files should be owned by root:root, and made writable only by the > | owner and universally readable (and executable, if appropriate), > | that is mode 644 or 755." > However most files shouldn't be modified as modifications will just be > lost (e.g. everything installed by the package manager that isn't > handled as a conffile). It also gives more permissions than the minimum > needed. > I think static files should not be writable instead, so every file under > /usr (and /bin, /sbin, /lib*; or everything dpkg installs that is not a > conffile) should have 444 (or 555). I assume this is in support of systems, containers, or jails where UID 0 may not have CAP_FOWNER? The basic argument makes sense to me, but this is the sort of change where we'll need to figure out a transition strategy coordinated across multiple packages, since this behavior is encoded in a lot of places. Maybe it would make sense for Guillem to weigh in first and indicate whether this would be a problem on the dpkg side and if he sees any concerns. Copying debian-dpkg@lists for that. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Re: Markup inside verbatim blocks in POD (was Re: Reasons to not use quote signs directly?)
Guillem Jover writes: > While fiddling with this I stumbled over a behavior in Pod::Man that > gives exactly what I want, but it might be "undefined behavior" that > I should probably not be relying on? (I'd love to be wrong here :). > ,--- > =head1 NAME > verbatim - test verbatim formatted hack > =head1 EXAMPLE > Some text here. > The verbatim formatted hack: > Z<> > This is a C > with B and I, > and F or > even L references. > `--- > The key here is the first line in the paragraph starting at column 0, > while the rest having leading spaces. Pod::Man then outputs these lines > as is, respecting the spacing, only formatting the text, which makes > groff add the usual line breaks at those leading space points (this can > be changed with the .lsm macro). Also po4a also parser this as desired > and marks this paragraph as 'no-wrap' in the resulting msgid. The first > line and the Z<> are a bit of wart, but oh well. > This of course does not work with other formatters, but then I'm not > sure I care about those as the purpose in this case is to just create > man pages. > Is this something I could rely on? Because that'd be lovely. :D Oh, huh. Interesting. I think you can rely on the preservation of the line breaks and formatting through Pod::Man. I philosophically don't believe in changing things like that when it can be avoided and try to pass through the original file as much as possible while making markup transformations. The whitespace there has no semantic meaning in POD, so it's *possible* that a future version of Pod::Simple, which is doing the underlying parsing, might throw away the whitespace for some reason. But it seems relatively unlikely. So this is undefined behavior, but I suspect in practice it's relatively unlikely to break. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Re: Bug#932753: tag2upload should record git tag signer info in .dsc [and 1 more messages]
Ian Jackson writes:
> Ian Jackson writes ("Re: Bug#932753: tag2upload should record git tag signer
> info in .dsc [and 1 more messages]"):
>> Russ Allbery writes ("Bug#932753: tag2upload should record git tag signer
>> info in .dsc [and 1 more messages]"):
>> > Git-Tag-Info: fingerprint=FINGERPRINT
>> > Git-Tag-Tagger: Firstname Surname
>>
>> This LGTM if other people like the look.
> It occurs to me based on another conversation I had: should this be in
> .dsc or .changes ?
I personally think it should be in the *.dsc file because that makes it
more visible directly in the archive if we need to track down how a
package was uploaded for some reason. (This is the security engineer in
me talking, probably.) We probably *could* track down the same
information via *.changes and other systems, but I don't see a reason to
not put it in the *.dsc file and conceptually think of it as "replacing"
the current uploader signature on the *.dsc file.
That said, I could be missing some subtlety of why the *.changes file
would be better.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: tag2upload should record git tag signer info in .dsc [and 1 more messages]
Ian Jackson writes: > That means the original "uploader" information (ie the identity of the > person signing the git tag) is not any more present in the source > package. To rememdy that I propose the following new field: > Git-Tag-Info: FINGERPRINT Firstname Surname > The parsing rules are: the first word is the fingerprint entirely in > hex. The rest is from the tag's "tagger" line (and may not match). One thing that jumps out at me here is that this field isn't extensible, since anything after the first space-separated word has to be taken to be the tagger line. Unfortunately, doing something extensible within the field requires adding a separator, which in turn requires dealing with escaping, and thus is kind of a mess. Given that, what if you instead used two fields: Git-Tag-Info: fingerprint=FINGERPRINT Git-Tag-Tagger: Firstname Surname and then Git-Tag-Info could be extended later using additional key/value pairs to hold other information, use spaces or commas between attributes, and so forth? For instance, that would let us add the date later if it looked like that might be useful for some reason. That also allows the tagger field to be defined has having the same syntax as Maintainer (or one of the other existing RFC-2822-style fields we have), which I think increases the chances that parsers will get this right. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: dpkg-shlibdeps couldn't find library ... warning vs error
Guillem Jover writes: > On Wed, 2019-06-26 at 14:58:34 -0400, Crim, Christopher wrote: >> I have tried searching for inforamtion related to to naming conventions >> for shared library names but the best I can come up with is that they >> need to be prefixed with "lib" and suffixed with ".so" and possibly the >> so number and revision. A name such as "libcom.debian.foo.bar.so" >> should be valid. If not I would appreciate being pointed to such >> requirements. > I'm not sure now, there's anywhere properly documenting these details. > I don't think the debian-policy manual contains rationale for these. > I've for now locallt documented the split_soname() function, willcheck > whether one of the man pages can also be improved. Policy does not document these details either. It mentions the two normal conventions (libfoo.so. and libfoo-.so), but only in the context of helping packagers understand what to look for when figuring out the SONAME of a library. It sounds like packaging may actually fail if a package ships shared libraries that are too far afield of the normal conventions because dpkg-shlibdeps imposes some restrictions, so maybe it would be worth adding some details there. But I'm not sure how often this comes up. Usually I refer people to the Libtool documentation on maintaining the SONAME, which documents two specific and reasonable conventions in the context of how Libtool manages the version information. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Bug#888549: chrome-gnome-shell: Please don't use /etc/opt, it's not FHS-compliant
Jonathan Nieder writes: > Jeremy Bicha wrote: >> chrome-gnome-shell (in this case) is an addon for the Google Chrome web >> browser. Since Chrome installs to /opt/ (which is encouraged by FHS), >> /etc/opt/ is the only standards-compliant location for >> chrome-gnome-shell to ship the configuration files it needs to provide >> its core functionality. >> There is no reason this functionality cannot be offered in Debian. We >> got complaints when we supported other browsers but not Google Chrome. > Since Google Chrome is not part of Debian, shouldn't this > functionality be offered in contrib, not Debian? chrome-gnome-shell supports all of Chromium, Chrome, and Firefox in the same package, two of which are in Debian. It only installs one file in /etc/opt for Chrome, namely: /etc/opt/chrome/native-messaging-hosts/org.gnome.chrome_gnome_shell.json Splitting that single config file into a separate contrib package feels like overkill here. It shouldn't hurt anything on a system without Chrome and it doesn't create any sort of dependency on Chrome, which is the normal case for contrib. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: debian/upstream/signing-key.asc in policy 4.1.0
Osamu Aoki <os...@debian.org> writes: > After all the discussion, Policy 4.1.0 goes as: > | 4.11. Optional upstream source location: debian/watch¶ > | > | This is an optional, recommended configuration file for the uscan > | utility which defines how to automatically scan ftp or http sites for > | newly available updates of the package. This is also used by some Debian > | QA tools to help with quality control and maintenance of the > | distribution as a whole. > | > | If the upstream maintainer of the software provides OpenPGP signatures > | for new releases, including the information required for uscan to verify > | signatures for new upstream releases is also recommended. To do this, > | use the pgpsigurlmangle option in debian/watch to specify the location > | of the upstream signature, and include the key or keys used to sign > | upstream releases in the Debian source package as > | debian/upstream/signing-key.asc. > | > | For more information about uscan and these options, including how to > | generate the file containing upstream signing keys, see uscan. > Please note few things which I failed to share: > The current uscan supports both > debian/upstream/signing-key.asc > debian/upstream/signing-key.pgp > Now, if debian/upstream/signing-key.asc is used, uscan converts it to > /signing-key.gpg by gpg for use with gpgv to check signature. > (I think the same goes with dpkg-source). It looks extra CPU power > waste but not a big deal. I do this conversion since no documentation > mention keyring can be ascii armored for gpgv. > The updated uscan will support debian/upstream/signing-key.asc only and > internally convert it /signing-key.gpg. I will make uscan to > convert other formats to this policy compliant *.asc. Also make noise > to the maintainer to push them to policy 4.1.0 Note that this Policy language is carefully written to make it perfectly fine for uscan to support all the things it currently supports, since it only talks about what Policy recommends the maintainer does. So don't feel any obligation to change what uscan is doing on Policy's account here. That said, as discussed elsewhere, I'm a huge fan of there being only one way to do something like this, with some easy tools to convert other methods into that one method. It reduces everyone's cognitive load in the future. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Upstream Tarball Signature Files
Henrique de Moraes Holschuh <h...@debian.org> writes: > We do when the binary sig is small enough to be stored along with the > inode, instead of requiring an entire filesystem block (4KiB), and the > armored signature is not small enough for that :-( Of course, this > really depends a lot on the filesystem, etc. I'm not sure what signatures you're looking at. Maybe ones with lots of separate signers? A typical *.asc file with one signer is about 500 bytes. > May I humbly suggest that, *if* a change is going to be made, we switch > to ".sig" (binary) and ".sig.asc" (armored), or .sig.gpg / sig.gpg.asc? > As in "let's not overload .asc to mean armored signature, when it only > means ASCII text"... Note that I'm arguing for no change, just documenting the existing support for *.asc upstream signatures. This will imply that anyone who wants to include an upstream signature that's provided in *.sig format will need to convert it to *.asc, but that's not a *change*. That's the current state of the archive. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Upstream Tarball Signature Files
Henrique de Moraes Holschuh <h...@debian.org> writes: > On Sun, 13 Aug 2017, Russ Allbery wrote: >> it can't just move the file -- it has to ASCII-armor it. But still, I >> think that's the right thing for the tools to do, not add another file. >> (The ASCII format is completely equivalent to the binary format; the >> conversion shouldn't lose or change any data.) > The armor just wastes space, and will do so for every signature in the > archive. I very much doubt we will ever notice such a tiny amount of overhead. > Why are we not using binary signatures in the first place, if we're > going to mandate conversions? We could go that route too, but I don't think the benefits are worth changing the existing code that supports *.asc files. But I certainly wouldn't object if the folks doing the work wanted to change. I just want to support only one or the other. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Upstream Tarball Signature Files
Paul Hardy <unifoun...@gmail.com> writes: > If it is permissible to rename a ".sig" file as ".asc", I think that is > the best solution because it copies the original signature file > unmodified. I tried it previously and it worked, but it seemed to me > like masquerading (because a binary file obviously is not an > ASCII-armored file) and not right. Oh, sorry, I'd missed that it was the binary format. Yeah, in that case it can't just move the file -- it has to ASCII-armor it. But still, I think that's the right thing for the tools to do, not add another file. (The ASCII format is completely equivalent to the binary format; the conversion shouldn't lose or change any data.) > The first part of my request was going to suggest adding ".asc" files in > examples. The Policy Manual gives sample lists of files that appear in > the Files and Checksums sections (5.6.21 and 5.6.24) of ".dsc" and > ".changes" files using "example_1.2.orig.tar.gz" and > "example_1.0.orig.tar.gz". Do you think it is appropriate to mention > that those sections may contain signature files of the form > "example_1.[02].orig.tar.gz.asc", showing that file name with the other > files? There seems to be no mention of such a file in the Policy > Manual. Sections 5.6.21 and 5.6.24 are where I thought of requesting > changes. I think it would be appropriate to document how to include upstream signature files in a Debian source package, absolutely. (That's quite a bit more than just adding them to examples.) -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Upstream Tarball Signature Files
Paul Hardy <unifoun...@gmail.com> writes: > Osamu: I did not mean just accept one format--I meant accept both ".asc" > and ".sig" files for ".changes", ".dsc", and uscan files. I suppose all > three manuals you mentioned could be modified to document this. > I had not brought this up until the latest lintian check on a test build > returned an error, but then Sean noted that the lintian error report is a > bug. > If there are no strong objections to this change, I will file a wishlist > bug as an "issue" for debian-policy about this. I will be away next > weekend so I will try to put together something before then. Hi Paul, This isn't a debian-policy matter. Support for ".sig" files in *.changes and *.dsc would be a bug against dpkg and possibly also in DAK for the archive to handle them, and in watch files would be a bug against devscripts. However, I don't think it's a good idea to support multiple file names for the same thing. Instead, package building tools should probably just rename *.sig files to *.asc if upstream uses *.sig, the same way thhat they rename upstream source tarballs to follow our naming convention (which upstream almost never uses). The bug may be best filed against devscripts for uscan --download to rename the signature on download. It's almost never a good idea to introduce synonyms into any sort of standard. It adds a lot of complexity that has to be maintained forever, to very little benefit. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: RFC: Unified package metadata format
Matthew Garrett <matthewgarr...@google.com> writes: > * Users auditing their systems can have full kernel-enforced > cryptographic assurance that the files they have on disk match the > files that Debian shipped. Doing that otherwise would involve you > having to take the machine offline. I would very much like to have this as well. This sort of thing makes it much easier to build out a maintainable FIM system that doesn't require people constantly whitelist new binaries manually. > * Even Debian users may (for security or other policy reasons) want to > configure systems so that they only run binaries that are provided > through some trusted distribution mechanism. Yes. Consider, for example, a Kerberos KDC or other security-critical system, where you may want to have some automated system for explicitly blessing a subset of the archive and specific versions of packages and not allow anything else. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Reasons to not use quote signs directly?
Guillem Jover <guil...@debian.org> writes: > Ah right, indeed it does. And it's explained in that same man page I > referred. O:) The escape sequence would be something like \[u0021] or > \[u0041_0300]. Oh! So, if I can just convert all Unicode characters to their numeric codes, this becomes very easy to do. No tables and other machinery required. I'm a little worried about the \[u0041_0300] form, though. Does that mean that \[u0041]\[u0300] does not work, and Pod::Man has to know whether characters are combining or not? I suppose that's possible with the Perl Unicode support, if necessary. Are the numbers there the hex digits of a Unicode code point? The groff_char man page is maddeningly light on details about this escape form, mentioning it only in a REFERENCE section. >> For Pod::Man usage, the output format I'd want would be a hash mapping >> Unicode code points to the correct groff escape. Or, in an absolutely >> ideal world, to have an Encode encoding for groff escapes, similar to how >> the Encode::MIME::Header encoding works to generate RFC 2047 strings. > I happened to stumble over an old patch by Brendan O'Dea that might be > helpful, including a reference here to not lose track of that: > > <https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=442066;filename=groff-utf8;msg=22> Oh, aha, that's basically the table I was looking for, although that's very limited compared to all Unicode characters, so it seems easier to just do a straight conversion to the \[u] form. >> B<> and I<> could just be surrounding normal words that should use >> normal hyphens. L is a link to a section in the same >> document entitled some-command, so the assumption there is also that it >> could be a regular English word. > Oh, at least perlpod(1) says that L links to a Perl manual page, > so I'd expect it to be equivalent to the L<crontab(5)> style when > processing minus chars, and L does the inter-section linking? Oh, sorry, yes, I was thinking of L. So the idea is that L should always use \- for all embedded hyphens? >> As you say, though, I'm not entirely sure the distinction is worth all >> the trouble we've put into it over the years. nroff at least seems to >> have just given up and maps them all to "-" in the output anyway. That >> used to be a Debian-specific change, but it looks like upstream has >> switched to treating - as \-, I think? For HTML output, upstream maps >> \- to and Debian still overrides that to - instead. (If >> upstream thinks \- is a minus sign and not ASCII 45, I'm really >> confused what's going on with this, though.) > We should probably ask Colin about this. :) Yes, please -- Colin, do you have any idea what the current best practice is here? I'm trying to figure out what to have Pod::Man do. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: schroot default chroot path
Johannes Schauer <jo...@debian.org> writes: > it would. If anybody knows a good argument for a default location for > schroot containers then I can add such a default. I am not aware of such > a standard path for system-wide schroot directories or tarballs. pbuilder just uses /var/cache/pbuilder by default. I think a good argument can be made for picking some default like this and going with it unless overridden. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Reasons to not use quote signs directly?
Guillem Jover <guil...@debian.org> writes: > Yeah the Xs were really annoying. On the AIX and Mac OS X systems I > tested on, AFAIR they produced garbage when rendering, but I can recheck > to be sure. I think I might have also tested on a system that used man > (w/o Unicode support) instead of man-db, but I'd need to reverify. And I > think the various BSDs use groff, but it might need checking too. Oh, okay, so proprietary UNIX is still a problem for just using Unicode everywhere, but Linux and BSD may be okay. > Just to clarify (because I think I was a bit vague previously), on > systems that didn't support Unicode using the groff macros produced no > output (so no garbage), which is better IMO than the Xs or garbage. :) Still not great, though. :( Sigh. So there's no silver bullet still. But I think the scale has tipped at this point to the degree where it's worth having good output with groff, even if that means one gets bad output without groff. > For the current conversion in dpkg, I've taken most of the common > symbols from groff_char(7) and created a very simple sed script, I'm not > sure if you were thinking about something along those lines (although in > proper perl)? > > <https://git.hadrons.org/cgit/debian/dpkg/dpkg.git/tree/man/utf8toman.sed?h=next/master=c07b9b79447e200645ea423f959194fcbf8d4d32> Yeah, that would work, although aren't there quite a few more sequences than that? Does groff have a way of representing an arbitrary Unicode code point? For Pod::Man usage, the output format I'd want would be a hash mapping Unicode code points to the correct groff escape. Or, in an absolutely ideal world, to have an Encode encoding for groff escapes, similar to how the Encode::MIME::Header encoding works to generate RFC 2047 strings. If groff doesn't have a way of encoding arbitrary Unicode code points, what do you think Pod::Man should do with characters that don't have a mapping (Chinese characters, for instance)? > If you could specify exactly which symbols you'd like to see supported I > might take a stab at this, when I have some spare time. Say everything > in groff_char(7) or similar. :) As much as possible is of course ideal, but I'm happy to take partial work! :) > I guess field names might be easy to spot as they have the standard form > Field-Name(-Other)* which is probably not common for English words? > This might trip over on other languages such as German for example which > tends to capitalize many words. A bit tricky for, say, book titles, too. :( > The other major issue are commands, which I'm not sure are so easy to > detect. Maybe they could get to use the \- minus if they are inside some > other markup. I see that C escapes them, as does > L<some-command(1)>, but L does not (any reason?), which > could be handy to use I guess. Filenames are also safe with > F. The only problem is using the proper markup that > also preserves the same output as the current man pages. B<> and I<> could just be surrounding normal words that should use normal hyphens. L is a link to a section in the same document entitled some-command, so the assumption there is also that it could be a regular English word. As you say, though, I'm not entirely sure the distinction is worth all the trouble we've put into it over the years. nroff at least seems to have just given up and maps them all to "-" in the output anyway. That used to be a Debian-specific change, but it looks like upstream has switched to treating - as \-, I think? For HTML output, upstream maps \- to and Debian still overrides that to - instead. (If upstream thinks \- is a minus sign and not ASCII 45, I'm really confused what's going on with this, though.) > I've always found the AUTHORS, COPYRIGHT or LICENSE sections to be > distracting, and in dpkg we got rid of all of them, because in addition > they were getting usually out-of-sync with the actual copyright > statements, and required adding names and updating years in two places. Yeah, that part is irritating. The alternative, which I use in my packages these days, is to have these reflect the authors, copyright, and license of the *manual page*, but that's also weird. =for license, resulting in a comment in the generated man page, seems like a better general solution (and then it probably makes sense for this to always reflect the license of the documentation file itself, not the larger package). -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Reasons to not use quote signs directly?
Guillem Jover <guil...@debian.org> writes: > In deb-changelog(5) there is currently this: > ,--- > .nf > \fIpackage\fP (\fIversion\fP) \fIdistributions\fP; \fImetadata\fP > [optional blank line(s), stripped] > * \fIchange-details\fP > \fImore-change-details\fP > [blank line(s), included in output of \fBdpkg\-parsechangelog\fP(1)] > * \fIeven-more-change-details\fP > [optional blank line(s), stripped] > \-\- \fImaintainer-name\fP <\fIemail-address\fP> \fIdate\fP > .fi > `--- > which I had to convert by surrounding with «=begin man» and «=end man». > If you know of a better way, I'm interested! Oh, markup inside verbatim. Yeah, this is a topic of some discussion in the Perl community. There was occasionally some talk of a =begin verbatim block that would act like a verbatim block but markup sequences would be allowed, but nothing really came of it. Perl 6 POD solved this problem with their =begin code block that takes as an argument a list of sequences to allow. But no one seems to be using Perl 6 still? I haven't really looked at their POD stuff at all. It started on a weirdly parallel track without much interaction with those of us who were maintaining all this stuff for Perl 5. I generally just give up on this and use the normal text markup conventions of angle brackets and whatnot, although I see why you don't want to do that here. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Reasons to not use quote signs directly?
ich don't seem to be good
fits for man page generation.
So, for things like tables, you're probably going to need to continue to
escape to raw *roff with =begin man.
> - Many minus signs are output as hyphens (for example for field names).
This is a nasty problem, since POD has no explicit markup for this and one
has to use heuristics.
Improvements in the heuristics are certainly welcome. This is the current
code:
# By the time we reach this point, all hyphens will be escaped by adding a
# backslash. We want to undo that escaping if they're part of regular
# words and there's only a single dash, since that's a real hyphen that
# *roff gets to consider a possible break point. Make sure that a dash
# after the first character of a word stays non-breaking, however.
#
# Note that this is not user-controllable; we pretty much have to do this
# transformation or *roff will mangle the output in unacceptable ways.
s{
( (?:\G|^|\s) [\(\"]* [a-zA-Z] ) ( \\- )?
( (?: [a-zA-Z\']+ \\-)+ )
( [a-zA-Z\']+ ) (?= [\)\".?!,;:]* (?:\s|\Z|\\\ ) )
\b
} {
my ($prefix, $hyphen, $main, $suffix) = ($1, $2, $3, $4);
$hyphen ||= '';
$main =~ s/\\-/-/g;
$prefix . $hyphen . $main . $suffix;
}egx;
As you can see, it's a bunch of messy and rather fragile regexes. But
there is a test system, so I'm happy to tweak these and add more tests if
you have specific use cases that you encounter.
The trick is going to be distinguishing between hyphenated English words
(which should use the unmarked - character in *roff source) and field
names where you want an explicit \- minus sign. Although I could see an
argument for just supporting disabling this heuristic if one doesn't care
about good line wrapping.
> - Default for pod2man is no justified text.
This is a (very strong) personal preference, since I think most man pages
are read on terminals with fixed-width fonts, and I think justified text
looks awful in a fixed-width font. But I'd be happy to add a non-default
flag that suppresses the turning off of justification.
> - The license blurb is only present as a comment on the source.
Yeah, I've given up on this and just put the license in a section of the
output of the man page, but I think it would be lovely to put it in a
comment. This probably requires some sort of =for license block (and I'm
not sure what Pod::Text should do with it -- just suppress it entirely, I
guess). I'm happy to add support for this (obviously, patches even more
welcome).
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Reasons to not use quote signs directly?
Guillem Jover <guil...@debian.org> writes: > Can use B(N) instead of L<man(N)>. Which might be needed anyway > to reduce the amount of fuzzy strings. The same to using I<> instead > of the more semantic F<>. I'd definitely prefer to make L<man(N)> do the right thing instead, since it would be nice to allow, say, a smart HTML converter to do proper links between man pages. > Seems to be really needed, mostly to markup verbatim blocks, otherwise > the formatting would need to be dropped. :/ What sort of verbatim formatting problems have you run into? -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Intent to commit craziness - source package unpacking
Ian Jackson <ijack...@chiark.greenend.org.uk> writes: > Guido Günther writes: >> Looking at git.debian.org I found plenty of users. I did an archive >> import of sid during Debconf and was only ran into 20 pristine-tar >> failures (bugs yet to be filed). > Interesting. My impression is that the perils and flaws of pristine-tar are highly exaggerated, at least if you care about it mostly working rather than being 100% reliable data storage that will never fail. (I believe for most Debian packages pristine-tar is essentially a convenience; you can always grab the tarball from other sources, but it's nice to not have to when it works well.) > I'm not sure of the logic behind that. I don't think dgit helps much > with the kind of tasks that pristine-tar helps with. The main benefit of pristine-tar is that you can clone the development repository on any random host and do package development, build local packages for testing, and do a package upload without having to locate any additional pieces. I haven't been following dgit development closely, but it did sound like you were addressing the same use case. >> gbp buildpackage has integration with pbuilder/cowbuilder (via >> git-builder) and I know people are using it since its better integrated >> into gbp since you don't need additional and it's documented in the >> manual. The sbuild dependency is there to have people not pull in >> cowbuilder/pbuilder so they can use --git-builder=sbuild. > Ah. Speaking as maintainer of the integration script between gbp buildpackage and pbuilder/cowbuilder, I would be happy to switch to sbuild if sbuild were clearly better, and it may be (I haven't personally looked). The last time I looked at sbuild was more than five years ago, and the setup looked horribly complicated compared to pbuilder and cowbuilder and was way more than I had time to deal with at the time. If sbuild is now at the point where you can just apt-get install sbuild, run a single setup command, and be ready to build packages (which is where cowbuilder is right now), I personally would be happy to use something that's a bit closer to what the buildds are doing. However, cowbuilder does just work, in my experience, and it's nice to not have to change. Note that the same integration also works with qemubuilder, for whatever that's worth. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#650077: dpkg: The Installed-Size estimate can be wrong by a factor of 8 or a difference of 100MB
Guillem Jover guil...@debian.org writes: On Wed, 2015-01-07 at 12:22:47 +0100, Johannes Schauer wrote: It is also worth asking what functionality the Installed-Size field is supposed to have when looking for a solution. It's primary purpose is probably to give apt a clue of whether or not there is enough free space to install a certain package. Personally I've always taken it as a small hint of the approx. size of the package, but the most interesting case which is always accurate is to spot size differences between the previous and next package version, for example from aptitude TUI. I consider the primary purpose to be to give a *human* a hint as to how large the package is. At least, that's how I've always used it. For that purpose, it really only needs to be accurate within a few hundred KB, and overstating the package size is probably better than understating it for packages with, say, large sparse files. It helps avoid problems like oh, this game looks interesting -- ack, where did all of my disk space go? If it can also provide information to apt about whether a package will fit on the disk, that's great, but I don't think we should put too much weight on that. Operating package managers very close to a full disk is a problematic action anyway, since there are a bunch of intermediate steps involved in installing a package, other files that get created dynamically, and so forth, and it's very hard to predict how much space will be required to successfully complete the installation. Certainly, Installed-Size doesn't do that. So, from a Policy perspective, I'd be happy with language that says this is an approximation of the size of the package on disk and leave it at that. It's tempting to generate it by just summing the sizes of the files in the Debian package after rounding them up to some common file system block size and not try to get too fancy. Of course, if people want to work on making the number more accurate, I won't stand in their way, but I don't think the reasonable uses for the field require that. Take into account that usually other disk usage is not accounted, like files generated at run-time, caches, logs and similar. There's the Extra-Size substvar just for that but I don't think any package is actually making use of it (at least according to codesearch.d.o), so… Yeah. Because knowing that to put in that field is a rather hard problem. Also apt (and cupt) only use that information to print the size deltas, apt only actually checks for available disk size for downloaded data, which is the only thing that actually makes sense doing. Yup. Given that (at least apt and cupt) are not actually comparing the available disk space with the accumulated packages Installed-Size, there will be no warning anyway, and to me just making dpkg fail gracefully on ENOSPC is the best option, anything else will just be wrong somewhere. +1. I think preventing package installation through Installed-Size would be a bad idea and quite annoying because it could disallow possible installations which would be even more confusing. +1. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#748936: apt doesnt understand architecture wildcards
Bernhard R. Link brl...@debian.org writes: Urgh. Really? This is far too complicated for most programs to implement properly. I'd suggest to rather fix dpkg (and also fix policy. Policy should obviously track dpkg, which is currently canonical for how wildcards work since it contains the primary implementation. If you think this should change, you should first convince the dpkg maintainers, and then raise this with Policy after dpkg has changed. The footnote describes absolutely nothing currently, It does describe something to me, but I'm probably too close to it. We're certainly happy to consider alternative wording. and having such important fields a meaning that you cannot calculate without knowing what architectures the system finally using the package uses makes it unhandable). I'm not completely sure what you mean by this, but if you mean that you can't know what architecture strings are valid without knowing which architectures are supported by dpkg, I think that's a feature in Policy, not a bug. I wouldn't want to update Policy every time a new architecture was added. That happens quite frequently. That said, Policy could probably stand to provide more guidance on how to interpret the results of dpkg-architecture -L and how they map to wildcard strings. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87mwe5fue0@windlord.stanford.edu
Re: glibc independent packages
Kevin Bortis wer...@gmail.com writes: Yesterday, I tried to setup a multiarch system with amd64 and the recently added architecture musl-linux-amd64 that uses the musl-libc instead of the GNU glibc. After setting up a working toolchain, it worked well building some packages for the musl-linux-amd64 port. One big problem was, that most, if not all packages depend on glibc, glibc-dev or libc-dev. I asked myself how this could be solved by not introducing a mess in the package control files. What if you had musl-libc-dev Provide libc-dev (or even libc6-dev), and then made sure it was already installed on your build daemon? Nearly all of the libc6 dependencies should come from shlibs, so as you rebuild packages in that environment, your new packages will acquire dependencies on the musl-libc instead. This is similar to your solution 3 but shouldn't require any changes to the glibc packages. solution 3: Create metapackage libc-dev and let glibc-dev, musl-libc-dev and possible others provide libc-dev. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87vc7epl43@windlord.stanford.edu
Re: Bug#582109: debian-policy: document triggers where appropriate
Raphael Hertzog hert...@debian.org writes: On Fri, 15 Mar 2013, Charles Plessy wrote: + Dpkg defines the folowing states for the packages. + taglist +tagNot-Installed/tag I would use the precise states listed in dpkg(1), i.e. entirely in lowercase. (same for all the states) I thought Guillem requested we use the capitalized versions. I think the capitalized versions stand out more and make it clearer that the expected meaning isn't necessarily the plain English meaning of the phrase. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87k3oacmbj@windlord.stanford.edu
Re: dpkg perl critic code cleanup
Guillem Jover guil...@debian.org writes: I took notice again, after having done so in the past and long forgotten it, of the perlcritic analyzer from Russ' recent write ups, and have been going through the dpkg perl code, finding many things to fix or improve, but not everything it reports always seems sensible. I've been queueing those in my local tree, and will be pushing them once I reopen master for jessie, not too long from now. In any case, thanks Russ, wonderful rediscovery! :) Oh, glad it was helpful! In case it's of interest, attached are my current perlcriticrc and perltidyrc files. (perltidy is... awkward. There are places where how it formats the code is clearly suboptimal, at least to me, and despite initial appearances it doesn't have enough dials. But I'm sticking with it so far.) -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ # -*- conf -*- # # Default configuration for perlcritic. Be sure to copy this into the source # for packages that run perlcritic tests automatically during the build for # reproducible test results. # # This file has been updated to match perlcritic 1.118. # # The canonical version of this file is maintained in the rra-c-util package, # which can be found at http://www.eyrie.org/~eagle/software/rra-c-util/. # # Written by Russ Allbery r...@stanford.edu # Copyright 2011, 2012 # The Board of Trustees of the Leland Stanford Junior University # # Permission is hereby granted, free of charge, to any person obtaining a # copy of this software and associated documentation files (the Software), # to deal in the Software without restriction, including without limitation # the rights to use, copy, modify, merge, publish, distribute, sublicense, # and/or sell copies of the Software, and to permit persons to whom the # Software is furnished to do so, subject to the following conditions: # # The above copyright notice and this permission notice shall be included in # all copies or substantial portions of the Software. # # THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR # IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, # FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL # THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER # LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING # FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER # DEALINGS IN THE SOFTWARE. severity = 1 verbose = %f:%l:%c: [%p] %m (%e, Severity: %s)\n # Pod::Man and Pod::Text fixed this bug years ago. I know, I maintain them. [-Documentation::RequirePodLinksIncludeText] # The POD sections Perl::Critic wants are incompatible with the POD template # from perlpodstyle, which is what I use for my POD documentation. [-Documentation::RequirePodSections] # The default of 9 is too small and forces weird code contortions. [InputOutput::RequireBriefOpen] lines = 15 # This is correct 80% of the time, but it isn't correct for a lot of scripts # inside packages, where maintaining $VERSION isn't worth the effort. # Unfortunately, there's no way to override it, so it gets turned off # globally. [-Modules::RequireVersionVar] # The default is a bit too aggressive. I was unable to write an Apache access # log regex with each major expression broken into a separate variable and fit # the default limit of 40 characters. (It's not clear how the variable names # are counted, but they don't seem to be by number of characters in the # variable reference.) [RegularExpressions::ProhibitComplexRegexes] max_characters = 80 # Nice idea, but it *utterly* confuses cperl-mode when used with braces, so # it's more trouble than it's worth. [-RegularExpressions::ProhibitEscapedMetacharacters] # I generally don't want to require Readonly as a prerequisite for all my Perl # modules. [-ValuesAndExpressions::ProhibitConstantPragma] # 100 is used for calculating percentages. Making it a constant is just # confusing. # # Literal 0777 means to use the umask for permissions when creating files. # Using a constant for this just makes it more obscure. 0777 is 511 in # decimal. [ValuesAndExpressions::ProhibitMagicNumbers] allowed_types = Octal allowed_values = 0 1 2 100 511 # Increase this to six digits so that I'm not told to add underscores to # port numbers (which is just silly). [ValuesAndExpressions::RequireNumberSeparators] min_value = 10 # Text::Wrap has a broken interface that requires use of package variables. [Variables::ProhibitPackageVars] add_packages = Text::Wrap # use English was one of the worst ideas in the history of Perl. It makes the # code slightly more readable for amateurs at the cost of confusing # experienced Perl programmers and sending people in futile quests for where # these magical global variables are defined. [-Variables::ProhibitPunctuationVars] # -*- conf -*- # # Default options for perltidy for proper Perl code reformatting
Re: dpkg perl critic code cleanup
Russ Allbery r...@debian.org writes: Oh, glad it was helpful! In case it's of interest, attached are my current perlcriticrc and perltidyrc files. (perltidy is... awkward. There are places where how it formats the code is clearly suboptimal, at least to me, and despite initial appearances it doesn't have enough dials. But I'm sticking with it so far.) Oh, and feel free to use the perlcriticrc file under whatever license you want; I don't actually care (nor will Stanford). It's just long enough that my license heuristics want it to have some license, and I tend to slap the Expat license on things in that case. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/874nj1tym4@windlord.stanford.edu
Re: M-A: Same package A providing and conflicting with package B
Stefano Zacchiroli z...@debian.org writes: Russ, thanks for clarifying the status of policy wording wrt multiarch. I was well aware of Policy 7.4, but it wasn't clear to me whether updating it wrt multiarch has (supposedly) already happened or not. Do you want a bug report against policy about this? I did check the bug listing, but I haven't found anything relevant to this specific issue (I might have missed more generic multiarch bugs, though). There has as yet been no work on Policy updates for multiarch. I'm hoping to be able to start working on that soon. I don't think there's a general bug for all Policy multiarch support (I should probably add one), just some more specific ones around the edges: #621050 Document dependencies needed to use multiarch paths #636383 10.2 and others: private libraries may also be multi-arch-ified #650974 Make Policy references to /usr/lib multiarch-aware #684672 document multiarch tuple definitions But still, I could use double checking about the correctness of current APT's behavior. From how Russ put it above, it shouldn't matter whether the conflict is via a virtual package name or via a real package name: self-conflicts across architecture boundaries should be ignored for M-A: same packages. Yes, that's what I think would be a reasonable extension of the current language around how Conflicts works. If a package is explicitly tagged Multi-Arch: same, then to me that clearly implies that the maintainer thinks that multiple architectures of the package should be installable at the same time. Otherwise, the package would be tagged Multi-Arch: foreign or not be labelled for multiarch at all. If Conflicts prevents that, then the combination of a Conflicts on the package name and Multi-Arch: same would be a straight bug, since they would contradict each other. If we treat Conflicts on the package name the same as for a virtual package, then that combination becomes meaningful: it means that the package itself is co-installable, but can't be co-installed with any other package that Provides the same name. That seems more useful. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87pq5lobfi@windlord.stanford.edu
Re: M-A: Same package A providing and conflicting with package B
Jonathan Nieder jrnie...@gmail.com writes: Johannes Schauer wrote: As I learned, the above means, that there must be only one package providing linux-kernel-headers. The problem is, that with linux-libc-dev conflicting with linux-kernel-headers of all arches, linux-libc-dev is not co-installable with itself anymore even though it is M-A: Same. That does sound like a bug. The intuitive behavior when foo both Provides and Conflicts with bar would be for the Conflicts to only apply to other packages. Indeed. This particular combination of package metadata has a specific meaning defined in Policy 7.4: A special exception is made for packages which declare a conflict with their own package name, or with a virtual package which they provide (see below): this does not prevent their installation, and allows a package to conflict with others providing a replacement for it. You use this feature when you want the package in question to be the only package providing some feature. So you need to specifically recognize the case of Conflicts naming the package itself or a virtual package that this package provides, and in that case the Conflicts should not be applied to that package for installability determination. None of this language has, as yet, been updated for multiarch, but I think it makes logical sense for a M-A: same package to be coinstallable even if it Conflicts with its own package name or a virtual package it Provides, by extension from the intention of this construct without multiarch. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/877grx8pys@windlord.stanford.edu
Re: Moving debian/* to non-standard location
Kip Warner k...@thevertigo.com writes: On Sat, 2012-09-08 at 22:57 -0700, Russ Allbery wrote: Generally you can just do it as a separate branch within the same repository. See, for example: http://www.eyrie.org/~eagle/notes/debian/git.html#combine (This still needs some updates for the --upstream-vcs-tag flag.) Hey Russ. Thanks for the tip. I'll definitely keep that in mind if I ever decide to migrate to Git. For now though, I'm using Bzr. They're similar for this purpose. I think bzr-builddeb even works essentially the same way, although you may not get pristine-tar and the --upstream-vcs-tag features. But you can still get the same benefit of using the same repository and just a different branch. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87txv7vi8b@windlord.stanford.edu
Re: Bug#571776: document symbols
Julien Cristau jcris...@debian.org writes: On Sun, Aug 12, 2012 at 14:25:12 -0700, Russ Allbery wrote: Okay, once more for the win. Here is the current version of the patch, incorporating substantial improvements from Jonathan Nieder and hopefully incorporating all the feedback in subsequent discussion. I'm looking for seconds so that we can finally merge this monster. Presented as a diff since that was the request last time, but the branch has also been pushed to the Policy Git repository, so if you want to review it various other ways, you can start at: http://anonscm.debian.org/gitweb/?p=dbnpolicy/policy.git;a=shortlog;h=refs/heads/bug571776-rra or with a Policy Git checkout and look at the bug571776-rra branch. Seconded. Thank you to everyone for the reviews! I've now merged this patch for the next release. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87r4qzkd0v@windlord.stanford.edu
Re: document symbols
Jonathan Nieder jrnie...@gmail.com writes: Russ Allbery wrote: I'm therefore including here the complete SGML source of that section not in diff format, followed by the diff of everything *outside* of that section. I think this will be easier to review. Thanks! I would have preferred a diff since it shows the text that is being replaced, too, but let's go with this for a first pass. Yeah, it's frustrating to review something this large, and none of the normal tools do a particularly good job at it. A side-by-side contextual diff tool is probably best. Anyway, thank you for the detailed review, and apologies for taking so long to get back to this. The amount of work required is intimidating, and I kept putting it off. For the most part, I adopted your changes; assume that if I don't comment here specifically, I've incorporated that change. (I started by applying your interdiff and then only changing the bits that I thought I could further clarify.) [...] p If a package contains a binary or library which links to a shared library, we must ensure that, when the package is installed on the system, all of the libraries needed are also installed. This text is carried over from before and contains a requirement I never noticed before. Suppose my package contains two binaries: maintool and side-tool. The latter is not very important and links to libbiglibrary. I might be tempted to make the dependency by my package on libbiglibrary a Recommends instead of a Depends. The above says I must not. Intentional? It seems like good policy, anyway. Could you open a separate bug about this? I think we should allow Recommends, but as you say it's already in the current wording and this change is already too complicated. We should discuss it separately. This means packages must not hard-code library dependencies. It also seems like good policy, but I suspect it would render packages such as chromium that use dlopen() and hard-code the corresponding library name in dependencies RC-buggy. Your fix (making dependencies for dlopen a should instead of a must) looked like a good way of fixing this problem to me. Thanks! To allow these dependencies to be constructed, shared libraries must provide either a filesymbols/file file or a fileshlibs/file file, which provide information on the package dependencies required to ensure the presence of this library. Subject/verb agreement: s/provide/provides/ While that's technically correct, it looks completely wrong to me. I reworded to make this two sentences instead, so that it's both formally correct and feels right. If I remove a symbol that was documented to be private or change the behavior of a function when given invalid arguments, is that a backward-compatible change? If I add change the implementation in such a way that the library becomes so large that some large programs cannot use it any more, is that a backward-incompatible change? You addressed this by introducing the concept of a reasonable program but not defining it. That sounded like the right approach to me, but I felt the need to say more, so I added a footnote explaining the intent: There are two types of ABI changes: ones that are backward-compatible and ones that are not. An ABI change is backward-compatible if any reasonable program or library that was linked with the previous version of the shared library will still work correctly with the new version of the shared library.footnote An example of an unreasonable program is one that uses library interfaces that are documented as internal and unsupported. If the only programs or libraries affected by a change are unreasonable ones, other techniques, such as declaring ttBreaks/tt relationships with affected packages or treating their usage of the library as bugs in those packages, may be appropriate instead of changing the SONAME. However, the default approach is to change the SONAME for any change to the ABI that could break a program. /footnote Unrelated change. The patch would have been easier to review if this were a separate commit, which could have gone straight to master since it doesn't change the output. Yes, sorry. I really hate the whole diff system for making changes to text documents, since I always reformat text documents as I work on them. I'll try to avoid this when people find it confusing, but as long as I'm writing the patches, you may have to just live with some of this, since putting more barriers in the way of writing text for Policy will mean that I'll do even less work than I do now. :/ That said, I agree that it's kind of annoying for review, and I'll try to get better about not doing it. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-dpkg-requ
Re: Bug#571776: document symbols
Jonathan Nieder jrnie...@gmail.com writes: Jonathan Nieder wrote: I'll reply with an interdiff relative to the last version of the patch. Here it is. And here is the interdiff between your patch and what I currently have, to make it easier for you and anyone who was familiar with your version of the patch to review what I further changed. I'm going to reply to this thread in a moment with the whole current patch, for hopefully the last time, and then we can try to get seconds and (at least) merge this monster. commit 97cb027db4afab774ea4f4ff9e7bef7a6dcbbda0 Author: Russ Allbery r...@debian.org Date: Sun Aug 12 14:14:23 2012 -0700 Further wording changes on top of Jonathan Neider's work Add a footnote explaining what a reasonable program is. Clarify the shlibs versioning text. Other minor textual changes for clarity. diff --git a/policy.sgml b/policy.sgml index 0965b76..fa1c39a 100644 --- a/policy.sgml +++ b/policy.sgml @@ -5978,11 +5978,11 @@ Built-Using: grub2 (= 1.99-9), loadlin (= 1.6e-1) whether new library interfaces are available and can be called). To allow these dependencies to be constructed, shared libraries must provide either a filesymbols/file file or - a fileshlibs/file file, which provides information on the + a fileshlibs/file file. These provide information on the package dependencies required to ensure the presence of interfaces provided by this library. Any package with binaries or libraries linking to a shared library must use these files to determine the required dependencies when it is built. Other packages which use a shared library (for example using ttdlopen()/tt) should compute appropriate dependencies using these files at build time as well. @@ -5990,21 +5990,25 @@ Built-Using: grub2 (= 1.99-9), loadlin (= 1.6e-1) p The two mechanisms differ in the degree of detail that they - provide. A filesymbols/file file documents for each symbol - exported by a library the minimal version of the package any - binary using this symbol will need, which is typically the - version of the package in which the symbol was introduced. - This permits detailed analysis of the symbols used by a + provide. A filesymbols/file file documents, for each symbol + exported by a library, the minimal version of the package any + binary using this symbol will need. This is typically the + version of the package in which the symbol was introduced. This + information permits detailed analysis of the symbols used by a particular package and construction of an accurate dependency, but it requires the package maintainer to track more information - about the shared library. A fileshlibs/file file, in - contrast, only documents the last time the library ABI changed - in any way. It only provides information about the library as a - whole, not individual symbols. When a package is built using a - shared library with only a fileshlibs/file file, the generated - dependency will require a version of the shared library equal to - or newer than the version of the last ABI change. This - generates unnecessarily restrictive dependencies compared + about the shared library. + /p + + p + A fileshlibs/file file, in contrast, only documents the last + time the library ABI changed in any way. It only provides + information about the library as a whole, not individual + symbols. When a package is built using a shared library with + only a fileshlibs/file file, the generated dependency will + require a version of the shared library equal to or newer than + the version of the last ABI change. This generates + unnecessarily restrictive dependencies compared to filesymbols/file files if none of the symbols used by the package have changed. This, in turn, may make upgrades needlessly complex and unnecessarily restrict use of the package @@ -6012,12 +6016,15 @@ Built-Using: grub2 (= 1.99-9), loadlin (= 1.6e-1) /p p - fileshlibsfile files also have a flawed representation of + fileshlibsfile files also only support a limited range of library SONAMEs, making it difficult to use fileshlibs/file files in some unusual corner cases.footnote - libfooN.shlibs says 'libfoo N' instead of the actual SONAME, - so if the SONAME doesn't match one of the two expected - formats (libfoo-N.so or libfoo.so.N) it can't be represented. + A fileshlibs/file file represents an SONAME as a library + name and version number, such as ttlibfoo VERSION/tt, + instead of recording the actual SONAME
Re: Bug#571776: document symbols
Russ Allbery r...@debian.org writes: commit 97cb027db4afab774ea4f4ff9e7bef7a6dcbbda0 Author: Russ Allbery r...@debian.org Date: Sun Aug 12 14:14:23 2012 -0700 Further wording changes on top of Jonathan Neider's work I fixed the spelling of your name in Git before I pushed. Sorry about that. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87fw7ru7j7@windlord.stanford.edu
Re: document symbols
Jonathan Nieder jrnie...@gmail.com writes: Hoorah! :) I don't see any problems in the normative content, so I'd second this if I could. Cosmetic nits (patch below): Thanks, applied. + In our example, if the last change to the ttzlib1g/tt + package that could change behavior for a client of that + library was in version tt1:1.2.3.3.dfsg-1/tt, then + the ttshlibs/tt entry for this library could say: + example compact=compact +libz 1 zlib1g (= 1:1.2.3.3.dfsg-1) + /example Should this say (= 1:1.2.3.3.dfsg-1~) or (= 1:1.2.3.3.dfsg) to be kind to backporters? Before the patch, the example said = 1:1.1.3. Let's go with 1:1.2.3.3.dfsg in the example to show the common case instead of the unusual case. I've applied this: commit 29e3fc2e05b59a7e13913a263a1e22d40cbc9918 Author: Russ Allbery r...@debian.org Date: Sun Aug 12 16:32:35 2012 -0700 Reflect the common case in the shlibs example diff --git a/policy.sgml b/policy.sgml index 050c688..3c863dc 100644 --- a/policy.sgml +++ b/policy.sgml @@ -6796,10 +6796,10 @@ Built-Using: grub2 (= 1.99-9), loadlin (= 1.6e-1) p In our example, if the last change to the ttzlib1g/tt package that could change behavior for a client of that - library was in version tt1:1.2.3.3.dfsg-2/tt, then + library was in version tt1:1.2.3.3.dfsg-1/tt, then the ttshlibs/tt entry for this library could say: example compact=compact - libz 1 zlib1g (= 1:1.2.3.3.dfsg-2~) + libz 1 zlib1g (= 1:1.2.3.3.dfsg) /example This version restriction must be new enough that any binary built against the current version of the library will work @@ -6811,7 +6811,7 @@ Built-Using: grub2 (= 1.99-9), loadlin (= 1.6e-1) As zlib1g also provides a udeb containing the shared library, there would also be a second line: example compact=compact - udeb: libz 1 zlib1g-udeb (= 1:1.2.3.3.dfsg-2~) + udeb: libz 1 zlib1g-udeb (= 1:1.2.3.3.dfsg) /example /p /sect2 -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87sjbrsn2a@windlord.stanford.edu
Re: Bug#273093: Unpredictable behavior when two packages want to divert the same file
Jonathan Nieder jrnie...@gmail.com writes: To be clear, which of the following is this report proposing? * Packages diverting the same file should conflict. My understanding of what Guillem said is that we should say this. You can't actually have two different diversions of the same file at the same time, so two separate packages can't both divert the file. If they do, you end up with a situation (even if you avoid the package conflict) where one of those two packages could be removed, removing the diversion, and then putting the system in an inconsistent state for the second package. In order to safely divert the same file in multiple packages, you would need diversions that would stack and could be separately unwound, and that isn't implemented. So a diversion in essence becomes like a file installed on the system: only one package can own it at a time, so packages that want to divert the same file have to conflict. What, for example, the various proprietary video drivers do is that they all share a utility package that manages the diversions for all of those packages so that the diversion code isn't duplicated in multiple packages. * Packages should not divert a file unless that file is divertable. To make a file divertable, the maintainer of the package shipping it adds a comment to debian/control mentioning the filename and which packages are allowed to divert it. I don't think the bug report was asking for more formality around the coordination with the package maintainer part. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87txx4kczi@windlord.stanford.edu
Re: BinNMU changelog handling for Multi-Arch: same packages
Raphael Hertzog hert...@debian.org writes: The right *temporary* solution then. Remember that this was meant as an intermediary solution until the full changelog (with the bin-nmu entry) is just integrated in the package medata (control.tar). Oh, yes, absolutely agreed. Sorry for not making that clear. Putting the changelog in the package metadata makes a ton of sense. In fact, if we could also do that with the copyright file, that would eliminate nearly all of our issues with linked doc directories and would simplify a whole currently-contentious area of Policy, replacing it with a much simpler debate about the right interface to view those files for installed packages. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87394xn8yz@windlord.stanford.edu
Re: BinNMU changelog handling for Multi-Arch: same packages
Julien Cristau jcris...@debian.org writes: On Wed, Jul 11, 2012 at 09:23:05 +0200, Raphael Hertzog wrote: I know that in the long term you're in favor of moving the changelog in the package metadata and I agree with this plan. But IMO we must find an interim solution in the mean time. Whatever solution ends up being chosen in the end (whether it's dropping the binNMU changelog, moving it to a separate file, or moving the whole changelog away, I don't hugely care), it's too late to make these changes for wheezy IMO. My gut instinct is to agree. Given the incomplete multiarch conversion, it seems like we should just do a final consistency binNMU on all affected packages right before the wheezy release so that they all match (I assume it's possible to do that? if not, we could do a sourceful upload/NMU through testing-proposed-updates) and call it good enough for wheezy. Stable updates are unlikely to have this problem, since I believe binNMUs are very rare inside stable. Doing new feature and design work in dpkg at this point in the release cycle doesn't seem like a good idea. I think using the separate file approach makes sense for wheezy+1 if the dpkg maintainers don't think that the move to package metadata will be done in time. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87mx35ltrt@windlord.stanford.edu
Re: dpkg fails to install 32-bit adobe acrobat reader on 64-bit wheezy system: depends issue
Chris Hiestand chiest...@salk.edu writes: libxml2 source shows that it has Architecture: any, so I'd imagine that should be not be a conflict even though there is no Multi-Arch field. No, that's only for source packages and indicates that the package *can* be built on any architecture. Architecture: all in a binary package means it can be installed on any architecture; otherwise, it's an architcture-specific binary package and must be multiarch to be installable as a non-native architecture (without --force options, of course). -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87y5pqknpw@windlord.stanford.edu
Re: dpkg fails to install 32-bit adobe acrobat reader on 64-bit wheezy system: depends issue
Guillem Jover guil...@debian.org writes: On Fri, 2012-04-20 at 16:06:19 -0700, Russ Allbery wrote: No, that's only for source packages and indicates that the package *can* be built on any architecture. Architecture: all in a binary package means it can be installed on any architecture; otherwise, it's an architcture-specific binary package and must be multiarch to be installable as a non-native architecture (without --force options, of course). To be precise, a foreign arch package could be installed regardless of its multiarch status, as long as there's no other instance present on the system and dpkg has been configured to recognize that foreign arch. Oh, right, sorry. If there's no conflict, you can do what you want. If you want to install multiple architectures of the same package, they all have to be multiarch. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87y5pqj6u8@windlord.stanford.edu
Re: popularity-contest broken with Multi-Arsch
Jonathan Nieder jrnie...@gmail.com writes: I ask because Bill's request makes a lot of sense in light of the explanation Russ gave on debian-devel of multiarch, where there is one package being installed and the list of architectures is just a detail of how it is installed. It's important to note that Guillem raised very good objections to my proposed model for handling architectures. (I didn't reply because I didn't know enough about the internal data model of dpkg to be able to discuss it meaningfully.) -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87r4w4zh8b@windlord.stanford.edu
Re: Bug#629385: Request for TC to rule on a course of action for supporting build-arch
Hearing no objections, I call for a TC vote on the following ballot: A. dpkg-buildpackage, when doing a binary-only build (-B), should probe the package with make -qn to see if the build-arch target appears to be implemented. If so, it should use debian/rules build-arch to build the package instead of debian/rules build. If it detects via make -qn that the target is missing, it should output a warning asking the packager to implement the required targets, and then fall back to using debian/rules build. The fallback to debian/rules build and the make -qn auto-detection are temporary to ease the transition but should be dropped at some point (wheezy+1, or wheezy+2). Debian Policy should be updated to make build-arch and build-indep mandatory targets. B. Further discussion -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/8762dzc8se@windlord.stanford.edu
Re: Bug#552688: Please decide how Debian should enable hardening build flags
I believe at this point the dpkg-buildflags solution has proven reasonably successful and is being widely deployed. I think we should confirm that the TC agrees with that approach and close out this bug. I therefore propose the following ballot: A. The Technical Committee agrees with the dpkg-buildflags approach currently in use to enable hardening flags. B. Further discussion. I think the remaining open question is whether there is a desire to list overriding the GCC maintainer and patching GCC to enable the flags for all compilation on the ballot. My guess is that there is not; if anyone disagrees, please speak up and I'll draft a revised ballot including that option. If there is no other feedback, I plan to call for a vote on the above ballot in a few days. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87r4wpp6mu@windlord.stanford.edu
Re: Bug#571776: document symbols
). - They can thus produce several sets of dependency - variables, each of the form - ttvarvarnameprefix/var:vardependencyfield/var/tt, - which can be referred to in the appropriate parts of the - binary package control files. + See manref name=dpkg-shlibdeps section=1. /p /sect1 - sect1 id=pkg-dpkg-distaddfile heading prgndpkg-distaddfile/prgn - adds a file to -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87aa3fum6e@windlord.stanford.edu
Re: Request for TC to rule on a course of action for supporting build-arch
I believe that the discussion of this has reached a conclusion and the dpkg maintainers are moving forward with an implementation. At this point, it seems like the right thing for the Technical Committee to do is to affirm that we agree with the approach arrived at. I propose the following ballot: A. dpkg-buildpackage, when doing a binary-only build (-B), should probe the package with make -qn to see if the build-arch target appears to be implemented. If so, it should use debian/rules build-arch to build the package instead of debian/rules build. If it detects via make -qn that the target is missing, it should output a warning asking the packager to implement the required targets, and then fall back to using debian/rules build. The fallback to debian/rules build and the make -qn auto-detection are temporary to ease the transition but should be dropped at some point (wheezy+1, or wheezy+2). Debian Policy should be updated to make build-arch and build-indep mandatory targets. B. Further discussion Please send any wording changes to the above, or any other options that you believe should be on the ballot. If there are no objections, I plan to call for a vote in a few days. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ipi2n1z2@windlord.stanford.edu
Re: Multiarch support in dpkg — really in time for wheezy?
John D. Hendrickson and Sara Darnell johnandsa...@cox.net writes: I discount Hertzog completely. He has no patch that creates a release - but words against words. Prove it works for installing users with a widely accepted and applauded release. You cannot yet. Then you can say those point out minor failures are fear mongering. John (or Sara?), your contributions to this thread are at the moment just making things worse. You have been talking about other topics entirely than the ones we've been discussing, and now you're attacking people based on a *very* incomplete understanding of the overall situation. The contention here is difficult enough to discuss without uninvolved third parties making very aggressive comments based on partial information. This thread is the surface of a large number of different conversations between a bunch of different people, only some of which have been on the mailing list. Please, could you take your specific technical concerns to a separate discussion and not jump into the middle of a difficult personal issue between people you're not working closely with? -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87d38skumw@windlord.stanford.edu
Re: Multiarch file overlap summary and proposal
m...@linux.it (Marco d'Itri) writes: On Mar 01, Russ Allbery r...@debian.org wrote: The situation with refcounting seems much less fragile than the situation without refcounting to me. I totally agree. Also, why does refcounting have to be perfect? What would break if it did not actually check that the two files provided by the same package for different architectures are identical? Well, it would break most of the things that make it less fragile. :) -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87399sgog4@windlord.stanford.edu
Re: Multiarch file overlap summary and proposal
Guillem Jover guil...@debian.org writes: On Thu, 2012-02-16 at 10:43:53 -0800, Russ Allbery wrote: I was thinking more about this, and I was finally able to put a finger on why I don't like package splitting as a solution. We know from prior experience with splitting packages for large arch-independent data that one of the more common mistakes that we'll make is to move the wrong files: to put into the arch-independent package a file that's actually arch-dependent. This was brought up by Steve in the thread, my reply: http://lists.debian.org/debian-devel/2012/02/msg00497.html Thanks for the pointer, Guillem, but I'm afraid I don't think this reply addresses my concerns. See the specific enumeration of things that we would have to split, and the ways in which they can break. I think the issue with C headers is particularly severe. I don't think this mirrors an existing problem. The sorts of things we split into arch: all packages are nowhere near as intrusive or as tightly coupled as the things we're talking about splitting to avoid refcounting; for example, right now, splitting out C headers into arch: all packages is very rare. The sort of package splitting that we would do to avoid refcounting would run a serious risk of introducing substantial new problems that we don't currently have. The situation with refcounting seems much less fragile than the situation without refcounting to me. Refcounting puts the chance of error in the right place (on people who want to use the new feature, since the situation will not change for users who continue using packages the way they do today), provides a clear error message rather than silent corruption, and fails safely (on any inconsistency) rather than appearing to succeed in situations that are not consistent. Those are all good design principles to have. I think the principle of not changing things for people who are not using multiarch is particularly important, and is inconsistent with either package splitting or with moving files into arch-qualified paths. We should attempt to adopt new features in a way that puts most of the risk on the people who are making use of the new features, and tries to be as safe as possible for existing users. I agree that we should not pursue that to an extreme that leads to an unmaintainable system, but I don't believe refcounting has that problem. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/874nu9vzbb@windlord.stanford.edu
Re: Multiarch file overlap summary and proposal
Carsten Hey cars...@debian.org writes: * Russ Allbery [2012-02-16 14:55 -0800]: Every file that differs has to be fixed in the current multi-arch plan. Documentation that contains its build date is going to need to be split out into a separate -docs package. I doubt that ftpmaster would be happy about -doc packages that contain just a few small man pages. I think they'll be okay with it when it's the cost of reasonable multiarch. I feel fairly strongly that it isn't sane to have a file overlap when the file doesn't match. You then lose the error detection when there are real problems, and I don't trust any of us, myself included, to correctly tag files where it doesn't matter. On this front, I agree with Guillem: some amount of package splitting is fine, and package splitting instead of additional complexity, like tagging files that are allowed to vary, looks like a good tradeoff to me. The splitting that I'm worried about is where the files are tightly coupled, which is not the case for development man pages that are now in -dev packages. debianutils uses a special make target 'prebuild' in debian/rules to update build system related files and PO files before the actual source package is built. This basic idea also could be used to build problematic documentation files on the maintainers computer before he/she builds the package. The other targets would then install the prebuilt documentation into the package without the need to build it first. A proper dependency on debian/$prebuilt_doc could ensure that maintainers do not forget to run debian/rules prebuild. If maintainers choose to use such a target, suggesting a common name for it in the developers reference could be reasonable. That's an interesting idea. That's very similar to what I already do as upstream (I build POD-generated man pages from my autogen script, and in Debian packaging don't bother to regenerate them). -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87vcn5hml3@windlord.stanford.edu
Re: Multiarch file overlap summary and proposal
I was thinking more about this, and I was finally able to put a finger on why I don't like package splitting as a solution. We know from prior experience with splitting packages for large arch-independent data that one of the more common mistakes that we'll make is to move the wrong files: to put into the arch-independent package a file that's actually arch-dependent. Look at the failure mode when that happens with the sort of package that we're talking about splitting out of m-a:same packages: * The arch-independent package gets arch-dependent content that happens to match the architecture of the maintainer's build machine, since that's the only place the arch-independent package is built. The maintainer will by definition not notice, since the content is right for their system. * The maintainer is probably using a popular system type (usually either i386 or amd64), and everyone else on that system type will also not notice, so the bug can be latent for some time. * Systems with the wrong architecture will get data files that have the wrong format or the wrong information. This is usually not a case that the software is designed to detect, so the result is normally random segfaults or similar sorts of major bugs. The failure case for header files is *particularly* bad: C software will generally compile fine with the wrong-sized data types and then, at *runtime*, happily pass the wrong data into the library, resulting in random segfaults and possibly even data corruption. This won't happen until runtime, so could go undetected for long periods of time. This is a particularly nasty failure mode due to how long it can stay undetected and how much havoc it causes. Now, compare to the failure mode with refcounting if the maintainer doesn't realize that an arch-specific file can't be shared: * Each arch-specific package will continue to get the appropriate files for that architecture. Each package will still be usable and consistent independently, so users who don't care about multiarch won't ever see a problem. * Users who want to co-install separate architectures will immediately encounter a dpkg error saying that the files aren't consistent. This means they won't be able to co-install the packages, but dpkg will prevent any actual harm from happening. The user will then report a bug and the maintainer will realize what happened and be able to find some way to fix it. * Even better, we can automatically detect this error case by scanning the archive for architecture pairs that have non-matching overlapping files and deal with it proactively. The refcounting failure mode behavior is just completely superior here. And this *is* a mistake that we're going to make frequently; we know that from past experience with splitting packages. Note that this problem often happens because, when the maintainer originally split the package, there was nothing arch-specific in the file, but upstream made it arch-specific later on and the maintainer didn't notice. (It's very easy to miss.) This is particularly common with header files. Note that arch-qualifying all of the files does not have the problems of package splitting, but it's also a much more intrusive fix. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87pqdeobyu@windlord.stanford.edu
Re: Multiarch file overlap summary and proposal
Carsten Hey cars...@debian.org writes: * Russ Allbery [2012-02-16 10:43 -0800]: * Users who want to co-install separate architectures will immediately encounter a dpkg error saying that the files aren't consistent. This means they won't be able to co-install the packages, but dpkg will prevent any actual harm from happening. The user will then report a bug and the maintainer will realize what happened and be able to find some way to fix it. * Even better, we can automatically detect this error case by scanning the archive for architecture pairs that have non-matching overlapping files and deal with it proactively. There are still files that differ that do not need to be fixed, for example documentation that contains it's build date. Every file that differs has to be fixed in the current multi-arch plan. Documentation that contains its build date is going to need to be split out into a separate -docs package. I'm fine with splitting documentation; that has far fewer problems than splitting other types of files, since documentation isn't tightly coupled at a level that breaks software. One way to address this is to use a new dpkg control file (placed in /var/lib/dpkg/info) that lists files that dpkg considers to be equal even if they differ. I don't think this is a good idea. I don't think we should allow this sort of inconsistency depending on what package is installed first. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87d39eie26@windlord.stanford.edu
Re: Multiarch file overlap summary and proposal
Ian Jackson ijack...@chiark.greenend.org.uk writes: Joey Hess writes (Re: Multiarch file overlap summary and proposal): Here are a few examples of the problems I worry about. I have not verified any of them, and they're clearly biased toward code I am familiar with, which suggests there are many other similar problems. * Puppet not only installs packages, it may remove them. A puppet config that does dpkg --purge foo will fail if multiarch is enabled, now it needs to find and remove foo:* Yes. Actually, why would that be the behavior? Why would dpkg --purge foo not just remove foo for all architectures for which it's installed, and require that if you want to remove only a specific architecture you then use the expanded syntax? This comes back to something that I started thinking about after Guillem's message, namely that I think the version lockstep is a feature, not a limitation. A lot of the complexity from biarch with RPM comes from the fact that the packages are (as I recall) independent and can be of different versions. This sounds like a nice feature, but I think it's actually a huge source of potential confusion and isn't as useful as it may look. I think it would be better to have a world in which all the architectures of the foo package on the system have to have the same version, because then you don't have to treat foo:i386 and foo:amd64 like they're separate packages. The list of installed architectures is an *attribute* of the package. A package is still either installed or not installed, but when it's installed, it can be installed for one or more architectures. But if it's installed for multiple architectures, those architectures are always upgraded together and always remain consistent. That avoids all weirdness of having a package work differently because the version varies depending on the ABI, and it significantly simplifies the mental model behind the package. Note that this obviously requires that a binNMU not be considered a different version of the package for this purpose. But I think that too makes sense. A binNMU *isn't* a full new version of the package; it's a new build of the same version. We've historically been a bit sloppy about this distinction, but I think it's a real distinction and a meaningful one. I have not looked in detail at the current multiarch implementations and I have no idea how closely the above matches what is actually being done, but I would advocate for it, even to the degree of embedding understanding of binNMU versioning in the package tools so that they know a binNMU is a new version from the perspective of needing to upgrade the package but not a new version from the perspective of version mismatches between arches. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ehtv650n@windlord.stanford.edu
Re: Multiarch file overlap summary and proposal
and similar interfaces despite the fact that the user doesn't care about it at all. I really don't like package splitting as our answer to everything. At the least, it definitely isn't an obviously clean and simple solution. 2. Include files are, by quantity, a pretty substantial percentage of the files we're talking about here once we start making our -dev packages multiarch aware. Most include files these days aren't arch-specific, since facilities like int32_t have removed a lot of the need to put architecture-specific information in headers. Refcounting handles them quite cleanly. They don't change during binNMUs, and they aren't compressed. I think splitting all -dev packages into -dev and -include is a non-starter. This is a bunch of extra packaging work, it adds a bunch of noise to our package lists that interferes with user searches, it really does create a substantial number of additional packages (one for every -dev package in the archive to a first approximation if we multiarch everything), and it creates new artificial user support problems, such as users who install the -include package and not the -dev package and then don't understand why they can't link with the library. So, what we're really talking about here, in the absence of refcounting, is moving the entirety of /usr/include into /usr/include/triplet. Now, this *does* work technically; compilers will find the headers, and the behavior will be what we want. But again this is ongoing packaging complexity to install the headers in a place other than where the upstream build system is going to put them. It's also surprising. We already broke a few packages just by moving the arch-specific include files of some packages there, which is unavoidable. I had to do more ugly things to the ugly openafs build system to cope, for example. And we just had a really uncomfortable conversation on the GCC mailing list (that amounted to what are those crazy Debian people doing?) because these moves broke building GCC from source because header files are no longer where they are everywhere else. Doing this for arch-specific headers is already problematic but not really avoidable if we're going to move forward. But that's a smaller change than doing it for nearly all headers, and I think we're really going to surprise our users in some unpleasant ways if we do this. Yes, software should not assume it knows the system header search paths, but the fact remains that software *does*, and fixing all of it is going to be painful and not produce a lot of good will with upstreams. 3. Package metadata in /usr/share/doc/package. Yes, we can avoid refcounting here by using package:arch instead, and I understand the appeal of simplicitly there. But the more I think about this, the more I think this is not the right model for how our packages should look and not the idea that we should be exposing to users. I don't think we should be encouraging the idea that package:i386 and package:amd64 are two completely distinct installed packages that have no relationship to each other. Rather, I think we should encourage users to think of a single installed package named package, which can be installed for one or more architectures. Creating separate package metadata directories is the right thing to do if we expect the i386 and amd64 installed packages to be different, have different copyrights, have different NEWS.Debian files, different READMEs, different changelogs (binNMU aside, as mentioned above), and so forth. But this is going down exactly that complexity path that Joey is talking about, IMO. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/874nur62jd@windlord.stanford.edu
Re: Multiarch file overlap summary and proposal
Joey Hess jo...@debian.org writes: Anyway, my worry about the refcounting approach (or perhaps M-A: same in general) is not the details of the implementation in dpkg, but the added mental complexity of dpkg now being able to have multiple distinct packages installed under the same name. I had a brief exposure to rpm, which can install multiple versions of the same package, and that was the main cause of much confusing behavior in rpm. While dpkg's invariant that all co-installable package names be unique (and have unique files) has certianly led to lots of ugly package names, it's kept the users' and developers' mental models quite simple. I worry that we have barely begun to scratch the surface of the added complexity of losing this invariant. This does seem to be more M-A: same in general, to me, since whether we have file overlaps or not we still have multiple packages with the same name. Which will force changes in everything that deals with packages, like Puppet, to be able to specify packages with particular architectures. I definitely agree on the complexity this adds. But I don't think there's an alternative to that complexity without using something like --sysroot or mini-chroots, and I don't think those are satisfying solutions to the set of problems we're trying to solve. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87pqdg4u5l@windlord.stanford.edu
Multiarch file overlap summary and proposal (was: Summary: dpkg shared / reference counted files and version match)
something else here, probably by generating new binary-specific changelog files for binNMUs. Does this seem comprehensive to everyone? Am I missing any cases? If this is comprehensive, then I propose the following path forward, which is a mix of the various solutions that have been discussed: * dpkg re-adds the refcounting implementation for multiarch, but along with a Policy requirement that packages that are multiarch must only contain files in classes 1 and 2 above. * All packages that want to be multiarch: same have to move all generated documentation into a separate package unless the maintainer has very carefully checked that the generated documentation will be byte-for-byte identical even across minor updates of the documentation generation tools and when run at different times. * Lintian should recognize arch-qualified override files, and multiarch: same packages must arch-qualify their override files. debhelper assistance is desired for this. * Policy prohibits arch-varying data files in multiarch: same packages except in arch-qualified paths. * The binNMU process is changed to add the binNMU changelog entry to an arch-qualified file (changelog.Debian.arch, probably). We need to figure out what this means if the package being binNMU'd has a /usr/share/doc/package symlink to another package, though; it's not obvious what to do here. Please note that this is a bunch of work. I think the Lintian work is a good idea regardless, and it can start independently. I think the same is true of the binNMU changelog work, since this will address some long-standing issues with changelog handling in some situations, including resolving just how we're supposed to handle /usr/share/doc symlinks. But even with those aside, this is a lot of stuff that we need to agree on, and in some cases implement, in a fairly short timeline if this is going to make wheezy. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/874nutncef.fsf...@windlord.stanford.edu
Re: Please test gzip -9n - related to dpkg with multiarch support
Goswin von Brederlow goswin-...@web.de writes: Changing the name in the package would break tools that rely on the name (like packages.debian.org extracting the Changelog). Also ugly. We control the tools; we can change the tools. Multiarch is a big deal. We weren't going to get through this without changing some tools. (One should not read that as my support of this specific alternative, as I've not decided there yet, but in general I think it's fair game to change our tools to support multiarch.) -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87k43vu389@windlord.stanford.edu
Re: Please test gzip -9n - related to dpkg with multiarch support
Guillem Jover guil...@debian.org writes: On Wed, 2012-02-08 at 13:19:17 +, Ian Jackson wrote: Well, it does mean that you might be lacking important information because the other changelog wouldn't be present on the system. While the implicit Replaces seems the easy way out, it just seems even more fragile than the shared files approach. Yes, this is definitely true. I was mentioning it as an easy way out, but it's aesthetically unappealing. And while the binNMU changelog issues might seem like a corner case, it's just a symptom of something that's not quite right. Also true. In fact, it's something that's been bothering me for a long time with linked doc directories. I'd like to prohibit them in more cases so that we get the binNMU changelogs on disk. Instead of this, I'd rather see the shared files approach just dropped completely, and /usr/share/doc/ files for “Multi-Arch: same” packages be installed under /usr/share/doc/pkgname:arch/. This would solve all these problems in a clean way for the common case with just the two or three mandated files (changelog, changelog.Debian and copyright), if a package provides lots more files then they should be split anyway into either a libfooN-common libfoo-doc, or similar. And finally this would not be really confusing, given that one of the last interface changes was to make all dpkg output for all “Multi-Arch: same” packages be always arch-qualified. The only thing I'm worried about here is that we lose something from the UI perspective. That's going to be a change historically from where we've told users to look, and it's a little awkward. But, thinking it over, the set of packages that we're talking about is fairly limited. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87liodrttk@windlord.stanford.edu
Re: Please test gzip -9n - related to dpkg with multiarch support
Steve Langasek vor...@debian.org writes: The unfounded assumption here is that you will always install a foreign-arch M-A: same package together with the native-arch version. If I install libaudio2:i386 because I want to play a game that's only available as a 32-bit binary and has this lib as a dependency, and nothing else on my system uses libaudio2, I still expect to get /usr/share/libaudio2/AuErrorDB installed. How is that not a serious policy violation already? AuErrorDB isn't versioned with the SONAME, so libaudio2 and libaudio3 would not be coinstallable. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/874nv0n7vd@windlord.stanford.edu
Re: Please test gzip -9n - related to dpkg with multiarch support
Steve Langasek vor...@debian.org writes: On Wed, Feb 08, 2012 at 04:55:02PM -0800, Russ Allbery wrote: Steve Langasek vor...@debian.org writes: The unfounded assumption here is that you will always install a foreign-arch M-A: same package together with the native-arch version. If I install libaudio2:i386 because I want to play a game that's only available as a 32-bit binary and has this lib as a dependency, and nothing else on my system uses libaudio2, I still expect to get /usr/share/libaudio2/AuErrorDB installed. How is that not a serious policy violation already? AuErrorDB isn't versioned with the SONAME, so libaudio2 and libaudio3 would not be coinstallable. Because libaudio2 is in the directory name. Oh, duh. Sorry, I'm just blind. Also, it's not a policy violation for a library package to contain files that don't have sensibly versioned names; it's only a policy violation for the name to not change on soname bump. So even if this were called /usr/share/AuErrorDB, it could be changed to /usr/share/libaudio3/AuErrorDB on soname change and still be compliant. Good point. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ty30iz9a@windlord.stanford.edu
Re: Please test gzip -9n - related to dpkg with multiarch support
Neil Williams codeh...@debian.org writes: Maybe the way to solve this properly is to remove compression from the uniqueness check - compare the contents of the file in memory after decompression. Yes, it will take longer but it is only needed when the md5sum (which already exists) doesn't match. Another possible solution is to just give any package an implicit Replaces (possibly constrained to /usr/share/doc) on any other package with the same name and version and a different architecture. This isn't as defensive, in that it doesn't catch legitimate bugs where someone has made a mistake and the packages contain different contents, but it also solves the binNMU issue (well, solves; the changelog will randomly swap back and forth between the packages, but I'm having a hard time being convinced this is a huge problem). -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87fwemz229@windlord.stanford.edu
Re: Bug#571776: document symbols
Raphael Hertzog hert...@debian.org writes: On Mon, 02 Jan 2012, Russ Allbery wrote: [...] p fileshlibs/file files were the original mechanism for handling library dependencies. They are documented in ref id=sharedlibs-shlibdeps. filesymbols/file files, documented in this section, are recommended for most packages, since they provide dependency information for each exported symbol and therefore generate more accurate dependencies for binaries that do not use symbols from newer versions of the shared library. However, fileshlibs/file files must be used for udebs. Packages which provide a filesymbols/file file are not required to provide a fileshlibs/file file. /p In practice I don't think that we have any package providing a symbols files without a shlibs file. Yes, but there was some discussion in the Policy bug asking why shlibs files were required when they're not used if a symbols file is present, and while I originally argued that keeping them both made sense, I came around to that position after reviewing the bug discussion. It doesn't hurt anything, but there doesn't really seem to be any point in providing shlibs if symbols is present. If your source package builds only a single binary package that contains only compiled binaries and libraries (but no scripts) and is not multiarch, you can use a command such as: example compact=compact dpkg-shlibdeps debian/tmp/usr/bin/* debian/tmp/usr/sbin/* \ debian/tmp/usr/lib/* /example but normally finding all of the binaries is more complex. I would drop the part above (up to the 4 dashes that I added). This example will only mislead people IMO because debian/tmp/ is far from being the norm. debian/pkg is much more common for single binary packages. And as you said, it doesn't cover all cases. Yeah, good point. This was retained from the old shlibs documentation, but at this point I don't think anyone really looks here to see how to do this. Dropped. binary package.footnote Again, prgndh_shlibdeps/prgn and prgndh_gencontrol/prgn will handle all of this for you if you're using ttdebhelper/tt. /footnote I would indicate in the footnote that dh_shlibdeps/dh_gencontrol use an alternate substvars file by default (debian/pkg.substvars). I now have: binary package.footnote Again, prgndh_shlibdeps/prgn and prgndh_gencontrol/prgn will handle all of this for you if you're using ttdebhelper/tt, including generating separate filesubstvars/file files for each binary package and calling prgndpkg-gencontrol/prgn with the appropriate flags. /footnote sect1 id=symbols headingThe filesymbols/file File Format/heading [...] For our example, the ttzlib1g/tt filesymbols/file file would contain: example compact=compact * Build-Depends-Package: zlib1g-dev /example (Don't forget the leading space.) What leading space are you referring to ? I now have: (Don't forget the space before the tt*/tt so that it will be parsed as part of the entry for that library.) Due to the way that the formatting of Policy works, it's very hard to tell that there's a space there, and unlike with symbols where the indentation is fairly obvious, it's not completely obvious that it's required. [...] sect1 id=shlibs-paths headingThe fileshlibs/file files present on the system/heading [...] item pfileDEBIAN/shlibs/file files in the build directory/p p When packages are being built, any filedebian/shlibs/file files are copied into the control information file area of the temporary build directory and given the name fileshlibs/file. These files give details of any shared libraries included in the same package. /p /item debian/shlibs is (no longer) a standard file... debhelper doesn't install such files, it generates shlibs files on the fly and I don't believe that any modern package still has debian/shlibs. So I would rewrite this paragraph to just say that DEBIAN/shlibs is the shlibs file produced by the current package build. I now have: p These files are generated as part of the package build process and staged for inclusion as control files in the binary packages being built. They provide details of any shared libraries included in the same package. /p I would shorten the explanation here and drop the example of how to install
Re: Bug#571776: document symbols
Russ Allbery r...@debian.org writes: I tried sending a unified diff, but the new sections are largely unreadable since they're intermixed with the old sections being removed. Hence, for review purposes, here are the symbols and shlibs sections in their entirety, followed by a diff for the changes elsewhere in Policy. You can also refer to branch bug571776-rra in the Policy repository. Here is an updated diff with the changes from Raphael's review. git diff --patience actually generates a decent diff (I learn something new every day!), so I didn't have to separate out the new sections. diff --git a/policy.sgml b/policy.sgml index 23c1913..b57dd76 100644 --- a/policy.sgml +++ b/policy.sgml @@ -840,10 +840,11 @@ Among those files are the package maintainer scripts and filecontrol/file, the qref id=binarycontrolfilesbinary package control file/qref that contains the control fields for - the package. Other control information files - include qref id=sharedlibs-shlibdepsthe fileshlibs/file - file/qref used to store shared library dependency information - and the fileconffiles/file file that lists the package's + the package. Other control information files include + the qref id=sharedlibs-symbolsfilesymbols/file file/qref + or qref id=sharedlibs-shlibdepsfileshlibs/file file/qref + used to store shared library dependency information and + the fileconffiles/file file that lists the package's configuration files (described in ref id=config-files). /p @@ -5521,9 +5522,9 @@ Replaces: mail-transport-agent linked against the old shared library. Correct versioning of dependencies on the newer shared library by binaries that use the new interfaces is handled via - the qref id=sharedlibs-shlibdepsttshlibs/tt - system/qref or via symbols files (see - manref name=deb-symbols section=5). + the qref id=sharedlibs-symbolsttsymbols/tt system/qref + or the qref id=sharedlibs-shlibdepsttshlibs/tt + system/qref. /p p @@ -5792,361 +5793,789 @@ Replaces: mail-transport-agent /p /sect + sect id=sharedlibs-symbols + headingDependencies between the library and other packages - + the ttsymbols/tt system/heading + + p + If a package contains a binary or library which links to a + shared library, we must ensure that, when the package is + installed on the system, all of the libraries needed are also + installed. These dependencies must be added to the binary + package when it is built, since they may change based on which + version of a shared library the binary or library was linked + with. To allow these dependencies to be constructed, shared + libraries must provide either a filesymbols/file file or + a fileshlibs/file file, which provide information on the + package dependencies required to ensure the presence of this + library. Any package which uses a shared library must use these + files to determine the required dependencies when it is built. + /p + + p + fileshlibs/file files were the original mechanism for + handling library dependencies. They are documented + in ref id=sharedlibs-shlibdeps. filesymbols/file files, + documented in this section, are recommended for most packages, + since they provide dependency information for each exported + symbol and therefore generate more accurate dependencies for + binaries that do not use symbols from newer versions of the + shared library. However, fileshlibs/file files must be used + for udebs. Packages which provide a filesymbols/file file + are not required to provide a fileshlibs/file file. + /p + + p + When a package that contains any shared libraries or compiled + binaries is built, it must run prgndpkg-shlibdeps/prgn on + each shared library and compiled binary to determine the + libraries used and hence the dependencies needed by the + package.footnote + prgndpkg-shlibdeps/prgn will use a program + like prgnobjdump/prgn or prgnreadelf/prgn to find the + libraries and the symbols in those libraries directly needed + by the binaries or shared libraries in the package. + /footnote + /p + + p + We say that a binary ttfoo/tt emdirectly/em uses a + library ttlibbar/tt if it is explicitly linked with that + library (that is, the library is listed in the + ELF ttNEEDED/tt attribute, caused by adding tt-lbar/tt + to the link line when the binary is created). Other libraries + that are needed by ttlibbar/tt are + linked emindirectly/em to ttfoo/tt, and the dynamic + linker will load
Re: Bug#571776: document symbols
Raphael Hertzog hert...@debian.org writes: There is no leading space before the *. Just like | it must be on the first column to differentiate with symbol definitions which do have a leading space on their lines. Oh, then deb-symbols(5) is wrong for both * and |... oh, I see, I was misreading how the syntax definition worked and the spaces around [] weren't literal. Aie. I'll fix. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87vcof8h7x@windlord.stanford.edu
Re: Bug#571776: document symbols
Raphael Hertzog hert...@debian.org writes: I think this description adapted from the deb-symbols(5) manual page mislead you into thinking that there were leading spaces before | or * when in fact there are none. I have updated the manual page to make it look like this now: library-soname main-dependency-template [| alternative-dependency-template] [...] [* field-name: field-value] [...] symbol minimal-version [id-of-dependency-template] Thanks, I've now fixed my draft text as well. + example +libGL.so.1 libgl1 + | libgl1-mesa-glx #MINVER# Drop the leading space on that last line. Done. +For our example, the ttzlib1g/tt filesymbols/file file +would contain: +example compact=compact + * Build-Depends-Package: zlib1g-dev And here too. Done. +/example +(Don't forget the space before the tt*/tt so that it will +be parsed as part of the entry for that library.) And that sentence is then useless (or needs to be reworded). Dropped. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ehv35h9k@windlord.stanford.edu
Re: Bug#571776: document symbols
Charles Plessy ple...@debian.org writes: here are some comments about the current patch. I agree with the other changes made subsequently in that thread. + If a package contains a binary or library which links to a + shared library, we must ensure that, when the package is + installed on the system, all of the libraries needed are also + installed. These dependencies must be added to the binary + package when it is built, since they may change based on which + version of a shared library the binary or library was linked + with. I have a difficulty with that sentence : isn't the goal of the symbols system to actually avoid that a dependancy changes when a package is built on a newer version of a library ? What rather changes is that the dependancy is modified when a new version of the package makes new calls to the library, which may have been implemented only in newer versions of the library. That's true, but somewhat deceptive because this can happen with no changes to the client code. In some cases, changes only to the library with no changes to the client code can require tighter dependencies when the client is built against the newer library. The obvious example is replacing a macro in a header with an actual function entry point. In this case, the client code will build and work fine with either the older or the newer version of the library, but when built against the newer library, it won't work with the older library. That's what this is trying to capture here. If the exact same code is rebuilt against a newer version of a library, it may have to depend on that newer version of the library. If the misunderstanding is on my side, please consider it a hint that the explanations can be expanded :) [PS: after reading the whole patch, maybe this has something to do with minimal-version ?] I'm not really sure what else to say, but I'm happy to add more if someone can take a shot at letting me know what's needed But I was intentionally trying to keep this vague and not get into enumerating the reasons why dependencies may need to be tightened. That's really a topic for a whole separate guide on how shared libraries should be packaged. The rest of your changes look good, although I haven't had a chance to incorporate them yet. I'll take a look, hopefully soon, although I may not have time this weekend (which is a long holiday weekend in the US). -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87boq6512a@windlord.stanford.edu
Re: Bug#571776: document symbols
Cyril Brulebois k...@debian.org writes: Russ Allbery r...@debian.org (13/01/2012): Yes, but there was some discussion in the Policy bug asking why shlibs files were required when they're not used if a symbols file is present, and while I originally argued that keeping them both made sense, I came around to that position after reviewing the bug discussion. It doesn't hurt anything, but there doesn't really seem to be any point in providing shlibs if symbols is present. Last I checked, one needs an shlibs file to get proper dependencies into udebs, which explains why libx* packages still use some -V flag in their dh_makeshlibs call. Yes, udebs are called out as an exception and it's still stated that shlibs must be used for udebs. They still are consistent with the property above, though, since symbols aren't supported for udebs, or at least that's what I understood. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87obu63ey2@windlord.stanford.edu
Re: Bug#571776: document symbols
- dependencies
- /heading
-
- p
- This program is usually called from filedebian/rules/file
- just before prgndpkg-gencontrol/prgn (see ref
- id=pkg-sourcetree), in the top level of the source tree.
- /p
-
- p
- Its arguments are executables and shared libraries
- footnote
- p
- They may be specified either in the locations in the
- source tree where they are created or in the locations
- in the temporary build tree where they are installed
- prior to binary package creation.
- /p
- /footnote for which shared library dependencies should
- be included in the binary package's control file.
- /p
-
- p
- If some of the found shared libraries should only
- warrant a ttRecommends/tt or ttSuggests/tt, or if
- some warrant a ttPre-Depends/tt, this can be achieved
- by using the tt-dvardependency-field/var/tt option
- before those executable(s). (Each tt-d/tt option
- takes effect until the next tt-d/tt.)
- /p
-
- p
- prgndpkg-shlibdeps/prgn does not directly cause the
- output control file to be modified. Instead by default it
- adds to the filedebian/substvars/file file variable
- settings like ttshlibs:Depends/tt. These variable
- settings must be referenced in dependency fields in the
- appropriate per-binary-package sections of the source
- control file.
- /p
-
- p
- For example, a package that generates an essential part
- which requires dependencies, and optional parts that
- which only require a recommendation, would separate those
- two sets of dependencies into two different fields.footnote
- At the time of writing, an example for this was the
- package/xmms/ package, with Depends used for the xmms
- executable, Recommends for the plug-ins and Suggests for
- even more optional features provided by unzip.
- /footnote
-It can say in its filedebian/rules/file:
- example
- dpkg-shlibdeps -dDepends varprogram anotherprogram .../var \
- -dRecommends varoptionalpart anotheroptionalpart/var
- /example
- and then in its main control file filedebian/control/file:
- example
- var.../var
- Depends: ${shlibs:Depends}
- Recommends: ${shlibs:Recommends}
- var.../var
- /example
- /p
-
- p
- Sources which produce several binary packages with
- different shared library dependency requirements can use
- the tt-pvarvarnameprefix/var/tt option to override
- the default ttshlibs:/tt prefix (one invocation of
- prgndpkg-shlibdeps/prgn per setting of this option).
- They can thus produce several sets of dependency
- variables, each of the form
- ttvarvarnameprefix/var:vardependencyfield/var/tt,
- which can be referred to in the appropriate parts of the
- binary package control files.
- /p
- /sect1
-
-
sect1 id=pkg-dpkg-distaddfile
heading
prgndpkg-distaddfile/prgn - adds a file to
--
Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/
--
To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87fwfxsrhq.fsf...@windlord.stanford.edu
Re: postinst corrupts my settings after a 'apt-get upgrade'.
vot...@gmx.de writes: i have some problems with the package update mechanism in my appliance. I have installed various services like 'forked-daapd'. Because i wanted to monitor and start the daemon via 'monit' i removed the init script from the runlevels via 'update-rc.d -f forked-daapd remove'. After a 'apt-get dist-upgrade' (after enabling Squeeze backports) i received the package from the backports. The problem now is that it seems that the 'postinst' script has registered the runlevels again and the process is statred via init.d script and monit now. The basic problem that you're having is that this is not the correct way to disable an init script in Debian. The correct way is to rename all the S* links in /etc/rc?.d for that service to K* links. If you make that change, you'll find it's preserved across upgrades and changes. And yes, that's annoying and there's no good tool in the base installation to handle it for you, and that's a bug that should be fixed. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/8739f7b6mk@windlord.stanford.edu
Re: [RFC] Skipping new-prerm failed-upgrade?
Raphael Hertzog hert...@debian.org writes: I would thus like to discuss 2 ideas: 1/ I'd argue that in the case of downgrade, dpkg should not try to run the failed-upgrade fallback because there's no way the oldest version can be aware of how to work-around a problem in a prerm script of a newer version that did not exist at the time the oldest prerm was written. Suggested patch attached. Do you agree with this? Do you see possible problems with this? I think I agree with this change. The only thing the old version could do is run generic recovery code, and if there's generic recovery code, it can just go into the new version directly where no fallback is required. Downgrade is basically unspecified in Policy right now. It would be interesting to do the work to specify how things behave, although I suspect it would be a non-trivial amount of work. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87zkldvf2v@windlord.stanford.edu
Bug#629582: dpkg-dev: Add local-patch-header?
Package: dpkg-dev Version: 1.16.0.3 Severity: wishlist Most of my packages are maintained in Git, with the separate changes, if broken out at all, broken out in separate branches with their own history. Since the tools like TopGit for generating a patch series from that setup are all rather awkward to use, I generally set single-debian-patch with a patch-header file explaining the situation. Currently, I'm using options for that, but that means that any NMU changes are rolled into the same patch. I'd rather set single-debian-patch only for my uploads from the revision control repository so that NMUs are kept in separate patches. So I want to switch to local-options from options for setting single-debian-patch. The problem is that I have a patch-header file that explains why all the changes are merged together into one patch, and the contents of that file do not apply to any NMU patches and would be confusing. But there doesn't seem to be a way to make the patch-header apply only to uploads from my repository and not be included in the package. Could you add a local-patch-header file or some other mechanism to use that patch-header only with my local-options file and not for every NMU diff or changes made by others? -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.38-2-686-bigmem (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages dpkg-dev depends on: ii base-files6.3Debian base system miscellaneous f ii binutils 2.21.51.20110523-1 The GNU assembler, linker and bina ii bzip2 1.0.5-6high-quality block-sorting file co ii libdpkg-perl 1.16.0.3 Dpkg perl modules ii make 3.81-8.1 An utility for Directing compilati ii patch 2.6.1-2Apply a diff file to an original ii xz-utils 5.0.0-2XZ-format compression utilities Versions of packages dpkg-dev recommends: ii build-essential 11.5 Informational list of build-essent ii fakeroot 1.15.1-1 tool for simulating superuser priv ii gcc [c-compiler] 4:4.6.0-5 The GNU C compiler ii gcc-4.4 [c-compiler] 4.4.6-3The GNU C compiler ii gcc-4.5 [c-compiler] 4.5.3-1The GNU C compiler ii gcc-4.6 [c-compiler] 4.6.0-10 The GNU C compiler ii gnupg 1.4.11-3 GNU privacy guard - a free PGP rep ii gpgv 1.4.11-3 GNU privacy guard - signature veri pn libalgorithm-merge-perl none (no description available) Versions of packages dpkg-dev suggests: ii debian-keyring2011.03.03 GnuPG keys of Debian Developers -- no debconf information -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Declarative Diversions - GSoC Project Update 1
Raphael Hertzog hert...@debian.org writes: Or to use two lines instead of one. And to support multiple entries make the different entries separated by an empty line (so that it's possible to add supplementary fields in the future shall that be required). --- source1 dest1 source2 dest2 --- This still doesn't give a completely general solution, although at this point the number of characters that aren't allowed becomes an edge case. I don't know if it's worth formalizing an escape procedure so that one could divert arbitrary filenames (which can contain, for example, newlines). -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87d3iy4ok3@windlord.stanford.edu
Re: Declarative Diversions - GSoC Project Update 1
Steve Langasek vor...@debian.org writes: There are definitely cases where Divert-To would be needed; Tollef has pointed out one, another is when diverting a shared library because you have to divert to a completely different directory to ensure ldconfig doesn't pick it up and create a symlink to the wrong (diverted) file. An interesting complex example of current uses of diversions that illustrates your point about shared libraries and a few other things may be the libglx-nvidia-alternatives package. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ipsq34ee@windlord.stanford.edu
Bug#625789: dpkg-source: --extend-diff-ignore doesn't work as expected
Jonathan Nieder jrnie...@gmail.com writes: Guido Günther wrote: As I wrote I dropped -i and -I from git-pbuilder with the last upload. However this broke the 1.0 source format build (since they don't exclude .git automatically), so I went for this: http://git.debian.org/?p=users/agx/git-buildpackage.git;a=commit;h=033f359f5c65ae02d81410320c0f2f77ea54ff3b Any thoughts on this solution? It makes sense to me. The following is an alternative but I think what you did is better. Hi folks, I'm really sorry about being so far behind on reviewing git-pbuilder changes. I'm going to work on catching up today. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#625789: dpkg-source: --extend-diff-ignore doesn't work as expected
Guido Günther a...@sigxcpu.org writes: As I wrote I dropped -i and -I from git-pbuilder with the last upload. However this broke the 1.0 source format build (since they don't exclude .git automatically), so I went for this: http://git.debian.org/?p=users/agx/git-buildpackage.git;a=commit;h=033f359f5c65ae02d81410320c0f2f77ea54ff3b Any thoughts on this solution? I read back through all the discussion of this, and this looks like exactly the right solution to me. This will be in my next release. Thanks! I was persuaded by the argument that, with source package format 3.0, there are a bunch of other places this can be controlled that are much better and can be included in the package in the debian/source directory. Documenting them there is better than having them be behavior of the script, since there they affect everyone's methods of building packages, not just people using the same tools. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#593909: Names of Fields in Control Files
Charles Plessy ple...@debian.org writes: Here is an updated patch, that contains the following: Each paragraph consists of a series of data fields; each field consists of the field name, followed by a colon and - then the data/value associated with that field. It ends at - the end of the (logical) line. Horizontal whitespace + then the data/value associated with that field. The field + name is composed of printable ASCII characters (i.e., + characters that have values between 33 and 126, inclusive) + except colon and must not with a begin with #. The + field ends at the end of the line or at the end of the + last continuation line (see below). Horizontal whitespace (spaces and tabs) may occur immediately before or after the value and is ignored there; it is conventional to put a Apart from adding that fields names may not begin with #, I also changed ‘US-ASCII’ for ‘ASCII’, since this is the vocabulary used by the Policy. Thanks, this is now applied for the next Policy release. Sorry about the long delay. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87pqozet8m@windlord.stanford.edu
Re: Bug#504880: Disambiguate installed for packages
Raphael Hertzog hert...@debian.org writes: On Fri, 04 Mar 2011, Jonathan Nieder wrote: ) I suspect others like it, too, but who knows? Patch attached. Seconds or objections welcome. Seconded. It's long and I might have missed some inaccuracies but I think it's an improvement in clarity. Thanks! With this and with Steve's earlier approval, I'm going to call this good enough and merge this monster. We can definitely fix any problems that I introduced later on after more people have had a chance to study it and apply it to their packages. Thank you, everyone, for all your reviews of this giant patch. I think it will be a great first step towards making maintainer script state less confusing. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87zko6mzeg@windlord.stanford.edu
Bug#619131: New field Package-List in .dsc
Raphael Hertzog hert...@debian.org writes: On Thu, 24 Mar 2011, Bernhard R. Link wrote: If it really is in the .dsc files then it would be nice if it also could include the Architecture: of those packages. That would make it easier for things like reprepro to decide if there might be some binary package missing. (Or for other forms of poor-man's stateless wanna-build stuff). The architecture is not a single value, but rather a list of values (in the source package). It might be doable to put that list at the end of the line but it doesn't feel quite right. What do others think? The missing architecture was my immediate thought as well, since for a moment I thought ftp-master might need it, but then I realized that the override settings are arch: all. So I'm ambivalent. I will mention that if you wanted to add the architecture, you could just s/ +/,/g on the architecture list and then you'd get something that should be reasonably easy to parse and would still use spaces to separate from other fields, since the architecture list isn't too complex in syntax other than being a list. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Accepted bup 0.17b-2squeeze1 (source i386)
Julien Cristau jcris...@debian.org writes: On Tue, Jan 4, 2011 at 10:03:00 +, Jon Dowland wrote: bup (0.17b-2squeeze1) testing-proposed-updates; urgency=low . * use python-support to tightly version python dependency, needed due to the binary extensions. Thanks Jakub Wilk. Closes: #608568. *sigh* if you're going to use dpkg v3, could you please avoid the automatic patch feature? It turns a trivial fix into 5 files changed, 70 insertions(+), 61 deletions(-) because patches/debian-changes-0.17b-1 | 58 patches/debian-changes-0.17b-2squeeze1 | 59 + If you're going to always generate a single Debian patch for whatever reason (I do this because the packaging is managed in Git with separate branches per change and I don't like any of the systems that turn Git branches into patches), add a debian/source/options file containing: single-debian-patch (and ideally add a debian/source/patch-header file with the header explaining why you're doing this). That will force the patch name to always be debian-changes. People reviewing the package will still see a diff of a diff unless they unpack the package and and diff the trees with the patch applied, but at least the file name won't change and the diff of the diff will be relatively meaningful. Some might argue for using local-options instead of options so that NMU diffs would be separated into their own files. I prefer using options, but opinions will vary. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87tyhogksf@windlord.stanford.edu
Re: Bug#593909: Names of Fields in Control Files
Charles Plessy ple...@debian.org writes: Here is an updated patch, that contains the following: Each paragraph consists of a series of data fields; each field consists of the field name, followed by a colon and - then the data/value associated with that field. It ends at - the end of the (logical) line. Horizontal whitespace + then the data/value associated with that field. The field + name is composed of printable ASCII characters (i.e., + characters that have values between 33 and 126, inclusive) + except colon and must not with a begin with #. The + field ends at the end of the line or at the end of the + last continuation line (see below). Horizontal whitespace (spaces and tabs) may occur immediately before or after the value and is ignored there; it is conventional to put a Apart from adding that fields names may not begin with #, I also changed ‘US-ASCII’ for ‘ASCII’, since this is the vocabulary used by the Policy. And, for the record, seconding this combined patch. Thank you for all your work on this! -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87bp6ze6ss@windlord.stanford.edu
Re: Bug#593909: Names of Fields in Control Files
Charles Plessy ple...@debian.org writes: how about simply paraphrasing the RFC 822/5832, which our the source of inspiration ? In that case, the requirement for field names will be to be printable ASCII characters, except colons. I propose the following change in the context the patch that I am preparing for clarifying the Policy's chapter about control files, in bug #593909. diff --git a/policy.sgml b/policy.sgml index be0a505..5c72355 100644 --- a/policy.sgml +++ b/policy.sgml @@ -2493,9 +2493,11 @@ endif p Each paragraph consists of a series of data fields; each field consists of the field name, followed by a colon and - then the data/value associated with that field. It ends at - the end of the line or at the end of the last - continuation line (see below). Horizontal whitespace + then the data/value associated with that field. The field + name is composed of printable US-ASCII characters (i.e., + characters that have values between 33 and 126, inclusive), + except colon. The field ends at the end of the line or at + the end of the last continuation line (see below). Horizontal whitespace (spaces and tabs) may occur immediately before or after the value and is ignored there; it is conventional to put a single space after the colon. For example, a field might Seconded. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87bp70tm61@windlord.stanford.edu
Re: Bug#593909: Names of Fields in Control Files
Charles Plessy ple...@debian.org writes: how about simply paraphrasing the RFC 822/5832, which our the source of inspiration ? In that case, the requirement for field names will be to be printable ASCII characters, except colons. I propose the following change in the context the patch that I am preparing for clarifying the Policy's chapter about control files, in bug #593909. It occurred to me, on reviewing your other patch as well, that this change should probably also say explicitly that field names may not begin with #. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/877hhotm20@windlord.stanford.edu
Bug#598922: apt-cache showsrc prints too many spaces
Julian Andres Klode j...@debian.org writes: The newlines are stripped by dak or dpkg, they are not in the Sources file and APT just displays the sources entry as it. Furthermore, Policy does not state that whitespace should be ignored, only the newlines; so this behavior is correct. That's a bug in Policy which we'll fix (and are already discussing). The following steps seem to be needed to change this: 1. Change Policy 5.6.3 to ignore multiple whitespace after newline Not just after newline. All whitespace is equivalent to a single space anywhere in any folded field. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Names of Fields in Control Files
Raphael Hertzog hert...@debian.org writes: On Sat, 25 Sep 2010, Jonathan Yu wrote: 22:02:40 rra jawnsy: I don't think we say that explicitly, but RFC 5322 requires it and I can't imagine ever not enforcing that. Although you should check with the dpkg maintainers to be sure. Could we/should we make the Debian Policy more restrictive, and specify explicitly that field names must only be ASCII-encoded? [...] Your comments and feedback on this would be much appreciated. I think this discussion is theoretical and useless. I hope nobody will suggest a field name containing non-ascii characters... I suspect there might be a communication problem that made this come across harsher than it was intended. But I'll mention that one of the things that's sometimes frustrating about trying to nail down the specification and standards around Debian's package format is that aspects of standardization that would be considered completely routine in, say, IETF work are considered theoretical and useless. If we were standardizing things in any other context, one of the very first things we'd do is write an ABNF grammar for Debian control fields, which would immediately and unambiguously state the allowed characters for each component. I'm certainly OK with policy requiring field names to be ASCII. I think that's probably the right thing to do. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87aan452dn@windlord.stanford.edu
Bug#163183: Bug#23712: conflicting packages with the same conffile
Raphael Hertzog hert...@debian.org writes: On Fri, 20 Aug 2010, Russ Allbery wrote: + p +A package that declares the same ttconffile/tt as another, +conflicting package may see left-over configuration files from +that other package. EPARSE on this sentence, it looks like some words are missing. Hm. All the words that I had intended to be there are there. I clearly need to rephrase it somehow, though, if it's not clear. How about: When two packages both declare the same ttconffile/tt, they may see left-over configuration files from each other even though they conflict with each other. If a user removes (without purging) one +of the packages and installs the other, the new package will +take over the ttconffile/tt from the old package. If the +file was modified by the user, it will be treated the same as +any other locally modified ttconffile/tt during an +upgrade. + /p -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#163183: Bug#23712: conflicting packages with the same conffile
Raphael Hertzog hert...@debian.org writes: On Wed, 18 Aug 2010, Russ Allbery wrote: What happens if you have a package on the system that's removed but not purged and you install another package (conflicting with the first) that contains the same conffile? I suspect the conffile will be treated as locally modified and the newly installed package will get the conffile from the old removed package, but I'm not sure. The conffile is taken over. The new version of the conffile is installed and overwrites the previous one if it has not been modified (i.e. it matches the md5sum recorded by the original package) otherwise you get the usual prompt and the user decides which version is installed. This happens with or without a Conflicts declaration. We have a bug open against dpkg as well: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=163183 It mainly argues that dpkg should warn that the conffile is transferred and that it should deal correctly with preserving user changes (which it does nowadays apparently). The fact that packages are marked as conflicting will just force apt to remove it first, which means that the remaining conffille can then be taken over even without a Replaces. Given how little problem this behaviour has caused us, we might want as well to document the current behaviour and make it policy rather than changing a behaviour that has not been hurting us. I propose the following patch, which does two things. First, it documents this situation so that package maintainers with conflicting conffiles are aware that they may see this. Second, it reorders the section on sharing configuration files to put all the sharing parts first and talk about conflicts last, both to make the paragraph flow better and because I think we want to encourage people to think about sharing rather than conflicting as their first option. Objections or seconds? diff --git a/policy.sgml b/policy.sgml index 9037de8..5fdf775 100644 --- a/policy.sgml +++ b/policy.sgml @@ -7950,22 +7950,6 @@ ln -fs ../sbin/sendmail debian/tmp/usr/bin/runq headingSharing configuration files/heading p - Packages which specify the same file as a - ttconffile/tt must be tagged as emconflicting/em - with each other. (This is an instance of the general rule - about not sharing files. Note that neither alternatives - nor diversions are likely to be appropriate in this case; - in particular, prgndpkg/prgn does not handle diverted - ttconffile/tts well.) - /p - - p - The maintainer scripts must not alter a ttconffile/tt - of emany/em package, including the one the scripts - belong to. - /p - - p If two or more packages use the same configuration file and it is reasonable for both to be installed at the same time, one of these packages must be defined as @@ -8014,6 +7998,34 @@ ln -fs ../sbin/sendmail debian/tmp/usr/bin/runq and which manages the shared configuration files. (The ttsgml-base/tt package is a good example.) /p + + p + If the configuration file cannot be shared as described above, + the packages must be marked as conflicting with each other. + Two packages that specify the same file as + a ttconffile/tt must conflict. This is an instance of the + general rule about not sharing files. Neither alternatives + nor diversions are likely to be appropriate in this case; in + particular, prgndpkg/prgn does not handle diverted + ttconffile/tts well. + /p + + p + A package that declares the same ttconffile/tt as another, + conflicting package may see left-over configuration files from + that other package. If a user removes (without purging) one + of the packages and installs the other, the new package will + take over the ttconffile/tt from the old package. If the + file was modified by the user, it will be treated the same as + any other locally modified ttconffile/tt during an + upgrade. + /p + + p + The maintainer scripts must not alter a ttconffile/tt + of emany/em package, including the one the scripts + belong to. + /p /sect1 sect1 -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#504880: Disambiguate installed for packages
Steve Langasek vor...@debian.org writes: On Sun, Aug 15, 2010 at 12:25:19PM -0700, Russ Allbery wrote: I believe they can be in the same state as the pre-dependency itself for exactly the same reasons, no? Upgrades don't require deconfiguring packages that depend on the package being upgraded, so if you abort in the middle of upgrading a package the pre-dependency depends on, the pre-dependency is still present and configured on the system, so dpkg will treat the pre-dependency as satisfied. The question is, if you upgrade a package which is a pre-dependency of another package, are any *new* dependencies of that package guaranteed to be unpacked before the package itself is? This seems like a sensible thing for the package manager to enforce, but I don't know if anything does so in practice. I think I've lost track of all the packages here and am not entirely sure what you're describing, but regardless we should probably move this part of things into #593177, which is specifically about this. s/desirable/wanted/? and s/dependend/depended/ :) Seems ok to me. Better than Jonathan's proposed wording, which doesn't read well because there's too much repetition. I might also add at the end: In such situations, the depended-on package should perform an equivalent clean-up operation if it's the first package to be removed or purged. But that may not be unambiguous enough to add any value here and I can't be bothered to further tune the language right now; I don't think that's a blocker and this bug has run quite long enough already. I'm going to bail on that because of the length of the bug; I'd really like to get this merged, since it's blocking resolving a few other bugs that touch the same areas of wording. I think it does read slightly better as two paragraphs. Here's what I have now: p The ttDepends/tt field should also be used if the prgnpostinst/prgn or prgnprerm/prgn scripts require the depended-on package to be unpacked or configured in order to run. In the case of ttpostinst configure/tt, the depended-on packages will be unpacked and configured first. (If both packages are involved in a dependency loop, this might not work as expected; see the explanation a few paragraphs back.) In the case of prgnprerm/prgn or other prgnpostinst/prgn actions, the package dependencies will normally be at least unpacked, but they may be only Half-Installed if a previous upgrade of the dependency failed. /p p Finally, the ttDepends/tt field should be used if the depended-on package is needed by the prgnpostrm/prgn script to fully clean up after the package removal. There is no guarantee that package dependencies will be available when prgnpostrm/prgn is run, but the depended-on package is more likely to be available if the package declares a dependency (particularly in the case of ttpostrm remove/tt). The prgnpostrm/prgn script must gracefully skip actions that require a dependency if that dependency isn't available. /p Does that look okay? -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87vd77dabo@windlord.stanford.edu
Re: Bug#504880: Disambiguate installed for packages
Raphael Hertzog hert...@debian.org writes: On Mon, 26 Jul 2010, Russ Allbery wrote: p The prgnDEBIAN/prgn directory will not appear in the file system archive of the package, and so won't be installed - by prgndpkg/prgn when the package is installed. + by prgndpkg/prgn when the package is unpacked. /p Technically, it's unpacked: not in /DEBIAN but in /var/lib/dpkg/tmp.ci/ and then moved to /var/lib/dpkg/info/package.* at the end of the unpack phase but it's probably not worth pointing out in policy (or only as a footnote). Is this true of all files in the control.tar.gz other than DEBIAN/control, even ones unknown to dpkg? Or does dpkg have an enumerated list of files that it does this with? It does seem like it would be worth documenting /var/lib/dpkg/info somewhere non-normative. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87lj87vhaf@windlord.stanford.edu
Re: Bug#504880: Disambiguate installed for packages
Steve Langasek vor...@debian.org writes: On Wed, Jul 21, 2010 at 01:52:50PM -0700, Russ Allbery wrote: + Sometimes, a package requires another package to be unpacked + emand/em configured before it can be unpacked. In this + case, the dependent package must specify this dependency in + the ttPre-Depends/tt control field. I think depending package is clearer than dependent package, since there's less possibility of confusion with dependency. (The usage dependent package does not currently exist elsewhere in Policy.) Changed. + The package will not yet be unpacked, so + the prgnpreinst/prgn script cannot rely on any files + included in its package. Only essential packages and + pre-dependencies (ttPre-Depends/tt) may be assumed to be + available. Pre-dependencies will be at least unpacked. + They may be only unpacked or Half-Configured, not + completely configured, but only if a previous version of the + pre-dependency was completely configured and the + pre-dependency had not been removed since then. /item Maybe it would be clearer to write it this way? Pre-dependencies will have been configured at least once, but at the time the preinst is called they may only be in an unpacked or Half-Configured state if a previous version of the pre-dependency was completely configured and has not been removed (uninstalled?) since then. Yeah, that looks good to me. Changed. Does dpkg provide any guarantee that the dependencies of the pre-dependency are also present at this point? If it doesn't, I think that should be considered a bug in dpkg, since you may be invoking a command that links against a library whose soname has changed since the last time the pre-dep package was configured. If it /does/ provide this guarantee, I think it should be documented in Policy. I believe they can be in the same state as the pre-dependency itself for exactly the same reasons, no? Upgrades don't require deconfiguring packages that depend on the package being upgraded, so if you abort in the middle of upgrading a package the pre-dependency depends on, the pre-dependency is still present and configured on the system, so dpkg will treat the pre-dependency as satisfied. I've not changed any wording in this area for this bug. + The files contained in the package will be unpacked. All + package dependencies will at least be unpacked. If there + are no circular dependencies involved, all package + dependencies will be configured. /item Should this include a pointer to the section documenting the rules for breaking circular dependencies? Added a reference. + unpacked in some error situations.footnote +For example, suppose packages foo and bar are installed +with foo depending on bar. If an upgrade of bar were +started and then aborted, and then an attempt to remove +foo failed because its prgnprerm/prgn script failed, +foo's ttpostinst abort-remove/tt would be called with +bar only Half-Installed. + /footnote /item - /list + /taglist +/p This footnote is interesting to me because although it accurately documents dpkg's behavior, I'm not sure what implications it has for how packages should guard against this case. I think I've always ignored this possibility in my maintainer scripts, and will continue to do so on the grounds that any attempt to handle this gracefully is likely to introduce much greater complexity (and therefore bugs) with very little upside (when all is said and done, a package you were trying to remove is still installed, so do we care if it configures successfully?) If we can make a straightforward recommendation to maintainers for how to handle this case, I think we should include that in the footnote. Otherwise, if it shouldn't affect how we write maintainer scripts, perhaps it's better not to have this footnote at all since it would only lead to maintainers trying to be too clever and shooting themselves in the foot? I think we should put it in the main text. I've now added, after the footnote and in the main text: The prgnpostinst/prgn should still attempt any actions for which its dependencies are required, since they will normally be available, but consider the correct error handling approach if those actions fail. Aborting the prgnpostinst/prgn action if commands or facilities from the package dependencies are not available is often the best approach. which I think is roughly what you're doing and what most people are doing and which I think is the generally best approach. + The prgnpostrm/prgn script is called after the package's
Re: Bug#504880: Disambiguate installed for packages
be called if an upgrade fails. However, this happens during the critical time when a shared libs may exist on-disk @@ -5536,7 +5652,7 @@ Replaces: mail-transport-agent ref id=conflicts) to ensure that the user only installs one development version at a time (as different development versions are likely to have the same header files in them, which would cause a - filename clash if both were installed). + filename clash if both were unpacked). /p p @@ -9858,7 +9974,7 @@ END-INFO-DIR-ENTRY p The prgnDEBIAN/prgn directory will not appear in the file system archive of the package, and so won't be installed - by prgndpkg/prgn when the package is installed. + by prgndpkg/prgn when the package is unpacked. /p p -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87d3tjvfmm@windlord.stanford.edu
Bug#592839: dpkg-source option to remove files on unpack: debian/source/remove-files
Raphael Hertzog hert...@debian.org writes: As suggested by Ian on -devel (see attachment), it would be nice to have a way to remove files during unpack of a source package to hide non-free files from our users without stripping them from the original tarball. I also prefer this approach over repacking upstream files so let's implement this feature. I'm pretty sure ftp-master isn't going to allow source packages with non-free content in the main archive regardless of whether that content is hidden on unpack (I certainly wouldn't if I were them), so implementing this is kind of pointless for Debian. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#504880: Disambiguate installed for packages
Steve Langasek vor...@debian.org writes: I don't think it's a whoops, but it is true that Breaks is asymmetric and it's specifically the /broken/ package that is deconfigured when the /breaking/ package is unpacked, and I think Policy should be clear about this. (Yes, the fact that the package manager normally proceeds to remove the broken package is an apt policy, not Policy.) So I think it's better to say: This is a stronger restriction than ttBreaks/tt, which just prevents the package listed in the Breaks field from being configured while the package with the Breaks field is present on the system. Avoids referring to packages listed in Breaks as 'broken', which it seems we're trying to do even though we use the common English verbs throughout Policy for the other relationship fields; and avoids the ambiguous is unpacked where what we really mean is the much more bulky is in an unpacked state. The whole thing comes out pretty awkward for all that, but I have no ideas on further improving it. I now have: p When one binary package declares a conflict with another using a ttConflicts/tt field, prgndpkg/prgn will refuse to allow them to be unpacked on the system at the same time. This is a stronger restriction than ttBreaks/tt, which prevents the broken package from being configured while the breaking package is in the Unpacked state but allows both packages to be unpacked at the same time. /p We do use breaking and broken elsewhere in Policy with respect to the Breaks header, so I felt comfortable using them here. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/871vaqx6w3@windlord.stanford.edu
Re: Bug#504880: Disambiguate installed for packages
Jonathan Nieder jrnie...@gmail.com writes: Russ Allbery wrote: I found the original awkward and hard to puzzle out. How about this: p Since ttDepends/tt only places requirements on the order in which packages are configured, packages in an installation run are usually all unpacked first and all configured later. [*]This allows multiple packages to be upgraded in one unpack and configure step even if some packages being upgraded have versioned dependencies on the upgraded versions of other packages involved in the installation run. /p The rationale makes sense. The second sentence, which I have marked with *, is getting a bit long and still does not have the charm of the original. How about this: p Since ttDepends/tt only places requirements on the order in which packages are configured, packages in an installation run are usually all unpacked first and all configured later. footnote This approach makes dependency resolution easier. If two packages A and B are being upgraded, the installed package A depends on exactly the installed package B, and the new package A depends on exactly the new package B (a common situation when upgrading shared libraries and their corresponding development packages), satisfying the dependencies at every stage of the upgrade would be impossible. This relaxed restriction means that both new packages can be unpacked together and then configured in their dependency order. /footnote /p That moves the whole thing into a footnote and gives a more specific example. In the case of prgnprerm/prgn or other prgnpostinst/prgn actions, the package dependencies will be at least unpacked or Half-Installed. Again, it will have been unpacked at some version and not removed since then, right? A very careful person can take advantage of that. Stealing your wording from elsewhere: In the case of prgnprerm/prgn or other prgnpostinst/prgn actions, the package dependencies will be at least unpacked, except they may be only Half-Installed if an upgrade of the dependency failed. I now have: In the case of prgnprerm/prgn or other prgnpostinst/prgn actions, the package dependencies will normally be at least unpacked, but they may be only Half-Installed if a previous upgrade of the dependency failed. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87sk35x6qr@windlord.stanford.edu
Re: Bug#504880: Disambiguate installed for packages
+4789,7 @@ Build-Depends: foo [linux-any], bar [any-i386], baz [!linux-any] p When one binary package declares that it breaks another, prgndpkg/prgn will refuse to allow the package which - declares ttBreaks/tt be installed unless the broken + declares ttBreaks/tt be unpacked unless the broken package is deconfigured first, and it will refuse to allow the broken package to be reconfigured. /p @@ -4756,18 +4840,18 @@ Build-Depends: foo [linux-any], bar [any-i386], baz [!linux-any] headingConflicting binary packages - ttConflicts/tt/heading p - When one binary package declares a conflict with another - using a ttConflicts/tt field, prgndpkg/prgn will - refuse to allow them to be installed on the system at the - same time. This is a stronger restriction than ttBreaks/tt, - which just prevents both packages from being configured at the - same time. Conflicting packages cannot be unpacked on the - system at the same time. + When one binary package declares a conflict with another using + a ttConflicts/tt field, prgndpkg/prgn will refuse to + allow them to be unpacked on the system at the same time. This + is a stronger restriction than ttBreaks/tt, which prevents + the broken package from being configured while the breaking + package is in the Unpacked state but allows both packages to + be unpacked at the same time. /p p - If one package is to be installed, the other must be removed - first. If the package being installed is marked as replacing + If one package is to be unpacked, the other must be removed + first. If the package being unpacked is marked as replacing (see ref id=replaces, but note that ttBreaks/tt should normally be used in this case) the one on the system, or the one on the system is marked as deselected, or both packages are @@ -4816,7 +4900,7 @@ Build-Depends: foo [linux-any], bar [any-i386], baz [!linux-any] itemwhen two packages provide the same file and will continue to do so,/item itemin conjunction with ttProvides/tt when only one - package providing a given virtual facility may be installed + package providing a given virtual facility may be unpacked at a time (see ref id=virtual),/item itemin other cases where one must prevent simultaneous installation of two packages for reasons that are ongoing @@ -5048,7 +5132,7 @@ Provides: mail-transport-agent Conflicts: mail-transport-agent Replaces: mail-transport-agent /example - ensuring that only one MTA can be installed at any one + ensuring that only one MTA can be unpacked at any one time. See ref id=virtual for more information about this example. /sect1 @@ -5347,7 +5431,7 @@ Replaces: mail-transport-agent footnote p During install or upgrade, the preinst is called before - the new files are installed, so calling ldconfig is + the new files are unpacked, so calling ldconfig is pointless. The preinst of an existing package can also be called if an upgrade fails. However, this happens during the critical time when a shared libs may exist on-disk @@ -5492,7 +5576,7 @@ Replaces: mail-transport-agent ref id=conflicts) to ensure that the user only installs one development version at a time (as different development versions are likely to have the same header files in them, which would cause a - filename clash if both were installed). + filename clash if both were unpacked). /p p @@ -9814,7 +9898,7 @@ END-INFO-DIR-ENTRY p The prgnDEBIAN/prgn directory will not appear in the file system archive of the package, and so won't be installed - by prgndpkg/prgn when the package is installed. + by prgndpkg/prgn when the package is unpacked. /p p -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ocdtx6j5@windlord.stanford.edu
Re: Bug#504880: Disambiguate installed for packages
Jonathan Nieder jrnie...@gmail.com writes: Russ Allbery wrote: I think we should hopefully be close to a final wording now. Indeed! All I have left are copy-edits (patch below). Thanks! Applied to my copy. @@ -5048,7 +5132,7 @@ Provides: mail-transport-agent Conflicts: mail-transport-agent Replaces: mail-transport-agent /example -ensuring that only one MTA can be installed at any one +ensuring that only one MTA can be unpacked at any one time. See ref id=virtual for more information about this example. /sect1 Aside: is this advice right? Maybe we should be encouraging Provides: mail-transport-agent Breaks: mail-transport-agent Replaces: mail-transport-agent instead. Policy 11.6 requires that any package providing mail-transport-agent install /usr/sbin/sendmail and provide a program called newaliases, and hence they really do need Conflicts: /etc/aliases is the source file for the system mail aliases (e.g., postmaster, usenet, etc.), it is the one which the sysadmin and postinst scripts may edit. After /etc/aliases is edited the program or human editing it must call newaliases. All MTA packages must come with a newaliases program, even if it does nothing, but older MTA packages did not do this so programs should not fail if newaliases cannot be found. Note that because of this, all MTA packages must have Provides, Conflicts and Replaces: mail-transport-agent control fields. The problem with using alternatives here is that the sendmail and newaliases programs have to match whatever MTA is actually being used, since bad things could happen (like losing data) if the alternative points to one MTA but a different MTA is actually running. Alternatives don't really provide a good way of making those things line up, so what we've historically done is make all the mail-transport-agent providers just ship those binaries in those paths and conflict with each other. That prevents installing more than one MTA at the same time, which could occasionally be useful, but ensures that everything installed is consistent and works together. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87iq41vpel@windlord.stanford.edu
Re: mail-transport-agent (Re: Bug#504880: Disambiguate installed for packages)
Jonathan Nieder jrnie...@gmail.com writes: If we instead take the Conflicts seriously, then switching between MTAs requires the following sequences of events: deconfigure packages that pre-depend or depend on mail-transport-agent remove the old mail-transport-agent unpack the new mail-transport-agent configure in the appropriate order This looks like an awfully slow way to accomplish a task that would probably be dealt with better by triggering on /etc/aliases. But that is probably something to propose for squeeze+2 or so. I think what happens in practice in this case is that apt calls dpkg with some --force-* flag, or at least that's what the messages that I've seen scroll by in this sort of situation seem to imply. I agree that it would be good to have a better way of handling it (although also agree that's a different bug than this one). -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87hbjl7qy9@windlord.stanford.edu
Re: Bug#504880: Disambiguate installed for packages
Thank you very much for the detailed review! Jonathan Nieder jrnie...@gmail.com writes: Russ Allbery wrote: p + What follows is a summary of all the ways in which maintainer + scripts may be called along with what facilities those scripts + may rely on being available at that time. Script names + preceeded by varnew-/var are the scripts from the new + version of a package being installed or upgraded. Script names + preceeded by varold-/var are the scripts from the old + version of a package that is being upgraded to a new version. +/p Spelling: “preceeded” should be “preceded”. Fixed. The term “upgraded” is a bit ambiguous in situations where a package is being downgraded or an upgrade is being rolled back. Probably the context makes the meaning obvious in any particular instance, though. I now have: p What follows is a summary of all the ways in which maintainer scripts may be called along with what facilities those scripts may rely on being available at that time. Script names preceded by varnew-/var are the scripts from the new version of a package being installed, upgraded to, or downgraded to. Script names preceded by varold-/var are the scripts from the old version of a package that is being upgraded from or downgraded from. /p to mention downgrades. The meaning of new and old of course doesn't change even during error unwind, but hopefully that's still clear from context. + Only essential packages and pre-dependencies + (ttPre-Depends/tt) may be assumed to be available. + Pre-dependencies will either be configured or will be + Unpacked or Half-Configured but previously had been + configured and was never removed. The second sentence is starting to get wordy. Maybe: Only essential packages and pre-dependencies (ttPre-Depends/tt) may be assumed to be available. Pre-dependencies will be unpacked and have been configured after they were last removed[1]. [1] During an upgrade, a package listed in ttPre-Depends/tt may be Unpacked or Half-Configured in its new version, but only if a previous version was configured completely and the package has not been removed since then. I don't want to move state information into a footnote. Here's a new version that is hopefully a bit cleaner: item The package will not yet be unpacked, so the prgnpreinst/prgn script cannot rely on any files included in its package. Only essential packages and pre-dependencies (ttPre-Depends/tt) may be assumed to be available. Pre-dependencies will be at least unpacked. They may be only unpacked or Half-Configured, not completely configured, but only if a previous version of the pre-dependency was completely configured and the pre-dependency had not been removed since then. /item I doubt these rules apply to the initial bootstrap. Is that worth mentioning somewhere? I don't think so. Initial bootstrap, like udebs, feels to me like something that's outside the intended scope of Policy. + Called during error handling of an upgrade that failed after + unpacking the new package because the + old prgnpostrm/prgn failed during the upgrade action. Getting wordy. Maybe: Called to recover from an upgrade that failed after unpacking the new package because the old prgnpostrm/prgn failed. The point that I'm trying to get at here is that it's specifically postrm upgrade that failed. I reworded it some -- see below. + Depending on the severity and nature of the error, the + package's dependencies, including pre-dependencies, may be + only Half-Installed or Unpacked and are not necessarily + configured, and the files for the old package may not yet be + unpacked. * Not sure what the phrase “Depending on the ... nature of the error” is supposed to be getting at here. Is this just to say the package might not have been fully installed yet? I would leave the clause out. Reworded to leave that out. * Can’t (new) dependencies be missing altogether? I thought part of the point of the pre-depends/depends distinction was that the latter does not constrain unpacking order. I believe unpacking order is still constrained, but the unpacked packages don't have to be fully configured before the depending package is unpacked. With Pre-Depends, the dependency is fully configured before the depending package is unpacked. However, you're right, I don't think anything guarantees that the dependencies are available at this point, only the pre-dependencies. * postrm does not get called
Re: Bug#504880: Disambiguate installed for packages
Russ Allbery r...@debian.org writes: Please review in detail, as this is the first documentation we'll have of several hairy assumptions involved in maintainer script dependencies. Here is an updated patch reflecting feedback from Ben Finney and Jonathan Nieder. diff --git a/policy.sgml b/policy.sgml index 847f716..eb458fe 100644 --- a/policy.sgml +++ b/policy.sgml @@ -1079,10 +1079,10 @@ /p p - Sometimes, a package requires another package to be installed - emand/em configured before it can be installed. In this - case, you must specify a ttPre-Depends/tt entry for - the package. + Sometimes, a package requires another package to be unpacked + emand/em configured before it can be unpacked. In this + case, the dependent package must specify this dependency in + the ttPre-Depends/tt control field. /p p @@ -3674,7 +3674,7 @@ Checksums-Sha256: p Broadly speaking the prgnpreinst/prgn is called before - (a particular version of) a package is installed, and the + (a particular version of) a package is unpacked, and the prgnpostinst/prgn afterwards; the prgnprerm/prgn before (a version of) a package is removed and the prgnpostrm/prgn afterwards. @@ -3758,111 +3758,173 @@ Checksums-Sha256: /heading p - list compact=compact - item - varnew-preinst/var ttinstall/tt - /item - item - varnew-preinst/var ttinstall/tt varold-version/var - /item - item - varnew-preinst/var ttupgrade/tt varold-version/var - /item - item - varold-preinst/var ttabort-upgrade/tt - varnew-version/var - /item - /list + What follows is a summary of all the ways in which maintainer + scripts may be called along with what facilities those scripts + may rely on being available at that time. Script names preceded + by varnew-/var are the scripts from the new version of a + package being installed, upgraded to, or downgraded to. Script + names preceded by varold-/var are the scripts from the old + version of a package that is being upgraded from or downgraded + from. + /p p - list compact=compact - item - varpostinst/var ttconfigure/tt - varmost-recently-configured-version/var - /item - item - varold-postinst/var ttabort-upgrade/tt - varnew-version/var - /item - item - varconflictor's-postinst/var ttabort-remove/tt - ttin-favour/tt varpackage/var - varnew-version/var - /item + The prgnpreinst/prgn script may be called in the following + ways: + taglist + tagvarnew-preinst/var ttinstall/tt/tag + tagvarnew-preinst/var ttinstall/tt + varold-version/var/tag + tagvarnew-preinst/var ttupgrade/tt + varold-version/var/tag item - varpostinst/var ttabort-remove/tt + The package will not yet be unpacked, so + the prgnpreinst/prgn script cannot rely on any files + included in its package. Only essential packages and + pre-dependencies (ttPre-Depends/tt) may be assumed to be + available. Pre-dependencies will be at least unpacked. + They may be only unpacked or Half-Configured, not + completely configured, but only if a previous version of the + pre-dependency was completely configured and the + pre-dependency had not been removed since then. /item + + tagvarold-preinst/var ttabort-upgrade/tt + varnew-version/var/tag item - vardeconfigured's-postinst/var - ttabort-deconfigure/tt ttin-favour/tt - varfailed-install-package/var varversion/var - [ttremoving/tt varconflicting-package/var - varversion/var] + Called during error handling of an upgrade that failed after + unpacking the new package because the ttpostrm + upgrade/tt action failed. The unpacked files may be + partly from the new version or partly missing, so the script + cannot not rely on files included in the package. Package + dependencies may not be available. Pre-dependencies will be + at least unpacked following the same rules as above, except + they may be only Half-Installed if an upgrade of the + pre-dependency failed. /item - /list + /taglist + /p p - list compact=compact - item - varprerm/var
