Difference between pages "Install/pt-br/Partitioning" and "FLOP:No-systemd system"

< Install(Difference between pages)
(Preparando o Disco Rígido)
 
 
Line 1: Line 1:
 +
{{FLOP
 +
|Created on=2015/02/09
 +
|Summary=How systemd sneaks in into Funtoo, and possible solutions for removing it.
 +
|Author=Mgorny,
 +
|Reference Bug=FL-2091
 +
}}
 +
== State inherited from Gentoo ==
 +
=== udev implementations ===
 +
Gentoo has three udev providers:
 +
* ''sys-apps/systemd'' provides udev as a part of standard systemd installation,
 +
* ''sys-fs/udev'' provides the systemd variant of udev decoupled from systemd, with some Gentoo patches,
 +
* ''sys-fs/eudev'' provides the Gentoo fork of udev from before it was coupled into systemd.
  
===Particionamento===
+
The existence of those providers is acknowledged by the following virtuals, see http://www.funtoo.org/Virtual_Packages :
 +
* ''virtual/udev'',
 +
* ''virtual/libudev'',
 +
* ''virtual/libgudev''.
  
=== Prepare o Disco Rígido ===
+
=== systemd support in packages ===
 +
Gentoo has separate methods of handling ''obtrusive'' and ''unobtrusive'' systemd support in packages.
  
==== Introdução ====
+
Obtrusive support is when systemd support:
 +
* collides with OpenRC support,
 +
* requires systemd being installed (e.g. linking to systemd libraries).
  
Em tempos remotos, só havia um jeito de inicializar (boot)o computador compatível com a arquitetura PC. Todos os nossos desktops e servidores tinham uma BIOS padrão, todos os nossos hard drives utilizavam Master Boot Records, e eram particionados utilizando esquema de partição MBR. E nós gostávamos disso daquele jeito mesmo!
+
Unobtrusive support is when the package can support both OpenRC and systemd simultaneously without issues. Examples of unobtrusive support is portable, conditional code (i.e. runtime detection of init) and installation of unit files that are not used when systemd is not used.
  
Então, depois veio os EFI e UEFI, que são firmware em novo-estilo projetados para inicializar sistemas, junto as tabelas de partição GPT para suportar discos superiores à 2.2TB. Tudo repentino, nós tínhamos uma variedade de opções para inicializar os sistemas Linux, tornando o que uma vez era um método único de encaixe de tudo  (one-method-fits-all) aproximar-se á algo muito mais complexo.
+
For obtrusive conditional support Gentoo uses USE=systemd flag. For unobtrusive support, Gentoo enables relevant features or installs relevant files unconditionally. This aimed to ease switching to systemd and back by reducing the number of rebuilds.  
  
Vamos parar por um momento para rever as opções de boot disponíveis para você. Esse pequeno Guia utiliza, e recomenda, o método da BIOS à moda antiga inicializando e usando um MBR. Funciona. Não há nada de errado com ele. Se seu disco é do tamanho de  2TB ou menor, ele não vai impedir que você use toda a capacidade do seu disco, também.
+
Currently, by default, when using and running OpenRC, unobtrusive scenario implemented by means even when USE=systemd disabled and systemd ebuild masked, ebuilds installing units, sockets, etc. We find this policy controversial to user's needs.
  
Mas, há alguns situações onde  o método da não é satisfatório. Se você obtiver um disco de tamando superior à 2TB, então partições MBR não o permitirão acessar todo o seu  armazenamento (storage). Então essa é uma rasão. Outra rasão é que há alguns então assim chamados  "PC" por aí afora que não suportam maias BIOS, e lhe força a utilizar o UEFI para inicializar. Então, sem compaixão pelas pessoas que se enquadram nessa situação, esse Guia de Instalação documenta boot pelo UEFI também.
+
== Current state in Funtoo ==
 +
=== Common changes ===
 +
Funtoo overrides all udev virtuals to support only eudev as udev provider. This also implicitly blocks installing systemd or udev.
  
Nossa recomandação ainda é ir pela moda antiga a não ser  que tenha resão para não. Chamamos esse método  de método '''BIOS + GRUB (MBR)'''. Esse é o método tradicional de configurar um PC para inicilizar o Linux.
+
However, sys-apps/systemd and sys-fs/udev are not masked, so attempt at installing either of them will result in hard-to-understand blockers. Furthermore, USE=systemd is not masked, so users can enable it and be confused by the resulting blockers.
  
Se você precisa usar UEFI para inicilizar, recomendamos não utillizar de maneira alguma o MBR para boot, já que alguns sistemas suportam as some UEFI, mas outros não. Ao inves disso, recomendamos utilizar o UEFI para inicializar o GRUB, que carregará o Linux. Referimos a esse método como o método '''UEFI + GRUB (GPT)'''.
+
A number of packages install systemd-related files (the ''unobtrusive support'' from Gentoo). This includes:
 +
* systemd units (services) in ''/usr/lib/systemd/system'' installed by multiple packages,
 +
* binfmt descriptions in ''/usr/lib/binfmt.d'' (''dev-dotnet/pe-format'', used by OpenRC as well),
 +
* modules loaded at boot in ''/usr/lib/modules-load.d'' (not yet observed, TODO: check if OpenRC uses it),
 +
* sysctl settings in ''/usr/lib/sysctl.d'' (not yet observed),
 +
* declarations of system users & groups in ''/usr/lib/sysusers.d'' (not yet observed outside systemd),
 +
* tmpfiles.d in ''/usr/lib/tmpfiles.d'' installed by multiple packages (used by OpenRC as well),
 +
* potentially other configuration files in ''/usr/lib/systemd'' (''sys-power/upower''),
 +
* potentially any other executable in ''/usr/lib/systemd'' (unsupported ''sys-fs/udev''), sometimes used outside systemd as well.
  
E sim, há ainda mais, alguns aos quais estão documentados na página [[Boot Methods]]. Nós costumavamos recomendar um étodo '''BIOS + GRUB (GPT)''', mas esse não tem consistentemente suporte em uma variedade de hardware.
+
=== no-systemd mix-in ===
 
+
The no-systemd mix-in additionally:
'''A grande pergunta é -- que método de boot eu devo usar?''' Aqui está como responder.
+
* masks sys-fs/udev and sys-apps/systemd,
 
+
* adds INSTALL_MASK to remove systemd files in ''/usr/lib/systemd'' (and the incorrect ''/lib/systemd'' directory).
;Princípio nº 1 - Moda antiga (Old School): Se você pode inicializar com confiavelmente o System Rescue CD e ele exibe um menu inicial azul claro, você está inializando o CD usando a BIOS, e provavelmente você pode assim inicilizar o Funtoo Linux ussando a BIOS. Então, vá pela moda antiga e use a boot da BIO, ''a não ser que'' você tenha alguma resão para usar UEFI, tal qual ter um disco do tamando superior a 2.2TB. Nesse caso, veja o segundo Princípio nº 2, já que seu sistema pode ter suporte também à  boot UEFI.
+
 
+
;Princípio nº 2 - Moderno (New School): Se você pode confiavelmente inicilizar o System Rescue CD e ele te exibe um menu inicial preto e branco -- parabens, seu sistema é configurado para suportar o boot via UEFI. Isso significa que você está pronto para instalar o install Funtoo Linux para inicializá-lo via UEFI. Seu sistema pode ainda ter suporte para inicilizar com a BIOS, mas  somente se for testado pela UEFI primeiro. Você pode dar uma bisbilhotada na sua configuração de boot pelo BIOS e brincar com isso.
+
 
+
;Qual pe a Grande Diferença entra a Moda Antiga e a Moderna?: Aqui está a coisa. Se você for com as as partições MBR a moda antiga, sua partição <code>/boot</code> será um sistema de arquivos ext2, e você utilizará <code>fdisk</code> para criar suas partições MBR. Se você com as partições GPT e boot via UEFI, sua partição <code>/boot</code> será um sistema de arquivos vfat, por que isso é o que o UEFI é capaz de ler, e você utilizará <code>gdisk</code> para criar suas partiçẽos GP. E você instalará o GRUB um pouco diferente. É a respeito disso que tudo vem abaixo, em caso você estivesse curioso/a.
+
 
+
{{Note|'''Algumas placas mãe pode aparentar suporte a UEFI, mas não suportam.''' Faça sua pesquisa. Por exemplo, O BIOS atribuído na minha Gigabyte GA-990FXA-UD7 rev 1.1 tem uma opção de abilitar o boot UEFI por CD/DVD. '''Isso não é o sufuciente para abilitar boot via UEFI pelo hard drives e instalar o Funtoo Linux.''' UEFI deve ter tanto para mídia removível (assim você pode inicializar o System Rescue CD utilizando o UEFI) quanto mídias fixas (assim você pode inicializar sua nova instalação do Funtoo Linux.) Revelá-se que revisões posteriores dessa placa (rev 3.0) tem um novo BIOS que suporta completamente o boot do UEFI.  Isso pode apontar para o terceiro princípio -- conheça teu hardware.}}
+
 
+
==== O método a moda antiga (BIOS/MBR) ====
+
 
+
{{Note|Use esse método se você estiver inicializando sua BIOS, e se o o menu boot inicial do seu System Rescue CD initial estiver em azul claro. Se você for utilizar o método moderno, [[#New-School (UEFI/GPT) Method|click aqui para saltar para o UEFI/GPT.]]}}
+
 
+
===== Preparo =====
+
 
+
Primeiro, é uma boa idea certificar-se de que encontrou o hard disk correto para particioná-lo. Tente esse comando e verifique que  <code>/dev/sda</code> é o disco que você quer particionar:
+
 
+
<console>
+
# ##i##fdisk -l /dev/sda
+
 
+
Disk /dev/sda: 640.1 GB, 640135028736 bytes, 1250263728 sectors
+
Units = sectors of 1 * 512 = 512 bytes
+
Sector size (logical/physical): 512 bytes / 512 bytes
+
I/O size (minimum/optimal): 512 bytes / 512 bytes
+
Disk label type: gpt
+
 
+
 
+
#        Start          End    Size  Type            Name
+
1        2048  1250263694  596.2G  Linux filesyste Linux filesystem
+
</console>
+
 
+
Agora, é recomendado que você apague quaisquer tabelas de partição MBR ou GPT existente no disco, que poderiam confundir o BIOS do sistema no momento da inicialização. Fazemos isso utilizando <code>sgdisk</code>:
+
{{fancywarning|Isso tornará quaisquer partições existentes inacessiveis! É formente lhe aconcelhado advetido realizar backup de qualquer dado crítico antes de prosseguir.}}
+
 
+
<console>
+
# ##i##sgdisk --zap-all /dev/sda
+
 
+
Creating new GPT entries.
+
GPT data structures destroyed! You may now partition the disk using fdisk or
+
other utilities.
+
</console>
+
 
+
Essa saída també não é nada para se preocupar, desde que o comando ainda  foi bem sucedido:
+
 
+
<console>
+
***************************************************************
+
Found invalid GPT and valid MBR; converting MBR to GPT format
+
in memory.
+
***************************************************************
+
</console>
+
 
+
===== Particionamento =====
+
 
+
Agora usaremos <code>fdisk</code> para criar a tabela de partição MBR e as partições:
+
 
+
<console>
+
# ##i##fdisk /dev/sda
+
</console>
+
 
+
Dentro do <code>fdisk</code>, siga esses passos:
+
 
+
'''Esvazie a tabela de partição''':
+
 
+
<console>
+
Command (m for help): ##i##o ↵
+
</console>
+
 
+
'''Crie a primeira Partição''' (boot):
+
 
+
<console>
+
Command (m for help): ##i##n ↵
+
Partition type (default p): ##i##↵
+
Partition number (1-4, default 1): ##i##↵
+
First sector: ##i##↵
+
Last sector: ##i##+128M ↵
+
</console>
+
 
+
'''Crie a segunda Partição''' (swap):
+
 
+
<console>
+
Command (m for help): ##i##n ↵
+
Partition type (default p): ##i##↵
+
Partition number (2-4, default 2): ##i##↵
+
First sector: ##i##↵
+
Last sector: ##i##+2G ↵
+
Command (m for help): ##i##t ↵
+
Partition number (1,2, default 2): ##i## ↵
+
Hex code (type L to list all codes): ##i##82 ↵
+
</console>
+
 
+
'''Crie a partição root:'''
+
 
+
<console>
+
Command (m for help): ##i##n ↵
+
Partition type (default p): ##i##↵
+
Partition number (3,4, default 3): ##i##↵
+
First sector: ##i##↵
+
Last sector: ##i##↵
+
</console>
+
 
+
'''Verifique a tabela de partição:'''
+
 
+
<console>
+
Command (m for help): ##i##p
+
 
+
Disk /dev/sda: 298.1 GiB, 320072933376 bytes, 625142448 sectors
+
Units: sectors of 1 * 512 = 512 bytes
+
Sector size (logical/physical): 512 bytes / 512 bytes
+
I/O size (minimum/optimal): 512 bytes / 512 bytes
+
Disklabel type: dos
+
Disk identifier: 0x82abc9a6
+
 
+
Device    Boot    Start      End    Blocks  Id System
+
/dev/sda1          2048    264191    131072  83 Linux
+
/dev/sda2        264192  4458495  2097152  82 Linux swap / Solaris
+
/dev/sda3        4458496 625142447 310341976  83 Linux
+
</console>
+
 
+
'''Grave a tabela de partição no disco:'''
+
 
+
<console>
+
Command (m for help): ##i##w
+
</console>
+
 
+
Sua nova tabela de partição MBR será agora gravada no seu disco.
+
 
+
{{Note|Você finalizou o particionamento! Agora, pule para [[#Creating filesystems|Crie os filesystems]].}}
+
 
+
==== Método Moderno (UEFI/GPT)  ====
+
 
+
{{Note|Use esse método se você estiver inicializando usando o UEFI, e se o menu de boot do seu System Rescue CD initial boot for preto e branco. Se for azul claro, esse método não funcionará.}}
+
 
+
Utilize o comando <tt>gdisk</tt> para criar uma tabela de partição GPT como a seguir. Adapte tamanhos conforme necessário, embora esse padrões funcionarão para a maioria dos  suários. Inicie o <code>gdisk</code>:
+
 
+
<console>
+
# ##i##gdisk
+
</console>
+
 
+
Dentro do <tt>gdisk</tt>, Siga esses passos:
+
 
+
'''Crie uma uma nova tabela de partição vazia''' (Isso ''apagará'' todos os dados no seu disco quando salvo):
+
 
+
<console>
+
Command: ##i##o ↵
+
This option deletes all partitions and creates a new protective MBR.
+
Proceed? (Y/N): ##i##y ↵
+
</console>
+
 
+
'''Crie a 1ª Partiçaõ''' (boot):
+
 
+
<console>
+
Command: ##i##n ↵
+
Partition Number: ##i##1 ↵
+
First sector: ##i##↵
+
Last sector: ##i##+500M ↵
+
Hex Code: ##i##↵
+
</console>
+
 
+
'''Crie a 2ª Partição''' (swap):
+
 
+
<console>
+
Command: ##i##n ↵
+
Partition Number: ##i##2 ↵
+
First sector: ##i##↵
+
Last sector: ##i##+4G ↵
+
Hex Code: ##i##8200 ↵
+
</console>
+
 
+
'''Create 3ª Partição''' (root):
+
 
+
<console>
+
Command: ##i##n ↵
+
Partition Number: ##i##3 ↵
+
First sector: ##i##↵
+
Last sector: ##i##↵##!i## (for rest of disk)
+
Hex Code: ##i##↵
+
</console>
+
 
+
Ao longo do caminho, você pode digitar "<tt>p</tt>" e apertar Enter para visualizar a tabela de partição atual. Se você cometar algum engano, você pode digitar "<tt>d</tt>" tuma partição existente que você criou. Quando estiver satisfeito com sua definição de partição, digite "<tt>w</tt>" para gravar sua configuração no disco:
+
 
+
'''Gravar a Tabela de Partição no Disco''':
+
 
+
<console>
+
Command: ##i##w ↵
+
Do you want to proceed? (Y/N): ##i##Y ↵
+
</console>
+
 
+
A tabela de partição será agora gravada em disco e o <tt>gdisk</tt> será fechado.
+
 
+
Agora, suas partições GPT/GUID foram criadas, e será exibido os seguintes ''dispositivos de bloco''  (''block devices'') no Linux:
+
 
+
* <tt>/dev/sda1</tt>, which will be used to hold the <tt>/boot</tt> filesystem,
+
* <tt>/dev/sda2</tt>, which will be used for swap space, and
+
* <tt>/dev/sda3</tt>, which will hold your root filesystem.
+
 
+
==== Creating filesystems ====
+
 
+
{{Note|This section covers both BIOS ''and'' UEFI installs. Don't skip it!}}
+
 
+
Before your newly-created partitions can be used, the block devices need to be initialized with filesystem ''metadata''. This process is known as ''creating a filesystem'' on the block devices. After filesystems are created on the block devices, they can be mounted and used to store files.
+
 
+
Let's keep this simple. Are you using old-school MBR partitions? If so, let's create an ext2 filesystem on /dev/sda1:
+
 
+
<console>
+
# ##i##mkfs.ext2 /dev/sda1
+
</console>
+
 
+
If you're using new-school GPT partitions for UEFI, you'll want to create a vfat filesystem on /dev/sda1, because this is what UEFI is able to read:
+
 
+
<console>
+
# ##i##mkfs.vfat -F 32 /dev/sda1
+
</console>
+
 
+
Now, let's create a swap partition. This partition will be used as disk-based virtual memory for your Funtoo Linux system.
+
 
+
You will not create a filesystem on your swap partition, since it is not used to store files. But it is necessary to initialize it using the <code>mkswap</code> command. Then we'll run the <code>swapon</code> command to make your newly-initialized swap space immediately active within the live CD environment, in case it is needed during the rest of the install process:
+
 
+
<console>
+
# ##i##mkswap /dev/sda2
+
# ##i##swapon /dev/sda2
+
</console>
+
 
+
Now, we need to create a root filesystem. This is where Funtoo Linux will live. We generally recommend ext4 or XFS root filesystems. If you're not sure, choose ext4. Here's how to create a root ext4 filesystem:
+
 
+
<console>
+
# ##i##mkfs.ext4 /dev/sda3
+
</console>
+
 
+
...and here's how to create an XFS root filesystem, if you choose to use XFS:
+
 
+
<console>
+
# ##i##mkfs.xfs /dev/sda3
+
</console>
+
 
+
Your filesystems (and swap) have all now been initialized, so that that can be mounted (attached to your existing directory heirarchy) and used to store files. We are ready to begin installing Funtoo Linux on these brand-new filesystems.
+
 
+
{{fancywarning|1=
+
When deploying an OpenVZ host, please use ext4 exclusively. The Parallels development team tests extensively with ext4, and modern versions of <code>openvz-rhel6-stable</code> are '''not''' compatible with XFS, and you may experience kernel bugs.
+
}}
+
  
==== Montando os filesystems ====
+
After enabling the mix-in, new packages no longer install directly systemd-related files. However, files from existing packages are kept until all the packages that were installing them are rebuilt. The {{Package|app-portage/install-mask}} script can be used to find packages needing rebuild. Alternatively, the user can remove those directories manually.
  
Monte os recem-criados filesystems como a seguir, criando <code>/mnt/funtoo</code> como ponto de montagem da instalação:
+
It should be noted that removing ''/usr/lib/systemd'' may be unsafe. While this particular example is irrelevant to Funtoo, sys-fs/udev installs its udev daemon there and the daemon is used by OpenRC as well. Therefore removing the directory results in defunct udev. Other packages may follow a similar logic of installing system daemons in ''/usr/lib/systemd'' while the daemons can be used on OpenRC systems.
  
<console>
+
== Possible changes for Funtoo ==
# ##i##mkdir /mnt/funtoo
+
=== Consistent no-systemd setup by default ===
# ##i##mount /dev/sda3 /mnt/funtoo
+
Since Funtoo does not support systemd, the explicit no-systemd mix-in seems redundant. Instead, the base profile could specifically:
# ##i##mkdir /mnt/funtoo/boot
+
# mask alternative udev providers,
# ##i##mount /dev/sda1 /mnt/funtoo/boot
+
# mask USE=systemd and other flags requiring systemd,
</console>
+
# disable installing systemd files in safe way.
  
Optionally, if you have a separate filesystem for <code>/home</code> or anything else:
+
=== systemd units controlled via USE flags ===
 +
It has been suggested that the ebuilds installing systemd-related files can gain USE=systemd even for non-obtrusive uses. To avoid forking numerous ebuilds, this could be done via modifying ''systemd.eclass''. However, the eclass isn't suited for conditional install (and so aren't some build systems) and focuses on providing the install paths.
  
<console>
+
Instead, the eclass could be modified to return a well-known discard directory — and the directory would be either added to INSTALL_MASK, or stripped directly in Portage. However, I don't see any clear advantage over using standard install locations and stripping them via INSTALL_MASK.
# ##i##mkdir /mnt/funtoo/home
+
# ##i##mount /dev/sda4 /mnt/funtoo/home
+
</console>
+
  
If you have <code>/tmp</code> or <code>/var/tmp</code> on a separate filesystem, be sure to change the permissions of the mount point to be globally-writeable after mounting, as follows:
+
=== Improved INSTALL_MASK handling ===
 +
A semi-related potential improvement is to port the features provided by {{Package|app-portage/install-mask}} directly into Portage. This would specifically involve:
 +
# support for named sets of directories (alike USE flags), e.g. instead of ''/usr/lib/systemd/system /usr/lib/systemd/user …'', you'd use ''@systemd'',
 +
# options to cause rebuilds/binpkg reinstalls when the files effectively installed by package would change (due to change in INSTALL_MASK),
 +
# ''emaint'' function to directly remove files in directories added to INSTALL_MASK.
  
<console>
+
{{FLOPFooter}}
# ##i##chmod 1777 /mnt/funtoo/tmp
+
</console>
+

Latest revision as of 09:00, February 10, 2015

Created on
2015/02/09
Original Author(s)
Michał Górny
Status
Reference Bug
FL-2091

Funtoo Linux Optimization Proposal: No-systemd system

How systemd sneaks in into Funtoo, and possible solutions for removing it.

State inherited from Gentoo

udev implementations

Gentoo has three udev providers:

  • sys-apps/systemd provides udev as a part of standard systemd installation,
  • sys-fs/udev provides the systemd variant of udev decoupled from systemd, with some Gentoo patches,
  • sys-fs/eudev provides the Gentoo fork of udev from before it was coupled into systemd.

The existence of those providers is acknowledged by the following virtuals, see http://www.funtoo.org/Virtual_Packages :

  • virtual/udev,
  • virtual/libudev,
  • virtual/libgudev.

systemd support in packages

Gentoo has separate methods of handling obtrusive and unobtrusive systemd support in packages.

Obtrusive support is when systemd support:

  • collides with OpenRC support,
  • requires systemd being installed (e.g. linking to systemd libraries).

Unobtrusive support is when the package can support both OpenRC and systemd simultaneously without issues. Examples of unobtrusive support is portable, conditional code (i.e. runtime detection of init) and installation of unit files that are not used when systemd is not used.

For obtrusive conditional support Gentoo uses USE=systemd flag. For unobtrusive support, Gentoo enables relevant features or installs relevant files unconditionally. This aimed to ease switching to systemd and back by reducing the number of rebuilds.

Currently, by default, when using and running OpenRC, unobtrusive scenario implemented by means even when USE=systemd disabled and systemd ebuild masked, ebuilds installing units, sockets, etc. We find this policy controversial to user's needs.

Current state in Funtoo

Common changes

Funtoo overrides all udev virtuals to support only eudev as udev provider. This also implicitly blocks installing systemd or udev.

However, sys-apps/systemd and sys-fs/udev are not masked, so attempt at installing either of them will result in hard-to-understand blockers. Furthermore, USE=systemd is not masked, so users can enable it and be confused by the resulting blockers.

A number of packages install systemd-related files (the unobtrusive support from Gentoo). This includes:

  • systemd units (services) in /usr/lib/systemd/system installed by multiple packages,
  • binfmt descriptions in /usr/lib/binfmt.d (dev-dotnet/pe-format, used by OpenRC as well),
  • modules loaded at boot in /usr/lib/modules-load.d (not yet observed, TODO: check if OpenRC uses it),
  • sysctl settings in /usr/lib/sysctl.d (not yet observed),
  • declarations of system users & groups in /usr/lib/sysusers.d (not yet observed outside systemd),
  • tmpfiles.d in /usr/lib/tmpfiles.d installed by multiple packages (used by OpenRC as well),
  • potentially other configuration files in /usr/lib/systemd (sys-power/upower),
  • potentially any other executable in /usr/lib/systemd (unsupported sys-fs/udev), sometimes used outside systemd as well.

no-systemd mix-in

The no-systemd mix-in additionally:

  • masks sys-fs/udev and sys-apps/systemd,
  • adds INSTALL_MASK to remove systemd files in /usr/lib/systemd (and the incorrect /lib/systemd directory).

After enabling the mix-in, new packages no longer install directly systemd-related files. However, files from existing packages are kept until all the packages that were installing them are rebuilt. The app-portage/install-mask (package not on wiki - please add) script can be used to find packages needing rebuild. Alternatively, the user can remove those directories manually.

It should be noted that removing /usr/lib/systemd may be unsafe. While this particular example is irrelevant to Funtoo, sys-fs/udev installs its udev daemon there and the daemon is used by OpenRC as well. Therefore removing the directory results in defunct udev. Other packages may follow a similar logic of installing system daemons in /usr/lib/systemd while the daemons can be used on OpenRC systems.

Possible changes for Funtoo

Consistent no-systemd setup by default

Since Funtoo does not support systemd, the explicit no-systemd mix-in seems redundant. Instead, the base profile could specifically:

  1. mask alternative udev providers,
  2. mask USE=systemd and other flags requiring systemd,
  3. disable installing systemd files in safe way.

systemd units controlled via USE flags

It has been suggested that the ebuilds installing systemd-related files can gain USE=systemd even for non-obtrusive uses. To avoid forking numerous ebuilds, this could be done via modifying systemd.eclass. However, the eclass isn't suited for conditional install (and so aren't some build systems) and focuses on providing the install paths.

Instead, the eclass could be modified to return a well-known discard directory — and the directory would be either added to INSTALL_MASK, or stripped directly in Portage. However, I don't see any clear advantage over using standard install locations and stripping them via INSTALL_MASK.

Improved INSTALL_MASK handling

A semi-related potential improvement is to port the features provided by app-portage/install-mask (package not on wiki - please add) directly into Portage. This would specifically involve:

  1. support for named sets of directories (alike USE flags), e.g. instead of /usr/lib/systemd/system /usr/lib/systemd/user …, you'd use @systemd,
  2. options to cause rebuilds/binpkg reinstalls when the files effectively installed by package would change (due to change in INSTALL_MASK),
  3. emaint function to directly remove files in directories added to INSTALL_MASK.


blog comments powered by Disqus