On 2018-09-25 15:44 +0200, Pierre Labastie via blfs-dev wrote: > On 9/24/18 9:36 PM, Bruce Dubbs via blfs-dev wrote: > > Over the years, BLFS has grown a lot. There are over 1000 individual > > tarballs > > listed in the book. This creates a large maintenance burden. It is a rare > > week when we have less than 30 new packages that need to be updated.
> Other packages that coud be removed (for deps, I've looked only at Sys V, > systemd may have some other requirements). Note that I won't say something > which has already been said (for example somebody suggested to remove exim, > which I would suggest too): > - cryptsetup+volume_key+libblockdev+udisks2 (only recommended for gvfs, and > optional for kf5) > - MIT Kerberos (useful in big multi-user environments only, optional dep of > many packages, but not more) gnome-control-center requires it. > - stunnel (optional dep of curl only) > - tripwire > - if removing some editors, why not remove bluefish, et al? (keep only vim, > emacs, and nano) > - tcsh (rather than zsh, nobody wants to use C-shell now) > - highlight is recommended for gtk-doc, because at a time there was a broken > vim script in gtk-doc. Is it still true? if not, highlight could be dropped. > - ibus (optional dep, needed on systemd?) Though I use fcitx, gnome-shell requires ibus now :(. > - sharutils (optional dep) > - xdg-user-dirs (was only needed for LXQt) > - hdparm (is this needed with modern hard drives?) > - dovecot (is there an lfs user setting up mail servers?) > - we could choose to have only one of bind or unbound > - sawfish (allows to remove rep-gtk and librep too) > - kde (but keep a few kf5 apps, specially okular) > - keep only one of xfce and lxde > - gnome apps and runtime deps, (I guess some gnome libs are useful outside of > gnome), but remember I use only the Sys V book. I think Douglas can handle them well :). > - icedtea-web (I believed it was scheduled for removal, but it is still there) > - SGML stack (what is this dinosaur doing in our book?) > > One general comment. I do not think removing packages will ease the book > maintenance that much. The linux ecosystem is growing, and the more important, > the "release early, release often" motto leads to frequent updates of > important packages we cannot drop. Even if we strip the book to half of the > current packages, there should still remain about 500 packages. If each of > those is updated twice a year, that makes for 1000 updates per year, that is > ~3 per days! > > I think that we should work on automating most of the updating work (build, > measure, edit, and test that it fits together), so that we could concentrate > on fixing (upstream, mainly) bugs and finding the "best way" to build > problematic packages. Agree. I'll try to do this for LFS and BLFS once I get a new workstation capable to compile lots of packages in a night. -- Xi Ruoyao <[email protected]> School of Aerospace Science and Technology, Xidian University -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
