Rename the package command

I just found out that there's a package called "mailagent" in Debian
which also contains a binary file called 'package'. This means users
who have mailagent and autopackage installed can't use both at the
same time. So I suggest switching to a new name for the terminal
frontend, like 'apkg' or 'autopackage'.

Another reason would be that 'package' doesn't really do what it once
was named for (http://autopackage.org/faq.html#2_5 ) and certainly
never will be, as PackageKit already implemented something like this.

For the 1.4 release I think there should still be a 'package' command
which forwards all calls to the new command after telling the user
that 'package' is deprecated.

What do you think?

---------------------------------------------------------------------
To unsubscribe, e-mail: autopackage-dev-unsubscribe@...
For additional commands, e-mail: autopackage-dev-help@...

/usr/local news

Hi

I am hereby declaring that my attempts to convert a few commonly used
open source libraries to support /usr/local have failed .

The pkg-config project took months to reply to my mail and patch. They
apparently didn't even understand what I was saying about /usr/local,
and months later eventually committed another patch based on mine,
which simply changes the way the paths are configured and still
doesn't support /usr/local. I mailed them and told them that's not the
point of my patch and tried to explain, but nobody responded to that
mail.

In brighter news, in Ubuntu 8.04, libc does support /usr/local. Looks
like /usr/local is supported by libc by default now,
/etc/ld.so.conf.d/libc.conf contains these 2 lines:
# libc default configuration
/usr/local/lib

Seeing as libc was the only major library in Ubuntu that didn't
support /usr/local, it looks like we can now whitelist Ubuntu 8.04 as
a distribution on which installing to /usr/local does work properly.

But it simply isn't going to work this way, with a tiny group of us
caring about cross-distribution compatibility and fd.o standards, and
the vast majority not knowing or caring, and even opposing us. I'm
contributing to Wine and Java - Linux as a platform for native
applications is largely dead to me at the moment.

Bye

coreutils, -c or --bytes=?

A user on the forum reported problems using autopackage on PuppyLinux.
I found out that tail command is missing the --bytes= option so I
proposed to him to replace it with -c.
http://watteimdocht.de/autopackage/forum/viewtopic.php?f=4&t=13

I found out that the --bytes= option was introduced in this revision:
http://trac.autopackage.org/changeset/1450
Mike, do you still know why you changed it?

---------------------------------------------------------------------
To unsubscribe, e-mail: autopackage-dev-unsubscribe@...
For additional commands, e-mail: autopackage-dev-help@...

Debug mode

GCC 4.2 & apgcc

Autopackage branched for 1.3

I've branched all the modules in SVN for the work on the next major
release of Autopackage.

Future development goes into trunk (as usual), while all 1.2
development should be committed to the apkg-1-2 branch (such as
bugfixes, backported features etc.)

If you want to keep using the bleeding edge autopackage, just stay
with trunk. If you want to use svn, but stay on the 1.2 version, you
can use either the 'svn switch'[1] command (good if you're low on
bandwidth and don't mind doing it manually for all modules) or you can
checkout a new copy using the checkout-from-svn script[2] and passing
the --branch=apkg-1-2 argument to it.

The major driver for 1.3 will be Jan-Niklas' work on 64 bit support.

-Isak

[1] svnbook seems to be down, but
http://www.google.com/search?q=svn+switch should give some hints
[2] http://www.autopackage.org/source.html

---------------------------------------------------------------------
To unsubscribe, e-mail: autopackage-dev-unsubscribe@...
For additional commands, e-mail: autopackage-dev-help@...

First Autopackage 1.3 patch

Hi everyone,

In the last few days I started creating a first patch for autopackage
1.3. Here it is:

http://trac.autopackage.org/attachment/ticket/10/x86_64-1.3.diff

It adds 64 bit support (based on my last patch) and moves nearly all
scripts out of the .package file. So a 1.3 package doesn't need to be
executed in order to install it.
When a package file is installed all scripts are then created using
the templates. The disadvantage is, that the backend.template and the
installer.x.template now need to be inside the support code tarball,
too.

Feedback and further questions appreciated :)

-
Jan-Nik

---------------------------------------------------------------------
To unsubscribe, e-mail: autopackage-dev-unsubscribe@...
For additional commands, e-mail: autopackage-dev-help@...

test, ignore

The list seems to have issues.. let's see if this message gets through

---------------------------------------------------------------------
To unsubscribe, e-mail: autopackage-dev-unsubscribe@...
For additional commands, e-mail: autopackage-dev-help@...

Mailing list was down

The list has been down due to hardware problems with the ISP. This
affected the web (www.autopackage.org) and mailing list, but the other
services worked fine (trac, planet, IRC, forums, and as far as I know
support code downloads).

The website is back now, and if this message gets through, so is the
mailing list.

-Isak

---------------------------------------------------------------------
To unsubscribe, e-mail: autopackage-dev-unsubscribe@...
For additional commands, e-mail: autopackage-dev-help@...

Re: Packing a C# project.

Resending this, since the list was down when I sent it...

On Thu, Jun 5, 2008 at 8:52 AM, Isak Savo <isak.savo@...> wrote:
> On Thu, Jun 5, 2008 at 12:10 AM, Neil Munro <neilmunro@...> wrote:
>>
>> 2008/6/4 Isak Savo <isak.savo@...>:
>>>
>>> On Wed, Jun 4, 2008 at 10:33 PM, Neil Munro <neilmunro@...> wrote:
>> >
>> > 2008/6/4 Isak Savo <isak.savo@...>:
>>
>> if (File.Exist("../../images/image.png"))
>>   myImageFile = "../../images/image.png";
>> else
>>  myImageFile = Path.Combine(Binreloc.DataDir ... //etc...
>>
>> That way, it doesn't matter which compile mode you build the program
>> in, it'll always just work.
>
> I like this method. Looks like a lot of work initially, but I don't mind too
> much.

 I agree. This is typically the solution I do.

>>
>> For 2), you'd have to setup MonoDevelop to actually copy everything to
>> a location on your disk and run it from there. This method would
>> require you to write some shell scripts. You can configure custom
>> commands by right clicking on your project file in monodevelop, select
>> properties and then navigate to
>> Configurations -> Debug (Active) -> Custom Commands.
>
> So what are the custom commands I need to set up, what do I need to copy
> where? Could I not have the folder in ../share and a sym-link that BinReloc
> looks in?

 You would create a bash script in your source directory called, e.g.
 post-build.sh
 That script would typically do:

 #!/bin/sh
 prefix=/tmp/myprogram-debug
 mkdir -p "$prefix/bin"
 mkdir -p "$prefix/share/myprogram"
 #copy binary to bin
 cp bin/Debug/myprogram "$prefix/bin"
 #copy data to share, just use cp to copy whatever data files you need
 to $prefix/share/myprogram/

 Then you call this script from mono-develop after a successfull build
 (using the options i talked about)

 But if you do solution 1) above, you don't need this script at all.

> I have set the binary output directory to be Debug and data should be in
> share/ below that and I would like to have the binary in bin/ so what script
> magic do I need?

Go with 1) above and don't change anything in monodevelop! That's
probably the easiest method.

>> I was a bit unclear, "/etc" is mostly used for system configuration
>> files. Normal applications rarely place anything there, mostly servers
>> and fundamental system tools do that. (There are a few exceptions to
>> this rule though, for example programs that use the GConf
>> configuration system, like the GNOME apps, they put their default
>> configuration values there.. but that's a completely different story..
>> let's not go there right now :)
>>
>> Configuration files which are ment to be changed by the user should be
>> stored in the users home directory. Typically, you would store them in
>> ~/.config/yourprogram or something like that (either just one file, or
>> a directory with multiple files depending on how much configuration
>> files you need.. probably just one!)
>>
>> Anything else should most likely go to $prefix/share/yourprogram.
>
> Got ya, only really use bin and share, right?

For most applications, yes.

If you're really interested in how the directory layout works, you
should read up on the FHS document (Filesystem Hierarchy Standard):
http://www.pathname.com/fhs/pub/fhs-2.3.html

-Isak

---------------------------------------------------------------------
To unsubscribe, e-mail: autopackage-dev-unsubscribe@...
For additional commands, e-mail: autopackage-dev-help@...

Packing a C# project.