Use separate name for repo & distribution codename/suite

mika / jenkins-debian-glue

Scripts for Debian package/repository handling inside Jenkins

MIT License

131 stars 91 forks source link

Use separate name for repo & distribution codename/suite #92

Open jbfavre opened 10 years ago

jbfavre commented 10 years ago

Currently, same variable $REPOS is used in /usr/bin/generate-reprepro-codename for both repo name and distribution codename in conf/distribution. We should use $distribution if provided or the one used to generate package.

This would allow to have one repository per software packaged with all flavor in it, which should make repository management easier.

mika commented 10 years ago

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?

jbfavre commented 10 years ago

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.

jbfavre commented 10 years ago

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 :)

realloc commented 10 years ago

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.

jbfavre commented 10 years ago

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

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.

mika commented 9 years ago

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

mika commented 4 years ago

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 https://github.com/mika/jenkins-debian-glue/pull/155 as a starting point?)