From: George V. <vla...@gm...> - 2010-08-26 19:26:02
|
2010/8/26 Thorsten Mühlfelder <the...@gm...> > currently every packager manages his SLKBUILDs at home and after creating > new > packages they are uploaded to the source directory. This leads to the > following problems: > Honestly, I don't see any problem at all. > * If a bug in a package is reported in the forum, someone may fix that in > the > SLKBUILD and upload the new one to the source dir. But then it's mandatory > that the package maintainer get's the updated SLKBUILD. So he must be > informed about it. > Of course. An email would be enough in that case. Not too much to ask, simple and effective. > * Last time when I've created the current branch I had to update *a lot* of > gapan's packages, too. So he had to get all these SLKBUILDs from the source > dir again to maintain them further. > So? All updated packages were listed in the changelogs, I knew what to get. Not a big deal. * If someone uploads a package for e.g. i486 only and I want to add it to > the > x86_64 branch That is never going to happen. All packages should be updated and are updated at the same time in both i486 and x86_64 repositories. > I may have to tweak the SLKBUILD because it was not x86_64 > ready before. Then I have to send the SLKBUILD to the maintainer again. > Still don't see a problem here though. Communication should be encouraged in any case. > Most of our SLKBUILDs are multiarch capable (I cannot remember where > different > SLKBUILDs for different arches are really needed. It should always be > possible to tweak the SLKBUILD so that it can handle all arches). > > My suggestion now is to create some system where every packager first pulls > the most recent SLKBUILDs, then modifies them and uploads them back. This > should be a standardized process for official packa,gers. > We currently have the source dirs where all SLKBUILDs could be obtained, > but > there are problems: > * every arch has own SLKBUILDs. Tweaking it for one arch wold need > uploading > them to different locations. > Yes, we have different source repositories for each arch, because we actually have two arches. But no, if the package is not updated in both arches, the SLKBUILD should not be updated in both source repos. You're forgetting the fact that the source repos should not hold the latest source files. The should always hold the source files that were used to build the packages that are present in the repositories at each given time. And they should be split by salix/slack version. So in a case like this, if a different SLKBUILD has been used for the different arches, different SLKBUILDs should be in the source repo, irregardless of which one is the best/latest. * Getting every SLKBUILD by hand before building a package is not a good > idea > Why not? In any case, the SLKBUILD is usually already in the packagers hard drive. If someone else updated it in the meantime, the packager should have been informed by an email personally, or this mail list. So he would still have the SLKBUILD in his hard drive. Perhaps we could create a single dir for the multiarch capable SLKBUILDs and > then just use some rsync to keep scripts up to date. > Bad idea. What if a package gets updated only in one arch? Maybe because of a problem that is arch specific (like slapt-get was only updated in the i486 repo recently). Do we move packages in and out of that multiarch source repo all the time? It can become a really huge mess really fast. But IMHO the better solution would be a real version control system. Then it > would be possible to update all SLKBUILDs with a "svn update", edit some of > them, build new packages, upload the packages and put the updates SLKBUILDs > to svn again. > This would create the need to manage this version controlled repo separately. As it is now, it is really simple: 1. Upload new package to the binary repo 2. Upload the source to the source repo If we have such a repo, at least an additional step would be required: 1. Upload new package to the binary repo 2. Update the source files in the source tree 3. Sync the source tree. which adds complexity and that's never a good thing. Since I am the one that does the most work with the repositories, I don't welcome the added complexity. The simplest solution is always the best. All that said, if you have something concrete that will make my life easier instead of harder, I wouldn't mind at all. |