It's a little funny, given the recent thread on "A GNU distro" - but
I've also been ruminating over the idea of a new, highly experimental
distro.  The main idea would be "no patches" aside from patches
officially distributed by the same upstream.  The only exception would
be for packages with ancient build systems that *require* you to edit
a Makefile and/or a config header, and then only to do said editing.
Other points along the same lines:
* Only package released versions of software - no alpha/beta/pre
versions, definitely no random SCM revisions.
* Always keep up to date with the latest released versions.  (With
possible exceptions if upstream clearly provides support for older
versions - then packaging supported older versions in addition to the
newest version as an alternative would be acceptable.)
* If a package is unmaintained to the point that its latest release no
longer builds using the latest released versions of its dependencies
and the toolchain, then it's simply not packaged (or removed after a
reasonable probation period).
* No elaborate custom configurations.  (Here the example I have in
mind is currently, to install Qt in /usr requires about 10 to 20
different path specification flags, so the distro would consider that
not really supported by upstream.  It would need to install it
somewhere like /usr/lib/qt5 and then add that to PATH and
ld.so.conf.d.  Of course, if future versions of Qt explicitly added
some more convenient way for a distribution to install to /usr, that
would change.)
* Any distribution-specific theming must be in clearly separate
packages from the upstream software.

Unresolved questions:
* What to do if some upstream makes a full release, but to build it
requires prerelease versions of some of its dependencies.
* What to do if some upstream considers itself "too cool" to make
releases.  (My thoughts there are: maybe then the patch-free distro
treats this situation as if upstream has declared that the latest git
revision is always the supported release.)

Anyway, I think out of the distributions I know of, LFS/BLFS is the
closest to this - but even that includes the coreutils i18n patch, and
minimal patches to fix compilation errors.  As I said, this would be
an experiment to see how usable a system with no patches whatsoever
would be in practice.
-- 
Daniel Schepler
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-chat
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Reply via email to