[aur-general] deletion request
please delete chino-preset-default, it ceased to exist as an installable package. https://aur.archlinux.org/packages/chino-preset-default/ thanks.
On 23/02/13 10:04 AM, David Adler wrote:
please delete chino-preset-default, it ceased to exist as an installable package. https://aur.archlinux.org/packages/chino-preset-default/
thanks.
How does it cease to exist? The source link is not broken and the PKGBUILD looks file to me.
On Sat, Feb 23, 2013 at 07:04:08PM +0100, David Adler wrote:
please delete chino-preset-default, it ceased to exist as an installable package. https://aur.archlinux.org/packages/chino-preset-default/
thanks.
can you define ceased to exist ? the website is still up, the downloads are working fine. do you mean this 'default preset' is somthing that needs to be used per user ? and should not globally installed ? -- Ike
On Sat, Feb 23, 2013 at 7:22 PM, Ike Devolder <ike.devolder@gmail.com> wrote:
On Sat, Feb 23, 2013 at 07:04:08PM +0100, David Adler wrote:
please delete chino-preset-default, it ceased to exist as an installable package. https://aur.archlinux.org/packages/chino-preset-default/
thanks.
can you define ceased to exist ?
the website is still up, the downloads are working fine.
do you mean this 'default preset' is somthing that needs to be used per user ? and should not globally installed ?
Sorry for not elaborating in the first place. Yes, it does still exist, as of version 0.16 it's just not installable anymore (configure script/makefiles are gone). It now comes as a tarball for the user to download and to untar to any preferred place. I'm the author of this thingy, and I decided to drop the considerable overhead of maintaining autotools for all those files, which doesn't provide much benefit to the user. To the contrary, having it installed to a not user-writable place might distract from the fact that this example-preset exists to (and often even needs to) be customised. thanks.
On 02/23/2013 08:41 PM, David Adler wrote:
To the contrary, having it installed to a not user-writable place might distract from the fact that this example-preset exists to (and often even needs to) be customised.
If it's just an example, wouldn't it make more sense to just install it to /usr/share for the user to copy it to where he wants it?
On Sat, Feb 23, 2013 at 8:55 PM, Johannes Löthberg <kyrias@archlinux.info> wrote:
On 02/23/2013 08:41 PM, David Adler wrote:
To the contrary, having it installed to a not user-writable place might distract from the fact that this example-preset exists to (and often even needs to) be customised.
If it's just an example, wouldn't it make more sense to just install it to /usr/share for the user to copy it to where he wants it?
That's how it was handled up to now, installed to /usr/share. I'd have to find a way to install an entire directory tree, including lots of files and some empty dirs, without maintaining Makefile.am's and such for every dir. Maybe I'm missing something and there's a simple way to recursively install a directory tree. Despite using google and reading quite a few docs on make and autools I didn't find a simple solution. Pointers are welcome. Installing it to /usr/share as a packed tarball would not give any benefit IMHO. This is sort of an upstream issue. As things are now, I see no way to easily have it installed. If this changes in the future, I'll upload a new package; for now I suggest it be deleted. cheers
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 02/23/2013 09:22 PM, David Adler wrote:
On Sat, Feb 23, 2013 at 8:55 PM, Johannes Löthberg <kyrias@archlinux.info> wrote:
On 02/23/2013 08:41 PM, David Adler wrote:
To the contrary, having it installed to a not user-writable place might distract from the fact that this example-preset exists to (and often even needs to) be customised.
If it's just an example, wouldn't it make more sense to just install it to /usr/share for the user to copy it to where he wants it?
That's how it was handled up to now, installed to /usr/share. I'd have to find a way to install an entire directory tree, including lots of files and some empty dirs, without maintaining Makefile.am's and such for every dir. Maybe I'm missing something and there's a simple way to recursively install a directory tree. Despite using google and reading quite a few docs on make and autools I didn't find a simple solution. Pointers are welcome. Installing it to /usr/share as a packed tarball would not give any benefit IMHO.
This is sort of an upstream issue. As things are now, I see no way to easily have it installed. If this changes in the future, I'll upload a new package; for now I suggest it be deleted.
cheers
Wait, do you need to actually do anything with the files before installing, or does it just copy the files when running make install? - -- Kindest Regards, Johannes Löthberg PGP Key ID: 583664EF Fingerprint: 14FD DCA8 4D41 FF41 78EF DD49 35CA 3661 5836 64EF -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCgAGBQJRKSxtAAoJEDXKNmFYNmTv8akQAOeH7/Ed94M/VbrRPN2dZYS4 7GMNzbuJs6HPsjNCGOyULYtDbLd+R00BzaN3KXaFH6tkwso4U6RqTSekFbYQ1Yku NgFrS30VpFwi9qK63qB8QFnSPG4Ai6mm2JMNxylQ7GUkeRs2n5YrUANjs4inomHN nhRU2oErNoKb9wfXYs2unJPI4pEJRRny+4w3PSyzrRUNRj/sBKMpmFsi521mGTzC 3RgQto21yFYKU71TD4N/RHZO2r0m5eOf5rjPwyDUDocb2gh2dzvhTvvEZVn9mYgr 2SpiPfMb+AKhU6E2Wi/O6HMXEPIMTQjwx84drwYtPwBnT4psGBjOBSxJ3sz9MYd9 opbY/H5EjtojV0dCB0kqNSiMt6i8oxid3PyJZ0Npsss74/A0WtazTIGdTi/iVY68 wJlO6MgoqlUcDas8mElCqhJ20DqddtfImppkXYsN6xWdRK589l/RgkFcSTwz7NSm WGxCoETw9tDLLqIMNxcF0JSR50ArGwI3I8zEVeo3I8gY+JgA/iKNsDMXKKLn0TB9 PjOROKMeeLQbcORkfUg43/xItN12NpgrRBiV1cTbGfewcXCqThxqvHC/wRQU0Du4 z80BYCvEvphgNvMvhy+9xq2AnohbcHjI3gCUd0oBGAJ0uvguJslsi0VqlrBz3aBd UEcYy437KMEGF+G7RucO =eKyi -----END PGP SIGNATURE-----
On Sat, Feb 23, 2013 at 9:54 PM, Johannes Löthberg <kyrias@archlinux.info> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On 02/23/2013 09:22 PM, David Adler wrote:
On Sat, Feb 23, 2013 at 8:55 PM, Johannes Löthberg <kyrias@archlinux.info> wrote:
On 02/23/2013 08:41 PM, David Adler wrote:
To the contrary, having it installed to a not user-writable place might distract from the fact that this example-preset exists to (and often even needs to) be customised.
If it's just an example, wouldn't it make more sense to just install it to /usr/share for the user to copy it to where he wants it?
That's how it was handled up to now, installed to /usr/share. I'd have to find a way to install an entire directory tree, including lots of files and some empty dirs, without maintaining Makefile.am's and such for every dir. Maybe I'm missing something and there's a simple way to recursively install a directory tree. Despite using google and reading quite a few docs on make and autools I didn't find a simple solution. Pointers are welcome. Installing it to /usr/share as a packed tarball would not give any benefit IMHO.
This is sort of an upstream issue. As things are now, I see no way to easily have it installed. If this changes in the future, I'll upload a new package; for now I suggest it be deleted.
cheers
Wait, do you need to actually do anything with the files before installing, or does it just copy the files when running make install?
Just copying. As simple as it sounds, I didn't find a simple solution, but it's not unlikely that I'm missing the obvious. regards
If i get it right, you want to create directories and copy files. Then why not use "install" command? Like; install -d -m 755 $srcdir/foo-version/src/foo.so $pkgdir/usr/lib/foo/foo.so 2013/2/23 David Adler <david.jo.adler@gmail.com>
On Sat, Feb 23, 2013 at 9:54 PM, Johannes Löthberg <kyrias@archlinux.info> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On 02/23/2013 09:22 PM, David Adler wrote:
On Sat, Feb 23, 2013 at 8:55 PM, Johannes Löthberg <kyrias@archlinux.info> wrote:
On 02/23/2013 08:41 PM, David Adler wrote:
To the contrary, having it installed to a not user-writable place might distract from the fact that this example-preset exists to (and often even needs to) be customised.
If it's just an example, wouldn't it make more sense to just install it to /usr/share for the user to copy it to where he wants it?
That's how it was handled up to now, installed to /usr/share. I'd have to find a way to install an entire directory tree, including lots of files and some empty dirs, without maintaining Makefile.am's and such for every dir. Maybe I'm missing something and there's a simple way to recursively install a directory tree. Despite using google and reading quite a few docs on make and autools I didn't find a simple solution. Pointers are welcome. Installing it to /usr/share as a packed tarball would not give any benefit IMHO.
This is sort of an upstream issue. As things are now, I see no way to easily have it installed. If this changes in the future, I'll upload a new package; for now I suggest it be deleted.
cheers
Wait, do you need to actually do anything with the files before installing, or does it just copy the files when running make install?
Just copying. As simple as it sounds, I didn't find a simple solution, but it's not unlikely that I'm missing the obvious.
regards
On 02/23/2013 10:28 PM, atilla ontas wrote:
If i get it right, you want to create directories and copy files. Then why not use "install" command? Like;
install -d -m 755 $srcdir/foo-version/src/foo.so $pkgdir/usr/lib/foo/foo.so
2013/2/23 David Adler <david.jo.adler@gmail.com>
Just copying. As simple as it sounds, I didn't find a simple solution, but it's not unlikely that I'm missing the obvious.
regards
My thoughts exactly.
On Sat, Feb 23, 2013 at 10:40 PM, Johannes Löthberg <kyrias@archlinux.info> wrote:
On 02/23/2013 10:28 PM, atilla ontas wrote:
If i get it right, you want to create directories and copy files. Then why not use "install" command? Like;
install -d -m 755 $srcdir/foo-version/src/foo.so $pkgdir/usr/lib/foo/foo.so
2013/2/23 David Adler <david.jo.adler@gmail.com>
Just copying. As simple as it sounds, I didn't find a simple solution, but it's not unlikely that I'm missing the obvious.
regards
My thoughts exactly.
That would be >400 install invocations for >400 files&dirs? For a similar case, Stackoverflow comes up with solutions involving autotools[1], though I think that would not be worth the effort. For users it is about as simple to download the preset and extract the tarball as it is to first install it and then recursively copy a directory from /usr/share. They'll need the preset in a writable location anyway. Unless there is a really simple one-liner, I don't feel inclined to make that preset an installable tarball again.
From what I read, recursively installing directory trees in a "don't look and just install everything"-manner is not recommended anyway, and all non-recursive sulutions seem to involve some effort to adapt the build system every time the directory tree changes.
[1] http://stackoverflow.com/questions/6395148/install-data-directory-tree-with-... best regards -d
On Sat, Feb 23, 2013 at 11:50:11PM +0100, David Adler wrote:
On Sat, Feb 23, 2013 at 10:40 PM, Johannes Löthberg <kyrias@archlinux.info> wrote:
On 02/23/2013 10:28 PM, atilla ontas wrote:
If i get it right, you want to create directories and copy files. Then why not use "install" command? Like;
install -d -m 755 $srcdir/foo-version/src/foo.so $pkgdir/usr/lib/foo/foo.so
2013/2/23 David Adler <david.jo.adler@gmail.com>
Just copying. As simple as it sounds, I didn't find a simple solution, but it's not unlikely that I'm missing the obvious.
regards
My thoughts exactly.
That would be >400 install invocations for >400 files&dirs?
For a similar case, Stackoverflow comes up with solutions involving autotools[1], though I think that would not be worth the effort.
For users it is about as simple to download the preset and extract the tarball as it is to first install it and then recursively copy a directory from /usr/share. They'll need the preset in a writable location anyway.
Unless there is a really simple one-liner, I don't feel inclined to make that preset an installable tarball again.
From what I read, recursively installing directory trees in a "don't look and just install everything"-manner is not recommended anyway, and all non-recursive sulutions seem to involve some effort to adapt the build system every time the directory tree changes.
[1] http://stackoverflow.com/questions/6395148/install-data-directory-tree-with-...
You know, you could just user /usr/bin/cp -r and some chmod magic if you actually need that. -- William Giokas | KaiSforza GnuPG Key: 0x73CD09CF Fingerprint: F73F 50EF BBE2 9846 8306 E6B8 6902 06D8 73CD 09CF
On Sat, Feb 23, 2013 at 11:53 PM, William Giokas wrote:
On Sat, Feb 23, 2013 at 11:50:11PM +0100, David Adler wrote:
On Sat, Feb 23, 2013 at 10:40 PM, Johannes Löthberg <kyrias@archlinux.info> wrote:
On 02/23/2013 10:28 PM, atilla ontas wrote:
If i get it right, you want to create directories and copy files. Then why not use "install" command? Like;
install -d -m 755 $srcdir/foo-version/src/foo.so $pkgdir/usr/lib/foo/foo.so
2013/2/23 David Adler <david.jo.adler@gmail.com>
Just copying. As simple as it sounds, I didn't find a simple solution, but it's not unlikely that I'm missing the obvious.
regards
My thoughts exactly.
That would be >400 install invocations for >400 files&dirs?
For a similar case, Stackoverflow comes up with solutions involving autotools[1], though I think that would not be worth the effort.
For users it is about as simple to download the preset and extract the tarball as it is to first install it and then recursively copy a directory from /usr/share. They'll need the preset in a writable location anyway.
Unless there is a really simple one-liner, I don't feel inclined to make that preset an installable tarball again.
From what I read, recursively installing directory trees in a "don't look and just install everything"-manner is not recommended anyway, and all non-recursive sulutions seem to involve some effort to adapt the build system every time the directory tree changes.
[1] http://stackoverflow.com/questions/6395148/install-data-directory-tree-with-...
You know, you could just user /usr/bin/cp -r and some chmod magic if you actually need that.
I'd first have to research whether that is a violation of the Arch Packaging Standards. I'd rather see that package deleted. I am the upstream author and, for aforementioned reasons, I don't see any advantage in having that preset installed. Neither from a user's pov nor from a dev's one.
participants (6)
-
atilla ontas
-
Connor Behan
-
David Adler
-
Ike Devolder
-
Johannes Löthberg
-
William Giokas