Re: buildpkg - a new way to build packages

imitis · **Posted:** Thu Jun 14, 2007 7:13 pm

I really like it this way!!!

sega01 · **Posted:** Fri Jun 15, 2007 2:17 am

I think that this would help speed up creation of new packages, and help standardize some aspects of package building. The fact that it produces shell script buildscripts instead of packages means that there are no extra requirements. It is nice to remain 100% compatible with the current system. Great job on the coding, I will probably use this for some of my own packages, and put into d/ on Zenserver :-).

Thanks,
sega01

Borromini · **Posted:** Fri Jun 15, 2007 6:57 am

Well, as a big fan of package building frameworks, I can only applaud this

.

Great job bruenig!

m4xr8d · **Posted:** Sat Jun 16, 2007 8:33 pm

Thank You. I can not believe how easy this makes packaging. I really appreciate the work that goes into your scripts. Thanks Again

_PN_boy · **Posted:** Sun Jun 17, 2007 5:29 pm

Hi,

some suggestions:
* sometimes the usual CFLAGS don't work so a way to bypass that could be useful, those would stay as default unless something else is specified in the ZENBUILD
* the icon extension on the .desktop file
* the docs to be copied could be placed in some variable in the ZENBUILD
* one cool stuff to be implemented could be something like this:
imagine U have to add something to existing file, example add "DICT pt PT pt_PT" to usr/share/myspell/dictionary.lst a script that could do that would be great, the script would do something similar to the dotnew function posting like this:

Code:

if ! grep -qe "^DICT pt PT pt_PT" usr/share/myspell/dictionary.lst; then echo "DICT pt PT pt_PT" >> usr/share/myspell/dictionary.lst; fi

this would obviously have to be configured also in the ZENBUILD, only the text(s) do search and the file(s) to patch

really nice work so far

Feel free to contact me privately if U want to discuss this or other features, I really appreciate Ur work on this

Regards,

Jokas · **Posted:** Sun Jun 17, 2007 6:29 pm

hey, can i suggest something.
I know i'm being a kind of irrealistic, but what if someone develop a way to make packages through a GUI?? I've never seen it before in ny distro. I don't know if it could be done or even if it's easy to do ( nothing ever is

), but it would be great. Imagine, you download a package source, input it in the GUI, select some options if needed, and you would be done. It could then output if everything is fine or if any dependencie is at fault

.

I know that maybe i'm saying bullshit, cuz actually i dont really know how to make a package from source ( but i'm willing to learn ), but imagine if wouldn't catch a lot of users ::)

_PN_boy · **Posted:** Sun Jun 17, 2007 7:30 pm

bruenig wrote:

* The docs thing you are talking about is already implemented except in an automatic form. Basically it used a find ignore case search for authors, changelog, copying, install, news, and readme. And then upon finding anything matching those it copies them over into /usr/doc/$pkgname-$pkgver.

I was referring to some non-standard that also have to go there, per example:
* d4x: ABOUT-NLS AUTHORS COPYING ChangeLog INSTALL NEWS PLANS README TODO
* acroread: Reader/Legal/ENU/license_ENU_uc.txt Reader/help/ENU/ReadMe.htm $TMP/AdobeReader/LICREAD.TXT $TMP/AdobeReader/INSTALL
* amsn: AGREEMENT CREDITS FAQ GNUGPL HELP INSTALL README TODO

some of those file wouldn't get to the package

bruenig wrote:

* The add something to an existing file would need to be done in doinst() which is already implemented.

I was referring to an automatic way, similiar to the one U've implemented for config() in the doinst.sh

brinstar · **Joined:** Sun May 13, 2007 12:51 pm **Posts:** 95

thanks again for this bruenig, awesome tool for us noobs

_PN_boy · **Posted:** Mon Jun 18, 2007 7:15 am

bruenig wrote:

I have implemented extradocs= to allow the moving of docs that don't fit into the automatic moving.

Nice

bruenig wrote:

As for the changing one file thing, I don't think it is prevalent enough to necessitate its own feature. I would like to keep the options as light as possible while still allowing everyone to package whatever they want. You can add such a thing to the doinst() function on occasion that it is necessary.

Fair enough, it was just a suggestion

DodoFXP · **Posted:** Mon Jun 18, 2007 3:19 pm

@Jokas

I suggested the same thing a couple of months back, but with this new "technique" (:D) it could work: we would have a GUI tool which gets the input from the user through textboxes and in return dumps a ZENBUILD which is then fed to buildpkg.
I am still wondering about the name "ZENBUILD". i would prefer to see it with some extension at least indicating the package it is describing. Something like "ZENBUILD-$pkgname".
Otherwise: THUMBS UP, AMIGO!

DodoFXP · **Posted:** Mon Jun 18, 2007 4:44 pm

the point of there being two zenbuild-$pkgname will also happen if you have two normal ZENBUILDs.
I would first of all use pure lowercase. =) I prefer typing straight rather than pressing shitf all the time =)

DodoFXP · **Posted:** Mon Jun 18, 2007 5:17 pm

Ah, so you meant having a zenbuild-$pkgname1 and zenbuild-$pkgname2 in the same folder? Sawa. Now i get it.

_PN_boy · **Posted:** Mon Jun 18, 2007 8:16 pm

U should make the created build script check for the presence of the source file, and refuse to run(or download the source) if it ain't present.

trying to run without the source file present will give this:

Code:

./build-alltray.sh
cp: cannot stat `alltray-0.69.tar.gz': No such file or directory
tar: *.tar*: Cannot open: No such file or directory
tar: Error is not recoverable: exiting now

Regards,

_PN_boy · **Posted:** Tue Jun 19, 2007 6:58 am

An exclude feature might be useful(yes, I know it can be done in the doinst.sh/build(), but this way is cleaner) something like:

Code:

exclude=( usr/lib/liballtray.la )

that would remove the files listed there from the package, it would deleted them, before makepkg

prfaasse · **Posted:** Tue Jun 19, 2007 2:52 pm

I have yet another suggestion: 'undeps': Some of my packages end up 'depending' upon things like mysql. That is however a plug-in dependency: the result does run ok without it, but there are references to it in the resulting package.

Please consider it a 'suggestion only'

Re: buildpkg - a new way to build packages

Who is online