Binary packages

[lmello]

Hello folks!

After several months, I decided to package some software for Salix. One of them is written is a double-pane file-manager written in pascal and, well, there are already binary packages for both x86 and x86_64 systems and instead of compiling them (which would require for me to build fpc AND its IDE, Lazarus) I'd like to deliver the pre-build packages instead. I've already tested them and they work OK.

What should I do? Is copying all the files to /usr/lib/doublecmd or /usr/lib64/doublecmd and create .desktop files in /usr/share/applications acceptable for Salix packaging standards?

[Shador]

What should I do? Is copying all the files to /usr/lib/doublecmd or /usr/lib64/doublecmd and create .desktop files in /usr/share/applications acceptable for Salix packaging standards?

I don't think so. Packages should be built from source. The only exceptions I know of are packages like flash where only binaries are avaible or possibly some really insanely difficult to build packages. But I don't think this is the case here.

double-pane file-manager written in pascal

Name?

which would require for me to build fpc AND its IDE, Lazarus

So the fpc package in the repository is not enough? Unlike for hedgewars.

http://wiki.lazarus.freepascal.org/Inst ... _Slackware
Wow! I had just a look at those instructions for building lazarus and it seems less complicated to build because the bootstrapping is not needed. But possibly they're build system is a pain like fpc ones. In any case most striking to me was the requirement to install the whole fpc sources as they are required during RUNTIME. This is crazy! Users need to install sources whose gz-compressed archive already weighs in with almost 25MB!

But it's not impossible either. I guess I could create and maintain a source package for fpc and your build of lazarus could depend on it.

[lmello]

double-pane file-manager written in pascal

Name?

Double Commander.

which would require for me to build fpc AND its IDE, Lazarus

So the fpc package in the repository is not enough? Unlike for hedgewars.

OMG sorry I wasn't aware that fpc was in the repos! The problem is that my Salix installation is in a faulty notebook which heats up and crashes when it's CPU is working 100% of the time.

I will try to make a SLKBUILD for Lazarus and Double Commander and post it, perhaps depfinder won't point out neither fpc and/or Lazarus, as the binary package works well without them.

[Shador]

I will try to make a SLKBUILD for Lazarus and Double Commander and post it, perhaps depfinder won't point out neither fpc and/or Lazarus, as the binary package works well without them.

??? What do you mean?

I just checked double commander and could find no way to build it without a lazarus package. But lazarus and fpc are build-time deps, so I don't know why you mention them with depfinder, which is used to determine run-time deps. Anyway I guess you need a lazarus package for double commander. As lazarus requires the source of fpc, I'll have to do a fpc source package.

Any thoughts on such a source package from the other devs? I don't think we have such a source package anywhere in our repository. Some suggestions:
pkgname=fpc-src

• Files go directly into /usr/src/fpc-$pkgver and the source package. We could set up a symlink named /usr/src/fpc to that directory so we don't have to repackage lazarus when there's a new version. But maybe that's necessary anyway.
• Alternatively files could go into /usr/src/fpc-$pkgver/sources and the same symlink from /usr/src/fpc to fpc-$pkgver could be setup.
• Another idea files are put into /usr/src/fpc-src-$pkgver and a symlink from /usr/src/fpc-src could be setup.

Any better ideas? Or is this a bad idea at all?

@Lmello: Could you please wait until we get this sorted out. I would provide you with a source package once that's done as soon as possible. Shouldn't take much time. And then you could start working on a lazarus package.

[JRD]

For me I vote for solution 3.

[gapan]

I'm not sure about this. Anyway you look at it, it's not really good.

About repackaging the binaries: This should really be avoided, it's certainly preferred to build from source. We have a few packages that are repackages though, the most famous one is firefox of course. I wouldn't even dare to build firefox from source, I did it once or twice in the past, I don't want to do it again. So, if building from source is almost impossible, as is the case with firefox, we could repackage the binaries. But I don't see it as impossible in this case.

And if we go to the building from source route, I really have to ask: is it worth the trouble? It needs yet another package as a dependency and that one is at least a weird package. Only the fpc-sources? Why? And for what purpose? For yet another double-pane file-manager? What's so special about this one, that one of the dozen other double-pane file-managers that are available doesn't offer?

Which brings me to another option with building from source. Instead of having yet another (useless otherwise) package in our repositories, the SLKBUILD for this file-manager could also download the fpc sources, put them where it needs them and build the package.

Keep in mind, that at this point, whatever you submit, will only enter our slkbuild repo, not our main packages repo. So, if you provide an SLKBUILD, you should make sure that the same SLKBUILD works for i486 and x86_64 architectures.

[Shador]

And if we go to the building from source route, I really have to ask: is it worth the trouble? It needs yet another package as a dependency and that one is at least a weird package. Only the fpc-sources? Why? And for what purpose? For yet another double-pane file-manager? What's so special about this one, that one of the dozen other double-pane file-managers that are available doesn't offer?

It's not the file manager that needs fpc-source, it's the lazarus package. Lazarus is the IDE of fpc and needed to build the file manager. So a normal user who just wants to install the file manager doesn't need lazarus, fpc and especially not fpc-source.

As far as I can see this is the only way to provide a working lazarus package.
Of course we could be building doublecommander without a lazarus package in some of our repositories, but I don't think that's such a good idea. The builder would have to get lazarus on his system otherwise.

[gapan]

OK. But I can see there is already an fpc-source slackbuild available in sourcery... So I'm still not sure what we're talking about.

[Shador]

OK. But I can see there is already an fpc-source slackbuild available in sourcery... So I'm still not sure what we're talking about.

Yes, but we have a binary fpc package in our repository. No idea how the slackbuilds package relates to ours. Probably it's fine right now, but that could change easily if we possibly provide a different version than Slackbuilds.

Therefor, as we have a binary package of fpc, I think it's only reasonable to provide a source package as well, which we know is the right one for our fpc and not much work anyway.

[gapan]

OK. You can take a look at how the sbo fpc-source package is structured and create one in a similar way then.