Re: Proposing task-debian
John Hasler [EMAIL PROTECTED] writes: How about an ordinary meta-package named emacs? That might be OK. Bear in mind that there used to be a real package named emacs, though, so you should be wary of breaking upgrades from very old systems. -- Rob Browning [EMAIL PROTECTED] PGP=E80E0D04F521A094 532B97F5D64E3930
Re: Easy removal of tasks (was Re: Proposing task-debian)
On 2.V.2001 at 15:09 Sam Powers wrote:
On Wednesday 02 May 2001 13:51, Simon Law wrote:
apt-get install { task-name-remove }
which happens to be REALLY ugly. Better to have apt-get support
task-removals. For example:
apt-get remove --remove-task [--purge] { task-name }
Simon
I think Roland's suggestion[1] of a new Installed-by: field in the apt
database is much cleaner, and could be used later on to make removing package
groups much simpler.
[1] http://lists.debian.org/debian-devel-0105/msg00082.html
Isn't it possible to integrate debfoster in apt?
Anton Zinoviev, [EMAIL PROTECTED]
Re: Easy removal of tasks (was Re: Proposing task-debian)
Anton Zinoviev wrote: Isn't it possible to integrate debfoster in apt? I think apt is even supposed to have some kind of hooks for storing the necessary info, they are just not used. -- see shy jo
Re: Proposing task-debian
Roland Bauerschmidt [EMAIL PROTECTED] wrote: How does this allow you to remove a task package in an intuitive way? That is what this discussion was about. I am not exactly sure if debfoster does exactly this (at least it does similar), but this is what would call the perfect solution: % apt-get install task-foo there is a new field Installed-by or something in the apt database. task-foo Installed-by: manual package-task-foo-depends-on Installed-by: auto % apt-get remove task-foo 'package-task-foo-depends-on' which was required for 'task-foo' was installed automatically as a dependency, but is not necessary anymore. Do you want to remove it? [Y/n] If a package is set Installed-by: auto and later manually apt-get install'ed, the field would be updated to manual. Just a thought. On apt-get remove also only those package would be checked that are depended on by the package to be removed. Hallo! I was recently told in german usenet [EMAIL PROTECTED] that FreeBSD used this kind of approach, its package managment (iirc ports) remembered whether a package was requested directly or pulled in by dependencies. cu andreas -- Uptime: 10 seconds load average: 0.00, 0.00, 0.00 vim:ls=2:stl=***\ Sing\ a\ song.\ ***
Re: Proposing task-debian
AM Hallo! AM I was recently told in german usenet [EMAIL PROTECTED] AM that FreeBSD used this kind of approach, its package managment (iirc AM ports) remembered whether a package was requested directly or pulled in AM by dependencies. I hear about that first time. I think it is not true. FreeBSD package management do not remember anything about package selection - you just install port and it can install others by depend. Ports that you wanted to install and ports that installed by dependence do not store any information if it was selected manually or not. At least it is so for 4.3-STABLE. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- | Ilya Martynov (http://martynov.org/)| | GnuPG 1024D/323BDEE6 D7F7 561E 4C1D 8A15 8E80 E4AE BE1A 53EB 323B DEE6 | | AGAVA Software Company (http://www.agava.com/) | -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Re: Proposing task-debian
On Tue, 1 May 2001, Steve Greenland wrote:
On 01-May-01, 12:50 (CDT), Vince Mulhollon [EMAIL PROTECTED] wrote:
On 05/01/2001 12:40:24 PM roland wrote:
Vince Mulhollon wrote:
From my poor memory, the generally agreed best idea is to setup two
packages, vaguely like this:
Package name: task-abc
Conflicts: task-abc-remove
Depends: abc, bcd, cde, def
Package name: task-abc-remove
Conflicts: task-abc, abc, bcd, cde, def
Please, NO! This is a pretty ugly hack and there are better ways to do
this, e.g. the debfoster aproach. I don't agree at all with you that
this is the generally agreed best idea. Rather the opposite.
Oh, I don't know if it's an ugly hack.
Well, one reason it's ugly is that your -remove tasks will show up in
the Task Selection dialog that runs before the initial install. I expect
that many new users would be rather confused...
It's also an ugly hack because you'll have to:
apt-get install { task-name-remove }
which happens to be REALLY ugly. Better to have apt-get support
task-removals. For example:
apt-get remove --remove-task [--purge] { task-name }
Simon
Easy removal of tasks (was Re: Proposing task-debian)
On Wednesday 02 May 2001 13:51, Simon Law wrote:
apt-get install { task-name-remove }
which happens to be REALLY ugly. Better to have apt-get support
task-removals. For example:
apt-get remove --remove-task [--purge] { task-name }
Simon
I think Roland's suggestion[1] of a new Installed-by: field in the apt
database is much cleaner, and could be used later on to make removing package
groups much simpler.
[1] http://lists.debian.org/debian-devel-0105/msg00082.html
Re: Proposing task-debian
On Mon, Apr 30, 2001 at 11:10:47PM -0400, Joey Hess wrote: Matt Zimmerman wrote: I think it makes as much sense as the existing task packages. Existing brokenness is no excuse for new brokenness though. I have gone into detail about how the current task system is fubar, and I think I've filed bugs on most of the task packages you mention since they should not exist. A few sentences in policy, or a small web page on /devel might help keep this from happening. More effective though, I think, would be to give developers a good way to express what they are trying to express with these broken task packages. I think they want to give users a way to easily select common packages at installation time. When I first installed Debian, I spent hours in dselect figuring out what I wanted, and today there are several times as many packages. I think most packages that fall into this category are server programs. Desktop systems tend to be installed once and last a long time. I seem to build servers many times more frequently than desktop systems, either to bring more capacity online or to experiment with different applications. Maybe what is needed is a Server installation menu which allows the user to install packages like these without searching around for them. Or, maybe we just need a better dselect. -- - mdz
Re: Proposing task-debian
While we're discussing what's wrong with task packages, I'd like to pick on them a little more: Task packages make things like task-gnome-desktop very easy to install, but removing the packages which are installed can sometimes be really tough, if you just wanted to try out gnome, for example. Perhaps task packages should be required to flag their dependencies for removal in their prerm to ease removal of the entire package group. (probably a better name for this type of package..) Any better ideas?
Re: Proposing task-debian
On 05/01/2001 03:09:16 AM Sam Powers wrote: While we're discussing what's wrong with task packages, I'd like to pick on them a little more: Task packages make things like task-gnome-desktop very easy to install, but removing the packages which are installed can sometimes be really tough, if you just wanted to try out gnome, for example. Perhaps task packages should be required to flag their dependencies for removal in their prerm to ease removal of the entire package group. (probably a better name for this type of package..) Any better ideas? Been there, done that, noone cares enough. Would take a policy change I suppose, to enforce it. From my poor memory, the generally agreed best idea is to setup two packages, vaguely like this: Package name: task-abc Conflicts: task-abc-remove Depends: abc, bcd, cde, def Package name: task-abc-remove Conflicts: task-abc, abc, bcd, cde, def From that description you can probably figure out whats going on. If someone cared enough to do that for all task packages, that would make removal of tasks simple. I don't think this will happen soon, because I get the feeling the the powerusers who would have to create the -remove packages don't use task packages to begin with. Making a sweeping generalization, most people who have root don't install task packages, if they want KDE they apt-get install koffice konquerer and let apt figure out all the dependancies. In other words they already know the names of the tools they need, so they don't need a task package crutch. Then I could complain that the newbies that could benefit by the installation of everything to do task-abc will probably not be able to figure out what's installed by the task package or what in general is installed on their system.. Ideally task-abc-remove would even remove itself once it's done. That would be hard, but it might be possible via a nasty combination of at, cron, and who knows what else. Other theories included enforcing the addition of a file in /usr/sbin, for example: # filename /usr/sbin/task-abc-remove # This shell script cleans out task-abc dpkg --remove abc # you get the idea dpkg --remove def dpkg --remove task-abc rm /usr/sbin/task-abc-remove This is also somewhat tricky, as youd have to create /usr/sbin/task-abc-remove as part of the postinst of task-abc.
Re: Proposing task-debian
On Mon, Apr 30, 2001 at 01:47:34PM -0400, Matt Zimmerman wrote: Perhaps it would be useful to create a new archive section for Debian-specific tools. There seem to be more written all the time, and it would be nice to be able to easily browse a list of them. Things like apt-zip, grep-dctrl, deborphan, debfoster, dlocate, debsums, dpkg-dev-el, dput, and reportbug come to mind as likely candidates for such a section. There's no reason to make I like this idea. Do others have other opinions about this? Who must be asked to create a new section? bye, -christian- -- Save the forests, eat more beavers!
Re: Proposing task-debian
Matt Zimmerman wrote: Perhaps it would be useful to create a new archive section for Debian-specific tools. Christian Hammers writes: I like this idea. Do others have other opinions about this? I like it also. -- John Hasler [EMAIL PROTECTED] (John Hasler) Dancing Horse Hill Elmwood, WI
Re: Proposing task-debian
Vince Mulhollon wrote: From my poor memory, the generally agreed best idea is to setup two packages, vaguely like this: Package name: task-abc Conflicts: task-abc-remove Depends: abc, bcd, cde, def Package name: task-abc-remove Conflicts: task-abc, abc, bcd, cde, def Please, NO! This is a pretty ugly hack and there are better ways to do this, e.g. the debfoster aproach. I don't agree at all with you that this is the generally agreed best idea. Rather the opposite. Roland -- Roland Bauerschmidt
Re: Proposing task-debian
On 05/01/2001 12:40:24 PM roland wrote: Vince Mulhollon wrote: From my poor memory, the generally agreed best idea is to setup two packages, vaguely like this: Package name: task-abc Conflicts: task-abc-remove Depends: abc, bcd, cde, def Package name: task-abc-remove Conflicts: task-abc, abc, bcd, cde, def Please, NO! This is a pretty ugly hack and there are better ways to do this, e.g. the debfoster aproach. I don't agree at all with you that this is the generally agreed best idea. Rather the opposite. Oh, I don't know if it's an ugly hack. Think about it, theres one program or system that handles conflicts and dependencies. Why not rely on it? Making multiple programs to do the same function (installing and removing packages) is probably not the prettiest method. As far as generally agreed best idea goes, I put it in quotes for a reason. As with all things Debian there is no way to make everyone happy.
Re: Proposing task-debian
On 01-May-01, 12:50 (CDT), Vince Mulhollon [EMAIL PROTECTED] wrote: On 05/01/2001 12:40:24 PM roland wrote: Vince Mulhollon wrote: From my poor memory, the generally agreed best idea is to setup two packages, vaguely like this: Package name: task-abc Conflicts: task-abc-remove Depends: abc, bcd, cde, def Package name: task-abc-remove Conflicts: task-abc, abc, bcd, cde, def Please, NO! This is a pretty ugly hack and there are better ways to do this, e.g. the debfoster aproach. I don't agree at all with you that this is the generally agreed best idea. Rather the opposite. Oh, I don't know if it's an ugly hack. Well, one reason it's ugly is that your -remove tasks will show up in the Task Selection dialog that runs before the initial install. I expect that many new users would be rather confused... Steve -- Steve Greenland [EMAIL PROTECTED] (Please do not CC me on mail sent to this list; I subscribe to and read every list I post to.)
Re: Proposing task-debian
Vince Mulhollon writes: Oh, I don't know if it [task-abc-remove] is an ugly hack. The obvious thing to do when one wants to remove a package is to remove the package. To an ordinary user task-abc is a package. He is not going to figure out that the way to remove it is to install another package. -- John Hasler [EMAIL PROTECTED] (John Hasler) Dancing Horse Hill Elmwood, WI
Re: Proposing task-debian
On Tue, May 01, 2001 at 12:50:51PM -0500, Vince Mulhollon wrote: Oh, I don't know if it's an ugly hack. Think about it, theres one program or system that handles conflicts and dependencies. Why not rely on it? Making multiple programs to do the same function (installing and removing packages) is probably not the prettiest method. As far as generally agreed best idea goes, I put it in quotes for a reason. As with all things Debian there is no way to make everyone happy. A cleaner implementation would be to create a simple program or script that would attempt to remove a given package and (recursively) all of its dependencies, skipping any that are depended upon by packages outside of the set of packages being manipulated. So if you had installed task-x-window-system-core, then later installed xterm (which depends on xlibs), you could run this hypothetical program on task-x-window-system-core, and remove all of the pieces of task-x-window-system-core that were not needed by other packages. This would make a good python-apt script. -- - mdz
Re: Proposing task-debian
Matt Zimmerman [EMAIL PROTECTED] wrote: A cleaner implementation would be to create a simple program or script that would attempt to remove a given package and (recursively) all of its dependencies, skipping any that are depended upon by packages outside of the set of packages being manipulated. So if you had installed task-x-window-system-core, then later installed xterm (which depends on xlibs), you could run this hypothetical program on task-x-window-system-core, and remove all of the pieces of task-x-window-system-core that were not needed by other packages. This would make a good python-apt script. Yeah, and you could call it... Let's see... debfoster is a good name! [EMAIL PROTECTED]:~$ apt-cache show debfoster Package: debfoster Priority: optional Section: admin Installed-Size: 80 Maintainer: Ivo Timmermans [EMAIL PROTECTED] Architecture: i386 Version: 1.99+2.0pre8-2 Depends: libc6 (= 2.2.2-2) Recommends: apt Filename: pool/main/d/debfoster/debfoster_1.99+2.0pre8-2_i386.deb Size: 18488 MD5sum: 9889daf0211f8ebae701f71d45fc5790 Description: Install only wanted Debian packages debfoster is a wrapper program for apt and dpkg. When first run, it will ask you which of the installed packages you want to keep installed. . After that, it maintains a list of packages that you want to have installed on your system. It uses this list to detect packages that have been installed only because other packages depended on them. If one of these dependencies changes, debfoster will take notice, and ask if you want to remove the old package. . This helps you to maintain a clean Debian install, without old (mainly library) packages lying around that aren't used any more. -- Sam Couter | Internet Engineer | http://www.topic.com.au/ [EMAIL PROTECTED]| tSA Consulting | OpenPGP key ID: DE89C75C, available on key servers OpenPGP fingerprint: A46B 9BB5 3148 7BEA 1F05 5BD5 8530 03AE DE89 C75C pgpNMW1p9LYBM.pgp Description: PGP signature
Re: Proposing task-debian
On Wed, May 02, 2001 at 12:30:23PM +1000, Sam Couter wrote: Matt Zimmerman [EMAIL PROTECTED] wrote: A cleaner implementation would be to create a simple program or script that would attempt to remove a given package and (recursively) all of its dependencies, skipping any that are depended upon by packages outside of the set of packages being manipulated. So if you had installed task-x-window-system-core, then later installed xterm (which depends on xlibs), you could run this hypothetical program on task-x-window-system-core, and remove all of the pieces of task-x-window-system-core that were not needed by other packages. This would make a good python-apt script. Yeah, and you could call it... Let's see... debfoster is a good name! debfoster does not do what I described, as you can see by its description. [EMAIL PROTECTED]:~$ apt-cache show debfoster Package: debfoster Priority: optional Section: admin Installed-Size: 80 Maintainer: Ivo Timmermans [EMAIL PROTECTED] Architecture: i386 Version: 1.99+2.0pre8-2 Depends: libc6 (= 2.2.2-2) Recommends: apt Filename: pool/main/d/debfoster/debfoster_1.99+2.0pre8-2_i386.deb Size: 18488 MD5sum: 9889daf0211f8ebae701f71d45fc5790 Description: Install only wanted Debian packages debfoster is a wrapper program for apt and dpkg. When first run, it will ask you which of the installed packages you want to keep installed. . After that, it maintains a list of packages that you want to have installed on your system. It uses this list to detect packages that have been installed only because other packages depended on them. If one of these dependencies changes, debfoster will take notice, and ask if you want to remove the old package. . This helps you to maintain a clean Debian install, without old (mainly library) packages lying around that aren't used any more. How does this allow you to remove a task package in an intuitive way? That is what this discussion was about. -- - mdz
Re: Proposing task-debian
Matt Zimmerman wrote: How does this allow you to remove a task package in an intuitive way? That is what this discussion was about. I am not exactly sure if debfoster does exactly this (at least it does similar), but this is what would call the perfect solution: % apt-get install task-foo there is a new field Installed-by or something in the apt database. task-foo Installed-by: manual package-task-foo-depends-on Installed-by: auto % apt-get remove task-foo 'package-task-foo-depends-on' which was required for 'task-foo' was installed automatically as a dependency, but is not necessary anymore. Do you want to remove it? [Y/n] If a package is set Installed-by: auto and later manually apt-get install'ed, the field would be updated to manual. Just a thought. On apt-get remove also only those package would be checked that are depended on by the package to be removed. Roland -- Roland Bauerschmidt
Re: Proposing task-debian
Matt Zimmerman [EMAIL PROTECTED] wrote: debfoster does not do what I described, as you can see by its description. I use it on my system for precisely that, only I don't limit it to just task packages. How does this allow you to remove a task package in an intuitive way? That is what this discussion was about. debfoster task-foo [ wait while task-foo and its dependencies are installed ] debfoster task-foo- [ wait while task-foo is removed ] Debfoster then asks: Do you want to keep libfoo1? [Y/n] Do you want to keep foo? [Y/n] Alternatively, you can remove task-foo however you like and then run debfoster with no arguments to get the same result. Isn't that the kind of thing you're after? -- Sam Couter | Internet Engineer | http://www.topic.com.au/ [EMAIL PROTECTED]| tSA Consulting | OpenPGP key ID: DE89C75C, available on key servers OpenPGP fingerprint: A46B 9BB5 3148 7BEA 1F05 5BD5 8530 03AE DE89 C75C pgpRv2x47EHi5.pgp Description: PGP signature
Re: Proposing task-debian
Joey == Joey Hess [EMAIL PROTECTED] writes: Joey If these tools become widly enough accepted that we think Joey everyone should have them available by default, we can make Joey them standard priority. In the new universe (debbootstrap, tasksel, etc) where a user might never run dselect, what makes sure that in the default configuration, standard priority packages get installed? I seem to be running into a lot of systems I install that end up without ed or emacs20. It's my understanding that if I pick the defaults I really ought to end up with these. [I'm not interested in a flamewar about whether emacs20 should be standard; currently it is.]
Re: Proposing task-debian
On Mon, Apr 30, 2001 at 08:34:04AM -0400, Sam Hartman wrote: Joey If these tools become widly enough accepted that we think Joey everyone should have them available by default, we can make Joey them standard priority. In the new universe (debbootstrap, tasksel, etc) where a user might never run dselect, what makes sure that in the default configuration, standard priority packages get installed? % tasksel --help tasksel: invalid option -- - tasksel [options]; where options is any combination of: -t -- test mode; don't actually run apt-get on exit -q -- queue installs; do not install packages with apt-get; just queue them in dpkg -r -- install all required-priority packages -i -- install all important-priority packages -s -- install all standard-priority packages -n -- don't show UI; use with -r or -i usually IIRC one of those -(r|i|s) is a default... -- Digital Electronic Being Intended for Assassination and Nullification
Re: Proposing task-debian
On Mon, Apr 30, 2001 at 08:34:04AM -0400, Sam Hartman wrote: Joey == Joey Hess [EMAIL PROTECTED] writes: In the new universe (debbootstrap, tasksel, etc) where a user might never run dselect, what makes sure that in the default configuration, standard priority packages get installed? They'll choose to select tasks, and tasksel -ris will presumably be run for them, which'll install all required, important and standard packages. This wasn't the case in potato originally, but I think that's been/going to be changed. [I'm not interested in a flamewar about whether emacs20 should be standard; currently it is.] tetex and emacs are the packages that people usually want out of standard; tetex already has its own task (task-tex), what would people think of making a task-emacs and moving both tetex and emacs out from standard? Cheers, aj (alternately, we could expand tasksel so that it'd take note of a religion-emacs metapackage...) -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``_Any_ increase in interface difficulty, in exchange for a benefit you do not understand, cannot perceive, or don't care about, is too much.'' -- John S. Novak, III (The Humblest Man on the Net) pgpUmloiWWggo.pgp Description: PGP signature
Re: Proposing task-debian
Anthony Towns writes: ...what would people think of making a task-emacs and moving both tetex and emacs out from standard? As an emacs user I think this is an excellent idea, but I worry that such stretching of the definition of task may confuse users. -- John Hasler [EMAIL PROTECTED] Dancing Horse Hill Elmwood, Wisconsin
Re: Proposing task-debian
On Sat, Apr 28, 2001 at 10:55:22PM -0400, Joey Hess wrote: Christian Hammers wrote: Would it be good to have a package task-debian that had dependencies to such meta packages (including the latest version of apt,debconf and dpkg) to ensure that users always get the latest Debian maintenance/meta packages if they wish so? Er, what would you think/do if you were a new user, and saw a list of tasks like Web Server, X Desktop, and so on, and nestled in aoung them was one titled, inexplicably. just Debian? If these tools become widly enough accepted that we think everyone should have them available by default, we can make them standard priority. Perhaps it would be useful to create a new archive section for Debian-specific tools. There seem to be more written all the time, and it would be nice to be able to easily browse a list of them. Things like apt-zip, grep-dctrl, deborphan, debfoster, dlocate, debsums, dpkg-dev-el, dput, and reportbug come to mind as likely candidates for such a section. There's no reason to make them standard, as only a small percentage of users are likely to be be interested in them, and a meta-package doesn't make sense as they don't represent a group of packages that should be installed together. -- - mdz
Re: Proposing task-debian
On Mon, Apr 30, 2001 at 10:03:49AM -0500, John Hasler wrote: Anthony Towns writes: ...what would people think of making a task-emacs and moving both tetex and emacs out from standard? As an emacs user I think this is an excellent idea, but I worry that such stretching of the definition of task may confuse users. I think Emacs as a task makes good sense. Policy seems to agree (Chapter 2, where the standard priority is defined: this is more of a piece of infrastructure than an application). -- - mdz
Re: Proposing task-debian
Matt Zimmerman writes: I think Emacs as a task makes good sense. I think getting it out of standard makes good sense, but I'm not convinced that it makes sense as a task. -- John Hasler [EMAIL PROTECTED] Dancing Horse Hill Elmwood, Wisconsin
Re: Proposing task-debian
On Mon, Apr 30, 2001 at 04:36:14PM -0500, John Hasler wrote: Matt Zimmerman writes: I think Emacs as a task makes good sense. I think getting it out of standard makes good sense, but I'm not convinced that it makes sense as a task. I think it makes as much sense as the existing task packages. For example, we have task packages for roxen (task-webserver-roxen), roxen2 (task-webserver-roxen2), and PostgreSQL (task-database-pg). These refer to specific implementations of a task, not just an abstract task. Perhaps task-devel-emacs would be the logical analogue. In many Linux distributions, Emacs is a high-level installation task, like Games or Mail. This makes sense to the average user, who usually either wants Emacs or does not. -- - mdz
Re: Proposing task-debian
Matt Zimmerman writes: I think it makes as much sense as the existing task packages. Many of which make no more sense than would task-emacs. Perhaps task-devel-emacs would be the logical analogue. Why would someone who wants emacs so that he can read news and mail with gnus and work on his Web page install task-devel-emacs? That's obviously for people who want to hack on emacs. How about an ordinary meta-package named emacs? -- John Hasler [EMAIL PROTECTED] (John Hasler) Dancing Horse Hill Elmwood, WI
Re: Proposing task-debian
Matt Zimmerman [EMAIL PROTECTED] writes: In many Linux distributions, Emacs is a high-level installation task, like Games or Mail. This makes sense to the average user, who usually either wants Emacs or does not. For a little amplification, while Emacs as an editor may not make much sense as a task (only a couple packages), a task which installed most Emacs add-ons might be useful. -- Alan Shutko [EMAIL PROTECTED] - In a variety of flavors! I used to have a drinking problem. Now I love the stuff.
Re: Proposing task-debian
On Mon, Apr 30, 2001 at 07:31:48PM -0400, Alan Shutko wrote: Matt Zimmerman [EMAIL PROTECTED] writes: In many Linux distributions, Emacs is a high-level installation task, like Games or Mail. This makes sense to the average user, who usually either wants Emacs or does not. For a little amplification, while Emacs as an editor may not make much sense as a task (only a couple packages), a task which installed most Emacs add-ons might be useful. I think the general idea is to get Emacs out of standard, since a lot of people don't want it, but still offer it as a straightforward option during the installation process. Currently, the choices for package selection at install time are tasksel and dselect. With the straightforward restriction I gave above, tasksel is the only option. Maybe this will change with debian-installer, or some future device. -- - mdz
Re: Proposing task-debian
Matt Zimmerman wrote: I think it makes as much sense as the existing task packages. Existing brokenness is no excuse for new brokenness though. I have gone into detail about how the current task system is fubar, and I think I've filed bugs on most of the task packages you mention since they should not exist. -- see shy jo
Re: Proposing task-debian
On Mon, Apr 30, 2001 at 11:10:47PM -0400, Joey Hess wrote: Matt Zimmerman wrote: I think it makes as much sense as the existing task packages. Existing brokenness is no excuse for new brokenness though. I have gone into detail about how the current task system is fubar, and I think I've filed bugs on most of the task packages you mention since they should not exist. Here are the assumptions: * emacs is used and desired by enough people that they should be able to get it easily * emacs is large and not used by enough people that it should be easily avoidable in the default install In both cases, easily probably involves not going into dselect or console-apt or using apt-get by hand. The conclusion is that there should be some way, using something like tasksel, to choose whether you want emacs installed or not. Likewise, there ought to be some way, using something like tasksel, to choose whether you want an X environment or not, and whether you want a fancy desktop like Gnome or KDE. Lots of people do want them. Lots of people don't. They're not exactly tasks, though. Would: [ ] X Desktop (Gnome/KDE) [ ] Emacs [ ] Dialup [ ] Printing [ ] Laptop [ ] Russian [ ] German [ ] Japanese [ ] Chinese [ ] Spanish [ ] Polish [ ] Office software (word processing, spreadsheet, etc) [ ] Desktop Publishing (TeX) [ ] Database software (Postgresql) [ ] Science [ ] Games [ ] Junior [ ] C [ ] C++ [ ] Fortran [ ] Objectionable C [ ] Python [ ] SGML [ ] Tcl/Tk [ ] Web Server (Apache) [ ] Windows Filesharing (Samba) [ ] DNS Server (bind) [ ] News Server (INN) [ ] Cluster node [ ] Mail Server (IMAP, etc) ...really be unreasonable? They're not all tasks (I speak Russian, I want to use Emacs, I want pretty little icons, just like Windows, my computer has a printer), and even the ones that are aren't tasks in the same sense (I want to be able to... vs I want my computer to...) But they're not hard for a user to work through, and they seem likely to be useful. (They could be further categorised by naming them like: task-devel-c task-lang-polish task-user-wordprocessing task-server-dns task-hardware-dialup And having tasksel know about the conventions we might use) Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``_Any_ increase in interface difficulty, in exchange for a benefit you do not understand, cannot perceive, or don't care about, is too much.'' -- John S. Novak, III (The Humblest Man on the Net) pgp1CQHsCJ2FE.pgp Description: PGP signature
Re: Proposing task-debian
Hi, On Sun, Apr 29, 2001 at 03:38:04AM +0200, Christian Hammers wrote: Recently I found two packages, debsig-verify and apt-listchanges only by coincidence because I read in a mailing list about them. Generally, I like the idea of a task-debian metapackage, because I also just discovered some useful tools by mere accident. However, please do not make such a task-package depend on debsig-verify, because after the installation of this program you cannot install any debpackage with dpkg, dselect or apt anymore, because dpkg by default uses debsig-verify when it is installed, but debsig-verify refuses to recognize any package as correctly signed (at least with the default configuration)!!! Cheers, Guenter -- Linux: Who needs GATES in a world without fences?
Proposing task-debian
Hello Recently I found two packages, debsig-verify and apt-listchanges only by coincidence because I read in a mailing list about them. Would it be good to have a package task-debian that had dependencies to such meta packages (including the latest version of apt,debconf and dpkg) to ensure that users always get the latest Debian maintenance/meta packages if they wish so? bye, -christian-
Re: Proposing task-debian
Christian Hammers wrote: Recently I found two packages, debsig-verify and apt-listchanges only by coincidence because I read in a mailing list about them. Would it be good to have a package task-debian that had dependencies to such meta packages (including the latest version of apt,debconf and dpkg) to ensure that users always get the latest Debian maintenance/meta packages if they wish so? Er, what would you think/do if you were a new user, and saw a list of tasks like Web Server, X Desktop, and so on, and nestled in aoung them was one titled, inexplicably. just Debian? If these tools become widly enough accepted that we think everyone should have them available by default, we can make them standard priority. -- see shy jo
Re: Proposing task-debian
On Sat, Apr 28, 2001 at 10:55:22PM -0400, Joey Hess wrote: Er, what would you think/do if you were a new user, and saw a list of tasks like Web Server, X Desktop, and so on, and nestled in aoung them was one titled, inexplicably. just Debian? Call it a working title. We can discuss the name of the package later :) If these tools become widly enough accepted that we think everyone should have them available by default, we can make them standard priority. Will apt-get -u upgrade automatically propose new packages with priority standard? Anyways I though more on the typical testing/unstable user than on people who do fresh installs... see shy jo bye, -christian-
