I think this might be one reason that /etc/mtab was deprecated in favor of a symlink to /proc/mounts :P On Thu, Feb 18, 2016 at 9:07 PM, Duncan <1i5t5.dun...@cox.net> wrote: > Rich Freeman posted on Thu, 18 Feb 2016 07:22:36 -0500 as excerpted: > > > 4. In the runlevel paradigm you usually think of services running > > inside a runlevel (perhaps this isn't strictly true, but most people > > think this way, in part because runlevels don't change much). In > > systemd this really isn't the case. Services run before targets, or > > after them. A target won't be considered running if anything it depends > > on isn't running. > > Some minor additional notes, with the first one being here. > > Systemd target units are analogous to edge-triggered interrupts, which > they resemble in that they are simply "synchronization points" (the term > used in the systemd.target (5) manpage itself). Level-triggered > interrupts can be held on or held off (high or low), but edge-triggered a > re simply events that occur and then are passed as time moves on. As > such, targets can be started, but not normally (while the job queue is > idle) stopped, as they de-assert as soon as they are actually reached, > tho many of their requirements generally continue to run until stopped by > some other event, often conflicts= against some other target or general > unit being started, or specific admin systemctl stop. > > Tho the systemd FAQ suggests this wasn't always so, as it suggests using > systemctl list-units --type=target in answer to a question about how to > find what "runlevel" you're in. That command seems to return nothing, > here, tho, at least while no target is actively starting, so it would > seem that answer's a bit dated. > > It can be noted, however, that certain units, most often specific targets > intended to be specifically invokable by users, can be "isolated", as > they have the AllowIsolate unit setting. Systemctl isolate will > then cause it to be started exclusively, stopping anything that's not a > dependency of that unit. The systemctl emergency, rescue, reboot, > shutdown, etc, commands, then become effectively shortcuts to the longer > systemctl isolate command form. > > > 5. I'd have to check, but I wouldn't be surprised if systemd doesn't > > actually require specifying a target at all. Your default "runlevel" > > could be apache2.service, which means the system would boot and launch > > everything necessary to get apache working, and it probably wouldn't > > even spawn a getty. This is NOT analogous to just putting only apache2 > > in /etc/runlevels/default, because in that example openrc is running the > > default runlevel, and it only pulls in apache2. Systemd is purely > > dependency driven and when you tell it to make graphical.target the > > default runlevel it is like running emerge kde-meta. If all you wanted > > was kde-runtime you wouldn't redefine kde-meta to pull in only > > kde-runtime, you'd just run emerge kde-runtime. Again, I haven't tested > > this, but I'd be shocked if it didn't work. Of course, specifying a > > service as a default instead of a target is very limiting, but it would > > probably work. Heck, you could probably specify a mount as the default > > and the system would just boot and mount something and sit there. Or > > you could make it a socket and all it would do is sit and listen for a > > connection inetd-style. > > As mentioned both in the systemd FAQ and in the systemd.special (7) > manpage, under default.target, this is the default unit started at > bootup. Normally, it'll be a symlink to either multi-user.target > (analogous to sysvinit semi-standard runlevel 3, CLI, no X), or > graphical.target (analogous to sysvinit semi-standard runlevel 5, > launching X and and a graphical *DM login). > > I don't see specific documentation of whether symlinking to a non-target > unit is allowed, but systemd does have a commandline option --unit=, > which is explicitly documented to take a _unit_, default.target being the > default, but other non-target units being possible as well. Presumably > systemd would examine said unit, looking for DefaultDependencies=no, and > if not specifically set, would start the early "system level" targets, > before starting the named unit in place of the normal default.target. > > So it's definitely possible to do via systemd commandline, but I'm not > sure if default.target is followed if it doesn't symlink a target unit, > or not. I'd guess yes, but have neither seen it specifically documented > nor tested it myself, nor read of anyone else actually testing it. > > > > > I find it more helpful to think of targets as just units that don't do > > anything. We don't use them in openrc but I suspect it would work out > > of the box, and maybe we should even consider doing it in at least some > > cases. For example, right now /etc/init.d/samba uses some scripting to > > launch both nmbd/smbd and fancy config file parsing
On Thu, Feb 25, 2016 at 1:12 AM, Martin Vaeth
wrote: > Luis Ressel wrote: > > > > That would require a local git clone. And that's exactly what those who > > still want Changelogs are trying to avoid. > > You need even a deep git clone with full history. > > Already now this means that you need 2 (or already 3?) times the > disk space as for an rysnc mirror; multiply all numbers by 4 > if you used squashfs to store the tree. > > In the course of the years the factor will continue to increase; > I guess at least by 1 for every year (there is possibility of some > compression of history, but OTOH, many packages are added and > removed, eclasses keep changing, etc.) > > So in 2-3 years, it can be for some users 20 times the disk storage > than what it needs now. > Or, in 2-3 years, maybe people will stop with the hyperbole. Hopefully sooner. The tree is a bunch of text files, of which a whole lot of text is repeated (esomewrapper, eclass-based builds which are identical but for a single line, version updates to packages that make no changes at all to the ebuild, etc.) which is great for compression, which git does.
On 25/02/16 08:59, Kent Fredric wrote: > On 25 February 2016 at 21:02, Consus
wrote: >> Well, we do have one >> >> https://gitweb.gentoo.org/repo/gentoo.git/log/dev-lang/perl >> >> I bet folks want to check out what's new in their local copy of >> Portage tree. > > > With a custom, portage oriented, on-demand log generator you could > produce a lot more detail ( and in a text format that doesn't > require a web browser to view ) , and potentially use > understanding of portage conventions to generate change data > outside those explicitly stated. > > Though that would be a "later feature" you could potentially bolt > on after the main logic was sorted out. > > The idea being you could request a changelog for a package with a > list of "interest aspects" and have the log reduced to changes > that affect those interests. > > For instance, you could do : > > curl http://thing.gentoo.org/changes/dev-lang/perl?arch=~x86 > > And with a bit of effort, you could generate a changelog that is > only relevant for somebody who is on ~x86, eliding changes that > x86 didn't get yet. > > For instance, an ~x86 filter would elide stabilizations for ~x86, > because you don't care about stabilizations if you're assuming > ~arch. ( And it would elide changes that were only visible for > other arches ) > > And this filter wouldn't necessarily be implemented in "grep for > keywords in the commit message", but *analyse the change in the > directory* based, which would give the ability to do things that > would otherwise only be possible with a git clone. > > > This idea is quite neat - you could do either some basic User-Agent check and either render a web page for viewing online for changes, or even have a specifier that gave you some other output options .. eg. ChangeLog (rev. chron) or basic web or XML or JSON which you could then post-process if you desired. I know this is kind of bloating the idea, but the flexibility and such would make it Really Useful .. I think, anyhow ... MJE
On 25 February 2016 at 21:02, Consus
wrote: > Well, we do have one > > https://gitweb.gentoo.org/repo/gentoo.git/log/dev-lang/perl > > I bet folks want to check out what's new in their local copy of Portage > tree. With a custom, portage oriented, on-demand log generator you could produce a lot more detail ( and in a text format that doesn't require a web browser to view ) , and potentially use understanding of portage conventions to generate change data outside those explicitly stated. Though that would be a "later feature" you could potentially bolt on after the main logic was sorted out. The idea being you could request a changelog for a package with a list of "interest aspects" and have the log reduced to changes that affect those interests. For instance, you could do : curl http://thing.gentoo.org/changes/dev-lang/perl?arch=~x86 And with a bit of effort, you could generate a changelog that is only relevant for somebody who is on ~x86, eliding changes that x86 didn't get yet. For instance, an ~x86 filter would elide stabilizations for ~x86, because you don't care about stabilizations if you're assuming ~arch. ( And it would elide changes that were only visible for other arches ) And this filter wouldn't necessarily be implemented in "grep for keywords in the commit message", but *analyse the change in the directory* based, which would give the ability to do things that would otherwise only be possible with a git clone. -- Kent KENTNL - https://metacpan.org/author/KENTNL
On 18:46 Thu 25 Feb, Kent Fredric wrote: > I'm considering bolting together some Perl that would allow you to run > a small HTTP service rooted in a git repo dir, and would then generate > given changes files on demand and then cache their results somehow. > > Then you could have a "Live changes as a service" where interested > parties could simply do: > > curl http://thing.gentoo.org/changes/dev-lang/perl > > and get a changelog spewed out instead of burdening the rsync server > with generating them for every sync. Well, we do have one https://gitweb.gentoo.org/repo/gentoo.git/log/dev-lang/perl I bet folks want to check out what's new in their local copy of Portage tree.