On Wed, Nov 27, 2019 at 11:28:34AM -0600, Chris Adams wrote:
> Once upon a time, Matej Grabovsky said:
> > Can you please explain what you mean? What are the alternatives if
> > there really are over 5000 packages in CTAN?
>
> Why does all of CTAN need to go into one source RPM?
Actually it's
On Wed, Nov 27, 2019 at 09:49:32PM -0500, Chris wrote:
> + Richard: Thank you very much for sharing those references, I had a look
> into each specfile and first of... whoa... they're very big But one
> thing I noticed is nbdkit is slightly inconsistent with some of the other
> package (or vs
On 11/27/19 6:49 PM, Chris wrote:
+ Sérgio: In regards to why sub-packages:
* Purely for modularity and isolation. Users who just use Apprise
for... say Discord and Email, don't need the other 49 packages. But
someone hosting a notification web service might want all of them except
the
Thank you all for replying with so much information! I just had a few
comments:
+ I'm officially afraid of the texlive spec file.
+ Sérgio: In regards to why sub-packages:
* Purely for modularity and isolation. Users who just use Apprise
for... say Discord and Email, don't need the other 49
Once upon a time, Matej Grabovsky said:
> Can you please explain what you mean? What are the alternatives if
> there really are over 5000 packages in CTAN?
Why does all of CTAN need to go into one source RPM?
--
Chris Adams
___
devel mailing list --
On Wed, Nov 27, 2019 at 02:33:15PM +, Richard W.M. Jones wrote:
> I also maintain projects with a large (though not this large) number
> of subpackages, eg: nbdkit has 25+:
>
> https://koji.fedoraproject.org/koji/buildinfo?buildID=1417304
[...]
> libvirt and qemu have a very large number
On Tue, Nov 26, 2019 at 08:49:31PM -0500, Chris wrote:
> Hi guys,
>
> I just wanted to poll you for some advice. My notification tool I maintain
> supports more than 50+ services now, but the only package isolation I do
> within 2 RPMs. One for the actual CLI (for admin's who want to use it)
On Wed, Nov 27, 2019 at 11:25:25AM +, Ankur Sinha wrote:
> On Wed, Nov 27, 2019 10:45:00 +, Ian McInerney wrote:
> > Tex isn't really the best example for the insane package numbers (since the
> > main Tex system, CTAN, actually does define them as separate packages). It
> > would be
On Wed, 2019-11-27 at 07:44 +0100, Igor Gnatenko wrote:
> No, 50 is perfectly fine. As others mentioned, we have much bigger amount of
> them in texlive.
Yeah, I also don't really see a problem in making packages more granular. There
are many usecaseswhere you want that,
such as installation
Your reply completely lacks any point. Why is TeX Live the best example of
what
to avoid when packaging in Fedora?
Having 50+ subpackages is perfectly justified once there is a reason why.
For TeX Live it is that upstream (CTAN) actually maintains package
dependencies and they do add and remove
On Wed, Nov 27, 2019 10:45:00 +, Ian McInerney wrote:
> Tex isn't really the best example for the insane package numbers (since the
> main Tex system, CTAN, actually does define them as separate packages). It
> would be interesting to know if anyone actually does just install one or two
>
Le 2019-11-27 11:45, Ian McInerney a écrit :
Tex isn't really the best example for the insane package numbers
(since the main Tex system, CTAN, actually does define them as
separate packages). It would be interesting to know if anyone actually
does just install one or two rather than all... I
Tex isn't really the best example for the insane package numbers (since the
main Tex system, CTAN, actually does define them as separate packages). It
would be interesting to know if anyone actually does just install one or
two rather than all... I know that I usually just install all of them on
On Wed, Nov 27, 2019 at 10:20 AM Nikos Mavrogiannopoulos
wrote:
>
> I think that from the user perspective that's the best example of what
> to avoid when packaging in Fedora.
Can you please explain what you mean? What are the alternatives if
there really are over 5000 packages in CTAN?
Arch
Le 2019-11-27 10:37, Tom Hughes a écrit :
On 27/11/2019 09:30, Nicolas Mailhot via devel wrote:
The clean way to do it is to put the list of things to generate
against in a spec variable, and write the generator logic in a (lua)
rpm macro. That keeps the generation inside the spec instead of
On 27/11/2019 09:30, Nicolas Mailhot via devel wrote:
The clean way to do it is to put the list of things to generate against
in a spec variable, and write the generator logic in a (lua) rpm macro.
That keeps the generation inside the spec instead of moving some package
creation steps outside
Le 2019-11-27 07:44, Igor Gnatenko a écrit :
No, 50 is perfectly fine. As others mentioned, we have much bigger
amount of them in texlive.
It's not just about the number of subpackages. Each package you publish
will end up as a separate node in the dependency graph.
Since functional plugins
Le 2019-11-27 08:08, Tom Hughes a écrit :
On 27/11/2019 01:49, Chris wrote:
I kind of like the way nagios-plugins breaks apart it's check_scripts
into many sub-packages, but 50+ subpackages seems a bit extreme... or
is it? It certainly seems like a bit of a nightmare to maintain; it
would be
On Wed, Nov 27, 2019 at 4:46 AM Sam Varshavchik wrote:
>
> Chris writes:
>
> > Hi guys,
> >
> >
> > I just wanted to poll you for some advice. My notification tool I maintain
> > supports more than 50+ services now, but the only package isolation I do
>
> You should really count the number of
On 11/27/19 5:45 AM, Sam Varshavchik wrote:
Chris writes:
Hi guys,
I just wanted to poll you for some advice. My notification tool I
maintain supports more than 50+ services now, but the only package
isolation I do
You should really count the number of texlive subpackages…
I would not
On 27/11/2019 01:49, Chris wrote:
I kind of like the way nagios-plugins breaks apart it's check_scripts
into many sub-packages, but 50+ subpackages seems a bit extreme... or is
it? It certainly seems like a bit of a nightmare to maintain; it would
be one very large .spec file.
If the
No, 50 is perfectly fine. As others mentioned, we have much bigger amount
of them in texlive.
If those are like plugins which may or may not require other packages, I
would split them. And probably put Recommends in the main package for the
most used ones.
On Wed, Nov 27, 2019, 02:58 Chris
On 11/26/19 8:34 PM, Sérgio Basto wrote:
On Tue, 2019-11-26 at 20:49 -0500, Chris wrote:
I just wanted to poll you for some advice. My notification tool I
maintain supports more than 50+ services now, but the only package
isolation I do within 2 RPMs. One for the actual CLI (for admin's who
On Tue, 2019-11-26 at 20:49 -0500, Chris wrote:
> Hi guys,
>
> I just wanted to poll you for some advice. My notification tool I
> maintain supports more than 50+ services now, but the only package
> isolation I do within 2 RPMs. One for the actual CLI (for admin's
> who want to use it) and the
\ Original Message
On Nov 26, 2019, 9:45 PM, Sam Varshavchik < mr...@courier-mta.com> wrote:
Chris writes:
> Hi guys,
>
>
> I just wanted to poll you for some advice. My notification tool I maintain
> supports more than 50+ services now, but the only package isolation I
Chris writes:
Hi guys,
I just wanted to poll you for some advice. My notification tool I maintain
supports more than 50+ services now, but the only package isolation I do
You should really count the number of texlive subpackages…
pgpeYylRqybGZ.pgp
Description: PGP signature
26 matches
Mail list logo
