mixin.mk: gather all mixin/* targets
These have appeared in desktop.mk, regular.mk, vm.mk
over time, and there are two problems around.
The minor one is that mixins have been introduced as
handy reusable bits close in context of their use;
this practically means that they fall under the same
class restrictions as their parent targets, that is
a mixin coming from regular.mk will only be available
for "distro" IMAGE_CLASS, and so on.
The major one is probably the worst design flaw in m-p:
building images from ground up, where ground is a valid
standalone buildable target as well.
Life has shown that we rather want to build up images
the other way around, choosing what essentials go in first
and then fitting the fine details along with the packaging.
The first sign of this difference appeared with ARMv7 Simply:
we had a well-built configuration aiming for x86 ISO, still
we needed roughly the same app/environment configuration
put into armh disk image.
Those platforms were different enough that we didn't actually
plan shipping *lots* of distributions but the problem was clear,
and it was much alike to the one that sprang m-p to life in the
first place (when we had a range of "common" distros and needed
to create and maintain a set of "school" ones that mostly had
similar or even identical difference to their respective base
ones -- and we couldn't do something like conf.d/p8.mk does now).
So mixins are going to become the softer way to turn m-p's
target configuration chain upside down to considerable extent:
build up what you're going to mix into the various deliverables,
and make it as portable across image classes, hardware platforms,
repository branches as feasible so that total maintenance effort
needed goes down or at least doesn't spike too bad.
And here's the first strike at that.
2017-09-15 17:45:11 +03:00
### various mixins with their origin
### desktop.mk
mixin/desktop-installer : +net -eth +vmguest \
use/x11-autostart use/fonts/install2 use/sound
@$( call add,BASE_LISTS, \
$( call tags,( base || desktop) && ( l10n || network) ) )
@$( call add,INSTALL2_PACKAGES,ntfs-3g)
@$( call add,BASE_PACKAGES,os-prober)
2017-09-25 23:45:56 +03:00
### e2k.mk
mixin/e2k-base : use /tty /S 0 use /net -eth /dhcp ; @:
mixin/e2k-desktop : use /e 2k /x 11 use /e 2k /sound use /l 10n /default /ru_RU \
use/browser/firefox/esr use/browser/firefox/i18n \
use/fonts/otf/adobe use/fonts/otf/mozilla
@$( call add,THE_PACKAGES,xinit xterm mc)
@$( call add,THE_PACKAGES,fonts-bitmap-terminus)
mixin.mk: gather all mixin/* targets
These have appeared in desktop.mk, regular.mk, vm.mk
over time, and there are two problems around.
The minor one is that mixins have been introduced as
handy reusable bits close in context of their use;
this practically means that they fall under the same
class restrictions as their parent targets, that is
a mixin coming from regular.mk will only be available
for "distro" IMAGE_CLASS, and so on.
The major one is probably the worst design flaw in m-p:
building images from ground up, where ground is a valid
standalone buildable target as well.
Life has shown that we rather want to build up images
the other way around, choosing what essentials go in first
and then fitting the fine details along with the packaging.
The first sign of this difference appeared with ARMv7 Simply:
we had a well-built configuration aiming for x86 ISO, still
we needed roughly the same app/environment configuration
put into armh disk image.
Those platforms were different enough that we didn't actually
plan shipping *lots* of distributions but the problem was clear,
and it was much alike to the one that sprang m-p to life in the
first place (when we had a range of "common" distros and needed
to create and maintain a set of "school" ones that mostly had
similar or even identical difference to their respective base
ones -- and we couldn't do something like conf.d/p8.mk does now).
So mixins are going to become the softer way to turn m-p's
target configuration chain upside down to considerable extent:
build up what you're going to mix into the various deliverables,
and make it as portable across image classes, hardware platforms,
repository branches as feasible so that total maintenance effort
needed goes down or at least doesn't spike too bad.
And here's the first strike at that.
2017-09-15 17:45:11 +03:00
### regular.mk
# common WM live/installer bits
2018-01-13 09:09:53 +03:00
mixin/regular-desktop : use /x 11/xorg +alsa use /xdg -user -dirs
mixin.mk: gather all mixin/* targets
These have appeared in desktop.mk, regular.mk, vm.mk
over time, and there are two problems around.
The minor one is that mixins have been introduced as
handy reusable bits close in context of their use;
this practically means that they fall under the same
class restrictions as their parent targets, that is
a mixin coming from regular.mk will only be available
for "distro" IMAGE_CLASS, and so on.
The major one is probably the worst design flaw in m-p:
building images from ground up, where ground is a valid
standalone buildable target as well.
Life has shown that we rather want to build up images
the other way around, choosing what essentials go in first
and then fitting the fine details along with the packaging.
The first sign of this difference appeared with ARMv7 Simply:
we had a well-built configuration aiming for x86 ISO, still
we needed roughly the same app/environment configuration
put into armh disk image.
Those platforms were different enough that we didn't actually
plan shipping *lots* of distributions but the problem was clear,
and it was much alike to the one that sprang m-p to life in the
first place (when we had a range of "common" distros and needed
to create and maintain a set of "school" ones that mostly had
similar or even identical difference to their respective base
ones -- and we couldn't do something like conf.d/p8.mk does now).
So mixins are going to become the softer way to turn m-p's
target configuration chain upside down to considerable extent:
build up what you're going to mix into the various deliverables,
and make it as portable across image classes, hardware platforms,
repository branches as feasible so that total maintenance effort
needed goes down or at least doesn't spike too bad.
And here's the first strike at that.
2017-09-15 17:45:11 +03:00
@$( call add,THE_PACKAGES,pam-limits-desktop)
@$( call add,THE_PACKAGES,installer-feature-desktop-other-fs-stage2)
@$( call add,THE_PACKAGES,alterator-notes dvd+rw-tools)
@$( call add,THE_BRANDING,alterator graphics indexhtml notes)
@$( call add,THE_PACKAGES,$$ ( THE_IMAGEWRITER) )
@$( call set,THE_IMAGEWRITER,imagewriter)
mixin/regular-wmaker : use /efi /refind use /syslinux /ui /gfxboot \
use/fonts/ttf/redhat use/x11/wmaker
@$( call add,LIVE_PACKAGES,livecd-install-wmaker)
@$( call add,LIVE_PACKAGES,installer-feature-no-xconsole-stage3)
@$( call add,MAIN_PACKAGES,wmgtemp wmhdaps wmpomme wmxkbru xxkb)
# gdm2.20 can reboot/halt with both sysvinit and systemd, and is slim
mixin/regular-gnustep : use /x 11/gnustep use /x 11/gdm 2.20 use /mediacheck \
use/browser/firefox/classic
@$( call add,THE_BRANDING,graphics)
mixin/regular-xfce : use /x 11/xfce use /fonts /ttf /redhat use /x 11/gtk /nm +nm ; @:
mixin/regular-xfce-sysv : use /init /sysv /polkit use /deflogin /sysv /nm \
use/x11/lightdm/gtk \
use/browser/firefox use/browser/firefox/classic \
use/browser/firefox/i18n use/browser/firefox/h264 \
use/fonts/otf/adobe use/fonts/otf/mozilla
@$( call add,THE_PACKAGES,pnmixer pm-utils elinks mpg123)
2018-02-04 02:46:23 +03:00
mixin/regular-lxde : use /x 11/lxde use /x 11/gtk /nm use /im \
use/browser/palemoon/i18n +nm +alsa
mixin.mk: gather all mixin/* targets
These have appeared in desktop.mk, regular.mk, vm.mk
over time, and there are two problems around.
The minor one is that mixins have been introduced as
handy reusable bits close in context of their use;
this practically means that they fall under the same
class restrictions as their parent targets, that is
a mixin coming from regular.mk will only be available
for "distro" IMAGE_CLASS, and so on.
The major one is probably the worst design flaw in m-p:
building images from ground up, where ground is a valid
standalone buildable target as well.
Life has shown that we rather want to build up images
the other way around, choosing what essentials go in first
and then fitting the fine details along with the packaging.
The first sign of this difference appeared with ARMv7 Simply:
we had a well-built configuration aiming for x86 ISO, still
we needed roughly the same app/environment configuration
put into armh disk image.
Those platforms were different enough that we didn't actually
plan shipping *lots* of distributions but the problem was clear,
and it was much alike to the one that sprang m-p to life in the
first place (when we had a range of "common" distros and needed
to create and maintain a set of "school" ones that mostly had
similar or even identical difference to their respective base
ones -- and we couldn't do something like conf.d/p8.mk does now).
So mixins are going to become the softer way to turn m-p's
target configuration chain upside down to considerable extent:
build up what you're going to mix into the various deliverables,
and make it as portable across image classes, hardware platforms,
repository branches as feasible so that total maintenance effort
needed goes down or at least doesn't spike too bad.
And here's the first strike at that.
2017-09-15 17:45:11 +03:00
@$( call add,LIVE_LISTS,$( call tags,desktop gvfs) )
2018-01-14 17:26:09 +03:00
@$( call add,THE_PACKAGES,qasmixer qpdfview)
mixin.mk: gather all mixin/* targets
These have appeared in desktop.mk, regular.mk, vm.mk
over time, and there are two problems around.
The minor one is that mixins have been introduced as
handy reusable bits close in context of their use;
this practically means that they fall under the same
class restrictions as their parent targets, that is
a mixin coming from regular.mk will only be available
for "distro" IMAGE_CLASS, and so on.
The major one is probably the worst design flaw in m-p:
building images from ground up, where ground is a valid
standalone buildable target as well.
Life has shown that we rather want to build up images
the other way around, choosing what essentials go in first
and then fitting the fine details along with the packaging.
The first sign of this difference appeared with ARMv7 Simply:
we had a well-built configuration aiming for x86 ISO, still
we needed roughly the same app/environment configuration
put into armh disk image.
Those platforms were different enough that we didn't actually
plan shipping *lots* of distributions but the problem was clear,
and it was much alike to the one that sprang m-p to life in the
first place (when we had a range of "common" distros and needed
to create and maintain a set of "school" ones that mostly had
similar or even identical difference to their respective base
ones -- and we couldn't do something like conf.d/p8.mk does now).
So mixins are going to become the softer way to turn m-p's
target configuration chain upside down to considerable extent:
build up what you're going to mix into the various deliverables,
and make it as portable across image classes, hardware platforms,
repository branches as feasible so that total maintenance effort
needed goes down or at least doesn't spike too bad.
And here's the first strike at that.
2017-09-15 17:45:11 +03:00
mixin/regular-tde : +tde \
use/syslinux/ui/gfxboot use/browser/firefox/classic use/fonts/ttf/redhat
@$( call add,THE_PACKAGES_REGEXP,kdeedu-kalzium.* kdeedu-ktouch.*)
@$( call add,DEFAULT_SERVICES_DISABLE,upower bluetoothd)
mixin/regular-lxqt : use /x 11/lxqt use /x 11/sddm \
use/browser/qupzilla use/x11/gtk/nm +nm +plymouth
@$( call set,THE_IMAGEWRITER,rosa-imagewriter)
# NB: never ever use/syslinux/ui/gfxboot here as gfxboot mangles
# kernel cmdline resulting in method:disk instead of method:cdrom
# which will change propagator's behaviour to probe additional
# filesystems (ro but no loop) thus potentially writing to
# an unrecovered filesystem's journal
mixin/regular-rescue : use /rescue use /isohybrid use /luks use /branding \
use/syslinux/ui/menu use/syslinux/timeout/600 \
use/firmware/qlogic test/rescue/no-x11 +sysvinit; @:
### vm.mk
mixin/cloud-init :
@$( call add,BASE_PACKAGES,cloud-init)
@$( call add,DEFAULT_SERVICES_ENABLE,cloud-config cloud-final)
@$( call add,DEFAULT_SERVICES_ENABLE,cloud-init cloud-init-local)
2017-10-23 14:18:24 +03:00
mixin/opennebula-context :
@$( call add,BASE_PACKAGES,opennebula-context)
@$( call add,DEFAULT_SERVICES_ENABLE,one-context-local one-context)
mixin.mk: gather all mixin/* targets
These have appeared in desktop.mk, regular.mk, vm.mk
over time, and there are two problems around.
The minor one is that mixins have been introduced as
handy reusable bits close in context of their use;
this practically means that they fall under the same
class restrictions as their parent targets, that is
a mixin coming from regular.mk will only be available
for "distro" IMAGE_CLASS, and so on.
The major one is probably the worst design flaw in m-p:
building images from ground up, where ground is a valid
standalone buildable target as well.
Life has shown that we rather want to build up images
the other way around, choosing what essentials go in first
and then fitting the fine details along with the packaging.
The first sign of this difference appeared with ARMv7 Simply:
we had a well-built configuration aiming for x86 ISO, still
we needed roughly the same app/environment configuration
put into armh disk image.
Those platforms were different enough that we didn't actually
plan shipping *lots* of distributions but the problem was clear,
and it was much alike to the one that sprang m-p to life in the
first place (when we had a range of "common" distros and needed
to create and maintain a set of "school" ones that mostly had
similar or even identical difference to their respective base
ones -- and we couldn't do something like conf.d/p8.mk does now).
So mixins are going to become the softer way to turn m-p's
target configuration chain upside down to considerable extent:
build up what you're going to mix into the various deliverables,
and make it as portable across image classes, hardware platforms,
repository branches as feasible so that total maintenance effort
needed goes down or at least doesn't spike too bad.
And here's the first strike at that.
2017-09-15 17:45:11 +03:00
mixin/icewm : use /x 11/lightdm /gtk +icewm ; @:
