Hi,

I have been in charge of managing the sources in Zenwalk. For doing so, I defined a format for getting the sources, a source repository format, and beginning in getting and providing source packages.

Here are the recommendations that are to add to the existing recommendations for packagers :

There are three cases :

1. You build a package with a ZENBUILD file. In this case, you don't have to do anything more than before, the sources are normally already defined in the ZENBUILD file.
   
2. If you don't use ZENBUILD yet, then you must provide the sources used (internal and external sources), one per line in a file PKG_NAME-noarch-RELEASE.src
   Example:
   For the package hal-0.5.10-i486-50.2.tgz
   The file hal-0.5.10-noarch-50.2.src must be created which contains 4 lines:
   
   Code:
   http://hal.freedesktop.org/releases/hal-0.5.10.tar.gz
   http://users.zenwalk.org/user-accounts/gapan/hal/rc.hal
   http://users.zenwalk.org/user-accounts/gapan/hal/hal.txt
   http://users.zenwalk.org/user-accounts/gapan/hal/zen-users.patch
   
   In fact, sources could often be found in the slackbuild comments. I already developped a little tool for extracting these informations, I'll post it quickly
   
3. If the package comes from Slackware, and not always from a even/public version. In this case, the file PKG_NAME-noarch-RELEASE.src should also be written, using the files found on the Slackware ftp.

Is it understandable ?

If I resume:
— If you have a package that use a ZENBUILD file, you have to provide:

— If you have a package that don't use yet a ZENBUILD file, you have to provide:


Feel free to send me comments/corrections.

Why -noarch-? Wouldn't it be better if the src file had the same arch as the package it provides sources for?

And you picked up the wrong package for a non-ZENBUILD example. Hal is actually built with buildpkg. Anyway, you made your point.

Hi,



Well...it's actually noarch, no architecture in source(usually)

buildpkg can also be done to create the .src file, If U feel it make things simpler for U

EDIT: BTW...what should be the contents of that .txt file? the slackdesc?

Regards,

OK, but won't these specific sources with included buildscripts create a package that has a specific arch? Depends on how you look at it I guess.

Uhmm... am I missing something? The .src file does not have links to the buildscript/ZENBUILD? If not, shouldn't it?

Yes -noarch- cause the sources is not really assigned to a specific architecture.

The .src doesn't list the buildscripts or anything else than sources or patches, so no it isn't bound to an architecture

I know that buildpkg could be easily modified to create .src file, but it is not needed if the file could be generated

.txt file is the slackdesc file yes. I remembered it is named .txt but maybe I wrong. The previous rules for packaging is ok, it's probably an error of my own.

To answer gapan about linking the buildscripts and the sources, these are done on the sources repo (http://zenwalk.enialis.net/sources/) by making a PROG-VER-SRC-RLZ.tbz package, containing the buildscripts (eventually the ZENBUILD file), the .src file, the .dep file, and the sources. These type of packages contains everything to build the binary package, without getting anything else (appart dependancies).

P.S. Thanks bruenig & _PN_boy for buildpkg/ZENBUILD tool

Should the slackdesc contain also the handy-ruler and classic header?
Or the 11 description lines would suffice?

Cheers :-)

If you use a ZENBUILD file for making a package, you don't have to worry about this.

Else, yes the software name msut be present, like the handy ruler. All is explain here for the old way of building a package.

Thanks. Of course I know the software name must be present... I was wondering about the handy-ruler... is it really necessary? :-) (it's a bit tedious insert it correctly in my scripts...).

I can provide the new .src also for my packages already in the repo, if needed.
Let me know

Cheers

For the necessity of the handy ruler, sorry but I don't know. Maybe fredg or Axxium or JP will better answer you about this.

Indeed, it's surely not necessary , it is just useful to write the lines in the correct way...
If we decide to include it I think it's just a matter of esthetics ;-)
I'll skip it for the moment.

Cheers :-)

I would prefer an src file having the same name as package (i486, not noarch).

Even if "noarch" would be more logical, I agree

JP

hurry-up, what are we waiting for ?

JP