package maintenance

Old stuff that should not bother anyone anymore
Shador
Posts: 1295
Joined: 11. Jun 2009, 14:04
Location: Bavaria

Re: package maintenance

Post by Shador »

I suggest that everything stay like it is for buildpkg except that it doesn't anymore create source files. The uploading consists of two steps uploading the package(-related) files and uploading the source files. The .src file isn't anymore generated by the user that's done by the upload tool with the right URLs on the server. Instead of providing the upload tool with local files you can also feed it with URLs which it will download and put the the URL to the downloaded file on the zw server in the src file. (Or as an alternative uses the provided URL for the source file and downloads it without using it in the src file)
If somebody wants to build a package, he must only download the src file and download all the files mentioned in it. Than he can just run the SLKBUILD (which is also in the src file) or modify it first. Nothing apart from the files in the src file needed.
IMHO that makes it a lot easier for new packager, which don't have webspace.

Instead of removing src file generation completely form SLKBUILDs, you could change it to generate one file containing the paths to all the package files and one file containing the paths or URLs of the source files.. Then you can just feed that file to the upload tool, which will speed up the process.
Image
User avatar
gapan
Salix Wizard
Posts: 6238
Joined: 6. Jun 2009, 17:40

Re: package maintenance

Post by gapan »

I can see the uploading become tedious for me, if I want to upload dozens of packages at a time, like I often did in zenwalk... :?
Image
Image
User avatar
JRD
Salix Warrior
Posts: 950
Joined: 7. Jun 2009, 22:52
Location: Lyon, France

Re: package maintenance

Post by JRD »

Ok, so we must also kept that in mind...
Image
Shador
Posts: 1295
Joined: 11. Jun 2009, 14:04
Location: Bavaria

Re: package maintenance

Post by Shador »

That's what I tried to handle especially with this. If you were uploading many packages you would only have to select those 2 files and then the rest would happen automatically.
Shador wrote:Instead of removing src file generation completely form SLKBUILDs, you could change it to generate one file containing the paths to all the package files and one file containing the paths or URLs of the source files.. Then you can just feed that file to the upload tool, which will speed up the process.
To make it clear something like this:
pkgfile:

Code: Select all

file:///home/shador/packages/spring/spring-0.79.1-i686-1ab.txz
file:///home/shador/packages/spring/spring-0.79.1-i686-1ab.dep
file:///home/shador/packages/spring/spring-0.79.1-i686-1ab.md5
srcfile:

Code: Select all

http://spring.clan-sy.com/download/spring-0.79.1.tar.bz2
file:///home/shador/packages/spring/weird-issue-weird-patch.diff
file:///home/shador/packages/spring/SLKBUILD
I think that's significantly less to select than uploading .txz .dep .md5 .src and whatever is needed apart.

Those 2 files should of course be generated automatically by slkbuild. The difference is that you mustn't specify URLs for the sources or the package files.
You just pass that two files to the Upload page:
  • pkgfile: all the files are uploaded for file:// or downloaded from the URL for http:// or ftp://, changelog updated by seperate information provided by the user
  • srcfile: again all the files are uploaded for file:// but for http:// or ftp:// nothing is done; in a next step a .src-file is generated from this information:
This means that the user just provides what he used to build the package, the resulting package files and the changelog (maybe via drop down (Updated, Added) and description (new version, fixing security issue)) and the server does handle all the rest (i.e. uploading, src file generation, changelog updating, file placing).
The pkgfile and srcfile files should be automatically generated by slkbuild but could also be written/modified by hand. Of course you would have to regenerate/modify/rewrite them if you move the directory before uploading the package.
Image
User avatar
JRD
Salix Warrior
Posts: 950
Joined: 7. Jun 2009, 22:52
Location: Lyon, France

Re: package maintenance

Post by JRD »

Very good solution, for both mass packagers and for occasional packagers.

This solution is really good !!
And people could host their packages or just upload them, whatever they prefer.
Is there anybody against this solution ?
Image
User avatar
gapan
Salix Wizard
Posts: 6238
Joined: 6. Jun 2009, 17:40

Re: package maintenance

Post by gapan »

Hmmm... why do we need 2 files? pkg and src? src files was the only sane way I could think of to manage the sources in zenwalk, since the sources repo and the packages repo belonged to different users and JP never cared to make it easier.

a single .pkg file could be separated by the server to the {.t[gbxlz],.md5,.dep} files and all others which can only be source files. So for each package, the packager uploads a single pkg file. Couple that with multiple uploading of .pkg files and it's very easy to upload any number of packages.

However... on the other hand, someone that doesn't use slkbuild to create his packages, won't be bothered to create a .pkg file by hand and submit it...
Image
Image
User avatar
JRD
Salix Warrior
Posts: 950
Joined: 7. Jun 2009, 22:52
Location: Lyon, France

Re: package maintenance

Post by JRD »

Ohhh I understand...and you're right. Even simpler with one file.
Image
Shador
Posts: 1295
Joined: 11. Jun 2009, 14:04
Location: Bavaria

Re: package maintenance

Post by Shador »

I also though about putting everything in one file but decided agains because... for actually no reason. :mrgreen:
I prefer that solution with one file now though.
gapan wrote:So for each package, the packages uploads a single pkg file.
Do you mean the .pkg file is a tar archive? Because otherwise the .pkg file is the only file he has to select for uploading but the other files have to be uploaded/ downloaded, too.
gapan wrote: However... on the other hand, someone that doesn't use slkbuild to create his packages, won't be bothered to create a .pkg file by hand and submit it...
I don't really understand you here. :?: Do you mean that it's a disadvantage for users not using SLKBUILDs that they have to create the .pkg file by hand?

Anyway I'm really against falling back to the old builscripts for no special reason. A unified build system is much easier to understand. If I think about some people's build scripts it's really painful to just understand what they do. A SLKBUILD just shows the non-redundant stuff and makes it really easy and usually all you have to provide is really just the build and install part. It also makes it easier or even possible in some cases to package once or twice with other peoples SLKBUILDs or to take the package over. For some special packages like the kernel e.g. I cam understand that a buildscript with full control over everything is easier to maintain and to understand.
Image
User avatar
gapan
Salix Wizard
Posts: 6238
Joined: 6. Jun 2009, 17:40

Re: package maintenance

Post by gapan »

Shador wrote:
gapan wrote:So for each package, the packages uploads a single pkg file.
Do you mean the .pkg file is a tar archive? Because otherwise the .pkg file is the only file he has to select for uploading but the other files have to be uploaded/ downloaded, too.
Sorry, I mean one file to choose for uploading...
gapan wrote:I don't really understand you here. :?: Do you mean that it's a disadvantage for users not using SLKBUILDs that they have to create the .pkg file by hand?
Of course.
gapan wrote:Anyway I'm really against falling back to the old builscripts for no special reason. A unified build system is much easier to understand. If I think about some people's build scripts it's really painful to just understand what they do. A SLKBUILD just shows the non-redundant stuff and makes it really easy and usually all you have to provide is really just the build and install part. It also makes it easier or even possible in some cases to package once or twice with other peoples SLKBUILDs or to take the package over. For some special packages like the kernel e.g. I cam understand that a buildscript with full control over everything is easier to maintain and to understand.
Remember that this is slackware and people have already a huge selection of slackbuilds that they might want to use. Also slackware users often take pride in their slackbuilds, so we should at least give them the option to use whatever they want.
Image
Image
Shador
Posts: 1295
Joined: 11. Jun 2009, 14:04
Location: Bavaria

Re: package maintenance

Post by Shador »

slackbuilds are at least somehow unified, are they? I also have had only positive experiences which slackbuilds always beeing very readable. What I just don't want are messy buildscript which are even for the creator hardly understandable. So slackbuilds, SLKBUILDs and ZENBUILDs really are no problem (though ZENBUILDs are that easy to convert to SLKBUILDs that we should make it somehow obligatory :) ).
As long as the scripts stay readable and are well structurized (i.e. it should be easy to find the build section for example) and follows common established 'standards' (like variable names (mustn't be exactly the same) or code flow) I have no problem with them.
I think we should also push (not force) users to build new packages for Alcoholix with SLKBUILDs.
Image
Locked