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 \
2018-08-10 13:58:29 +03:00
use/bootloader/os-prober use/x11-autostart use/fonts/install2 use/sound
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,BASE_LISTS, \
$( call tags,( base || desktop) && ( l10n || network) ) )
@$( call add,INSTALL2_PACKAGES,ntfs-3g)
2017-09-25 23:45:56 +03:00
### e2k.mk
mixin/e2k-base : use /tty /S 0 use /net -eth /dhcp ; @:
2018-05-21 22:33:38 +03:00
mixin/e2k-desktop : use /e 2k /x 11 use /l 10n /default /ru_RU \
2017-09-25 23:45:56 +03:00
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)
2018-05-21 22:33:38 +03:00
mixin/e2k-livecd-install : use /e 2k /x 11
@$( call add,THE_PACKAGES,livecd-install alterator-notes)
@$( call add,THE_PACKAGES,fdisk hdparm rsync openssh vim-console)
@$( call add,THE_PACKAGES,apt-repo)
mixin/e2k-mate : use /e 2k /x 11 use /x 11/xorg use /fonts /install 2 \
2018-07-18 16:16:59 +03:00
use/deflogin/live use/deflogin/xgrp \
use/x11/mate use/x11/lightdm/slick \
2018-05-21 22:33:38 +03:00
use/fonts/otf/adobe use/fonts/otf/mozilla \
use/fonts/ttf/google use/fonts/ttf/redhat
@$( call set,INSTALLER,altlinux-desktop)
@$( call add,THE_BRANDING,mate-settings)
@$( call add,THE_BRANDING,alterator)
@$( call add,THE_BRANDING,graphics)
@$( call add,THE_PACKAGES,setup-mate-terminal)
2018-07-18 16:16:59 +03:00
@$( call add,THE_PACKAGES,setup-mate-nocomposite)
2018-05-21 22:33:38 +03:00
@$( call add,THE_PACKAGES,alterator-standalone)
@$( call add,THE_PACKAGES,terminfo-extra)
@$( call add,THE_PACKAGES,ethtool net-tools ifplugd)
@$( call add,THE_PACKAGES,zsh bash-completion)
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
2018-12-24 14:47:23 +03:00
mixin/regular-x11 : use /luks use /volumes /regular \
use/browser/firefox/i18n use/browser/firefox/h264 \
2019-03-13 22:07:28 +03:00
use/branding use/ntp/chrony use/services/lvm2-disable
2018-12-24 14:47:23 +03:00
@$( call add,THE_LISTS,$( call tags,( base || desktop) && regular) )
@$( call add,THE_PACKAGES,disable-usb-autosuspend)
@$( call add,THE_PACKAGES,btrfs-progs)
@$( call add,THE_PACKAGES,gpm)
@$( call add,DEFAULT_SERVICES_DISABLE,gpm powertop)
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
# common WM live/installer bits
2019-07-17 11:41:50 +03:00
mixin/regular-desktop : use /x 11/xorg +alsa use /xdg -user -dirs \
2019-12-02 19:11:11 +03:00
use/fonts/otf/adobe use/fonts/otf/mozilla use/net-eth
2018-12-23 18:01:05 +03:00
@$( call add,THE_PACKAGES,pam-limits-desktop beesu polkit)
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,alterator-notes dvd+rw-tools)
@$( call add,THE_BRANDING,alterator graphics indexhtml notes)
@$( call add,THE_PACKAGES,$$ ( THE_IMAGEWRITER) )
2020-02-11 19:28:13 +03:00
@$( call set,THE_IMAGEWRITER,altmediawriter)
2019-01-07 10:07:09 +03:00
@$( call add,THE_PACKAGES,upower bluez)
@$( call add,DEFAULT_SERVICES_DISABLE,gssd idmapd krb5kdc rpcbind)
@$( call add,DEFAULT_SERVICES_ENABLE,bluetoothd)
2019-05-20 18:56:40 +03:00
@$( call add,DEFAULT_SERVICES_ENABLE,cups)
2019-11-25 14:29:12 +03:00
@$( call add,DEFAULT_SERVICES_ENABLE,alteratord)
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
2019-01-07 10:31:27 +03:00
mixin/desktop-extra :
@$( call add,BASE_LISTS,$( call tags,( archive || base) && extra) )
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-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)
2019-09-09 22:25:48 +03:00
mixin/regular-icewm : use /fonts /ttf /redhat +icewm +nm -gtk
2019-01-07 09:16:15 +03:00
@$( call add,THE_LISTS,$( call tags,regular icewm) )
2019-01-18 14:35:38 +03:00
@$( call add,THE_LISTS,$( call tags,desktop nm) )
@$( call add,THE_PACKAGES,icewm-startup-networkmanager)
2019-11-16 20:22:04 +03:00
@$( call add,THE_PACKAGES,mnt)
2019-01-07 09:16:15 +03:00
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
# gdm2.20 can reboot/halt with both sysvinit and systemd, and is slim
2019-04-23 08:38:46 +03:00
mixin/regular-gnustep : use /x 11/gnustep use /x 11/gdm 2.20 use /mediacheck
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_BRANDING,graphics)
2020-02-16 10:10:50 +03:00
mixin/regular-cinnamon : use /x 11/cinnamon use /x 11/lightdm /slick +nm -gtk \
2019-09-02 18:07:32 +03:00
use/fonts/ttf/google use/net/nm/mmgui use/im; @:
2019-07-03 20:01:16 +03:00
mixin/regular-kde5 : use /x 11/kde 5 use /browser /falkon \
use/fonts/ttf/google use/fonts/ttf/redhat use/fonts/zerg \
+nm +pulse
@$( call add,THE_PACKAGES,kde5-telepathy falkon-kde5)
2019-09-09 22:25:48 +03:00
mixin/xfce-base : use /x 11/xfce +nm -gtk \
2018-12-20 13:00:57 +03:00
use/fonts/ttf/redhat use/fonts/ttf/google/extra
2019-06-09 12:39:29 +03:00
@$( call add,THE_BRANDING,xfce-settings)
2020-01-27 20:08:49 +03:00
@$( call add,THE_PACKAGES,xreader)
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
2019-09-02 18:07:32 +03:00
mixin/regular-xfce : mixin /xfce -base use /x 11/xfce /full \
use/domain-client; @:
mixin/regular-xfce-sysv : mixin /xfce -base \
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
use/fonts/otf/adobe use/fonts/otf/mozilla
@$( call add,THE_PACKAGES,pnmixer pm-utils elinks mpg123)
2018-03-11 09:22:44 +03:00
@$( call add,THE_PACKAGES,alsa-oss ossp whdd wget cdrkit)
2019-05-21 10:11:17 +03:00
@$( call add,THE_PACKAGES,qasmixer)
2019-02-14 17:47:35 +03:00
@$( call add,THE_PACKAGES,xfce4-screensaver)
2019-05-28 19:45:33 +03:00
@$( call add,THE_PACKAGES,sysstat leafpad)
2019-05-21 10:11:17 +03:00
@$( call add,THE_PACKAGES,nload)
2019-06-22 20:05:57 +03:00
@$( call add,THE_PACKAGES,NetworkManager-tui)
2019-12-05 07:06:50 +03:00
@$( call add,THE_PACKAGES,apt-conf-ignore-systemd)
2020-02-17 15:14:24 +03:00
@$( call add,THE_PACKAGES,pandoc)
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
2019-09-09 22:25:48 +03:00
mixin/regular-lxde : use /x 11/lxde use /im +nm -gtk
2019-01-24 15:40:19 +03:00
@$( call add,THE_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
2020-02-11 19:28:13 +03:00
mixin/regular-lxqt : use /x 11/lxqt +nm -gtk ; @:
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
2019-09-09 22:25:48 +03:00
mixin/mate-base : use /x 11/mate use /fonts /ttf /google +nm -gtk
2019-01-24 15:40:19 +03:00
@$( call add,THE_LISTS,$( call tags,mobile mate) )
2018-12-12 10:24:31 +03:00
2019-09-02 18:07:32 +03:00
mixin/regular-mate : mixin /mate -base use /domain -client
@$( call add,THE_LISTS,$( call tags,base smartcard) )
2019-01-29 13:59:55 +03:00
mixin/office : use /fonts /ttf /google use /fonts /ttf /xo
@$( call add,THE_LISTS,$( call tags,desktop && ( cups || office) ) )
@$( call add,THE_PACKAGES,apt-indicator)
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
# 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; @:
2020-02-12 07:10:56 +03:00
mixin/regular-builder : use /dev /builder /base use /net -eth /dhcp use /ntp /chrony
2019-03-21 08:55:20 +03:00
@$( call add,THE_PACKAGES,bash-completion elinks gpm lftp openssh)
@$( call add,THE_PACKAGES,rpm-utils screen tmux wget zsh)
@$( call add,DEFAULT_SERVICES_ENABLE,gpm)
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
### 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)
2019-09-02 21:43:37 +03:00
@$( call set,GLOBAL_NET_ETH,)
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
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 ; @:
