aptly
aptly copied to clipboard
aptly-dev
Lets start support rpm based OS
Check out createrepo for creating RPM repositories. I'm not saying there wouldn't be value in being able to use the same tool for .deb's and .rpm's but personally I'm fine with having to use two tools. Aptly is sorely needed for .deb's because all the other options are terrible. createrepo is very easy to use.
@LHCGreg, most probably aptly would use createrepo internally to publish rpm repositories. But offering snapshotting, pulling, merging and local repositories on top of that should be important. WDYT?
+1 This would be awesome—createrepo has a very short inconsistent period when indexing and does not support versioning of package environments, so having immutable metadata would be brilliant.
If you want to keep notified about this ticket, please click the subscribe button on the right, rather than adding +1 comments:
+1 This is what I'm looking for (One tool/Frontend for both deb an rpm even if it would use createrepo in background). I would need it to create 3rd party repos for different OS (Debian,Ubuntu,SuSe,RedHat, Centos, ...). In fact I saw it is on your agenda, is there any hint when it is planed to be released? Would be awesome, just like the whole project :)
I would also really love to see this make it into aptly. We have a bunch of ruby stuff wrapping aptly and createrepo right now that could go away if you had this functionality
FYI Pulp provides repo management for RHEL/CentOS (http://www.pulpproject.org/) which is part of Katello (http://www.katello.org/) which provides content and lifecycle management and which is included in The Foreman (http://theforeman.org/).
May-be it would be interesting that aptly and Pulp/Katello colaborate? (Just a thought)
+1 native/built in RPM support
:-1: @icebrian Sorry, prefer native/built rpm support in aptly, rather than depend on 3 different projects each with their own dependancies... aptly installs smoothly very well, and i'd like that to persist.
@smira do you have a rough outline of what needs to be done to support RPMs? I would like to help out with this but need a little help getting started.
@sepulworld I tried to collect some work items here: https://docs.google.com/document/d/1Ili6lDOJO3Epj__JTdVGiJKpLBrU-R0mckhdO5prKvk/edit?usp=sharing
It's not complete list
@smira
The createrepo_c suite does quite a bit:
- Creating repositories
- Merging repositories
- Modifying them
- Updating them
- Generating DeltaRPMs and creating associated repository data for them
As far as I know, some of this functionality has never really existed in Debian systems, so if Aptly is too Debian specific, it may take quite a bit more work to implement the needed functionality to support RPM Metadata (rpm-md) repositories.
As for the createrepo suite, createrepo itself hasn't seen any development in a while, as efforts are largely focused on getting moved over to createrepo_c.
Hi ,
Do we have any update on this . When this feature is getting releases
https://github.com/cavaliercoder/go-rpm provides native go code for dealing with RPM file format and parts of YUM which would be useful for this project.
Thanks @pquerna for the mention. My main goal for go-rpm was a yum/rpm implementation to backend y10k. Having a look at aptly, my efforts with y10k seem to have a very similar use case, except targeting rpm instead of deb and obviously with much less maturity.
Currently (though unreleased), go-rpm and y10k (in the native_rpm branch) can mimic reposync in 100% native Go. I am currently reimplementing createrepo functionality natively with gradual success.
I'd be delighted to have support in developing go-rpm and y10k. I would also consider abandoning y10k and instead contributing to the development of aptly as an rpm compatible tool. My goal is better tooling for publishing yum repos.
Fair question and still a good suggestion but like @elliotmoore, I prefer the idea of Go native implementations that have no dependencies on system libraries.
It's definitely a trade off between the stability of the original library (libcreaterepo_c) and having a Go native implementation that can be reused in different tools without creating platform limitations due to dependencies. That, and it's a pretty cool challenge and creates choice for developers.
Aptly is leaps and bounds better written and designed than Pulp, it gets RPM support, company switches tomorrow.
I think the problem is the whole concept within yum repos is that you can do whatever you want, where as debian repo's have a much more rigid hierarchy imposed on itself.
If this ran with the idea of imposing dist/arch/component paradigms on yum repos, would that blow people's mind too much?
it can be done, createrepo_c don't care.
The entire gain for my project is a unified api for doing both, but in the mean time we're looking at writing a go-api that shells out to createrepo_c
@thebwt It might be just be OK! At least for people who primarily use dpkg/apt, since it'll be natural for them. I've never felt well in the debian structure of repos, but I think for people who like it should be good! I know enough people who feel more at home in how debian does them. Having the same structure across different OS is quite helpful.
(I'm in testing of repositor, which is kind of a clone of Pulp v1, meaning just the pure repo management. That one looks like pulp and just is more manageable. Think about if you want to be compatible for people who rather want the unstructured yum way, or the best possible tool for apt-minded. If not the first, maybe it's not even wrong to have two tools for two mindsets. Well, three since there's also people who enjoy all the spaceshipness of Pulp)
I would be very happy with increased structure, my only concern would be on mirroring interop, but for hosted repo's I already separate them out Debian style. Many yum repos themselves have a structure to them implicitly, you could simply mirror a specified distro/arch specific portion of a repo. They also can have metadata, which may be valuable, just not sure offhand...
@FlorianHeigl, I hate pulp so much, I'd eat a bug to demolish that fragile behemoth.
