I am the current maintainer of the AUR package ttf-google-webfonts-hg[4], and I'm bothered by the mess of various packages there are for Google's Web Fonts project. It's not at all KISS in its current state.
There are currently four different AUR packages[1][2][3][4] that essentially supply the same files, and all four packages conflict with each other. Around August of 2012, the package named ttf-google-webfonts[1] was orphaned, and user w0ng created a GitHub repository[5] that mirrors the Mercurial repository[6] on Google Code (why?). Then, the new maintainer changed the original ttf-google-webfonts package from a VCS-type package that simply lacked "-hg" in the name to a package that pulls tarballs from w0ng's GitHub repo[5].
As you can see in the comments for ttf-google-webfonts[1], this has caused all sorts of confusion and messages about the package being out-of-date or having invalid checksums. To get around these issues, user epinephrine created the package ttf-google-webfonts-git[3] that clones w0ng's GitHub repo[5] instead of pulling tarballs from it, which significantly reduces the maintenance required on the package.
Then, user Gently created a package named ttf-google-webfonts-distilled[2] that pulls a tarball from w0ng's GitHub repo[5] and only installs a small subset of the fonts therein.
Shortly after ttf-google-webfonts[1] was changed from being a Mercurial-based package and not liking the direction that the package was taking, I reuploaded the original ttf-google-webfonts package as ttf-google-webfonts-hg[4] for people that simply wanted the old package back that uses the actual Google Web Fonts repository to download the files.
To clean up this mess, I propose that ttf-google-webfonts-distilled[2] and ttf-google-webfonts-git[3] be deleted outright, for what should be obvious reasons. I also propose that ttf-google-webfonts[1] be deleted because of how frequently the Web Fonts project is updated and because the project lacks version numbers. If people really feel strongly about keeping that maintenance nightmare, then let them have it, but I really don't see what advantage it provides over the original ttf-google-webfonts-hg[4] other than one less makedepends.
I apologize for the huge email, but this situation really is a mess.
[1] https://aur.archlinux.org/packages/ttf-google-webfonts/ [2] https://aur.archlinux.org/packages/ttf-google-webfonts-distilled/ [3] https://aur.archlinux.org/packages/ttf-google-webfonts-git/ [4] https://aur.archlinux.org/packages/ttf-google-webfonts-hg/ [5] https://github.com/w0ng/googlefontdirectory [6] https://code.google.com/p/googlefontdirectory/
Jason
On Apr 2, 2013 12:16 AM, "Jason St. John" jstjohn@purdue.edu wrote:
I am the current maintainer of the AUR package ttf-google-webfonts-hg[4], and I'm bothered by the mess of various packages there are for Google's Web Fonts project. It's not at all KISS in its current state.
There are currently four different AUR packages[1][2][3][4] that essentially supply the same files, and all four packages conflict with each other. Around August of 2012, the package named ttf-google-webfonts[1] was orphaned, and user w0ng created a GitHub repository[5] that mirrors the Mercurial repository[6] on Google Code (why?). Then, the new maintainer changed the original ttf-google-webfonts package from a VCS-type package that simply lacked "-hg" in the name to a package that pulls tarballs from w0ng's GitHub repo[5].
As you can see in the comments for ttf-google-webfonts[1], this has caused all sorts of confusion and messages about the package being out-of-date or having invalid checksums. To get around these issues, user epinephrine created the package ttf-google-webfonts-git[3] that clones w0ng's GitHub repo[5] instead of pulling tarballs from it, which significantly reduces the maintenance required on the package.
Then, user Gently created a package named ttf-google-webfonts-distilled[2] that pulls a tarball from w0ng's GitHub repo[5] and only installs a small subset of the fonts therein.
Shortly after ttf-google-webfonts[1] was changed from being a Mercurial-based package and not liking the direction that the package was taking, I reuploaded the original ttf-google-webfonts package as ttf-google-webfonts-hg[4] for people that simply wanted the old package back that uses the actual Google Web Fonts repository to download the files.
To clean up this mess, I propose that ttf-google-webfonts-distilled[2] and ttf-google-webfonts-git[3] be deleted outright, for what should be obvious reasons. I also propose that ttf-google-webfonts[1] be deleted because of how frequently the Web Fonts project is updated and because the project lacks version numbers. If people really feel strongly about keeping that maintenance nightmare, then let them have it, but I really don't see what advantage it provides over the original ttf-google-webfonts-hg[4] other than one less makedepends.
I apologize for the huge email, but this situation really is a mess.
[1] https://aur.archlinux.org/packages/ttf-google-webfonts/ [2] https://aur.archlinux.org/packages/ttf-google-webfonts-distilled/ [3] https://aur.archlinux.org/packages/ttf-google-webfonts-git/ [4] https://aur.archlinux.org/packages/ttf-google-webfonts-hg/ [5] https://github.com/w0ng/googlefontdirectory [6] https://code.google.com/p/googlefontdirectory/
Jason
I mostly agree with you, but I would still keep the git package because I, and I believe most people, don't want to pull 2Gb from the mercurial repo and keep them lying around. This is painfully slow and, even though 2Gb are nothing today, it is silly to waste space like this. The git repo contains only the relevant TTF files and I think it is the better choice for whom wants to download the Google web fonts.
How do others feel about this?
-- Maxime
AFAIK PKGBUILDs can still implement their own VCS downloads in build(), so, why not have it only pull the relevant paths? A quick google gave me [1], you get the idea...
cheers! mar77i
[1] http://stackoverflow.com/questions/50945/can-you-do-a-partial-checkout-with-...
On Thu, 2013-04-04 at 08:42 +0200, Martti Kühne wrote:
AFAIK PKGBUILDs can still implement their own VCS downloads in build(), so, why not have it only pull the relevant paths? A quick google gave me [1], you get the idea...
cheers! mar77i
[1] http://stackoverflow.com/questions/50945/can-you-do-a-partial-checkout-with-...
Execpt, google-webfonts uses Mercurial which afaict does not allow that [1]. Even doing a partial clone with a specified depth would be pointless as TTF files are together with a bunch of other files in their directories. The hg package is relevant for those who want to clone the whole repo, not just the TTF files, and the git package is best for those who only want the fonts. It seems there is a tool named ConvertExtension which is mentioned in [1], this could be used to only pull the TTF from the hg repo, but this process wouldn't allow for incremental updates like git.
[1] http://mercurial.selenic.com/wiki/PartialClone
-- Maxime
On 04/04/2013 05:15 AM, Alucryd wrote:
On Thu, 2013-04-04 at 08:42 +0200, Martti Kühne wrote:
AFAIK PKGBUILDs can still implement their own VCS downloads in build(), so, why not have it only pull the relevant paths? A quick google gave me [1], you get the idea...
cheers! mar77i
[1] http://stackoverflow.com/questions/50945/can-you-do-a-partial-checkout-with-...
Execpt, google-webfonts uses Mercurial which afaict does not allow that [1]. Even doing a partial clone with a specified depth would be pointless as TTF files are together with a bunch of other files in their directories. The hg package is relevant for those who want to clone the whole repo, not just the TTF files, and the git package is best for those who only want the fonts. It seems there is a tool named ConvertExtension which is mentioned in [1], this could be used to only pull the TTF from the hg repo, but this process wouldn't allow for incremental updates like git.
[1] http://mercurial.selenic.com/wiki/PartialClone
-- Maxime
Yeah; not only does mercurial not allow it now, the associated bug report is marked WONTFIX [2]. Still, those other packages (besides -git, -hg) are redundant.
On Tue, Apr 2, 2013 at 12:59 AM, Maxime GAUDUIN alucryd@gmail.com wrote:
I mostly agree with you, but I would still keep the git package because I, and I believe most people, don't want to pull 2Gb from the mercurial repo and keep them lying around. This is painfully slow and, even though 2Gb are nothing today, it is silly to waste space like this. The git repo contains only the relevant TTF files and I think it is the better choice for whom wants to download the Google web fonts.
How do others feel about this?
I totally agree with this.
Regards, Marcel
On Sun, Apr 7, 2013 at 10:55 PM, Marcel Korpel marcel.lists@gmail.comwrote:
On Tue, Apr 2, 2013 at 12:59 AM, Maxime GAUDUIN alucryd@gmail.com wrote:
I mostly agree with you, but I would still keep the git package because
I,
and I believe most people, don't want to pull 2Gb from the mercurial repo and keep them lying around. This is painfully slow and, even though 2Gb
are
nothing today, it is silly to waste space like this. The git repo
contains
only the relevant TTF files and I think it is the better choice for whom wants to download the Google web fonts.
How do others feel about this?
I totally agree with this.
Regards, Marcel
Okay, the only remaining webfonts packages in AUR are now ttf-google-webfonts-git and ttf-google-webfonts-hg.
Cheers.
On Sun, Apr 7, 2013 at 5:11 PM, Maxime GAUDUIN alucryd@gmail.com wrote:
On Sun, Apr 7, 2013 at 10:55 PM, Marcel Korpel marcel.lists@gmail.comwrote:
On Tue, Apr 2, 2013 at 12:59 AM, Maxime GAUDUIN alucryd@gmail.com wrote:
I mostly agree with you, but I would still keep the git package because
I,
and I believe most people, don't want to pull 2Gb from the mercurial repo and keep them lying around. This is painfully slow and, even though 2Gb
are
nothing today, it is silly to waste space like this. The git repo
contains
only the relevant TTF files and I think it is the better choice for whom wants to download the Google web fonts.
How do others feel about this?
I totally agree with this.
Regards, Marcel
Okay, the only remaining webfonts packages in AUR are now ttf-google-webfonts-git and ttf-google-webfonts-hg.
Cheers.
Maxime
Thank you.
For those curious, I compared the disk usage of both the -git and -hg packages on my system.
ttf-google-webfonts-git uses 459 MiB. ttf-google-webfonts-hg uses 2.6 GiB.
To make things less ambiguous, I am going to alter the pkgdesc for my package to clarify why we have both a -git and -hg version. I CC'd the maintainer of the -git version.
Jason
On Sun, Apr 7, 2013 at 5:11 PM, Maxime GAUDUIN alucryd@gmail.com wrote:
On Sun, Apr 7, 2013 at 10:55 PM, Marcel Korpel marcel.lists@gmail.comwrote:
On Tue, Apr 2, 2013 at 12:59 AM, Maxime GAUDUIN alucryd@gmail.com wrote:
I mostly agree with you, but I would still keep the git package because
I,
and I believe most people, don't want to pull 2Gb from the mercurial repo and keep them lying around. This is painfully slow and, even though 2Gb
are
nothing today, it is silly to waste space like this. The git repo
contains
only the relevant TTF files and I think it is the better choice for whom wants to download the Google web fonts.
How do others feel about this?
I totally agree with this.
Regards, Marcel
Okay, the only remaining webfonts packages in AUR are now ttf-google-webfonts-git and ttf-google-webfonts-hg.
Cheers.
Maxime
I noticed that a new package named ttf-google-webfonts-tarball [1] was uploaded yesterday.
The submitter of the package states, "This is for all those who use simple AUR helpers, e.g. cower, that need a version number to know that there's been an update and/or those who don't like the git/hg repos just hanging around on their systems (i.e. those who delete their AUR sources and packages)."
Do the TUs feel that this package is necessary? It suffers from the same problem of frequent and endless maintenance that ttf-google-webfonts did that I mentioned in my first email in this thread.
[1] https://aur.archlinux.org/packages/ttf-google-webfonts-tarball/
Jason
On Wed, Apr 24, 2013 at 10:28 PM, Jason St. John jstjohn@purdue.edu wrote:
On Sun, Apr 7, 2013 at 5:11 PM, Maxime GAUDUIN alucryd@gmail.com wrote:
On Sun, Apr 7, 2013 at 10:55 PM, Marcel Korpel marcel.lists@gmail.comwrote:
On Tue, Apr 2, 2013 at 12:59 AM, Maxime GAUDUIN alucryd@gmail.com wrote:
I mostly agree with you, but I would still keep the git package because
I,
and I believe most people, don't want to pull 2Gb from the mercurial repo and keep them lying around. This is painfully slow and, even though 2Gb
are
nothing today, it is silly to waste space like this. The git repo
contains
only the relevant TTF files and I think it is the better choice for whom wants to download the Google web fonts.
How do others feel about this?
I totally agree with this.
Regards, Marcel
Okay, the only remaining webfonts packages in AUR are now ttf-google-webfonts-git and ttf-google-webfonts-hg.
Cheers.
Maxime
I noticed that a new package named ttf-google-webfonts-tarball [1] was uploaded yesterday.
The submitter of the package states, "This is for all those who use simple AUR helpers, e.g. cower, that need a version number to know that there's been an update and/or those who don't like the git/hg repos just hanging around on their systems (i.e. those who delete their AUR sources and packages)."
Do the TUs feel that this package is necessary? It suffers from the same problem of frequent and endless maintenance that ttf-google-webfonts did that I mentioned in my first email in this thread.
[1] https://aur.archlinux.org/packages/ttf-google-webfonts-tarball/
Jason
I don't feel like this is at all necessary. The AUR helper part is definitely a non-issue because bumping the pkgver on a VCS package with a proper pkgver function works just fine.
The package should be called Google fonts, not webfonts, like https://aur.archlinux.org/packages/ttf-google-fonts-hg/
http://googlewebfonts.blogspot.com/2013/04/a-new-look-and-name-for-google-we... "This week, Google Web Fonts got a simpler, cleaner look that makes searching and accessing your fonts easier than ever. And in the spirit of simplicity, today Google Web Fonts is now just “Google Fonts.” It’s still the same great collection of free fonts you know and love, but with a new name."
On Wed, Apr 24, 2013 at 10:32:36PM -0400, Daniel Micay wrote:
On Wed, Apr 24, 2013 at 10:28 PM, Jason St. John jstjohn@purdue.edu wrote:
On Sun, Apr 7, 2013 at 5:11 PM, Maxime GAUDUIN alucryd@gmail.com wrote:
On Sun, Apr 7, 2013 at 10:55 PM, Marcel Korpel marcel.lists@gmail.comwrote:
On Tue, Apr 2, 2013 at 12:59 AM, Maxime GAUDUIN alucryd@gmail.com wrote:
I mostly agree with you, but I would still keep the git package because
I,
and I believe most people, don't want to pull 2Gb from the mercurial repo and keep them lying around. This is painfully slow and, even though 2Gb
are
nothing today, it is silly to waste space like this. The git repo
contains
only the relevant TTF files and I think it is the better choice for whom wants to download the Google web fonts.
How do others feel about this?
I totally agree with this.
Regards, Marcel
Okay, the only remaining webfonts packages in AUR are now ttf-google-webfonts-git and ttf-google-webfonts-hg.
Cheers.
Maxime
I noticed that a new package named ttf-google-webfonts-tarball [1] was uploaded yesterday.
The submitter of the package states, "This is for all those who use simple AUR helpers, e.g. cower, that need a version number to know that there's been an update and/or those who don't like the git/hg repos just hanging around on their systems (i.e. those who delete their AUR sources and packages)."
Do the TUs feel that this package is necessary? It suffers from the same problem of frequent and endless maintenance that ttf-google-webfonts did that I mentioned in my first email in this thread.
[1] https://aur.archlinux.org/packages/ttf-google-webfonts-tarball/
Jason
I don't feel like this is at all necessary. The AUR helper part is definitely a non-issue because bumping the pkgver on a VCS package with a proper pkgver function works just fine.
I created it for those of us who need it. If you use yaourt (which many a TU would attempt to dissuade you from doing), it may work, but for others of us, it does not. No one's asking you to use it, but it should be an option, IMHO.
As to the "AUR helper part [being] definitely a non-issue," that's demonstrably wrong. Either ttf-google-webfonts-git's PKGBUILD suffers from a lack of "a proper pkgver function," or something more than such a function is required for certain AUR helpers to recognize that an update is needed, as the April 14 updates to the repo were not enough for cower to pick up on the new version. A review of the source code makes it clear that at least certain AUR helpers will not be able to handle the pkgver function route as currently implemented.
On Thu, Apr 25, 2013 at 9:24 AM, David J. Haines djhaines@gmx.com wrote:
On Wed, Apr 24, 2013 at 10:32:36PM -0400, Daniel Micay wrote:
On Wed, Apr 24, 2013 at 10:28 PM, Jason St. John jstjohn@purdue.edu wrote:
On Sun, Apr 7, 2013 at 5:11 PM, Maxime GAUDUIN alucryd@gmail.com wrote:
On Sun, Apr 7, 2013 at 10:55 PM, Marcel Korpel marcel.lists@gmail.comwrote:
On Tue, Apr 2, 2013 at 12:59 AM, Maxime GAUDUIN alucryd@gmail.com wrote:
I mostly agree with you, but I would still keep the git package because
I,
and I believe most people, don't want to pull 2Gb from the mercurial repo and keep them lying around. This is painfully slow and, even though 2Gb
are
nothing today, it is silly to waste space like this. The git repo
contains
only the relevant TTF files and I think it is the better choice for whom wants to download the Google web fonts.
How do others feel about this?
I totally agree with this.
Regards, Marcel
Okay, the only remaining webfonts packages in AUR are now ttf-google-webfonts-git and ttf-google-webfonts-hg.
Cheers.
Maxime
I noticed that a new package named ttf-google-webfonts-tarball [1] was uploaded yesterday.
The submitter of the package states, "This is for all those who use simple AUR helpers, e.g. cower, that need a version number to know that there's been an update and/or those who don't like the git/hg repos just hanging around on their systems (i.e. those who delete their AUR sources and packages)."
Do the TUs feel that this package is necessary? It suffers from the same problem of frequent and endless maintenance that ttf-google-webfonts did that I mentioned in my first email in this thread.
[1] https://aur.archlinux.org/packages/ttf-google-webfonts-tarball/
Jason
I don't feel like this is at all necessary. The AUR helper part is definitely a non-issue because bumping the pkgver on a VCS package with a proper pkgver function works just fine.
I created it for those of us who need it. If you use yaourt (which many a TU would attempt to dissuade you from doing), it may work, but for others of us, it does not. No one's asking you to use it, but it should be an option, IMHO.
As to the "AUR helper part [being] definitely a non-issue," that's demonstrably wrong. Either ttf-google-webfonts-git's PKGBUILD suffers from a lack of "a proper pkgver function," or something more than such a function is required for certain AUR helpers to recognize that an update is needed, as the April 14 updates to the repo were not enough for cower to pick up on the new version. A review of the source code makes it clear that at least certain AUR helpers will not be able to handle the pkgver function route as currently implemented.
-- David J. Haines djhaines@gmx.com
The version on the tarball PKGBUILD is updating when you upload a new one. The version on the VCS package is uploading when the maintainer re-uploads it. It's not relevant to whether a tarball package is useful.
On Thu, Apr 25, 2013 at 10:07:16AM -0400, Daniel Micay wrote:
On Thu, Apr 25, 2013 at 9:24 AM, David J. Haines djhaines@gmx.com wrote:
On Wed, Apr 24, 2013 at 10:32:36PM -0400, Daniel Micay wrote:
On Wed, Apr 24, 2013 at 10:28 PM, Jason St. John jstjohn@purdue.edu wrote:
On Sun, Apr 7, 2013 at 5:11 PM, Maxime GAUDUIN alucryd@gmail.com wrote:
On Sun, Apr 7, 2013 at 10:55 PM, Marcel Korpel marcel.lists@gmail.comwrote:
On Tue, Apr 2, 2013 at 12:59 AM, Maxime GAUDUIN alucryd@gmail.com wrote: > I mostly agree with you, but I would still keep the git package because I, > and I believe most people, don't want to pull 2Gb from the mercurial repo > and keep them lying around. This is painfully slow and, even though 2Gb are > nothing today, it is silly to waste space like this. The git repo contains > only the relevant TTF files and I think it is the better choice for whom > wants to download the Google web fonts. > > How do others feel about this?
I totally agree with this.
Regards, Marcel
Okay, the only remaining webfonts packages in AUR are now ttf-google-webfonts-git and ttf-google-webfonts-hg.
Cheers.
Maxime
I noticed that a new package named ttf-google-webfonts-tarball [1] was uploaded yesterday.
The submitter of the package states, "This is for all those who use simple AUR helpers, e.g. cower, that need a version number to know that there's been an update and/or those who don't like the git/hg repos just hanging around on their systems (i.e. those who delete their AUR sources and packages)."
Do the TUs feel that this package is necessary? It suffers from the same problem of frequent and endless maintenance that ttf-google-webfonts did that I mentioned in my first email in this thread.
[1] https://aur.archlinux.org/packages/ttf-google-webfonts-tarball/
Jason
I don't feel like this is at all necessary. The AUR helper part is definitely a non-issue because bumping the pkgver on a VCS package with a proper pkgver function works just fine.
I created it for those of us who need it. If you use yaourt (which many a TU would attempt to dissuade you from doing), it may work, but for others of us, it does not. No one's asking you to use it, but it should be an option, IMHO.
As to the "AUR helper part [being] definitely a non-issue," that's demonstrably wrong. Either ttf-google-webfonts-git's PKGBUILD suffers from a lack of "a proper pkgver function," or something more than such a function is required for certain AUR helpers to recognize that an update is needed, as the April 14 updates to the repo were not enough for cower to pick up on the new version. A review of the source code makes it clear that at least certain AUR helpers will not be able to handle the pkgver function route as currently implemented.
-- David J. Haines djhaines@gmx.com
The version on the tarball PKGBUILD is updating when you upload a new one. The version on the VCS package is uploading when the maintainer re-uploads it. It's not relevant to whether a tarball package is useful.
So, then the solution is for the -git maintainer to update / re-upload the PKGBUILD whenever there's a "version" bump to the git repo?
So, then the solution is for the -git maintainer to update / re-upload the PKGBUILD whenever there's a "version" bump to the git repo? -- David J. Haines djhaines@gmx.com
No, the solution is for the users of the -git package to track upstream changes and re-compile the package as and when they see fit.
On Thu, 25 Apr 2013 16:04:12 +0100 WorMzy Tykashi wormzy.tykashi@gmail.com wrote:
So, then the solution is for the -git maintainer to update / re-upload the PKGBUILD whenever there's a "version" bump to the git repo? -- David J. Haines djhaines@gmx.com
No, the solution is for the users of the -git package to track upstream changes and re-compile the package as and when they see fit.
As it is for all -git (and -svn and -hg, etc) packages. As it should be, IMHO.
On Thu, Apr 25, 2013 at 11:17:36AM -0400, Jonathan Arnold wrote:
On Thu, 25 Apr 2013 16:04:12 +0100 WorMzy Tykashi wormzy.tykashi@gmail.com wrote:
So, then the solution is for the -git maintainer to update / re-upload the PKGBUILD whenever there's a "version" bump to the git repo? -- David J. Haines djhaines@gmx.com
No, the solution is for the users of the -git package to track upstream changes and re-compile the package as and when they see fit.
As it is for all -git (and -svn and -hg, etc) packages. As it should be, IMHO.
-- Jonathan Arnold Webstream: http://hieronymus.soup.io
Talent wins games, but team work and intelligence wins championships. Michael Jordan
Thus the utility of the -tarball PKGBUILD: users don't have to track it; they can rely on the maintainer.
On Thu, Apr 25, 2013 at 5:31 PM, David J. Haines djhaines@gmx.com wrote:
On Thu, Apr 25, 2013 at 11:17:36AM -0400, Jonathan Arnold wrote:
On Thu, 25 Apr 2013 16:04:12 +0100 WorMzy Tykashi wormzy.tykashi@gmail.com wrote:
So, then the solution is for the -git maintainer to update / re-upload the PKGBUILD whenever there's a "version" bump to the git repo? -- David J. Haines djhaines@gmx.com
No, the solution is for the users of the -git package to track upstream changes and re-compile the package as and when they see fit.
As it is for all -git (and -svn and -hg, etc) packages. As it should be, IMHO.
-- Jonathan Arnold Webstream: http://hieronymus.soup.io
Talent wins games, but team work and intelligence wins championships. Michael Jordan
Thus the utility of the -tarball PKGBUILD: users don't have to track it; they can rely on the maintainer. -- David J. Haines djhaines@gmx.com
Such a thing is only true when using AUR helpers, which, again, are not supported. Even as a helper user, I don't think the -tarball package is needed.
Cheers,
On 25 April 2013 17:15, Maxime GAUDUIN alucryd@gmail.com wrote:
On Thu, Apr 25, 2013 at 5:31 PM, David J. Haines djhaines@gmx.com wrote:
On Thu, Apr 25, 2013 at 11:17:36AM -0400, Jonathan Arnold wrote:
On Thu, 25 Apr 2013 16:04:12 +0100 WorMzy Tykashi wormzy.tykashi@gmail.com wrote:
So, then the solution is for the -git maintainer to update / re-upload the PKGBUILD whenever there's a "version" bump to the git repo?
No, the solution is for the users of the -git package to track upstream changes and re-compile the package as and when they see fit.
As it is for all -git (and -svn and -hg, etc) packages. As it should be, IMHO.
Thus the utility of the -tarball PKGBUILD: users don't have to track it; they can rely on the maintainer.
Such a thing is only true when using AUR helpers, which, again, are not supported. Even as a helper user, I don't think the -tarball package is needed.
As user of AUR, I agree. I'm slowly getting sick of the AUR mess and spread of duplicate packages motivated by some narrow corner cases and customisation. Either makepkg and PKGBUILD is enhanced to properly support the development kind of packages, namely *-{git|hg|svn} and perform actual update of local copy of sources (even if PKGBUILD has not been updated) or users have to accept the fact they play with cutting-edge version of software so they take care of updates it on their own.
Stop AUR insanity!
Best regards,
On Thu, Apr 25, 2013 at 12:35 PM, Mateusz Loskot mateusz@loskot.net wrote:
On 25 April 2013 17:15, Maxime GAUDUIN alucryd@gmail.com wrote:
On Thu, Apr 25, 2013 at 5:31 PM, David J. Haines djhaines@gmx.com wrote:
On Thu, Apr 25, 2013 at 11:17:36AM -0400, Jonathan Arnold wrote:
On Thu, 25 Apr 2013 16:04:12 +0100 WorMzy Tykashi wormzy.tykashi@gmail.com wrote:
So, then the solution is for the -git maintainer to update / re-upload the PKGBUILD whenever there's a "version" bump to the git repo?
No, the solution is for the users of the -git package to track upstream changes and re-compile the package as and when they see fit.
As it is for all -git (and -svn and -hg, etc) packages. As it should be, IMHO.
Thus the utility of the -tarball PKGBUILD: users don't have to track it; they can rely on the maintainer.
Such a thing is only true when using AUR helpers, which, again, are not supported. Even as a helper user, I don't think the -tarball package is needed.
As user of AUR, I agree. I'm slowly getting sick of the AUR mess and spread of duplicate packages motivated by some narrow corner cases and customisation. Either makepkg and PKGBUILD is enhanced to properly support the development kind of packages, namely *-{git|hg|svn} and perform actual update of local copy of sources (even if PKGBUILD has not been updated) or users have to accept the fact they play with cutting-edge version of software so they take care of updates it on their own.
Stop AUR insanity!
Best regards,
Mateusz Loskot, http://mateusz.loskot.net
makepkg has full support for VCS packages now, it runs the pkgver function to check for a new version and then updates/rebuilds. It even knows how to fetch the sources automatically.
On Thu, Apr 25, 2013 at 01:01:37PM -0400, Daniel Micay wrote:
On Thu, Apr 25, 2013 at 12:35 PM, Mateusz Loskot mateusz@loskot.net wrote:
On 25 April 2013 17:15, Maxime GAUDUIN alucryd@gmail.com wrote:
On Thu, Apr 25, 2013 at 5:31 PM, David J. Haines djhaines@gmx.com wrote:
On Thu, Apr 25, 2013 at 11:17:36AM -0400, Jonathan Arnold wrote:
On Thu, 25 Apr 2013 16:04:12 +0100 WorMzy Tykashi wormzy.tykashi@gmail.com wrote:
> So, then the solution is for the -git maintainer to update / > re-upload the PKGBUILD whenever there's a "version" bump to the git > repo? >
No, the solution is for the users of the -git package to track upstream changes and re-compile the package as and when they see fit.
As it is for all -git (and -svn and -hg, etc) packages. As it should be, IMHO.
Thus the utility of the -tarball PKGBUILD: users don't have to track it; they can rely on the maintainer.
Such a thing is only true when using AUR helpers, which, again, are not supported. Even as a helper user, I don't think the -tarball package is needed.
As user of AUR, I agree. I'm slowly getting sick of the AUR mess and spread of duplicate packages motivated by some narrow corner cases and customisation. Either makepkg and PKGBUILD is enhanced to properly support the development kind of packages, namely *-{git|hg|svn} and perform actual update of local copy of sources (even if PKGBUILD has not been updated) or users have to accept the fact they play with cutting-edge version of software so they take care of updates it on their own.
Stop AUR insanity!
Best regards,
Mateusz Loskot, http://mateusz.loskot.net
makepkg has full support for VCS packages now, it runs the pkgver function to check for a new version and then updates/rebuilds. It even knows how to fetch the sources automatically.
Well until PKGBUILD and the AUR report versions correctly, I'd want to see the -tarball variant (and others like it) stick around. That's my two cents.
On Thu, Apr 25, 2013 at 3:10 PM, David J. Haines djhaines@gmx.com wrote:
On Thu, Apr 25, 2013 at 01:01:37PM -0400, Daniel Micay wrote:
On Thu, Apr 25, 2013 at 12:35 PM, Mateusz Loskot mateusz@loskot.net wrote:
On 25 April 2013 17:15, Maxime GAUDUIN alucryd@gmail.com wrote:
On Thu, Apr 25, 2013 at 5:31 PM, David J. Haines djhaines@gmx.com wrote:
On Thu, Apr 25, 2013 at 11:17:36AM -0400, Jonathan Arnold wrote:
On Thu, 25 Apr 2013 16:04:12 +0100 WorMzy Tykashi wormzy.tykashi@gmail.com wrote:
> > So, then the solution is for the -git maintainer to update / > > re-upload the PKGBUILD whenever there's a "version" bump to the git > > repo? > > > > No, the solution is for the users of the -git package to track > upstream changes and re-compile the package as and when they see fit.
As it is for all -git (and -svn and -hg, etc) packages. As it should be, IMHO.
Thus the utility of the -tarball PKGBUILD: users don't have to track it; they can rely on the maintainer.
Such a thing is only true when using AUR helpers, which, again, are not supported. Even as a helper user, I don't think the -tarball package is needed.
As user of AUR, I agree. I'm slowly getting sick of the AUR mess and spread of duplicate packages motivated by some narrow corner cases and customisation. Either makepkg and PKGBUILD is enhanced to properly support the development kind of packages, namely *-{git|hg|svn} and perform actual update of local copy of sources (even if PKGBUILD has not been updated) or users have to accept the fact they play with cutting-edge version of software so they take care of updates it on their own.
Stop AUR insanity!
Best regards,
Mateusz Loskot, http://mateusz.loskot.net
makepkg has full support for VCS packages now, it runs the pkgver function to check for a new version and then updates/rebuilds. It even knows how to fetch the sources automatically.
Well until PKGBUILD and the AUR report versions correctly, I'd want to see the -tarball variant (and others like it) stick around. That's my two cents. -- David J. Haines djhaines@gmx.com
A tarball does not have the version reported any more correctly. The AUR reports the version set as pkgver which is just set when the maintainer builds the package and re-uploads, if there's a pkgver function. There's no relevance of a tarball vs. VCS when it comes to the reported pkgver.
On Tue, Apr 2, 2013 at 12:16 AM, Jason St. John jstjohn@purdue.edu wrote:
I am the current maintainer of the AUR package ttf-google-webfonts-hg[4], and I'm bothered by the mess of various packages there are for Google's Web Fonts project. It's not at all KISS in its current state.
There are currently four different AUR packages[1][2][3][4] that essentially supply the same files, and all four packages conflict with each other. Around August of 2012, the package named ttf-google-webfonts[1] was orphaned, and user w0ng created a GitHub repository[5] that mirrors the Mercurial repository[6] on Google Code (why?). Then, the new maintainer changed the original ttf-google-webfonts package from a VCS-type package that simply lacked "-hg" in the name to a package that pulls tarballs from w0ng's GitHub repo[5].
As you can see in the comments for ttf-google-webfonts[1], this has caused all sorts of confusion and messages about the package being out-of-date or having invalid checksums. To get around these issues, user epinephrine created the package ttf-google-webfonts-git[3] that clones w0ng's GitHub repo[5] instead of pulling tarballs from it, which significantly reduces the maintenance required on the package.
Then, user Gently created a package named ttf-google-webfonts-distilled[2] that pulls a tarball from w0ng's GitHub repo[5] and only installs a small subset of the fonts therein.
Shortly after ttf-google-webfonts[1] was changed from being a Mercurial-based package and not liking the direction that the package was taking, I reuploaded the original ttf-google-webfonts package as ttf-google-webfonts-hg[4] for people that simply wanted the old package back that uses the actual Google Web Fonts repository to download the files.
To clean up this mess, I propose that ttf-google-webfonts-distilled[2] and ttf-google-webfonts-git[3] be deleted outright, for what should be obvious reasons. I also propose that ttf-google-webfonts[1] be deleted because of how frequently the Web Fonts project is updated and because the project lacks version numbers. If people really feel strongly about keeping that maintenance nightmare, then let them have it, but I really don't see what advantage it provides over the original ttf-google-webfonts-hg[4] other than one less makedepends.
I apologize for the huge email, but this situation really is a mess.
[1] https://aur.archlinux.org/packages/ttf-google-webfonts/ [2] https://aur.archlinux.org/packages/ttf-google-webfonts-distilled/ [3] https://aur.archlinux.org/packages/ttf-google-webfonts-git/ [4] https://aur.archlinux.org/packages/ttf-google-webfonts-hg/ [5] https://github.com/w0ng/googlefontdirectory [6] https://code.google.com/p/googlefontdirectory/
Jason
I totally agree with you. All the other packages are useless and should be nuked. Also, they rely on an unofficial mirror.
+1
-- Alessio
thanks for sharing
----- supports phone number -- Sent from: http://archlinux.2023198.n4.nabble.com/tur-users-f2040002.html
aur-general@lists.archlinux.org