[pacman-dev] Linking to OpenSSL
Hi, I have been working on an Arch fork for the past several months, and thus have been following Arch developments closely. I noticed this commit ( http://projects.archlinux.org/gitweb.cgi?p=pacman.git;a=commit;h=b8a66d68593d1f267c3bb8cd8943724711626903 ), where OpenSSL replaces the usage of md5sum and sha1sum utilities for Pacman. While I like the idea of using libraries instead of external binaries, I feel that linking to OpenSSL complicates a few things. For one, it is big, and must be included with any non-static binaries of Pacman (in the installer, this would not be so ideal, unless OpenSSL is included anyways). Another, is that it is simply not legal under the GPL. OpenSSL includes an advertising clause that makes it incompatible with the GPL. Wget and climm had to modify their GPL licenses to link to it ( http://en.wikipedia.org/wiki/Openssl#Licensing ). I purpose using GNUTLS instead. It is released under the LGPLv2.1, should be fully capable, and is compatible with the GPL. Many projects that use OpenSSL can also optionally link to GNUTLS instead, so I would suggest doing so with all possible packages (lftp, elinks, wget). What are your thoughts about this? Pacman is an excellent package manager; thank you for all of the work that you put into it. Cheers, Teran (sega01) ___ pacman-dev mailing list pacman-dev@archlinux.org http://archlinux.org/mailman/listinfo/pacman-dev
Re: [pacman-dev] Linking to OpenSSL
Ah, ok. I must have read it incorrectly, but in the case of makepkg I personally prefer the *sum utilities. It is a simply revert anyways, and I will eventually get around to doing some major changes to makepkg (I have a few ideas, but nothing set in stone). Thanks, Teran On Sat, Jul 19, 2008 at 7:12 PM, Xavier <[EMAIL PROTECTED]> wrote: > Teran McKinney wrote: >> Hi, >> >> I have been working on an Arch fork for the past several months, and >> thus have been following Arch developments closely. I noticed this >> commit ( >> http://projects.archlinux.org/gitweb.cgi?p=pacman.git;a=commit;h=b8a66d68593d1f267c3bb8cd8943724711626903 >> ), where OpenSSL replaces the usage of md5sum and sha1sum utilities >> for Pacman. While I like the idea of using libraries instead of >> external binaries, I feel that linking to OpenSSL complicates a few >> things. > > I am confused, the patch you showed is for makepkg, which is a bash script. > The usage of md5sum and sha1sum binaries was replaced by the usage of > openssl binary. We don't use openssl lib. > > For pacman, we also need md5 hashing functionality. For that we imported > a md5.c file from the xyssl project. > > ___ > pacman-dev mailing list > pacman-dev@archlinux.org > http://archlinux.org/mailman/listinfo/pacman-dev > ___ pacman-dev mailing list pacman-dev@archlinux.org http://archlinux.org/mailman/listinfo/pacman-dev
Re: [pacman-dev] /etc/makepkg.local
Perhaps testing for executability instead would be better? Regardless, I like the idea. --Teran (sega01) On Sat, Jul 26, 2008 at 14:43, Mark Constable <[EMAIL PROTECTED]> wrote: > Just a suggestion. If this was the last line in /etc/makepkg.conf > then it would allow anyone to append functions that could be used > inside a PKGBUILD. Potentionally good bang for buck for one extra > line added to the official makepkg package. > > [ -f /etc/makepkg.local ] && source /etc/makepkg.local > > --markc > > ___ > pacman-dev mailing list > pacman-dev@archlinux.org > http://archlinux.org/mailman/listinfo/pacman-dev > ___ pacman-dev mailing list pacman-dev@archlinux.org http://archlinux.org/mailman/listinfo/pacman-dev
[pacman-dev] Pacman only tries to resolve with the primary nameserver
Hey, While revamping eleutherNet's ( http://eleuther.net ) DNS setup and giving it external IPv6 connectability, I found Pacman's sync server resolving method to be problematic during testing. Pacman 3.2.0 seems to only try the primary nameserver when resolving a server to sync to. The common (though not completely ideal) practice for using internal domains in VPNs is making the internal DNS server your primary and keeping your normal nameserver as secondary for resolving "real" domains after the VPN's DNS server fails to resolve the domain. Almost all applications will try to resolve through the whole nameserver list if there are no matches initially, but Pacman does not seem to.do this. Pacman is an awesome package manager, but having either optional or standard functionality for this would be nice. Thanks, Teran (sega01) ___ pacman-dev mailing list pacman-dev@archlinux.org http://archlinux.org/mailman/listinfo/pacman-dev
Re: [pacman-dev] [PATCH] makepkg: allow compression type to be autodetected
Wouldn't this break package extensions that are not *.tar.{gz,bz2}? I personally do not like this, as my Arch fork uses .ipkg (I find pkg.tar.$COMPRESSION very ugly, IMHO). Perhaps tar could simply tar the archive and a setting in makepkg.conf would allow for any method of compression? Example: makepkg.conf: COMPRESS='gzip -9' Makepkg: bsdtar -cf "$pkg_file" $comp_files * $COMPRESS "$pkg_file" Of course, you would need to deal with renaming it from ${EXTENSION}.gz back to $EXTENSION. Some error checking would be nice too. Regarding repo-add, it could simply `tar -xf` and it would be extracted if `tar` understands that type of compression. It could also check with `file`, perhaps. Cheers, Teran (sega01) PS: Why is bsdtar used instead of GNU tar? On Fri, Sep 5, 2008 at 06:03, Xavier <[EMAIL PROTECTED]> wrote: > On Fri, Sep 5, 2008 at 3:46 AM, Dan McGee <[EMAIL PROTECTED]> wrote: >> Inspired by commit 7e8f1469c4168875b54956d63884b8583ce99e38, use our given >> PKGEXT or SRCEXT to determine what method of compression to use on the >> package we create. If the extension is invalid, this should fall back to >> creating a non-compressed tar file. >> >> Signed-off-by: Dan McGee <[EMAIL PROTECTED]> > > Looks nice, and repo-add and pacman could already handle tar.gz and > tar.bz2 transparently. > ___ > pacman-dev mailing list > pacman-dev@archlinux.org > http://archlinux.org/mailman/listinfo/pacman-dev > ___ pacman-dev mailing list pacman-dev@archlinux.org http://archlinux.org/mailman/listinfo/pacman-dev
[pacman-dev] Multiple/Shared Architectures
Hey, I've planned out a set of changes I want to try with Pacman and Makepkg. Most deal with creating a source repository setup that would store source files as their sha512sums, but that isn't related to this. Another thing that I want to do is have a "shared" repository for non-architecture specific packages. I would rather not use different repositories for the "shared" architecture, ie: core-shared, extra-shared. Here is my current mirror layout: icadyptes/i486/{core,extra} The shared architecture could be at: icadyptes/shared/{core,extra} I'm sure that this conflitcts with a few things inside libalpm, but here is my proposed implmentation: pacman.conf: SupportedArchs = i486 shared (Could have i686 too, or anything making this useful for other tasks) mirrorlist: Server = ftp://icadyptes.go-beyond.org/icadyptes/$arch/$repo A shared repository would save disk space on mirrors, as well as bandwidth (to a lesser extent). The makepkg implementation for this could simply be setting $arch to shared. Distributions using Pacman would need to change other things for this to work properly, but in my opinion, it is a clean change that could be very useful. Packages could be queried for just like they are if it is not immediately found in the first repository, checking until it finds an architecture with the package's name. This could serve other purposes, too. With additional hacking (and possibly pacman.conf options), doc files could be split into seperate packages (and hence a different repo), and be given the "doc" architecture. Users would add "doc" to SupportedArchs (I'm sure this could have a better name), and when they download a new package the doc files would come in a seperate package with it. SupportedArchs would also be ordered by preference, so perhaps it could be pentium4, i686, i486, shared, so that packages (on an incomplete build) more optimised for a certain architectures would be prefered over their lesser-optimum counter parts (sure that this induces a few potential problems though). Now that I think about it, there could even be a $distribution setting for people wanting to pull packages from multiple distributions :-P. You guys have already put a ton of work into Pacman, and made it one awesome package manager. Not sure if this idea interests you or not, but it is something I'd really love to have in my Arch fork. I'm willing to code this in myself, but I'd need to learn more C first, and am sure that any of you could do it in much less time. Let me know what you think of it, and if you have any suggestions or ideas. Thanks, Teran (sega01) PS: I think that the stock makepkg should default to arch=(any) if $arch is not set. I do this in Icadyptes, and it is a very safe (to my knowledge) and easy hack. Has there been any discussion or patches regarding PGP signed database files? ___ pacman-dev mailing list pacman-dev@archlinux.org http://archlinux.org/mailman/listinfo/pacman-dev
Re: [pacman-dev] Multiple/Shared Architectures
On Mon, Sep 29, 2008 at 00:14, Dan McGee <[EMAIL PROTECTED]> wrote: > On Sat, Sep 27, 2008 at 3:03 PM, Teran McKinney <[EMAIL PROTECTED]> wrote: >> PS: I think that the stock makepkg should default to arch=(any) if >> $arch is not set. I do this in Icadyptes, and it is a very safe (to my >> knowledge) and easy hack. Has there been any discussion or patches >> regarding PGP signed database files? > > http://bugs.archlinux.org/task/5331 Glad that others are interested in this too. I would definitely vote for a signature by database method, by package is very complex and large. gpg --verify repo.db is very insecure, it allows any valid key in the user's database to be used when signing the package. If they have automatic key fetching enabled, it gets even worse. I would have seperate keys for each repo and sign accordingly. A shell script implementation of this is quite simple, but a proper C implementation might not be too bad either (especially if you don't hook into any libraries and just go by command exit status). > There is support for arch=(any) already, > and it does not require any new repositories > (when using the scheme with symlinks/hardlinks). > You can search pacman-dev and archlinux-public archives for more. > AFAIR devtools/aurtools & dbscripts still need to be modified > to start using this feature. I am aware of arch=(any), but IMO, it is redundant and somewhat wasteful to be forced to set it, since arch=(any) as a genuine usage is so common. A symlink system is very messy and impractical, but it would probably work. I did not realize that the libalpm-side restrictions of architecture settings were removed, so this should make things easier. Thanks, Teran (sega01) ___ pacman-dev mailing list pacman-dev@archlinux.org http://archlinux.org/mailman/listinfo/pacman-dev
Re: [pacman-dev] PKGBUILD.proto
Seems a little more concise to me, but I personally think that the install script should be commented out (if it has a default value). Maybe arch=('any') should be default? Would make life easier for non-i686/x86_64 maintainers, and is generally much more truthful. Cheers, Teran (sega01) On Sat, Dec 6, 2008 at 03:25, Eric Bélanger <[EMAIL PROTECTED]> wrote: > On Sat, 6 Dec 2008, Allan McRae wrote: > >> Jud wrote: >>> >>> Hi, >>> >>> Dan suggested I send this to the pacman-dev list. >>> >>> After completing some research and asking alot of questions I present >>> some minor changes to PKGBUILD.proto supplied as a .diff to be merged >>> after your approval. I believe it helps the intended audience create a >>> better PKGBUILD in less time according to the latest Arch Packaging >>> Standards. >>> >>> Cheers >>> Jud >>> >>> >>> Inline: >>> --- PKGBUILD.proto 2008-12-05 23:32:33.05000 +1000 >>> +++ PKGBUILD.proto.new 2008-12-05 23:37:45.374547000 +1000 >>> @@ -3,13 +3,15 @@ >>> # NOTE: Please fill out the license field for your package! If it is >>> unknown, # then please put 'unknown'. >>> -# Contributor: Your Name <[EMAIL PROTECTED]> >>> + >>> +# Contributor: Your Name <[EMAIL PROTECTED]> # Use dots only to >>> reduce spam + >>> >> >> I'm sure people can figure that out for themselves >> >>> pkgname=NAME >>> -pkgver=VERSION >>> +pkgver=VERSION # Note: if pkgver is '0.99-10' then use an underscore, >>> i.e. '0.99_10' pkgrel=1 >>> pkgdesc="" >>> -arch=() >>> -url="" >>> +url="http://ADDRESS/"; >>> +arch=('i686' 'x86_64') > > By convention, the arch field goes right after the pkgdesc > > >>> license=('GPL') >>> groups=() >>> depends=() >>> @@ -20,17 +22,13 @@ >>> replaces=() >>> backup=() >>> options=() >>> -install= >>> -source=($pkgname-$pkgver.tar.gz) >>> -noextract=() > > Why did you removed the noextract field? Was it done by mistake? > >>> -md5sums=() #generate with 'makepkg -g' >>> +install=(${pkgname}.install) >>> >> >> I really dislike the brackets there. install holds a value not an array >> much like pkgname, pkgrel. >> >>> +source=(http://ADDRESS/TO/FILE/${pkgname}-${pkgver}.tar.gz) >>> +md5sums=() # Generate with 'makepkg -g' >>> build() { >>> - cd "$srcdir/$pkgname-$pkgver" >>> - >>> - ./configure --prefix=/usr >>> + cd ${srcdir}${pkgname}-${pkgver} > > you forgot a / > > >>> + ./configure --prefix=usr >>> make || return 1 >>> - make DESTDIR="$pkgdir/" install >>> + make DESTDIR=${pkgdir} install || return 1 >>> } >>> - >>> -# vim:set ts=2 sw=2 et: >>> > > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > > ___ > pacman-dev mailing list > pacman-dev@archlinux.org > http://archlinux.org/mailman/listinfo/pacman-dev > ___ pacman-dev mailing list pacman-dev@archlinux.org http://archlinux.org/mailman/listinfo/pacman-dev
Re: [pacman-dev] GPG work
I like the idea of GPG signed repositories, but they are just about useless if they are signing MD5s. MD5 is very insecure, but good for normal file integrity checking. Can Pacman use SHA-256 or similiar? Another thing to watch out for is malicious publication of old repositories with old and vulnerable packages that have the force option set. I've thought briefly on how to circumvent this, but not enough to have a method I would purpose. Thanks, Teran On Mon, Dec 8, 2008 at 12:34, Dan McGee <[EMAIL PROTECTED]> wrote: > On Mon, Dec 8, 2008 at 4:55 AM, Gerhard Brauer <[EMAIL PROTECTED]> wrote: >> Am Sun, 7 Dec 2008 15:18:32 -0600 >> schrieb "Dan McGee" <[EMAIL PROTECTED]>: >> >>> I did quite a bit more work with GPG today. I wrapped my head around >>> GPGME, which presents a nice C interface to the GPG stuff so we are >>> now a lot closer to a working implementation: >>> http://code.toofishes.net/gitweb.cgi?p=pacman.git;a=shortlog;h=refs/heads/newgpg >>> >>> >From the script side of things, I didn't change much. The libalpm >>> >code >>> has changed considerably, and there is still a lot of room for >>> improvement. Let me know if you guys have questions. >> >> With heads/newgpg pacman doesn't check or find the .sig Files. If >> starting with --debug i got these debug messages: >> >> debug: md5(/var/cache/pacman/pkg/abook-0.5.6-3-i686.pkg.tar.gz) >> =79777684f62164 934a1264df66b8fdc6 >> debug: returning error 35 from gpgme_init : signature directory not >> configured correctly >> debug: installing packages >> debug: found cached pkg: /var/cache/pacman/pkg/abook-0.5.6-3-i686.pkg.tar.gz >> debug: loading target '/var/cache/pacman/pkg/abook-0.5.6-3-i686.pkg.tar.gz' >> debug: no package signature file found >> >> Where or what have i to configure as the "gpgme_init : signature directory"? >> My public key is in /root/.gnupg/pubring.gpg. I tried it also with >> /tmp/testing.gpg but the same error. >> AFAI could read the code this may belongs to commit: >> http://code.toofishes.net/gitweb.cgi?p=pacman.git;a=commit;h=1a286336147c7d3af42041d26205b9ca3980f459 >> I see a prog gpgme-config, but don't see what i could do with ;-) >> >> Help ;-) > > I didn't promise this worked out of the box- I just meant that it was > a better start than the other code. You're either going to have to > know C and understand what is going on (and fix it), or wait for it to > be in a better state of completion. > > -Dan > ___ > pacman-dev mailing list > pacman-dev@archlinux.org > http://archlinux.org/mailman/listinfo/pacman-dev > ___ pacman-dev mailing list pacman-dev@archlinux.org http://archlinux.org/mailman/listinfo/pacman-dev
Re: [pacman-dev] icadyptes makepkg changes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, I was subscribed to the pacman-dev list on my old email account, but just moved it over. I noticed the thread about Icadyptes' makepkg changes and got Allan's message. I would be happy to see some of Icadyptes' makepkg changes make it into the mainline makepkg, but I doubt all of them will (on top of that, some of my code is quite hackish). Some features are implemented nicely, though others are definitely a work in progress. Most changes were applied to the 3.2.1 makepkg, and I have not updated it for split package support and some of the other changes. I will list the changes I can remember by order of how useful I think they would be to the mainline makepkg. Most useful: runtimedeps=(): I added a runtimedeps=() option for dependencies that are needed at runtime and not for building. This would be useful for scripts that only need a `make install DESTDIR="$pkgdir"` on the building side. I've used it a few times already, but it is not the most common case. Not setting arch=() implies arch=('any'): After a couple months of development, some benchmarks, and finding that AMD K6-2s lack the CMOV instruction, I moved Icadyptes to i486/generic. It is frustrating (though scriptable) to change all buildscripts from arch=('i686' 'x86_64) to arch=('i486' 'x86_64), but I did not care for the setup from the begining. Rarely is a source tarball only buildable on one x86 subset, and I don't like having to write arch=('any') in each buildscript, so I made arch=('any') the default if no arch line was set. I think that this could be expanded a bit with negation flags for archs, ie arch=('!i486' 'i686'). Or perhaps arch=('i586+'), but that is getting a little complex and overdone in my opinion. Potentially useful: Replacing checksums inside the PKGBUILD with SHA256SUMs in a CHECKSUMS file: Originally, I kept the {md5,sha1}sums=() lines in buildscripts, but couldn't be bothered to update them if the source files were updated. This needs a lot of work, but I simplified the code gutting the PKGBUILD-internal checksums and replaced it with a seperate CHECKSUMS file containing SHA256SUMs of $source=() and $install. One can simply run `makepkg -g` to regenerate the checksums now, which is quite nice. Other scripts would have to be updated to copy CHECKSUMS over, but I have had no issues with it after some minor tweaking here. $SRCDEST using SHA256SUMs as the filenames: This needs work too, but if you are using a shared source directory makepkg will download the source files, verify them against CHECKSUMS, and move them to $SRCDEST. Using $SRCDEST with the normal filenames is problematic due to filename collision with other packages, so this is an (IMO) elegant and safe solution. I used SHA256 because MD5 is very insecure, SHA1 is potentially vulnerable, and it isn't as overkill (though some would say SHA256 is excessive) as SHA512. While an attacker could do a number of attacks to give the user faulty build scripts, at least this part of the system is secure. Of course, any checksum algorithim can be used. Doubt you would want these: Removal of OS X hacks: I can mostly understand using alternative utilities so that *BSDs can use makepkg, but I have no idea of why you care about Mac OS X enough to implement slower and more bloated workarounds to things like getopt. In my opinion, you have to draw the line somewhere. I personally think that makepkg and Pacman should be solely for Arch, but that is just my two cents. Removal of OpenSSL dependencies: I don't care for OpenSSL and try to replace it with GnuTLS where I can, so I reverted back to using the *sum utilities. GnuTLS is lighter, easier to build, and doesn't have the advertising license clause that OpenSSL does. Of course, the *sum utilities are from GNU coreutils, not GnuTLS. Moving to GNU tar from bsdtar so that libarchive can eventually be removed entirely as a package. Although libarchive looks fairly nice, so I should do some more research on this. Pacman changes: Pacman is currently pretty vanilla in Icadyptes, but I apply the reverted patch for internal file:// handling, statically link it against libarchive, use curl (you may want to look at my {pacman,makepkg}.conf as they pass a couple more flags), and generally have fairly light configure options (disabling NLS, etc.). I also use .ipkg for the package extension, but I don't think any of this is very usable by the mainstream Pacman :-). Thanks for the interest in my makepkg modifications. Let me know if you have any comments, ideas, or suggestions. Cheers, Teran (sega01) On Tue, 20 Jan 2009 14:58:50 + "Teran McKinney" wrote: > Forwarded conversation > Subject: [pacman-dev] icadyptes makepkg changes > > > From: Allan McRae > Date: Tue, Jan 20, 20
Re: [pacman-dev] Pacman Disk Space Issues
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hey, I've personally ran into this before, but don't think that it is worth "fixing" in the current Pacman setup. User error is usually the cause of this, since an admin should always have adequate disk space before installing new packages. Preventing this is difficult, like Brendan said, available disk space may be taken by other causes when Pacman is running. Not to mention, some users like to split the filesystem into a multitude of partitions. However, I do have one unlikely suggestion that *could* combat this without much difficulty. I was thinking of this more to (partially) solve the issue of package updates being cut short by a hard shutdown. Basically, packages would be extracted to /var/lib/pacman/extract (or similair), and if extraction has not errored, files would be moved to their corresponding locations. This would keep the new, possibly incompatible files out of the system until they can almost instantly be moved over, except in the case of /var, or others being on different partitions. This has the drawback that the user must have roughly installed size*2 disk space free, since the old package and new package would both have to be extracted at once (I personally think this is almost a non-issue). The current Pacman implementation may already require that much free disk space, but I'm not sure. An alternative to the above is to create directories in the folders that the package extracts to, such as .pacextract in /bin. This would insure that all mounted partitions get a fast rename/move, mitigating potential data loss and allowing for perfect disk space checking. It could be done so that the .pacextract feature only runs on the bottom 2 or 3 directories (/usr, /usr/local, but not /usr/share/man/man8, which would have .pacextract/man8 in /usr/share/man), or on a predetermined set of directories in pacman.conf. I think my explanation might be a little confusing, so I will write it out in approximate psuedo-shell script. mkdir /usr/bin/.pacextract tar xf xz-4.999.8beta-1.pkg.tar.gz -C /usr/bin/.pacextract (with other flags so that tar only extracts the archive contents of /usr/bin) mv /usr/bin/.pacextract/* /usr/bin && rm -r /usr/bin/.pacextract The simpler (extract to /var/lib/pacman/extract) method does not offer the fast move when multiple partitions are used and perfect disk space utilization checking, but would be easier to code. Anyways, this idea is quite experimental. I do think it would thoroughly solve the disk space without too much difficulty, but I personally wouldn't use it soley for that. Cheers, Teran -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.10 (GNU/Linux) iF4EAREIAAYFAkmevj0ACgkQPsLC06eiyfHnKAD9H0nTW2EU8Z46rjh3PvZD+LT2 mjUUCvhBtuX6xyQANoIA/ipz7RN87qtEJT+N2J295GcqNQ66PUKbppcrM85qh6eL =LgkR -END PGP SIGNATURE- ___ pacman-dev mailing list pacman-dev@archlinux.org http://www.archlinux.org/mailman/listinfo/pacman-dev
Re: [pacman-dev] [PATCH] Add rundepends keyword to makepkg
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hey, This is already in Icadyptes' makepkg as runtimedeps=(). Not sure if runtimedeps=() matches the PKGBUILD variable naming scheme as much, but I would appreciate considering to use runtimedeps=() instead. Although if you go with rundepends=(), I'll probably switch over too. Glad that there is some interest for this in the mainline makepkg. Thanks, Teran On Thu, 16 Apr 2009 14:25:25 +1000 Allan McRae wrote: > Dan McGee wrote: > > On Tue, Jul 15, 2008 at 1:27 AM, Allan McRae > > wrote: > >> Thomas Bächler wrote: > >> > >>> When a package A requires a package B at runtime, but B is not > >>> needed for building A or B cannot be installed while A is being > >>> built, rundepends=('B') can be used to add B to A's dependencies, > >>> omitting the dependency check at built time. > >>> > >>> > >>> > >> Any chance of resubmitting this with the required documentation > >> added (PKGBUILD.5.txt and addition to PKGBUILD.proto)? I think > >> that this patch can be included once that is done. > >> > > > > Hello old thread! Anyone still interested in this? I'm not sure what > > the status on it is, other than it is probably my fault it got > > dropped on the floor. > > > > The patch was never resubmitted and it is way down the priority list > for me so I had forgotten all about it to. > > Anyway, I will be writing documentation for the package splitting > stuff in makepkg soon so I could include that if no-one else does. I > would prefer someone else did it... > > Allan > > > ___ > pacman-dev mailing list > pacman-dev@archlinux.org > http://www.archlinux.org/mailman/listinfo/pacman-dev -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) iF4EAREIAAYFAknnIlkACgkQPsLC06eiyfHMWgEArEFHqFD70LUQshpMyNZhyC0z 2dshVN6dN9IOBlv3v/QBANkfGITXy8nic+QYdMRS/kRzp5MNjt7FJ5OI1v9mny9t =e8B/ -END PGP SIGNATURE- ___ pacman-dev mailing list pacman-dev@archlinux.org http://www.archlinux.org/mailman/listinfo/pacman-dev
Re: [pacman-dev] [PATCH] Add rundepends keyword to makepkg
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, I should have mentioned this in my reply to the Icadyptes makepkg thread, but I would have appreciated some replies showing interest in any particular change. Especially without any mentioned interest or replies I don't want to bother patching the mainstream Pacman. No replies for me implied no interest. Some of my changes are fairly radical and all are implemented messily, as I haven't even touched the man pages or docs. The more basic ones would be easy to recode. If you want any code examples for Icadyptes' makepkg changes, you'll have to look at the makepkg script <ftp://icadyptes.org/icadyptes/abs/core/base/pacman/makepkg>. But honestly, runtimedeps=() is such a simple change that it would take you just as long to import it and review it as it would for you to write it (asside from the docs). Same with arch=() implying arch=('any'). Cheers, Teran On Fri, 17 Apr 2009 04:27:42 +1000 Allan McRae wrote: > Teran McKinney wrote: > > Hey, > > > > This is already in Icadyptes' makepkg as runtimedeps=(). Not sure if > > runtimedeps=() matches the PKGBUILD variable naming scheme as much, > > but I would appreciate considering to use runtimedeps=() instead. > > Although if you go with rundepends=(), I'll probably switch over > > too. > > > > Glad that there is some interest for this in the mainline makepkg. > > > > Thanks, > > Teran > > > > This is just my opinion... but if you do not submit a patch with the > changes you are using in Icadyptes, then I really don't care what you > are doing. You have previously been encouraged to submit the changes > you made for consideration and I have yet to see a single patch. > > Allan > > > > ___ > pacman-dev mailing list > pacman-dev@archlinux.org > http://www.archlinux.org/mailman/listinfo/pacman-dev -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) iF4EAREIAAYFAknodtUACgkQPsLC06eiyfG7SAEAnD/TiW0VC6Qtm2ljfezL+Rby 6yLHQEasI802tqjxWLMBALmiZ+IIsTYAQcJdO1i7U/2g5ZlU8X8FLcM7Us3lyfah =mACC -END PGP SIGNATURE- ___ pacman-dev mailing list pacman-dev@archlinux.org http://www.archlinux.org/mailman/listinfo/pacman-dev
Re: [pacman-dev] [PATCH] Introduce new PKGBUILD variable `changelog`
On Thu, 08 Oct 2009 16:10:05 +0200 Cedric Staniewski wrote: > Hi, > > This patch adds a new PKGBUILD variable, changelog, which replaces > the old, hardcoded ChangeLog file. The old behavior is completely > removed, which means that existing ChangeLog files will be ignored if > there is no appropriate line in the PKGBUILD. For a more detailed > description, please see the patch below. > > I hope I also caught all the necessary documentation updates. > > Cedric For Icadyptes I store all of my buildscripts in Git and make comments and log revisions from there. I think that it would be a much easier and more thorough solution, although it does have some weaknesses on edge cases, possibly. <http://gitweb.icadyptes.org> Just wanted to suggest that. I know it's not integrated, but I think it's a better long-term solution, personally. Thanks, Teran -- --Teran McKinney (sega01) Blog, website, consulting: http://go-beyond.org/ Icadyptes (Arch Linux fork): http://icadyptes.org/ HLB Studios (art and the best duct tape wallets ever): http://hlbstudios.com/ Note that this email is PGP/MIME signed, as per the signature.asc attachment. If you do not know what this is, please don't worry about the attached signature.asc file. If you do know what this is and my signature is invalid, it may be due to malicious activity, a bug, or a mystery of email forwarding and what not. If you are concerned about whether or not this email is altered, please let me know. Of course, if it's altered enough, this text could be removed as well, so if this text isn't here it is probably of higher concern. Thanks! -- signature.asc Description: PGP signature