Re: [gentoo-dev] Re: rfc: Does OpenRC really need mount-ro

[Raymond Jennings]

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 

Re: [gentoo-dev] Re: Bug #565566: Why is it still not fixed?

[Gordon Pettey]

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.

Re: [gentoo-dev] Re: Bug #565566: Why is it still not fixed?

[M. J. Everitt]

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

Re: [gentoo-dev] Re: Bug #565566: Why is it still not fixed?

[Kent Fredric]

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

Re: [gentoo-dev] Re: Bug #565566: Why is it still not fixed?

[Consus]

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.