linux-erofs.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Gao Xiang via Linux-erofs <linux-erofs@lists.ozlabs.org>
To: David Michael <fedora.dm0@gmail.com>
Cc: linux-erofs@lists.ozlabs.org
Subject: Re: Enhancement request: exclude paths from mkfs.erofs
Date: Sun, 1 Dec 2019 08:44:35 +0800	[thread overview]
Message-ID: <20191201004431.GA24276@hsiangkao-HP-ZHAN-66-Pro-G1> (raw)
In-Reply-To: <CAEvUa7=N7qUobof=vwpXF2XfXcW8R67SB3KV1phRN2ZmG23CvQ@mail.gmail.com>

Hi David,

On Sat, Nov 30, 2019 at 02:42:37PM -0500, David Michael wrote:
> Hi,
> 
> I'd like to request support for excluding paths in mkfs.erofs similar
> to the -ef (exclude file) option for mksquashfs.  An option that takes
> a file containing a list of paths and glob patterns should be
> sufficient.
> 
> For a simple use case:  I want to build an EROFS image from a Gentoo
> install root, but I don't need development files in it.  An exclude
> option would allow generating a smaller image without the unused files
> while keeping them in the writable source path so additional packages
> could be installed on it later.  This would have /usr/include and
> /usr/lib/*.a for some basic entries in its exclude file.
> 
> If this isn't something that anyone else is interested in implementing
> in the near future, I can try it myself and send a patch after I have
> some time to get more familiar with the code.

That is a useful feature, and I was also thinking that "-pf PSEUDO_FILE"
is useful since root is still needed for device files now...

I have to admit that squashfs has many exist users (thus many exist
developers), but I think in the long term EROFS should perform much better
due to our overall project positioning, ondisk format / runtime advantages
and active community due to paid job maintainers on this as well and open
mind to all new useful features.

For me, now I am busying in XZ algorithm (although there are other random
intra-company exams recently killing much of my time). I have to implement
it to prepare wider scenarios. This is the first priority thing of EROFS.

Cc Guifu. I'm not sure currently he has some extra time working on this.
If some chance, we are very happy that more experienced experts could
join us as well to build a real powerful ROFS solution together.

Files can be simply filtered in the function erofs_mkfs_build_tree.
Any improvements (no matter big or small) are greatly welcomed. :-)

Thanks,
Gao Xiang

> 
> Thanks.
> 
> David

      reply	other threads:[~2019-12-01  0:45 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-30 19:42 Enhancement request: exclude paths from mkfs.erofs David Michael
2019-12-01  0:44 ` Gao Xiang via Linux-erofs [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=20191201004431.GA24276@hsiangkao-HP-ZHAN-66-Pro-G1 \
    --to=linux-erofs@lists.ozlabs.org \
    --cc=fedora.dm0@gmail.com \
    --cc=hsiangkao@aol.com \
    /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;
as well as URLs for NNTP newsgroup(s).