I just wanted to say how much I like the way this is progressing, the sourcetemplate options is a really great time saver. It's nice to have the tool always stay up-to-date with changes in the packaging process.

Hmm. I'm having a similar problem. I have buildpkg1.4.3 installed, and running the patch gives me this:



Any idea what I'm doing wrong?

It seams that every time I post a patch in the forum no one seems to can apply it(including me)

here's a link to it

things I'm considering adding to buildpkg:
* delete directory usr/doc/$pkgname-$pkgver if empty
* delete zero length files in usr/doc/$pkgname-$pkgver
* look for pkgconfig .pc in source and adding them to usr/lib/pkgconfig
* check it is needed to add code to handle info pages, this one does two checks, the usr/info and if install-info is in the doinst.sh before adding the necessary code.
* add code to handle all file in etc to be handled by dotnew, if no dotnew is specified in the ZENBUILD and the etc directory exists.
* remove the usr/info/dir file if present

comments and suggestions are welcome, including new additions or something of the above list that shouldn't be added...

What a name! Thanks, that worked a treat. Now I just need something to build to test it out....



Those all sound useful. Something I've been wondering about for a while is a 'suggests' option. I've seen some packages (using Gslapt under Vector) which have a 'suggests' option to specify files that are not required by would be useful. For instance, the MC rebuild that I did a few days ago could usefully have a 'suggests' file which includes lzma and dar. There are other examples where a package would be useful for full function, but is not a dep in the normal sense of the word. Not sure if there is any easy mechanisim to include that though...

In fact, as an example, you are detecting info files to work out how to handle them. If an info file is detected, it would be useful to 'suggest' texinfo and possibly pinfo as well.

paul.

All those are out of buildpkg scope, this is something to be done both at the repo level and in netpkg, only then can buildpkg also take advantage of the suggests in PACKAGES.TXT
Gapan would also probably like it at least for gst-plugins

New version: v1.6.0
CHANGELOG:
* delete directory usr/doc/$pkgname-$pkgver if empty
* delete zero length files in usr/doc/$pkgname-$pkgver
* check it is needed to add code to handle info pages, this one does two checks, if the usr/info directory exists and if install-info is in the doinst.sh before adding the necessary code.
* add code to handle all file in etc to be handled by dotnew, if no dotnew is specified in the ZENBUILD and the etc directory exists.
* remove the usr/info/dir file if present
* added a "ls -lR $startdir/pkg" to create_package so that all files permissions and ownerships would be appended in the log file, suggestion by George Vlahavas

I've been fighting this new feature all day long trying to build a VirtualBox 2.0.0 package. As part of the installation, I need to install two files, rc.vboxdrv and rc.vboxnet into the /etc/rc.d/ directory. doinst then runs the rc.vboxdr script to build a vbox kernel module and starts it. This allows VirtualBox to start without any post installation user configuration; a prime directive of ZW packageing
With this code in buildpkg now, it adds the ".new" to these files names even thought i did not add them to the "dotnew" directive in the ZENBUILD. Now when upgrading from an older package the new rc scripts don't get installed and the old one remains. doinst then starts the old rc script which points to non existing directories and the module does not get built. The user, of course, will not see this and when he tries to start VirtualBox he get a messages the the kernel module needs to get built. Unless he smart enough to do a "netpkg dotnew" attempts to build the modules as instructed by the error message will continue to fail. I finally figure this out by doing a diffs of build files from a prior Virtualbox builds and determine the the current package in the repros (1.6.4) has this problem also.
For now I'm commenting out those lines in buildpkg, but I suggest that this feature get reconsidered. I understand that configuration file should not get updated without the user knowledge; but should all the files in /etc/ be handle this way? Why have the dotnew directive then?
Thanks
Rich

Personally I think the automatic handling of dotnew files is a good idea, but laprjns has an excellent point: it messes up some packages. Perhaps a simple command-line option to turn it off would be appropriate? I think it should still be on by default though.

Why? Isn't this what the "dotnew=()" in ZENBUILD is for?
So, in my case that would mean that I would purposely not include the files in the dotnew statement, but buildpkg would tag all files in /etc with .new unless i remember to turn it off via the command line option? Makes no sense to me . And what do I do if some of the files need the .new tag and some others don't?
Seems to me the the original concept of the "dotnew=() statement was right. The packager needs to be aware that some files, maybe most, in /etc can't just be overwritten on upgrades and needs to allow the users to chose to over write them. Don't get me wrong, I think buildpkg is a wonderful tool, allowing people like me to be able to package. But I think you cannot totally eliminate the need for the packager to understand what his package is doing during the installation and how that can effect the users systems.
Thanks
Rich

The reason I advocate automatic dotnew handling is that before it was implemented, there were many packages that lacked proper dotnew files where they should have been. If all packagers just used the "dotnew=" line in their ZENBUILDs that would fix the problem too. Perhaps packages should simply be not allowed through the Testing section if they have files in /etc that should be dotnew files, but aren't? That way we could go back to the old way, or better yet add an option inside the ZENBUILD to turn automatic dotnew handling on.

Why not like that:

• No dotnew=() statement every file in etc will become dotnew
• Empty dotnew=(), the packager wants to decide which files will become dotnew, if he doesn't want any to become so, he'll just leave it empty
• dotnew=(aaa ... zzz) The packager wants only the specified files to become dotnew, similiar to the above point

Or you use a similiar design to requiredbuilder combo of black- and whitelist.

Here's another solution I like with nodotnew and dotnew.

-By default all files in /etc will become dotnew (like now)
-nodotnew can be either used to choose the file not to become .new or to overwrite the default with nodotnew=('/etc')
-dotnew can be used to pick single files e.g. when the default was overwritten with nodotnew or when the packager wants to choose files outside of etc

Hi,

I'll have some free time to work in buildpkg during next week (22-26/09)

As to the dotnew, the default behavior will not be changed, but an "advanced" option do disable this new feature will be added.

Ideas are welcome

Regards,

I really like this idea, I think it makes a lot of sense and should be able to do everything we need it to. If you're still looking for suggestions, I vote this idea. Plus, this idea will be completely backwards compatible with old ZENBUILDs.

I just don't agree too much with the empty dotnew ain't all that intuitive, my idea was an option in the ZENBUILD something like no-auto-dotnew or something similar, this way it stays better documented. No?

Any more suggestions are quite welcome.