Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Stephan Hoffmann <sho@relinux.de>
To: buildroot@busybox.net
Subject: [Buildroot] [RFC] Removing CLEAN_CMDS and UNINSTALL_(STAGING|TARGET)_CMDS
Date: Tue, 12 Feb 2013 09:38:56 +0100	[thread overview]
Message-ID: <5119FFA0.2090804@relinux.de> (raw)
In-Reply-To: <1360363083-28747-1-git-send-email-thomas.petazzoni@free-electrons.com>

Am 08.02.2013 23:37, schrieb Thomas Petazzoni:
> Hello,
>
> This is an RFC patch set to discuss whether or not we should keep the
> <pkg>_CLEAN_CMDS, <pkg>_UNINSTALL_TARGET_CMDS and
> <pkg>_UNINSTALL_STAGING_CMDS. It is a topic that has been discussed at
> various times in the past months/years.
Hello Thomas,

the "make <pkg>-clean" handling we have is practically useless, since
some packages implement it more or less and others only remove the stamp
files or whatever. So we could either repair it or remove it.

Since the only reason to clean a package is that one has changed the
configuration "make <pkg>-dirclean" does as well. So I opt for removing
the <pkg>-clean target and the <pkg>_CLEAN_CMDS.

>
> A lot of packages don't implement them, we generally don't ask for
> them to be implemented when reviewing packages, and the uninstall
> commands are generally never updated when a package version is bumped,
> which means that they are probably bitrotting pretty quickly. We also
> have no automated way of testing these commands.
>
> That said, it is true that the <pkg>-clean target might be useful for
> some use cases. However, is <pkg>-uninstall really useful, considering
> that it doesn't take into account the removal of the reverse
> dependencies?
From buildroot's concept of defining the packages with Kconfig I did not
see the point of uninstall at all. It could either be called
automatically after removing packages from .config or, when make
<package>_uninstall is called, update .config afterwards. Both does not
seem practicable to me.

So I opt for removing this, too.


Regards

Stephan
> Again, this patch set is not meant to be applied as is, it is here to
> get the discussion started. Sending the patches with it is simply a
> way to ensure that the discussion is considered seriously :-)
>
> Best regards,
>
> Thomas
>
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot

  parent reply	other threads:[~2013-02-12  8:38 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-08 22:37 [Buildroot] [RFC] Removing CLEAN_CMDS and UNINSTALL_(STAGING|TARGET)_CMDS Thomas Petazzoni
2013-02-08 22:37 ` [Buildroot] [RFC 1/5] packages: remove all the <pkg>_CLEAN_CMDS commands Thomas Petazzoni
2013-02-08 22:38 ` [Buildroot] [RFC 2/5] package: remove support from CLEAN_CMDS Thomas Petazzoni
2013-02-08 22:38 ` [Buildroot] [RFC 3/5] packages: remove all the <pkg>_UNINSTALL_STAGING_CMDS commands Thomas Petazzoni
2013-02-08 22:38 ` [Buildroot] [RFC 4/5] packages: remove all the <pkg>_UNINSTALL_TARGET_CMDS commands Thomas Petazzoni
2013-02-08 22:38 ` [Buildroot] [RFC 5/5] package: remove support for UNINSTALL_(TARGET|STAGING)_CMDS Thomas Petazzoni
2013-02-08 22:49 ` [Buildroot] [RFC] Removing CLEAN_CMDS and UNINSTALL_(STAGING|TARGET)_CMDS Yann E. MORIN
2013-02-08 23:26   ` Thomas Petazzoni
2013-02-12  6:32 ` Arnout Vandecappelle
2013-02-12  8:38 ` Stephan Hoffmann [this message]
2013-02-12 13:25 ` Luca Ceresoli

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5119FFA0.2090804@relinux.de \
    --to=sho@relinux.de \
    --cc=buildroot@busybox.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox