IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
led-ws kernel flavour has gained kernel-modules-vmware
recently, let's add this to the appropriate targets.
It's used in regular-jeos already but THE_ part was missing.
VMware specific bits went into use/install2/vmware target,
and all of those targets are worth their use/install2/vmguest
collective one instead of just sticking the kitchen sink into
use/install2/full immediately.
This one has been missing for quite some time (infiniband modules
should have triggered a commit like this back then), finally there
in very crude and draft form for the starters.
By the time these hooks run the font packages' %post scriptlets
should have fired already; no need to carry the utilities on.
Yes these are bit-by-bit savings. No it's too expensive still.
My gut feeling is that we're not going to see glib2's
messages a lot within installer environment anyways.
And there's a forgotten /usr/share/X11/locale/ too.
An installer needs video playback acceleration
when it has some content to show and some means to;
as long as these are not supported just drop this
unconditionally.
These are only needed for alterator-vm when making
LUKS encrypted partitions; ideally the extra libraries
would be omitted automatically when luks isn't included.
This package has replaced installer-feature-setup-network-stage3
without declaring that; it appears that installer-distro-altlinux-*
don't require it even if most of the others do.
This is to ensure it's included, at least at the moment.
led@ has different kernel-modules-* package set,
some of those "standard" names are provided but
vbox* is not the case.
As our macros and helpers will grok this just fine,
let's add both variants so what's present gets in.
sub/main subprofile should not be requested directly
as documented in its README but rather via use/repo/main;
let's fix this discrepancy and check that no regressions
come hurling down.
INSTALL2_PACKAGES turned out to be sensitive to the
feature addition order: if efi was added before install2
then the packages added by the former were overridden
by the latter.
This is also related to commit g7b76c73 as +installer
can be added pretty much anywhere, there's no warranty
that use/install2 appears early enough in configuration
build-up sequence.
This one is a part of a larger rewrite to move away from
distro-centric build-up to configuration-centric one with
the particular packaging being of secondary importance
compared to actual functionality.
EFI/UEFI is mostly about partitioning and bootloader setup,
at least from a distribution's point of view; so the
appropriate tools should be handy and firmware interface
module should not be exterminated from installer images
but get autoloaded instead.
Please note that while there exists 32-bit x86 EFI
we don't bother with it at the time being: it's relevant
to some irrelevant Xeon systems as well as for the older
Intel Macs (<2008) that are long out of fashion anyways.
That is, initially we deal with x86_64 EFI only.
Thanks Serg Markov for bringing my attention to this:
http://www.opennet.ru/openforum/vsluhforumID3/86552.html#61
While the official distros might skip some filesystems for
support reasons there's no reason for community distros to
do so either.
Let's try that with icewm.iso...
NB: installer has a misfeature of dropping jfs/reiserfs
support in runtime unless "expertmode" magic word
is on the kernel bootargs string (#27763, #17368).
That sub/stage2/install2 was somewhat clumsy actually as it looked
like a hierarchical thing while being a substitution thing:
generic stage2 would get put in place renamed as install2.
This could only get worse with hierarchical features which have
already been both requested and considered for quite a time,
and "stage2 at install2" reads much more naturally.
Why would anyone try to remove apt when it's needed
for package dependency tracking for the installation,
it only takes a less cursory look at the build.log
to figure out it didn't actually happen anyways...
An initial draft of it was done half a year ago but several tricky
thingies had kept the code from showing up as it was rather brittle
and incomplete.
This implementation involves quite a few changes all over the place
but finally works good enough for live and installer images.
Please pay attention to the versions of these packages:
- installer-feature-setup-plymouth (0.3.2-alt1+)
- branding-altlinux-sisyphus (20110706-alt2+ if used)
- plymouth (0.8.3-alt20.git20110406+)
See also:
- http://www.altlinux.org/Branding
- http://www.altlinux.org/Plymouth
Just like livecd-install, graphical installer KMS support
looks better as an optional part of install2 feature.
Of course it's optional only if the release manager is fine
with VESA drivers and not KMS-requiring intel/radeon/nouveau;
thanks led@ for a confirmation just in case.
This further refines the modular build by making
metadata being a clearly separated feature rather
than having to rely on runtime tests, and also by
moving the code which cares for kernel bits of base
installation (.base list) in a feature of its own.
There's more to it but let's get the ball rolling first.
Initial SPICE support has been added for kvm/libvirt installation
and boot-up using qxl and spice by default as proposed by shaba@.
VirtualBox part is shifted a level deeper correspondingly
but otherwise stays the same.
There's much reason for reuse instead of duplication
among the different stage2-based subprofiles.
In particular, the rather monolithic driver cleanup script
of the ancient is better done in several clear pieces with
the final depmod run.
Scripts dropping apt/rpm databases will dump pkglist first.
A script purging /boot/* will honour live-install if present.
Minor inno^Wfixups all over the map too.
As it happens, I've stumbled upon a successfully built image
with alterator-grub in BASE and lilo in install2's installer-steps.
Of course the installer bailed out after dealing with packages :-/
Thanks Leo-sp50 for pointing out the (hopefully) right direction.
So far the tagged scripts concept is too fragile,
and these were used unconditionally anyways.
features.in/Makefile is broken regarding copying
tagged scripts right now...
As too many things started duplicating between distros proper
and (e.g. corresponding) LiveCDs, it became apparent that a class
of entities which end up working for THE_USER (not a sysadmin,
and not a developer, just a Linux user) is in need.
So THE_KMODULES will power installed basesystem and live image,
while THE_PACKAGES, THE_LISTS and THE_GROUPS will participate
in building those.
The features might get copy-pasted (or even copied-and-pruned)
when initialized; there's an unneccessary duplication of the
function name in the line adding it to FEATURES list, thus
prone to being forgotten and causing some havoc later on.
It was wrong in the first place but tackling this with some
double-colon rules ran into terminality issues, and further
tortures were considered unneccessary.
The current solution isn't perfect (no completely transparent
function name registration upon corresponding target being called)
but at least it is an improvement...
