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?
#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 [email protected]:

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//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.