Is the actual current procedure for submitting aan RPM to the Fedora depository documented anywhere?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wednesday 07 January 2004 10:23, Eric S. Raymond wrote:
Is the actual current procedure for submitting aan RPM to the Fedora depository documented anywhere? -- <a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
It would be thought a hard government that should tax its people one tenth part. -- Benjamin Franklin
Here's a start.
http://www.fedora.us/wiki/PackageSubmissionQAPolicy
- -- Public Key available Here: http://www.bravegnuworld.com/~rjune/rjune.asc
Richard June rjune@bravegnuworld.com:
On Wednesday 07 January 2004 10:23, Eric S. Raymond wrote:
Is the actual current procedure for submitting an RPM to the Fedora depository documented anywhere?
Here's a start.
I knew about this; it's part of the reason I asked the question. What's there is both out of date and inadequate.
When I told Mike Johnson that I wanted to streamline the process by making it easy to submit RPMs via a script, he said I was aiming at the wrong target because that's the old (fedora.us) procedure, not the new one. And I know that document is out of date in at least one respect; the "epoch number" is dead.
Once again, I run 37 projects which I would like to make available in the Fedora repository. I'm trying to develop a way I can ship RPMS, or equivalent metadata from which the Fedora project can build RPMs, automatically every time I do a point release.
What do I have to do? And why isn't this documented clearly and completely? Don't you want the repository to be well populated?
On Wed, 7 Jan 2004 14:34:06 -0500, Eric S. Raymond wrote:
Richard June rjune@bravegnuworld.xxx:
On Wednesday 07 January 2004 10:23, Eric S. Raymond wrote:
Is the actual current procedure for submitting an RPM to the Fedora depository documented anywhere?
Here's a start.
I knew about this; it's part of the reason I asked the question. What's there is both out of date and inadequate.
When I told Mike Johnson that I wanted to streamline the process by making it easy to submit RPMs via a script, he said I was aiming at the wrong target because that's the old (fedora.us) procedure, not the new one. And I know that document is out of date in at least one respect; the "epoch number" is dead.
Once again, I run 37 projects which I would like to make available in the Fedora repository. I'm trying to develop a way I can ship RPMS, or equivalent metadata from which the Fedora project can build RPMs, automatically every time I do a point release.
What do I have to do? And why isn't this documented clearly and completely? Don't you want the repository to be well populated?
Official "Fedora Extras" does not exist yet. In other words, you cannot submit your packages to a repository that doesn't exist.
--
On Wed, Jan 07, 2004 at 02:34:06PM -0500, Eric S. Raymond wrote:
Once again, I run 37 projects which I would like to make available in the Fedora repository. I'm trying to develop a way I can ship RPMS, or equivalent metadata from which the Fedora project can build RPMs, automatically every time I do a point release.
But do you want every automatic point release propogating to the release repository without human testing ?
I can see clearly that you want to automate it for your own package trees so that people can effectively subscribe to 'fetchmail of the day' or similar things. For that you might want to look at Dag Wieers stuff since he's rolling 500+ packages for several releases all the time.
Alan
Alan Cox alan@redhat.com:
On Wed, Jan 07, 2004 at 02:34:06PM -0500, Eric S. Raymond wrote:
Once again, I run 37 projects which I would like to make available in the Fedora repository. I'm trying to develop a way I can ship RPMS, or equivalent metadata from which the Fedora project can build RPMs, automatically every time I do a point release.
But do you want every automatic point release propogating to the release repository without human testing ?
In many cases yes. About thirty of those projects are very stable; point releases are mainly for things like porting fixes and should go straight to the street. Maybe half a dozen have testing issues on each release; those I would direct to your unstable repository.
I can see clearly that you want to automate it for your own package trees so that people can effectively subscribe to 'fetchmail of the day' or similar things. For that you might want to look at Dag Wieers stuff since he's rolling 500+ packages for several releases all the time.
Pointer?
On Wed, 2004-01-07 at 21:41, Eric S. Raymond wrote:
I can see clearly that you want to automate it for your own package trees so that people can effectively subscribe to 'fetchmail of the day' or similar things. For that you might want to look at Dag Wieers stuff since he's rolling 500+ packages for several releases all the time.
Pointer?
Behold, the power the interweb. http://www.google.com/search?&q=Dag%20Wieers
(2nd link)
Dave
On Wed, Jan 07, 2004 at 04:41:34PM -0500, Eric S. Raymond wrote:
I can see clearly that you want to automate it for your own package trees so that people can effectively subscribe to 'fetchmail of the day' or similar things. For that you might want to look at Dag Wieers stuff since he's rolling 500+ packages for several releases all the time.
Pointer?
google:dag wieers 8)
Alan Cox alan@redhat.com:
On Wed, Jan 07, 2004 at 04:41:34PM -0500, Eric S. Raymond wrote:
I can see clearly that you want to automate it for your own package trees so that people can effectively subscribe to 'fetchmail of the day' or similar things. For that you might want to look at Dag Wieers stuff since he's rolling 500+ packages for several releases all the time.
Pointer?
google:dag wieers 8)
I found it, and then I found the ring he's part of (ATrpms, dag, FreshRPMS and newrpms).
Hmmm....
Perhaps these people should *be* Fedora extras? Looks to me like the community has already evolved a rather well-functioning set of apt repositories. and I like the no-single-point-of-failure aspect of what they're doing.
Is there some reason for Fedora not to farm out the extras job to people who seem already to be doing it competently?
On Wed, Jan 07, 2004 at 05:37:58PM -0500, Eric S. Raymond wrote:
Perhaps these people should *be* Fedora extras? Looks to me like the community has already evolved a rather well-functioning set of apt repositories. and I like the no-single-point-of-failure aspect of what they're doing. Is there some reason for Fedora not to farm out the extras job to people who seem already to be doing it competently?
At least one is "maybe they don't want to be Fedora Extras" and another in several cases is that they choose to carry material that might not be allowed in the USA, just the free world. As a US corporation Red Hat is subject to US law.
Alan
On Wed, 2004-01-07 at 17:46, Alan Cox wrote:
On Wed, Jan 07, 2004 at 05:37:58PM -0500, Eric S. Raymond wrote:
Perhaps these people should *be* Fedora extras? Looks to me like the community has already evolved a rather well-functioning set of apt repositories. and I like the no-single-point-of-failure aspect of what they're doing. Is there some reason for Fedora not to farm out the extras job to people who seem already to be doing it competently?
At least one is "maybe they don't want to be Fedora Extras" and another in several cases is that they choose to carry material that might not be allowed in the USA, just the free world. As a US corporation Red Hat is subject to US law.
Aren't there a number of countries that are leaking into the 'not-freeworld' group other than just the US. I thought some other western nations were doing equally stupid legislation.
I might be just losing my mind.
-sv
Alan Cox alan@redhat.com:
At least one is "maybe they don't want to be Fedora Extras" and another in several cases is that they choose to carry material that might not be allowed in the USA, just the free world. As a US corporation Red Hat is subject to US law.
These both seem like readily solvable problems to me.
If you look at http://dag.wieers.com/home-made/apt/mega-merge.php, you'll see that this group describes itself as "The Red Hat/Fedora authoritative packager list". That sure sounds to me as though they would welcome official status if offered.
As for the DECSS problem, everybody understands it and we already have a workaround via the existence of livna.org.
I suggest that Fedora make the following offer to this group: Fedora will put these repositories in the distributed apt.sources and collectively designate them as Fedora Extras, on the following conditions:
(1) Software compromised for IP reasons must be exiled to livna.org Repository keepers must agree to comply with a ban list compiled by Red Hat.
(2) RPMs must meet Fedora QA standards. Repository maintainers must expect their submission, test and build procedures to be audited, and will be dropped from the list of authoritative repositories if they fail to meet standards.
I doubt you'd get any pushback on these requirements. And the cost of QA-monitoring these repositories would undoubtedly be lower than the cost of building and maintaining one big repository of your own. You'd win fairly big on the download costs alone.
Eric S. Raymond wrote:
These both seem like readily solvable problems to me.
If you look at http://dag.wieers.com/home-made/apt/mega-merge.php, you'll see that this group describes itself as "The Red Hat/Fedora authoritative packager list". That sure sounds to me as though they would welcome official status if offered.
fedora.us is a collaborative project with about two dozen active packagers involved every day. freshrpms/axel/dag/newrpms is comprised of several one-man operations that sometimes conflict and cause package clashes. They have no published QA policy and only after-the-fact peer review and revisions.
http://www.fedora.us/wiki/RepositoryMixingProblems Due to these reasons fedora.us has always said that we will not coordinate with external repositories. We never have these package clashes, and our package quality is on the average better. The drawback here is slower package review and publication.
Those other repositories are authoritative, within their own world. You can choose to live in either their world, or our world. Open Source means you have the freedom to choose. I choose to live in the fedora.us world, and apparently so did Red Hat. [1]
(1) Software compromised for IP reasons must be exiled to livna.org Repository keepers must agree to comply with a ban list compiled by Red Hat.
It already seems to have happened. It seems that rpm.livna.org is collaborative with a Bugzilla and QA procedure too.
(2) RPMs must meet Fedora QA standards. Repository maintainers must expect their submission, test and build procedures to be audited, and will be dropped from the list of authoritative repositories if they fail to meet standards.
We have fedora.us QA standards and nobody else has suggested a full proposal for an alternative, so currently fedora.us is on track for eventally become Fedora Extras around FC2 timeframe.
fedora.us is the only authoritative repository & project.
There is no authoritative list of repositories because fedora.redhat.com is designed so the user can choose to use any 3rd party repository.
I doubt you'd get any pushback on these requirements. And the cost of QA-monitoring these repositories would undoubtedly be lower than the cost of building and maintaining one big repository of your own. You'd win fairly big on the download costs alone.
We respectfully disagree with this line of thinking.
Warren Togami warren@togami.com
[1] http://www.newsforge.com/software/03/10/01/1417208.shtml
Warren Togami warren@togami.com:
http://www.fedora.us/wiki/RepositoryMixingProblems Due to these reasons fedora.us has always said that we will not coordinate with external repositories. We never have these package clashes, and our package quality is on the average better. The drawback here is slower package review and publication.
The bigger drawback is that you don't have an extras repository at all! It sounds like you may be allowing unattained perfection to become the enemy of the good.
(1) Software compromised for IP reasons must be exiled to livna.org Repository keepers must agree to comply with a ban list compiled by Red Hat.
It already seems to have happened. It seems that rpm.livna.org is collaborative with a Bugzilla and QA procedure too.
Good, that's a forward step.
(2) RPMs must meet Fedora QA standards. Repository maintainers must expect their submission, test and build procedures to be audited, and will be dropped from the list of authoritative repositories if they fail to meet standards.
We have fedora.us QA standards and nobody else has suggested a full proposal for an alternative, so currently fedora.us is on track for eventally become Fedora Extras around FC2 timeframe.
OK. Now we're back to my original question...
I doubt you'd get any pushback on these requirements. And the cost of QA-monitoring these repositories would undoubtedly be lower than the cost of building and maintaining one big repository of your own. You'd win fairly big on the download costs alone.
We respectfully disagree with this line of thinking.
OK, that's your call to make and not mine. Axel Thimm's post and yours come together to make it clear that I've inadvertently walked into the middle of a political issue. That's not where I want to be.
What I do want is a well-defined procedure by which I can drop (for example) fetchmail point releases into an "official" repository and have them available for people to apt-get.
Things I don't care about:
* what the repository is called * who runs it * whether it takes RPMs I build or builds its own from metadata and tarballs that I drop there.
Things I do care about:
* It must be generally accepted as authoritative for people running Fedora. * It must not require me to do hand-work for each release (that means it can't have an unscriptable web-only interface)
You have to solve this problem sometime, because there are about 500,000 developers out there with similar needs. I'm willing to build client tools like the fedora-submit and bugzilla-submit scripts I've already done to assist the effort.
What's the path forward?
Eric S. Raymond wrote:
http://www.fedora.us/wiki/RepositoryMixingProblems Due to these reasons fedora.us has always said that we will not coordinate with external repositories. We never have these package clashes, and our package quality is on the average better. The drawback here is slower package review and publication.
The bigger drawback is that you don't have an extras repository at all! It sounds like you may be allowing unattained perfection to become the enemy of the good.
Huh?
fedora.us is all about providing add-ons for Red Hat Linux, and now Fedora Core. (Well and also now Legacy, community developed security backport update packages for the older distributions.)
(1) Software compromised for IP reasons must be exiled to livna.org Repository keepers must agree to comply with a ban list compiled by Red Hat.
It already seems to have happened. It seems that rpm.livna.org is collaborative with a Bugzilla and QA procedure too.
Good, that's a forward step.
And they seem to be using the exact same QA procedure that fedora.us uses.
I doubt you'd get any pushback on these requirements. And the cost of QA-monitoring these repositories would undoubtedly be lower than the cost of building and maintaining one big repository of your own. You'd win fairly big on the download costs alone.
We respectfully disagree with this line of thinking.
OK, that's your call to make and not mine. Axel Thimm's post and yours come together to make it clear that I've inadvertently walked into the middle of a political issue. That's not where I want to be.
Unfortunately this is true of our current situation.
What I do want is a well-defined procedure by which I can drop (for example) fetchmail point releases into an "official" repository and have them available for people to apt-get.
apt-get may be a problem, given that there is great resistance within RH to including apt-get within FC. That resistance is weakening though. Resistance is futile. <evil grin>
There used to be seemingly good arguments against apt... like the use of --nodeps (which truly was not a problem). But now the latest apt uses native rpmlib, so that argument is gone. There are also benefits like this (quoting Panu Matilainen):
I have experienced yum being EXTREMELY SLOW compared to apt when calculating a huge amount of dependencies, for example.
Indeed. Just calculating the dependencies of RH 9 -> FC 1 upgrade (no actual upgrade done, all headers, pkglists etc local) on my PIII 500Mhz testbox takes apt: 10 seconds yum: ~50 *minutes*
http://linux.duke.edu/projects/metadata/readme.metadata Fortunately though rpm-metadata is in the process of standardizing, and that will further reduce resistance to including apt since the same mirrors will work for apt, yum, or up2date. The question now is if apt and the other clients will have it fully implemented in time for FC2 inclusion. HELP THEM!!!
ESR wrote:
Things I don't care about:
- what the repository is called
- who runs it
- whether it takes RPMs I build or builds its own from metadata and
tarballs that I drop there.
This is good.
Things I do care about:
- It must be generally accepted as authoritative for people running Fedora.
It is already clearly understood that fedora.us will become Fedora Extras at some point.
- It must not require me to do hand-work for each release (that means it can't have an unscriptable web-only interface)
You have to solve this problem sometime, because there are about 500,000 developers out there with similar needs. I'm willing to build client tools like the fedora-submit and bugzilla-submit scripts I've already done to assist the effort.
My greatest concern here is that I question the efficacy of any such client. I can see how a XML-RPC client can used a template based approach in submitting new packages within a new Bugzilla report, or submitting a package update to an existing Bugzilla report, but otherwise I don't see it being very useful.
https://bugzilla.fedora.us/show_bug.cgi?id=520 Something like how I started this Bugzilla report is one way packages are submitted. Only the URL to SRPM, URL to md5sums.asc, and a short description about what the package does. A tool that can do this reliably would save maybe 30-45 seconds. It would easy to use that same tool to post updates to that package in the existing report too. Beyond this what would the tool do that is useful?
In the future fedora.redhat.com will allow CVS access with ACL's for certain developers to apply updates directly to CVS for both tracking and build source purposes. My current proposal is to do both this and one report per package publication for tracking the discussion necessary to bring each package to publication status. The procedure for submission, testing, approval and publication would be similar to what fedora.us is currently doing, except much more automated, with a few approval steps by managers along the way.
Currently FC is not using any Bugzilla tracking for each updates-testing, and this is a bit disconcerting for the community developers and users alike. This direction that we are heading will hopefully improve this situation.
Warren
Warren Togami warren@togami.com:
The bigger drawback is that you don't have an extras repository at all! It sounds like you may be allowing unattained perfection to become the enemy of the good.
Huh?
fedora.us is all about providing add-ons for Red Hat Linux, and now Fedora Core. (Well and also now Legacy, community developed security backport update packages for the older distributions.)
But I just got told twice that the Extras repository does not yet exist!
What I do want is a well-defined procedure by which I can drop (for example) fetchmail point releases into an "official" repository and have them available for people to apt-get.
apt-get may be a problem, given that there is great resistance within RH to including apt-get within FC. That resistance is weakening though. Resistance is futile. <evil grin>
Actually, I don't even care about apt per se. I could live with yum.
http://linux.duke.edu/projects/metadata/readme.metadata Fortunately though rpm-metadata is in the process of standardizing, and that will further reduce resistance to including apt since the same mirrors will work for apt, yum, or up2date. The question now is if apt and the other clients will have it fully implemented in time for FC2 inclusion. HELP THEM!!!
Ah, now this brings up my other issue, which is that the present RPM Groups field is basically useless and should be replaced with a Trove map. Who owns the format of that field?
My greatest concern here is that I question the efficacy of any such client. I can see how a XML-RPC client can used a template based approach in submitting new packages within a new Bugzilla report, or submitting a package update to an existing Bugzilla report, but otherwise I don't see it being very useful.
That would cover the common case where I'm doing a point release that I want to drop in to your repository.
https://bugzilla.fedora.us/show_bug.cgi?id=520 Something like how I started this Bugzilla report is one way packages are submitted. Only the URL to SRPM, URL to md5sums.asc, and a short description about what the package does. A tool that can do this reliably would save maybe 30-45 seconds. It would easy to use that same tool to post updates to that package in the existing report too. Beyond this what would the tool do that is useful?
What I want to do is be able to call that tool in my release scripts.
That is, I want to do with the Fedora repository what I now do for all 37 of my projects via freshmeat-submit, one of my recent projects. Whenever I do a release, I run an upload script specific to that project. The upload script does a bunch of uploads, then calls freshmeat-submit. freshmeat-submit does an XML-RPC transaction with freshmeat.net and posts a release announcement.
What I want to be able to do is run a client that drops submission information in your queue automatically, mining it out of my locally generated RPMs if need be.
You tell me the required metadata is (1) an URL to an SRPM, an MD5 signature, and a package description. This raises a couple of questions:
(1) Why not just mine the description out of the Description field of the SRPM?
(2) Don't RPMs have their own internal checksum?
If the answer to (2) is no, seems to me the thing to do would be to enhance RPM to do its own MD5 checksumming and require submitters to be using a version new enough to have that feature.
Ah, now this brings up my other issue, which is that the present RPM Groups field is basically useless and should be replaced with a Trove map. Who owns the format of that field?
The world, afaict. And per-pkg group listings aren't going to help. It doesn't cope well with i18n and the flexibility is horribly limited. This is why the groups stuff comes up in comps.xml.
-sv
On Wed, Jan 07, 2004 at 08:24:38PM -0500, Eric S. Raymond wrote:
Whenever I do a release, I run an upload script specific to that project. The upload script does a bunch of uploads, then calls freshmeat-submit. freshmeat-submit does an XML-RPC transaction with freshmeat.net and posts a release announcement.
That side of it makes complete sense.
You tell me the required metadata is (1) an URL to an SRPM, an MD5 signature, and a package description. This raises a couple of questions:
(1) Why not just mine the description out of the Description field of the SRPM?
(2) Don't RPMs have their own internal checksum?
Checksums and digital signatures optionally. One very good reason for submitting an MD5sum in the request though is to make sure you didn't screw up the URL or get a stale file cached somewhere. It could be a completely valid genuine GPG signed wrong RPM otherwise. Having the extra verification just means the system knows it got the right package, nobody slipped up and no evil web accelerator or cache got in the way to ruin the party.
(BTW SHA please MD5 has flaws 8)
Alan
skvidal@phy.duke.edu (seth vidal) writes:
(BTW SHA please MD5 has flaws 8)
What flaws in particular?
md5 is not collision resistant. An attacker could create a bad and a good rpm-package. Both could be modified in such a way that they stay valid rpm-packages but differ at some places (e.g. in padding bits). When having e.g. 64 such bits, you could create 2^64 different but valid packages.
For the 128 bit md5sum, it is very likely (at least for common security purposes) that you can find a matching good-bad package-pair within this 2^64 possibilities (birthday attack). Now, attacker places good package into the QA-queue and waits for the review. Then, he replaces it with the bad package (with same md5sum) and fedora.us will have a malicious package...
This attack can be prevented by two ways:
* use better hash-function (e.g. 160 bit SHA1), or * speedup QA process so that it is faster than the dup-finding process;)
I do not know numbers about the duration of md5sum birthday attacks, but IMO they are *not* an issue for current QA process...
Enrico
On Wed, Jan 07, 2004 at 08:41:52PM -0500, seth vidal wrote:
(BTW SHA please MD5 has flaws 8)
What flaws in particular?
I'm not disagreeing I'm just not aware of them and am also curious why rpm --dump sompkgname still lists md5sums of files instead of sha1sum's.
I guess because nobody hash changed systems yet. Its not a pressing problem. Of the 3 MD hash functions MD4 is broken entirely nowdays. MD2 has some known limits which are not serious and MD5. Its currently estimated that it would take someone several days to find an MD5 collision using custom hardware because MD5 has some cryptoanalytic weaknesses.
SHA-1 (the original SHA-0 was broken) is a somewhat strong algorithm that also has the advantage that people like the US government like it and its part of FIPS PUB 180-2.
At the moment I don't believe (but I am not a cryptographer!) that MD5 is a problem, but it is very likely to become so as machines get faster.
On Thu, Jan 08, 2004 at 09:02:07AM -0500, Alan Cox wrote:
On Wed, Jan 07, 2004 at 08:41:52PM -0500, seth vidal wrote:
(BTW SHA please MD5 has flaws 8)
What flaws in particular?
I'm not disagreeing I'm just not aware of them and am also curious why rpm --dump sompkgname still lists md5sums of files instead of sha1sum's.
I guess because nobody hash changed systems yet. Its not a pressing problem. Of the 3 MD hash functions MD4 is broken entirely nowdays. MD2 has some known limits which are not serious and MD5. Its currently estimated that it would take someone several days to find an MD5 collision using custom hardware because MD5 has some cryptoanalytic weaknesses.
SHA-1 (the original SHA-0 was broken) is a somewhat strong algorithm that also has the advantage that people like the US government like it and its part of FIPS PUB 180-2.
At the moment I don't believe (but I am not a cryptographer!) that MD5 is a problem, but it is very likely to become so as machines get faster.
I think md5 is only looked at if the rpm is not gpg-signed. At that point you should get sha1 checksumming, right? So md5 is anyway only a crc value, not something you rely on with the current tools.
greetings,
Florian La Roche
Alan Cox alan@redhat.com:
(2) Don't RPMs have their own internal checksum?
Checksums and digital signatures optionally. One very good reason for submitting an MD5sum in the request though is to make sure you didn't screw up the URL or get a stale file cached somewhere. It could be a completely valid genuine GPG signed wrong RPM otherwise. Having the extra verification just means the system knows it got the right package, nobody slipped up and no evil web accelerator or cache got in the way to ruin the party.
Got it. OK, this means my hypothetical client needs to be able to push the URL and a verification checksum. I still think the Description field ought to be extracted at the Fedora end from the SRPM itself.
esr@thyrsus.com ("Eric S. Raymond") writes:
Got it. OK, this means my hypothetical client needs to be able to push the URL and a verification checksum. I still think the Description field ought to be extracted at the Fedora end from the SRPM itself.
True, fedora.us is needing more infrastructure like a package registry with webfrontend and a better QA frontend (current bugzilla is not really suitable for the package-submission QA).
We need just a talented webdeveloper who is willing to spend time in such an implementation and/or the configuration of bugzilla ;)
Enrico
Enrico Scholz enrico.scholz@informatik.tu-chemnitz.de:
Got it. OK, this means my hypothetical client needs to be able to push the URL and a verification checksum. I still think the Description field ought to be extracted at the Fedora end from the SRPM itself.
True, fedora.us is needing more infrastructure like a package registry with webfrontend and a better QA frontend (current bugzilla is not really suitable for the package-submission QA).
We need just a talented webdeveloper who is willing to spend time in such an implementation and/or the configuration of bugzilla ;)
If you guys can task someone to do an XML-RPC service, I'll write the client. I just collaborated with Patrick Lenz over at freshmeat on a similar tool, quite successfully.
esr@thyrsus.com ("Eric S. Raymond") writes:
Something like how I started this Bugzilla report is one way packages are submitted. Only the URL to SRPM, URL to md5sums.asc, and a short description about what the package does.
...
(2) Don't RPMs have their own internal checksum?
Yes, they have but we request the md5sums because of security reasons: hostile packager could replace the package with a malicious version after a successful review.
The buildsystem verifies actual and expected MD5sum to prevent this kind of attack.
Enrico
Eric S. Raymond wrote:
My greatest concern here is that I question the efficacy of any such client. I can see how a XML-RPC client can used a template based approach in submitting new packages within a new Bugzilla report, or submitting a package update to an existing Bugzilla report, but otherwise I don't see it being very useful.
That would cover the common case where I'm doing a point release that I want to drop in to your repository.
Excellent.
https://bugzilla.fedora.us/show_bug.cgi?id=520 Something like how I started this Bugzilla report is one way packages are submitted. Only the URL to SRPM, URL to md5sums.asc, and a short description about what the package does. A tool that can do this reliably would save maybe 30-45 seconds. It would easy to use that same tool to post updates to that package in the existing report too. Beyond this what would the tool do that is useful?
What I want to do is be able to call that tool in my release scripts.
That is, I want to do with the Fedora repository what I now do for all 37 of my projects via freshmeat-submit, one of my recent projects. Whenever I do a release, I run an upload script specific to that project. The upload script does a bunch of uploads, then calls freshmeat-submit. freshmeat-submit does an XML-RPC transaction with freshmeat.net and posts a release announcement.
What I want to be able to do is run a client that drops submission information in your queue automatically, mining it out of my locally generated RPMs if need be.
You tell me the required metadata is (1) an URL to an SRPM, an MD5 signature, and a package description. This raises a couple of questions:
(1) Why not just mine the description out of the Description field of the SRPM?
(2) Don't RPMs have their own internal checksum?
If the answer to (2) is no, seems to me the thing to do would be to enhance RPM to do its own MD5 checksumming and require submitters to be using a version new enough to have that feature.
RPM does have all information necessary and it could be auto-generated yes. SRPMS are also signed with rpm --addsign before submission. We had been including md5sums GPG signed with package submissions so QA testers can easily verify signatures without the necessity of importing arbitrary user GPG keys into their rpm keyring. Using a simple upload script this is not a difficult time consuming process. I use the following script:
#!/bin/sh cd ~/fedora md5sum *.rpm > md5sums rm md5sums.asc gpg --clearsign md5sums rsync -e ssh -auv --delete /home/warren/fedora/
Warren
On Wed, 7 Jan 2004 20:24:38 -0500, Eric S. Raymond wrote:
The bigger drawback is that you don't have an extras repository at all! It sounds like you may be allowing unattained perfection to become the enemy of the good.
Huh?
fedora.us is all about providing add-ons for Red Hat Linux, and now Fedora Core. (Well and also now Legacy, community developed security backport update packages for the older distributions.)
But I just got told twice that the Extras repository does not yet exist!
fedora.us (Fedora Linux) does exist.
But due to its merger with the (ex-) Red Hat Linux Project into the Fedora Project, it's only a semi-official place where to get add-ons for now.
The _official_ Fedora Extras does not exist yet. It has higher goals, such as automated build systems, CVS repositories and more.
fedora.us is all about providing add-ons for Red Hat Linux, and now Fedora Core. (Well and also now Legacy, community developed security backport update packages for the older distributions.)
But I just got told twice that the Extras repository does not yet exist!
fedora.us (Fedora Linux) does exist.
But due to its merger with the (ex-) Red Hat Linux Project into the Fedora Project, it's only a semi-official place where to get add-ons for now.
I am, and I think a lot of other people, are a bit confused about this issue. fedora.us is on one hand not a official place, but on the other hand a lot off people on this list are refer to fedora.us like it is obvious that you should look there for info. But there are no info at fedora.redhat.com that fedora.us is a information source. And for a long time fedora.us had a first page saying that the site was no longer valid and refereed to fedora.redhat.com.
If the fedora/redhat people want involvement from other people I think it is important to inform us how to participate in the "community". As long as there are no information about how to help, I can't help.
A good start may be to look how other community based dists are doing: * gentoo - http://www.gentoo.org/doc/en/ebuild-submit.xml * debian - http://www.debian.org/devel/join/
/Magnus
The _official_ Fedora Extras does not exist yet. It has higher goals, such as automated build systems, CVS repositories and more.
--
Magnus Runesson wrote :
[...] I think a lot of other people, are a bit confused about this issue. fedora.us is on one hand not a official place, but on the other hand a lot off people on this list are refer to fedora.us like it is obvious that you should look there for info. But there are no info at fedora.redhat.com that fedora.us is a information source. And for a long time fedora.us had a first page saying that the site was no longer valid and refereed to fedora.redhat.com.
Well, didn't "FC1" exactly stand for "Fedora Confusion 1"? Oh wait, no, I'm probably just mixing up with something else. Oh, no, wait again... I'm just... confused :-D
Matthias
On Thu, 08 Jan 2004 16:40:47 +0100, Magnus Runesson wrote:
fedora.us (Fedora Linux) does exist.
But due to its merger with the (ex-) Red Hat Linux Project into the Fedora Project, it's only a semi-official place where to get add-ons for now.
I am, and I think a lot of other people, are a bit confused about this issue. fedora.us is on one hand not a official place, but on the other hand a lot off people on this list are refer to fedora.us like it is obvious that you should look there for info. But there are no info at fedora.redhat.com that fedora.us is a information source.
fedora.us is linked on the front page of fedora.redhat.com, in the "Fedora Name" section, and in particular on the "Participate" front page where it is advertized as an existing place where you can contribute "right now".
And for a long time fedora.us had a first page saying that the site was no longer valid and refereed to fedora.redhat.com.
The replacement front page only explained the merger of the "Red Hat Linux Project" and "Fedora Linux" and hence pointed people to the new "Fedora Project", but still provided an entry point to its start page.
If the fedora/redhat people want involvement from other people I think it is important to inform us how to participate in the "community". As long as there are no information about how to help, I can't help.
Click on "Participate" in the right menu at http://fedora.redhat.com then read the page. Or since you know about http://fedora.us now, read the pages at the right border there.
On Thu, 2004-01-08 at 08:24, Eric S. Raymond wrote:
Warren Togami warren@togami.com:
fedora.us is all about providing add-ons for Red Hat Linux, and now Fedora Core. (Well and also now Legacy, community developed security backport update packages for the older distributions.)
But I just got told twice that the Extras repository does not yet exist!
What's wrong with using Fedora.us repositories? A lot of important packages not found on Fedora Core is there - Mozilla Firebird, Thunderbird, Galeon, Gaim-encryption, etc. - and sometimes even bug fixes that have not been released by Red Hat.
- Michel
Eric S. Raymond wrote :
But I just got told twice that the Extras repository does not yet exist!
...and this is IMHO the biggest issue ATM. Once the minimal infrastructure shows up, it'll hopefully start moving forward real fast. But in the meantime, things are a bit opaque over at Red Hat and the result is that flame wars like this one still pop up from time to time.
I will not add anything to the thread. I just want to say that I'm impatiently waiting for Extras to exist at last. I really think it can bring all efforts together again if done the right way.
Matthias
On Thu, 8 Jan 2004 11:11:05 +0100, Matthias Saou wrote:
Eric S. Raymond wrote :
But I just got told twice that the Extras repository does not yet exist!
...and this is IMHO the biggest issue ATM. Once the minimal infrastructure shows up,
Minimal infrastructure won't make people happy who find the current fedora.us infrastructure and system unsatisfactory. Minimal infrastructure most likely means non-automated builds, and that will require human resources to perform package sanity checks before developer time is wasted on failed build attempts.
it'll hopefully start moving forward real fast.
Public discussion of the planned general procedure of package submission and approval, too.
Michael Schwendt wrote :
On Thu, 8 Jan 2004 11:11:05 +0100, Matthias Saou wrote:
Eric S. Raymond wrote :
But I just got told twice that the Extras repository does not yet exist!
...and this is IMHO the biggest issue ATM. Once the minimal infrastructure shows up,
Minimal infrastructure won't make people happy who find the current fedora.us infrastructure and system unsatisfactory.
Not necessarily. I meant things like a CVS repository for all spec files and patches (shared for Core, Extras and Alternatives for instance), starting to reuse (some of) the fedora.us guidelines and policies etc.
Minimal infrastructure most likely means non-automated builds, and that will require human resources to perform package sanity checks before developer time is wasted on failed build attempts.
Opening automated builds to outside developers, i.e. "part of the world" won't be trivial, so I wouldn't expect that to be anything near, even once past the "minimal infrastructure" part. Then again it would be a nice surprise if I was wrong about that.
I'm not quite sure I understand the end of your statement, so maybe I missed your point.
it'll hopefully start moving forward real fast.
Public discussion of the planned general procedure of package submission and approval, too.
I got the impression that the discussions which started ended with very few interventions from Red Hat's side, and "let's just reuse fedora.us" from the people contributing to fedora.us's side. Without more elements from Red Hat as to where the main direction is headed, I don't think current discussions can get to an acceptable (i.e. interesting) signal/noise level, and I take this very thread as a witness ;-)
Matthias
On Thu, 8 Jan 2004 13:10:28 +0100, Matthias Saou wrote:
Eric S. Raymond wrote :
But I just got told twice that the Extras repository does not yet exist!
...and this is IMHO the biggest issue ATM. Once the minimal infrastructure shows up,
Minimal infrastructure won't make people happy who find the current fedora.us infrastructure and system unsatisfactory.
Not necessarily. I meant things like a CVS repository for all spec files and patches (shared for Core, Extras and Alternatives for instance), starting to reuse (some of) the fedora.us guidelines and policies etc.
... and the ability to add CVS accounts (who has write-access where?) or just create it based on existing src.rpms in the repository? That would give more convenient access to src.rpm contents. But would it help populating an official Fedora Extras repo with packages?
Minimal infrastructure most likely means non-automated builds, and that will require human resources to perform package sanity checks before developer time is wasted on failed build attempts.
Opening automated builds to outside developers, i.e. "part of the world" won't be trivial, so I wouldn't expect that to be anything near, even once past the "minimal infrastructure" part. Then again it would be a nice surprise if I was wrong about that.
I'm not quite sure I understand the end of your statement, so maybe I missed your point.
The end refers to the necessity of package reviews, which complicate the package submission process and which are not accepted by some packagers. Which in turn brings us back to the question how QA will look like with official Fedora Extras?
Matthias Saou wrote:
I got the impression that the discussions which started ended with very few interventions from Red Hat's side, and "let's just reuse fedora.us" from the people contributing to fedora.us's side. Without more elements from Red Hat as to where the main direction is headed, I don't think current discussions can get to an acceptable (i.e. interesting) signal/noise level, and I take this very thread as a witness ;-)
Matthias
There are a two possible reasons why Red Hat developers have generally not gotten involved with our standards discussions.
1) Some have stated that they truly feel strict documented standards that fedora.us finds important simply DO NOT MATTER. They rather continue doing things the old way: Few strict standards and basically do whatever seems to work. This thankfully is a minority position.
2) Others who might care are simply too busy tackling DIFFICULT real development problems, like selinux or Gnome 2.6.
What we must all realize, especially Red Hat developers, is that we MUST discuss the standards that we will use for FC2 now. We must be prepared early during the beta period. And it DOES matter. We must have packaging guidelines, processes and policies documented unlike relying on the time consuming self-learing process, if we are ever to make this a truly open collaborative community project.
If Red Hat is not involved in these standards discussions, what I fear will happen is the community will create process & policy documents. Then later when those standards matter (FC2), Red Hat totally ignores it because they don't take us seriously, and they were not involved in those discussions. I see us heading in this direction and yet another not-so-openly-developed FC release unless things change now.
Regarding "let's just reuse fedora.us", I have long advocated doing so because fedora.us WORKS TODAY, and nobody else has submitted anything else remotely near a full comprehensive alternative proposal.
Building upon the current fedora.us, our discussions here will IMPROVE upon exising fedora.us policies & procedures in order to be prepared for FC2 and the Fedora Extras merge. Among the proposed changes in policies & procedures are:
* Package Naming will be altered with the overall goal of simplifying the fedora.us naming conventions without introducing new packaging problems. ** Remove the leading "0.fdr." from %{release} tags. ** Fully numeric disstags have been favored by RH and fedora.us leadership in past discussions, but this requires more discussion. ** reptag will not be necessary for Fedora Core and Fedora Extras, since FC and FE will be the authoritative repositories. All other repositories build around the FC+FE base. ** reptag will be necessary for all other repositories. The current proposal is attaching it at the end of %{release}.
* Changes to the QA process to allow smoother publication of packages without sacrificing quality and safety. * Better documentation explaining development processes, so new developers can get onboard more easily without wasting much time of existing developers. * Better documentation explaining the developer & tester trust gaining process. * All packaging conventions are to be compiled into a single better formatted package, with links to deeper information about individual packaging requirements. * Probably a lot more, but I can't think too well at 3:41AM...
I am now heading toward personally working on the following two: ---------------------------------------------------------------- * CVS with trust and legal forms requirements. ACLs allow users to have commit access to only certain packages of the repository, allowing the package maintainers to be community members. * Public build system available to trusted developers. Trusted developers can act as conduits for newer developers while they are in the process of gaining trust. All source code for the public build system will be fully Open Source and available for others to replicate for their own tesitng purposes, or 3rd party repository development.
Warren
- Some have stated that they truly feel strict documented standards
that fedora.us finds important simply DO NOT MATTER. They rather continue doing things the old way: Few strict standards and basically do whatever seems to work. This thankfully is a minority position.
I have put together a quick hack to run "rpmlint" on the current Fedora Core development rpms. I found a "%__mkfontdir" in OpenOffice and a "$RPM_BUILD_ROOT" in the octave rpm and have filed bugzilla reports on those two.
Apart from that it shows some further packaging errors, but they are mostly harmless. I don't think any other things warrent bugzilla reports, as that uses up more resources than is beneficial on the results side.
Feel free to use my current rpm to check additional rpm repositories or work on adding better config setting for rpmlint to make it more meaningful for FC2. Otherwise this should be a 2 days job for someone to add cleanup patches and recompile rpms, but not engage all individual rpm packagers with...
For people reading until now the url is http://people.redhat.com/laroche/rpmlint* with the src.rpm and the output of Fedora from a few days ago. (I have not yet looked at the fedora.us rpmlint rpm, just saw that repo also has one...)
greetings,
Florian La Roche
On Thu, 8 Jan 2004 14:55:22 +0100, Florian La Roche wrote:
I have put together a quick hack to run "rpmlint" on the current Fedora Core development rpms. I found a "%__mkfontdir" in OpenOffice and a "$RPM_BUILD_ROOT" in the octave rpm and have filed bugzilla reports on those two.
Please explain or post the bug numbers, because the "octave" component in Fedora Core and Raw Hide returns zarro boogs. Anything wrong about $RPM_BUILD_ROOT? Fedora.us guidelines prefer $RPM_BUILD_ROOT over %{buildroot}, because the former has been described as being much more official (though the latter is unlikely to be removed, isn't it?).
On Thu, Jan 08, 2004 at 03:13:11PM +0100, Michael Schwendt wrote:
On Thu, 8 Jan 2004 14:55:22 +0100, Florian La Roche wrote:
I have put together a quick hack to run "rpmlint" on the current Fedora Core development rpms. I found a "%__mkfontdir" in OpenOffice and a "$RPM_BUILD_ROOT" in the octave rpm and have filed bugzilla reports on those two.
Please explain or post the bug numbers, because the "octave" component in Fedora Core and Raw Hide returns zarro boogs. Anything wrong about
#112746 on bugzilla.redhat.com
$RPM_BUILD_ROOT? Fedora.us guidelines prefer $RPM_BUILD_ROOT over %{buildroot}, because the former has been described as being much more official (though the latter is unlikely to be removed, isn't it?).
Are you reviewing this per rpm or do you have automated scripts? Why would you bother how it is done unless it gives a broken rpm on installed machines? My hope is that people interested in this can at some point clean up spec-files, but this should not be pushed onto other developers who only care to look at functionality within rpms. Let's keep this modular from a developer resource issue. ;-)
greetings,
Florian La Roche
On Thu, 8 Jan 2004 15:32:08 +0100, Florian La Roche wrote:
On Thu, Jan 08, 2004 at 03:13:11PM +0100, Michael Schwendt wrote:
On Thu, 8 Jan 2004 14:55:22 +0100, Florian La Roche wrote:
I have put together a quick hack to run "rpmlint" on the current Fedora Core development rpms. I found a "%__mkfontdir" in OpenOffice and a "$RPM_BUILD_ROOT" in the octave rpm and have filed bugzilla reports on those two.
Please explain or post the bug numbers, because the "octave" component in Fedora Core and Raw Hide returns zarro boogs. Anything wrong about
#112746 on bugzilla.redhat.com
Filed about RHEL 3. Interesting.
$RPM_BUILD_ROOT? Fedora.us guidelines prefer $RPM_BUILD_ROOT over %{buildroot}, because the former has been described as being much more official (though the latter is unlikely to be removed, isn't it?).
Are you reviewing this per rpm or do you have automated scripts?
Automated scripts that would examine all packages in a repository would make sense only if there were strict policies which are accepted by all packagers. The primary part of your bug report is about $RPM_BUILD_ROOT in a post scriplet. That's an issue, of course.
Why would you bother how it is done unless it gives a broken rpm on installed machines?
Well, I don't, as long as the package builds and works. You need to understand that hardly anyone would disapprove a package because it used macros. But consistency is nice, whereas some packages are submitted with a mixture of %{buildroot} and $RPM_BUILD_ROOT. And btw, I must admit (and I've done that before) I don't really understand comments like this: http://www.fedora.us/pipermail/fedora-devel/2003-April/001155.html
Also, if it is agreed on using either one in all spec files, one can tune custom helper scripts.
And of course, you want to avoid that one packager prefers %buildroot and replaces every $RPM_BUILD_ROOT he finds and when a different packager prepares a major package update (or a development version), he changes every %buildroot back because he finds it ugly or anything like that.
warren@togami.com (Warren Togami) writes:
** Fully numeric disstags have been favored by RH and fedora.us leadership in past discussions, but this requires more discussion. ... ** reptag will be necessary for all other repositories. The current proposal is attaching it at the end of %{release}.
reptag at the end causes ambiguities. You can not say if '1.1.1.foo' means versions 1.1 for FC1, or if it means version 1 for FC1.1.
repotag before disttag is the only way which makes sense; see
http://www.fedora.us/pipermail/fedora-devel/2003-December/002478.html
Enrico
On Thu, 2004-01-08 at 08:17, Enrico Scholz wrote:
warren@togami.com (Warren Togami) writes:
** Fully numeric disstags have been favored by RH and fedora.us leadership in past discussions, but this requires more discussion. ... ** reptag will be necessary for all other repositories. The current proposal is attaching it at the end of %{release}.
reptag at the end causes ambiguities. You can not say if '1.1.1.foo' means versions 1.1 for FC1, or if it means version 1 for FC1.1.
repotag before disttag is the only way which makes sense; see
http://www.fedora.us/pipermail/fedora-devel/2003-December/002478.html
You're right. Sounds good. And additionally it makes numeric distribution tags readable (not just a number amongst other numbers but separated from the rest by the repository tag - the "and which of these numbers is the disttag?" question was one of my dislikes of the purely numeric scheme).
-- Fernando
Fernando Pablo Lopez-Lezcano wrote:
On Thu, 2004-01-08 at 08:17, Enrico Scholz wrote:
warren@togami.com (Warren Togami) writes:
** Fully numeric disstags have been favored by RH and fedora.us leadership in past discussions, but this requires more discussion. ... ** reptag will be necessary for all other repositories. The current proposal is attaching it at the end of %{release}.
reptag at the end causes ambiguities. You can not say if '1.1.1.foo' means versions 1.1 for FC1, or if it means version 1 for FC1.1.
repotag before disttag is the only way which makes sense; see
http://www.fedora.us/pipermail/fedora-devel/2003-December/002478.html
You're right. Sounds good. And additionally it makes numeric distribution tags readable (not just a number amongst other numbers but separated from the rest by the repository tag - the "and which of these numbers is the disttag?" question was one of my dislikes of the purely numeric scheme).
-- Fernando
This is assuming we accept reptag in all Core and Extras packages. Previous discussions have had reptag not included in FC and FE, but necessary for all other repositories.
On Thu, Jan 08, 2004 at 05:17:31PM +0100, Enrico Scholz wrote:
warren@togami.com (Warren Togami) writes:
** Fully numeric disstags have been favored by RH and fedora.us leadership in past discussions, but this requires more discussion. ... ** reptag will be necessary for all other repositories. The current proposal is attaching it at the end of %{release}.
reptag at the end causes ambiguities. You can not say if '1.1.1.foo' means versions 1.1 for FC1, or if it means version 1 for FC1.1.
That's why it was argumented (among others) that the disttag needs to start with letters like
-1.1.rhfc1.es -1.rhfc1.1.es
No ambiguity possible. Larger release numbers win over newer distributions.
repotag before disttag is the only way which makes sense; see
This breaks the use of disttags for ensuring distribution upgrade paths. For the same version the release number is compared. If that is equal it continues at the second order tier with the disttag. If even that was equal it would continue to comparing repotags, which would be senseless.
Pulling the repotag in front of the disttag obsoletes its use as an order parameter, which is a bad thing.
http://www.fedora.us/pipermail/fedora-devel/2003-December/002478.html
Axel.Thimm@physik.fu-berlin.de (Axel Thimm) writes:
reptag at the end causes ambiguities. You can not say if '1.1.1.foo' means versions 1.1 for FC1, or if it means version 1 for FC1.1.
That's why it was argumented (among others) that the disttag needs to start with letters like
-1.1.rhfc1.es -1.rhfc1.1.es
Seems that this needs an extra discussion. But for my taste, 'rhfc' is bit too long and shorter alternatives will destroy the updatepath.
No ambiguity possible.
With 'V.R.D' naming scheme (e.g. '-1.es.1.1') this would be no issue neither...
Larger release numbers win over newer distributions.
Same with V.R.D...
repotag before disttag is the only way which makes sense; see
This breaks the use of disttags for ensuring distribution upgrade paths.
1.foo.1 < 1.foo.1.1 is still the correct update-path.
Pulling the repotag in front of the disttag obsoletes its use as an order parameter, which is a bad thing.
Why? repotag is for information only. Using it as an ordering parameter would not be wise. %release can be compared within the same repository only, but not between repositories.
E.g. if to take '10.foo.rh9' or '1.bar.rh9' can not be determined by %release; it can mean that foo's packager is a bloody beginner who needed ten tries to make it built, and that '1.bar.rh9' was written by a packaging god who succeeded at the first try.
Enrico
On Sat, Jan 10, 2004 at 03:03:06AM +0100, Enrico Scholz wrote:
Axel.Thimm@physik.fu-berlin.de (Axel Thimm) writes:
reptag at the end causes ambiguities. You can not say if '1.1.1.foo' means versions 1.1 for FC1, or if it means version 1 for FC1.1.
That's why it was argumented (among others) that the disttag needs to start with letters like
-1.1.rhfc1.es -1.rhfc1.1.es
Seems that this needs an extra discussion. But for my taste, 'rhfc' is bit too long and shorter alternatives will destroy the updatepath.
Well, I started this discussion back in September leading to long, but yet starving threads. Check the archives for upgrade paths or disttags in the subject. There is also the same discussion on fedora.us from March/April.
No ambiguity possible.
With 'V.R.D' naming scheme (e.g. '-1.es.1.1') this would be no issue neither...
Larger release numbers win over newer distributions.
Same with V.R.D...
Yes, but only within a repoid world, not accross different repoid, e.g.
-1.1.es.rhfc5 loses over -1.1.fdr.rhfc1
which is clearly not what you want if you are considering more than one repo. If OTOH you are defining this for a non-repo-mixing world like fedora.us, you don't even have to add a repotag ...
Pulling the repotag in front of the disttag obsoletes its use as an order parameter, which is a bad thing.
Why? repotag is for information only.
Exactly. That's why it should get the least significant ordering, i.e. must be last. It would be better for it to not be considered as an order parameter at all, but that would mean pulling it into the name or dropping in. The former is insane, the latter would be better than putting in front of the disttag.
Using it as an ordering parameter would not be wise. %release can be compared within the same repository only, but not between repositories.
There _are_ some repositories coordinating. Why throw that away?
There are no benefits in doing it repotag in front of disttag, but there are doing it the other way.
E.g. if to take '10.foo.rh9' or '1.bar.rh9' can not be determined by %release; it can mean that foo's packager is a bloody beginner who needed ten tries to make it built, and that '1.bar.rh9' was written by a packaging god who succeeded at the first try.
foo's packager could have as well upped the Epoch and done lots of bad things to destroy both package contents, as well as upgrade paths.
The release buildnumber should alway win, second should come the disttag, in case the same build has been performed for verious distributions of the same upgrade line. repotag is order insignificant and should, if at all, only be placed last.
Personally I wouldn't mind seing repotag dissapear. There are other way identifying the origin of a package. But it doesn't hurt either (unless you write your full name in there and come from Spain ;).
Axel Thimm Axel.Thimm@physik.fu-berlin.de writes:
Larger release numbers win over newer distributions.
Same with V.R.D...
Yes, but only within a repoid world, not accross different repoid, e.g.
-1.1.es.rhfc5 loses over -1.1.fdr.rhfc1
which is clearly not what you want if you are considering more than one repo.
Why should the 'es' package win over the 'fdr' one? The right behavior would be that on updates the 'es' package will be installed when the old package is an 'es' one, and for 'fdr' vice versa. But this is not supported by current rpm/apt/yum/... tools so mixing of uncoordinated repositories needs manual intervention (e.g. apt-pinning) and it does not matter if repotag is before or after disttag.
If OTOH you are defining this for a non-repo-mixing world like fedora.us, you don't even have to add a repotag ...
It is used there for informational purposes, and it should not be used for other ones.
Pulling the repotag in front of the disttag obsoletes its use as an order parameter, which is a bad thing.
Why? repotag is for information only.
Exactly. That's why it should get the least significant ordering, i.e. must be last.
No, when used consistently, the position of the repotag does not matter for ordering and it should be set based on other criteria (like unambiguousness).
It would be better for it to not be considered as an order parameter at all, but that would mean pulling it into the name or dropping in.
I vote for latter option; Jeff Johnson mentioned that the DistURL: tag might be used for similar tasks but there are no proposals how to integrate it in into current tools (apt/yum).
Perhaps the disttag should be disappear too and highlevel tools like apt and yum should decide based on DistURL: whether package is to be updated on dist/repo change or not.
Using it as an ordering parameter would not be wise. %release can be compared within the same repository only, but not between repositories.
There _are_ some repositories coordinating. Why throw that away?
When coordinated repositories are having distinct packagesets, this whole discussion is unneeded. Having overlapping packagesets is duplicate work and sounds like russian roulette to me: the most modified package wins which might be either a sign of good maintainership, or of unability to make it working.
Enrico
On Sun, Jan 11, 2004 at 06:06:47PM +0100, Enrico Scholz wrote:
Axel Thimm Axel.Thimm@physik.fu-berlin.de writes:
Larger release numbers win over newer distributions.
Same with V.R.D...
Yes, but only within a repoid world, not accross different repoid, e.g.
-1.1.es.rhfc5 loses over -1.1.fdr.rhfc1
which is clearly not what you want if you are considering more than one repo.
Why should the 'es' package win over the 'fdr' one?
Maybe, because it is build for FC5 at the end of 2005 instead of the version for FC1?
If OTOH you are defining this for a non-repo-mixing world like fedora.us, you don't even have to add a repotag ...
It is used there for informational purposes, and it should not be used for other ones.
So make it order insiginificant and move it towards the end of the release tag, maybe that far, that it drops off.
Using it as an ordering parameter would not be wise. %release can be compared within the same repository only, but not between repositories.
There _are_ some repositories coordinating. Why throw that away?
When coordinated repositories are having distinct packagesets, this whole discussion is unneeded. Having overlapping packagesets is duplicate work and sounds like russian roulette to me: the most modified package wins which might be either a sign of good maintainership, or of unability to make it working.
There are quite valid reasons (and welcomed, too) for packages being overridden by other repositories, for example
o if a first tier repository is only allowed to ship a crippled version of some software for whatever reason (patents, non-OSS components disabled, etc.), as well as o if a package in a repository will not be maintained anymore like products reaching their EOL, o you need a fast security update, o you build a custom repo with custom modification (where this repo could even be private in a company), o possible more reasons, just check all existing repos, all have had an upgrade of some base component for one reason or another.
Back to the the core matter: As placing the repotag in front of the disttag only obstructs things, please don't suggest it. Place it after the disttag or drop it. My suggestion for specs:
Make it an optional suffix to relase tags:
releasetag := <build>[.<disttag>][.<releasetag>]
(for completeness sake disttag is also flagged as optional as some packages like firmware packages can be safely assumed cross distribution valid).
On Wed, 7 Jan 2004 18:56:57 -0500, Eric S. Raymond wrote:
http://www.fedora.us/wiki/RepositoryMixingProblems Due to these reasons fedora.us has always said that we will not coordinate with external repositories. We never have these package clashes, and our package quality is on the average better. The drawback here is slower package review and publication.
The bigger drawback is that you don't have an extras repository at all!
Huh?
--
On Wed, Jan 07, 2004 at 01:35:13PM -1000, Warren Togami wrote:
freshrpms/axel/dag/newrpms is comprised of several one-man operations that sometimes conflict and cause package clashes.
Even when that happens from time to time (the compined repos do have 892 packages as I just read off Dag's page), these are far less severe than the painful "Epoch: 0" slamming that fedora.us applied with obvious zero QA, breaking all users mixing repositories.
In fact we should be the ones warning from mixing with fedora.us.
They have no published QA policy and only after-the-fact peer review and revisions.
Well, Red Hat also does not have published QA policies, so this is not a sign of not having QA and good packaging. And fedora.us has been accomodating its QA policy also to its liking, or some people were suddenly dictating package submission freezes and unfreezes as they saw fit.
http://www.fedora.us/wiki/RepositoryMixingProblems Due to these reasons fedora.us has always said that we will not coordinate with external repositories. We never have these package clashes, and our package quality is on the average better.
I am sure you have to believe that ;)
The drawback here is slower package review and publication.
Those other repositories are authoritative, within their own world. You can choose to live in either their world, or our world. Open Source means you have the freedom to choose. I choose to live in the fedora.us world, and apparently so did Red Hat. [1]
Yes, that is true.
BTW the fedora.us folks are not the problem. I found them mostly cooperative and willing to discuss common problems (but then mostly private). There are very fine packagers among them, and most of them don't believe in monoculture, too. I hope to see a phase transition, or an internal revolution, that will drop the bad hertitage.
(1) Software compromised for IP reasons must be exiled to livna.org Repository keepers must agree to comply with a ban list compiled by Red Hat.
It already seems to have happened. It seems that rpm.livna.org is collaborative with a Bugzilla and QA procedure too.
Isn't rpm.livna.org the offspring from fedora.us, where all no-go packages were copied to (rhetorical question ;)? So it isn't a real accomplishment to be cooperative with yourself, as it is not a wonder either that fedora.us has indeed a repository it does not reject cooperation with ...
(2) RPMs must meet Fedora QA standards. Repository maintainers must expect their submission, test and build procedures to be audited, and will be dropped from the list of authoritative repositories if they fail to meet standards.
We have fedora.us QA standards and nobody else has suggested a full proposal for an alternative, so currently fedora.us is on track for eventally become Fedora Extras around FC2 timeframe.
So, R P Herrold's workflow suggestions have not only been ignored but totally wiped out of memory, too.
Here is a simplified paragraph of (the known) ATrpms QA procedure: Packages exist in four states: "stable", "good", "testing", "bleeding". New packages enter at the end of the stability scala. People do QA by chosing their stability level. Their feedback decides on moving the package into more stable or less stable regions.
This had been suggested on fedora.us more than half a year ago.
fedora.us is the only authoritative repository & project.
There is no authoritative list of repositories because fedora.redhat.com is designed so the user can choose to use any 3rd party repository.
So you won't propose "RepositoryMixingProblems" there? ;)
I doubt you'd get any pushback on these requirements. And the cost of QA-monitoring these repositories would undoubtedly be lower than the cost of building and maintaining one big repository of your own. You'd win fairly big on the download costs alone.
We respectfully disagree with this line of thinking.
I think the winnings would have been more on not dublicating things. We could be twice as far, if fedora.us had only invested time in packaging not already packaged packages, or had invested into compatibility, as the free repositories cannot use fedora.us due to its mixing problems (Compatibility issues must ba handled from both sides).
On Thu, 8 Jan 2004 04:16:01 +0100, Axel Thimm wrote:
On Wed, Jan 07, 2004 at 01:35:13PM -1000, Warren Togami wrote:
freshrpms/axel/dag/newrpms is comprised of several one-man operations that sometimes conflict and cause package clashes.
Even when that happens from time to time (the compined repos do have 892 packages as I just read off Dag's page), these are far less severe than the painful "Epoch: 0" slamming that fedora.us applied with obvious zero QA, breaking all users mixing repositories.
What have you been smoking? Explicit Epoch 0 in versioned dependencies is a QA policy. And explicit Epoch 0 in packages itself doesn't do any harm.
(1) Software compromised for IP reasons must be exiled to livna.org Repository keepers must agree to comply with a ban list compiled by Red Hat.
It already seems to have happened. It seems that rpm.livna.org is collaborative with a Bugzilla and QA procedure too.
Isn't rpm.livna.org the offspring from fedora.us, where all no-go packages were copied to (rhetorical question ;)? So it isn't a real accomplishment to be cooperative with yourself, as it is not a wonder either that fedora.us has indeed a repository it does not reject cooperation with ...
rpm.livna.org does not reject cooperation with fedora.us as it depends on fedora.us (besides Core packages). For livna.org to cooperate with other repositories, there are not enough developer resources available.
On Wed, Jan 07, 2004 at 06:11:21PM -0500, Eric S. Raymond wrote:
will put these repositories in the distributed apt.sources and collectively designate them as Fedora Extras, on the following conditions:
(1) Software compromised for IP reasons must be exiled to livna.org Repository keepers must agree to comply with a ban list compiled by Red Hat.
Even linking to such repositories may be illegal.
On Wed, Jan 07, 2004 at 06:11:21PM -0500, Eric S. Raymond wrote:
As for the DECSS problem, everybody understands it and we already have a workaround via the existence of livna.org.
I suggest that Fedora make the following offer to this group: Fedora will put these repositories in the distributed apt.sources and
I think you mean yum not apt ?
(2) RPMs must meet Fedora QA standards. Repository maintainers must expect their submission, test and build procedures to be audited, and will be dropped from the list of authoritative repositories if they fail to meet standards.
I doubt you'd get any pushback on these requirements. And the cost of QA-monitoring these repositories would undoubtedly be lower than the cost of building and maintaining one big repository of your own. You'd win fairly big on the download costs alone.
You assume that centralisation is good. From day one it was apparent that people would keep repositories however they felt like keeping them. Once things around Extras/Addons finally get saner I am sure there will be packages that migrate into that, and likewise I am sure there will be packages that move the other way.
Another thing to bear in mind is that quite a few of the repositories people run that are not so well known would fall flat if they were in the default yum configuration, just as some of the mirrors would if they were in the default configuration for the base packages and updates.
IMHO we are by far the better for having multiple repositories which maybe co-operate but don't share policy or agree on things entirely. It'll sort itself out over time as to which methods work best and what users like to do.
There are however some things that would definitely benefit the world whichever way we go. The most obvious one is a program and a description format for describing a repository and adding/removing it from /etc/yum.conf. The reason for that being to make it a mozilla helper so when you go to freshrpms or wherever you can simply click "Subscribe" and get a local dialog/tool doing the yum.conf updating, checking an GPG signature and if appropriate importing their GPG key.
Point and click subscribe solves a lot of the problems about finding stuff especially if someone decides to keep an index of repositories.
Alan
On Wed, 7 Jan 2004 18:11:21 -0500, Eric S. Raymond wrote:
If you look at http://dag.wieers.com/home-made/apt/mega-merge.php, you'll see that this group describes itself as "The Red Hat/Fedora authoritative packager list".
Marketing.
(2) RPMs must meet Fedora QA standards.
I appreciate that you're trying to push Fedora Extras forward. But "Fedora QA standards" are not an open thing yet. Actually, not even packaging guidelines or policies exist yet.
Repository maintainers must expect their submission, test and build procedures to be audited, and will be dropped from the list of authoritative repositories if they fail to meet standards.
Get them to not offer competing sets of packages. Or who will test all possible permutations of packages from repo X used together with alternative versions of dependencies found in repo Y and Z? And why not review packages prior to release? And what are the "standards" and who defines them? And what to do when the individual packager, with hits several hundreds of packages to maintain, can't catch up with security fixes due to lack of time or package updates during vacation? I still think a community project would be superior.
I doubt you'd get any pushback on these requirements. And the cost of QA-monitoring these repositories would undoubtedly be lower than the cost of building and maintaining one big repository of your own. You'd win fairly big on the download costs alone.
In theory, enough human resources provided, it should be possible to take over a src.rpm from an arbitrary repository, review it and publish it elsewhere.
On Wed, Jan 07, 2004 at 05:37:58PM -0500, Eric S. Raymond wrote:
Alan Cox alan@redhat.com:
On Wed, Jan 07, 2004 at 04:41:34PM -0500, Eric S. Raymond wrote:
I can see clearly that you want to automate it for your own package trees so that people can effectively subscribe to 'fetchmail of the day' or similar things. For that you might want to look at Dag Wieers stuff since he's rolling 500+ packages for several releases all the time.
Pointer?
google:dag wieers 8)
I found it, and then I found the ring he's part of (ATrpms, dag, FreshRPMS and newrpms).
This alliance is enlargening, and represents the Bazaar in contrast to fedora.us' Cathedral ;)
We believe in diversity and while we all joined fedora.us a year ago, believing the project would serve as a coordinating entity, we were finally driven away by the curse set by the current project's leadership towards a monoculture. fedora.us' leadership only recently proclaimed that rejecting cooperation with us back then and now is a good thing.
My suggestion to you would be to setup your own repository. It is quite easy, and I can help out in PM. One of ATrpms' tasks is to enforce people to create their own repos in a loosly coordinated repo maintainer forum.
Hmmm....
Perhaps these people should *be* Fedora extras? Looks to me like the community has already evolved a rather well-functioning set of apt repositories. and I like the no-single-point-of-failure aspect of what they're doing.
Thanks!
Is there some reason for Fedora not to farm out the extras job to people who seem already to be doing it competently?
Fedora is a merger of Red Hat Linux and fedora.us, carrying even fedora.us' name. Since fedora.us rejected and rejects cooperation on the grounds of "coordination being far too difficult and incurring much greater overhead", some of this may have colored off on the merged Fedora project.
Personally I think these problems are induced by fedora.us' leadership. I believe most of the other fedora.us' folks are openminded towards interrepository communication and coordination. Maybe a change in leadership will unblock the rejection attitude and brings us further along. But this is something fedora.us or Fedora needs to resolve internally.
Anyway the current setup of heretic repos is working quite well. Become a heretic yourself today! ;)
On Thu, 8 Jan 2004 00:34:22 +0100, Axel Thimm wrote:
We believe in diversity and while we all joined fedora.us a year ago,
Joining a mailing-list is not equal to joining fedora.us.
Joining fedora.us is what I've had hoped some of the existing packagers would be interested in.
However, the list archives of fedora-devel@fedora.us between November 2002 and April 2003 contain many political discussions and no real signs of the packagers wanting to merge into an open community project.
The archives are pretty tiresome to read with all the debates about making fedora.us adapt existing packaging practise instead of working on improved guidelines for a single source of extra packages (well, except for packages with patenting and licencing issues).
IMO, there has never been an interest in collaborating on truely authoritative packages. Instead, the old competition of who pushes out an update package first continues, and it is tried to cover the true motivation behind that with arguments like "diversity is good", even if the only differences between two given packages are insufficient build dependencies, wrong dependencies or a file being included in a different sub-package.
In reality, what those individual repository maintainers want is total control about their own packages and, of course, continueing to run their own branded repositories with fame and glory in mind.
Official Fedora Extras gives the chance to redo some of the pre fedora.us discussions. And yet again, some of the individual repo maintainers showed interest only in repository inter-operability or avoiding modification to their packages inflicted by changes in Fedora Core, e.g. /etc/redhat-release detection or package release distribution tags.
believing the project would serve as a coordinating entity,
With individual repository maintainers not being willing to compromise that has turned out to become impossible or *very* time-consuming. While fedora-devel@fedora.us would still be discussing subtleties, the individual repo maintainers would continue to pipe out packages without prior community reviews and approvals.
Anyway the current setup of heretic repos is working quite well. Become a heretic yourself today! ;)
Except for package conflicts which the ordinary user encounters easily when he tries to mix freshrpms and ATrpms.
On Thu, Jan 08, 2004 at 03:01:01AM +0100, Michael Schwendt wrote:
On Thu, 8 Jan 2004 00:34:22 +0100, Axel Thimm wrote:
We believe in diversity and while we all joined fedora.us a year ago,
Joining a mailing-list is not equal to joining fedora.us.
No, but having crafted parts of fedora.us' specs and trying to keep it on the Right Track (TM) is.
However, the list archives of fedora-devel@fedora.us between November 2002 and April 2003 contain many political discussions and no real signs of the packagers wanting to merge into an open community project.
You wear funny glasses. The "political discussions" were about creating specifications that either serve a single repo only or more (both then existing and future repos). And then people got upset with
o a call to clone freshrpms instead of extending it. o fedora.us decisions being made by a single person after consulting two pals on irc. o any input about interrepository issues bouncing off on hostility or ignorance.
Indeed fedora.us' leadership explicitly states that it has rejected cooperation back then as is continuing to still do so, as it believes it to be the right thing to do.
So what signs exactly were you expecting? Why should someone who's work and input is being rejected want to merge with fedora.us?
The archives are pretty tiresome to read with all the debates about making fedora.us adapt existing packaging practise instead of working on improved guidelines for a single source of extra packages (well, except for packages with patenting and licencing issues).
Now that's utter crap.
In reality, what those individual repository maintainers want is total control about their own packages and, of course, continueing to run their own branded repositories with fame and glory in mind.
O.K., you try to reach for below the belt, I won't bite.
Official Fedora Extras gives the chance to redo some of the pre fedora.us discussions. And yet again, some of the individual repo maintainers showed interest only in repository inter-operability or avoiding modification to their packages inflicted by changes in Fedora Core, e.g. /etc/redhat-release detection or package release distribution tags.
Please explain. Package disttags have been sorted out after a very long staving thread. So what are you referring at?
believing the project would serve as a coordinating entity,
With individual repository maintainers not being willing to compromise that has turned out to become impossible or *very* time-consuming.
How can something that has not even been tried become *very* time-consuming? Are you applying revision to history?
While fedora-devel@fedora.us would still be discussing subtleties, the individual repo maintainers would continue to pipe out packages without prior community reviews and approvals.
You are confusing things here. The long start of fedora.us was due to discussing specs, and interrepository qualification was never accepted. This resulted in people not liking fedora.us' emerging policies and their comments, but not in a delay of the specs. I remember myself even encouraging to stop academia and start packaging, so you are obviously blaming the wrong people.
Anyway the current setup of heretic repos is working quite well. Become a heretic yourself today! ;)
Except for package conflicts which the ordinary user encounters easily when he tries to mix freshrpms and ATrpms.
I wonder how I managed to grow my repository from day one compatible with freshrpms then, and how it works that every ATrpms user has another 5-11 other repositories active including freshrpms? I must have probably be dreaming that this is happening.
Have you ever checked the conflicts you would encounter mixing fedora.us and <name a big repo here>? Ever read the threats about the biggest repository mixing problem being the Epoch: 0 problem induced by fedora.us in March/April?
Yes, the warning about not mixing fedora.us with other repos had finaly become valid, fedora.us created the mixing nightmare it was trying to solve ...
On Thu, 8 Jan 2004 03:39:06 +0100, Axel Thimm wrote:
However, the list archives of fedora-devel@fedora.us between November 2002 and April 2003 contain many political discussions and no real signs of the packagers wanting to merge into an open community project.
You wear funny glasses. The "political discussions" were about creating specifications that either serve a single repo only or more (both then existing and future repos). And then people got upset with
You write "people" to hide the fact that only a very few persons have participated in those discussions.
o a call to clone freshrpms instead of extending it.
Nice play with words. Fedora.us' goal was to depend solely on Red Hat Linux or Fedora Core, respectively, and not on any independent none-open repository maintained by single individuals.
o fedora.us decisions being made by a single person after consulting two pals on irc.
Which has been criticized and stopped, AFAIK. Nowadays there are a few more interested people at fedora.us who voice their concerns and who are consulted before any policy is changed. But it is also understandable that this infamous "single person" wanted to get a community project getting started rather sooner than later. Fedora.us has infrastructure in place which we can use *right now* and which older projects, such as rhcontrib.bero.org or rpmforge.net had not, and which other project don't have either. What we do with it is up the community who is free to support/contribute and influence future decisions.
o any input about interrepository issues bouncing off on hostility or ignorance.
Indeed, the term "hostility" is not far off. Some threads in the archives can be described best as heated controversies. Nowadays it is not much different on this list, unfortunately, because some people continue to blame specific individuals.
So what signs exactly were you expecting? Why should someone who's work and input is being rejected want to merge with fedora.us?
The question is biased. Of course there has never been interest in offering existing packages under the fedora.us "brand" or applying QA procedures for packages which "seem to be just fine". No further comment.
We've been through this before. I don't maintain a huge repository and popular website myself and hence I don't have the duty to maintain several hundred packages for different distributions and to track a mailing-list for possible bug reports or issues. But I know what it is like to create packages because the software has not been packaged yet and what a great feeling it is to find well-made and well-maintained packages provided by someone else which I can rely on.
The archives are pretty tiresome to read with all the debates about making fedora.us adapt existing packaging practise instead of working on improved guidelines for a single source of extra packages (well, except for packages with patenting and licencing issues).
Now that's utter crap.
Now that's hostility.
In reality, what those individual repository maintainers want is total control about their own packages and, of course, continueing to run their own branded repositories with fame and glory in mind.
O.K., you try to reach for below the belt, I won't bite.
Get an unbiased person to wade through the fedora-devel@fedora.us list archives and comment on what impression he gets. But of course, I'm considered biased, too, and "wear funny glasses".
Official Fedora Extras gives the chance to redo some of the pre fedora.us discussions. And yet again, some of the individual repo maintainers showed interest only in repository inter-operability or avoiding modification to their packages inflicted by changes in Fedora Core, e.g. /etc/redhat-release detection or package release distribution tags.
Please explain. Package disttags have been sorted out after a very long staving thread. So what are you referring at?
Exactly the overly long starving thread(s).
believing the project would serve as a coordinating entity,
With individual repository maintainers not being willing to compromise that has turned out to become impossible or *very* time-consuming.
How can something that has not even been tried become *very* time-consuming? Are you applying revision to history?
Please sum up, what has been attempted at by fedora-devel@fedora.us prior to April 2003?
Anyway the current setup of heretic repos is working quite well. Become a heretic yourself today! ;)
Except for package conflicts which the ordinary user encounters easily when he tries to mix freshrpms and ATrpms.
I wonder how I managed to grow my repository from day one compatible with freshrpms then, and how it works that every ATrpms user has another 5-11 other repositories active including freshrpms? I must have probably be dreaming that this is happening.
Check your sources of input. Check some message boards and mailing-lists. Conflicts between your packages and freshrpms.net do exist. People are smart enough to work around conflicts and don't make it a big issue.
Have you ever checked the conflicts you would encounter mixing fedora.us and <name a big repo here>?
Fedora.us is neither designed as being mixable nor is it advertized as being mixable.
On Thu, Jan 08, 2004 at 04:48:50AM +0100, Michael Schwendt wrote:
Have you ever checked the conflicts you would encounter mixing fedora.us and <name a big repo here>?
Fedora.us is neither designed as being mixable nor is it advertized as being mixable.
I would certainly prefer it was designed to make it easy for other people to keep their archive sets compatible. FC1 core doesn't advertise 5 year binary compatibility - and doesn't have it, but nobody is proposing to completely ignore compatibility and breaking third party repository code.
On Thu, 8 Jan 2004 09:10:52 -0500, Alan Cox wrote:
On Thu, Jan 08, 2004 at 04:48:50AM +0100, Michael Schwendt wrote:
Have you ever checked the conflicts you would encounter mixing fedora.us and <name a big repo here>?
Fedora.us is neither designed as being mixable nor is it advertized as being mixable.
I would certainly prefer it was designed to make it easy for other people to keep their archive sets compatible. FC1 core doesn't advertise 5 year binary compatibility - and doesn't have it, but nobody is proposing to completely ignore compatibility and breaking third party repository code.
Sounds as if you may have misunderstood my comment. It *is* easy for other people to keep their own repositories compatible with fedora.us, but not vice versa. For instance, you are incompatible with fedora.us as soon as you give your packages names which differ from fedora.us package naming guidelines and when that results in failed/unresolvable dependencies or unsupported upgrade paths. Similarly, you are incompatible if you include files in packages where they conflict with fundamental packages from fedora.us. It's not the job of fedora.us to allow for such mixing of repositories. By publishing guidelines and policies fedora.us (and the Fedora Project will have to do that, too) lay the groundwork for 3rd party repositories to play well with it. If, however, you ask for working around potential clashes with independent repositories, well, who will do the extra testing of mixed repositories? I don't see anyone who would be willing to test whether an application package from fedora.us is satisfied with dependencies taken from a 3rd party repository and vice versa. It's not fedora.us' job to adapt to a multitude of existing independent packagers, their usually undocumented packaging styles and their packages.