I'll look at dir2pet as well - should be minor modifications to eliminate the issues. Probably just use Xdialogs unless I can figure out a way to get it to use a single gtkdialog effectively._________________Web Programming - Pet Packaging 100 & 101

the way the pet directories are made .... the files are "watched" as they are installed and then copied to the appropriate directory. This is probably the best way to do it since only some programs support a --destdir= parameter_________________Web Programming - Pet Packaging 100 & 101

Oh well, no problem. Give dir2pet a bit of a makeover in Xdialog (I haven't yet figured out how THAT works) and we'll call it 0.2.0 ?

EDIT:

I sorta meant having make install not actually install the program, but it's okay.

At this point just make dir2pet do its stuff in Xdialog instead of to stdout.

Maybe name it something else, and include it with our tool, so the original dir2pet remains for those who prefer stdout to Xdialog. For now we'll indicate that, and if dir2pet as a script gets overall adopted as a different way we aren't stepping on someone else's toes, I'd think. But that's up to you since you're doing this and 4.4, so you make the call on that.Last edited by Gedrean on Tue 20 Oct 2009, 17:14; edited 1 time in total

Hi,
a small user experience feedback:
for people compiling/packaging few packages at the same times, do not start more than one new2dir script (or derivative script) at the same time,
otherwise you will get a mix of packages.

regards,

NB:Regarding compilation flags, checking what others are doing :freeBSD, gentoo, slackware,... it seems they all go and advice for minimal customization.

Hi,
a small user experience feedback:
for people compiling/packaging few packages at the same times, do not start more than one new2dir script (or derivative script) at the same time,
otherwise you will get a mix of packages.

regards,

NB:Regarding compilation flags, checking what others are doing :freeBSD, gentoo, slackware,... it seems they all go and advice for minimal customization.

We know that they advise that. Part of what the flags that were chosen is to do is to cut size down a lot (largely because Puppy is for older lower-profile PCs) or to compensate for slow computers by speeding up boot or run times.

And thanks for the suggestions, it does help us to know that.
Mostly this is intended as an autocompiler, and the flags, as noted, should work about 99% of the time -- so far they have, I haven't had compiles fail because of those flags. Any compiles that do fail I try without pcompile and get the same results with no flags, just config options. Mostly they're just either badly coded software, or software expecting a depend of a diff version than I have, or stuff that for one reason or another just won't compile in Puppy. Evar.

src2pkg can handle concurrent packaging -as many as you like.
Also, since your tools use installwatch, you should use the updated version or my fork of the project called sentry as it will catch a *lot* more of the files and changes than the old installwatch. Nearly all my changes were incorporated into the installwatch git repo, or you can just link installwatch to sentry.
You can get sentry here:

Really, don't try to be so fancy with CFLAGS/LDFLAGS -using -Os will let gcc do all that for you without any other options -it knows which options do what -even when we don't. You'll save tons more size by carefully choosing config options anyway. Even aggressive stripping is not always a good idea -you try to shave a very few bytes off and wind up with something unusable. src2pkg does include the ability to strip aggressively, but it is not on by deafult. If you want to easily strip aggressively, just use 'sstrip' instead of strip.

The only thing I have against src2pkg is it doesn't build a PET natively, it builds a different package type, then we can sorta convert to PET, but it seems a bit roundabout.

Quote:

Also, since your tools use installwatch, you should use the updated version or my fork of the project called sentry as it will catch a *lot* more of the files and changes than the old installwatch. Nearly all my changes were incorporated into the installwatch git repo, or you can just link installwatch to sentry.

Thanks for the information. Installwatch comes on the devx SFS, so it's not really replaceable the way we want to, and new2dir (which was written by BarryK) is what we based 2dirs off of, and it uses installwatch -- so it's kinda hard to migrate. Though looking at Sentry is definitely in my to-do list and it may also get into techno's, as a replacement for installwatch in devx from now on, as long as it has the same interface and return style.

Question though, does that "all my changes were incorporated..." mean the new installwatch, and your Sentry, function identically?

Quote:

Really, don't try to be so fancy with CFLAGS/LDFLAGS -using -Os will let gcc do all that for you without any other options -it knows which options do what -even when we don't. You'll save tons more size by carefully choosing config options anyway. Even aggressive stripping is not always a good idea -you try to shave a very few bytes off and wind up with something unusable. src2pkg does include the ability to strip aggressively, but it is not on by deafult. If you want to easily strip aggressively, just use 'sstrip' instead of strip.

Well that's good to take into consideration, but as I said the flags chosen here aren't really causing any problems yet. Probably for 0.2.0 the defaults might get changed to just the optimize, architecture, mtune and the like.

Does it, as I am hoping severely and suspecting and wondering, make copies of any overwritten files before they are overwritten, allowing the state of the machine to be reverted after installation, and not losing files that were installed?

I am all about upgrading any parts of the devx in 4.4, so I will have a look at updating installwatch/sentry. I have heard a couple of complaints about new2dir missing some things and also having some random parts of the source tree in the final dirs, so it is definitely worth a look.

amigo wrote:

... just use 'sstrip' instead of strip.

Yes 'sstrip' does better than 'strip' but if you later run strip on an sstriped binary it becomes completely unusable (at least on the versions I tested), since the woof build environment does this (optionally) that would really be a bad idea and you only save like 1-2kb anyways over normal strip. removing the .notes and .comments sections left by gcc is pretty safe though to make up for the difference. I don't know if sstrip does that or not. --strip-unneeded is good enough and have not had any problems except with e3 which is configured to build out of the box as a binary that resembles an sstripped binary (not your typical gcc + elf format) Note that e3c does not have this problem because it makes a traditional style elf executable_________________Web Programming - Pet Packaging 100 & 101

I am all about upgrading any parts of the devx in 4.4, so I will have a look at updating installwatch/sentry. I have heard a couple of complaints about new2dir missing some things and also having some random parts of the source tree in the final dirs, so it is definitely worth a look.

I KNEW IT!

I've had built programs including bits of the source tree in the new2dir/2dirs/dir2pet group. Annoying as HELL.

All my changes except one (I think) were included upstream, but sentry uses exactly the same syntax, so you can simply symlinkg installwatch to sentry.

The --backup function does exactly as you describe -any file about to be overwritten is copied over to the backup area and is then available to be written back. This is a really cool feature and is fully usable with src2pkg using the '-SAFE' option -it guarantees that your system will be the same as before -even before packing is finished.

As far as not making pets directly, I did post a patch here which makes src2pkg do that -except I didn't quite have all the details correct with the md5sums, I think. A small alteration with the 'correct' method as used for tgz2pet should fix it. Barring that, simply creating a normal tgz/tbz/txz package with src2pkg and then running tgz2pet would still be much simpler than running the several commands you are currently using.
Another thing you might find useful is that src2pkg uses a patched version of tar which works directly with pets -it 'knows' that they are tgz's so you don't have to do all the renaming and re-renaming. Also, the tar version used by src2pkg (very old tar-1.13) is used purposely because of some special behaviours which are not available in later versions -having to do with the way it preserves perms/properties of links, dirs and files. This is why slackware and src2pkg still use it.

One of my collaborators has gotten src2pkg creating *.deb packages (which was in my plans all along -as well as rpm's), so I may roll the pet-creation code back in along with the other varieties. As mentioned already, the real 'problem' with building pets is that they break so many of the 'rules' of what constitutes a 'sane' package, so some of src2pkg's best investigations and corrections would have to be overridden to allow for pet creation.

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum