Re: [arch-dev-public] Add active Python versions to the repos
Remember, write the angry email first, wait a half hour, then re-write. Please keep the IRC flamewars to IRC where some of us can avoid it without losing contact with important discussion. :) signature.asc Description: PGP signature
Re: [arch-dev-public] Add active Python versions to the repos
On Sun, 2020-11-22 at 11:45 -0500, Eli Schwartz via arch-dev-public wrote: > On 11/22/20 10:05 AM, Filipe Laíns wrote: > > On Sat, 2020-11-21 at 20:24 -0500, Eli Schwartz via arch-dev-public wrote: > > > Your analysis is correct, it is indeed hell. I'm not sure why that is an > > > argument in favor of doing even more of it though. > > > > > > Now, if you were proposing to get rid of some of this, I could get > > > behind that. > > > > It was not an analysis, "hell" was an used here as an idiom. > > https://i.imgur.com/axJmn.gif > > You were unintentionally accurate. > > > > > even Python. > > > > > > I don't know if maybe you've missed the fact that we've spent like a > > > year now aggressively upgrading or removing leaf packages depending on > > > python2 in search of that glorious Promised Future where we can finally > > > remove the python2 package itself? > > > > I did not miss that. I absolutely want to see the python2 modules removed, > > not > > _necessarily_ the python2 interpreter. > > Now I'm starting to see part of the reason why people are having a > difference of opinions here. > > I think I probably speak for a bunch of people when I say I'd like to > see the interpreter dropped due to not being needed by any packages > *and* being an end of life interpreter. The interpreter is only useful > inasmuch as people use it to run software, so if we don't have any... > > I expect by the time we finally remove all reverse dependencies for it, > the gap between the python2 EOL and its removal from the distro will be > quite a bit biger than it currently is. > > > > And we're doing that even for a major incompatible release that most > > > people argue is actually a different language. > > > > > > I'm not sure how this suddenly became an argument to package a ton of > > > point releases that aren't even incompatible. > > > > Except they are... Python does not follow semver, only patch releases are > > supposed to be compatible. They do try to keep breakage to a minimum, but it > > definitely exists. One very obvious example is the introduction of "async" > > and > > "await" as reserved keywords. There are a bunch of other backwards > > incompatible > > changes, so yes, they are incompatible releases, to the point you could call > > them different languages. > > This is the first time I ever heard anyone describe "backwards > incompatible changes means it is now a different programming language". You literally mentioned that in your reply. Though I assume you meant more significant change than what is being discussed. If the languages semantics are different one could argue it is actually a different language. Anyway, this does not really matter for the issue being discussed. > I had backwards incompatible changes in a patchlevel bugfix in the > python 3.8.x release line causing immediate traceback and SystemExit on > a program's startup, does that mean every bugfix is now a different > programming language? > > (I mean this quite literally. Python bugfixed a function not working as > expected under certain situations. The program it broke was working > around the failure by manually doing $thing, the traceback happened when > you try to do $thing twice.) > > > > > I don't think having people opening bugs because they are > > > > deliberately using an older version of Python is a big problem. It > > > > hasn't been for any of the other languages, I don't think it will be > > > > here. > > > > I think this is an hypothetical that doesn't really materialize into > > > > reality. > > > > > > You're proposing something far beyond the scope of what we do for other > > > languages, and ignoring that for other languages we only do it if driven > > > to in desperation because another official repository package depends on > > > it. > > > > > > We don't introduce leaf packages of ancient versions of currently > > > packaged interpreters just for fun. I don't even think anyone else does > > > that either. > > > > That was not of the point of me bringing up other languages. The whole point > > of > > me bringing up other languages was to show that Andreas' concern is unlikely > > to > > materialize into reality. > > You think no one reports bugs for python-* packages that we should > provide the python2 version? I promise you, you're wrong. I've closed > those bugs, so I know they exist. That is not "users raising bugs that something doesn't work with an older version of python", and is not what I argued against. > You specifically brought up Java and Javascript, languages where each > application is forced to vendor their entire dependency list rather than > using system modules. For this reason, people don't report the kind of > bugs Andreas is concerned about for Java/nodejs... They are not necessarily forced, but whatever, just ignore that. > So I assumed you could not possibly be talking about Andreas' concern, > and I responded somewhat tangentially myself. We can, of course,
Re: [arch-dev-public] Add active Python versions to the repos
On 11/22/20 10:05 AM, Filipe Laíns wrote: > On Sat, 2020-11-21 at 20:24 -0500, Eli Schwartz via arch-dev-public wrote: >> Your analysis is correct, it is indeed hell. I'm not sure why that is an >> argument in favor of doing even more of it though. >> >> Now, if you were proposing to get rid of some of this, I could get >> behind that. > > It was not an analysis, "hell" was an used here as an idiom. https://i.imgur.com/axJmn.gif You were unintentionally accurate. >>> even Python. >> >> I don't know if maybe you've missed the fact that we've spent like a >> year now aggressively upgrading or removing leaf packages depending on >> python2 in search of that glorious Promised Future where we can finally >> remove the python2 package itself? > > I did not miss that. I absolutely want to see the python2 modules removed, not > _necessarily_ the python2 interpreter. Now I'm starting to see part of the reason why people are having a difference of opinions here. I think I probably speak for a bunch of people when I say I'd like to see the interpreter dropped due to not being needed by any packages *and* being an end of life interpreter. The interpreter is only useful inasmuch as people use it to run software, so if we don't have any... I expect by the time we finally remove all reverse dependencies for it, the gap between the python2 EOL and its removal from the distro will be quite a bit biger than it currently is. >> And we're doing that even for a major incompatible release that most >> people argue is actually a different language. >> >> I'm not sure how this suddenly became an argument to package a ton of >> point releases that aren't even incompatible. > > Except they are... Python does not follow semver, only patch releases are > supposed to be compatible. They do try to keep breakage to a minimum, but it > definitely exists. One very obvious example is the introduction of "async" and > "await" as reserved keywords. There are a bunch of other backwards > incompatible > changes, so yes, they are incompatible releases, to the point you could call > them different languages. This is the first time I ever heard anyone describe "backwards incompatible changes means it is now a different programming language". I had backwards incompatible changes in a patchlevel bugfix in the python 3.8.x release line causing immediate traceback and SystemExit on a program's startup, does that mean every bugfix is now a different programming language? (I mean this quite literally. Python bugfixed a function not working as expected under certain situations. The program it broke was working around the failure by manually doing $thing, the traceback happened when you try to do $thing twice.) >>> I don't think having people opening bugs because they are >>> deliberately using an older version of Python is a big problem. It >>> hasn't been for any of the other languages, I don't think it will be >>> here. >>> I think this is an hypothetical that doesn't really materialize into >>> reality. >> >> You're proposing something far beyond the scope of what we do for other >> languages, and ignoring that for other languages we only do it if driven >> to in desperation because another official repository package depends on it. >> >> We don't introduce leaf packages of ancient versions of currently >> packaged interpreters just for fun. I don't even think anyone else does >> that either. > > That was not of the point of me bringing up other languages. The whole point > of > me bringing up other languages was to show that Andreas' concern is unlikely > to > materialize into reality. You think no one reports bugs for python-* packages that we should provide the python2 version? I promise you, you're wrong. I've closed those bugs, so I know they exist. You specifically brought up Java and Javascript, languages where each application is forced to vendor their entire dependency list rather than using system modules. For this reason, people don't report the kind of bugs Andreas is concerned about for Java/nodejs... So I assumed you could not possibly be talking about Andreas' concern, and I responded somewhat tangentially myself. We can, of course, talk about Andreas' concern, but given I've now submitted the authoritative facts on the matter, I'm not sure what else there is to say. It does indisputably happen right now. The logical inference is, it will happen *more*, if we add more runtimes for people to submit bugtracker tickets for. >> You want to package old versions of the python3 interpreter "but not >> modules", because "people would like to use it for tox". > > People can use it tox or to create virtual environments directly. The main > point > of the proposal is that people have use for the old interpreters and I would > like to provide them. The main point of my objection is that their use isn't to run software, it's to regression test it -- something more suited to Continuous Integration which already targets a
Re: [arch-dev-public] Add active Python versions to the repos
On Sun, 2020-11-22 at 09:43 -0600, Doug Newgard via arch-dev-public wrote: > On Sun, 22 Nov 2020 15:32:22 + > Filipe Laíns via arch-dev-public wrote: > > > On Sun, 2020-11-22 at 09:13 -0600, Doug Newgard via arch-dev-public wrote: > > > Why did you start the discussion if you plan on ignoring other people's > > > opinions anyway? > > > > > > Doug > > > > I am not ignoring Andreas' or Eli's opinion, I understand that they don't > > want > > these packages in the repos. What I am asking is why they don't want them > > there? > > I don't appreciate you trimming the paragraph I was replying to. I makes my > comments look completely different without context. Sorry, I only replied to the specific reply because my email client is messing up the format and I have not fixed it yet. I did not meant to take it out of context. > The paragraph specifically said that you see no reason to block anything as > long as someone is willing to maintain it. That means that other's opinions > in this disussion don't matter, unless I misunderstood? > > Doug That was not meant that way. Similarly to your reply, the context matters. The comment was meant as "If this helps people and does not impact you, why would you block it?", I said this because Eli seems hell bent on not having the packages in the repos. Sorry if it came out the wrong way. Cheers, Filipe Laíns signature.asc Description: This is a digitally signed message part
Re: [arch-dev-public] Add active Python versions to the repos
On Sun, 22 Nov 2020 15:32:22 + Filipe Laíns via arch-dev-public wrote: > On Sun, 2020-11-22 at 09:13 -0600, Doug Newgard via arch-dev-public wrote: > > Why did you start the discussion if you plan on ignoring other people's > > opinions anyway? > > > > Doug > > I am not ignoring Andreas' or Eli's opinion, I understand that they don't want > these packages in the repos. What I am asking is why they don't want them > there? I don't appreciate you trimming the paragraph I was replying to. I makes my comments look completely different without context. The paragraph specifically said that you see no reason to block anything as long as someone is willing to maintain it. That means that other's opinions in this disussion don't matter, unless I misunderstood? Doug
Re: [arch-dev-public] Add active Python versions to the repos
On Sun, 2020-11-22 at 09:13 -0600, Doug Newgard via arch-dev-public wrote: > Why did you start the discussion if you plan on ignoring other people's > opinions anyway? > > Doug I am not ignoring Andreas' or Eli's opinion, I understand that they don't want these packages in the repos. What I am asking is why they don't want them there? I have addressed the concern Andreas raised. I am not sure if satisfactorily to him as he has not replied yet. Eli, so far, has presented me with the current status quo, stating this is not we currently do. Which was never what I was arguing, that's why I have started this thread, in hope of changing that. From his reply, the only part I see as actual reasoning against the proposed change is this: > I don't see any reason why [community] needs to grow to support the needs of exclusively Continuous Integration testsuite matrixes. Which I have addressed. Please let me know if I've missed any of his points. Cheers, Filipe Laíns signature.asc Description: This is a digitally signed message part
Re: [arch-dev-public] Add active Python versions to the repos
On Sun, 22 Nov 2020 15:05:04 + Filipe Laíns via arch-dev-public wrote: > As long as there is someone willing to maintain the packages, why would we > block > it? I doesn't really have any effect on the rest of the people. If the person > start having trouble maintaining them, they can be dropped. It doesn't affect > you and helps other people. > > Cheers, > Filipe Laíns Why did you start the discussion if you plan on ignoring other people's opinions anyway? Doug
Re: [arch-dev-public] Split openssl package
On 11/21/20 4:52 AM, Pierre Schmitz wrote: > Hi all, > > there is a new set of openssl packages in testing that are split into > openssl, openssl-doc and openssl-perl. See > https://bugs.archlinux.org/task/54887 > > As most users just need the library the perl dependency can be > dropped. Summing up: > > Before: > openssl: depends on Perl; size: 3.6 MiB (7.31 MiB) > > After: > openssl: depends just on glibc; size: 1.78 MiB (5.49 MiB) > openssl-perl: depends on Perl > openssl-doc: size: 1.82 MiB I wasn't going to mention this, originally, because even though I don't *like* splitting openssl into openssl-doc to remove 1/4 of a 7mb package (we don't generally split out -doc packages unless the size is noticeable enough to actually impact users, which this isn't IMHO, and man 5 pacman.conf contains "NoExtract" for a reason), this is ultimately a maintainer judgment call. This was before I realized, in addition to moving a bunch of section 3 developer-oriented manpages, you also moved the section 1 manpages documenting the end-user command-line tool /usr/bin/openssl and the section 5 manpages documenting the end-user configuration file format. This is entirely wrong, and if you are going to split out the API docs in usr/share/man/man3 it MUST be *only* the API docs in the man3/ directory, not the entire set of manual pages. > > We actually talked about this at ArchConf last year. Splitting the > package was the easy part, but dropping the Perl dependency means that > any package up the tree that depends on openssl needs to be checked if > it actually needs Perl itself. Thanks to everybody who did the hard > work here! > > PS: Do you think we should post a news item about this change? Most > people won't need to worry about this, but those few who need the perl > scripts need to install the separate package. > > Greetings, > > Pierre > -- Eli Schwartz Bug Wrangler and Trusted User OpenPGP_0x84818A6819AF4A9B.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
Re: [arch-dev-public] Add active Python versions to the repos
On Sat, 2020-11-21 at 20:24 -0500, Eli Schwartz via arch-dev-public wrote:
> Your analysis is correct, it is indeed hell. I'm not sure why that is an
> argument in favor of doing even more of it though.
>
> Now, if you were proposing to get rid of some of this, I could get
> behind that.
It was not an analysis, "hell" was an used here as an idiom.
> > even Python.
>
> I don't know if maybe you've missed the fact that we've spent like a
> year now aggressively upgrading or removing leaf packages depending on
> python2 in search of that glorious Promised Future where we can finally
> remove the python2 package itself?
I did not miss that. I absolutely want to see the python2 modules removed, not
_necessarily_ the python2 interpreter.
> And we're doing that even for a major incompatible release that most
> people argue is actually a different language.
>
> I'm not sure how this suddenly became an argument to package a ton of
> point releases that aren't even incompatible.
Except they are... Python does not follow semver, only patch releases are
supposed to be compatible. They do try to keep breakage to a minimum, but it
definitely exists. One very obvious example is the introduction of "async" and
"await" as reserved keywords. There are a bunch of other backwards incompatible
changes, so yes, they are incompatible releases, to the point you could call
them different languages.
> > I don't think having people opening bugs because they are
> > deliberately using an older version of Python is a big problem. It
> > hasn't been for any of the other languages, I don't think it will be
> > here.
> > I think this is an hypothetical that doesn't really materialize into
> > reality.
>
> You're proposing something far beyond the scope of what we do for other
> languages, and ignoring that for other languages we only do it if driven
> to in desperation because another official repository package depends on it.
>
> We don't introduce leaf packages of ancient versions of currently
> packaged interpreters just for fun. I don't even think anyone else does
> that either.
That was not of the point of me bringing up other languages. The whole point of
me bringing up other languages was to show that Andreas' concern is unlikely to
materialize into reality.
> > > It's sad enough we still have python2 and gtk2 around. To have gcc9
> > > around and other duplicates is not what I want to see growing in
> > > Arch.
> >
> > What you call sad I call a bad UX. Why do we need to force users to
> > compile active releases of the Python interpreters themselves, which
> > can take a long time if they are building with optimization, or to
> > resort to pre-built repos with much lower security standards than us,
> > when there are people willing to maintain them?
> >
> > I can't understand how it's sad to help out users by not forcing them
> > to resort the sort of things I mentioned above, as long as we are not
> > struggling to do so. I like helping people, that's why I am a packager,
> > that is the opposite of sad for me, so I really can't understand this.
>
> I have... no idea what the problem is supposed to be here? I'm
> desperately trying to understand what the actual point of your proposal is.
>
> You want to package old versions of the python3 interpreter "but not
> modules", because "people would like to use it for tox".
People can use it tox or to create virtual environments directly. The main point
of the proposal is that people have use for the old interpreters and I would
like to provide them.
> Old versions of stuff that people need for who knows what weird reason
> is *the textbook reason* why the AUR exists. How long it takes to
> compile stuff in the AUR is not our problem, and we don't have a
> rationale to upload gcc-{4,5,6,7,8,9} because actual users need to use a
> lot of diverse compilers "to test that it still works on really old
> compilers".
AFAIK, the textbook reason why the AUR exists is to provide software that isn't
in the official repos. It being older versions should be completely incidental,
but not the "textbook reason".
> Likewise, if people want to test support for old versions of python3,
> they have options which don't involve uploading trash into [community].
I like how you refereed to the currently active Python releases as "trash", will
keep that in mind.
> - Do what normal people do, and build AUR packages they need
> - Ask FFY00 to provide signed repos
> - Use travis CI, which doesn't use distro packages but provides a
> diverse set of hand-compiled python versions, which is apparently some
> kind of gold standard for doing regression testing on lots of
> different python releases ;)
> - Use pyenv
>
> Apparently none of these are viable options in your mind, and the most
> Arch-like of them, option #1 "use the AUR" you believe to be problematic
> because it takes a long time to build with optimizations... even though
> you yourself said those packages don't enable
Re: [arch-dev-public] Split openssl package
On Sun, Nov 22, 2020 at 2:57 AM Eli Schwartz via arch-dev-public wrote: > As I mentioned there, I don't really see the need to make a split > package just for 25kb of optional scripts that can just use optdepends. > > "I tendo o lean towards a separate package instead of using optdepends > as it is more explicit and you do not end up with partly invalid package." > > Do you then propose Arch should switch policies and start using split > packages everywhere instead of our usual optdepends? Not sure what to > think here. This feels inconsistent. First of all, I think using split packages and optdependes are both reasonable solutions. Splitting a package can be used to either reduce sizes of individual packages or to reduce dependencies. The latter can be achieved by optdependes as well. My personal rule of thumb here would be: If a program cannot work without a given dependent it should not be optional. In contrast if you have software that e.g. is able to use several databases for storage but falls back to sqlite one could declare mysql, postgres etc. as optional as long as the program is usable without them. Either way, I would call both solutions to be correct. Greetings, Pierre
