On 18/03/12 05:47, Matthew Monaco wrote:
>
> In the meantime I'm playing with Xyne's great idea of plugins.
>
Just so you know... splitting out parts of makepkg has been discussed
quite a bit already. That including solutions for how to enable running
makepkg both from within the source tree a
On 03/17/2012 01:26 PM, Thomas Bächler wrote:
> Am 17.03.2012 20:05, schrieb Matthew Monaco:
>> Is there any reason why devel_update() actually needs to do an in-place sed?
>> I
>> replaced it with an eval and its working fine.
>>
>> The function now looks like:
>>
>> if [[ -n $newpkgver ]]; the
Am 17.03.2012 20:05, schrieb Matthew Monaco:
> Is there any reason why devel_update() actually needs to do an in-place sed? I
> replaced it with an eval and its working fine.
>
> The function now looks like:
>
> if [[ -n $newpkgver ]]; then
> if [[ $newpkgver != "$pkgver" ]]; then
> e
On 03/12/2012 09:58 PM, Allan McRae wrote:
> blah
I have a patch that I've tested (a little bit) that appears to work...
Is there any reason why devel_update() actually needs to do an in-place sed? I
replaced it with an eval and its working fine.
The function now looks like:
if [[ -n $newpkgv
Dan McGee wrote:
> > I don't like the @@ and :: syntax. Maybe
> > "git://remotename//http://projects.archlinux.org/git/pacman.git";? That
> > way we can simply look for "git://" and also easily figure out if there
> > is a remote name or not. "//" should also be a safe delimiter because in
> > the
On 14/03/12 02:12, Thomas Bächler wrote:
> Am 13.03.2012 13:15, schrieb Allan McRae:
>> #branch=maint
>> #tag=v4.0.1
>> #commit=f42ad345
>>
>> This gives full clarity to what is being specified an allows for
>> potential cases where branches and tags have the same name and we could
>> provide multi
Am 13.03.2012 13:15, schrieb Allan McRae:
> #branch=maint
> #tag=v4.0.1
> #commit=f42ad345
>
> This gives full clarity to what is being specified an allows for
> potential cases where branches and tags have the same name and we could
> provide multiple options, semicolon separated, if needed (obvi
On 14/03/12 01:49, Matthew Monaco wrote:
> On 03/13/2012 06:15 AM, Allan McRae wrote:
>>
>> Hmm... good idea using the fragment identifier for specifying the
>> branch/tag/commit to checkout. Being inspired by how pypi uses these to
>> provide checksums, could I even suggest:
>>
>> #branch=maint
On 03/13/2012 06:15 AM, Allan McRae wrote:
>
> Hmm... good idea using the fragment identifier for specifying the
> branch/tag/commit to checkout. Being inspired by how pypi uses these to
> provide checksums, could I even suggest:
>
> #branch=maint
> #tag=v4.0.1
> #commit=f42ad345
>
> This give
Am 13.03.2012 12:33, schrieb Allan McRae:
> The three cases I see as needing covered are:
>
> 1) build from master HEAD
> 2) build from a branch HEAD
> 3) build from a given commit/tag
>
>
> What we need to find is the simplest way of allowing these (and other
> reasonable suggestion that arise
On 13/03/12 21:53, Dan McGee wrote:
> On Tue, Mar 13, 2012 at 7:41 AM, Florian Pritz wrote:
>> On 13.03.2012 04:58, Allan McRae wrote:
>>> 1) URL:
>>> There were previous patches to the mailing list that never really got
>>> finished, but I think we were fairly happy with this syntax:
>>>
>>> sour
On Tue, Mar 13, 2012 at 7:41 AM, Florian Pritz wrote:
> On 13.03.2012 04:58, Allan McRae wrote:
>> 1) URL:
>> There were previous patches to the mailing list that never really got
>> finished, but I think we were fairly happy with this syntax:
>>
>> source=(git://projects.archlinux.org/pacman.git)
On 13.03.2012 04:58, Allan McRae wrote:
> 1) URL:
> There were previous patches to the mailing list that never really got
> finished, but I think we were fairly happy with this syntax:
>
> source=(git://projects.archlinux.org/pacman.git)
> source=(git@@http://projects.archlinux.org/git/pacman.git)
On 13/03/12 21:23, Dan McGee wrote:
> On Tue, Mar 13, 2012 at 7:20 AM, Florian Pritz wrote:
>> On 13.03.2012 12:05, Allan McRae wrote:
>>> I do understand the branch name is useless once you have a tag/commit
>>> id. That is why later in the email I said it only really serves as
>>> documentation
On Tue, Mar 13, 2012 at 7:20 AM, Florian Pritz wrote:
> On 13.03.2012 12:05, Allan McRae wrote:
>> I do understand the branch name is useless once you have a tag/commit
>> id. That is why later in the email I said it only really serves as
>> documentation.
>
> Use comments for that.
So just how
On 13.03.2012 12:05, Allan McRae wrote:
> I do understand the branch name is useless once you have a tag/commit
> id. That is why later in the email I said it only really serves as
> documentation.
Use comments for that.
--
Florian Pritz
signature.asc
Description: OpenPGP digital signature
On 13/03/12 20:25, Thomas Bächler wrote:
> Am 13.03.2012 09:21, schrieb Allan McRae:
>>> Is it at all feasible to just use the build date for package ordering if
>>> it's a
>>> vcs package? This way the pkgver can be the ref that was checked out:
>>>
>>> - the short hash
>>> - the tag
>>> -
On 13/03/12 20:39, Thomas Bächler wrote:
> Am 13.03.2012 11:36, schrieb Allan McRae:
>> On 13/03/12 20:13, Thomas Bächler wrote:
What makepkg does:
> 1) goes into $vcsdir, checks for the pacman directory
>- if not present, do the git checkout
>- if present, enter and do a "
Am 13.03.2012 11:36, schrieb Allan McRae:
> On 13/03/12 20:13, Thomas Bächler wrote:
>>> What makepkg does:
1) goes into $vcsdir, checks for the pacman directory
- if not present, do the git checkout
- if present, enter and do a "git pull" unless --holdver is specified
>> This
On 13/03/12 20:13, Thomas Bächler wrote:
>> What makepkg does:
>> > 1) goes into $vcsdir, checks for the pacman directory
>> >- if not present, do the git checkout
>> >- if present, enter and do a "git pull" unless --holdver is specified
> This should be a path under SRCDIR. This should als
Am 13.03.2012 09:21, schrieb Allan McRae:
>> Is it at all feasible to just use the build date for package ordering if
>> it's a
>> vcs package? This way the pkgver can be the ref that was checked out:
>>
>> - the short hash
>> - the tag
>> - the branch (_short hash maybe OR only automaticall
Am 13.03.2012 04:58, schrieb Allan McRae:
> To get the ball rolling again, I think we should pick one VCS system and
> flesh out what we need and what the prototype PKGBUILD would look like.
> Then we can move on to the other VCS systems and finally implement it.
> I guess by the time all the bik
On 13/03/12 15:36, Matthew Monaco wrote:
> On 03/12/2012 09:58 PM, Allan McRae wrote:
>> 2) Specifying commit to work with:
>> I think that this is the difficult bit... the syntax with the source
>> array is already convoluted enough, so I do not think they should be
>> added there. So that sug
On 03/12/2012 09:58 PM, Allan McRae wrote:
> It is well know that the VCS package support in makepkg is subpar...
> The number of bugs about this is into double figures. There have also
> been some patches submitted attempting to be able to use the source=()
> array in PKGBUILDs to specify a VCS r
It is well know that the VCS package support in makepkg is subpar...
The number of bugs about this is into double figures. There have also
been some patches submitted attempting to be able to use the source=()
array in PKGBUILDs to specify a VCS repo and remove a lot of the
repetitive crap involve
25 matches
Mail list logo
