Вышел GNU Guix 1.0.0

Вот именно, что всё именно так и лучше не терять бдительности!

И говорят, что вы, регистранты, просто не способны услышать нашего каста. Что ж, тем хуже для вас сделали бы какой-нибудь тред про эти чисто функциональные функционально чистые пакетные менеджеры, чтобы глупые вопросы в одном месте задавать можно было. Может быть и пригодится.

Да, nix требовательный к пользователю с точки зрения знания ЯП.

Вот, теперь всё сошлось. Досадно, конечно, что цена именно такова.

Досадно, конечно, что цена именно такова.

Это если ты будешь заниматься разработкой или опакечиванием софта. Для арчевода чтоб установить систему конфиг читаем и понятен.

Так вот именно что буду! Пакетов в NixOS хоть и уже много, а всё равно недостаточно. И потом, рано или поздно обязательно попадётся такая программа,которой ещё нет ни в каких пакетах, а установить её хочется. И вот в такие моменты Arch показывает свою сильнейшую сторону, позволяя с лёгкостью выполнить такую, казалось бы, сложную задачу, как создание нового пакета. В NixOS же на такую лёгкость рассчитывать уже не придётся.

Пакеты на Nix писать гораздо легче, чем PKGBUILD или EBUILD. Для большей части пакетов достаточно просто зависимости указать и исходники скачать.

Пакеты на Nix писать гораздо легче, чем PKGBUILD или EBUILD. Для большей части пакетов достаточно просто зависимости указать и исходники скачать.

И чем это проще Gentoo, где ты точно также просто укажешь зависимости и адрес архива с исходниками?

Вот пример одного из моих ебилдов:

EAPI=6

inherit cmake-utils

DESCRIPTION="Tools for binary instrumentation, analysis, and modification"
HOMEPAGE="http://www.dyninst.org/dyninst"
SRC_URI="https://github.com/dyninst/dyninst/archive/v${PV}.tar.gz -> ${P}.tar.gz"

LICENSE="LGPL-2.1"
SLOT="0"
KEYWORDS="~amd64 ~x86"

NixOS не проще Gentoo в плане написания описания сборки, а скорее наоборот — ибо не все программы нормально работают без FHS, и их нужно патчить.

Да? А теперь напиши-ка ebuild на вот такое:

{ stdenv, fetchFromGitHub, rustPlatform, pkgconfig, udev }:
rustPlatform.buildRustPackage 
{
  pname = "kanshi-unstable";
  version = "2019-02-02";

  src = fetchFromGitHub {
    owner = "emersion";
    repo = "kanshi";
    rev = "970267e400c21a6bb51a1c80a0aadfd1e6660a7b";
    sha256 = "10lfdan86bmwazpma6ixnv46z9cnf879gxln8gx87v7a1x3ss0bh";
  };

  buildInputs = [ pkgconfig udev ];

  cargoSha256 = "sha256:0lf1zfmq9ypxk86ma0n4nczbklmjs631wdzfx4wd3cvhghyr8nkq";
}

Про патчинг полностью согласен, тут иногда бывает больно, но хорошо написанный софт пакетится просто с удовольствием.

EDIT: Да, оно написано, но ебилд в три раза длиннее моего пакетика :)

Да? А теперь напиши-ка ebuild на вот такое

И чем твой пример отличается? То, что это Rust? Так это вопрос не подхода, а наличия предопределенных классов для сборки.

В Gentoo поддержка как cargo, так и работы с коммитами/ветками/et cetera есть.

но хорошо написанный софт пакетится просто с удовольствием.

Точно также, как и в Gentoo.

Другое дело, что ПО, которое относится к FHS как к данности — это не плохо написанное ПО, ибо FHS как бы стандарт.

EDIT: Да, оно написано, но ебилд в три раза длиннее моего пакетика :)

Упомянуть про то, что это «длиннее в три раза» – список зависимостей, который перечислен с переводами строк, а также пустые поля – ты конечно не решился.

Потому что этот EBUILD был сгенерирован одной строчкой: cargo ebuild в директории с программой на Rust.

FHS как бы стандарт

Который давно нуждается как минимум в пересмотре, а то и вовсе в радикальном изменении. NixOS этот стандарт пересмотрел и изменил по своему, стало проще логичней.

Для пакетов, не способных жить без FHS есть специальная песочница.

Так вот именно что буду! Пакетов в NixOS хоть и уже много, а всё равно недостаточно.
В NixOS же на такую лёгкость рассчитывать уже не придётся.

Не беги впереди паровоза. Сначала попробуй установить NixOS в виртуалке, почитать мануал(вполне хороший) и посмотреть конфиги других.

Дело не в том, в чем cтандарт нуждается или нет.

Дело в том, что если это стандарт, то нельзя называть ПО, которое ему следует – плохо написанным.

Ты против NixOS или что?

Ты против NixOS или что?

Я пользователь NixOS, и я против фанбойства.

Соглашусь. С другой стороны, мне тоже кажется, что FHS пора на покой.

Хорошо, соглашусь, в nix тратится на 1 минуту клацанья по клавишам больше. Тем не менее, это все равно очень легко.

Крайне редко, иначе мы бы вместо snap, appimage, сторонних репозиториев и пр. видели бы четкие и стройные официальные репозитории.

От переезда на guixsd ситуация не улучшится. Мы так и будем скакать каждые 5 лет на «более лучший дистрибутив»? Как там кстати импортер пакетов из nixos поживает?

Более того, некоторые мейнтейнеры одновременно поддерживают описания сборки как для Guix, так и для Nix

Двойная работа

GuixSD не отрицает сборку системы из готовых примитивов.

Но и не форсирует её. Поэтому получается куча решений в стол, которые не становятся общим достоянием и в итоге переизобретаются пользователями, пока кто-нибудь не поленится это протолкнуть в дистрибутив. В таком случае гораздо интересней было бы видеть функциональную альтернативу вещам вроде lfs и buildroot

Неправильно ты, дядя Федор, бутерброд ешь.

Мне известен этот способ. Но в данном случае он мне ни к чему. Я итак всегда использую unstable, поскольку релиз достаточно быстро тухнет в целом

Полезные функции — это те, которые нужны человеку их использующих. Если апстрим решает что полезно мне, а что нет — мне нужна возможность без поддержания собственного форка описаний пакетов по-человечески использовать систему так, как я считаю это нужным.

Если именно как ты считаешь нужным, говорю же это должен быть конструктор типа buildroot. В противном случае ты рано или поздно будешь сталкиваться с общим мнением.

Другое дело, что хорошо бы иметь «one true unofficial non-free repo», и вполне может быть, что я попробую сотворить данное начинание.

Это похвально, потому что подключение 100500 оверлеев реально не лучшая идея. В идеале все яйца должны быть в одной корзине.

А свой конфиг NixOS можешь показать?

Могу тебе свой большой конфиг прислать в личку

Абсолютно верно. Я кстати именно поэтому и хочу успеха hnix – он позволит писать описания пакетов и их сборку на одном языке.

Это как??? Монадическую цепочку на Хаскеле делать вместо императивной лапши на баше? Не уверен, что это будет удобно. Та же крайность, что и переписывание всего на лиспе

Но как говорил один аноним, ты и в nix можешь правила сборки на любом языке варганить, просто в nixpkgs для удобства принят баш

А по NixOS ты их много видел? t184256 вот целенаправленно пытался устроиться, но только как-то ничего не вышло.

Постоянно вижу на околониксовых ресурсах. И что что не вышло? Там удаленка или релокация, само собой отличные коммуникативность и владение разговорным английским)

Это как??? Монадическую цепочку на Хаскеле делать вместо императивной лапши на баше? Не уверен, что это будет удобно. Та же крайность, что и переписывание всего на лиспе

Таки да, но монадическая цепочка на хаскелле очевидно позволяет писать сборщик на любом языке при желании.

Пакеты на Nix писать гораздо легче, чем PKGBUILD или EBUILD.

а как там с кросскомпиляцией? сижу под Gentoo/Win7/Hackintosh. порываюсь поставить NixOS или Guix, собрать midipix (это такой Cygwin уровня native NT kernel API, типа SUA под винду), собрать и опакетить. то есть, запилить аналог msys2, только не с арчбилдами, как в Msys2, а с nixpkgs или рецептами сборки на схемке.

под генту у меня был оверлей с ебилдами под mingw на локалхосте. кроссмингвом собирал в отдельный префикс, потом rsync-ом в винду копировал. оно даже нормально работало, палудис под винду что-то там собирал. а потом стало проще msys2 под винду установить готовый.

в msys2 вроде арчбилды для кроссмингва писать просто, своё самособранное опакетить просто. ну и сам msys2 из-под винды тоже вполне нормально работает.

под nixpkgs вроде нагуглил какие-то nixpkg для кроссборки мингвом. под Guile и Guix вроде ничего не нашлось.

в общем, хочется этот midipix собирать типа как оверлей с ебилдами, ну или msys2 с арчбилдами, из-под Nix/Guix в виртуалочке. а то пока все эти midipix руками приходится собирать из-под линукса (скриптом) и rsync-ом. а хотелось бы полноценно под винду портировать.

в общем, кто с кросскомпиляцией разбирался или свои «ебилды» на nixpkgs/guix писал, или свои оверлеи делал. есть какие-то хаутушки, или нужно сидеть вручную всё выпиливать и опакечивать.

хочется всё-таки опакетить этот midipix. вполне перспективная замена cygwin, на первый взгляд. и работает как подсистема NT ядра, как раньше SUA была, полноценно и правильно сделанная — musl допортировали на NT native kernel API, сделали на нём подсистему с форками, сигналами, и прочим позиксом. а не как msys2 + mingw с арчбилдами + msvcrt.dll неявным, в котором позикса нету, или cygwin1.dll где закат солнца вручную в рантайме, в dll вокруг CreateProcess.

в общем, как в NixOS/Guix свой оверлей сделать проще всего?

NixOS не проще Gentoo в плане написания описания сборки, а скорее наоборот — ибо не все программы нормально работают без FHS, и их нужно патчить.

аналога USE-флагов с 10500 конфигурациями одного пакета полноценного нет, нужно «ебилды» на nixpkg вручную править для того же эффекта?

Как там кстати импортер пакетов из nixos поживает?

тот же вопрос. физически он там есть. насколько хорошо оно работает?

и кстати, из своих отдельных пакетных менеджеров типа cargo, pip, gem оно в пакеты насколько хорошо конвертирует?

на лиспе писать или на хаскеле с монадическими цепочками

ну теоретически как раз для импортёра/конвертации рецептов сборки во что-то s-выражения удобны. а то с башем опять всё скатывается в арч с PKGBUILD-ами или brew на баше, а тут хоть какая-то декларативность.

аналога USE-флагов с 10500 конфигурациями одного пакета полноценного нет, нужно «ебилды» на nixpkg вручную править для того же эффекта?

Есть аналог USE-flags, только с ними теряется бинарный кэш вообще на всю систему.

pkgsCross.mingwW64 и вперед.

Не, я имел в виду такое: nixcrpkgs или такое: midipix-packages, рачевальня --- а можно сделать по LFS-ному:незамутнённое

только в качестве «оверлея» для NixOS (вроде уже есть, nixcrpkgs) или Guix (надо запилить)

midipix.org/news

кстати, кто ставил в VirtualBox NixOS/Guix?

как там расширения Virtual box guest additions for NixOS or Guix guestsустановить ?

стандартный шарболл

sh /mnt/cdrom/VBoxLinuxAdditions.run

root@guix /mnt/cdrom# sh ./VBoxLinuxAdditions.run 
Verifying archive integrity... All good.
Uncompressing VirtualBox 5.2.30 Guest Additions for Linux........
VirtualBox Guest Additions installer
Unable to determine correct library path.
root@guix /mnt/cdrom# 

потому что не находит /bin/rm ( делаем симлинк ) /usr/lib64 (а вот тут думать надо) и прочее для ldconfig.

подозреваю, что в NixOS тоже самое

его можно распаковать :

sh   /mnt/cdrom/VBoxLinuxAdditions.run  --tar -xtf -C ~/VBox-unpaked/

но там дальше тоже похожий затык.

в общем, кто расширения VirtualBox guest additions устанавливал в гостя NixOS/Guix, отпишитесь как это сделать по нормальному

только в качестве «оверлея» для NixOS (вроде уже есть, nixcrpkgs)

есть для mingw-64, нет для musl/midipix

Так вроде nixos как раз для того чтобы уйти от такого трэша.

virtualisation.virtualbox.guest.enable = true;

а то с башем опять всё скатывается в арч с PKGBUILD-ами или brew на баше, а тут хоть какая-то декларативность

Какая нахрен декларативность, если у тебя в любом случае билд инструкция получатся, хоть ты трижды монадами обложись. Все что можно было вынести в декларатив в nixos вынесли. Посмотри парочку примеров в nixpkgs

поставил не его, а Guix. а там как раз такой треш потому что не FHS. ну а в остальном вроде норм.

nixos и для vagrant есть. guixSD для vagrant вроде пока нет, но инсталлятор нормально работает. (если не считать что в дефолтно установленом после инсталлятора нет ls, coreutils, procpsutils и прочее, нужно руками доставлять, лол. прикольный дистрибутив).

в общем, как в NixOS/Guix свой оверлей сделать проще всего?

Как NUR репозиторий: https://github.com/nix-community/NUR

Оно и логично: если само ядро не очень работает, точно так же будет работать и дистрибутив на базе оного.

Не очень работает в том смысле, что 95% пакетов из репы не собираются. По крайней мере так было, когда я последний раз пытался собрать себе GNU/Guix/Hurd.