Re: APT do not work with Squid as a proxy because of pipelining default
On Wed, May 19, 2010 at 03:28:00PM +0200, Bjørn Mork was heard to say: > Pierre Habouzit writes: > > This is bullshit. It's *VERY* easy to "support" pipelining: parse one > > request at a time, and until you're done with a given request, you just > > stop to watch the socket/file-descriptor for reading (IOW you let the > > consecutive request live in the kernel buffers). > > Yeah, you make it sound easy. I'm sure those writing proxy servers are > just stupid. There are lots of easy features that my own software doesn't support, and I don't think I'm particularly stupid. It just means I have less than an infinite amount of time. Daniel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100520010845.ga16...@emurlahn.burrows.local
Re: [RFC] DEP-6: Meta-Package debian/control field
I agree with Eugene: the spec as presented is flawed. All package management tools (you forgot to list dpkg) treat Depends-satisfaction as an invariant, and there isn't really a compelling reason for this to change. The wording you present is a little confusing, but once you work through it, it's clear that it says "treat Depends on this package like Recommends". Except that there may be an "unless you don't" tagged on. I actually would prefer a Meta-Depends sort of solution. The "dependencies" we're talking about are really not package dependencies in the normal sense at all, and we shouldn't be confusing them with normal dependencies. IMO, that basic conflation, while a convenient and expedient hack when it was introduced years ago, is the cause of our troubles. Arguably, your Meta-Package proposal really says "change all Depends to Meta-Depends if Meta-Package is true". However, I don't like making the meaning of Depends dependent (hah) on another package field, or overloading the meaning of such a basic part of the package system. For instance, dpkg shouldn't care about metapackages at all (IMO), any more than it cares about Recommends; this is a high-level concept that doesn't have to do with guaranteed relationships among installed packages. I also don't like the definition of Meta-Depends as "like Depends, except "; I think that the behavior and intention of Meta-Depends are different enough that they should be described explicitly. To summarize: if we're going to introduce a new package relationship, I'd like to see us do it right and up-front rather than "on the cheap" with a hack we'll have to live with for years. (I apologize for not including my own proposal in this mail, due to it suffering from an acute case of non-existence; if I have time I will write one, but please don't count on that what with holidays and real life and all) Cheers, Daniel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#551992: general: stopping squeeze chroot shuts system
On Thu, Oct 22, 2009 at 02:16:39PM +0200, Martin Boer was heard to say: > On this system I installed a squeeze chroot using the following command: > > debootstrap squeeze /chroot/squeeze-x64-lighttpd-chroot > http://ftp.debian.org/debian/ > > This works as expected but when I stop the chroot, the system shuts as well. > This is highly unexpected and somewhat unpleasant behaviour. By "stop the chroot", do you mean that you typed "exit" in the chrooted shell, or that you ran "shutdown -h" there? Daniel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: fstrcmp
On Tue, Jun 02, 2009 at 02:32:06PM +0200, Jérôme Pouiller was heard to say: > In another thread, Adeodato Simó wrote: > > I can't see how it'd work here, at least without the help of some > > on-disk structure, since we're talking about a space of 25,000 > > packages. > > Naive search of matching string under a set of 25,000 strings is > something like 2000 times slower (maybe far more) than a correct > algorithm. Adeodato thinks it is not usable. I said we shouldn't reject > idea because of performances and I suggested a better algorithm should > be used. aptitude already scans every package regularly. For instance, when you ask it to install something that doesn't exist, it checks every package name using a naive substring algorithm. According to "time", this takes 1.5 to 1.7 seconds on my computer, most of which appears to be spent initializing the program. Fuzzy matches are more expensive, of course. It might even be interesting to just do an edit distance computation up to k=1 and see how that performed, though; I bet it would be reasonable with some mild optimization. Daniel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Possible mass bug filing: non-doc packages recommending doc packages
On Fri, May 08, 2009 at 06:55:43PM +0200, Stefano Zacchiroli was heard to say: > I don't think that the mere fact that we changed the default behavior > of apt-get/aptitude should get in the way of that maintainer's > choice. If we used to live in a world where, by maintainer choice, doc > was not installed by default, that world should IMO stay the same. aptitude's behavior was "changed" in 2001. It was changed because Recommends has always meant that the package manager should automatically select the recommended package when the recommending package was selected. Daniel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Possible mass bug filing: non-doc packages recommending doc packages
On Fri, May 08, 2009 at 02:58:56PM -0700, Russ Allbery was heard to say: > > I think that lintian warning is the right way to do it. > > I don't -- I think there are too many false positives for a lintian > warning given the thread. I also think this is fundamentally going in > the wrong direction. Wouldn't our users expect to get the documentation > with many of these packages by default? Normally you do get some > documentation with things, and I've always been surprised by, say, ntp > not including any documentation without installing a separate package. I agree with this. I consider installing a program and *not* installing its documentation to be an unusual situation, and if this bug is filed I will treat it as a request to make my packages worse. aptitude-doc is split out to save archive space and as a feature for users who want to save a few megabytes by removing the user manual, not because I want to force users to jump through hoops to get documentation on their system. Daniel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Possible mass bug filing: non-doc packages recommending doc packages
On Fri, May 08, 2009 at 06:49:38PM +0200, Stefano Zacchiroli was heard to say: > On Thu, May 07, 2009 at 09:47:56PM -0700, Daniel Burrows wrote: > > As a practical matter, downgrading these dependencies will cause > > aptitude and other package managers to believe that the documentation > > is unnecessary and suggest removing it. > > Even if the user marked as non-automatic the involved -doc packages? No, but I doubt more than a handful of users have done this. > Also, I see no other way of doing that transition ... Do you have any > aptitude-fu suggestion? :) $ aptitude unmarkauto "~n-doc$" Daniel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Possible mass bug filing: non-doc packages recommending doc packages
As a practical matter, downgrading these dependencies will cause aptitude and other package managers to believe that the documentation is unnecessary and suggest removing it. Daniel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Consistent formating long descriptions as input data
On Sat, Apr 25, 2009 at 10:12:45PM +0200, Andreas Tille was heard to say: > On Sat, 25 Apr 2009, Daniel Burrows wrote: > >> I would prefer Restructured Text, for the simple reason that it has an >> actual specification with a fairly complete description of its syntax >> and semantics. > > I do not have practical experience with both and so I do not have > any preference. The only thing I'f fear is that we might loose track > in finally solving the problem in discussing which library to use. > So do you think I should try to switch from markdown to reST in the > debug output project? I hesitate to tell you what to do, since I'm not the one doing the work. But I think it would be worthwhile to at least prototype both options and see how they stack up. I also should say that I only have practical experience with Markdown (except that I've edited Wikis occasionally and some of them use RST); the alternative looks better to me, but it's easy to say that when I haven't actually used it. :-) > For those who are interested: At > > http://blends.debian.net/debug/tasks/ Wow, that's a lot of work! I certainly won't ask you to do it all over again. Daniel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Consistent formating long descriptions as input data
On Fri, Apr 24, 2009 at 08:37:22AM +0200, Andreas Tille was heard to say: >>> 2. Markdown is probably better in detecting second level lists >>> thank I would have done it programmatically - so here is >>> a benefit. On the other hand there are some strange false >>> positives for second level lists. >> >>These should be something we can look at to provide a policy >> recommendation so these false positives can be reduced. > > Yes, that's the idea. On the other hand looking at some examples > I have the feeling that sometime markup has a strange way to handle > some lists. I'll come up with examples once I implemented the > "Remarks feature" so you can easily see what I mean. One example is the patch I just committed to the online aptitude release notes to fix a weird Markup problem. I've attached it for illustration. The solution ended up being to indent every paragraph of a bullet beyond the first one by an extra space. If you don't do this, Markdown becomes extremely confused about the status of sub-lists: it sometimes tries to break out of the top-level list and display them as new lists, sometimes it makes the second sub-item (but no other sub-items) a child of the first sub-item, etc. I would prefer Restructured Text, for the simple reason that it has an actual specification with a fairly complete description of its syntax and semantics. In constrast, I've never been able to find any useful documentation of Markdown beyond "what /usr/bin/markdown does". Having a decent spec makes it a lot easier to implement alternate parsers or to understand why the canonical parser is doing an unexpected thing with your input. Compare, for instance: http://docutils.sourceforge.net/docs/ref/rst/restructuredtext.html http://daringfireball.net/projects/markdown/syntax One manifestation of this: I can't tell you if the behavior I described regarding nested lists matches the Markdown documentation or not, because the Markdown syntax documentation doesn't even mention nested lists, let alone define how exactly they should be written in a Markdown document. I guess maybe you could say they're undefined and the processor will do whatever it does? :-/ In the RST spec this is described in the section labeled "Indentation". Daniel commit 95e90bf80d8313aa21e1731f2687e3f4c0c853dd Author: Daniel Burrows Date: Sat Apr 25 10:40:39 2009 -0700 Fix the formatting of the show-summary information. diff --git a/wiki/projects/aptitude/news/aptitude-0.5.2-release-notes.mdwn b/wiki/projects/aptitude/news/aptitude-0.5.2-release-notes.mdwn index d29e3e7..e4d9abb 100644 --- a/wiki/projects/aptitude/news/aptitude-0.5.2-release-notes.mdwn +++ b/wiki/projects/aptitude/news/aptitude-0.5.2-release-notes.mdwn @@ -66,54 +66,47 @@ also includes major changes to the dependency solver. [[!img aptitude-0.5.2-fix-upgrade-manually.png size="400x400"]] + **\[cmdline]** Added a new command-line option, - `--show-summary`, to the `why` - command-line action. This option causes aptitude to - show a brief list of the first package in each - dependency chain that would have been displayed. - Dependency chains that contain Suggests are not - displayed, so combining this option with `-v` will cause - aptitude to display all the packages that require the - target. - - Documentation for this feature is currently missing. - The `--show-summary` option accepts an optional argument - giving the summary mode: - - - `no-summary`: don't show a summary. - - - `last-package`: only show the last package in each - chain; that is, either the manually installed package - that requires the target package, or the package you - selected from the command-line. This is the default - if `--show-summary` is used with no argument. In - future releases of aptitude this will be - `first-package`, since that name makes a lot more - sense. - - - `last-package-and-type`: display the last package in -each chain, along with an indication of the strength -of the chain. - - - `all-packages`: briefly display each chain of packages - in its entirety. - - - `all-packages-with-dep-versions`: briefly display each - chain of packages in its entirety, along with the - version constraint, if any, of each dependency. - - The configuration option - `Aptitude::CmdLine::Why-Display-Mode` can be set to any - value that `--show-summary` accepts; if `--show-summary` - is present on the command-line, it overrides this option. - In future releases of aptit
Re: Consistent formating long descriptions as input data (Was: RFC: Better formatting for long descriptions)
On Tue, Apr 21, 2009 at 09:31:31AM +0200, Andreas Tille was heard to say: > Moreover I see no reason to bind anybody to a certain library > like markdown. My experience has shown that people will insist > on their very own way to do things. Do you think apt, aptitude, > synaptic etc. developers would be happy if you start filing bug > reports to make them use markdown? So my suggestion leaves > perfectly space for using markdown as well as even raw text > output - which would look also better with consistent formatting. I'm happy to support whatever markup language people want to use. My only concern with markdown is that I use it for my blog, and I periodically run into weird cases where the formatting doesn't work as expected. It seems to be especially bad when you start nesting formatting elements inside each other (quoted text inside a list inside a list is one example I found in the past). I've made a Markdown version of the release notes for aptitude releases for the last year or so and I always seem to find myself randomly adjusting indents until it stops producing the wrong HTML. For the sorts of markup our descriptions have now it'll be fine, but it's my experience that when you give people a hammer they start hitting everything that's vaguely nail-shaped with it. :-) But if people want to use markdown, I'll render it. Daniel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#522142: ITP: Qoreutils -- Coreutils reimplemented using Qt libraries
On Wed, Apr 01, 2009 at 06:54:22PM +0200, "Milan P. Stanic" was heard to say: > On Wed, 2009-04-01 at 09:09, Mike Bird wrote: > > On Wed April 1 2009 00:03:10 Sune Vuorela wrote: > > > Qoreutils is a reimplementation of the classic tools from coreutils, > > > such as ls, mkdir and cp > > Thanks but this won't be necessary. We just uploaded a GCC patch > > that converts coreutils to use Qt. No source changes are needed. > > Sorry for my ignorance, but what does that mean? We will have to install > libqt always? It means you need to read the Date: header. :-) Daniel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFC: Better formatting for long descriptions
I don't have the energy to push this any more, but I should probably at least refer to my previous attempt to standardize bulleted lists: http://lists.debian.org/debian-devel/2005/12/msg00531.html You might find it useful, or not. At least it more or less documents current practice in aptitude (I think there have been some tweaks since then; if anyone cares I could go research what they are and dig them up). Daniel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: -dbg packages; are they actually useful?
I doubt most users will install them on their own, but I've found them to be moderately useful in tracking down crashes. It's easier to convince people to install a -dbg package than to convince them to recompile the program from source. Daniel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: incapable and obsolete APT / Aptitude replacement
On Mon, Feb 09, 2009 at 09:37:29PM -0800, Daniel Burrows was heard to say: > I made early on was not to fetishize arbitrary "optimality" definitions, > because you can end up chasing phantoms that way. "Optimal" solutions > are not necessarily best. They are good for academic projects, though, > because you can easily "grade" yourself on whether you're doing a good > job and write papers about what a good job you did. ;-) This has been bothering me all night, so I'd better explain myself more or it will bother me all day. :-) Academics like to completely analyze and understand problems and their solutions. This is good. I like doing it myself. It does, however, bias you in favor of solutions that can be completely understood and analyzed. If they have a problem that's hard to analyze, there's a tendency to replace it with a similar problem that they know how to analyze; for instance, problems in programming language design are often tackled by trying to find better and better ways to express trivial little computational problems. Sometimes that gets you a good answer; sometimes it gets you an OK answer and sheds light on how to design more practical solutions; sometimes it gets you a programming language that's *really, really good* at writing the factorial function and nothing else. Part of the problem is that you don't know where you'll end up with this approach until you try, which is why we call it "research". Anyway, I didn't mean to suggest that their approach was bad; just that it's not the only way. (and really, if I had the time, I'd probably be doing the same thing they are; my coding process is mainly optimized around fitting my work into about 10 hours a week, average) Daniel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: incapable and obsolete APT / Aptitude replacement
On Mon, Feb 09, 2009 at 12:59:49PM +0100, kc.ubuntu...@centrum.cz was heard to
say:
> I would like to ask you a little bit controversal question. As a user I miss
> a package manager based on powerfull dependency solver. Using APT in
> DEB-based distributions, I can easilly create some kind of problem, APT is
> unable to solve. This is because the APT is the worst dependency solver
> almost ever invented. Proof can be found here:
The biggest problem with apt's dependency solver is that it can't
conceive of anything other than the current and candidate versions.
That alone renders it useless for anything but trivial circumstances.
Unfortunately, because it's all heuristic, you need to throw the
resolver out and rewrite from scratch to lift that restriction.
> http://www.mancoosi.org/edos/manager.html
The claim that aptitude can't handle this is utter bunk. Out of
curiosity, I typed the first one on that page down in the minimalist
syntax I use to test the aptitude resolver. (attached) It passed:
dan...@emurlahn:~/programming/aptitude/post-lenny/src/generic/problemresolver$
./test testcarglass.txt
(snip lots of cruft)
--- Found solution ;[];460
Would eliminate stupid, but stupid elimination is disabled.
Inserting conflict {engine := engine v2, wheel := wheel v3, tyre := tyre v2,
door := door v2, window := window v0}
*** Converged after 7 steps.
--- Found solution ;[];470
Would eliminate stupid, but stupid elimination is disabled.
Inserting conflict {engine := engine v2, wheel := wheel v3, tyre := tyre v2,
door := door v2, window := window v1, glass := glass v1}
*** Converged after 2 steps.
--- Found solution ;[];470
Would eliminate stupid, but stupid elimination is disabled.
Inserting conflict {engine := engine v2, wheel := wheel v3, tyre := tyre v1,
door := door v2, window := window v2, glass := glass v2}
*** Converged after 3 steps.
It didn't find the most "optimal" answer first because, as far as I
can tell, it considered the precursor to the "optimal" answer to be
equivalent to a "less optimal" answer, and preferred immediately
returning a result vs continuing to search in the hope of finding a
better one. Which reminds me, I have a feature request to keep
running for a "few" (maybe 50) steps past the first answer in search
of a better one...
Anyway, I don't consider that a big deal. One of the design decisions
I made early on was not to fetishize arbitrary "optimality" definitions,
because you can end up chasing phantoms that way. "Optimal" solutions
are not necessarily best. They are good for academic projects, though,
because you can easily "grade" yourself on whether you're doing a good
job and write papers about what a good job you did. ;-) (please note
that I say that only half-mockingly; I'd love to be paid to work on
this stuff, and playing the academia game seems to be one route these
days; this stuff wasn't taken seriously when I was in school because it
was "just for hobbyists" :-( )
Single-criterion tests like this are also a problem because for big
and complicated problems like this, you really need an overall picture
of what sort of results you're getting on a wide variety of inputs. At
my paid job, one of my projects was working on code to match input text
blocks against a database of postal addresses. You might think that
would be easy, but when you get to 30 million addresses it gets a bit
tricky...
Anyway, one thing you learn quickly is that you can make a change to
fix one address that's sitting in front of you, and 50 other addresses
suddenly go from producing a correct answer to producing a wrong answer.
It's like trying to flatten a bumpy rug -- push it down in one place
and three more pop up. You won't make any progress unless you have a
broad picture of whether you're actually doing better or not. Package
management is a lot like that, and I prefer to go by the fact that I
only have a handful of bug reports telling me that aptitude totally
failed on some inputs or others.
BTW, did you read this note at the bottom of the page?
> The content of this chapter should in no way be construed as a
> criticism of the tools we analysed: they do try to solve a much
> harder problem than ours, and they really try their best at it,
> handling all the added complexity of the extra bits of metadata
> associated to package management: we know of no satisfactory
> solution for this problem up to now, and our tools are not a
> replacement for Apt, Protage, Urpmi, Smart and the like.
> I made some personal test, to compare the solver capabilities myself. I add
> KDE 4.2 repository to SUSE and Ubuntu, and made an upgrade from 4.1.3 to 4.2.
> After that i disabled KDE 4.2 repositories and delete one of the KDE 4.2
> packages. This lead to inconsistent state, because KDE 4.2 repository was
> unavailable to repaire the dependency. The solution is obvious. Donwgrade
> somepackages back to KDE 4.1.3, to m
Re: Sections - especially section:kde and section:gnome
On Wed, Jan 07, 2009 at 08:32:24AM +0100, Joerg Jaspert was heard to say: > > > I don't remember using sections in over 4 years of Debian usage, though > > I had already used GNU/Linux for a few months before I switched to > > Debian. But I doubt even a user new to GNU/Linux would use them much. > > Everyone that uses a tool like aptitude does use them much. I guess > similar is true for a graphical ting like synaptic and whatnot else we > have. Using sections to break up the package list is an artifact of 2000, when it actually made sense. With the number of packages in the archive now it no longer really makes sense to use sections, and they will probably go away (at least as the default view) at some point in the future, in favor of searches on keywords and tags. Daniel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Adoption of Nix?
Hi there. As I'm sure everyone knows, I'm not exactly unbiased here since I've done a lot of work on the apt system (although nix looks more like a replacement for dpkg). This is the same package manager that was posted on lambda-the-ultimate a while back, right? Since you didn't provide a link, I'll provide one. According to Google, we're talking about this: http://nixos.org My first impression from reading blurbs on news sites was that they either found some seriously deep magic, or they're ignoring a lot of the practical issues that are involved in managing packages within a large Linux distribution -- and I suspect the latter rather than the former. As an academic research project, they are within their rights to do that, and for some use cases it doesn't matter, but it doesn't mean we should adopt their software in Debian. To take a few excerpts from their site: Nix stores packages in the Nix store, usually the directory /nix/store, where each package has its own unique subdirectory such as /nix/store/r8vvq9kq18pz08v249h8my6r9vs7s0n3-firefox-2.0.0.1/ Never mind that this breaks the FHS -- I'll pretend for now that we've amended policy to allow this, or that we've stuck it in /var with some horrible bind-mounting to make it appear in the right places. That's a terrible user interface decision! This is Unix, and filenames are part of the user interface. That file name, aside from breaking all user expectations (as per my note about the FHS), is completely unmemorable, means that packages with the same name aren't necessarily sorted together in directory listings, breaks tab-completion, and includes a long string of (to the user) meaningless gobbledygook. At the very *least*, you should put the package name first, to fix the tab-completion and sorting problems: /nix/store/firefox-2.0.0.1-r8vvq9kq18pz08v249h8my6r9vs7s0n3 but then what if I have two firefox-2.0.0.1s installed? How do I know which one is which? I hope nix at least has stow-like abilities to create a unified /bin directory, but that doesn't help when you want to track down the files of a program for whatever reason. Multiple versions You can have multiple versions or variants of a package installed at the same time. This is especially important when different applications have dependencies on different versions of the same package — it prevents the “DLL hell”. Because of the hashing scheme, different versions of a package end up in different paths in the Nix store, so they don’t interfere with each other. That's fine as long as your hard drives (never mind the flash devices embedded systems use, where dpkg is already painfully heavy) are infinitely large, or you don't install very many versions of very many packages. The thought of doing this to track "unstable" terrifies me; I suspect that even a large hard drive would fill up a few weeks, months tops. And you can't automatically purge versions, because you never know which ones a user wants. Presumably there's a way to turn this off. In fact, I would expect that we *would* turn this off by default, with a manual override for particular packages, if we used it in Debian, because I can't see it being usable for a whole distribution otherwise. On the other hand: An important consequence is that operations like upgrading or uninstalling an application cannot break other applications, since these operations never “destructively” update or delete files that are used by other packages. That sounds like they haven't thought hard about the problems around upgrades and removals, which are not trivial. (there's a research team at the University of Paris they could talk to about this, if they haven't already) Because of that, I suspect that we *can't* disable the "install multiple versions" feature -- it sounds like the package manager fundamentally relies on this to do anything. In addition to my earlier comments: what if I have multiple Web servers or database servers installed (or multiple versions of one of them)? Which one runs at startup, and what if I have packages that specifically depend on another one? Complete dependencies As other people have written, their claims are at best overblown. e.g., while it can tell that I use Python, there's no possible way it can tell which versions of Python I'm compatible with. It also sounds like maybe they bind programs to the exact binary of the library they're built with, which would mean that you have to rebuild all the reverse dependencies of a library every time you rebuild the library! (that's so outrageous that I'm sure I must just be incorrectly extrapolating from the summary on their Web site) Also: what about programs that refer to a file, but can function without it? This seems to have the same problem as other harnesses that "automatically" detect dependencies through file access, in that it will see a program probing for some functionali
Re: screenshots.debian.net
On Tue, Nov 18, 2008 at 09:12:08PM -0800, Daniel Burrows <[EMAIL PROTECTED]> was heard to say: > I'm not surprised that the bandwidth consumption is excessive, > though. I'll think it over once I figure out why my VteTerminals > self-destruct when I hide them... For anyone who cares, the answer was "your VteTerminals self-destruct when you tell them to in a corner of the code you forgot about." D'oh! Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: screenshots.debian.net
On Mon, Nov 17, 2008 at 10:02:45PM +0200, George Danchev <[EMAIL PROTECTED]> was heard to say: > On Monday 17 November 2008 18:13:55 Daniel Burrows wrote: > > When the user clicks on a package in the GUI interface, they see the > > description of the package. I don't know what sort of load this would > > impose once the interface is out of "beta", but I'm guessing it's a lot > > more than you're seeing through the Web service. > > > > I'd like to make good use of this service, but I don't want to turn > > it into a smoking crater in the process. ;-) I don't really know what > > image-fetches-per-second translates into at your end, so I guess I'm > > looking for some guidance. > > I'm afraid that such frivoulous image fetching would be magnitude or two more > heavier to serve than fetching the new packages for today from a local Debian > mirror(s), since users are more likely to performe the latter once or twice > per day, but the former any time they feel bored or experiencing a long long > day ;-) I don't think this is "frivolous": for programs that are graphical, it can be very useful to see what the program looks like before you run it. I'm not surprised that the bandwidth consumption is excessive, though. I'll think it over once I figure out why my VteTerminals self-destruct when I hide them... Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: screenshots.debian.net
On Mon, Nov 17, 2008 at 11:49:06AM +0100, Christoph Haas <[EMAIL PROTECTED]> was heard to say: > On Montag, 17. November 2008, Daniel Burrows wrote: > > On Sun, Nov 16, 2008 at 07:46:27PM +0100, Christoph Haas > <[EMAIL PROTECTED]> was heard to say: > > > There should be a way to select what screenshot you want. I'm saving > > > the version number along with the screenshot. > > > > Personally, I would rather be able to provide a version number > > and then get the "best" screenshot you have. > > What is the "best"? :) I deliberately left that vague because I wasn't sure. :-) If there's an exact match, I would return that image; otherwise, I don't really care. The same thing the unversioned page returns would be fine and probably better than trying to be clever and find a good match. > > Then I could show a > > matching screenshot if there was one, and *something* if there > > wasn't. > > I can add a version parameter to the /thumbnail requests that would give > you only a thumbnail for the exact version. Just keep in mind that by > default the web interface suggest the Sid package revision. And that > number changes pretty often. So I'd say it's not likely you will get a > certain screenshots for your desired version. Unless of course you query > for the Lenny version. But I assume that most people just accept that > automatically displayed revision number even though the screenshots comes > from Lenny. So I'd say in 99% of the cases you get nothing. Well, I expect the common use case here would be users trying to select software in stable (or maybe testing). > > Also, would it be possible to get an API for uploading screenshots? > > (I say that as if I had any clue how to invoke such an API...) > > There is one. It uses the HTTP protocol. :) Just do an HTTP POST request > and send the three fields like in the upload form. Err...when I go to upload I get a webform, not a URL to point to? How do I generate an "HTTP POST request" in C++? Open a TCP socket and send some magic down it? I guess I can find an RFC with the right Google query... > > I imagine that automatically fetching > > thumbnails for an entire list of a few hundred packages would be poor > > manners. > > Let's find a better way to do that if you need more than what's usually > requested via the web interface. Traffic is less the problem than CPU load > probably. Unless you just do that once of course. To explain my offhand comment more clearly. Let's just say, hypothetically speaking, that I'm the developer of a GUI package manager for Debian. It would be nice (where by nice I mean *really UBERCOOL*) if, whenever users see a list of packages, they could see a little thumbnail next to each package with a screenshot of the package. When the user mouses over the screenshot, I could pop up a tooltip and fetch the full image into it. My comment was that while I think this would be a really nice feature for my software, it seems like it would probably put too much of a burden on your resources. I doubt there's any way to do this in a way that decreases the load, but maybe you have ideas I'm missing. > > Do you think you can handle fetching the thumbnail of each > > package the user clicks on? > > I currently do. Or how do you mean? When the user clicks on a package in the GUI interface, they see the description of the package. I don't know what sort of load this would impose once the interface is out of "beta", but I'm guessing it's a lot more than you're seeing through the Web service. I'd like to make good use of this service, but I don't want to turn it into a smoking crater in the process. ;-) I don't really know what image-fetches-per-second translates into at your end, so I guess I'm looking for some guidance. Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: screenshots.debian.net
On Sun, Nov 16, 2008 at 07:46:27PM +0100, Christoph Haas <[EMAIL PROTECTED]> was heard to say: > On Sonntag, 16. November 2008, Daniel Burrows wrote: > > On Thu, Nov 13, 2008 at 10:18:26PM +0100, Christoph Haas > <[EMAIL PROTECTED]> was heard to say: > > > Thumbnail (<= 160x120 pixels): > > > http://screenshots.debian.net/thumbnail/PACKAGENAME > > > (this URL returns a dummy thumbnail if no screenshot was found) > > > > Just one quick question: will there eventually be support for > > different versions to have different screenshots? Occasionally > > there's a big difference across versions, and users might want to > > see it. > > There should be a way to select what screenshot you want. I'm saving the > version number along with the screenshot. So in theory I could tell which > one is for a newer version of the software than the other (although I'd > have to 'dpkg --compare-versions' because I couldn't think of an SQL > function to do that yet). But I wouldn't know which one was for Etch or > Lenny without some additional queries on data I don't have yet. Personally, I would rather be able to provide a version number and then get the "best" screenshot you have. Then I could show a matching screenshot if there was one, and *something* if there wasn't. Also, would it be possible to get an API for uploading screenshots? (I say that as if I had any clue how to invoke such an API...) Oh, and a third question while I'm at it: what sort of bandwidth is available for this system? I imagine that automatically fetching thumbnails for an entire list of a few hundred packages would be poor manners. Do you think you can handle fetching the thumbnail of each package the user clicks on? Thanks, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: screenshots.debian.net
On Thu, Nov 13, 2008 at 10:18:26PM +0100, Christoph Haas <[EMAIL PROTECTED]> was heard to say: > Thumbnail (<= 160x120 pixels): > http://screenshots.debian.net/thumbnail/PACKAGENAME > (this URL returns a dummy thumbnail if no screenshot was found) Just one quick question: will there eventually be support for different versions to have different screenshots? Occasionally there's a big difference across versions, and users might want to see it. Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Headsup: ncurses soname bump 5 to 6
On Tue, Sep 16, 2008 at 09:21:44PM +0200, Daniel Baumann <[EMAIL PROTECTED]> was heard to say: > just a quick note: after lenny, ncurses will bump soname major from 5 to > 6 in order to make mouse wheels work. The transition will be big, but > can be entirely handled with binNMUs only and this is what this mail is > about: > > There is no hurry, but please start using soname-independent > build-depends on ncurses as 'libncurses-dev | libncurses5-dev' in your > next uploads. Sadly, this won't work for packages using libncursesw5 -- I got a rather large number of hits when I grepped for ncursesw in the Sources file for sid. Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Release Update: freeze guidelines, testing, BSP, rc bug fixes
On Mon, Sep 01, 2008 at 08:01:29AM +0200, Luk Claes <[EMAIL PROTECTED]> was heard to say: > Release notes > ~ > There is still quite a lot of work to be done on the lenny release notes. > Coordination for this will happen on the [EMAIL PROTECTED] > mailing list (further information to appear in a mail to that list). If > you know of any issues that need to be documented, file them as bugs > against the ``release-notes'' pseudo package. Do you know where I can find the current version of the release notes? I don't want to file bugs asking for documentation of things that are already documented. Or is the NewInLenny page the staging ground for the release notes? Thanks, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Source field in binary Packages list
On Sat, Aug 30, 2008 at 07:13:50PM -0300, Thadeu Lima de Souza Cascardo <[EMAIL PROTECTED]> was heard to say: > On Sat, Aug 30, 2008 at 03:21:36PM -0500, Raphael Geissert wrote: > > Thadeu Lima de Souza Cascardo wrote: > > > > > Hello, > > > > > > I am working on a grouping feature for aptitude, to group binary > > > packages by their source package. However, some packages in the Packages > > > file do not have a Source field. My guess was to use the package name as > > > the source package name. Is this right? > > > > Yup > > > > > > > > Thanks, > > > Thadeu Cascardo. > > Thanks again! > > For those interested, I've submitted the patches to the BTS as bugs > 497205 and 497206. Note that 497205 should break libapt-pkg ABI, so take > care. :-) Why do you need #497205? Is it too slow to just use SourcePkg() in the package records object? Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#496967: general: System completely blocks any input
On Sat, Aug 30, 2008 at 12:21:16PM +0200, Frank Küster <[EMAIL PROTECTED]> was heard to say: > Is there any live system available which can handle lvm volumes? I think > I even have some free disk space for an additional partition to install > the live system on harddisk. But I cannot access it from Knoppix, and > didn't find information on lvm in the Knoppix FAQ. I haven't tried it, but I would expect that the Ubuntu live CD has the necessary support. e.g., this article says it works if you install the lvm user-space tools in the live system: http://linuxwave.blogspot.com/2007/11/mounting-lvm-disk-using-ubuntu-livecd.html Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: newer sub package zaps main package instead of waiting
On Sat, Aug 23, 2008 at 05:02:49AM +0800, [EMAIL PROTECTED] was heard to say: > Say, often a developer upgrades a group of related packages, but they > don't hit the mirrors at the same time. This causes apt-get > dselect-upgrade and dist-upgrade to remove the older parts instead of > holding back for the newer parts. One must use apt-get upgrade for the > many days the condition persists. This sort of situation was the motivation for a change to the behavior of the "upgrade" command in aptitude. Unlike apt-get, aptitude will install new packages in "safe-upgrade" (formerly "upgrade"); it just refuses to remove any packages to resolve dependencies. (it will still remove automatically installed packages if nothing uses them) Since new packages were the main reason I used full-upgrade, I've found that I can carry on (in unstable, no less) safe-upgrading for weeks at a time before I need to run a full-upgrade to sort out some tricky dependency problem. Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: feature: to add explanations of recommendations and suggestions dependencies
On Tue, Aug 12, 2008 at 11:03:50PM -0400, Felipe Sateler <[EMAIL PROTECTED]> was heard to say: > Charles Plessy wrote: > > > Le Mon, Aug 11, 2008 at 07:02:02PM -0400, Felipe Sateler a écrit : > >> Goswin von Brederlow wrote: > >> > >> Could they be added as XB-Comment:? I use XS-Comment and it appears in the > >> dsc, I don't know if XB-* appear in the deb or elsewhere. > > > > Hi Felipe, > > > > The answer is only in the sources for the moment. > > A quick test shows that XB-Comment: something shows as Comment: something in > the > deb. However, this doesn't mean that it will show up in apt-cache show. It > would depend on how the Packages file is created. A quick test with apt-ftparchive shows that the answer is "yes". Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: feature: to add explanations of recommendations and suggestions dependencies
On Tue, Aug 12, 2008 at 08:57:24PM +0100, Adeodato Simó <[EMAIL PROTECTED]> was heard to say: > * Shachar Or [Sun, 10 Aug 2008 18:36:35 +0300]: > > > I am not suggesting this data will be put in with the package's > > description, > > Why not? I think (briefly) explaining some of the most relevant > recommends and suggests is a perfect use of the description space. And > if more verbosity is needed, that information should go into the > README.Debian file in my opinion. The thing is that the Description field is not machine-parseable. If aptitude, for instance, knew about the purpose of a Recommends, it could indicate this to the user at convenient places in the UI where the Description might not be visible (and without requiring the user to hunt for the recommendation in the Description). Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Good communication with upstream is good idea
On Tue, Jul 22, 2008 at 02:46:01PM +1000, Brian May <[EMAIL PROTECTED]> was heard to say: > Steve Langasek wrote: >> And even if LP accepted other openid providers, one would still have to log >> in to LP the first time in order to configure which openid provider to use, >> which I guess is still going to be more effort than some are interested in >> doing. :) >> > It would certainly address the issues I regularly face with being forced > to register with XYZ different websites: > >* Have I registered here before? >* What is my username? >* What is my password? >* Ok, I can't work that out. What email address did I give this > site? Does it still work? >* What sites have I registered on? If you can live with having this information in an encrypted file, you might want to take a look at the pwsafe package. Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Package management unsafe?
On Fri, Jul 11, 2008 at 07:36:44AM -0500, Ron Johnson <[EMAIL PROTECTED]> was heard to say: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > > http://www.cs.arizona.edu/people/justin/packagemanagersecurity/attacks-on-package-managers.html > > What are people's thoughts on this? I don't see anything new or surprising on that page. In fact, the two attacks they list (replaying old versions of an archive and taking over a mirror) were discussed at the time that archive signing was added to apt. My recollection is that the conclusion regarding replay attacks was that it wasn't clear how signing archives would prevent this (you would presumably need to somehow periodically change the archive signature, and warn the user if it was out of date). Mirror takeovers are, of course, exactly why archive signing was added to apt. I'm talking now about their use to provide unsigned and faulty packages, not to delay updates (which is just a replay attack). It's not clear whether archive signing will actually defend against this attack *in practice*; some users seem to investigate bad signatures, but I'm sure a lot just override the warning, especially because there are an unfortunately high number of false positives. But the technology itself can detect this situation. When I saw the headline I figured he was talking about actual code vulnerabilities in package managers (e.g., buffer overflows parsing the Packages file); that would be a lot more interesting and worrying. Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Non-related 'Recommends' dependencies - bug or not?
On Fri, Jun 13, 2008 at 12:31:22AM -0400, Felipe Sateler <[EMAIL PROTECTED]> was heard to say: > Frans Pop wrote: > > > Dependencies should in principle be "top down", not "bottom up". And > > defining dependencies from libs to apps is almost per definition "bottom > > up". > > As a nice experiment (you need testing or unstable's aptitude for this): > > % aptitude search '?section(^libs) ?recommends(!?section(libs) !?section(doc) > !?section(python) !?section(perl) !?section(doc) !?section(libdevel) )' | wc > -l > 139 The equivalent for older aptitudes is this: aptitude search '~s^libs ~Drecommends:(!~slibs !~sdoc !~spython !~sperl !~slibdevel)' | wc -l Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Fwd: Re: [Pkg-virtualbox-devel] Bug#484624: virtualbox-ose depends on a
On Fri, Jun 06, 2008 at 06:01:20PM +0530, Ritesh Raj Sarraf <[EMAIL PROTECTED]> was heard to say: > Is this something to do with apt/dpkg? If you recommend a pure virtual package, apt will pick an arbitrary provider (IIRC the first one that occurs in its internal cache) to fulfill the dependency. Unfortunately, there's no way to make dependencies conditional on the hardware of the system. Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Handling of removed packages
On Thu, May 29, 2008 at 06:17:44PM +0200, Frans Pop <[EMAIL PROTECTED]> was heard to say: > James Vega wrote: > > As of version 0.4.11, this does happen. From the NEWS file: > > * Command-line updates in aptitude will now list packages that are > > newly obsolete. This doesn't work when a source is removed and > > all its packages become obsolete, for technical reasons. > > Hmm. New Debian release. User uses codenames in sources.list. > > # sed -i "s/etch/lenny/" /etc/apt/sources.list > # aptitude update > > Does this fit in the exception listed above? I would think yes and in that > case the only use case we really care about would not be supported. > Maybe I'm reading that wrong though or is "source" defined at a higher level > than I think it is. Here's what happens: aptitude update after editing sources.list will initialize itself as usual, update the package lists, then re-read them and looks for packages that weren't obsolete before. The problem is that in the initialization procedure, apt will only read package lists that are mentioned in sources.list. So as far as aptitude knows, all the packages that are currently installed from etch (in your example) were already obsolete before the lists are even updated, and so they won't show up in the list of new obsolete packages. Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: pwsafe and OpenSSL?
On Fri, May 16, 2008 at 11:46:13PM +0200, Moritz Muehlenhoff <[EMAIL PROTECTED]> was heard to say: > Daniel Burrows wrote: > > I notice that pwsafe is linked against openssl. Is it affected by the > > recent debacle and if so, how? Do I need to regenerate all my > > randomized passwords, or somehow re-encrypt the pwsafe database? > > I've looked briefly into it: The Blowfish encryption key is constructed > from a SHA1 built from an initial random value, two zero bytes and the > passphrase. So if an unmodified database created using a broken libssl > copy is exposed to an attacker, it's more open to brute forcing attempts, > but still safe-guarded by the passphrase. > > Fortunately the random part is renewed whenever the database is saved. > By my understanding - I don't use pwsafe myself - this should happen > whever an entry is added or modified. According to upstream, that's not enoguh :( -- you need to create a new database and merge into it. It looks like someone has put this information into the wiki already. Also, that sinking feeling in my stomach was right: the random passwords you generate in pwsafe were predictable with the broken openssl. So anyone who's relied on the randomization feature of pwsafe needs to reset all their passwords. Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: divergence from upstream as a bug
On Sun, May 18, 2008 at 12:07:04PM +0200, Lucas Nussbaum <[EMAIL PROTECTED]> was heard to say: > A saner solution would be to only use the BTS when it's not possible > to discuss the patch with upstream. We could do the following: > > - add pseudo-headers in the patches for: > + URL of the bug that the patch is fixing (could be a Debian > bug or an upstream bug, or even another distro's bug) > + URL of the discussion (patch, ML thread) happening upstream about > this patch It seems to me that if you also add a pseudo-header for the bugs that are relevant to a patch, the BTS could automatically incorporate the patch into the bug log, and set any states that are deemed appropriate. Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: figtoipe / difficulties with Replaces:
On Sat, May 17, 2008 at 03:48:03PM +0200, Alexander Bürger <[EMAIL PROTECTED]> was heard to say: > 0==0 > Info for debian-devel: we try to figure out how to package figtoipe. > Before version 6.0pre30-1, a version of figtoipe was included in the ipe > package. Since then, figtoipe is a separate upstream package and also > gone from the ipe .deb. A new version of figtoipe, which is improved and > has fewer bugs than the one coming with older ipe versions, exists and > shall be packaged for debian in a way that it can be installed together > with any ipe version. > 0==0 I don't understand the question enough, I guess. What's wrong with the usual solution? i.e., figtoipe Replaces ipe (< 6.0pre30-1) figtoipe Conflicts ipe (< 6.0pre30-1) Using Replaces on its own seems bizarre to me. OTOH, some packages do this; e.g., xfce4 Replaces xfce4-dev without conflicting with it. [0] Daniel [0] you can get the full list with aptitude search '?for x: ?replaces(?for y:?not(?x:conflicts(?=y)))' -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
pwsafe and OpenSSL?
I notice that pwsafe is linked against openssl. Is it affected by the recent debacle and if so, how? Do I need to regenerate all my randomized passwords, or somehow re-encrypt the pwsafe database? Thanks, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: analyzing popcon data for bogus recommends
On Tue, May 13, 2008 at 11:09:20PM -0400, Felipe Sateler <[EMAIL PROTECTED]> was heard to say: > Joey Hess wrote: > > > It would be nice to have a list which Recommends are ignored/overridden > > the most when installing packages, to identify Recommends that need to be > > downgraded to Suggests. Could we derive such a list from popcon data? I > > think it would need to be done by analyzing each individual popcon data > > submission, so I can't do it as that data is not published. > > I think you need more than popcon data: popcon doesn't say which packages were > manually installed and which were automatically AFAIK. Maybe package B is > installed and only recommended by A, but there is no way to tell if package B > wasn't needed on it's own. It's true that you probably couldn't use this to find recommendations that *should* exist, but if a Recommends is being widely ignored / overridden (i.e., if the number of systems installed A but not B is high), then it might be worth re-examining that dependency. Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How do I trace aptitude dependencies?
On Mon, Apr 28, 2008 at 02:38:51PM -0400, Bryan Donlan <[EMAIL PROTECTED]> was heard to say: > Aha, why -v helped indeed. One note about it though: > [EMAIL PROTECTED] bd] aptitude why -v imagemagick iceape-browser > p imagemagick Dependslibmagick10 > p libmagick10 Dependslibdjvulibre21 (>= 3.5.20) > p libdjvulibre21Recommends djvulibre-desktop > p djvulibre-desktop Recommends djview4 | djview3 | djview | evince > p djview4 Recommends djvulibre-plugin > p djvulibre-plugin Recommends mozilla-browser | mozilla | > mozilla-firefox | iceweasel | iceape-browser | konqueror | galeon | > netscape-base-4 | netscape > [EMAIL PROTECTED] bd] aptitude why -v imagemagick mozilla-browser > p imagemagick Dependslibmagick10 > p libmagick10 Dependslibdjvulibre21 (>= 3.5.20) > p libdjvulibre21Recommends djvulibre-desktop > p djvulibre-desktop Recommends djview4 | djview3 | djview | evince > p djview4 Recommends djvulibre-plugin > p djvulibre-plugin Recommends mozilla-browser | mozilla | > mozilla-firefox | iceweasel | iceape-browser | konqueror | galeon | > netscape-base-4 | netscape > > Since iceape-browser is really being pulled in via the mozilla-browser > depend, shouldn't that step be listed as well in the first command? That's a good question. The thing is that "why" doesn't tell you what "install" did; it just traces out dependencies blindly. It's picking the alternative because it's "shorter" than the path through a provides. > Also, when I disable djvulibre-desktop in the aptitude plan with -, > hal is still pulled in, even though: You mean that you did this, right? (a) mark imagemagick for installation (b) disable djvulibre-desktop In (b), aptitude will only automatically clear installations of packages that nothing requires. If hal is being autoinstalled, it doesn't know the difference (any more) between hal being autoinstalled for djvulibre-desktop, or for one of the approximately 5,000 other packages that think they need it. > Shouldn't there be no path to hal, meaning it should be auto-removed > now? If it's pinned by a previously-installed package's recommends or > suggests, is there a way to get aptitude to prune planned-to-install > packages pulled in through recommends which have been since disabled > manually? At the moment, aptitude doesn't attempt to figure this out. Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How do I trace aptitude dependencies?
On Mon, Apr 28, 2008 at 07:05:24AM -0700, Daniel Burrows <[EMAIL PROTECTED]> was heard to say: > One option you have is to run "aptitude why -v imagemagick iceape-browser", > which will show you all the possible dependency chains between those > packages. On my computer, I get this (reformatted, "why" apparently doesn't deal well with very long ORs): i A imagemagick Dependslibmagick10 i A libmagick10 Dependslibdjvulibre21 (>= 3.5.20) i A libdjvulibre21Recommends djvulibre-desktop p djvulibre-desktop Recommends djview4 | djview3 | djview | evince p djview4 Recommends djvulibre-plugin p djvulibre-plugin Recommends mozilla-browser | mozilla | mozilla-firefox | iceweasel | iceape-browser | konqueror | galeon | netscape-base-4 | netscape It looks like djvulibre-plugin is a plugin for Netscape-style browsers, so it recommends installing one. Since links isn't, mozilla-browser gets picked, which is really iceape-browser. Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How do I trace aptitude dependencies?
On Mon, Apr 28, 2008 at 01:17:24AM -0400, Bryan Donlan <[EMAIL PROTECTED]> was heard to say: > Currently I have a situation where attempting to upgrade imagemagick > from version 7:6.2.4.5.dfsg1-1+lenny1 to version 7:6.3.7.9.dfsg1-2+b1 > pulls in over 200mb of dependencies, including mozilla-browser, > iceape-browser, and half of gnome. Using aptitude's 'i' command to > attempt to get information on why some of these are being installed > results in things like: > i pbuilder Recommends devscripts > i A devscripts Recommends www-browser > piA iceape-browser Provides www-browser > piA iceape-browser Recommends iceape-gnome-support This is *a* reason to install iceape-gnome-support, but perhaps not the reason it's getting pulled in in your case. > This makes no sense, as I already have links installed for > www-browser. Even stranger are things like: > > i pbuilder Recommends devscripts > i A devscripts Recommends www-browser > p konqueror Provides www-browser > p konqueror Dependslibqt3-mt (>= 3:3.3.8b) > p libqt3-mt Dependslibaudio2 It's saying that one reason you might want to install libaudio2 is if you installed konqueror to fulfill the devscripts dependency. The general problem of "why is this package being installed?" is NP-hard where it isn't unsolvable (the latter being because the information aptitude would need isn't present in the package database, but rather in the user's head or in the guts of some apt algorithm). aptitude doesn't attempt to answer this question. Instead, aptitude tells you "what installed or to-be-installed package (if any) depends on this package?" [0] This is useful for finding out why auto-removal is behaving in a particular way, but as you discovered, it doesn't answer all possible questions one might have. One option you have is to run "aptitude why -v imagemagick iceape-browser", which will show you all the possible dependency chains between those packages. I'm happy to improve the algorithm if anyone has useful suggestions. Daniel [0] with the caveat that it tries to check dependencies that aren't virtual or ORed first, and looks for strong dependencies before weak ones. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Installation of suggested packages: recursive or not?
On Sat, Mar 22, 2008 at 02:21:52PM +0900, Charles Plessy <[EMAIL PROTECTED]> was heard to say: > Le Thu, Mar 20, 2008 at 08:13:30AM -0700, Daniel Burrows a écrit : > > > > BTW, aptitude already supports non-recursively installing Suggests, and > > flagging them as manual at the same time: "~Rsuggests:^package$" will > > install everything that's directly suggested by "package". > > Dear Daniel, > > Thanks for the suggestion. Do you think that there could be an option > that does the same except that the package would be flagged "auto" ? If > you are busy I can help updating the documentation. I would like to > provide an easy to remember way to perform this task for the users of > the packages I mentioned earlier (med-bio, t-coffee, bioperl). There could be. In fact, you can get it now: "~Rsuggests:^package$+M" (the "+M" means "install it and mark it automatic") On the other hand, resurrecting "--with-suggests" would be a more friendly way of doing this. I think I would add a sanity-check to force you to turn on "SuggestsImportant" in the config file first: if you don't, the newly installed packages will be unused and the installs will be immediately canceled. Daniel
Re: Installation of suggested packages: recursive or not?
On Thu, Mar 20, 2008 at 12:38:17PM +0900, Charles Plessy <[EMAIL PROTECTED]> was heard to say: > Le Wed, Mar 19, 2008 at 02:05:05PM -0400, Joe Smith a écrit : > > >On Wed, 19 Mar 2008, Don Armstrong wrote: > > >> > > >>apt-get -o APT::Install-Suggests=true install foo; or similar. > > > I will say the following. I fully agree that "--install-suggests" should > > exist, and should do the right thing. > > Hi all, > > I was about to submit a wishlist bug, and then wondererd: isn't '-o > APT::Install-Suggests=true' recursive? (In the sense that it will also > add the suggested packages from the suggested packages.) The > --install-suggests I have in my mind is not: the user cases would be > with our CDD metapackages, that either Recommend or Suggest, or packages > like t-coffee or bioperl that have a long list of suggested packages > that are usually dispensable. Yes, it is. That's why I yanked it from aptitude: at the time, turning on the installation of Suggests would reliably result in huge swathes of packages being installed for some innocuous program. This may have changed since then. To see (more or less) what installing Suggests will do to your system, run: aptitude -s -o 'APT::Install-Suggests=true' -o 'APT::AutoRemove::SuggestsImportant=true' install '~RBsuggests:~i' On my computer, after a pile of dependency failures, I got: 0 packages upgraded, 386 newly installed, 1 to remove and 2 not upgraded. Need to get 505MB of archives. After unpacking 1854MB will be used. Some people will find that acceptable, others won't. A secondary problem is that automatic dependency removal will remove packages whose strongest link to a manual package is a Suggests. If you ever turn on Suggests-installation as a one-shot deal, you need to either also mark all the suggested packages as manual, or turn on "keep suggested packages on the system" (APT::AutoRemove::Suggests-Important). BTW, aptitude already supports non-recursively installing Suggests, and flagging them as manual at the same time: "~Rsuggests:^package$" will install everything that's directly suggested by "package". Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: What CDs and DVDs should we produce for lenny?
On Tue, Mar 18, 2008 at 02:21:45AM -0700, Don Armstrong <[EMAIL PROTECTED]> was heard to say: > On Tue, 18 Mar 2008, Anthony Towns wrote: > > I guess there's an inequality like: > > > > images on mirrors <= images on torrents <= images via jigdo > > Is there any way we can construct the torrent image on the fly from > the jigdo file? [That is, transform the packages that make up bits > x<->y into what they'd be on the iso?] Or maybe you could use debtorrent to download the files to fill out the jigdo image? (Disclaimer: I haven't used debtorrent so I don't know how efficient using it this way would be) Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: actively notifying users of removed packages
On Tue, Mar 11, 2008 at 04:19:42PM +0100, Luca Brivio <[EMAIL PROTECTED]> was heard to say: > Alle 14:57, mar 11 marzo 2008, Andreas Bombe ha scritto: > > It's no active notification, but aptitude lists all installed packages > > that aren't in any distribution included in sources.list under "Obsolete > > and Locally Created Packages". Verifying that this doesn't include any > > packages that I expect there (like locally compiled kernel module > > packages) is my way of checking for removed packages. > > aptitude should perhaps list packages that became (that is, are and weren't > before) obsolete (= not being in any archive? removed?) every time actions > are performed through its CLI? Seems like an efficient way... I wrote a patch to do this on the way to work this morning, and I think it should actually work now. Note, though, that it only works for obsolete packages in the new index: if you remove a source and update, packages made obsolete by that change aren't detected. Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Best practices for handling API (not ABI) breaks?
Hi, I'm the maintainer of libsigc++-2.0, a typesafe callback library for C++. Upstream has just released a new version, 2.2, which preserves the version 2.0 ABI but is not source-compatible: programs that compiled against the 2.0 series will break with this new release. There are 114 packages that depend on libsigc++-0, too many to do this just by bugging a few maintainers to recompile. What's the best practice for handling this situation? Thanks, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: mass ITPs
On Sat, Mar 01, 2008 at 08:49:05PM +0100, Romain Beauxis <[EMAIL PROTECTED]> was heard to say: > Le Saturday 01 March 2008 19:48:50 Christian Perrier, vous avez écrit : > > If someone cares to listen: when you think about ITPing each and every > > piece of FLOSS that pops around: think about *helping* people who > > maintain existing packages instead of adding even more noise to our > > noisy bunch of various crap^W software. > > Hey, reading you I figured out that all newcomers are required to have > contributions in Debian, which means *new packages*. [EMAIL PROTECTED]:~$ aptitude search '~m"Debian QA"' | wc -l 489 Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-buildpackage now reorganizing debian/control Depends field??
On Fri, Feb 22, 2008 at 08:50:37PM +0100, Raphael Hertzog <[EMAIL PROTECTED]>
was heard to say:
> On Fri, 22 Feb 2008, Otavio Salvador wrote:
> > "Sergei Golovan" <[EMAIL PROTECTED]> writes:
> > > Then having a unique, well-defined order of packages in Depends is a
> > > good idea. If packages aren't sorted their order is undefined (not all
> > > of the dependencies are added by hands, many of them come from
> > > substitution variables). So, the order may change from build to build.
> > > Since it is important for APT then this situation should be avoided.
> >
> > No. Just let's respect the control file order. If the maintainer has
> > put it this way, and we follow it, we avoid this too.
>
> No, Sergei is right. The order of packages within ${shlibs:Depends} is not
> defined, you're not completely avoiding the problem by reverting the
> change.
Would it be possible to only re-order elements that were introduced by
a variable substitution? That would make the list deterministic without
changing what the maintainer wrote.
Daniel
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-buildpackage now reorganizing debian/control Depends field??
On Fri, Feb 22, 2008 at 02:54:20PM +0100, David Paleino <[EMAIL PROTECTED]> was heard to say: > Il giorno Fri, 22 Feb 2008 10:04:52 -0300 > Otavio Salvador <[EMAIL PROTECTED]> ha scritto: > > > As I said, for APT, the order has meaning _always_. > > > > apt-get install foo bar > > > > Is completely different of > > > > apt-get install bar foo > > Could you please elaborate on this? I know for sure that Pre-Depends exists > just for the cases where order _does_ matter. But I've never had problems in > installing packages in any order (or probably I've just been lucky). Apt by default makes an initial attempt to resolve dependencies greedily which is a fancy way of saying that it tries to install each package it encounters and recursively solve its dependencies. So if a dependency is resolved by a package that's listed earlier, it'll never be traversed; on the other hand, a package might get installed that makes a previous choice redundant. Using a full dependency resolver would be one way of fixing this problem, but that tends to produce less predictable results. Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: the new style "mass tirage" of bugs
On Wed, Feb 20, 2008 at 04:53:20PM -0600, John Goerzen <[EMAIL PROTECTED]> was heard to say: > On Wed February 20 2008 3:43:18 pm Ben Finney wrote: > > Who other than the bug reporter would you suggest should try > > reproducing the bug? > > > > Suggesting "put that effort into fixing the bugs" is presuming that > > the prospective bug fixer knows *which* bugs are worth the effort. If > > the bug reporter is unresponsive, the bug is unlikely to be resolved > > anyway because it can't be confirmed fixed. > > > > > > What would you put in place of triage? > > I think that the point is that triage should happen at *submission* time, not > so long later. > > I have learned that certain well-known packages (OpenOffice, say) are bug > blackholes. I submit a bug, and never hear anything from Debian maintainers > except for periodic triage stuff when a new upstream comes out. I can't speak for anyone else, but in the case of aptitude, I have just about enough free time to keep up with bugs. The problem is that I sometimes want to spend my free time on other things, such as hanging out with my girlfriend, enjoying the outdoors, cleaning my apartment, etc. And of course if I ever do anything related to the project that's not strictly bug-fixing (say, writing new code, improving documentation, or writing messages to mailing lists like I'm doing right now), I also fall behind. Oh, and fixing bugs that are nontrivial? That makes me fall behind too if the bug takes more than a few hours to fix. I know this makes me a sucky maintainer [0], but I simply don't have more time and energy than I have. I'm totally in awe of people who can hold down a full-time job, have a personal life, and still devote tons of time to Debian and be uber-maintainers. I don't know how they manage it. Daniel [0] http://alioth.debian.org/~fjp/log/posts/aptitude_upload_not_something_to_be_proud_of.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: avoid conf file overwrite message?
On Thu, Feb 21, 2008 at 09:43:29PM -0800, Steve Langasek <[EMAIL PROTECTED]> was heard to say: > On Thu, Feb 21, 2008 at 06:24:37PM -0800, William Francis wrote: > > *** apache.conf (Y/I/N/O/D/Z) [default=N] ? Y > > Installing new version of config file /etc/twiki/apache.conf ... > > > Is there a way (short of piping in /usr/bin/yes or something similar) > > to make that go away? Eventually I'll use something like puppet to > > manage these files but for now this happens to be the easiest way. If > > I do answer 'Y' it does indeed do what I want. > > Diverting conffiles is not supported. Suppressing the prompts is supported > with a dpkg option; one of --force-confnew, --force-confold, or > --force-confdef, depending on which default you want to use. (It's possible > to configure dpkg options in /etc/apt/apt.conf, though I don't remember the > incantation exactly.) This should work, although I haven't tested it: APT::Dpkg::Options:: "--force-blah"; See apt.conf(5). Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Possible mass bug filing: missing shared library dependencies
On Thu, Jan 17, 2008 at 10:35:35PM +0200, Niko Tyni <[EMAIL PROTECTED]> was
heard to say:
> Daniel Burrows <[EMAIL PROTECTED]>
>heroes-common
Whoops. The package started out binary-indep, then changed to binary-dep.
I remembered to start invoking dh_shlibdeps on it ... but naturally I
forgot to add ${shlibs:Depends} to the Depends line, so that shlibdeps
invocation had no effect.
Daniel
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Introducing security hardening features for Lenny
On Tue, Jan 29, 2008 at 09:31:00PM -0600, John Goerzen <[EMAIL PROTECTED]> was heard to say: > On Tuesday 29 January 2008 4:31:51 pm Yves-Alexis Perez wrote: > > On mar, 2008-01-29 at 15:47 -0600, John Goerzen wrote: > > > I notice, for instance, that the latest cups > > > requires avahi. Can we build it without that and install it without > > > that by > > > default for those that don't need it, to eliminate Yet Another Daemon? > > > > You do know that it depends on the lib, not the daemon? > > -- > > Yves-Alexis > > It wound up pulling in the daemon on my box. Though it could be that the > daemon was already installed because kde required it, and upgrading cups > required the upgraded lib, and the daemon wouldn't work with the upgraded > lib, so it too had to be upgraded... I didn't track that one all the way > back. [EMAIL PROTECTED]:~$ aptitude why cupsys avahi-daemon i cupsys Recommends avahi-utils i A avahi-utils Dependsavahi-daemon Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: What to do when the LaTeX sources are missing, but an XML equivalent was rewritten from scratch ?
On Mon, Nov 19, 2007 at 10:52:21PM +0100, Norbert Preining <[EMAIL PROTECTED]> was heard to say: > On Mo, 19 Nov 2007, Don Armstrong wrote: > > If the author uses the pdf, it's the pdf. If the author uses the tex, > > Umpf, how do you proof/ensure that the source of a pdf is the pdf? > I hope you don't trust the "PDF Producer" field and similar? In general, we trust members of Debian to not deliberately subvert Debian's processes and procedures. Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Friendly reminder: the Vcs-Browser field is now official
On Mon, Oct 29, 2007 at 08:33:24PM +0100, Romain Francoise <[EMAIL PROTECTED]> was heard to say: > The packages listed below use the 'XS-Vcs-Browse' field, which has > been obsoleted by the new, official 'Vcs-Browser' field. Please > consider upgrading your control files to use that. Also note that > the proper capitalization is 'Vcs-Browser', not 'VCS-Browser'. > Thanks. Is this field meant to point at the Debian repository or the upstream repository? (I assume the Debian one) Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ITP: geogebra -- dynamic mathematics software for schools
On Mon, Oct 22, 2007 at 01:58:46PM +0200, Antonio Ullan <[EMAIL PROTECTED]> was heard to say: > Package: wnpp > Severity: wishlist > Owner: Antonio Ullán <[EMAIL PROTECTED]> > > * Package name: geogebra > Version : 3.x.y > Upstream Author : Markus Hohenwarter <[EMAIL PROTECTED]> > * URL : http://www.geogebra.org/ > * License : GPL > Description : geogebra is a free and multi-platform dynamic mathematics > software for schools that joins geometry, algebra and calculus The long description is not a continuation of the short description. Try this instead: Description: mathematics software for schools geogebra is a suite of mathematics software that combines a dynamic geometry system with quantitative geometry, algebra and calculus. You can probably write more into the long description; this is just what I was able to find out in 5 minutes by browsing geogebra's Web site. Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Compiling all packages with debug information?
On Wed, Oct 10, 2007 at 01:03:35AM -0700, Russ Allbery <[EMAIL PROTECTED]> was heard to say: > Oh, your private e-mail helped me understand what you're proposing. > You're saying that we could set it up so that the local user could build > the -dbg packages if they need them. At this point, what's the advantage versus just supporting DEB_BUILD_OPTIONS=debug in more packages? Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#444673: ITP: nted -- A new musical score editor for Linux
On Sun, Sep 30, 2007 at 11:33:39AM +0200, Pini <[EMAIL PROTECTED]> was heard to say: > * Package name: nted > Version : 0.6.1 > Upstream Author : Jan Anders <[EMAIL PROTECTED]> > * URL : > http://vsr.informatik.tu-chemnitz.de/~jan/noteedit/noteedit.html > * License : GPL > Programming Lang: C++ > Description : A WYSIWYG musical score editor for Linux Aren't NoteEdit packages already in Debian? Or is this a new and unrelated project? Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Installation of Recommends by default on October 1st
On Wed, Aug 01, 2007 at 09:36:39PM -0400, Joey Hess <[EMAIL PROTECTED]> was heard to say: > Neil Williams wrote: > > And a script to implement that in every box I have to install. Again > > and Again and Again and > > > > You almost forcing me into maintaining a fork of apt that restores the > > current behaviour from the very start. > > Forking apt and putting a line in a config file seem two quite > dissimilar levels of work. YMMV I guess. You don't even need to edit a configuration file in a script; just drop a file into /etc/apt/apt.conf.d containing the appropriate configuration option and apt will include it. Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Installation of Recommends by default on October 1st
On Wed, Aug 01, 2007 at 09:58:30PM +0200, Bernd Zeimetz <[EMAIL PROTECTED]> was heard to say: > > > No - because the default is already in place in aptitude which is WHY I > > don't use aptitude. If apt goes the same way, the default configuration > > of each offers no choice. > > > > By the time I get a chance to switch that option off, the installation > > has added loads of JUNK that I do NOT want. > > but when aptitude came up with that setting a lot of Recommends: should > have been in Suggests: instead. Just to clarify, aptitude didn't "come up" with anything. This was the standard behavior in Debian at the time (dselect was far more draconian about forcing you to install recommended packages), and one of the top complaints I got was that aptitude mishandled Recommends by not installing them! Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Non-security updates between stable releases?
On Tue, Jul 31, 2007 at 12:07:44PM +0200, Adam Borowski <[EMAIL PROTECTED]> was heard to say: > stable (pinned at 500): foo=1.0 [Depends: bar>=1.0], bar=1.0 > testing (pinned at 200): foo=1.2 [Depends: bar>=1.2], bar=1.2 > > If the user says: apt-get install foo=1.2, apt won't be smart enough to find > out it needs to upgrade bar as well. Same for aptitude or any other > front-end, making pulling packages from testing or experimental a pain. That's actually not true in aptitude. Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: apt-get -y upgrade for non-interactive sessions - and replacing conf files in /etc
On Thu, Jul 05, 2007 at 03:17:12PM -0700, Alan Ezust <[EMAIL PROTECTED]> was heard to say: > On 7/5/07, Steve Greenland <[EMAIL PROTECTED]> wrote: >> Alan, you know that it should only be prompting you on conffiles you >> actually >> modified? Do you really want those overwritten? > > Yes, I see it is indeed only prompting me for conffiles that I > manually modified. In my particular situation, and I realize this is > unusual/dangerous, I still would like to to clobber my handmade > changes with newer versions from a .deb file. Setting those two > environment variables did not change the behavior of dpkg in this > particular case. If you really want to do this, I think you need to pass --force-confnew to dpkg. You can arrange this either in /etc/dpkg/dpkg.cfg or in /etc/apt/apt.conf. Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Testers needed: aptitude 0.4.5.2
On Sun, Jun 17, 2007 at 01:01:27PM +0200, Vince H&K <[EMAIL PROTECTED]> was heard to say: > Daniel Burrows wrote: > > If I don't hear about any show-stoppers in the next week or so, I'll > > upload the new version of aptitude to unstable. Positive reports of it > > working would also be good, so I know that someone out there really is > > testing. :-) > > I really wish I would test, but it seems the recent aptitude FTBS on > all arches... There is a simple sprintf problem with -Werror, which is > easily fixed, but unfortunately, there are other problems afterwards in > the compilation that I seem unable to fix. I'll be filing a bug over the > next minutes. It doesn't FTBFS on i386 :-/. I'll check the bug and see if I can work out what's going wrong for you. Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Testers needed: aptitude 0.4.5.2
On Sat, Jun 16, 2007 at 04:48:56PM -0400, Felipe Sateler <[EMAIL PROTECTED]> was heard to say: > Daniel Burrows wrote: > > > * aptitude forgetting the automatic status of packages that were > > installed with old versions of aptitude. > > > > * aptitude not saving automatic states so that apt-get can see them. > > Any way of checking this easily? I imagine a diff of the old and > new /var/lib/aptitude/pkgstates is enough for the first. How to ckeck for > the third one? The main way you'd notice the third one would be if removing packages with apt-get failed to remove their dependencies. Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Testers needed: aptitude 0.4.5.2
Hi all, As you probably noticed, Michael Vogt uploaded apt 0.7.2 to unstable with support for detecting automatically installed packages. I've ported aptitude to use the new apt interfaces instead of its internal implementation, and uploaded the result to experimental. The ported aptitude should merge its database of automatically installed packages into the apt database -- any packages listed as automatic in either database will become automatic. Since this required touching a fair chunk of the internal aptitude logic, I'd appreciate it if people could test this before I release it into the wild. Here are a few general things to watch out for that should NOT happen and should be reported as bugs: * aptitude not thinking that packages automatically installed by apt-get et al are automatic. * aptitude forgetting the automatic status of packages that were installed with old versions of aptitude. * aptitude not saving automatic states so that apt-get can see them. * aptitude failing to set automatic states when it should. * aptitude's "undo" command not restoring automatic states. * Any other weirdness regardless of whether it affects automatic states. You might want to back up /var/lib/aptitude/pkgstates before running the new aptitude, just in case you encounter a nasty bug. If I don't hear about any show-stoppers in the next week or so, I'll upload the new version of aptitude to unstable. Positive reports of it working would also be good, so I know that someone out there really is testing. :-) Thanks, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: APT 0.7 for sid
On Sun, Jun 10, 2007 at 06:08:44PM -0500, Steve Greenland <[EMAIL PROTECTED]> was heard to say: > On 10-Jun-07, 17:47 (CDT), Daniel Burrows <[EMAIL PROTECTED]> wrote: > > Since then, it seems like most users have switched to apt-get and > > synaptic, with hardly anyone using aptitude or dselect any more > > Really? I'd have guessed that most people used aptitude. I can't imagine > anyone preferring synaptic to aptitude. Of course, I don't really > understand why anyone prefers [any graphical MUA] to mutt, or [any > graphical newsreader] to trn. I mean, GUIs are nice for things you don't > use every day, but for serious work, they're so damn slow and klutzy. Well, that might be just my general pessimism rearing its ugly head :). My impression has been that aptitude wasn't getting very many *new* users, but it might just be that aptitude users are a self-sufficient bunch and don't email me with questions. Come to think of it, my sense of the number of aptitude users fell off dramatically after I wrote the user's manual and put in answers to all the questions I kept getting... > Regards, > Steve the hopelessly out-of-date Hey, I resemble that remark. :) Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: aptitude removals (was Re: APT 0.7 for sid)
On Sun, Jun 10, 2007 at 08:13:18PM -0400, Felipe Sateler <[EMAIL PROTECTED]> was heard to say: > Daniel Burrows wrote: > > > Bug #299009 is AFAIK about the fact that aptitude produces different > > dependency resolutions from the visual UI versus the command-line. This > > is because the command-line has more context about what the user is > > doing and tweaks the resolver accordingly. > > Would you elaborate on that, please? I don't get why the command line has > more context. In your response to that bug report you said: That's a good question, and I've thought about it from time to time. Probably when I take a crack at this bug again, I'll at least take a shot at unifying the approach taken in the two frontends. TBH, what I wrote above was just paraphrasing (parroting) my comment in the bug report. > I fail to see the difference between "aptitude install X Y Z" and going into > the visual mode and then marking X Y Z for installation. Where is the extra > information? I think what I meant was that out of the whole world of packages in the cache, you mainly care about X, Y, and Z. You don't care (much) about packages that get dragged in by them, or about packages that are being kept at their current version but that you didn't mention. However, I think that a similar effect can probably be achieved in visual mode by adding a massive bonus to the current version of all packages being manually installed, removed, or upgraded, along with all held packages. I may also have been worried about the possibility that the resolver would get stuck on trying to avoid changing your selections, even if it turned out to be necessary to do so. But experience has shown that the opposite is the case: giving strong hints to keep user selections produces better results than otherwise (hence aptitude sets request-strictness to 1, which pretty much guarantees that you don't see solutions that change your selections unless there's no alternative). And on the third hand, it's entirely possible that I didn't have a clue what I was talking about in 2005. Also, the resolver was new back then and I didn't have as good a feeling as I do now for how it behaves, so I was being pretty cautious about tweaking its weights. Anyway, this is getting offtopic -- maybe we could take it to private mail if you want to talk more about dependency resolution. Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: APT 0.7 for sid
On Sun, Jun 10, 2007 at 06:05:49PM -0500, Peter Samuelson <[EMAIL PROTECTED]> was heard to say: > > [Daniel Burrows] > > I'm in favor of either enabling this by default in apt or downgrading > > Recommends in policy to just a "really Suggests". > [snip interesting background material] > > I would suggest - nay, I would recommend - keeping Policy the way it is > and fixing packages to use Recommends as it was intended. It is a very > useful semantic and I wouldn't want to see it get lost. We already > have Suggests, after all. Yes, absolutely. I guess I got so caught up in my trip down memory lane that I forgot to include my own opinion, which is the same as what Peter says above. But my main point is that we have a weird limbo where you're supposed to treat recommends as important, except that actually doing that leads to excessive installations and occasional breakage. We need to bite the bullet and resolve the inconsistency; and despite my personal preference, I think that either resolution is preferable to the current situation. > > This has led to a situation where I occasionally hear things like > > this statement, from a developer whose incorrect Recommendation was > > being obeyed by aptitude and breaking the system: > > > > "It's things like this that encourage me to continue using apt-get > >instead of aptitude!" > > Simply astonishing. I hope the developer was roundly larted, by you or > someone else, with a copy of Policy printed on heavy paper and > hardbound with brass accents. Well, the package in stable has the wrong recommendation. Does that count? :-P This won't affect most users, because the specific problem was that he had listed a pure virtual package as his recommendation; most users will have the correct alternative, but picking the wrong one can render the system unbootable if you're (un)lucky. Daniel PS: the reason I'm not mentioning the package that this involves, or the developer in question, is because I don't want to personalize this. The problem isn't that individual, it's that the general attitude towards Recommends seems, from my personal and highly biased viewpoint, to be evolving towards a "strong Suggests" model, rather than a "weak Depends". -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: APT 0.7 for sid
On Wed, Jun 06, 2007 at 09:49:00PM -0400, Joey Hess <[EMAIL PROTECTED]> was heard to say: > Michael Vogt wrote: > > - support for the new dpkg "Breaks" field (thanks to Ian Jackson for > > his work on this) > > Although dpkg still doesn't have Breaks support, so we still can't use > it, AFAIK.. > > > - automatic installation of recommends like aptitude > > I want to check how this will affect d-i. The Recommends tree is still > fairly hairy/unrefined and can result in a lot of crud being pulled in. > (See #388290. Though having them installed by default would certianly > add pressure to fix the bogus ones.) I'm in favor of either enabling this by default in apt or downgrading Recommends in policy to just a "really Suggests". What follows are my personal observations on how the use and interpretation of Recommends has evolved. Policy says that Recommended packages should be found with the recommender in "all but unusual installations". Traditionally this was interpreted to mean that "the default installation requires this but you can hack it up to behave differently if you really want to", and dselect implemented this by pretty much forcing you to install recommendations. When apt-get came along (circa 1998?), it didn't implement Recommends at all. At the time I added Recommends support to aptitude (2001), dselect was still fairly widely used, and new aptitude users, while they didn't miss dselect's strong-arming them into installing recommends, did wish that aptitude would select them by default. Once I worked out how to handle this in a non-annoying way, I implemented pretty much what aptitude does now: Recommendations get selected on the first install but not afterwards. Since then, it seems like most users have switched to apt-get and synaptic, with hardly anyone using aptitude or dselect any more (except inasmuch as aptitude is called by d-i). The result seems to be that developers psychologically view Recommends as a sort of "more emphatic Suggests" that they can't rely on the package manager actually using. This has led to a situation where I occasionally hear things like this statement, from a developer whose incorrect Recommendation was being obeyed by aptitude and breaking the system: "It's things like this that encourage me to continue using apt-get instead of aptitude!" The fact that I hit these every few months without actively going out and looking for them suggests to me that there's a fairly broad anti-Recommends sentiment out there. Either that or I'm just unlucky. :) We should, IMO, have a single agreed-upon use of and semantics for Recommendations. If most developers think that Recommendations are meaningless, then maybe we should make them meaningless. But we should not have a situation where following Policy and tradition mean you get subjected to random sniping about your "wrong" behavior. And I don't think that we can get people to start using recommendations properly without having them implemented in a widely-used package manager. We've tried that for the last 7-8 years and the result has been a decrease in the quality of recommendations, with the simultaneous appearance of opposition to the idea that a package manager should follow Recommends: lines at all. Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: APT 0.7 for sid
On Sun, Jun 10, 2007 at 10:45:06AM -0700, Daniel Burrows <[EMAIL PROTECTED]> was heard to say: > aptitude throws out the solution of "revert all the proposed changes > and stay at the current state". Setting Aptitude::Discard-Null-Solution > to false will disable this behavior. *sheepish look* Uh, yeah, that would be Aptitude::ProblemResolver::Discard-Null-Solution. Daniel (who would be embarassed even if he *hadn't* gone into the source, looked up the correct configuration option, and then mistyped it into his email...) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: APT 0.7 for sid
On Fri, Jun 08, 2007 at 07:42:40AM -0700, Daniel Burrows <[EMAIL PROTECTED]> was heard to say: > On Thu, Jun 07, 2007 at 09:54:16AM +0200, Raphael Hertzog <[EMAIL PROTECTED]> > was heard to say: > > > term. I would also love to find a way in the future to interface with > > > the aptitude dependency problem resolver (that is superiour to the one > > > in libapt). > > > > In what way is it superior? Until now, apt-get always found a solution to > > all the dist-upgrade that I gave him whereas aptitude sometimes didn't. > > Raphael, > > When you encounter situations where aptitude can't find a solution, > could you please send them to me? aptitude's resolver is designed to be > complete, so if it misses valid solutions it's a bug. I've been reminded of an exception to this. aptitude throws out the solution of "revert all the proposed changes and stay at the current state". Setting Aptitude::Discard-Null-Solution to false will disable this behavior. Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: aptitude removals (was Re: APT 0.7 for sid)
On Sun, Jun 10, 2007 at 10:46:37AM -0400, Philippe Cloutier <[EMAIL PROTECTED]> was heard to say: > > > >Apparently there have been bugs in this for years and no-one reported > >them until they caused trouble for the d-i team several months ago. > >They should be fixed in stable's aptitude now, and I would appreciate > >bug reports on any transition problems that remain. > FWIW, I thought that you acknowledged that this problem was reported in > #299009 (over 25 months ago). I'm mentioning this because I believe this > issue is/was the main reason for "anti-aptitudism". Bug #299009 is AFAIK about the fact that aptitude produces different dependency resolutions from the visual UI versus the command-line. This is because the command-line has more context about what the user is doing and tweaks the resolver accordingly. There's a side note in there that at the time (25 months ago), there were known problems in the then-stable release of aptitude which caused incorrect removals. I'm not sure what I was referring to -- I was working full-time on Debian (i.e., I was unemployed :-/) at the time, and I had a lot more context available back then. So my gripe might have been a little misdirected -- I forgot how old the aptitude in sarge was. My apologies to the world! It was a little disconcerting when I recently subscribed to debian-user and saw people saying "oh, don't mix apt-get and aptitude" as if it were gospel and the intended usage. I guess I'll just have to keep correcting those statement until good information drives out the bad. (FYI: the bug report that gave me the clue to the last slippery instance of this problem was #411123; kudos to Frans Pop for a high-quality report. The fact that I never saw it probably says something about my usage patterns, not to mention that I never use apt-get...) Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: APT 0.7 for sid
On Thu, Jun 07, 2007 at 09:54:16AM +0200, Raphael Hertzog <[EMAIL PROTECTED]> was heard to say: > > term. I would also love to find a way in the future to interface with > > the aptitude dependency problem resolver (that is superiour to the one > > in libapt). > > In what way is it superior? Until now, apt-get always found a solution to > all the dist-upgrade that I gave him whereas aptitude sometimes didn't. Raphael, When you encounter situations where aptitude can't find a solution, could you please send them to me? aptitude's resolver is designed to be complete, so if it misses valid solutions it's a bug. Thanks, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: APT 0.7 for sid
On Thu, Jun 07, 2007 at 08:55:59AM +0200, Eduard Bloch <[EMAIL PROTECTED]> was heard to say: > #include > * Russ Allbery [Wed, Jun 06 2007, 08:40:47PM]: > > > > Is this the same dependency resolver that tries to remove half your > > > packages as a result of the most minor package removal? > > > > No, that's not done by the dependency resolver. That's done by the code > > that removes packages that you never told it should be installed. > > > > This problem goes away completely if you only use aptitude-aware tools to > > install packages. It's basically a transition issue. (I do agree that > > the transition could be improved.) > > > Why do you think that aptitude is perfect? I can remember a not so nice > evening few months ago when aptitude (on Ubuntu) tried to remove half of > the distro when installing simple packages. The reason was the forgotton > source line for the previous release in sources.list - but still, it > should cope with that and not wreak random havoc. > Why did it want to remove your packages? I can't think of any reason that missing the previous release should have caused problems -- unless maybe there were broken dependencies that needed the previous release in order to be resolved? Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: APT 0.7 for sid
On Wed, Jun 06, 2007 at 08:40:47PM -0700, Russ Allbery <[EMAIL PROTECTED]> was heard to say: > Ron Johnson <[EMAIL PROTECTED]> writes: > > On 06/06/07 17:59, Michael Vogt wrote: > > >> I would also love to find a way in the future to interface with the > >> aptitude dependency problem resolver (that is superiour to the one in > >> libapt). > > > Is this the same dependency resolver that tries to remove half your > > packages as a result of the most minor package removal? > > No, that's not done by the dependency resolver. That's done by the code > that removes packages that you never told it should be installed. > > This problem goes away completely if you only use aptitude-aware tools to > install packages. It's basically a transition issue. (I do agree that > the transition could be improved.) aptitude's dependency removal has always been intended to be conservative: it doesn't treat a package as a candidate for removal unless it actually "saw" it get autoinstalled. Apparently there have been bugs in this for years and no-one reported them until they caused trouble for the d-i team several months ago. They should be fixed in stable's aptitude now, and I would appreciate bug reports on any transition problems that remain. Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Why not move Apt to a relational database
I'm sorry I don't have more time to comment on this. On Sun, Jun 03, 2007 at 10:55:01AM +0100, Justin Emmanuel <[EMAIL PROTECTED]> was heard to say: > Based on a relational database it will run faster, also there should be > some more data stored about the programs to facilitate system restoring. Is this really true? I'll freely admit that I have only cursory experience with RDBMSes. However, with the current apt cache code, lookups are basically a pointer dereference (and maybe a page fault). I don't see how an RDBMS could possibly improve on that. There might be other benefits to an RDBMS, but I'm not convinced this is one. One benefit which I didn't see listed in your mail is that it might become easier to augment the cache with more information; a great deal of slowness in aptitude's startup, for instance, comes from reading tables that aren't included in apt's global cache. Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Reasons for recommends and suggests
On Sat, May 19, 2007 at 09:52:44AM -0500, Manoj Srivastava <[EMAIL PROTECTED]> was heard to say: > A field in the control file is unlikely to have enough space to > truly state the reasons (remember, the maintainer has alsready stated > that in their judgement the packages belong together for all but the > most unusual installations). Adding a special file with expanded > explanations or essays might work. The goal is not to produce an iron-clad defense of your judgement, it's to allow the user to make a more informed judgement than they could otherwise make. I've drawn some packages fully at random from the package list to see whether there's any reason to believe that we couldn't construct a helpful explanation of their suggestions. It's interesting to note that somewhere around 3/4 of the packages I checked didn't have any suggestions or recommendations at all, so even if we tried to document all suggestions fully, most packages would be unaffected. === pop-before-smtp Suggests: imap-server | pop3-server Suggests-Reason: imap-server | pop3-server: because pop-before-smtp needs access to the log file of your POP3 or IMAP server. pop-before-smtp scans the logs of your POP3 or IMAP server in order to detect user logins. If the server is running on another computer, you must provide access to its log files on this computer (for instance, by enabling remote syslog access). === === kdeaccessibility-doc-html Suggests: kdebase Suggests-Reason: kdebase: to run the software this package documents. === === kdeartwork-misc Suggests: kworldclock Suggests-Reason: kworldclock: to make use of the kworldclock themes included in this package. === === ttf-bengali-fonts Suggests: x-ttcidfont-conf Suggests-Reason: x-ttcidfont-conf: to automatically register these fonts with the X window system. === === pida Suggests: bicyclerepair Suggests-Reason: bicyclerepair: because bicycle-repair is a useful Python tool that I like. === (I installed both pida and bicycle-repair, and as far as I can tell, this is the only relationship between them. bicycle-repair has IDE plugins...but there doesn't seem to be one for pida) Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Reasons for recommends and suggests
On Thu, May 17, 2007 at 04:56:23PM -0700, Don Armstrong <[EMAIL PROTECTED]> was heard to say: > On Fri, 18 May 2007, Brian May wrote: > > > "Neil" == Neil Williams <[EMAIL PROTECTED]> writes: > > > > Neil> The only bug suitable for this scenario is a wishlist bug > > Neil> for a more verbose manpage. > > > > I want to know if I should install the package recommendations or not > > when I install the package. > > The recommends should be a set such that you'd want to install them, > unless you know specifically why you don't. [In the majority of cases > that I've personally run into, this means "unusual" setups like a > separate database server, stripped installs, etc.] That's true for recommendations, but suggestions are fully optional, and providing the user with the information necessary to make an informed decision would be IMO a very good thing. Recommends come along "for free" then. :-) > Moreover, the information necessary to explain what packages that are > Recommends: or Suggests: actually do and the additional features they > require is not something that can be easily jammed into the > Description without making the description uselessly long. That's true. But I would very much be in favor of adding new, optional fields that describe the dependencies of the package. These can be integrated into the package management interface at appropriate points, without cluttering the description itself. Stuffing information into README.Debian doesn't help, since (a) you can't read it until you've installed the package, and (b) NLP parsing isn't good enough to find the text you need and extract it automatically :-). Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: apt-get
On Fri, May 18, 2007 at 04:19:28PM -0400, Greg Folkert <[EMAIL PROTECTED]> was heard to say: > It was really hard for me to switch to using aptitude, but now since I > have, I get annoyed when I use apt-get, although I use apt-get regularly > on a certain machine. I'd still like to use aptitude, but the person I > do the work for won't change. Greg, Why was it hard for you to switch to aptitude? Thanks, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: apt-get
On Fri, May 18, 2007 at 12:29:56PM -0400, Jose Luis Rivas Contreras <[EMAIL PROTECTED]> was heard to say: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Howard Young escribió: > > looking through the list I now see that may be quite possible to achieve > > what I wanted using, some sort of match priority command and piping it > > back into the remove command. > > You should try using aptitude, it does what you want ;-) Not if he wants suggestions. Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: apt-get
On Fri, May 18, 2007 at 10:50:06AM -0600, Warren Turkal <[EMAIL PROTECTED]> was heard to say: > On Friday 18 May 2007 08:03, Howard Young wrote: > > Thank you for this link. I have read the information but it seems not to > > have a specific option for what I want. > > If you use aptitude for everything, it will keep track of packages that are > automatically installed when a specific package is installed. For instance, > if I install a package that pulls in libpq4, I can remove that package and > aptitude will remove the libpg4 assuming I haven't installed anything else > that depends on it. I believe this functionality would address what you want. > The key is that you have to use aptitude for all package > installation/uninstallation tasks. This is not true for suggested packages. Aptitude had a flag to install suggested packages, but I removed it because turning it on was almost always useless. You can enable Keep-Suggests and manually set the suggested packages to automatic mode, but this will hold *all* suggestions on the system, effectively disabling the auto-removal feature (since the suggests graph is very dense -- if you follow suggests, a large fraction of the package database will be installed/kept on the system). There is presently no mechanism in aptitude for tagging particular dependencies, and this is not a trivial problem (because you need to "follow" the dependency as the cache changes under you; guess wrong and you'll remove software the user still wants!) Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Reasons for recommends and suggests
On Thu, May 17, 2007 at 06:22:11PM +0100, Neil Williams <[EMAIL PROTECTED]> was heard to say: > On Thu, 17 May 2007 11:29:16 +0200 > Hendrik Sattler <[EMAIL PROTECTED]> wrote: > > My problem with the current situation that you either do the policy of > > always > > installing such stuff or you don't. There is no way to decide case by case > > because there is definitely information missing in the description of > > packages. > > You install a Recommends or Suggests when you want to use some part of > the package that uses it. The obvious place to document such > requirements is the manpage for the optional script. In most cases, > users simply don't need to use those options. When aptitude displays its list of "here's what I'll do", there's a section for packages being automatically installed, and one for recommended/suggested packages that are not being installed. Right now it says things like: foo recommends bar (>= 1.2.3) I would really like to have it say: foo recommends bar (>= 1.2.3) to frobnicate the whazzit. My thought on this topic has been to do something like: Recommends-Reason: bar (>= 1.2.3); to frobnicate the whazzit. These fields would be purely decorative, so they could be ignored by the core algorithms (no need to rewrite dpkg's Depends parsing). They also don't clutter up the Depends line, which is IMO likely to be important if you're just trying to read through the dependencies. My general feeling is that these would be unlikely to have enough uptake to justify implementing them...but if a patch were to drop from heaven (or I suddenly found that I had a week of free time, hah) I would be happy to give it a shot. Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian desktop -situation, proposals for discussion and change. Users point of view.
On Mon, May 14, 2007 at 02:55:40PM +0200, "Mgr. Peter Tuharsky" <[EMAIL PROTECTED]> was heard to say: > Debian developers often see "Ubuntu the enemy" and are mocking it as > inferior technology. However, they fail to see, what does the Debian > really offer to desktop users eventually. They fail to understand, why > are they using Ubuntu happily and reference it to novices. It seems, > that desktop users don't see Debian fitting their needs. What are the means? When you talk about "desktop users", I think you really mean "novice consumers". Is that a fair assessment? In my experience, Debian can work just fine on the desktop in some situations, just not for novice home users. (think, e.g., about desktops for office workers) > b, Stability > > It simply depends on, well, luck on choosing the particulary good > version of software. With stable upstream versions of software, there > should not be major stability issues anyhow. > > Debian proclaims to offer excellent stability. However, if some > application does have stability issues, users must wait at least 2 years > for next "stable" version of Debian to see the fix. The stability is not > automatically guaranteed by oldness of software and lack of upgrades in > Debian. The word "stable" with regard to Debian's repositories doesn't mean "works without bugs". Every piece of software has bugs, and in general, if a newer version of the software appears to have less bugs, that's a reflection of the fact that there's been less time for people to report the bugs it contains. Debian stable is "stable" in the sense of "solid rock" versus "shifting sands": we ensure that the behavior of the system won't change during a stable cycle. There might be bugs in it, but they'll be the same bugs throughout stable's lifetime. Why would you want this? In a setting where you have people doing productive work using a piece of software, unnecessary changes to the software are *worse* in the short term than a fixed and unchangable set of bugs: not only are changes likely to break the software, but they may require users to retrain or disrupt the processes of your organization. This is true even if the new software is an unqualified improvement (either in terms of bug count or usability) over the old software; look at the backlash over the new Ribbon interface in Microsoft office, for instance. Having briefly overseen a small network of Debian systems for a research group, my sense is that an 18-month cycle would work well in this setting; anything shorter than a year would be too disruptive. I await correction from more experienced members of this list who can tell me I'm full of it. :) Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: /etc/udev/rules.d non-symlinks
On Tue, Apr 10, 2007 at 12:11:57PM +0200, Loïc Minier <[EMAIL PROTECTED]> was heard to say: > On Mon, Apr 09, 2007, Joey Hess wrote: > > The intent is to let users disable a udev rule by removing the symlink, or > > reorder a rule to a different number by renaming the symlink. Putting a > > rules > > conffile directly in /etc/udev/rules.d/ wouldn't allow for this, and as > > Marco > > says in #359614, this "may be useful. Or at least appeared to be useful when > > I designed this." My question is simply whether anyone actually finds this > > useful? > > Can we encode the number in the rule itself? Perhaps in the comments > at the top of the file. >This would allow dpkg to handle numbering changes correctly. You could look at how file-rc handles a similar problem -- IIRC it replace update-init.d with a script that edits a file in /etc. Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: For those who care about stable updates
On Sun, Mar 12, 2006 at 12:20:25PM +0100, Frank Küster <[EMAIL PROTECTED]> was heard to say: > Andreas Barth <[EMAIL PROTECTED]> wrote: > > > Actually, in case stockholm gets elected, > > Sorry, where's the Wiki page describing codenames for DPL candidates? Wait, you mean we aren't putting European cities forward for DPL-ship? ;-) Daniel signature.asc Description: Digital signature
Re: Obsolete packages in Experimental
On Wed, Jan 25, 2006 at 04:25:52PM +0100, Jérôme Warnier <[EMAIL PROTECTED]> was heard to say: > Le vendredi 20 janvier 2006 à 14:17 +, Paul Brossier a écrit : > > On Fri, Jan 20, 2006 at 04:09:28AM -0600, Peter Samuelson wrote: > > > > > > [Jérôme Warnier] > > > > Or even better: a list of all packages already installed on my system > > > > which have an experimental version? > > > > > > There might be a better way, but assuming you have experimental in your > > > sources.list... > > > > > > > aptitude search ~Aexperimental | grep ^i > Right, and if the second character on the line is a B, that means this > packages is already from experimental. > So you could filter the ones you could still upgrade with: > aptitude search ~Aexperimental | grep ^i|grep -v ^iB Err, the B means that the package is currently in a broken state. That might be strongly correlated with being experimental, but there's no guarantee in either direction ;-). To get a list of currently installed experimental packages, install aptitude >= 0.4.0 and do: aptitude search '~S~i~Aexperimental'. Daniel signature.asc Description: Digital signature
Re: Aptitude question
On Mon, Jan 16, 2006 at 10:57:22AM +0900, Miles Bader <[EMAIL PROTECTED]> was heard to say: > Daniel Burrows <[EMAIL PROTECTED]> writes: > > When you say that normal operation is getting slower, do you mean just > > the load time or its overall performance? The time required to load > > in all the state files is a bit long, but once they're loaded the > > program seems to run reasonably quickly to me. > > The really problematic thing is indeed the state-file loading time; it > seems to take 30 - 40 seconds on my machine (with no disk I/O as the > files are already cached by the kernel). It would be interesting to see profile data for this. The new aptitude has a "nop" command that does nothing but load the cache and then stop, the better to get profiling information (but it's too fast on my computer to yield useful results). A lot of what aptitude is doing there is parsing RFC822-alike files using core apt code, and it's possible that the apt end of things could be optimized. There's even a patch in the BTS that eliminates various unnecessary copies (#$319377), although it might be better in some cases to prevent aptitude from calling those routines so many times (e.g., it should really be caching configuration values rather than doing lookups in the middle of a long loop). > Normal operation is generally OK, though some searches (e.g. "~dfoo") > are so slow as to be almost useless -- especially given that it's > "i-search", so a super-slow search gets repeated for every key as you > type the search string! I suspect that the problem with searches is due to locality: aptitude has to access several structures/files to perform a search, and (IIRC) it only attempts to order accesses along one "axis". i.e., it accesses packages in the order that they occur in the main cache, but this isn't necessarily the same order that they occur in, e.g., the Description files. If you look at the apt-cache code, in contrast, you'll see that it does a two-pass search, first iterating through the package cache to match package names, then sorting packages according to their order in the description file to match descriptions. This is easy for apt-cache, since it only has one type of match; aptitude's much more complex matching language and search architecture would require some more effort to optimize this way. I had some notes at one point on modifying aptitude's search to be multi-pass in order to increase locality, but I didn't get around to carrying through on the project. > > The main thing that changed recently that would impact the program's speed > > under normal use is the switch to using Unicode internally, which means that > > many string manipulations take 4x as long, and input strings (e.g., from > > package descriptions) have to be decoded before they're used. > > Do you know if the package/state files so large that it's really running > against fundamental memory bandwidth problems? I've noticed (in my own > programs) that some standard C++ library code, e.g. reading from > io-streams, seems suspiciously slow (though I've not confirmed this with > measurements)... I doubt that the code is hitting any fundamental limits, since you mentioned that the program is slow even when everything is cached. The standard library generally seems reasonably quick to me, although I avoid iostream input like the plague. Daniel signature.asc Description: Digital signature
Re: Aptitude question
On Tue, Jan 10, 2006 at 11:41:25AM +0900, Miles Bader <[EMAIL PROTECTED]> was heard to say: > Daniel Burrows <[EMAIL PROTECTED]> writes: > > [0] alert readers will note that the caveat "if the user waits for a > > sufficient amount of time" has to be added here; however, this is typically > > much less than one second per solution on my hardware. > > Er, what _is_ your hardware anyway? Though I love the aptitude interface > and functionality, I've noticed that on my home machine (not so fast, but > not too bad with average software), normal aptitude operation has been > getting more and more slothlike in recent times, to the point where I often > just hit ^C to exit after upgrading, instead of waiting ages for all the > "updating random stuff #11, very slowly... 2%" stuff to finish before I can > type "q" At the moment I'm using a laptop with a Pentium 4 chip. When you say that normal operation is getting slower, do you mean just the load time or its overall performance? The time required to load in all the state files is a bit long, but once they're loaded the program seems to run reasonably quickly to me. The main thing that changed recently that would impact the program's speed under normal use is the switch to using Unicode internally, which means that many string manipulations take 4x as long, and input strings (e.g., from package descriptions) have to be decoded before they're used. Daniel signature.asc Description: Digital signature
Re: Trivial bug on apt-file (Was : Re: Development standards for unstable)
On Fri, Jan 13, 2006 at 02:34:32PM +0900, Charles Plessy <[EMAIL PROTECTED]> was heard to say: > As stated by the Debian Policy Manual : > > "The Depends field should be used if the depended-on package is required > for the depending package to provide a significant amount of > functionality." > > and > > "The Recommends field should list packages that would be found together > with this one in all but unusual installations." Something that may have been lost earlier in this thread is that apt-file *does* Recommend curl. The apt-file maintainer believes that it is useful enough to install apt-file without curl to justify weaking that to a Recommendation. Unless you are going to discuss that point specifically, the proper place to send your complaints is bug #42266. Daniel signature.asc Description: Digital signature
Re: Aptitude question
On Sat, Jan 07, 2006 at 12:51:55AM +0100, Jiří Paleček <[EMAIL PROTECTED]> was heard to say: > On Wed, 04 Jan 2006 19:50:14 +0100, Linas Zvirblis <[EMAIL PROTECTED]> > wrote: > > >Jiri Palecek wrote: > >>How does aptitude decide which one to choose? Shouldn't it > >>prefer to do something that won't break other packages? Or should > >>it ask the user for help? > > >As for your problem, you must provide way more information than just "it > >does not work" in order to get help. There are at least five different > >versions of aptitude you could be using on whatever version of Debian > >you use. Most of us cannot read minds, especially over the Internet. > > If you had read (at least the written protion of) my mind more carefully, > you would realize that I have never said "it does not work". I thought it > more as a feature request (or idea) than bug report. I was asking about > how is aptitude supposed to solve such situations, beacuse it isn't clear > if it really should try to guess the correct packages to install. The problem is that of the five versions Linas referred to, there are at least two separate ways of resolving such situations, which are likely to behave differently in your case. > Then, try to install "A". This will, in my version of aptitude > (0.2.15.9-7), > breaks package "D". However, the constraints are satisfiable by downgrading > package "B". The version in unstable (0.4.*) can calculate every (interesting) solution to a given dependency problem [0] and will show as many as you ask for. > As you had already noted, it greatly depends on the particular system (you > don't wanna read my /var/lib/dpkg/available and status, do you?). I thought > it more as an illustrative example. Actually, I often end up loading other people's system state files in the course of bug-hunting. Daniel [0] alert readers will note that the caveat "if the user waits for a sufficient amount of time" has to be added here; however, this is typically much less than one second per solution on my hardware. signature.asc Description: Digital signature
Re: Proposal/Request for Comments: Formally extending package Descriptions to handle bulleted lists.
On Tue, Dec 13, 2005 at 01:21:41AM +0100, Jeroen van Wolffelaar <[EMAIL PROTECTED]> was heard to say: > On Mon, Dec 12, 2005 at 03:09:52PM -0800, Daniel Burrows wrote: > > Extensions to the syntax of Description blocks: > > > > As mentioned above, all lines beginning with two or more spaces are > > treated identically under current Policy. This proposal introduces > > the concept of a /bulleted block/. A bulleted block consists of a > > series of lines such that: > > s/lines/series of items/, otherwise, you'd have a a series of lines that > each consist of a number of lines: ambigious (or at least confusing) > wording. Each bulleted block is one bullet item -- the syntax doesn't care about sequences of items, just individual ones (although the frontend is free to treat sequences differently from lone items). This can probably be made clearer. How about this wording? = snip here = As mentioned above, all lines beginning with two or more spaces are treated identically under current Policy. This proposal introduces the concept of a /bulleted block/. A bulleted block represents the contents of a single list item; it consists of a series of lines such that: = snip here = > > (2) The first non-space character of the first line is a bullet > > character, and > > > > (3) Each subsequent line begins with at least N + 1 + M spaces, > > where M is the number of spaces immediately following the first > > non-space character of the first line. > > I'd note that M might be as small as zero. This is implied by the lack > of prohibition in (2), but it can't hurt to be clear. As was noted in another reply, it probably makes sense to require M == 1 in the spec; only a few packages that I've seen use anything else and it looks best in legacy frontends. > > For the purposes of this definition, the bullet characters are [*-+]. > > Better write [*+-], to prevent needless ambiguity with regex syntax, > where [*-+] actually means '*' or '+', excluding '-'. Or just list the > three characters. Good point. I'm afraid that I'm guilty of being a bit lazy here. > In concreto, I'd suggest using the following definition instead, also > covering the nested bulleting that's only defined-by-example below: It actually is defined, but you have to read between the lines. (it's the bit about parsing as if N+M spaces were stripped) Unfortunately, my example was wrong! (see attachment) > For in policy 5.6.12: [snip] As you noted, this is a bit hard to read; I'll probably tackle the problem of writing this up for Policy at some point in the future, once there's some agreement on what the format should be. > > The following are examples of bulleted blocks: > > > > = snip here = > > * If Peter Piper picked a peck of pickled peppers, how many pickled > > peppers did Peter Piper pick? > > > > *Fourscore and > > seven years ago, > > our forefathers brought forth upon this continent > > a new nation. > > . > >-- Abraham Lincoln, 16th President of the United States of America > > According to your and my definition, this would be a bullet item too, > like (in HTML) - Abraham Lincoln (...) America ? Or how do I > misread your definition then, if this is *not* an instance of a bulleted > list? Yes, that's a good point. My example includes something that parses incorrectly :-). Note, however, that in the wild there are exactly two packages that break this way in aptitude out of the whole archive (checked with a regexp search), and that even these would not break if we required a space after the bullet character. > Alternative: > > A totally different way might be to exploit policy's opportunity to > extending the description syntax. Policy 5.6.12 explicitely states that > lines starting with a dot should not be used and are left open for > future expansions. So why not use *that*? Like, definition by example: I don't like this approach as much for a couple reasons -- it's not as natural (the format I proposed looks fine without any interpretation at all), you'd have to edit a lot of packages (most bulleted lists are in the right format already, in my observation), and it might not display properly in legacy frontends (frontends might display them literally, but Policy is silent on how these lines should be handled; aptitude IGNORES everything past the dot!) Daniel signature.asc Description: Digital signature
Re: Proposal/Request for Comments: Formally extending package Descriptions to handle bulleted lists.
On Tue, Dec 13, 2005 at 12:01:52AM +, Roger Leigh <[EMAIL PROTECTED]> was heard to say: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Daniel Burrows <[EMAIL PROTECTED]> writes: > > > The attached text is a first draft of a proposed extension to the > > Description field to explicitly handle bulleted lists. > > That's quite a complex document for something I believe should be > quite simple. > > When I use Emacs, it can reflow text (M-q) by looking at the > indentation level of the following lines. It can even cope with > bullets, outdents, indents, etc. If a frontend display routine could > handle that, that would solve the problem generically, and would > handle any level of indentation required. The heart of the document describes how to do this in a simple and precise way. The first section explains some reasons that it's useful to recognize bulleted lists, while the last couple sections have implementation notes and analysis of the impact on current frontends and Descriptions. > Specifically regarding bullets: We now have UTF-8 encoded control > files, so why not simply use the UCS bullet character (U+2022)? It might make sense to recognize the Unicode bullet character, but forcing people to use it is not a good idea for several reasons, with backwards-compatibility being a major one. Daniel signature.asc Description: Digital signature
Re: Proposal/Request for Comments: Formally extending package Descriptions to handle bulleted lists.
On Mon, Dec 12, 2005 at 05:49:02PM -0600, Peter Samuelson <[EMAIL PROTECTED]> was heard to say: > > [Daniel Burrows] > > (1) The first line begins with N > 2 spaces, > > Don't you mean N >= 2? > > > (2) The first non-space character of the first line is a bullet > > character, and > > > > (3) Each subsequent line begins with at least N + 1 + M spaces, > > where M is the number of spaces immediately following the first > > non-space character of the first line. > > I think that's overgeneral. I do not see the point in allowing M != 1. > I say keep the spec simple; forcing frontends to include parsing > complexity that doesn't even add anything useful is a Bad Thing. > > (If aptitude wants to handle M != 1 in order to make certain legacy > descriptions look better, fine, but I don't think it should be > explicitly condoned.) Good point. I've adjusted this in my copy (updated version attached). Daniel Abstract: This document describes a proposed extension to the Description formatting policy (policy section 5.6.13) to support better formatting of bullet lists in package descriptions. The proposed policy is primarily a formalization of existing best practice regarding bullets; most current package descriptions will parse as expected with no changes, and packages that do not can easily be converted to the new format without degrading presentation in legacy package management tools. The Description extensions described in this document are presently implemented in aptitude (>= 0.4.0). Background and Motivation: Policy 5.6.23 provides for "preformatted" lines in descriptions. These are lines beginning with at least two spaces, and will be displayed verbatim; they are either unwrapped or hard-wrapped. The current best-practice approach to including bullet lists in package descriptions is to write each line of the list as a preformatted line; for instance, = snip here = QEMU is a FAST! processor emulator: currently the package supports arm, powerpc, sparc and x86 emulation. By using dynamic translation it achieves reasonable speed while being easy to port on new host CPUs. QEMU has two operating modes: . * User mode emulation: QEMU can launch Linux processes compiled for one CPU on another CPU. * Full system emulation: QEMU emulates a full system, including a processor and various peripherials. It enables easier testing and debugging of system code. It can also be used to provide virtual hosting of several virtual PC on a single server. . As QEMU requires no host kernel patches to run, it is very safe and easy to use. = snip here = This convention has several serious limitations, however. Perhaps most importantly, it does not gracefully accomadate smaller terminals; while other paragraphs are word-wrapped by conforming user interfaces, word-wrapping of these preformatted paragraphs is (rightly) forbidden. This leads to poor readability when the terminal size is decreased; for instance, formatting to 60 columns produces: = snip here = QEMU is a FAST! processor emulator: currently the package supports arm, powerpc, sparc and x86 emulation. By using dynamic translation it achieves reasonable speed while being easy to port on new host CPUs. QEMU has two operating modes: * User mode emulation: QEMU can launch Linux processes compi led for one CPU on another CPU. * Full system emulation: QEMU emulates a full system, includ ing a processor and various peripherials. It enables easier test ing and debugging of system code. It can also be used to provide virtual hosting of several virtual PC on a single server. . As QEMU requires no host kernel patches to run, it is very safe and easy to use. = snip here = In contrast, the proposed mechanism allows this description to be formatted in 60 columns as follows: = snip here = QEMU is a FAST! processor emulator: currently the package supports arm, powerpc, sparc and x86 emulation. By using dynamic translation it achieves reasonable speed while being easy to port on new host CPUs. QEMU has two operating modes: * User mode emulation: QEMU can launch Linux processes compiled for one CPU on another CPU. * Full system emulation: QEMU emulates a full system, including a processor and various peripherials. It enables easier testing and debugging of system code. It can also be used to provide virtual hosting of several virtual PC on a single server. As QEMU requires no host kernel patches to run, it is very safe and easy to use. = snip here = Extensions to the syntax of Description blocks: As mentioned above, all lines beginning with two or more spaces are treated identically under current Policy. This proposal introduce
Re: Proposal/Request for Comments: Formally extending package Descriptions to handle bulleted lists.
On Mon, Dec 12, 2005 at 06:38:59PM -0500, sean finney <[EMAIL PROTECTED]> was heard to say: > On Mon, Dec 12, 2005 at 03:09:52PM -0800, Daniel Burrows wrote: > > The attached text is a first draft of a proposed extension to the > > Description field to explicitly handle bulleted lists. The extended > > wow! that's quite a document. i'm glad to see that people are > focusing on the Really Big problems facing debian today. > > okay, that was a bit punchy... sorry i couldn't help it :) > > seriously though, i think the proposal is quite well written. the only > critique i have is that i think it's maybe going a little too far out > there to talk about nested lists, as i can't imagine them being at all > practical in what's supposed to be a short, informative description of > a package. That's a fair point, but I felt that there wasn't any reason to artificially restrict the sorts of lists that could be handled when nested lists can be dealt with in such a natural fashion. There are at least a few cases where I can imagine two-level lists being useful, and they seem to exist in the wild (see samhain and xml-core, for instance). One interesting question that I can see is whether to treat a *word-wrapped* line that starts with a bullet character as a bulleted item. Doing so would make several more natural ways of expressing lists work, especially nested lists -- the example in my document is actually wrong! On the other hand, doing this at the top-level would mean that conforming descriptions wouldn't degrade cleanly, while doing it only for sub-lists is inelegant. Daniel signature.asc Description: Digital signature
Proposal/Request for Comments: Formally extending package Descriptions to handle bulleted lists.
The attached text is a first draft of a proposed extension to the Description field to explicitly handle bulleted lists. The extended syntax allows list items to be treated specially by frontends (for instance, bullet characters can be replaced with graphics, and the body of the list item can be word-wrapped); current Descriptions should either parse correctly or be no worse off than they currently are. Current versions of aptitude implement this proposal. Daniel Abstract: This document describes a proposed extension to the Description formatting policy (policy section 5.6.13) to support better formatting of bullet lists in package descriptions. The proposed policy is primarily a formalization of existing best practice regarding bullets; most current package descriptions will parse as expected with no changes, and packages that do not can easily be converted to the new format without degrading presentation in legacy package management tools. The Description extensions described in this document are presently implemented in aptitude (>= 0.4.0). Background and Motivation: Policy 5.6.23 provides for "preformatted" lines in descriptions. These are lines beginning with at least two spaces, and will be displayed verbatim; they are either unwrapped or hard-wrapped. The current best-practice approach to including bullet lists in package descriptions is to write each line of the list as a preformatted line; for instance, = snip here = QEMU is a FAST! processor emulator: currently the package supports arm, powerpc, sparc and x86 emulation. By using dynamic translation it achieves reasonable speed while being easy to port on new host CPUs. QEMU has two operating modes: . * User mode emulation: QEMU can launch Linux processes compiled for one CPU on another CPU. * Full system emulation: QEMU emulates a full system, including a processor and various peripherials. It enables easier testing and debugging of system code. It can also be used to provide virtual hosting of several virtual PC on a single server. . As QEMU requires no host kernel patches to run, it is very safe and easy to use. = snip here = This convention has several serious limitations, however. Perhaps most importantly, it does not gracefully accomadate smaller terminals; while other paragraphs are word-wrapped by conforming user interfaces, word-wrapping of these preformatted paragraphs is (rightly) forbidden. This leads to poor readability when the terminal size is decreased; for instance, formatting to 60 columns produces: = snip here = QEMU is a FAST! processor emulator: currently the package supports arm, powerpc, sparc and x86 emulation. By using dynamic translation it achieves reasonable speed while being easy to port on new host CPUs. QEMU has two operating modes: * User mode emulation: QEMU can launch Linux processes compi led for one CPU on another CPU. * Full system emulation: QEMU emulates a full system, includ ing a processor and various peripherials. It enables easier test ing and debugging of system code. It can also be used to provide virtual hosting of several virtual PC on a single server. . As QEMU requires no host kernel patches to run, it is very safe and easy to use. = snip here = In contrast, the proposed mechanism allows this description to be formatted in 60 columns as follows: = snip here = QEMU is a FAST! processor emulator: currently the package supports arm, powerpc, sparc and x86 emulation. By using dynamic translation it achieves reasonable speed while being easy to port on new host CPUs. QEMU has two operating modes: * User mode emulation: QEMU can launch Linux processes compiled for one CPU on another CPU. * Full system emulation: QEMU emulates a full system, including a processor and various peripherials. It enables easier testing and debugging of system code. It can also be used to provide virtual hosting of several virtual PC on a single server. As QEMU requires no host kernel patches to run, it is very safe and easy to use. = snip here = Extensions to the syntax of Description blocks: As mentioned above, all lines beginning with two or more spaces are treated identically under current Policy. This proposal introduces the concept of a /bulleted block/. A bulleted block consists of a series of lines such that: (1) The first line begins with N > 2 spaces, (2) The first non-space character of the first line is a bullet character, and (3) Each subsequent line begins with at least N + 1 + M spaces, where M is the number of spaces immediately following the first non-space character of the first line. For the purposes of this definition, the bullet characters are [*-+]. The following are examples of bulleted blocks: = snip here = * If Peter Piper picked a peck of pickled pepp
Re: Debian and the desktop
On Mon, Dec 12, 2005 at 08:25:49PM +0100, Simon Richter <[EMAIL PROTECTED]> was
heard to say:
> >-default sound setup
>
> Sound is symptomatic of a much larger class of problems, namely that
> there is no system service that forwards resources other than display
> and keyboard to the user currently logged in... [snip]
> What would be required is some resource
> forwarding framework in which a priviledged process will pass out
> handles to sound/usb/floppy/... [snip]
>
> >-default wireless setup
>
> This is also related to the clash of the two approaches ("multiuser
> system with capable admin" versus "single-user personal system where all
> users need admin priviledge to associate to new APs as they roam with
> their laptop"). What we need is a solution that handles the in-between
> cases as well, and it's not Debian specific either.
Essentially what you are saying is that since we can't provide a 100%
generic solution that works perfectly in every concievable situation by
default, we shouldn't bother making the default install work better in
any situation (even, say, one that accounts for the overwhelming majority
of current and potential users). This is certainly in keeping with Debian
tradition, and it's also the reason I now hand out Ubuntu CDs instead of
Debian ones to new users.
Daniel
signature.asc
Description: Digital signature
Re: [RFC] xulrunner, shlibs, and dependencies.
On Sat, Dec 03, 2005 at 12:28:36AM -0800, Steve Langasek <[EMAIL PROTECTED]> was heard to say: > On Sat, Dec 03, 2005 at 08:58:45AM +0100, Mike Hommey wrote: > > Will all the tools resolving the dependencies be fine with a dependency > > on a virtual package without one an a real package ? (like for > > zlib1g-dev | libz-dev) > > Yes. See apt's Provides for an example of this. Just in case there's any confusion: the problem with depending only on a virtual package is that some tools tend to pick an arbitrary Provider of the package, which can in turn lead to unpredictable behavior. If only one provider at a time is installable, this shouldn't be a problem, though. Daniel signature.asc Description: Digital signature
Re: Spliting packages between pkg and pkg-data
On Mon, Nov 21, 2005 at 04:26:34PM +0100, Goswin von Brederlow <[EMAIL PROTECTED]> was heard to say: > Nicolas Boullis <[EMAIL PROTECTED]> writes: > > > On Sun, Nov 20, 2005 at 12:13:48PM +0100, Bill Allombert wrote: > >> Hello Debian developers, > >> > >> When doing research about circular-deps, I looked at a lot of packages > >> that are split between a binary package and a data package. This is a > >> good thing since this reduce the total siez of the archive, however > >> there are simple rules that should be followed: > >> > >> 3) Keep the files that 'signal' executables in the same package than the > >>executable (e.g. menu file, program manpage). > > > > Why? I agree that it menu files and manpages are generally not that > > large, but what would it break to have them in pkg-data? > > (I would consider it strange to have such files out of the main pkg > > package, but it looks policy-compliant as far as I can see...) > > > > > > Nicolas > > foo depends on foo-data. But foo-data does NOT depend on foo. > > So an "apt-get install foo-data", while being useless, is consistent > for dpkg. After that you would end up with a menu entry for foo but no > foo binary. Shouldn't menu refuse to create menu entries for "foo" if the foo package is not installed? At least, I thought that's what ?package(foo): ... meant. Daniel signature.asc Description: Digital signature
