Bug#428256: ITP: ffrenzy -- Multiplayer platform with dwarfs fighting with/for food
Package: wnpp Severity: wishlist Owner: Paul van Tilburg <[EMAIL PROTECTED]> * Package name: ffrenzy Version : 1.0.2 Upstream Authors: Bas Kloet <[EMAIL PROTECTED]>, Christian Luijten <[EMAIL PROTECTED]>, Emiel Neggers <[EMAIL PROTECTED]>, Bram Senders <[EMAIL PROTECTED]>, Sjoerd Simons <[EMAIL PROTECTED]>, Paul van Tilburg <[EMAIL PROTECTED]> * URL : http://ffrenzy.luon.net/ * License : GPL Programming Lang: C mainly, Python for the menu and utils Description : Multiplayer platform with dwarfs fighting with/for food Dwarfs need to collect food as fast as possible to bring it back to their mushrooms to live. When a dwars leaves his home without providing it with food too long, it dies from hunger. The collected food can be thrown at other dwarfs, making them unconscious when hit. When a power-up is picked up, thrown food will have special powers! This is a distributed network game for two to eight players. One instance needs to act as server for syncing player names and the levels. N.B. A package of Feeding Frenzy! is already available in our repository: deb http://luon.net/debian/ unstable main Regards, Paul -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (102, 'experimental') Architecture: powerpc (ppc) Kernel: Linux 2.6.18-4-powerpc Locale: LANG=C, LC_CTYPE=nl_NL.UTF8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: synchronizing README.Debian with wiki.debian.org
Junichi Uekawa <[EMAIL PROTECTED]> wrote: > Hi, > >> > I had an idea and still pondering on it. I wanted to do automatic >> > two-way synchronization with README.Debian and wiki.debian.org >> >> Excuse me - which existing wiki pages are synchronized with >> README.Debian? > > > I don't really know of any, [...] > My personal impression is that although we have this system of > maintaining 'README.Debian', it's often outdated on most packages. It > might help if users have direct (although maintainers should really > check the contents) influence on its contents. Ah, I understand. Yes, it *is* a good idea. I don't know whether we're the only ones, but tex-common has a "README.Debian.$ext" in txt, pdf and html/* format (prepared with debiandoc-sgml), which replaces README.Debian. How would your script interact with that situation? [Actually it's called "TeX-on-Debian.*", the naming has historical reasons, and I'd rather not rename it, but we could easily add a symlink from README.Debian to it. The general point is still: README.Debian in different formats] Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
arch-all-package shown with two versions on p.d.o (was: Bug#427859: lmodern fails to configure on upgrade, dpkg error)
Hi all, Florent noticed that for tex-common, two versions are listed as being available in testing although the package is Arch: all: Florent Rougon <[EMAIL PROTECTED]> wrote: > BTW, I don't understand why both 1.0.1 and 1.7 are listed for > testing at: > > http://packages.debian.org/cgi-bin/search_packages.pl?keywords=tex-common&searchon=names&subword=1&version=all&release=all > > Any idea? I have none, is anyone able to help? Is this a problem in the script that generates packages.debian.org's information, or elsewhere? Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: Large static datasets like genomes (Re: Reasonable maximum package size ?)
On Sat, 9 Jun 2007, Steffen Moeller wrote: It would be lovely if we could agree on a set of databases to support in Debian and to have a permanent location in the file system for them. For the reasons that Tim has already outlined I do not see to distribute the larger database as Debian packages. Once a (computational) biologist starts a new project, (s)he wants the latest data no matter what and anything older than three months (or a week sometimes) is likely not to be acceptable. I do not see any packaging effort to work for that and particularly not in the way we think of the stable distribution. Well, but some kind of /etc/biodata/sources.list that is parsed by some downloader via cronjob and putting the data into the location you mentioned above comes into mind. I do not ask for the impossible but for supporting users. I as a user would be bored by doing things my computer could do itself. What may be stable though is an application that install the latest databases for the user. And maybe that application would even know how to make use of the diffs to the respective latest release that many databases like EMBL offer in order to reduce download times (we are talking about many Gigs for these big players). I could well imagine, that an application that maintains the most important databases of say the Nucleic Acids Research's January issue could well be publishable and may be a nice project for a summer student to start off. Any volunteers on this list by any chance? Ah yes - I see we share quite the same idea. I am not certain about how to reference a such auto-maintained particular database from other packages. Maybe there could be something like virtual packages that depend on the auto-biodb-maintaintenance tool and call it in their postinst scripts as $ auto-biodb-maintaintenance --make-sure-it-is-maintained dbname Something like that. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
dh_installman problems
Hi, I am trying to teach myself to package up a program for debian, but can't get the manpage I have written to work properly. It has the line '.TH CAJUN 1 "June 10, 2007"' near the top of the file and is named cajun.1 in the debian dir inside the src package dir. dh_installman seems to ignore the file and not install it in the build. What am I missing? does dh_installman need an argument? I thought it searched the debian dir for files that have the .TH line and installs them. Anton -- Anton Piatek email: [EMAIL PROTECTED] blog/photos:http://www.strangeparty.com pgp: [0xB307BAEF] (http://tastycake.net/~anton/anton.asc) fingerprint: 116A 5F01 1E5F 1ADE 78C6 EDB3 B9B6 E622 B307 BAEF pgpKk26xgCYp2.pgp Description: PGP signature
Re: arch-all-package shown with two versions on p.d.o (was: Bug#427859: lmodern fails to configure on upgrade, dpkg error)
Hi, On Sun, Jun 10, 2007 at 02:17:49PM +0200, Frank Küster wrote: > Florent noticed that for tex-common, two versions are listed as being > available in testing although the package is Arch: all: > > Florent Rougon <[EMAIL PROTECTED]> wrote: > > > BTW, I don't understand why both 1.0.1 and 1.7 are listed for > > testing at: > > > > http://packages.debian.org/cgi-bin/search_packages.pl?keywords=tex-common&searchon=names&subword=1&version=all&release=all > > > > Any idea? > > I have none, is anyone able to help? Is this a problem in the script > that generates packages.debian.org's information, or elsewhere? packages.debian.org is only informative, not authorative (e.g., it is always a day or two behind). rmadison says: nighthawk~$ rmadison -s testing tex-common tex-common |1.7 | testing | source, all The only totally authorative measure is madison on ftp-master directly, but that's restricted. Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dh_installman problems
On Sunday 10 June 2007 17:04, Anton Piatek wrote: > I am trying to teach myself to package up a program for debian, but can't > get the manpage I have written to work properly. > It has the line '.TH CAJUN 1 "June 10, 2007"' near the top of the file and > is named cajun.1 in the debian dir inside the src package dir. > dh_installman seems to ignore the file and not install it in the build. > > What am I missing? does dh_installman need an argument? I thought it > searched the debian dir for files that have the .TH line and installs them. No, you must have misread the dh_installman manpage. You have to tell dh_installman which manpages to install in which package, then dh_installman looks at the .TH lines of those manpages and determines what sections to put them in. -- Magnus Holmgren[EMAIL PROTECTED] (No Cc of list mail needed, thanks) pgpJdzAt5Vfdg.pgp Description: PGP signature
aptitude removals (was Re: APT 0.7 for sid)
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". Anyway, if it's resolved, I'll have to give aptitude a try. I second Michael in thanking you for "bringing this feature at the right place". -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: arch-all-package shown with two versions on p.d.o (was: Bug#427859: lmodern fails to configure on upgrade, dpkg error)
On Sun, Jun 10, 2007 at 02:17:49PM +0200, Frank Küster wrote: > Hi all, > > Florent noticed that for tex-common, two versions are listed as being > available in testing although the package is Arch: all: > > Florent Rougon <[EMAIL PROTECTED]> wrote: > > > BTW, I don't understand why both 1.0.1 and 1.7 are listed for > > testing at: > > > > http://packages.debian.org/cgi-bin/search_packages.pl?keywords=tex-common&searchon=names&subword=1&version=all&release=all > > > > Any idea? > > I have none, is anyone able to help? Is this a problem in the script > that generates packages.debian.org's information, or elsewhere? rmadison only lists 1.7. Julian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dh_installman problems
On Sun, Jun 10, 2007 at 04:04:44PM +0100, Anton Piatek wrote: > Hi, > I am trying to teach myself to package up a program for debian, but can't get > the manpage I have written to work properly. > It has the line '.TH CAJUN 1 "June 10, 2007"' near the top of the file and is > named cajun.1 in the debian dir inside the src package dir. > dh_installman seems to ignore the file and not install it in the build. > > What am I missing? does dh_installman need an argument? I thought it searched > the debian dir for files that have the .TH line and installs them. > As a point of information, there is a mailing list/website to assist in making Debian packages: http://mentors.debian.net and http://lists.debian.org/debian-mentors/ Also the Wiki: http://wiki.debian.org/HowToPackageForDebian -k -- | .''`. == Debian GNU/Linux == | my web site: | | : :' : The Universal |mysite.verizon.net/kevin.mark/| | `. `' Operating System| go to counter.li.org and | | `-http://www.debian.org/ |be counted! #238656 | | my keyserver: subkeys.pgp.net | my NPO: cfsg.org | |join the new debian-community.org to help Debian! | |___ Unless I ask to be CCd, assume I am subscribed ___| pgpn0uZpXrBfr.pgp Description: PGP signature
Re: APT 0.7 for sid
On 6/10/07, Junichi Uekawa <[EMAIL PROTECTED]> wrote: I might not have been clear on the wording. To fix this situation, ftp://ftp.jp.debian.org/debian/dists/sid/main/i18n/Translation-ja.bz2 needs to be encoded in UTF-8 instead of EUC-JP. (and I am wondering why this file is dated back to May 2006). That's because they're not the latest files. The latest output form the DDTP project is here: http://ddtp.debian.net/debian/dists/sid/main/i18n/ There have been requests to have the FTP site mirror from there or have some other mechanism to get the data to the main servers. As far as I know it needs an FTP master to fix. I understand the reason for it not having been done earlier was lack of support in apt? Now, the question is; who to ask? Michael Bramer (Grisu) is the maintainer of the DDTP project, but it needs an ftpmaster to fix. Have a nice day, -- Martijn van Oosterhout <[EMAIL PROTECTED]> http://svana.org/kleptog/ -- 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: arch-all-package shown with two versions on p.d.o
Michael Banck <[EMAIL PROTECTED]> wrote: >> > http://packages.debian.org/cgi-bin/search_packages.pl?keywords=tex-common&searchon=names&subword=1&version=all&release=all >> > >> > Any idea? >> >> I have none, is anyone able to help? Is this a problem in the script >> that generates packages.debian.org's information, or elsewhere? > > packages.debian.org is only informative, not authorative (e.g., it is > always a day or two behind). It's 16 days in this case, and both versions have never been in testing at the same time. > The only totally authorative measure is madison on ftp-master directly, > but that's restricted. I'm not looking for an authoritative answer, but rather for useful information on the web, for users and for other developers. Who is responsible for p.d.o? Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: arch-all-package shown with two versions on p.d.o
On 6/10/07, Frank Küster <[EMAIL PROTECTED]> wrote: Who is responsible for p.d.o? djpig & Joey and some others: http://blog.djpig.de/en/devel/debian/packages-status-update.html http://blog.djpig.de/en/devel/debian/tabbed-packages.html -- bye, pabs http://wiki.debian.org/PaulWise
Re: APT 0.7 for sid
"Martijn van Oosterhout" <[EMAIL PROTECTED]> wrote: > On 6/10/07, Junichi Uekawa <[EMAIL PROTECTED]> wrote: >> I might not have been clear on the wording. To fix this situation, >> ftp://ftp.jp.debian.org/debian/dists/sid/main/i18n/Translation-ja.bz2 >> needs to be encoded in UTF-8 instead of EUC-JP. (and I am wondering >> why this file is dated back to May 2006). > > That's because they're not the latest files. The latest output form > the DDTP project is here: > http://ddtp.debian.net/debian/dists/sid/main/i18n/ > > There have been requests to have the FTP site mirror from there or > have some other mechanism to get the data to the main servers. As far > as I know it needs an FTP master to fix. I understand the reason for > it not having been done earlier was lack of support in apt? Have you submitted a bug against ftp.d.o? I couldn't find one. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Getting package translations into the mirrors (was Re: APT 0.7 for sid)
On 6/10/07, Frank Küster <[EMAIL PROTECTED]> wrote: > That's because they're not the latest files. The latest output form > the DDTP project is here: > http://ddtp.debian.net/debian/dists/sid/main/i18n/ > > There have been requests to have the FTP site mirror from there or > have some other mechanism to get the data to the main servers. As far > as I know it needs an FTP master to fix. I understand the reason for > it not having been done earlier was lack of support in apt? Have you submitted a bug against ftp.d.o? I couldn't find one. I havn't because I didn't think it was my problem. But I found it here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=109955 It's six years old, the URLs have changed but thats it. I came to this rather late so I don't know the story. Just google for apt-i18n brings up some stuff. There's this: http://lists.debian.org/debian-i18n/2006/06/msg00107.html http://lists.debian.org/debian-devel-announce/2006/06/msg3.html When I last asked about it I was told to wait, so I've done nothing. I've CCed grisu, perhaps he knows what's going on... Have a nice day, -- Martijn van Oosterhout <[EMAIL PROTECTED]> http://svana.org/kleptog/
Re: Large static datasets like genomes (Re: Reasonable maximum package size ?)
On Sunday 10 June 2007 17:20:54 you wrote: > On 9 Jun 2007, at 11:27 am, Steffen Moeller wrote: > > Once a (computational) biologist starts a new > > project, (s)he wants the latest data no matter what and anything > > older than > > three months (or a week sometimes) is likely not to be acceptable. > > Actually, my experience is that they tend to want diametrically > opposite things, > at the same time. > > 1) When starting a new project, they usually want the very latest data. > 2) But they usually then want to keep that data static for the > lifetime of > the project. :o) very true. For 1) I hink that Debian packages for databases do not work. They might well work for 2), though. But ... how can one directly access a feature on the genome that has no accession number because you have just found it across releases of Ensembl? * base pairs and chromosome ID does not work across (NCBI) releases * centiMorgans are too vague * distances in bp relative to the nearest genomic marker? Not too bad, probably. The easiest seems indeed to keep the data on which whatever results are computed which is diagnosed as behaviour 2). And 1) is done in order to be close to up-to-date at least when the Journal's reviewers inspect the work :o) I actually think that Debian packages can help at least with the tools used for the analysis since the updating is technically easy ... unless when you have some Perl 5.0.x-specific code this means. Ouch. Many greetings Steffen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Transitional packages
When a binary package simply gets a new name (no splitting or merging involved), should there *always* remain a dummy/transitional package under the old name, or are there exceptions where the dummy package is considered to do more harm (littering, basically) than good, for example -doc packages or other cases where no real functionality is lost by not immediately upgrading? I'm not talking about a situation where a main package changes its dependency on the old package name to the new package name, thereby causing the transition to take place. -- Magnus Holmgren[EMAIL PROTECTED] (No Cc of list mail needed, thanks) pgpHrJubKBmf6.pgp Description: PGP signature
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: Bourne shell assistance needed for Bug #422909
* From: Roger Leigh
* Date: Wed, 09 May 2007 22:48:49 +0100
>
> Hi folks,
Hallo.
> # Unmount all filesystem under specified location
> # $1: mount base location
> do_umount_all()
> {
> "$LIBEXEC_DIR/schroot-listmounts" -m "$1" |
> while read mountloc; do
> if [ "$AUTH_VERBOSITY" = "verbose" ]; then
> echo "Unmounting $mountloc"
> fi
> umount "$mountloc" || exit 1
> done || exit 1
> }
>
> The problem here is that if schroot-listmounts segfaults (the trigger
> in this case) or returns an error,
Two things.
1) Note, that `while' runs in the sub-shell (make sure to understand this)
2) Pipe is cause of wrong assumption. Little stick -- huge impact.
Thus, here it is:
USENET FAQ:
Here Bourne shell version is most convenient, don't try to
use/understand POSIX shell version ;)
UNIX Power Tools (47.2.1.4 More Elaborate Combinations)
http://unix.org.ua/orelly/unix/upt/ch47_02.htm
Compare that to historical perspective.
Thus, without bashizms yet!
--
-o--=O`C
#oo'L O
<___=E M
--
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]
Bug#428328: ITP: pixbros -- 2D game inspired in Bubble Bobble, Snow Bros and Tumble Pop
Package: wnpp Severity: wishlist Owner: Miriam Ruiz <[EMAIL PROTECTED]> * Package name: pixbros Version : 0.5 Upstream Author : Pablo Navarro <[EMAIL PROTECTED]> * URL : http://www.pixjuegos.com/?q=node/54 * License : GPL Programming Lang: Fenix Description : 2D game inspired in Bubble Bobble, Snow Bros and Tumble Pop PIX Bros is a platform game inspired in three different historical arcade games: Bubble Bobble, Snow Bros and Tumble Pop. Three siblings end up transformed into their favourite videogame heroes inside the computer. The game allows 3 players simultaneously. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: APT 0.7 for sid
Daniel Burrows a écrit : > 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 > Hi, I would say aptitude has a very surprising behaviour when upgrading a single package that pulls in a lot of dependencies (this mostly happens when you run unstable, but do not use apt-get upgrade regularly). Let's say I want to upgrade only gnome-terminal, but, due to an ongoing transition, this needs to pull in most of the gnome platform. Then, aptitude's prefered solution would be: 1) hold gnome-terminal 2) still upgrade a few dependencies 3) keep the big transition out Now, this may be correct in the sense that it does not break anything, but it makes little sense: not only does aptitude *not* do what I set out to do in the first place, but it stills does a few unrelated upgrades. Maybe this could be fixed by setting a high penalties on solutions that do not answer the original request of the user. I hope this is clear. Maybe I should keep a log the next time this happens, so I can send a proper bug report. Cheers, BC -- 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
[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. > 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. Peter signature.asc Description: Digital signature
Re: APT 0.7 for sid
On 10-Jun-07, 17:47 (CDT), Daniel Burrows <[EMAIL PROTECTED]> wrote: > 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. Which, IMO, is ideal. > 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. > 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. Agree 100%. Regards, Steve the hopelessly out-of-date -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net -- 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 12:59:38AM +0200, Michael Vogt wrote: > I plan to do an apt 0.7.2 upload for sid this weekend. It's a big merge > of the version in debian/experimental and the version in Ubuntu. [..] I just uploaded apt, python-apt and synaptic. If binNMUs could be arranged for the remaining packages that needs a rebuild that would be most appreciated. [..] > - automatic installation of recommends like aptitude [..] This is currently turned off because of the concerns raised. its a matter of changing the default of "APT::Install-Recommends" to true. I want to turn it on by default in the near future, but with a reasonable warning time for the transition. Many thanks for all good feedback! Thanks, Michael -- 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: aptitude removals (was Re: APT 0.7 for sid)
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: > At the command-line, aptitude knows that its job > is to perform a certain set of actions and preferably as few others as > possible (for instance, "aptitude install X Y Z" should install packages > X, Y, and Z). > In visual mode, in contrast, the interaction between the user and the > program is a lot more open-ended, and it's a lot trickier to figure out > exactly what the user wants (in fact, I'm not sure it's even possible in > principle). 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? -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: APT 0.7 for sid
Steve Greenland <[EMAIL PROTECTED]> writes: >> 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. Yeah, that was my impression too, at least from reading debian mailing lists. A lot of people still like apt-get, but there seems to be a fairly strong movement to aptitude, and synaptic is sort of in the "oh some people use that too" category (no doubt the numbers are different among unsophisticated users, but they're harder to see). -Miles -- "Suppose He doesn't give a shit? Suppose there is a God but He just doesn't give a shit?" [George Carlin] -- 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 wrote: > 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 [..] > Steve the hopelessly out-of-date dselect still works, fwiw ;) Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: APT 0.7 for sid
On 6/10/07, Steve Greenland <[EMAIL PROTECTED]> wrote: 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. I am definitely a GUI person (aptitude is the last non-GUI program with a GUI available that I still use), but I still prefer aptitude to any other. I was under the impression that most others did too, is it not the recommended Debian way? Maybe the non-developer community prefers the GUIs, it's hard to tell, all I know is that whenever I've strayed from aptitude, something has always brought me back (sometimes strange install choices, but usually it's automatic removal). Even on (k)ubuntu, where the recommended package manager is (adept) synaptic, I've tried them out but ended up going back to aptitude, and through the long process of marking everything as automatic and then picking and choosing what I want to install (which is actually easier on ubuntu thanks to the umbrella packages they use). Cameron -- 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: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: APT 0.7 for sid
On Sun, Jun 10, 2007 at 04:36:15PM -0700, Daniel Burrows wrote: > 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". I don't see that at all, fwiw. There may be more people kvetching to you about it as aptitude's use becomes more prevalent and the impact of this behavior becomes more apparent, but I don't think this is a result of an evolving viewpoint but rather the outcome of long years when Recommends *were* treated as strong suggests by the toolchain. I think folks will come around to understanding the difference before too long, as a matter of course. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- 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 07:06:44PM -0700, Daniel Burrows wrote: > 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... aptitude is priority: important, and while it's not used in the installer or mentioned in the installation manual (AFAIK), it has been the recommended upgrade path for two releases now, with its Recommends: handling being a major reason for this. I'd be surprised if there weren't at least *some* users switching to it as a result. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: APT 0.7 for sid
On Monday 11 June 2007 04:17, Steve Langasek wrote: > aptitude is priority: important, and while it's not used in the > installer or mentioned in the installation manual (AFAIK), Although no installer components use aptitude directly, tasksel - which is called during almost all installations - does use it. The installation guide mentions aptitude in various places, for example: http://d-i.alioth.debian.org/manual/en.i386/ch06s03.html#di-install-software > it has been > the recommended upgrade path for two releases now, with its Recommends: > handling being a major reason for this. I'd be surprised if there > weren't at least *some* users switching to it as a result. That much is correct :-) pgpfGkWpWJ4bB.pgp Description: PGP signature
Re: APT 0.7 for sid
> upgrade path for two releases now, with its Recommends: handling being a > major reason for this. I'd be surprised if there weren't at least *some* > users switching to it as a result. Developer users probably. The ones that resist are more non-developer users. I'm constantly being annoyed at work with so-called systems administrators pinging /me about "my Debian box upgrades badly" which is nearly always the consequence of the use of apt-get for upgrades. And I can definitely confitm that, when one just answers "read the bloody release notes and learn about aptitude", the surprise is often very high when people discover that the recommended tool is aptitude and not apt-get. There are so many examples all around the web with various apt-get calls and pretty few with aptitude. In these days where googling becomes a synonym of "read the documentation", it hurts badly. Another widely misunderstood feature of aptitude is the ability to handle packages installed as dependencies. It's pretty often badly understoood and leads to horror stories floating around of "aptitude wants to remove half of the system" while the issue is just the user not understanding the documentation that explains how to switch properly from apt-get to aptitude. signature.asc Description: Digital signature
