Re: Proposing task-debian

2001-04-28 Thread Joey Hess
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

2001-04-28 Thread Christian Hammers
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-




Re: Proposing task-debian

2001-04-29 Thread Dr. Guenter Bechly
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?




Re: Proposing task-debian

2001-04-30 Thread Sam Hartman
> "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

2001-04-30 Thread Josip Rodin
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

2001-04-30 Thread Anthony Towns
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]> 
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

2001-04-30 Thread John Hasler
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

2001-04-30 Thread Matt Zimmerman
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

2001-04-30 Thread Matt Zimmerman
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

2001-04-30 Thread John Hasler
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

2001-04-30 Thread Matt Zimmerman
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

2001-04-30 Thread John Hasler
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

2001-04-30 Thread Alan Shutko
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

2001-04-30 Thread Matt Zimmerman
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

2001-04-30 Thread Joey Hess
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

2001-04-30 Thread Anthony Towns
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]> 
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

2001-04-30 Thread Matt Zimmerman
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

2001-05-01 Thread Sam Powers
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

2001-05-01 Thread Vince Mulhollon

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

2001-05-01 Thread Christian Hammers
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

2001-05-01 Thread John Hasler
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

2001-05-01 Thread Roland Bauerschmidt
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

2001-05-01 Thread Vince Mulhollon

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

2001-05-01 Thread Steve Greenland
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

2001-05-01 Thread John Hasler
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

2001-05-01 Thread Matt Zimmerman
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

2001-05-01 Thread Sam Couter
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

2001-05-01 Thread Matt Zimmerman
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

2001-05-01 Thread Roland Bauerschmidt
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

2001-05-01 Thread Sam Couter
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

2001-05-02 Thread Andreas Metzler
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

2001-05-02 Thread Ilya Martynov
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

2001-05-02 Thread Simon Law
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 { -remove }

which happens to be REALLY ugly.  Better to have apt-get support
task-removals.  For example:

apt-get remove --remove-task [--purge] {  }

Simon




Re: Proposing task-debian

2001-05-06 Thread Rob Browning
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




Easy removal of tasks (was Re: Proposing task-debian)

2001-05-02 Thread Sam Powers
On Wednesday 02 May 2001 13:51, Simon Law wrote:
>   apt-get install { -remove }
>
> which happens to be REALLY ugly.  Better to have apt-get support
> task-removals.  For example:
>
>   apt-get remove --remove-task [--purge] {  }
>
> 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: Easy removal of tasks (was Re: Proposing task-debian)

2001-05-03 Thread Anton Zinoviev
On  2.V.2001 at 15:09 Sam Powers wrote:
> On Wednesday 02 May 2001 13:51, Simon Law wrote:
> > apt-get install { -remove }
> >
> > which happens to be REALLY ugly.  Better to have apt-get support
> > task-removals.  For example:
> >
> > apt-get remove --remove-task [--purge] {  }
> >
> > 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)

2001-05-03 Thread Joey Hess
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