Github messages for voidlinux
 help / color / mirror / Atom feed
* [ISSUE] gifsicle vs. Gifsicle
@ 2021-05-04 17:02 kwshi
  2021-05-04 17:47 ` ericonr
  2021-11-04  7:50 ` [ISSUE] [CLOSED] " Johnnynator
  0 siblings, 2 replies; 3+ messages in thread
From: kwshi @ 2021-05-04 17:02 UTC (permalink / raw)
  To: ml

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

New issue by kwshi on void-packages repository

https://github.com/void-linux/void-packages/issues/30677

Description:
Currently the void-packages repo contains two _different_ packages named `gifsicle` (previously maintained by @pullmoll, now [orphaned](https://github.com/void-linux/void-packages/commit/f40cd776860a478ea987274897e9d64e7b44ea3e)) and `Gifsicle` (maintained by @ColdPhoenix00).  That's a little bit confusing, and it's unclear, at first glance, why there are two separate packages for it and which one I should install.

Closer inspection w/ `xbps-query -Rf` and `xbps-query -R` reveals that `Gifsicle` provides an additional (GUI) executable named `gifview` and has an additional dependency on `libX11`.  Both packages are otherwise the same (both provide `gifdiff` and `gifsicle`, along with their manpages).

I believe, for clarity's sake, these two packages should be reorganized/disambiguated somehow.  I propose one of the following options:
1. Rename `Gifsicle` to `gifsicle-gui` to indicate its additional X dependency & the fact that it installs a GUI program (whereas plain `gifsicle` does not).
2. Rename `Gifsicle` to `gifsicle-gifview`, and remove the `gifdiff` and `gifsicle` binaries from that package, so that only `gifview` is provided by `gifsicle-gifview`.  Maybe make `gifsicle-gifview` depend on `gifsicle`.  This option avoids duplicating providers for `/usr/bin/gifdiff` and `/usr/bin/gifsicle`; this way, `gifsicle-gifview` is an _add-on_ rather than an alternative/conflict to plain `gifsicle`.
3. Remove either `Gifsicle` or `gifsicle`.  The downside to this is that
   - if we remove `Gifsicle`, then there will be no way to install `gifview`;
   - if we remove `gifsicle`, then users will be forced to install `gifview` (together with its libX11 dependency) no matter what.  Perhaps this option is acceptable, but it depends on what y'all think.



^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: gifsicle vs. Gifsicle
  2021-05-04 17:02 [ISSUE] gifsicle vs. Gifsicle kwshi
@ 2021-05-04 17:47 ` ericonr
  2021-11-04  7:50 ` [ISSUE] [CLOSED] " Johnnynator
  1 sibling, 0 replies; 3+ messages in thread
From: ericonr @ 2021-05-04 17:47 UTC (permalink / raw)
  To: ml

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

New comment by ericonr on void-packages repository

https://github.com/void-linux/void-packages/issues/30677#issuecomment-832125891

Comment:
I'd join the two packages together (make one a transitional dummy to the other), and always carry `gifview`. Most image manipulation programs depend on `libX11` in some way already, so this won't bring additional dependencies to most people (and that's assuming those people were manipulating images on a headless server rather than a graphical system).

Moving to `gifsicle` as the main one is reasonable because it's what the tarball is named, but then most of the template from `Gifsicle` should be preferred, because it uses a pre-processed tarball and doesn't need `autoreconf`.

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [ISSUE] [CLOSED] gifsicle vs. Gifsicle
  2021-05-04 17:02 [ISSUE] gifsicle vs. Gifsicle kwshi
  2021-05-04 17:47 ` ericonr
@ 2021-11-04  7:50 ` Johnnynator
  1 sibling, 0 replies; 3+ messages in thread
From: Johnnynator @ 2021-11-04  7:50 UTC (permalink / raw)
  To: ml

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

Closed issue by kwshi on void-packages repository

https://github.com/void-linux/void-packages/issues/30677

Description:
Currently the void-packages repo contains two _different_ packages named `gifsicle` (previously maintained by @pullmoll, now [orphaned](https://github.com/void-linux/void-packages/commit/f40cd776860a478ea987274897e9d64e7b44ea3e)) and `Gifsicle` (maintained by @ColdPhoenix00).  That's a little bit confusing, and it's unclear, at first glance, why there are two separate packages for it and which one I should install.

Closer inspection w/ `xbps-query -Rf` and `xbps-query -R` reveals that `Gifsicle` provides an additional (GUI) executable named `gifview` and has an additional dependency on `libX11`.  Both packages are otherwise the same (both provide `gifdiff` and `gifsicle`, along with their manpages).

I believe, for clarity's sake, these two packages should be reorganized/disambiguated somehow.  I propose one of the following options:
1. Rename `Gifsicle` to `gifsicle-gui` to indicate its additional X dependency & the fact that it installs a GUI program (whereas plain `gifsicle` does not).
2. Rename `Gifsicle` to `gifsicle-gifview`, and remove the `gifdiff` and `gifsicle` binaries from that package, so that only `gifview` is provided by `gifsicle-gifview`.  Maybe make `gifsicle-gifview` depend on `gifsicle`.  This option avoids duplicating providers for `/usr/bin/gifdiff` and `/usr/bin/gifsicle`; this way, `gifsicle-gifview` is an _add-on_ rather than an alternative/conflict to plain `gifsicle`.
3. Remove either `Gifsicle` or `gifsicle`.  The downside to this is that
   - if we remove `Gifsicle`, then there will be no way to install `gifview`;
   - if we remove `gifsicle`, then users will be forced to install `gifview` (together with its libX11 dependency) no matter what.  Perhaps this option is acceptable, but it depends on what y'all think.



^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2021-11-04  7:50 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-05-04 17:02 [ISSUE] gifsicle vs. Gifsicle kwshi
2021-05-04 17:47 ` ericonr
2021-11-04  7:50 ` [ISSUE] [CLOSED] " Johnnynator

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).