public inbox for development@lists.ipfire.org
 help / color / mirror / Atom feed
From: Michael Tremer <michael.tremer@ipfire.org>
To: development@lists.ipfire.org
Subject: Re: Question regarding orphaned files on existing IPFire installations
Date: Mon, 21 Mar 2022 11:40:26 +0000	[thread overview]
Message-ID: <D868B8A1-3601-4C40-91B0-30F09B3E01C4@ipfire.org> (raw)
In-Reply-To: <f4d541bb-0cd7-703b-b950-be428d29d981@ipfire.org>

[-- Attachment #1: Type: text/plain, Size: 2747 bytes --]

Hello,

> On 19 Mar 2022, at 17:05, Peter Müller <peter.mueller(a)ipfire.org> wrote:
> 
> Hello development folks,
> 
> while preparing some of the last Core Updates, I frequently came across rootfile
> changes, or patches making some files previously shipped (and therefore present on
> existing IPFire installations) obsolete.
> 
> By accident, I stumbled across some of these files again, and would therefore like
> to raise the question of what to do with them. Should I, being in responsible for
> a certain Core Update, delete these via the update.sh script?

Yes, this is how it should be done.

> (This would mean to check every rootfile change for deleted files, and include them
> in an 'rm' block in the update.sh script. I am willing to put that effort in, but
> want to make sure this is desired.)

Yes it is.

We have never done a very good job with this, because the diff of the filelists between updates can be rather long and we have no automatic way how to determine this.

However, since we have the filesystem cleanup script that already tidies up any libraries, this should become a lot easier because there isn’t as much fluctuation in /bin, /usr/bin and so on. If anything, there are normally new files.

> Also, I recently came across some scripts such as ovpn-ccd-convert no longer needed.

I merged this patch. Thank you.

> For whatever reason, /usr/share/GeoIP/ is also still present on all IPFire machines
> I administer, although it should have been deleted during the update to Core 140.

Please send a patch to delete it for c166 then.

> If I come across such incidents, should I include them in the 'rm' block of an
> update.sh script as well?

Yes. Files should be deleted before any new ones are extracted (just in case), and so we should also rather have more space available than too little.

> Threads regarding full filesystems come up at https://community.ipfire.org/ on
> a regular, but not worryingly frequency. I am getting the feeling that we are not
> always cleaning up leftovers during updates as thorough as we could to. :-)

I do not believe that there is substantial space to be freed on the root partition.

People with older installations have a / partition that is only 2GB and I hope that compressing the firmware will free up enough space that those systems will be able to function without requirement to be reinstalled with a new partition layout.

> Thanks, and best regards,
> Peter Müller
> 
> P.S.: Also, I am back in action, and can take care of Core Update 167 (or 166, if
> there is something left to do on it), if desired. Just drop me a line.

Yes, please take over the Core Updates again. That saves me a lot of time :)

      reply	other threads:[~2022-03-21 11:40 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-19 17:05 Peter Müller
2022-03-21 11:40 ` Michael Tremer [this message]

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=D868B8A1-3601-4C40-91B0-30F09B3E01C4@ipfire.org \
    --to=michael.tremer@ipfire.org \
    --cc=development@lists.ipfire.org \
    /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