Puppy Linux Discussion Forum

[amigo]

OOps, another glitch in waf option usage -I'm pretty sure there has been a version change in waf.
In 06-configure_source change line 597 :

[jemimah]

Big_bass, pasting that script doesn't work. Can you attach it instead?

----

It would be easier if the src2pkg pet was preconfigured for puppy. You get slackware packages out by default. Xterm is just a symbolic link to rxvt - there's no wrapper - so that's a major obstacle in getting it to work. I'm not sure why it won't let me build packages in /root. I have to read the documentation for 15 minutes to figure out which options I need. Those are the only reasons the learning curve is steep.

I guess what I really think I want as a new user, is a package building wizard that holds my hand through the build process, and that doesn't make too many decisions without my input, but doesn't assume I know how to make a package either. Src2pkg is great once configured.


If I just get my sources from the developers website, I'd say maybe only 30% will compile without massaging either the configure script, the makefile, or the source. Is using slackware or debian sources better than that? My puplets are mostly built from vanilla source and I really prefer rolling updates rather than rebuilding the while system periodically.

Thanks for the updates. I'll test them shortly.

[big_bass]

[jemimah]

That works now big_bass. Do I need these other files?

[big_bass]

Hey jemimah

[amigo]

"and that doesn't make too many decisions without my input, but doesn't assume I know how to make a package either" These two are really at odds with each other. Configuring and compiling source code is a real 'black art' for anyone who hasn't done a lot of it before. The standard instruction of './configure && make && make install' is only valid in a fraction of the cases as you well know.

src2pkg automatically takes care quite a few cases that don't fit that pattern at all -like waf, python, perl, imake, etc. It also takes care of many autoconf-type sources which still can't be done as above. For example, when using autoconf-sources downloaded from a version-control repo -they don't have the *.in files- so src2pkg knows what to do with them -run autocnf.sh(or other similar script), run 'autoreconf, or a manual list of command which tries to do the same thing. With that, we've already covered commands/tricks which would take a long time to learn -did you know about 'autoreconf -if'?

Once configuration is done (don't forget about how we can also 'harvest' previous human knowledge for that), we get to actually compiling the sources. Again, src2pkg has lots of 'experience' and applies it using heuristic rules which have built up over years. Even just concentrating on perl sources, there are three different ways to build the modules. Doing so manually means have to read the README to (maybe) find out how to do it for this case.

Finally, creating 'sane' packages is a whole 'nother art and is not the same for all systems. You can even use src2pkg to check the sanity of packages created using other methods. Final package creation allows for many options to accomodate both normal 'good practices' and individual needs/desires.

Now, the point is, that exposing a 'newbie' to the full gamut of options will only confuse them. Of course, setting a few basic options by default is a good idea. But beyond that, most build failures are going to be due to base-level problems and not to src2pkg itself. I mean, if the system doesn't have some dependency installed, then configure or make is going to fail. At that point, the user has to be led into learning more about what src2pkg is really doing which they don't see.

I can easily accept that only 30% of what *you* build will do so without some patching, addition of confirue options or other such action. But you are building some pretty complex stuff which is not always the case with newbies. Your experience using src2pkg is bound to help you decide how to help the newbie most effectively.

About the options GUI, I think that it should only ask about the most basic options -otherwise the user is overwhelmed with unnecessary choices:
* You should definitely set PKG_FORMAT to 'pet' or 'pet2' by default. (I recently added code which is auto-detecting slackware systems -there are now two types for it 'tgz' and 'txz'. Could can be added for auto-detecting pet/pet2 as well).
* Users should be prompted to set PACKAGER and SIG. PACKAGER is the person's name and SIG is a suffix 'tag' which gets added to the package name.
* You might present the QUIET option(default is QUIET=YES)
* If you look at my src2pkg.conf which I posted, you'll see I have EXTRA_FLAGS(CFLAGS appends) and EXTRA_LDFLAGS like this:
EXTRA_FLAGS="-pipe -fomit-frame-pointer"
EXTRA_LDFLAGS="--relax,--sort-common,--no-keep-memory"
These are both set to a low common denominator. You yourself may widh to tweak these some, but these flags are fully usable on all arches. technosaurus uses a long list of extras to try and create the smallest possible output, but most of his flags are not portable to other arches, some are redundant and some are explicitly ill-advised. I don't think newbies shoudl be confronted with a choice here. either leave the settings blank or use what I am using. Adding options indiscriminately will cause failures sometimes. The other day I built something which wouldn't even work with these set at all.
* I would present the offer to use CWD for all build files instead of the default /tmp. It makes it so muh easier to have an overview of the SRC_DIR and PKG_DIR.
* You might query for COMPRESS_BINS, BIN_COMPRESSOR, but use default 'COMPRESSION_SIZE_LIMIT=50' to avoid trying to explain that compressing very small bins will only make them larger.
* AUTO_DESKTOP=YES works pretty well, for what it is. An extension which would prompt for better input would do a better job...
*FAIL_ON_BAD_DIRS=NO and FHS_POLICY=NONE will make src2pkg more forgiving of crazy puppy apps which want to sling files everywhere in the most unlikely places... But as joe mentioned, you should not build packages directly in /root or $HOME -src2pkg will reject this as it is too dangerous. Using a subdir of $HOME is okay though.
* src2pkg goes to great lenghts to create well-crafted, standards-and-license compatible packages, so it will always try to include docs and man-pages. You can limit the number of docs it installs by default by using DOCLIST=MINIMAL. (I've just noticed that this option is not mentioned in the conf file -will fix)

I have been told that the src2pkg man-pages and --help output are quite 'dense'. They are nearly the same, so having a long look through them, combined with a close look at the default conf file should clear up lots questions you might have. Most of the options in the conf file are for advanced usage and need not be changed often.(Joes advice to change the conf file for specific builds is not advised -rather package-specific tweaks/overrides should go in a NAME.src2pkg script for the build)

Be aware that options given on the command-line take precedence over options in the conf file and any *.src2pkg script *unless* the latter options are defined unconditionally. All required options have already been set by the time the first build step (pre_process) finishes -except any which can only be discovered once the sources are unpacked(mostly configure-related stuff) The order of precedence is like this: command-line, NAME.src2pkg script, $HOME/src2pkg.conf, /etc/src2pkg/src2pkg.conf, DEFINES. Do (nearly) always use conditional settings like this:
! [[ $VAR ]] && VAR=VAL
The exception is when an admin wants to override unwanted settings by users. That's when simply VAR=VAL goes in the main conf file.

In trying to understand the command-line options better, note that UPPERCASE options are switches which take no options. Most lowercase option do need a value to be set. lowercase options are mostly build-specific, whereas UPPERCASE ones are like preferences for general behaviour. If you use -N to generate a script, then you can execute builds with simply:
src2pkg -X (plus any other uppercase options you want)
which shortens your command line considerably. This also makes it easier to experiment with resume, pause and other uppercease options -especially if you deliberately choose some simple and fast-building source. A bit of time playing with the options which look interesting will pay well.

I nearly always start a build by dropping the archive on the src2pkg-dnd icon to generate a completely generic script. I then run:
src2pkg -X -E -A
If I've used a debian patch or rpm archive, I have a look for any included patches. src2pkg will automatically apply patches placed in the CWD or special patch location, but will not automatically aplly those inside the sources. If I decide to use any of the patches I place them in one of the special locations and re-do the step of dropping the source archive on the dnd icon so the PATCHLIST gets auto-generated.
If the build fails I do:
src2pkg -X -E -A -VV (use --resume=?? if the build is long)
* Important! To preserve anything edits to the NAME.src2pkg script, rename it to remove the '.auto' suffix -otherwsie it will get overwritten if you run src2pkg -N there again. This distinction (with or without '.auto' also provides an immediate visual cue about the difficulty of the build. Always having a srcipt -even when not needed, makes it easier to use bulk or group build mini-scripts -see in the examples: cd SUBDIR && src2pkg -X

I better stop now before overwhelming you...

@ Joe, do you have a copy of BK's xterm-wrapper script?

[big_bass]

Hey Gilbert

[amigo]

Thanks Joe. Meanwhile I had remembered the essence of how to get pseudo '-hold' working for other terminals. I was looking at this a couple of weeks ago on debian. I'm gonna add some code in a couple of places to implement this -there are sevreral spots using 'xterm -hold ...' which need to be addressed.

About the GUI, you know well, by now, that src2pkg doesn't often need much help once very basic preferences and system-specific options are set. So, I think that a GUI for newbies should avoid the kid-in-a-candy-store syndrome -too many options will just intimidate them needlessly. You have a basic structure working which should be fairly easy to refine -up or down. I do think it would be a good idea to 'cat' the full content of a 'virgin' conf file onto the end of the conf file you generate. As users get more competent, they may want to tweak other settings so it would be good to have all the (commented) options in view.

Over the next couple of days I'm gonna address a few spots where I know pet-creation can be improved. As I mentioned before, I've add auto-destection of PKG_FORMAT for slack (tgz or txz depending on distro version #) and for debian. I had in mind to do the same for puppy at the time, but had forgotten which file reference I could use to distinguish between old puppy versions and woof builds. Is it /root/PUP_PECS which is not in old versions? Either of you remember/know how to tell the difference.

Speaking of pet/pet2, I think Jemimah will find that PET2 only works when passed from the command line -I'm gonna fix that also.

Also, speaking of '/root', you'll wanna use $HOME instead in your GUI for compatibility with other systems. When you are done fooling with the GUI, I'll have a good look at it and then include it in the src2pkg sources.

I'm gonna try to get a quick follow-up release out this weeks which addresses a couple of minor issues and includes some pet-related tweaks, so keep it comin'!

[big_bass]

Hey Gilbert

I made the GUI for puppy easier
and removed a lot of code to make it simple to read
look it over and comment on what it still needs jemimah, amigo or any other suggestion ?



Joe

[amigo]

Thanks, Joe. I'll have a look at it soon. I'm about ready to wrap up a new (quick follow-up) release, so I'll see if this is close to being included.

[big_bass]

Hey Gilbert

this has a few fixes adding the $HOME instead of root
not bug fixes just fine tuning

*and a message about the main config file
I didnt want to append it because the dialog box would be huge
to scroll

this should be the final unless you decide to edit something else

Joe

[amigo]

Thanks, Joe!
"this should be the final unless you decide to edit something else" okay, I'll try to have a look at it tomorrow.

[stu90]

Having never compiled anything before this all sounds very technical and somewhat overwhelming - if i could make a suggestion, how about perhaps a screen recording run through video example of compiling say Gimp of some other popular application with Src2pkg?

cheers.

[big_bass]

Hey stu90






A good suggestion

********************************
getting started
********************************

src2pgk is very simple
once the configuration it set up to be used for us on puppy
I hope this GUI takes care of the one click approach to things

then a src2pkg "quick start" will be be documented with simple examples
that you can test and get familiar with without all the advanced options

I know that amigo has already well documented that easy getting started step

and you will be able to start compiling packages
and have fun in having control of what you want to install !
a liberating feeling indeed






***********************************
only extra technical history behind the scene
***************** ********** *******
please be patient and understand that all this discussion( between developers) is for the end goal of handling all the configuration for puppy automatically

because puppy itself has no long term fixed standardized format
or package discipline practices
this is not a negative statement its just a fact ( we have adjusted to)
it breaks most of the rules required to build a linux package
even the *pet suffix is not an official standard itself
and using root for starters


instead of focusing on the inbuilt errors (of puppy)
the configuration has to allow for our non standard practices
that we have grown used to


*I had worked with amigo long before using the older non woof pet package then the package format changed again on puppy
(I was his "puppy package builder" contact point since puppy version 3.01 when src2pkg was first ported to puppy )

since I moved on to using "TXZ packages" that contact point wasn't updated again til now . *many package formats could be built with src2pkg so its smart to learn how to use it
I continue to use src2pkg only using the txz packages instead
and wanted to help "puppy users" build packages from source also
because that will make them more informed about the
choices that are available


Joe

[scsijon]

ok, for a dumb q!

I now have in my comp 3 packages, the src2pkg.....pet and two GUI.....gz's.

What am I suppose to do with them to make a useable application?

thanks
scsijon