Hello,
An option for showing only those packages that nothing depends on
could be useful.
That bit's easy. My first PERL script did that. But what about alternatives?
Jiri [EMAIL PROTECTED]
--
#!/usr/bin/perl
print ENDDOC and exit if $ARGV[0] =~ /-h/;
List installed packages which are
Programs that are useful by itself could install with a counter that's
already 1 higher. For example: if all the packages that depend on Xterm are
removed, the counter of Xterm is still not zero. So it would not be
deleted.
Thinking a bit longer: in this way almost no programs reach zero.
Programs that are useful by itself could install with a counter that's
already 1 higher. For example: if all the packages that depend on Xterm are
removed, the counter of Xterm is still not zero. So it would not be
deleted.
Thinking a bit longer: in this way almost no programs reach
Maybe they could get a question like do you want to get rid of YYY
too? It was installed only for supporting XXX but may be useful
on its own.
Uh... I think I mentioned this a few days ago. So... I guess my vote would
be... yes. I'm all for it.
I guess the thing I was mostly suggesting was a
On Mon, 30 Nov 1998, Mitch Blevins wrote:
about auto-removing unneeded packages
I think the best solution would be to be able to mark packages in dselect
and dpkg, just like we currently have them marked as 'purge', 'hold', etc.
We would just add a way to mark packages as
Helge Hafting wrote:
[...]
X-+-xbase
|
+-xservers
|
+-xfonts
This looks good. Of course the groups should be collapsable so
the user can get where he wants fast.
Yes, this is what I was thinking of. Right now the only way to
'associate' packages with
Leandro Dutra wrote:
This feature would, I fear, strain the dpkg system even more. I'm
starting to see occasional failures under dselect/apt/dpkg that
fortunately, for now, are transient (i.e. rerun dselect/apt and the
failure doesn't reoccur). It suggests to me that we are
Ed Cogburn writes:
I occasionally see a general protection failure (or something similar)
message that starts with a string of zeros. As long as they are
transient, they are not serious (but indicate a weakness in dpkg)
No they don't. A general protection failure can never be caused by an
[EMAIL PROTECTED] wrote:
Ed Cogburn writes:
I occasionally see a general protection failure (or something similar)
message that starts with a string of zeros. As long as they are
transient, they are not serious (but indicate a weakness in dpkg)
No they don't. A general protection
Ed Cogburn wrote:
[snipped for brevity]
Yes, /usr/local is a problem. Well, perhaps this method could include
an 'override' for any package that would suppress dpkg's indication that
a deb package has been orphaned. The user who as developed a
/usr/local/ binary that depends on an
On Tue, 1 Dec 1998, Ed Cogburn wrote:
[EMAIL PROTECTED] wrote:
[ Something about gpfs ]
As I said later in my message, I'm not sure of the error messages
'name' or origin, because I haven't seen one of these failures
recently. It can't be hardware though, these transient errors
The problem of needing *some* sort of terminal can be solved by having
both xterm and rxvt provide the same terminal capability, and have
x-base suggest the terminal stuff. It shouldn't depend on it though,
one can imagine an useful x-installation without a terminal.
Nothing
Programs that are useful by itself could install with a counter that's
already 1 higher. For example: if all the packages that depend on Xterm are
removed, the counter of Xterm is still not zero. So it would not be deleted.
Thinking a bit longer: in this way almost no programs reach zero.
Larry
Programs that are useful by itself could install with a counter that's
already 1 higher. For example: if all the packages that depend on Xterm are
removed, the counter of Xterm is still not zero. So it would not be
deleted.
Thinking a bit longer: in this way almost no programs reach zero.
Helge Hafting wrote:
The problem of needing *some* sort of terminal can be solved by having
both xterm and rxvt provide the same terminal capability, and have
x-base suggest the terminal stuff. It shouldn't depend on it though,
one can imagine an useful x-installation without a
Mitch Blevins wrote:
Ed Cogburn wrote:
Yes, this is what I was thinking of. Right now the only way to
'associate' packages with one another, besides the section name, is to
use a common prefix in the name so they show up together in the same
place in dselect's screen. Imagine a
Ed Cogburn wrote:
Mitch Blevins wrote:
One problem with auto-deinstallation of support packages is that
you may have other packages that also use the same support package.
You would have to grep the dependency database to ensure you
weren't removing a library/package that was used
On Mon, 30 Nov 1998, Mitch Blevins wrote:
Ed Cogburn wrote:
Mitch Blevins wrote:
One problem with auto-deinstallation of support packages is that
you may have other packages that also use the same support package.
You would have to grep the dependency database to ensure you
Previously Mitch Blevins wrote:
One problem with auto-deinstallation of support packages is that
you may have other packages that also use the same support package.
You would have to grep the dependency database to ensure you
weren't removing a library/package that was used elsewhere.
Even
[...]
X-+-xbase
|
+-xservers
|
+-xfonts
This looks good. Of course the groups should be collapsable so
the user can get where he wants fast.
Yes, this is what I was thinking of. Right now the only way to
'associate' packages with one another, besides the section
Why not use a counter ? When a package is installed it increments the
counters of the packages it depends on. Deleting a package also decrements
the counters of the others. If a counter gets zero it can safely be deleted.
There is one other 'association' issue that is getting worse.
Subject: Is this really the right thing to do?
Date: Sat, Nov 28, 1998 at 03:16:07PM -0500
In reply to:Ed Cogburn
Quoting Ed Cogburn([EMAIL PROTECTED]):
I've been watching the explosive growth of deb packages in slink, now
around 2700 packages. Recently, the split
This feature would, I fear, strain the dpkg system even more. I'm
starting to see occasional failures under dselect/apt/dpkg that
fortunately, for now, are transient (i.e. rerun dselect/apt and the
failure doesn't reoccur). It suggests to me that we are pushing our
package
Finding out if a package has no dependencies is done already,
when you try to delete one. The flag I suggested would
be a display-only thing in dselect, using this mechanism.
Your counter may perhaps be a useful performance enhancement though.
Note that you can't just delete packages as count
Mitch Blevins wrote:
Ed Cogburn wrote:
Mitch Blevins wrote:
One problem with auto-deinstallation of support packages is that
you may have other packages that also use the same support package.
You would have to grep the dependency database to ensure you
weren't removing a
Wichert Akkerman wrote:
Previously Mitch Blevins wrote:
One problem with auto-deinstallation of support packages is that
you may have other packages that also use the same support package.
You would have to grep the dependency database to ensure you
weren't removing a library/package
One problem with auto-deinstallation of support packages is that
you may have other packages that also use the same support package.
Seeing how this problem is almost identical to the problem of memory
allocation in a language like C or C++ (ie, memory-leaks vs.
dangling-pointers), perhaps we
The developers of dpkg could do something like add a 'package
grouping'
feature that lets newcomers (especially newbies to X11) understand the
relationship between packages.
Do anyone knows what the dpkg developers think about the issue?
Is this a documentation issue? Maybe
The developers of dpkg could do something like add a 'package
grouping'
feature that lets newcomers (especially newbies to X11) understand the
relationship between packages.
Is this a documentation issue? Maybe there is a requirement for a document
explaining the general
layout of
On Mon, 30 Nov 1998, Leandro Dutra wrote:
The developers of dpkg could do something like add a 'package
grouping'
feature that lets newcomers (especially newbies to X11) understand the
relationship between packages.
Is this a documentation issue? Maybe there is a
Leandro Dutra wrote:
The developers of dpkg could do something like add a 'package
grouping'
feature that lets newcomers (especially newbies to X11) understand the
relationship between packages.
Is this a documentation issue? Maybe there is a requirement for a document
Ed Cogburn wrote:
Yes, this is what I was thinking of. Right now the only way to
'associate' packages with one another, besides the section name, is to
use a common prefix in the name so they show up together in the same
place in dselect's screen. Imagine a user looking at the huge
The developers of dpkg could do something like add a 'package
grouping'
feature that lets newcomers (especially newbies to X11) understand the
relationship between packages.
Do anyone knows what the dpkg developers think about the issue?
Leandro Guimaraens Faria Corcete Dutra
I've been watching the explosive growth of deb packages in slink, now
around 2700 packages. Recently, the split-up of X11 into around 12
packages and the numerous packages used in slink for the Netscape
programs and the huge number (around 30) of packages that has to be
installed for
34 matches
Mail list logo
