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
2021-06-07 17:36:30 +03:00
mixin/desktop-installer : +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 \
2020-11-06 15:09:38 +03:00
use/browser/firefox/esr use/browser/firefox \
2017-09-25 23:45:56 +03:00
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
2020-09-05 23:02:42 +03:00
@$( call add,THE_PACKAGES,livecd-install)
2018-05-21 22:33:38 +03:00
@$( 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)
2023-11-29 11:02:49 +03:00
mixin/vm-archdep :: use /auto -resize ; @:
i f e q ( , $( filter -out i 586 x 86_ 64 aarch 64,$ ( ARCH ) ) )
mixin/vm-archdep :: +efi
i f e q ( , $( filter -out p 10,$ ( BRANCH ) ) )
@$( call set,KFLAVOURS,un-def)
e l s e
@$( call set,KFLAVOURS,std-def un-def)
e n d i f
e n d i f
i f e q ( , $( filter -out armh ,$ ( ARCH ) ) )
mixin/vm-archdep ::
@$( call set,KFLAVOURS,un-def mp)
e n d i f
i f e q ( , $( filter -out armh aarch 64,$ ( ARCH ) ) )
mixin/vm-archdep :: use /bootloader /uboot use /no -sleep use /arm -rpi 4; @:
e n d i f
i f e q ( , $( filter -out mipsel ,$ ( ARCH ) ) )
mixin/vm-archdep :: use /tty /S 0
@$( call set,KFLAVOURS,un-malta)
e n d i f
i f e q ( , $( filter -out riscv 64,$ ( ARCH ) ) )
mixin/vm-archdep :: use /bootloader /uboot
@$( call set,KFLAVOURS,un-def)
e n d i f
mixin/vm-archdep-x11 : mixin /vm -archdep use /vmguest /kvm /x 11; @:
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
2023-09-21 15:47:36 +03:00
mixin/regular-x11 : use /browser /firefox \
2019-03-13 22:07:28 +03:00
use/branding use/ntp/chrony use/services/lvm2-disable
2021-03-17 21:04:51 +03:00
@$( call add,THE_LISTS,$( call tags,( base || desktop) && regular && !extra) )
2018-12-24 14:47:23 +03:00
@$( 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)
2022-11-25 14:59:47 +03:00
i f n e q ( s i s y p h u s , $( BRANCH ) )
2021-09-01 00:53:34 +03:00
@$( call set,FX_FLAVOUR,-esr)
e n d i f
2018-12-24 14:47:23 +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
# common WM live/installer bits
2021-12-13 13:50:26 +03:00
mixin/regular-desktop : +alsa +nm -native \
2021-03-15 18:37:06 +03:00
use/x11/xorg use/xdg-user-dirs use/l10n \
use/fonts/otf/adobe use/fonts/otf/mozilla use/branding/notes
2023-02-17 11:11:20 +03:00
@$( call set,LOCALES,en_US ru_RU pt_BR)
2020-09-05 23:02:42 +03:00
@$( call add,THE_PACKAGES,pam-limits-desktop beesu polkit dvd+rw-tools)
2020-08-21 18:53:58 +03:00
@$( call add,THE_BRANDING,alterator graphics indexhtml)
2020-09-05 23:02:42 +03:00
i f n e q ( , $( filter -out e 2k %,$ ( ARCH ) ) )
@$( call add,THE_BRANDING,notes)
e n d i f
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,$$ ( THE_IMAGEWRITER) )
2020-02-11 19:28:13 +03:00
@$( call set,THE_IMAGEWRITER,altmediawriter)
2021-07-22 14:03:07 +03:00
@$( call add,THE_PACKAGES,upower udev-rules-rfkill-uaccess)
2019-01-07 10:07:09 +03:00
@$( call add,DEFAULT_SERVICES_DISABLE,gssd idmapd krb5kdc rpcbind)
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)
2022-01-16 12:52:06 +03:00
@$( call add,CONTROL,fusermount:public)
2022-03-01 13:42:20 +03:00
@$( call add,CONTROL,libnss-role:disabled)
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) )
2021-09-02 19:51:03 +03:00
mixin/regular-wmaker : use /fonts /ttf /redhat use /x 11/wmaker +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
@$( call add,LIVE_PACKAGES,installer-feature-no-xconsole-stage3)
2021-09-10 20:33:36 +03:00
@$( call add,MAIN_PACKAGES,wmgtemp wmhdaps wmxkbru xxkb)
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-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_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
2023-08-13 16:21:46 +03:00
mixin/regular-gnustep : use /x 11/gnustep 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)
2023-11-28 17:56:20 +03:00
mixin/regular-cinnamon : use /x 11/cinnamon use /x 11/lightdm /slick +nm -gtk \
2023-08-08 14:47:20 +03:00
use/fonts/ttf/google use/im
@$( call add,THE_PACKAGES,xdg-user-dirs-gtk)
2023-08-30 15:34:55 +03:00
@$( call add,THE_PACKAGES,gnome-disk-utility gnome-system-monitor)
2019-07-03 20:01:16 +03:00
2021-07-28 07:57:01 +03:00
mixin/regular-deepin : use /x 11/deepin use /browser /chromium +nm ; @:
2021-06-24 18:11:44 +03:00
2023-11-28 20:22:14 +03:00
mixin/regular-gnome : use /x 11/gnome use /fonts /ttf /redhat +nm -gtk 4
2023-09-26 18:17:50 +03:00
@$( call add,THE_PACKAGES,power-profiles-daemon)
2023-08-23 11:44:59 +03:00
@$( call add,THE_PACKAGES,gnome-terminal)
2023-10-23 20:57:55 +03:00
@$( call add,THE_PACKAGES,gnome-software)
2023-08-23 11:44:59 +03:00
@$( call add,PINNED_PACKAGES,gnome-terminal:Required)
2020-05-16 17:52:13 +03:00
@$( call add,THE_PACKAGES,chrome-gnome-shell)
2023-06-02 07:20:41 +03:00
@$( call add,THE_PACKAGES,qt5-wayland qt6-wayland)
2023-10-09 19:30:53 +03:00
@$( call add,THE_PACKAGES,cups-pk-helper cups)
2023-10-12 17:35:56 +03:00
@$( call add,THE_PACKAGES,eepm)
2023-10-16 19:43:05 +03:00
@$( call add,THE_PACKAGES,fonts-ttf-lxgw-wenkai)
2020-05-16 17:52:13 +03:00
2019-07-03 20:01:16 +03:00
mixin/regular-kde5 : use /x 11/kde 5 use /browser /falkon \
2021-04-07 21:51:48 +03:00
use/x11/kde5-display-manager-lightdm \
2023-11-03 15:10:31 +03:00
use/fonts/ttf/google use/fonts/ttf/redhat use/fonts/zerg
2023-10-23 13:45:22 +03:00
@$( call add,THE_PACKAGES,plasma5-xdg-desktop-portal-kde)
2023-06-02 20:35:09 +03:00
@$( call add,THE_PACKAGES,qt6-wayland)
2023-11-07 20:36:06 +03:00
@$( call add,THE_PACKAGES,plasma5-discover)
2024-03-02 14:14:24 +03:00
@$( call add,THE_PACKAGES,accountsservice)
2023-10-23 13:45:22 +03:00
i f n e q ( , $( filter -out e 2k % riscv 64 loongarch 64,$ ( ARCH ) ) )
2021-12-12 12:56:37 +03:00
@$( call add,THE_PACKAGES,falkon-kde5)
e n d i f
2019-07-03 20:01:16 +03:00
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
2021-08-01 19:44:21 +03:00
@$( call add,THE_PACKAGES,xfce4-regular)
2020-01-27 20:08:49 +03:00
@$( call add,THE_PACKAGES,xreader)
2020-05-05 12:46:51 +03:00
@$( call add,THE_PACKAGES,xdg-user-dirs-gtk)
2022-08-20 18:10:28 +03:00
@$( call add,THE_PACKAGES,xkill)
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
2023-11-03 15:10:31 +03:00
mixin/regular-xfce : mixin /xfce -base use /domain -client +pipewire
2022-02-13 15:52:13 +03:00
@$( call add,THE_PACKAGES,pavucontrol xscreensaver-frontend)
2021-06-15 12:42:51 +03:00
@$( call add,THE_PACKAGES,xfce4-pulseaudio-plugin xfce-polkit)
2019-09-02 18:07:32 +03:00
2019-09-09 22:25:48 +03:00
mixin/regular-lxde : use /x 11/lxde use /im +nm -gtk
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
2021-11-16 17:18:23 +03:00
mixin/regular-mate : mixin /mate -base use /domain -client ; @:
i f n e q ( , $( filter -out riscv 64,$ ( ARCH ) ) )
2019-09-02 18:07:32 +03:00
@$( call add,THE_LISTS,$( call tags,base smartcard) )
2021-11-16 17:18:23 +03:00
e n d i f
2019-09-02 18:07:32 +03:00
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 \
2021-11-15 17:04:16 +03:00
use/rescue/.base use/syslinux/sdab.cfg use/grub/sdab_bios.cfg \
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/firmware/qlogic test/rescue/no-x11 +sysvinit; @:
2021-09-03 15:29:09 +03:00
mixin/regular-builder : use /dev /builder /base use /net /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)
2023-06-27 11:47:17 +03:00
@$( call add,THE_PACKAGES,apt-repo)
2019-03-21 08:55:20 +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
### 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 ; @:
