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. > > The most time intensive process is preparing for our semi-annual release. > This is a two week process that provides quality control to ensure all > packages build with current libraries and support programs. If packages are > not kept up to date at other times, the time for the release process will grow > significantly. In addition, during the time of release processing, new > packages continue to be released. > > To try to alleviate this problem, I am proposing that we remove some packages > from LFS. The list below is my initial proposal of packages that are less > frequently needed by users and are not worth maintaining by BLFS. These > packages are user level programs and do not include libraries. Removal of > libraries that are only used by these packages will follow. > > If I do not hear of any objections, I intend to start removing these packages > around October 1st. > > I'm also open to nominations for removal of other packages. > > -- Bruce > > btrfs-progs-4.17.1 > jfsutils-1.1.15 > ntfs-3g-2017.3.23 > reiserfsprogs-3.6.27 > xfsprogs-4.18.0 > JOE-4.6 > Kate-18.08.0 > Mousepad-0.4.1 > zsh-5.6 > Compface-1.5.2 > MC-4.8.21 > Sysstat-11.6.5 > GCC-Ada-8.2.0 > Guile-2.2.4 > Apache-Maven-3.5.4
fop is moving to use maven... If we want to keep fop, we'll need maven. > NcFTP-3.2.6 > Lynx-2.8.9rel.1 or W3m-0.5.3 I'd rather keep lynx, but I can change... What are the advantages of links over the others? > Alpine-2.21 > ProFTPD-1.3.6 > sendmail-8.15.2 > OpenLDAP-2.4.46 > IceWM-1.4.2 > AbiWord-3.0.2 > Gnumeric-1.12.43 > Balsa-2.5.6 > feh-2.27.1 > FontForge-20170731 > Pidgin-2.13.0 > Transmission-2.94 > xarchiver-0.5.4 > Transcode-1.1.7 > Audacious-3.10 > Enscript-1.6.6 > MuPDF-1.13.0 > paps-0.6.8 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) - 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?) - 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. - 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. Regards Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
