On 28.10.2011 09:53, Juergen Daubert wrote:
On Wed, Oct 26, 2011 at 03:17:01PM +0200, Michal Soltys wrote:
[...]
Btw, shouldn't we try to add application specific stuff
like the one for lvm and mdadm via the corresponding
port, a kind of run-control directory with short scripts
added by the packages comes to my mind?
I'd rather left that to users. More complex configurations can vary
quite a lot, their parts can be stuffed in different places -
depending on one's needs. Existing hooks are just an
example/headstart.
Hmm, sorry, but my point was a different one. The only, or at
least biggest, problem I see with our current rc stuff is the
missing feature to extend/modify it via our packages.
And that's nothing we can left over to the user, but the
packager of the concerned port has to do.
[1] is a good example for such an extension, my idea for a
nice solution would be to add code to the init system via the
mdadm package and not to hardcode it to rc.
Maybe something similar what you can do with udev rules or with
cron by adding stuff to the /ect/cron.d directory.
I see the point, though might be hard to keep it flexible.
Btw - about mdadm - see at the bottom.
[...]
I started updating pkgmk as well, I can't live without native git
support, and few lesser things (such as local directories) ... for a
start ;)
I don't see why we need native git support in pkgmk.
I'd suggest to go the usual way and discuss the problems and
ideas first here and start coding after a common decision, not
the other way around ;)
Well, I need it to simplify my life, so not like it will go to waste,
but to make a point (motivation and so on) *FYI*:
Quite a few repos (not only git ones) provide stable branch, or often if
not, then de-facto master (regardless of the actual name) branch is what
is interesting - as its more current and stable than tarballs (sometimes
very outdated, or treated as 2nd rate citizens so to speak).
Few examples:
bridge utils - not so long ago - 1.5+fixes in repo, 1.4 stalled tarball
for over a year (if not more, don't remember exactly)
util-linux - nice stable/v2.20 ref
amule - official tarball is [almost always] terribly outdated
procps-fork - no tarballs at all, but very nice deb+fed+suse fork (and
there're literally many tens of patches for procps ...)
Or when kernel.org went out of business, git repos quickly moved out to
other sites (github, etc.) often without bothering much about release
tarballs or other such mundane things.
and so on ...
I'm adding feature that (+/-, still in progress, but shaping out nicely):
- never stores more on the disk than comparable tarball (no history, no
tags, no other junk - carefully crafted 1 parentless commit); that also
includes recursively all submodules; ITOW a bit of git plumbing (not a
lazy wrapper around git clone)
- the version is updated only after "download" (if it didn't exist yet),
or only forced at user's request - won't go ahead of maintainer's point
in time though
- the version is yyyy.mm.dd, automatically generated from original ref's
timestamp
- any remotely defined ref can be used
- the particular point in time is kept
- the md5sum is recursive ls-tree of particular ref
So basically it should be fully compatible with all existing utils.
Quick example:
name=util-linux
version=none
source=(git:...
git-ref=( [util-linux.git]="stable/v2.20" )
Then we do usual pkgmk stuff, and the above gets updated to:
name=util-linux
version=2011.12.13
source=(git:...
git-ref=( [util-linux.git]="stable/v2.20" )
git-head=( [util-linux.git]=<sha1> )
And that's all. It can be pushed to the repo. When compiled on user's
machine, it will never update the version itself or move ahead of
maintainer's actual ref (unless forced). Anytime the maintainer decides
to update the port (e.g. due to some new commits), it's a matter of
forcing version update and repushing.
Don't get me wrong, every help for CRUX is much appreciated,
but with our very limited resources we should use them in the
most effective and prioritized way, IMHO.
Well, I needed certain stuff which certainly can be useful for a few
folks, so why keep it hidden (be it scripts, or pkgmk, or maybe a few
other things - though c++ is not my thing, or itow my opinion is
somewhat similar to Linus's one ;) (this is not a flamebait, just fyi)).
Maybe add regular crux@ to CC as well ?
Why? I think crux-devel is the appropriate place for such
discussions.
It certainly is, but I thought about crux users generally being more
technically aware ones than those using other distros (so possibility
for some good comments/remarks/ideas, and it's not like the userbase is
too big). Well, they should be following devel in such case, but you see
the point about CC.
[1] http://crux.nu/bugs/index.php?do=details&task_id=747
Regarding this:
- initialization for v3.2 is udev only + mdadm.conf's [few new] knobs
(unless 64-md rules are reedited or not included, though this is not
stellar idea, considering e.g. hot-remove rules); --assembly --scan is
even potentially dangerous without --no-degraded (though that depends on
user's expectations)
- mdmon must not be killed; this one is autostarted (excluding certain
corner cases, see below) but careless kill can end with a nasty surprise
(D state), or e.g. a resync after reboot (if say reshape on container
was in progress, and mdmon was killed a bit too early). Well - all
external metadata updates are done by mdmon, so it's a tiny pandora box
when it suddenly dies. That's main motivation behind IMMORTALS=(<stuff>)
in rc-ng (also: lvm doesn't need ignore-udev knobs, because udevd is
also immortal)
There're some corner cases scheduled for fix at some point too, see
http://www.spinics.net/lists/raid/msg35492.html
Btw, in context of lvm - --mknodes is invalid for udev based lvm (stuff
will mostly keep working, but scripts will get out of the way on
mismatch, so no more /dev/disk/by* symlinks or other udev goodies). It's
fixed in rc-ng version.
_______________________________________________
crux-devel mailing list
crux-devel@lists.crux.nu
http://lists.crux.nu/mailman/listinfo/crux-devel
