Use separate name for repo & distribution codename/suite about jenkins-debian-glue HOT 7 OPEN

There's $REPOSITORY (for the path of reprepro) vs. $REPOS (for the Codename as used inside $REPOSITORY/conf/distributions) but I don't see $REPOS re-used, so I'm not sure I fully understand what you're proposing. Any chance you could provide a PoC/patch?

from jenkins-debian-glue.

When I build a "release" package, package is uploaded in $REPOSITORY/release/$release and $release is also used in conf/distribution as codename.

What I would like to do is upload package in repo $REPOSITORY/release/$release but use $distribution (like wheezy, squeeze, precise, ..) in conf/distribution.

Maybe I'm doing something wrong but I don't see what.

Will try to provide PoC/patch.

from jenkins-debian-glue.

My bad. Everything happens in /usr/bin/build-and-provide-package and specifically in function release_repos line 614.

I really think we should use ${distribution} there. I'll work on a patch :)

from jenkins-debian-glue.

This is done to have multiple packages of the same release to be placed in the same repo.
If we have to build large project with complicated build-deps this feature helps to use already built packages to satisfy build-deps of forthcoming package builds.

from jenkins-debian-glue.

@realloc and this should not change !
Lets' say:

1. I backport Zabbix and I want to backport it for Debian Wheezy & Debian Squeeze
   2.Currently, at least 2 versions are maintained: 2.0 & 2.2

With current organization, you have to manage 4 release repositories, one per software version per distribution.

Now, imagine that you use $distribution as codename for $release repository.
You now have only one repository per software to manage. In my example, only 2 repositories: one for Zabbix 2.0 and the other for Zabbix 2.2

That sounds more easy and, at least to me, more logical.

What about dependencies ? In fact, it does not change anything. You'll still have to package your library for each distribution you support and integrate them in repo, as for now.

from jenkins-debian-glue.

Is someone willing to work on an up2date patch for this issue?

from jenkins-debian-glue.

JFTR: I don't have any environment in usage where this situation applies and am quite out of the loop regarding this. Also we (sadly) don't have according tests which ensure that on such changes nothing breaks in existing setups, so right now it's hard for me to work on this in my current scarce spare time. But if anyone is wiling to work on this I'd be more than happy to accept well tested and detailled PRs . (If anyone is interested in getting this fixed maybe look into #155 as a starting point?)

from jenkins-debian-glue.