Package builder utility

[Triarius Fidelis]

It's not really.. So you're suggesting to chmod 0700 /tmp/$APP-$APP_VER ??

Ya. Can't hurt at any rate. I'll see if I can finally grok Gambas this time, and have a look at the source code myself...

[M0E-lnx]

Ok.. Here is the latest on the development:

I Have implemented the requested features (including the chmoding of the build dir).

I am now in the process of building a "Preferences" window to store a couple of default settings
So far these include

• Temporary Build Directory
• Packager ID (so you don thave to type it every time you build a package)
• Text Editor Selection

I kind of need some help in the last one. I do not wish to start a war as to which text editor is better, but rather I'd like to get the user's input on choices
As of now, I have listed

• mousepad
• geany
• kwrite
• medit

The whole idea behind a text editor selection is because I will add the ability to explore the contents of an existing package, at which time the user will have the ability to edit the slack-desc and .desktop file in the package using the selected text editor. Then we would put the package back together.

Shoot away

[lagagnon]

I would suggest including only those text editors which come pre-installed with either Standard or SOHO. So that would include mousepad, mcedit, vim, kedit,

[Triarius Fidelis]

Why not just allow the user to type in any pathname, then follow it up with the file?

For instance, I wouldn't want another instance of Vim to start running when one has already started. To that end, I would tell the package to use 'vim --servername server --remote'

[M0E-lnx]

Well, The general idea is what Lagagnon said, the ones that ship with the VL releases should be in the options, but I also have an option for other. When the user clicks other, a dialog appears, and allows the user to select their own.

EDIT:

BTW, should I offer the option to edit the slack-required file? ... I know this could be dangerous

[blurymind]

YES!

This utility is evolving really nicely,making packaging and editing of packages a easier,less time consuming task!

Editing the slack-desc file is a needed feature if you ask me,but its needed for tlz packages that were created by makepkg procedure (no configure and make)... Some apps under linux that are written in python can't be packaged by vpackager,but vpackager can have the powerful feature ,give the ability to the user to write a slack-required file and put it inside,without the need to explodepkd and makepkg again and again just to fix a typo. ( what i had to do with my last packages - fontpage and acetoneiso ).... so here my feature requests:

packageeditor should be a sepparate module of vpackager. Can you make it that,the user who starts vpackager,starts it only to package stuff,not to edit packages...no clutter with buttons that have nothing to do
with the main thing.Just include it in the file> menu,above the "quit" option)
So make package editor a sepparate module of vpackager,that can be called to open a package,just by opening the package.tlz file with it (no browse for package buttons and dialogues)

vpackage-edit packagename.tlz

...
Vpackage-edit could be called from vpackager's file>edit a package menu....but it should be able to directly open tlz files with it...

and it should have the following features:
*directory listing of files inside the package (showing the dirs and the files inside)
*check if package has a proper slack-required and slack-desc  file (not a must,but a sweet feature) and "slack-required" and "slack-desc" butttons that will open the files for edit, since they are always in install folder.. maybe slack-desc button could call the slack-desc editor that vpackager already has. This way the user could easily change whats written in the description,in case there are typos or old information that is absolete (old website url,wrong license,etc etc)
and if there is no slack-desc or slack-required file found inside,the user could write one (a very important feature)
*cancel,quit and apply changes buttons at the bottom =P (it will have to uncompress the package first,before the user can edit and put stuff inside,right?) Apply button should package it again and overwrite the original file.
*the ability to import file in the package (in any of the dirs it has)
*the ability to edit files (slack-required) with a text editor (i vote for mousepad,since its the fastest,but this can also be done with the preferences window,where the user can just type the command which is for the text editor,and not chose from a list or anything)...when opening a file inside the package,the user should have the ability to change it and overwrite the old file...

*the ability to create a package with makepkg out of any directory that the user choses. (maybe this could be sepparate from vpackage-edit,but it can use it --- include the option "make package from folder" in vpackagers file> menu)

the ability to import files and delete files in a package is priceless for managing packages that can't create a slack-required file and the user must write one!

Anyways,i really think that this will deliver a great support for packages that dont build with the standart procedure. Then they can be installed with a prefix to a given dir and then packaged and a slack-required file could be written for them easily. 

...please don't change the way it uses the tmp directory.Its not broken,dont fix it, plus its easier for the packager to find and open the slack-desc and slack-required file of the package he/she made, so its easy to copy and paste at the forum.

[caitlyn]

I haven't read every post in the thread so there may be some duplication.  My apologies in advance if that is the case.

My overall impression is that this is a wonderfully thought out and well designed tool that will eventually be a great addition to VL, but... the version currently in the testing repository is nowhere near ready for prime time.

Problems:

1.  Adding an existing slack-desc file:  it looks for slack-dec instead.
2.  Save package to non-standard directory still doesn't work.
3.  Most serious:  Error handling (i.e.: failed dependency) is pretty much not there at all.

I deliberately tried the gnumeric 1.7.10 compressed tarball knowing full well that I hadn't installed the new version of goffice.  Instead of telling me that the configure script had failed it told me that the package was built.  (Not true, of course.)  No output or error message was saved.  I don't know about anyone else but IME not all developers accurately or completely detail dependencies.  This sort of error is the one I run into most when building a new package.

One other thought:

Choice of build options is default or custom.  A third choice should be VL standard.  IMHO that should include --prefix=/usr and --with-included-gettext.  The latter builds gtk2 and GNOME apps with full multilingual support.  Very few configure scripts will actually fail if that is included but not supported (there are a few, though).

I consider vlpackager very promising and I congratulate the developers for bringing it so far along already.  It just needs a bit more work before I'd actually consider using it regularly.

Thanks,
Cait

[blurymind]

i too found a bunch of errors.

you specified some but...

First of all,the save package to alternative directory WORKS for me.
and i build a few packages and it always stopped when some dependency wasnt satisfied,but it didnt spit the error message as in the console..

the error:
*when i click on next,without specifiing a package, the message "no source package" just keeps on popping out countless times and i cant close the window at all.Instead the error message keeps popping out.

[M0E-lnx]

@ Caitlyn:

The slack-desc thing is intended that way. You are given 2 options, One, pick out an existing slack-desc file, or create a new one.

The other 2 issues on your list have been fixed (but I still haven't uploaded a new revision to the repos).

About the build choices, I consider it unnecessary to include any custom build options and call them "default for STD", which is why I included the ability to add these when you click on the custom build.

@ blurymind

Your issue has alson been fixed. The save package window and functions have been re-done, everything should work a lot better now.

This is where it currently stands.

The package editor tool will be available from the menu, of course the user will browse for a package (no command line tool here) after that, you'll be able to edit the slack-desc and .desktop file.

I'm not sure editing the slack-required would be such a safe feature, because this could lead to bad packages.

I'm curious, why would you want to add other files to an existing package? ... It may not be a bad feature, but I wouldn't want to turn this into a file manager

Will be uploading a new version soon

[blurymind]

my intention is to edit packages that i've created with makepkg...packages like acetoneiso or fontpage and many other python apps that use a simple copy to dir install script and dont go through the standart configure and make procedure that vpackager uses.

Some apps that are like so need other packages to operate,but their install script doesnt look for the dependencies or create a slack-required file. Of course a naturaly created slack-required files doesnt need to be edited.When there is no slack-required file (for the packages created by using makepkg to put all thats needed),one must write one, so whenever someon installs it,he or she wouldnt have to bother looking for a README file to find out why its not working and what has to be installed.

look at the site gnomefiles.org
Most of the stuff there,written in python can only be installed by a install script that just copies the files where needed (the one thing that a tlz package can do as well)
...
they usually say what needs to be installed in the README file. I dont want the casual user to have to bother with that,when a tlz package is capable of doing it automagically.

[M0E-lnx]

I do plan on adding support for python apps later on, so eventually vpackager may be able to create a package out of a python source tarball. But I would have vpackager run the install script and package the stuff. There is ways to do this, just need to get them in there.. for now, I'd like to get the current phase working right before I move on to more features.

[blurymind]

alot of the apps have completely different install scripts,named differently.

[Joe1962]

I find I need to tweak most packages. Stuff like adding different .desktop files for KDE and XFCE, deleting duplicate documentation, or even the documentation sources, retouching the dependencies, adding a slack-suggests ot slack-conflicts, etc, etc...

[M0E-lnx]

Would it be enough to explode the package and open a file manager to the location?

or do I need to do anything more than that?
I figure, If I get it to do that, then you can pretty much do whatever you need from there... add/remove contents, move thigns around, edit files, etc.

[blurymind]

well,you could do that,but some things can be automated to save time:

*check if in the install directory there are slack-required and/or slack-desk file
if not promp user to create them,opening mousepad or vpackager's slack-desc editor!
*Check for the presence of a *.desktop file, it can also be automated for editing...
*even if there are have the ability to open them directly without the need to navigate..
*list the contents of the package in one list and the number of files. (no need to browse)
...

=========EDIT===================
VVVVVV

a *.desktop creator could eliminate human mistakes that the user could make (specify a png/pixmap icon and give it wrong name in the desktop file,thus it wouldnt show in the start menu when installed)

...orr the mistake to type a wrong cathegory name,so it might not show in the start menu at all.. ( a drop down menu could fix that and would be very neat)

lol,this might look like a little too much,but some non-gui applications wouldnt need a desktop file at all,so the user should decide whether its needed or not.... maybe this package-explorer can be included as an option in the Save package window,so the user could examine the package before saving it...

there is also the question after exploring and adding something,how will it be tlz-ed again. Makepkg?