Re: AP v1.4.2: Dependency Building: Still Broken

--001485f01d60d5e870046b07461c
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

>
> Yeah. I think a good idea would be just to accept AutopackageTargets
> with 3 numbers.


Yep, let's do that.  I use the same approach for my applications.


> I also don't like, that all impair version are development releases
> (e.g. 1.1, 1.3, 1.5, ...). The Linux kernel droped this idea, too. For
> example there was only one 1.3 release and I don't think there were
> many testers. So I would say that 1.5 would be the next stable
> release. What do you think?


I think that's a good idea: throw away the intermediate testing subversion
approach.

Just make sure that the remote dependency resolution feature is tested
before each release and you'll keep me happy.  I'm sorry to write that it
still appears to be broken in v1.4.2.

I just created Hamachi and Quamachi packages using v1.4.2.  When I tried to
install Quamachi, Autopackage is still unable to install the (remote)
Hamachi package.  The error message this time was simply: FAIL: Unable to
prepare package ...

I had set the debug level to '3' beforehand, but no log file was created.
Can you please actually take the time to test that this remote dependency
resolution feature is fixed before releasing v1.4.3?  If preferred, you're
welcome to email me the beta code tarballs and I'll test it here.

I want to stop releasing Deb/RPM/TGZ packages with my application and force
everyone to use AP, but it seems to be too unstable right now.  I'm hoping
we can get this ongoing problem fixed and then leave all related code the
hell alone for all eternity.

--001485f01d60d5e870046b07461c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"borde=
r-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-le=
ft: 1ex;">Yeah. I think a good idea would be just to accept AutopackageTarg=
ets<br>







with 3 numbers.</blockquote><div><br>Yep, let&#39;s do that.=C2=A0 I use th=
e same approach for my applications.<br>=C2=A0<br></div><blockquote class=
=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, 204, 204); margin=
: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">







I also don&#39;t like, that all impair version are development releases<br>
(e.g. 1.1, 1.3, 1.5, ...). The Linux kernel droped this idea, too. For<br>
example there was only one 1.3 release and I don&#39;t think there were<br>
many testers. So I would say that 1.5 would be the next stable<br>
release. What do you think?</blockquote><div><br>I think that&#39;s a good =
idea: throw away the intermediate testing subversion approach.<br><br>Just =
make sure that the remote dependency resolution feature is tested before ea=
ch release and you&#39;ll keep me happy.=C2=A0 I&#39;m sorry to write that =
it still appears to be broken in v1.4.2.<br>




<br>I just created Hamachi and Quamachi packages using v1.4.2.=C2=A0 When I=
 tried to install Quamachi, Autopackage is still unable to install the (rem=
ote) Hamachi package.=C2=A0 The error message this time was simply: FAIL: U=
nable to prepare package ...<br>




<br>I had set the debug level to &#39;3&#39; beforehand, but no log file wa=
s created.=C2=A0 Can you please actually take the time to test that this re=
mote dependency resolution feature is fixed before releasing v1.4.3?=C2=A0 =
If preferred, you&#39;re welcome to email me the beta code tarballs and I&#=
39;ll test it here.<br>


<br>I want to stop releasing Deb/RPM/TGZ packages with my application and f=
orce everyone to use AP, but it seems to be too unstable right now.=C2=A0 I=
&#39;m hoping we can get this ongoing problem fixed and then leave all rela=
ted code the hell alone for all eternity.<br>




<br></div></div>

--001485f01d60d5e870046b07461c--