Re: difficulty in understanding options in init-system-GR
Hi Mo, Quoting Mo Zhou (2019-12-07 08:44:47) > I went through the options in the init-system-GR[1] but I feel > difficult to tell the subtle differences between the options. I'd like > to ask for some hints here. > > Option F is distince from the others as it clearly emphasizes "deeper > systemd integration". Option E puts equal weights to both systemd and > non-systemd solutions. So let's skip the two. > > The rest options, i.e. B A D H G, look nearly the same to me: "first > tier support for systemd, second tier for others" > The only difference I noted is the bug severity for non-systemd > support. > > In which way(s) are options (B, A, D, H, G) different from each other? > A couple of keywords should be helpful enough to differentiate them. > > Thanks in advance. > > > P.S. It could be extremely useful if a straightforward comparison > table like > [this](https://en.wikipedia.org/wiki/Comparison_of_file_systems) is > available. But it isn't. > > I'd kindly suggest the future GR initiators make some comparison > tables as long as options with subtle differences appear. > > [1] https://www.debian.org/vote/2019/vote_002 The very act of comparing is subjective, so finding one to be the "canonical" one might end up being difficult. I suggest to read the threads on debian-vote@l.d.o which includes both a) elaborations from some authors and b) attempts at making comparisons and emphasizing the differences. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: difficulty in understanding options in init-system-GR
On Dec 07, Mo Zhou wrote: > The rest options, i.e. B A D H G, look nearly the same to me: > "first tier support for systemd, second tier for others" > The only difference I noted is the bug severity for non-systemd support. > > In which way(s) are options (B, A, D, H, G) different from each other? > A couple of keywords should be helpful enough to differentiate them. They go from more systemd support to less systemd support in that order, and there are actually big practical differences. But I need to be clear: only choices 1 (B) and 2 (A) will allow Debian to progress like the other major distributions without being hindered by trying to support other init systems which are used/maintained by an handful of people. -- ciao, Marco signature.asc Description: PGP signature
Re: difficulty in understanding options in init-system-GR
On Sat, Dec 07, 2019 at 11:45:36AM +0100, Marco d'Itri wrote: > > The rest options, i.e. B A D H G, look nearly the same to me: > > "first tier support for systemd, second tier for others" > > The only difference I noted is the bug severity for non-systemd support. > > > > In which way(s) are options (B, A, D, H, G) different from each other? > > A couple of keywords should be helpful enough to differentiate them. > They go from more systemd support to less systemd support in that order, > and there are actually big practical differences. > But I need to be clear: only choices 1 (B) and 2 (A) will allow Debian > to progress like the other major distributions without being hindered by > trying to support other init systems which are used/maintained by an > handful of people. Choice 1 is F and Choice 2 is B. A is Choice 3 and says "Being able to run Debian systems with init systems other than systemd continues to be something that the project values.". -- WBR, wRAR signature.asc Description: PGP signature
Re: difficulty in understanding options in init-system-GR
Marco d'Itri - 07.12.19, 11:45:36 CET: > On Dec 07, Mo Zhou wrote: > > The rest options, i.e. B A D H G, look nearly the same to me: > > "first tier support for systemd, second tier for others" > > > > The only difference I noted is the bug severity for non-systemd > > support. > > > > In which way(s) are options (B, A, D, H, G) different from each > > other? A couple of keywords should be helpful enough to > > differentiate them. > They go from more systemd support to less systemd support in that > order, and there are actually big practical differences. > But I need to be clear: only choices 1 (B) and 2 (A) will allow Debian > to progress like the other major distributions without being hindered > by trying to support other init systems which are used/maintained by > an handful of people. I think you crossed the line between explaining the options and… trying to influence the choice of someone else by stating your opinion as a fact. I strongly recommend you to stay away of trying to influence the choice of someone else like this. State your own preference as much as you'd like to, as *your* *own* preference, not as a fact. I stayed away from the discussion on debian-vote, as I am no Debian developer and thus have no right to make an election here. Nor do I claim or request to have one. I just maintain a package which since a long time supports both Systemd and Sysvinit – on implementing the Sysvinit support I learned how to improve the Systemd support as well. I intend to watch the outcome of this election and then decide upon consequences I'd draw from it regarding my engagement for Debian. I still believe this whole GR may not serve Debian as a project, but I let go on arguing about that. Thanks, -- Martin
Re: difficulty in understanding options in init-system-GR
On Dec 07, Andrey Rahmatullin wrote: > > They go from more systemd support to less systemd support in that order, > > and there are actually big practical differences. > > But I need to be clear: only choices 1 (B) and 2 (A) will allow Debian > > to progress like the other major distributions without being hindered by > > trying to support other init systems which are used/maintained by an > > handful of people. > Choice 1 is F and Choice 2 is B. Thank you for your correction, you are obviously right. -- ciao, Marco signature.asc Description: PGP signature
Re: difficulty in understanding options in init-system-GR
On Dec 07, Martin Steigerwald wrote: > I think you crossed the line between explaining the options and… trying > to influence the choice of someone else by stating your opinion as a > fact. I have no doubts that my fellow debian developers know who I am and can put my words in the correct perspective. -- ciao, Marco signature.asc Description: PGP signature
Re: difficulty in understanding options in init-system-GR
On Sat, Dec 7, 2019 at 3:45 PM Mo Zhou wrote: > > Hi folks, > > I went through the options in the init-system-GR[1] but I feel difficult > to tell the subtle differences between the options. I'd like to ask for > some hints here. > I asked on IRC this morning too. Someone pointed me the LWN article[1], I think it has a good summary. [1] https://lwn.net/Articles/806332/ -- Shengjing Zhu
Re: difficulty in understanding options in init-system-GR
Hello, On Sat 07 Dec 2019 at 07:44AM +00, Mo Zhou wrote: > I went through the options in the init-system-GR[1] but I feel difficult > to tell the subtle differences between the options. I'd like to ask for > some hints here. > > Option F is distince from the others as it clearly emphasizes "deeper > systemd integration". Option E puts equal weights to both systemd and > non-systemd solutions. So let's skip the two. > > The rest options, i.e. B A D H G, look nearly the same to me: > "first tier support for systemd, second tier for others" > The only difference I noted is the bug severity for non-systemd support. > > In which way(s) are options (B, A, D, H, G) different from each other? > A couple of keywords should be helpful enough to differentiate them. Sam posted a voting guide on his blog.[1] Ian posted a blog post defending options D+H.[2] Ian is also working on a voting guide of his own atm but it's not yet posted. [1] https://hartmans.livejournal.com/99642.html [2] https://diziet.dreamwidth.org/3482.html -- Sean Whitton signature.asc Description: PGP signature
Re: difficulty in understanding options in init-system-GR
Mo Zhou writes ("difficulty in understanding options in init-system-GR"):
> I went through the options in the init-system-GR[1] but I feel difficult
> to tell the subtle differences between the options. I'd like to ask for
> some hints here.
I have written a blog posting about this:
Debian init systems GR - voting guide
https://diziet.dreamwidth.org/3999.html
> In which way(s) are options (B, A, D, H, G) different from each other?
> A couple of keywords should be helpful enough to differentiate them.
I think my posting will answer your question. If not, please let me
know...
Regards,
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Re: RFP: lintian-sort -- reproducibly sort the Lintian tool's output
On Fri, Dec 06, 2019 at 10:30:28PM -0800, Felix Lechner wrote:
> Hi,
>
> > The lintian-sort tool reorders the messages reported by the lintian(1)
> > Debian package analysis tool so that they are kept in the same order
> > between successive builds.
>
> > Wouldn't it be much better to apply this change to lintian itself?
>
> Lintian now orders tags before printing. That resolves the most
> relevant feature requested here. The output was already deterministic,
> but depended on the order in which checks that had been sorted were
> run:
>
> https://bugs.debian.org/944807
>
> This is the Lintian commit message:
>
>
> https://salsa.debian.org/lintian/lintian/commit/e0f76bdd6bf57d84ba2e7b478973ddc8b84df950
>
> Besides the bug in Lintian, this message also closes an RFP bug that
> had been cloned. Please re-open the RFP bug if we still need a second
> tool.
>
> To help make Lintian better, please file merge requests on Salsa. Thanks!
Thanks a lot for this e-mail and for doing the work on Lintian, as well
as all your (team's) other work on Lintian!
I actually saw the Lintian change (I have it pinned to unstable in my
APT preferences), and I dropped lintian-sort from my Debian packaging
workflow (the scripts I run after each package build), but I plain
forgot that I had also filed an ITP bug and even a bug against
Lintian... sorry about that, and thanks for noticing/remembering!
You were indeed quite right to close both.
Keep up the great work!
G'luck,
Peter
--
Peter Pentchev roam@{ringlet.net,debian.org,FreeBSD.org} p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
signature.asc
Description: PGP signature
Re: About license compatibility
Thank you for your detailed answer. :)
I'm gonna ask one more question, please.
> At least this is not the case of Debian. As I previously said, Debian as a
> distribution or any other distributions *cannot* have an overall license.
> Every distribution is made up of various software. Debian must respect the
> original upstream license of each software and must not alter them. If the
> upstream license is not reasonable or considered "non-free", Debian would
> decide not to include it into Debian's "main" section. As far as I know,
> Debian never declared itself to be released "under GPLv2" or any other
> licenses. When you are logging in from terminal on Debian devices, the
> following greeting information will pop up
I was confused Ubuntu cannot have an overall license, because of the
license of Ubuntu as below.
"Ubuntu operates under the GNU General Public License (GPL) and all of the
application software installed by default is free software.
In addition, Ubuntu installs some hardware drivers that are available only
in binary format, but such packages are clearly marked in the restricted
component."
(https://en.wikipedia.org/wiki/Ubuntu)
But, I can get it clearly now after I know there is no mention of GPL at
the Ubuntu's license page.
(https://ubuntu.com/licensing)
Best regards.
2019년 12월 7일 (토) 오전 4:14, Boyuan Yang 님이 작성:
> Hi,
>
> 在 2019-12-06五的 11:06 +0900，JungHwan Kang写道：
> > Thank you for your answer.
> >
> > > 2019. 12. 6. 오전 12:57, Boyuan Yang 작성:
> > >
> > > Hi,
> > >
> > > Disclaimer: the canonical answer to license issues should be given by
> > > debian-
> > > legal mailing list (https://lists.debian.org/debian-legal). There
> might be
> > > errors in my words below.
> > >
> > > 在 2019-12-06五的 00:10 +0900，JungHwan Kang写道：
> > > > Hi, Debian forks.
> > > > I know Debian has GPLv2.
> > >
> > > My personal understanding is that "Debian" is never ever specifically
> > > released
> > > under certain license ("GPLv2" or anything else). I have never heard of
> > > the
> > > saying that "Debian is under GPLv2" or "Debian has GPLv2". Debian is
> made
> > > up
> > > of tens of thousands of individual packages and each package has its
> own
> > > license recorded in debian/copyright file and you may find that file as
> > > /usr/share/doc//copyright when the package is installed on
> > > your
> > > system.
> >
> > Is this the license policy for debian below?
> > https://en.m.wikipedia.org/wiki/Debian_Free_Software_Guidelines
>
> The official license policy documentation is published here:
> https://www.debian.org/legal/licenses/ . The Debian Free Software
> Guidelines
> are some high-level guides that are accepted across Debian but they may
> not be
> the precise description of Debian's license policy.
>
>
> > > > There are many packages having a different license in the Debian
> > > > distribution.
> > > > How to resolve a conflict between licenses to specify GPLv2?
> > > > For instance, GPLv2 & GPLv3 are incompatible.
> > >
> > > I never heard that GPLv2 license and GPLv3 license are incompatible.
> > >
> > > The real example of incompatibility should be OpenSSL and GPL (
> > > https://people.gnome.org/~markmc/openssl-and-the-gpl.html) or GPL and
> CDDL
> > > (
> > > https://lwn.net/Articles/687550/). Debian is aware of those issues and
> > > these
> > > issues have been taken care of already.
> >
> > I mean if there is a Linux distribution released under GPLv3, the
> > distribution isn’t able to include packages under GPLv2.
> > https://images.app.goo.gl/cqzufQ1c7CHP8dNL6
>
> > The programs included with the Debian GNU/Linux system are free software;
> > the exact distribution terms for each program are described in the
> > individual files in /usr/share/doc/*/copyright.
> >
> > Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
> > permitted by applicable law.
>
> It only describes the individual licenses of each software and there's
> never
> an overall license for Debian itself.
>
>
> As other developers said previously (in
> https://lists.debian.org/debian-devel/2019/12/msg00034.html ),
> "...shipping
> two packages whose licenses are incompatible... is never a problem. An
> incompatibility can only be triggered when you actually 'combine' the two
> packages...". As a result, it's okay for Debian to *ship* both GPL-2-only
> packages and GPL-3-only packages. We are talking about shipping only, not
> about compiling or linking; the latter case would indeed be a violation of
> licenses.
>
> Aside of that, If you do find any software provided in Debian is using
> source
> code that are licensed under conflicting licenses (e.g., combining
> GPL-2-only
> AND GPL-3-only source codes to generate a package) or linking two
> binary/libraries that are using conflict licenses (e.g., OpenSSL library
> and
> original GPL-licensed software, as described in
> https://people.gnome.org/~markmc/openssl-and-the-gpl.html) , please file
> a bug
> against that software in Debian with high se
