Re: Purging a package............... (and apt-config processing order)
2014-11-25 05:14 keltezéssel, The Wanderer írta: >> I don't know whether /etc/apt/apt.conf is processed before fragments >> in /etc/apt/apt.conf.d - but I'd be interested in learning. >> Anyone?? > > Now that you bring it up, I'd be interested in that myself. Fortunately, > it's trivially discoverable: > > $ strace apt-get --dry-run autoremove &> /tmp/apt-dryrun-autoremove.strace > $ grep apt.conf /tmp/apt-dryrun-autoremove.strace > > I'm not going to paste the output here, but apparently the fragment > files are processed first. > Perhaps 'apt-config dump' command helps to find out the proper order. -- --- Friczy --- 'Death is not a bug, it's a feature' -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54778e24.9080...@freemail.hu
Re: Purging a package...............
On Tue, 25 Nov 2014 12:33:22 +0200 Andrei POPESCU sent:
> On Ma, 25 nov 14, 14:25:13, Charlie wrote:
> >
> > Thank you for that information, it was most helpful.
> >
> > I decided to add:
> >
> >
> >SuggestsImportant
> >{
> > "false"
> >};
> > };
> >
> > To the existing etc/aptapt.conf.d/01autoremove file.
>
> This may or may not be what you want, but changing that file is a
> conffile of the package 'apt', so you will now be getting a prompt
> whenever the maintainers make changes to it, whether related or not.
>
> If you don't want that you should probably revert to the package
> maintainer's file and put your customizations in your own snippet
> under apt.conf.d.
>
> Kind regards,
> Andrei
Thank you both Andrei and Scott.
I have now added into the /etc/apt/apt.conf.d/91autoremove with the
line: APT::AutoRemove::SuggestsImportant "false";
And returned the other back to the original text.
Thanks again for expanding on what would happen.
Charlie
--
Registered Linux User:- 329524
***
An idea can turn to dust or magic, depending on the talent that
rubs against it. Bill Bernbach
***
Debian GNU/Linux - just the best way to create magic
-
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141126072046.61734dd8@taogypsy
Re: Purging a package............... (best practise for SuggestsImportant)
On 25/11/14 21:33, Andrei POPESCU wrote:
> On Ma, 25 nov 14, 14:25:13, Charlie wrote:
>>
>> Thank you for that information, it was most helpful.
>>
>> I decided to add:
>>
>>
>>SuggestsImportant
>>{
>> "false"
>>};
>> };
>>
>> To the existing etc/aptapt.conf.d/01autoremove file.
>
> This may or may not be what you want, but changing that file is a
> conffile of the package 'apt', so you will now be getting a prompt
> whenever the maintainers make changes to it, whether related or not.
Good point!
My fault Charlie, using 'could' in that example was bad and I should
have thought of the possible results - it'd have been safest if I'd just
given the fragments and /etc/apt/apt.conf example doc link to explain
the index format for more complex apt config changes.
I'd recommend reverting to the original /etc/apt/apt.conf.d/01autoremove
and creating a new fragment e.g.:-
91suggestsimport with the content line that Andrei originally suggested.
>
> If you don't want that you should probably revert to the package
> maintainer's file and put your customizations in your own snippet under
> apt.conf.d.
>
> Kind regards,
> Andrei
>
Thanks Andrei.
Kind regards
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/547467af.2050...@gmail.com
Re: Purging a package...............
On Ma, 25 nov 14, 14:25:13, Charlie wrote:
>
> Thank you for that information, it was most helpful.
>
> I decided to add:
>
>
>SuggestsImportant
>{
> "false"
>};
> };
>
> To the existing etc/aptapt.conf.d/01autoremove file.
This may or may not be what you want, but changing that file is a
conffile of the package 'apt', so you will now be getting a prompt
whenever the maintainers make changes to it, whether related or not.
If you don't want that you should probably revert to the package
maintainer's file and put your customizations in your own snippet under
apt.conf.d.
Kind regards,
Andrei
--
http://wiki.debian.org/FAQsFromDebianUser
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic
http://nuvreauspam.ro/gpg-transition.txt
signature.asc
Description: Digital signature
Re: Purging a package............... (and apt-config processing order)
On 25/11/14 15:14, The Wanderer wrote: > On 11/24/2014 at 11:03 PM, Scott Ferguson wrote: > >> I don't know whether /etc/apt/apt.conf is processed before >> fragments in /etc/apt/apt.conf.d - but I'd be interested in >> learning. Anyone?? > > Now that you bring it up, I'd be interested in that myself. > Fortunately, it's trivially discoverable: > > $ strace apt-get --dry-run autoremove &> > /tmp/apt-dryrun-autoremove.strace $ grep apt.conf > /tmp/apt-dryrun-autoremove.strace > > I'm not going to paste the output here, but apparently the > fragment files are processed first. > Thanks for that - I've added it to my references, along with the method you used to prove it. Apropos of which, if it's of interest to anyone:- *the *.d in a directory name indicates a fragments directory (generally) *in at least the instance of apt (preferences, conf, and sources) it's now the "recommended" Best Practise - though I have yet to discover (mostly through a lack of research) when support for apt.conf and apt.preferences[*1] will (or if ever) cease to be supported. Again, I'd be interested in learning. Anyone?? *it 'seems'[*2] it stems from sysv change from a monolithic /etc/rc conf file to a more easily managed directory of fragments. [*1] I don't know about sources.list, I use fragments in /etc/apt/sources.list.d for repositories other than the basic official Debian ones specific to the release - I don't propose that's the correct way to do things (and welcome useful comments). [*2] if it's important - I have only anecdotal support for that, tenuous, "belief". Kind regards. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54740f33.8000...@gmail.com
Re: Purging a package............... (and apt-config processing order)
On 11/24/2014 at 11:03 PM, Scott Ferguson wrote: > I don't know whether /etc/apt/apt.conf is processed before fragments > in /etc/apt/apt.conf.d - but I'd be interested in learning. > Anyone?? Now that you bring it up, I'd be interested in that myself. Fortunately, it's trivially discoverable: $ strace apt-get --dry-run autoremove &> /tmp/apt-dryrun-autoremove.strace $ grep apt.conf /tmp/apt-dryrun-autoremove.strace I'm not going to paste the output here, but apparently the fragment files are processed first. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Purging a package............... (and apt-config processing order)
CORRECTION On 25/11/14 14:25, Charlie wrote: > On Tue, 25 Nov 2014 14:02:37 +1100 Scott Ferguson sent: > >> On 25/11/14 13:02, Charlie wrote: >>> On Mon, 24 Nov 2014 23:24:29 +0200 Andrei POPESCU sent: >>> >> Notes:- >> *Fragments are processed in alpha order (numbers, then the following >> letters)- i.e. 10something will over-rule 11something, and 10something >> will be over-ruled by 10thisthing. *Should* have been:- Notes:- *Fragments are processed in alpha order (numbers, then the following letters)- i.e. 10something will *be over-ruled by* 11something To be clearer - apt-config processes the rules in alpha order, if two rules conflict the last rule processed over-rules an earlier rule. I don't know whether /etc/apt/apt.conf is processed before fragments in /etc/apt/apt.conf.d - but I'd be interested in learning. Anyone?? My apologies for the misinformation (note to self - sack editor) -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5473ff91.9040...@gmail.com
Re: Purging a package...............
On Tue, 25 Nov 2014 14:02:37 +1100 Scott Ferguson sent:
> On 25/11/14 13:02, Charlie wrote:
> > On Mon, 24 Nov 2014 23:24:29 +0200 Andrei POPESCU sent:
> >
> >> Because of this I set
> >>
> >> APT::AutoRemove::SuggestsImportant "false";
> >>
> >> in apt.conf
> >
> > I have no apt.conf but I do have an /etc/apt/apt.conf.d directory?
> >
> > Am I missing an apt.conf file and should one be added?
>
> Yes, and no ;)
>
> You can create one, or, you can create a fragment file and place it in
> /etc/apt/apt.conf.d
> AFAIK, both approaches are "good".
>
> An example fragment usage is to create a fragment e.g. (as root):-
> nano /etc/apt/apt.conf.d/91autoremove
> and populate it with Andrei's suggested config.
>
> e.g.:-
> cat /etc/apt/apt.conf.d/91autoremove
> APT::AutoRemove::SuggestsImportant "false";
>
>
>
> Notes:-
> *Fragments are processed in alpha order (numbers, then the following
> letters)- i.e. 10something will over-rule 11something, and 10something
> will be over-ruled by 10thisthing.
>
> *If two fragments have the same number they are processed in alpha
> order.
>
> *Using the number 91 is an arbitrary choice.
>
> *Fragments 'can' be easier to manage e.g.:- I keep a variety of
> fragments in /etc/apt where they are ignored unless I, sometimes just
> for momentary use, mv them to /etc/apt/apt.conf.d (where they are
> processed by apt (using "apt-config").
>
> *You may find you already have an autoremove fragment:-
> cat /etc/apt/apt.conf.d/01autoremove
> APT
> {
> NeverAutoRemove
> {
> "^firmware-linux.*";
> "^linux-firmware$";
> "^linux-image.*";
> "^kfreebsd-image.*";
> "^linux-restricted-modules.*";
> "^linux-ubuntu-modules-.*";
> "^gnumach$";
> "^gnumach-image.*";
> };
>
> Never-MarkAuto-Sections
> {
> "metapackages";
> "restricted/metapackages";
> "universe/metapackages";
> "multiverse/metapackages";
> "oldlibs";
> "restricted/oldlibs";
> "universe/oldlibs";
> "multiverse/oldlibs";
> };
> };
>
>
> Which you 'could' add the suggested config to, e.g.:-
> APT
> {
> NeverAutoRemove
> {
> "^firmware-linux.*";
> "^linux-firmware$";
> "^linux-image.*";
> "^kfreebsd-image.*";
> "^linux-restricted-modules.*";
> "^linux-ubuntu-modules-.*";
> "^gnumach$";
> "^gnumach-image.*";
> };
>
> Never-MarkAuto-Sections
> {
> "metapackages";
> "restricted/metapackages";
> "universe/metapackages";
> "multiverse/metapackages";
> "oldlibs";
> "restricted/oldlibs";
> "universe/oldlibs";
> "multiverse/oldlibs";
> };
>
> SuggestsImportant
> {
> "false"
> };
> };
>
>
> For the apt.conf method (/etc/apt/apt.conf) see:-
> /usr/share/doc/apt/examples/configure-index.gz
> for examples
>
> >
> > Charlie
> >
>
> Kind regards
>
> Useful refs:-
> man apt.conf
> http://debian-handbook.info/browse/wheezy/sect.apt-get.html#sect.apt-config
> https://wiki.debian.org/AptConf
Thank you for that information, it was most helpful.
I decided to add:
SuggestsImportant
{
"false"
};
};
To the existing etc/aptapt.conf.d/01autoremove file.
So thank you very much.
Charlie
--
Registered Linux User:- 329524
***
Distrust any enterprise that requires new clothes. .Henry
David Thoreau
***
Debian GNU/Linux - just the best way to create magic
-
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141125142513.3e4b4fcd@taogypsy
Re: Purging a package...............
On 25/11/14 13:02, Charlie wrote:
> On Mon, 24 Nov 2014 23:24:29 +0200 Andrei POPESCU sent:
>
>> Because of this I set
>>
>> APT::AutoRemove::SuggestsImportant "false";
>>
>> in apt.conf
>
> I have no apt.conf but I do have an /etc/apt/apt.conf.d directory?
>
> Am I missing an apt.conf file and should one be added?
Yes, and no ;)
You can create one, or, you can create a fragment file and place it in
/etc/apt/apt.conf.d
AFAIK, both approaches are "good".
An example fragment usage is to create a fragment e.g. (as root):-
nano /etc/apt/apt.conf.d/91autoremove
and populate it with Andrei's suggested config.
e.g.:-
cat /etc/apt/apt.conf.d/91autoremove
APT::AutoRemove::SuggestsImportant "false";
Notes:-
*Fragments are processed in alpha order (numbers, then the following
letters)- i.e. 10something will over-rule 11something, and 10something
will be over-ruled by 10thisthing.
*If two fragments have the same number they are processed in alpha order.
*Using the number 91 is an arbitrary choice.
*Fragments 'can' be easier to manage e.g.:- I keep a variety of
fragments in /etc/apt where they are ignored unless I, sometimes just
for momentary use, mv them to /etc/apt/apt.conf.d (where they are
processed by apt (using "apt-config").
*You may find you already have an autoremove fragment:-
cat /etc/apt/apt.conf.d/01autoremove
APT
{
NeverAutoRemove
{
"^firmware-linux.*";
"^linux-firmware$";
"^linux-image.*";
"^kfreebsd-image.*";
"^linux-restricted-modules.*";
"^linux-ubuntu-modules-.*";
"^gnumach$";
"^gnumach-image.*";
};
Never-MarkAuto-Sections
{
"metapackages";
"restricted/metapackages";
"universe/metapackages";
"multiverse/metapackages";
"oldlibs";
"restricted/oldlibs";
"universe/oldlibs";
"multiverse/oldlibs";
};
};
Which you 'could' add the suggested config to, e.g.:-
APT
{
NeverAutoRemove
{
"^firmware-linux.*";
"^linux-firmware$";
"^linux-image.*";
"^kfreebsd-image.*";
"^linux-restricted-modules.*";
"^linux-ubuntu-modules-.*";
"^gnumach$";
"^gnumach-image.*";
};
Never-MarkAuto-Sections
{
"metapackages";
"restricted/metapackages";
"universe/metapackages";
"multiverse/metapackages";
"oldlibs";
"restricted/oldlibs";
"universe/oldlibs";
"multiverse/oldlibs";
};
SuggestsImportant
{
"false"
};
};
For the apt.conf method (/etc/apt/apt.conf) see:-
/usr/share/doc/apt/examples/configure-index.gz
for examples
>
> Charlie
>
Kind regards
Useful refs:-
man apt.conf
http://debian-handbook.info/browse/wheezy/sect.apt-get.html#sect.apt-config
https://wiki.debian.org/AptConf
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5473f14d.7020...@gmail.com
Re: Purging a package...............
On Mon, 24 Nov 2014 23:24:29 +0200 Andrei POPESCU sent: > Because of this I set > > APT::AutoRemove::SuggestsImportant "false"; > > in apt.conf I have no apt.conf but I do have an /etc/apt/apt.conf.d directory? Am I missing an apt.conf file and should one be added? Charlie -- Registered Linux User:- 329524 *** Rightful liberty is unobstructed action according to our will within limits drawn around us by the equal rights of others. I do not add 'within the limits of the law' because law is often but the tyrant's will, and always so when it violates the rights of the individual. --Thomas Jefferson *** Debian GNU/Linux - just the best way to create magic - -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141125130207.731f2b6d@taogypsy
Re: Purging a package...............
On Du, 23 nov 14, 15:11:56, Bob Proulx wrote: > > That is expected. Because when you purged that package the tool > doesn't know if you were going to install an alternative tool or a > different version of that tool or something different. It shouldn't > remove the dependencies recursively. Again there are other tools for > doing recursive removals. See "orphaner" in the 'deborphan' package > for example. Although I think "apt-get autoremove --purge" is the > main example these days. Please note that by default apt will not consider packages for autoremoval if they are Recommended, and as of 0.8.15.3 (pre-wheezy), Suggested by some other package. Because of this I set APT::AutoRemove::SuggestsImportant "false"; in apt.conf Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic http://nuvreauspam.ro/gpg-transition.txt signature.asc Description: Digital signature
Re: Purging a package...............
On Sun, 23 Nov 2014 15:11:56 -0700 Bob Proulx sent: > Charlie wrote: > > In a different email, under the heading: Re: Installing an > > Alternative Init? Andrei posted this in part: > > > > [quote] A package not properly cleaning after itself on purge is > > generally considered a bug in Debian, severity depending on the > > impact, of course. [end quote] > > > > I suppose this is literal, just that package? > > Yes. Just that package. Not the package dependencies. Because there > is the APT "autoremove" functionality for that purpose. > > > Because I have install a package which also pulled in some > > dependencies. > > > > Upon purging it, because it didn't suit the purpose of what I > > wanted to do. It purged itself, but left the dependencies on the > > system. > > That is expected. Because when you purged that package the tool > doesn't know if you were going to install an alternative tool or a > different version of that tool or something different. It shouldn't > remove the dependencies recursively. Again there are other tools for > doing recursive removals. See "orphaner" in the 'deborphan' package > for example. Although I think "apt-get autoremove --purge" is the > main example these days. > > > I can only suppose this is what is supposed to happen? I > > backtracked and found them, purging each in turn. > > > > I also suppose this is what's supposed to happen? > > > > Or is there some command using apt-get that allows me to purge a > > package and the dependencies it pulled in as well? > > That or run this: > > apt-get autoremove --purge > > The above is my normal course of action. > > > Just curious and trying to learn a bit more. > > Read the man page for apt-mark for more information about how this > works. That command is relatively new in Wheezy. Previously there > was some of the functionality (hold/install) directly in dpkg. That > plus whether a package was installed manually or installed as a > dependency has had an interface to that information made available > through the apt-mark command. You can see the list of packages > automatically installed with "apt-mark showauto". You can directly > manipulate the state using that command too. > > The idea is that if the package that pulled in packages is removed > then you can run apt-get autoremove to remove the dependencies too. > It is up to you to know that if you want them purged you can add the > --purge option. I have good backups plus I use etckeeper so I am > confident of simply purging /etc files and therefore mostly purge > packages. That avoids a lot of interaction bugs such as some of the > well known problems with PHP having config to load libraries that have > been removed. If it were purged then the config would have been > removed too and no problem would have been noticed. That is just one > example. Therefore it is good to keep the system clean of "rc" state > things. The deborphan command can help there too. > > dpkg -l | grep ^rc > > On my Sid system it is this daily routine: > > apt-get update && apt-get dist-upgrade -d -y # in /etc/cron.daily > apt-get upgrade > apt-get dist-upgrade > apt-get autoremove --purge > apt-get clean > reportbug packagefoo > > At the dist-upgrade and autoremove steps I carefully inspect the list > and say No and adjust things with "hold" as needed. After upgrade and > reportbug it is often necessary to downgrade to the previous version > still in Testing. > > apt-cache policy packagefoo > apt-get install packagefoo=1.2.3-4 > > Bob Thank you Reco, Bob for your comprehensive answer, and Songbird. Now I understand more fully what is happening and what is required. Charlie -- Registered Linux User:- 329524 *** Tomorrow I will live, the fool does say: Today itself's too late; the wise lived yesterday. Martial *** Debian GNU/Linux - just the best way to create magic - -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141124153428.7533a2ab@taogypsy
Re: Purging a package...............
Bob Proulx wrote: ... also, sometimes via the package deborphan the utility called orphaner can help get rid of libraries that are no longer needed. but of course with any tool, please understand what it is asking for you to remove before saying OK (simulate is a useful option as it may find more each time through). songbird -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pv4akb-09c@id-306963.user.uni-berlin.de
Re: Purging a package...............
Charlie wrote: > In a different email, under the heading: Re: Installing an Alternative > Init? Andrei posted this in part: > > [quote] A package not properly cleaning after itself on purge is > generally considered a bug in Debian, severity depending on the impact, > of course. [end quote] > > I suppose this is literal, just that package? Yes. Just that package. Not the package dependencies. Because there is the APT "autoremove" functionality for that purpose. > Because I have install a package which also pulled in some > dependencies. > > Upon purging it, because it didn't suit the purpose of what I wanted to > do. It purged itself, but left the dependencies on the system. That is expected. Because when you purged that package the tool doesn't know if you were going to install an alternative tool or a different version of that tool or something different. It shouldn't remove the dependencies recursively. Again there are other tools for doing recursive removals. See "orphaner" in the 'deborphan' package for example. Although I think "apt-get autoremove --purge" is the main example these days. > I can only suppose this is what is supposed to happen? I backtracked and > found them, purging each in turn. > > I also suppose this is what's supposed to happen? > > Or is there some command using apt-get that allows me to purge a > package and the dependencies it pulled in as well? That or run this: apt-get autoremove --purge The above is my normal course of action. > Just curious and trying to learn a bit more. Read the man page for apt-mark for more information about how this works. That command is relatively new in Wheezy. Previously there was some of the functionality (hold/install) directly in dpkg. That plus whether a package was installed manually or installed as a dependency has had an interface to that information made available through the apt-mark command. You can see the list of packages automatically installed with "apt-mark showauto". You can directly manipulate the state using that command too. The idea is that if the package that pulled in packages is removed then you can run apt-get autoremove to remove the dependencies too. It is up to you to know that if you want them purged you can add the --purge option. I have good backups plus I use etckeeper so I am confident of simply purging /etc files and therefore mostly purge packages. That avoids a lot of interaction bugs such as some of the well known problems with PHP having config to load libraries that have been removed. If it were purged then the config would have been removed too and no problem would have been noticed. That is just one example. Therefore it is good to keep the system clean of "rc" state things. The deborphan command can help there too. dpkg -l | grep ^rc On my Sid system it is this daily routine: apt-get update && apt-get dist-upgrade -d -y # in /etc/cron.daily apt-get upgrade apt-get dist-upgrade apt-get autoremove --purge apt-get clean reportbug packagefoo At the dist-upgrade and autoremove steps I carefully inspect the list and say No and adjust things with "hold" as needed. After upgrade and reportbug it is often necessary to downgrade to the previous version still in Testing. apt-cache policy packagefoo apt-get install packagefoo=1.2.3-4 Bob signature.asc Description: Digital signature
Re: Purging a package...............
Hi. On Mon, 24 Nov 2014 08:22:29 +1100 Charlie wrote: > > In a different email, under the heading: Re: Installing an Alternative > Init? Andrei posted this in part: > > [quote] A package not properly cleaning after itself on purge is > generally considered a bug in Debian, severity depending on the impact, > of course. [end quote] > > I suppose this is literal, just that package? Yup. You should be able to remove every package installed, unless it's marked 'Essential'. You can remove those too, yet you'll likely (*very*) break your system. And if you're unable to remove a package using apt or aptitude - that's a bug. Both apt and aptitude can leave package's dependencies in place if asked to do so, and that's not a bug. > Because I have install a package which also pulled in some > dependencies. > > Upon purging it, because it didn't suit the purpose of what I wanted to > do. It purged itself, but left the dependencies on the system. And the tool you've used for this was? > I can only suppose this is what is supposed to happen? I backtracked and > found them, purging each in turn. > > I also suppose this is what's supposed to happen? Depends on the tool. And its invocation. > Or is there some command using apt-get that allows me to purge a > package and the dependencies it pulled in as well? This should do the trick: apt-get autoremove --purge Unless, of course, some of package's dependencies are considered special, and marked as manually-installed by apt (see #719417). In the last case you'll likely want to install and use deborphan. Reco -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141124010635.3796bee5e641b0ac7eb91...@gmail.com
Purging a package...............
In a different email, under the heading: Re: Installing an Alternative Init? Andrei posted this in part: [quote] A package not properly cleaning after itself on purge is generally considered a bug in Debian, severity depending on the impact, of course. [end quote] I suppose this is literal, just that package? Because I have install a package which also pulled in some dependencies. Upon purging it, because it didn't suit the purpose of what I wanted to do. It purged itself, but left the dependencies on the system. I can only suppose this is what is supposed to happen? I backtracked and found them, purging each in turn. I also suppose this is what's supposed to happen? Or is there some command using apt-get that allows me to purge a package and the dependencies it pulled in as well? Just curious and trying to learn a bit more. Thanks, Charlie -- Registered Linux User:- 329524 *** Deep in their roots, All flowers keep the light. .Theodore Roethke *** Debian GNU/Linux - just the best way to create magic - -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141124082229.16a1683b@taogypsy
Re: apt-get: purging a package that has already been removed?
Received Tue 02 Mar 2004 9:08pm +1100 from Adam Funk: > Sorry if this is a stupid question, but... > > Suppose foo has already been removed without the --purge option, and I > later want to purge it. > > # apt-get --purge remove foo > gives the error that foo is not installed and therefore takes no action. > > I can work around this with > # apt-get install foo > # apt-get --purge remove foo > but that seems silly. Is there a "correct" way to purge foo? I do it with: # wajig purge foo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: apt-get: purging a package that has already been removed?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, Mar 02, 2004 at 09:46:18AM +, Adam Funk wrote: > but that seems silly. Is there a "correct" way to purge foo? Many. My favorite is just using dpkg --purge. - -- .''`. Paul Johnson <[EMAIL PROTECTED]> : :' : `. `'` proud Debian admin and user `- Debian. Because it *must* work. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFARLxtUzgNqloQMwcRAtD3AKCZ9g9MUE658/vUqYp5w30h+NRfUACguJRv CjpJERtE7DuAJ+vmaO4VEoE= =NzYA -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: apt-get: purging a package that has already been removed?
On Tuesday 02 March 2004 10:10, Adam Funk wrote: > Sorry if this is a stupid question, but... > > Suppose foo has already been removed without the --purge option, and I > later want to purge it. > > # apt-get --purge remove foo > gives the error that foo is not installed and therefore takes no > action. > > I can work around this with > # apt-get install foo > # apt-get --purge remove foo > but that seems silly. Is there a "correct" way to purge foo? Thanks to everyone who said "dpkg --purge". I'm so used to using apt-get for everything (except dpkg -l) that I hadn't thought to look there. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: apt-get: purging a package that has already been removed?
On Tuesday 02 March 2004 10:46, Adam Funk wrote: > Sorry if this is a stupid question, but... > > Suppose foo has already been removed without the --purge option, and I > later want to purge it. > > # apt-get --purge remove foo > gives the error that foo is not installed and therefore takes no action. > > I can work around this with > # apt-get install foo > # apt-get --purge remove foo > but that seems silly. Is there a "correct" way to purge foo? aptitude seems happy enough to purge previously removed packages. -- richard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: apt-get: purging a package that has already been removed?
On 2004-03-02, Adam Funk <[EMAIL PROTECTED]> wrote: > Sorry if this is a stupid question, but... > > Suppose foo has already been removed without the --purge option, and I > later want to purge it. > > # apt-get --purge remove foo > gives the error that foo is not installed and therefore takes no action. > > I can work around this with > # apt-get install foo > # apt-get --purge remove foo > but that seems silly. Is there a "correct" way to purge foo? I don't know if there's a better way, but using dselect to (s)elect it as to be purged and then (i)nstall as per selections works. Alexis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: apt-get: purging a package that has already been removed?
Hello Adam Funk (<[EMAIL PROTECTED]>) wrote: > Sorry if this is a stupid question, but... > > Suppose foo has already been removed without the --purge option, and I > later want to purge it. > > # apt-get --purge remove foo > gives the error that foo is not installed and therefore takes no > action. dpkg --purge foo best regards Andreas Janssen -- Andreas Janssen <[EMAIL PROTECTED]> PGP-Key-ID: 0xDC801674 Registered Linux User #267976 http://www.andreas-janssen.de/debian-tipps.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: apt-get: purging a package that has already been removed?
Hello Adam! On Tue, Mar 02, 2004 at 09:46:18AM +, Adam Funk wrote: > Suppose foo has already been removed without the --purge option, and I > later want to purge it. > > # apt-get --purge remove foo > gives the error that foo is not installed and therefore takes no action. > > I can work around this with > # apt-get install foo > # apt-get --purge remove foo > but that seems silly. Is there a "correct" way to purge foo? dpkg -P Cheers, Flo signature.asc Description: Digital signature
Re: apt-get: purging a package that has already been removed?
On Tue, Mar 02, 2004 at 09:46:18AM +, Adam Funk wrote: > Suppose foo has already been removed without the --purge option, and I > later want to purge it. > > # apt-get --purge remove foo > gives the error that foo is not installed and therefore takes no action. > > I can work around this with > # apt-get install foo > # apt-get --purge remove foo > but that seems silly. Is there a "correct" way to purge foo? dpkg --purge foo Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
apt-get: purging a package that has already been removed?
Sorry if this is a stupid question, but... Suppose foo has already been removed without the --purge option, and I later want to purge it. # apt-get --purge remove foo gives the error that foo is not installed and therefore takes no action. I can work around this with # apt-get install foo # apt-get --purge remove foo but that seems silly. Is there a "correct" way to purge foo? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Purging a package with apt (was: Re: Q: Why 24 depth/not 32?)
On Nov 29 2000, Defresne Sylvain wrote: > * Rogerio Brito ([EMAIL PROTECTED]) wrote: > > apt-get --purge xdm > It should be : apt-get --purge remove xdm Yeah, of course it should be. :-( []s, Roger... -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Rogerio Brito - [EMAIL PROTECTED] - http://www.ime.usp.br/~rbrito/ =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Re: Purging a package with apt (was: Re: Q: Why 24 depth/not 32?)
On Thu, 30 Nov 2000, Ignasi Tura wrote:
> I've grepped /usr/doc/apt for 'purge', man apt, apt --help and I haven't
> found any reference towards 'purge'!
auric{jgg}~/apt2/build/bin#man apt-get | grep -B 1 -i purge
--purge
Use purge instead of remove for anything that would
Jason
Re: Purging a package with apt (was: Re: Q: Why 24 depth/not 32?)
> > apt-get --purge xdm > > > It should be : apt-get --purge remove xdm Hi, I've grepped /usr/doc/apt for 'purge', man apt, apt --help and I haven't found any reference towards 'purge'! I should repeat the commands and clean my glasses, or the docs must be updated? A purge option for apt was something I missed from it, so I've been interested in the theme. Ignasi __ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com
Re: Purging a package with apt (was: Re: Q: Why 24 depth/not 32?)
Hi * Rogerio Brito ([EMAIL PROTECTED]) wrote: > On Nov 28 2000, Nate Amsden wrote: > > apt-get remove xdm > > dpkg --purge xdm > > Just do: > > apt-get --purge xdm > It should be : apt-get --purge remove xdm Bye -- DEFRESNE Sylvain
Purging a package with apt (was: Re: Q: Why 24 depth/not 32?)
On Nov 28 2000, Nate Amsden wrote: > apt-get remove xdm > dpkg --purge xdm Just do: apt-get --purge xdm It saves you the trouble of doing two commands and apt-get also takes care of the dependencies (if there are any to be taken care of). []s, Roger... -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Rogerio Brito - [EMAIL PROTECTED] - http://www.ime.usp.br/~rbrito/ =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
