[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
