New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Lets start support rpm based OS #39

Open
Joni-Lover opened this Issue Apr 21, 2014 · 47 comments

Comments

Projects
None yet
@Joni-Lover

Joni-Lover commented Apr 21, 2014

many users would like to use your tool for RPM repositories

@smira smira added the enhancement label Apr 21, 2014

@smira smira added this to the v0.7 milestone Apr 21, 2014

@LHCGreg

This comment has been minimized.

Show comment
Hide comment
@LHCGreg

LHCGreg Apr 25, 2014

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 commented Apr 25, 2014

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.

@smira

This comment has been minimized.

Show comment
Hide comment
@smira

smira Apr 25, 2014

Member

@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?

Member

smira commented Apr 25, 2014

@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?

@LHCGreg

This comment has been minimized.

Show comment
Hide comment
@LHCGreg

LHCGreg Apr 26, 2014

@smira Oh right, I forgot that aptly is more than just hosting packages.

LHCGreg commented Apr 26, 2014

@smira Oh right, I forgot that aptly is more than just hosting packages.

@Joni-Lover

This comment has been minimized.

Show comment
Hide comment
@Joni-Lover

Joni-Lover Apr 26, 2014

yes, that is exactly what is not in createrepo

Joni-Lover commented Apr 26, 2014

yes, that is exactly what is not in createrepo

@smira smira modified the milestones: v0.8, v0.7 Jun 27, 2014

@smira smira removed this from the v0.8 milestone Aug 26, 2014

@mrmanc

This comment has been minimized.

Show comment
Hide comment
@mrmanc

mrmanc Oct 29, 2014

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

mrmanc commented Oct 29, 2014

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

@sepulworld

This comment has been minimized.

Show comment
Hide comment
@sepulworld

sepulworld commented Oct 29, 2014

+1

@sodabrew

This comment has been minimized.

Show comment
Hide comment
@sodabrew

sodabrew Oct 29, 2014

If you want to keep notified about this ticket, please click the subscribe button on the right, rather than adding +1 comments:
screen shot 2014-10-29 at 12 16 11 pm

sodabrew commented Oct 29, 2014

If you want to keep notified about this ticket, please click the subscribe button on the right, rather than adding +1 comments:
screen shot 2014-10-29 at 12 16 11 pm

@fgsch

This comment has been minimized.

Show comment
Hide comment
@fgsch

fgsch Nov 15, 2014

+1
I'd love to have a single tool to manage RPM and Debian repositories.

fgsch commented Nov 15, 2014

+1
I'd love to have a single tool to manage RPM and Debian repositories.

@titilambert

This comment has been minimized.

Show comment
Hide comment

titilambert commented Nov 26, 2014

+1

@Heiko-san

This comment has been minimized.

Show comment
Hide comment
@Heiko-san

Heiko-san Dec 1, 2014

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

Heiko-san commented Dec 1, 2014

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

@smira

This comment has been minimized.

Show comment
Hide comment
@smira

smira Dec 1, 2014

Member

I would do my best to push for 0.10 version...

Member

smira commented Dec 1, 2014

I would do my best to push for 0.10 version...

@dmitrievav

This comment has been minimized.

Show comment
Hide comment
@dmitrievav

dmitrievav commented Jan 28, 2015

+1

@kisoku

This comment has been minimized.

Show comment
Hide comment
@kisoku

kisoku Mar 23, 2015

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

kisoku commented Mar 23, 2015

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

@icebrian

This comment has been minimized.

Show comment
Hide comment
@icebrian

icebrian Apr 28, 2015

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)

icebrian commented Apr 28, 2015

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)

@elliotmoore

This comment has been minimized.

Show comment
Hide comment
@elliotmoore

elliotmoore Apr 28, 2015

+1 native/built in RPM support

👎 @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.

elliotmoore commented Apr 28, 2015

+1 native/built in RPM support

👎 @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.

@sepulworld

This comment has been minimized.

Show comment
Hide comment
@sepulworld

sepulworld Jun 3, 2015

@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 commented Jun 3, 2015

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

@smira

This comment has been minimized.

Show comment
Hide comment
@smira
Member

smira commented Jun 10, 2015

@redrampage

This comment has been minimized.

Show comment
Hide comment
@redrampage

redrampage commented Jul 22, 2015

+1

@6opo9a

This comment has been minimized.

Show comment
Hide comment
@6opo9a

6opo9a commented Jul 23, 2015

+1

@Conan-Kudo

This comment has been minimized.

Show comment
Hide comment
@Conan-Kudo

Conan-Kudo Sep 1, 2015

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

Conan-Kudo commented Sep 1, 2015

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

@riteshnanda09

This comment has been minimized.

Show comment
Hide comment
@riteshnanda09

riteshnanda09 Dec 31, 2015

Hi ,

Do we have any update on this . When this feature is getting releases

riteshnanda09 commented Dec 31, 2015

Hi ,

Do we have any update on this . When this feature is getting releases

@pquerna

This comment has been minimized.

Show comment
Hide comment
@pquerna

pquerna Jan 13, 2016

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.

pquerna commented Jan 13, 2016

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.

@cavaliercoder

This comment has been minimized.

Show comment
Hide comment
@cavaliercoder

cavaliercoder Feb 4, 2016

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.

cavaliercoder commented Feb 4, 2016

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.

@Conan-Kudo

This comment has been minimized.

Show comment
Hide comment
@Conan-Kudo

Conan-Kudo Feb 4, 2016

@cavaliercoder Why not instead use libcreaterepo_c with your program?

Conan-Kudo commented Feb 4, 2016

@cavaliercoder Why not instead use libcreaterepo_c with your program?

@cavaliercoder

This comment has been minimized.

Show comment
Hide comment
@cavaliercoder

cavaliercoder Feb 4, 2016

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.

cavaliercoder commented Feb 4, 2016

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.

@techzilla

This comment has been minimized.

Show comment
Hide comment
@techzilla

techzilla Dec 14, 2016

Aptly is leaps and bounds better written and designed than Pulp, it gets RPM support, company switches tomorrow.

techzilla commented Dec 14, 2016

Aptly is leaps and bounds better written and designed than Pulp, it gets RPM support, company switches tomorrow.

@thebwt

This comment has been minimized.

Show comment
Hide comment
@thebwt

thebwt Dec 14, 2016

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 commented Dec 14, 2016

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

@FlorianHeigl

This comment has been minimized.

Show comment
Hide comment
@FlorianHeigl

FlorianHeigl Dec 14, 2016

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

FlorianHeigl commented Dec 14, 2016

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

@techzilla

This comment has been minimized.

Show comment
Hide comment
@techzilla

techzilla Dec 19, 2016

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.

techzilla commented Dec 19, 2016

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.

@james-lawrence

This comment has been minimized.

Show comment
Hide comment
@james-lawrence

james-lawrence Jun 21, 2017

seems like this has died? is anyone actively working on it?

james-lawrence commented Jun 21, 2017

seems like this has died? is anyone actively working on it?

@FlorianHeigl

This comment has been minimized.

Show comment
Hide comment
@FlorianHeigl

FlorianHeigl Jun 21, 2017

@james-lawrence there was doubts if it's really in scope for aptly to support a very different repo structure. I think the decision is still open, and your input (needs) would help. If you need movement on this, please write them down.

@techzilla I fully understand you. I think Pulp v1 was really good, and it seems the new team never really read the original paper and instead of a tool build a star destroyer...
In one place we use Pulp and will keep using it because we simply need the scalability it has, and especially the faster repo updates it does (better than createrepo -c -u or so). but for normal sized use cases it's too bad at supporting the actual repo workflow (vs. supporting putting 2 fulltime devs on implementing+maintaining the workflow using the API), and comes with just too sick overheads.

I did also try repositor.io by now. It is a fragile clusterfuck and would need more maintainers to keep up it's promises (docker registry? yeah, but not if you need to have an authentication or would like to work with a recent client? errata? yeah, but the daily updates last happened in 2016, ...)

So how do I put this - there is still room for doing things better.
But I would recommend to not underestimate the effort of doing twice as much, and still having a unified interface to manage very different concepts of repos.

FlorianHeigl commented Jun 21, 2017

@james-lawrence there was doubts if it's really in scope for aptly to support a very different repo structure. I think the decision is still open, and your input (needs) would help. If you need movement on this, please write them down.

@techzilla I fully understand you. I think Pulp v1 was really good, and it seems the new team never really read the original paper and instead of a tool build a star destroyer...
In one place we use Pulp and will keep using it because we simply need the scalability it has, and especially the faster repo updates it does (better than createrepo -c -u or so). but for normal sized use cases it's too bad at supporting the actual repo workflow (vs. supporting putting 2 fulltime devs on implementing+maintaining the workflow using the API), and comes with just too sick overheads.

I did also try repositor.io by now. It is a fragile clusterfuck and would need more maintainers to keep up it's promises (docker registry? yeah, but not if you need to have an authentication or would like to work with a recent client? errata? yeah, but the daily updates last happened in 2016, ...)

So how do I put this - there is still room for doing things better.
But I would recommend to not underestimate the effort of doing twice as much, and still having a unified interface to manage very different concepts of repos.

@james-lawrence

This comment has been minimized.

Show comment
Hide comment
@james-lawrence

james-lawrence Jun 21, 2017

@FlorianHeigl not really worried about the structure imposed. just looking for a solid tool that:

  1. easy to deploy
  2. is usable using standard yum/dnf .repo configuration files.
  3. supports uploading packages
  4. mirror other rpm repos (this is a very minimal want)

james-lawrence commented Jun 21, 2017

@FlorianHeigl not really worried about the structure imposed. just looking for a solid tool that:

  1. easy to deploy
  2. is usable using standard yum/dnf .repo configuration files.
  3. supports uploading packages
  4. mirror other rpm repos (this is a very minimal want)
@Conan-Kudo

This comment has been minimized.

Show comment
Hide comment
@Conan-Kudo

Conan-Kudo Jun 22, 2017

It would also be nice if it had the ability to generate a detached signature of the repomd.xml for distributions that generally expect it (openSUSE, etc.).

Conan-Kudo commented Jun 22, 2017

It would also be nice if it had the ability to generate a detached signature of the repomd.xml for distributions that generally expect it (openSUSE, etc.).

@FlorianHeigl

This comment has been minimized.

Show comment
Hide comment
@FlorianHeigl

FlorianHeigl Jun 22, 2017

@Conan-Kudo good point - we manually do that in Pulp via something cron-like and its not nice.
from experience: you'd really want that well-integrated so that you don't end up with invalid signatures if keys are not loaded.
Ideally, aptly would be able to read/look at the signatures, anything "after the fact" is highly fragile.

FlorianHeigl commented Jun 22, 2017

@Conan-Kudo good point - we manually do that in Pulp via something cron-like and its not nice.
from experience: you'd really want that well-integrated so that you don't end up with invalid signatures if keys are not loaded.
Ideally, aptly would be able to read/look at the signatures, anything "after the fact" is highly fragile.

@lazyfrosch

This comment has been minimized.

Show comment
Hide comment
@lazyfrosch

lazyfrosch Jun 22, 2017

We actually use aptly to upload RPM packages.

The packages are then published to a RPM repository via a local cron job that picks up the upload.

lazyfrosch commented Jun 22, 2017

We actually use aptly to upload RPM packages.

The packages are then published to a RPM repository via a local cron job that picks up the upload.

@maxadamo

This comment has been minimized.

Show comment
Hide comment
@maxadamo

maxadamo Aug 3, 2017

createrepo does not support snapshot

maxadamo commented Aug 3, 2017

createrepo does not support snapshot

@szhem

This comment has been minimized.

Show comment
Hide comment
@szhem

szhem Mar 26, 2018

Hi there, as the landing page states that support of yum repositories is coming soon, I'm just wondering where there is any ETA regarding this feature?

image

szhem commented Mar 26, 2018

Hi there, as the landing page states that support of yum repositories is coming soon, I'm just wondering where there is any ETA regarding this feature?

image

@smira

This comment has been minimized.

Show comment
Hide comment
@smira

smira Mar 31, 2018

Member

@szhem I think that's something which is on the roadmap forever, but it never got implemented, so I don't feel we're ever going to get there.

Member

smira commented Mar 31, 2018

@szhem I think that's something which is on the roadmap forever, but it never got implemented, so I don't feel we're ever going to get there.

@carlwgeorge

This comment has been minimized.

Show comment
Hide comment
@carlwgeorge

carlwgeorge Apr 2, 2018

@smira If that's the case, please remove mention of RPM support from the website.

carlwgeorge commented Apr 2, 2018

@smira If that's the case, please remove mention of RPM support from the website.

@Conan-Kudo

This comment has been minimized.

Show comment
Hide comment
@Conan-Kudo

Conan-Kudo Apr 2, 2018

@smira If you want to implement RPM repositories in a "pure-Go" manner, you can look at the following to do RPM parsing:

The Yum repodata format is just XML, and there is plenty of test data in the createrepo_c repo: https://github.com/rpm-software-management/createrepo_c

Conan-Kudo commented Apr 2, 2018

@smira If you want to implement RPM repositories in a "pure-Go" manner, you can look at the following to do RPM parsing:

The Yum repodata format is just XML, and there is plenty of test data in the createrepo_c repo: https://github.com/rpm-software-management/createrepo_c

@smira

This comment has been minimized.

Show comment
Hide comment
@smira

smira Apr 2, 2018

Member

@Conan-Kudo yes, generating (publishing) repository should be fairly straightforward, but getting all the details right for rpm packages, making sure mirroring work, all the .deb/.rpm separation works properly is a lot of work...

Member

smira commented Apr 2, 2018

@Conan-Kudo yes, generating (publishing) repository should be fairly straightforward, but getting all the details right for rpm packages, making sure mirroring work, all the .deb/.rpm separation works properly is a lot of work...

@cavaliercoder

This comment has been minimized.

Show comment
Hide comment
@cavaliercoder

cavaliercoder Apr 2, 2018

Implementing the YUM/repo side of things in native Go is actually pretty heavy work. I made a solid start in https://github.com/cavaliercoder/go-rpm but the cost outweighed the benefit. A big part of the problem was that (at the time) there was no Go native implementations of SQLite or XZ compression. Things may have improved now. It's probably not worth the effort vs. calling out to createrepo.

cavaliercoder commented Apr 2, 2018

Implementing the YUM/repo side of things in native Go is actually pretty heavy work. I made a solid start in https://github.com/cavaliercoder/go-rpm but the cost outweighed the benefit. A big part of the problem was that (at the time) there was no Go native implementations of SQLite or XZ compression. Things may have improved now. It's probably not worth the effort vs. calling out to createrepo.

@cavaliercoder

This comment has been minimized.

Show comment
Hide comment
@cavaliercoder

cavaliercoder commented Apr 2, 2018

Incomplete YUM implementation is hidden here: https://github.com/cavaliercoder/y10k/tree/native_rpm/yum

@Conan-Kudo

This comment has been minimized.

Show comment
Hide comment
@Conan-Kudo

Conan-Kudo Apr 2, 2018

@cavaliercoder You don't need SQLite metadata. DNF (Fedora/Mageia) and Zypper (SUSE) only read the XML metadata and the XML metadata can be compressed in gzip, bzip2, or xz format currently (most distributions use gzip, because of the rsyncable property). Yum will use XML metadata by default, too.

Conan-Kudo commented Apr 2, 2018

@cavaliercoder You don't need SQLite metadata. DNF (Fedora/Mageia) and Zypper (SUSE) only read the XML metadata and the XML metadata can be compressed in gzip, bzip2, or xz format currently (most distributions use gzip, because of the rsyncable property). Yum will use XML metadata by default, too.

@cavaliercoder

This comment has been minimized.

Show comment
Hide comment
@cavaliercoder

cavaliercoder Apr 2, 2018

Cool! One of my goals was universal client support, so supporting most of the database formats was necessary. If newer clients only use the XML db, maybe that issue is de-scoped.

My projects are mostly unmaintained now - certainly not under active development. I'd just like to share what I found and hopefully someone smarter than me can bring things to a more valuable conclusion.

cavaliercoder commented Apr 2, 2018

Cool! One of my goals was universal client support, so supporting most of the database formats was necessary. If newer clients only use the XML db, maybe that issue is de-scoped.

My projects are mostly unmaintained now - certainly not under active development. I'd just like to share what I found and hopefully someone smarter than me can bring things to a more valuable conclusion.

@Conan-Kudo

This comment has been minimized.

Show comment
Hide comment
@Conan-Kudo

Conan-Kudo Apr 2, 2018

@cavaliercoder All versions of DNF, Zypper, Yum, Smart, and APT-RPM use XML metadata. The SQLite metadata was an optimization added for external infrastructure tools to use (e.g. repoview, et al). I don't know of any tools actively maintained today that use the SQLite metadata.

Conan-Kudo commented Apr 2, 2018

@cavaliercoder All versions of DNF, Zypper, Yum, Smart, and APT-RPM use XML metadata. The SQLite metadata was an optimization added for external infrastructure tools to use (e.g. repoview, et al). I don't know of any tools actively maintained today that use the SQLite metadata.

@cavaliercoder

This comment has been minimized.

Show comment
Hide comment
@cavaliercoder

cavaliercoder Apr 2, 2018

Great! Hopefully the way forward is simpler than I anticipate.

cavaliercoder commented Apr 2, 2018

Great! Hopefully the way forward is simpler than I anticipate.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment