Github messages for voidlinux
 help / color / mirror / Atom feed
From: hippi777 <hippi777@users.noreply.github.com>
To: ml@inbox.vuxu.org
Subject: Re: [proposal] templates without official binaries
Date: Sun, 01 Nov 2020 21:06:13 +0100	[thread overview]
Message-ID: <20201101200613.W0NZNzBm3MLN8srvZgtRvrR_sG1vas2hbqYZ1qtOTuI@z> (raw)
In-Reply-To: <gh-mailinglist-notifications-41a7ca26-5023-4802-975b-f1789d68868e-void-packages-25901@inbox.vuxu.org>

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

New comment by hippi777 on void-packages repository

https://github.com/void-linux/void-packages/issues/25901#issuecomment-720143673

Comment:
thank u very much Duncaen! :) i think i finally got to the point, and i should say it is fine then this way (i mean not messing with the template options) - or at least after all i dare to hope so... :D


> btw... is this happening? This will be a blessing since I heard many complaining that there aren't enough packages on official repos. If there is a separate repo for user packages they can be found in one place rather than being scattered throughout the web.

this is the very essence of my proposal, and it sounds like the need for it really exists, however i made no steps towards it, and im not aware of anything like that...


i think what u, Duncaen, explained to me applies more-or-less to the case of the extra/dropped templates too, but as those wouldnt necessarily mess with the blessed templates or the packaging, they could still get a place to exists, and why i came here is that keeping such resources around the official stuffs would make them discoverable.

and yep, i know this smells like aur and i saw anticipation about that previously (maybe that was the git head grub :D ), but as of my understanding, that was about the maintainability of them, while that isnt a necessary requirement as of my proposal. so the question that remains here is whether it could get a repo under the flagship of github.com/void-linux, or maybe a directory somewhere inside github.com/void-linux/void-packages, as i guess that these options could make any related workflow any smoother, but u will know that better. the downside of the latter is that it would generate some noise for the packagers, and the former would still need the staff to merge whatever would come there. and still, i mean that these would be denoted as not being too much distinct from a junkyard with possible gems for common needs that doesnt fit, while it is still better than making things from the ground up or even hunting for them on various grounds.

after all, if it isnt a thing that the maintainers would welcome to be too near, it can still be done elsewhere, and it can still get a pointer from somewhere, but the question is if it could worth for any reason to keep such near or not? maybe it could even become a thing like aur by the time, maybe it can be started elsewhere and a reason to make an official fork could arose, so after all, this isnt that much of a cardinal question, but it may still worth to think about it, and to ask it. either way, a decision about it will draw the path for any continuation.

  parent reply	other threads:[~2020-11-01 20:06 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-26 15:53 [ISSUE] " hippi777
2020-10-27 11:53 ` Duncaen
2020-10-27 11:53 ` Duncaen
2020-10-27 13:20 ` hippi777
2020-10-31 16:58 ` reback00
2020-10-31 17:23 ` hippi777
2020-10-31 17:47 ` reback00
2020-11-01  9:56 ` hippi777
2020-11-01 10:29 ` Duncaen
2020-11-01 11:45 ` hippi777
2020-11-01 12:05 ` Duncaen
2020-11-01 12:06 ` Duncaen
2020-11-01 18:13 ` reback00
2020-11-01 18:14 ` reback00
2020-11-01 18:17 ` reback00
2020-11-01 20:06 ` hippi777 [this message]
2020-11-01 22:31 ` fosslinux
2020-11-01 22:34 ` fosslinux
2020-11-02 16:12 ` reback00
2022-04-22  2:14 ` github-actions
2022-04-22 15:56 ` [ISSUE] [CLOSED] " Duncaen

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=20201101200613.W0NZNzBm3MLN8srvZgtRvrR_sG1vas2hbqYZ1qtOTuI@z \
    --to=hippi777@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).