Support DEB Files

[quidryan]

First, let me say that you're a genius for figuring out how to hijack the CopySpec piece of Gradle. It's definitely the most Gradle-esque way of creating an rpm. It's also generic enough that it could describe the building other system packages. I feel that with some tweaks, the same system could be used to create debs too. I started work on this, and have it working.

https://github.com/quidryan/gradle-rpm-plugin/tree/add-debian-support

It stills need tests in a few areas and some docs, but otherwise it's done. I'd like to get your opinions before submitting the pull request though. What do you think about Deb support in the same plugin? What do you think about using an Extension, which can be shared between all tasks (Rpm or Deb)? E.g.

apply plugin: 'rpm-package'
ospackage {
     arch = I386
     os = LINUX
     into '/opt/foo'
     from('lib') {
        into 'lib'
    }
}
task fooRpm(type: Rpm) {
     packageName = 'foo'
     release = 1
}
task barRpm(type: Rpm) {
     packageName = 'bar'
     arch = X64
     release = 1
}

or

apply plugin: 'os-package'
ospackage {
     packageName = 'foo'
     release = 1
     into '/opt/foo'
     from('lib') {
        into 'lib'
    }
}
task fooRpm(type: Rpm) {
    arch = I386
    os = LINUX
}
task fooDeb(type: Deb) {
}

While an extension is nice, it's sorta necessary when building for two types of packages, which is why I added. Things do get a little weird when trying to specify "os" property in the extension, but it's worth it. Unless we say non package specific stuff in the extension, but that means you can't do the first example.

If this or Deb support isn't a direction that you'd like to go, that's fine. In that case, I'll make sure to rebrand the plugin and give you tons and tons of credit.

[AlanKrueger]

Does your fork suffer from this issue? https://github.com/TrigonicSolutions/gradle-rpm-plugin/issues/30

I'm thinking that might be related to the way I was hooking the CopySpec, but I haven't been able to spend much time on it. (Relocating across the country and working for a more demanding job means I spend a lot less time on this stuff.)

On Tue, Jun 11, 2013 at 2:19 PM, Justin Ryan notifications@github.comwrote:

First, let me say that you're a genius for figuring out how to hijack the CopySpec piece of Gradle. It's definitely the most Gradle-esque way of creating an rpm. It's also generic enough that it could describe the building other system packages. I feel that with some tweaks, the same system could be used to create debs too. I started work on this, and have it working.

https://github.com/quidryan/gradle-rpm-plugin/tree/add-debian-support

It stills need tests in a few areas and some docs, but otherwise it's done. I'd like to get your opinions before submitting the pull request though. What do you think about Deb support in the same plugin? What do you think about using an Extension, which can be shared between all tasks (Rpm or Deb)? E.g.

apply plugin: 'rpm-package' ospackage { arch = I386 os = LINUX into '/opt/foo' from('lib') { into 'lib' } } task fooRpm(type: Rpm) { packageName = 'foo' release = 1 } task barRpm(type: Rpm) { packageName = 'bar' arch = X64 release = 1 }

or

apply plugin: 'os-package' ospackage { packageName = 'foo' release = 1 into '/opt/foo' from('lib') { into 'lib' } } task fooRpm(type: Rpm) { arch = I386 os = LINUX } task fooDeb(type: Deb) { }

While an extension is nice, it's sorta necessary when building for two types of packages, which is why I added. Things do get a little weird when trying to specify "os" property in the extension, but it's worth it. Unless we say non package specific stuff in the extension, but that means you can't do the first example.

If this or Deb support isn't a direction that you'd like to go, that's fine. In that case, I'll make sure to rebrand the plugin and give you tons and tons of credit.

— Reply to this email directly or view it on GitHubhttps://github.com/TrigonicSolutions/gradle-rpm-plugin/issues/36 .[image: Web Bug from https://github.com/notifications/beacon/Q__N7IhZ1wBYuxvooaGvn1lldWBJZW5OPHO_PDRJt8mRa1YEjMXvlGYuKIKacpRN.gif]

[quidryan]

Things are structured differently, so it's entirely possible that this is fixed. Is there a unit test that shows this problem?

I'm starting to look at using @Category to see if can help isolate the additional fields on CopySpec to just this plugin's configure blocks.

[quidryan]

I see the problem too, I'll continue that conversation over on issue #30.

[jacek99]

+1. DEB support would be great.