Github messages for voidlinux
 help / color / mirror / Atom feed
From: Duncaen <Duncaen@users.noreply.github.com>
To: ml@inbox.vuxu.org
Subject: Re: Better communication
Date: Mon, 04 Sep 2023 02:15:15 +0200	[thread overview]
Message-ID: <20230904001515.bv8zxHvrAIDIvizU5VTds8AUQVGQEKJL6EOqzWGsJ1A@z> (raw)
In-Reply-To: <gh-mailinglist-notifications-41a7ca26-5023-4802-975b-f1789d68868e-void-packages-45892@inbox.vuxu.org>

[-- Attachment #1: Type: text/plain, Size: 4778 bytes --]

New comment by Duncaen on void-packages repository

https://github.com/void-linux/void-packages/issues/45892#issuecomment-1704445743

Comment:
> If an update removes a package that I use, I would appreciate a post install message telling me so, telling me why and what can I do instead (telling me to manually install an alternative package for example).

The packages are being listed for removal, you still have to actually accept the updates before the package is removed.

A post install message can only be shown by package that are still installed, new messages can't be put in old packages.

If there is something that pulling in the old or the new version, we can put an install message in it, like it was done with `pipewire-mediasessions` where an install message was added to `pipewire`.

There are a lot of packages that are being removed all the time, for good reasons. 

Without removing them "automatically", users won't be able to update their system or install packages at all. The "automatic" (user accepted) removals make it possible to update and remove packages at the same time, without breaking any dependencies. Users would have to manually remove the breaking packages while breaking potentially other currently installed packages that depend on them using `xbps-remove --force-revdeps oldpkg` so they can then update again with`xbps-install -u`.

If you really don't like the "automatic" removals, there are two options for you.

1. `ignorepkg=removed-packages` and then uninstall the `removed-packages` meta package and manually remove packages if strictly required due to dependencies.
2.  Hold the `removed-packages` package and unhold it when required and (twice checked by you) using `xbps-pkgdb -m hold removed-packages` and `xbps-pkgdb -m unhold removed-packages` afterwards you can hold again.

If you do that, and you run into any troubles that you can't solve yourself, make sure you mention that you do this and first try to check if that is the cause.

> With the crypto PR, I am upset that out of the blue void is taking an anti crypto stance & then doing a wide purging of packages it's users depend on, regardless of how well they where maintained or if there was any willing maintainers.

There was not a single person that objected it in the pull request. And we already accepted that this wasn't good and more maintainers and contributors should have been pinged.

> There was also zero links to any IRC log, or any summery of the WHAT & WHY for the ""consensus"". The way this was handled feels like there is an alternative non technical motive that is trying to be hidden.

Nobody linked or showed any logs, because there are no links, the channel is public and everyone is welcomed to join. Nobody here or in the PR afterwards said that the IRC discussion was enough to accept the removal.

Nothing was or is being hidden, it was a public pull request by a contributor that was open for 12 days, then it was merged after some approval.
Again, this was reverted and discussed already in the PR that brought it back. If more people would have been pinged/tagged in the PR, this wouldn't have been a problem at all.

I don't see why why have to discuss this at length, nobody disapproved of bringing the packages back when contributors and maintainers wanted to bring them back.

> I do not understand why it would be removed.

Literally just because some contributor opened a pull request and there was some chatter on IRC about the packages being outdated and not well maintained or of interest for anymore.

And again it was already reverted, and people accepted that it wasn't sufficient enough without pinging/tagging more maintainers.

> If there is no intent on being neutral, then please make your political or social stance explicit and clear, if crypto people are not welcome in the void ecosystem then please just tell us that.
> If crypto in it self is not a problem and its a problem with maintaining packages, then lets work on that, I may be interested in helping with packaging if crypto packaging needs help, but I don't want to bother if that is not welcome.

Find a web3 based distributions with NFTs and shit, "crypto people" lol.

Its probably generally a good decision to not accept any "new" crypto currency packages anymore, would've been even better if that had been done earlier.
If there for some reason actually happens to be something useful and important, then this can always be discussed. This avoids people wasting their time writing packages for things nobody with write access has interest in or is going to merge without having interest.

The wording is what it is, there was simply no big discussion and I don't think the wording is wrong in any way.

  parent reply	other threads:[~2023-09-04  0:15 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-03  5:23 [ISSUE] " Yorizuka
2023-09-03  5:43 ` classabbyamp
2023-09-03  6:00 ` Yorizuka
2023-09-03  6:00 ` Yorizuka
2023-09-03  6:29 ` Yorizuka
2023-09-03 11:11 ` Duncaen
2023-09-03 16:20 ` Yorizuka
2023-09-03 17:07 ` Duncaen
2023-09-03 17:07 ` Duncaen
2023-09-03 17:08 ` Duncaen
2023-09-03 17:18 ` Duncaen
2023-09-03 17:20 ` Duncaen
2023-09-03 17:20 ` Duncaen
2023-09-03 17:24 ` Duncaen
2023-09-03 17:30 ` Duncaen
2023-09-03 17:31 ` Duncaen
2023-09-03 18:54 ` Duncaen
2023-09-03 18:55 ` Duncaen
2023-09-03 20:18 ` Yorizuka
2023-09-03 20:38 ` Eloitor
2023-09-03 21:22 ` Yorizuka
2023-09-04  0:13 ` Duncaen
2023-09-04  0:14 ` Duncaen
2023-09-04  0:15 ` Duncaen [this message]
2023-09-04  0:16 ` Duncaen
2023-09-04  0:18 ` Duncaen
2023-09-04  7:20 ` Yorizuka
2023-09-04  7:21 ` Yorizuka
2023-09-04  7:22 ` Yorizuka
2023-09-04  7:27 ` Yorizuka
2023-09-04  7:35 ` Yorizuka
2023-09-04  7:37 ` Yorizuka
2023-09-04  9:54 ` Duncaen
2023-09-04  9:56 ` Duncaen
2023-09-04 10:01 ` Duncaen
2023-09-04 10:05 ` Yorizuka
2023-09-04 10:07 ` Yorizuka
2023-09-04 10:07 ` Yorizuka
2023-09-04 10:17 ` Duncaen
2023-09-04 10:24 ` Yorizuka
2023-09-04 11:10 ` Yorizuka
2023-09-04 11:12 ` Yorizuka
2023-09-04 11:17 ` Yorizuka
2023-09-04 11:25 ` Yorizuka
2023-09-04 11:39 ` Yorizuka
2023-09-04 23:35 ` 0x5c
2023-09-05  0:49 ` Yorizuka
2023-09-05  0:53 ` Yorizuka
2023-09-05  1:09 ` Yorizuka
2023-09-16 15:52 ` [ISSUE] [CLOSED] " ahesford

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230904001515.bv8zxHvrAIDIvizU5VTds8AUQVGQEKJL6EOqzWGsJ1A@z \
    --to=duncaen@users.noreply.github.com \
    --cc=ml@inbox.vuxu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).