HTML dump on Sat Feb 22 18:59:19 EST 2003
http://videl.ics.hawaii.edu/pipermail/fedora-devel/2003-February/000244.html
#[1]Index [2]Previous [3]Next
[Fedora-devel] Re: Fedora Package Wish List
R P Herrold [4]fedora-devel@videl.ics.hawaii.edu
Fri Feb 21 19:28:00 2003
* Previous message: [5][Fedora-devel] Re: Fedora Package Wish List
* Next message: [6][Fedora-devel] Fedora Package Naming Guidelines
(Draft #3)
* Messages sorted by: [7][ date ] [8][ thread ] [9][ subject ] [10][
author ]
_________________________________________________________________
On Fri, 21 Feb 2003, Warren Togami wrote:
> I hope that people do not see me as trying a "hostile takeover" of
> FreshRPMS. I have great respect for Matthias and his good work with his
> excellent packages. I am only pointing out these issues of co-existence.
Think before you do, do what is right, and don't worry about
what people think. But you have to expect criticism when you
propose a massive independent packager repository fork. There
are not that many of us, and after reflection, you have to
know it would leave a bad taste. The 'issue' of
"co-existence" only arises because of overlap. No overlap --
no issue.
I also think you need to pick a battle that is still alive.
Mathias' email crossed my mailbox through the:
[11]rpm-list@freshrpms.net route three days ago. 'Thias hung out
on the IRC as well, and I had a nice extended chat with him.
I am thinking of seeking 'yum' archive coverage in
freshrpms.net. it is only about 1/10th as big as the apt space
requirement. I am in process, doing so for my
archive.
The battle is not can we get a unification in versioning,
avoiding apt looping upgrades; nor can freshrpms get free of
Epoch, once improvidently used; nor can Fedora produce an
archive into a state permitting hands-off 'apt' maintenance;
nor if we can get apt to use the same version comparison code
as rpm; nor even, if we can get rpm itself to hands-off solve
versioning conflicts solely hased on external file names.
These are RPM packaging problems everywhere; in unification,
freshrpms, Fedora, apt, AND rpm -- they exist (like bones in a
piece of cooked fish), and a careful packager will be aware of
them.
The same problems, with different manifestation, exist if you
use Debian. See:
[12]http://lists.debian.org/debian-devel/2003/debian-devel-200302/msg00736.h
tml
and are worse with the BSD's in binary maintenance
matters, and worse still in commercial Unix(tm) if one strays
from the vendor. There is a reason that RTR, and TWW, are the
only major porting houses with any reasonable prominence, and
the they limit themselves largely to straight FSF and
major peoject builds.
As to the 'hostile takeover' matter, I certainly try to keep
perspective that we are only packaging software -- and that a
person who blindly relies on others, and automated maintenance
without understanding the issues is going to get wedged, from
time to time. See:
[13]http://lists.debian.org/debian-devel/2003/debian-devel-200302/msg00774.h
tml
Rusty Coker (active in SE Linux) chimed in with the mplayer
example, closer to home for RHL -- remember the stink there?
[14]http://lists.debian.org/debian-devel/2003/debian-devel-200302/msg00789.h
tml
... so there are simply issues, benign and malicious, which
Fedora cannot solve. Accept it, get over it, and move on.
I'm gonna' keep packaging my way for my use in my repository;
until and unless the Fedora process gets documented, open, and
running, I'm not gonna sign any Fedora packages.
[ I think it was a serious mistake, except for the newness of
the QA proposal, and the absence of tools to systemetize
uploads and review sign-offs, for you to have tracked down and
verified upstream sources matched md5sums -- the package and
the tarball sums and sigs either match, or they do not.
Absent sigs == do not match.
... If they don't check out, as a courtesy you might tell the
submitter (no-one is reading my QA doc proposal anyway --
there are two sections 14b ), and let then withdraw the
submission. If they don't do so in a timely fashion, file a
Negative under 14c. You cannot, and I will not try to, do
everything. If it is outside demarc'ed responsibility, file
the exception, and move on. Debian figured this out with
formal ITP's and NM removals, long ago. If is not a
co-incidence my QA draft is rathar formal and has objective
criteria. ]
Anyway, back to your post, how else can one casually read the
comments at 03:34:52 and 03:34:55, other than as a 'there can
be only one' Highlander ending... . If you want
essentially perfect, but exceedingly stale, you should
probably package only for Debian stable.
I understand that you (hopefully) are in the IRC section,
referring to frustration on co-ordination of package naming
and enumeration. But we already have had this issue for a
long time. It's not that big a deal. Not worth a fork, not
preventing Fedora from completing infrastructure and doing
quality packaging of unique offerings today.
A friend was building 'lame' this week from MDK-style SRPMs,
and it carried a (broken, in my opinion, because unnecessarly
obvious)
BuildRequire: gcc3
Well of course, pounding out this cruft, and doing the Mdk
custom macro expansion fixup needed for an RHL build
environment, it builds and runs on RHL.
At a SRPM level, one can solve ABI compatability issues
between RHL and MDK and CL and Apple OS/X (OR [maybe] by being
strictly compliant with JUST _LSB_ dependencies, do so at a
BINARY level within the LSB compliant Linuxes). I say Maybe,
because I have not seen it., and I have been looking hard for
it for years ( [15]http://www.owlriver.com/projects/SLUG/ - it is
one of the earliest pieces of independent content referenced
at the LSB site -- well, checking, they have cut over to
php-nuke, and pre 2002 content has vanished. It was ...)
Finally -- I'm frustrated too, at the absence of design
and documentation feedback. But that just means I conform
_my_ packaging and documentation efforts, and provide an
example. I am in process 'yum-ifying' my archive, which is
non-trivial, because of yum variances, forced on it in turn by
the rpm-librpm-python issues which dcran and I have been
working on in #fedora.
- Russ herrold
[03:30:56] I have to uninstall freshrpms
gpgme
[03:31:01] uninstall kgpg
[03:31:16] to install fedora gpgme just to
try gpa?
[03:31:31] Yes
[03:31:37] This is a huge problem that Matthias
doesn't want to cooperate
[03:31:48] Warren, why?
[03:31:52] Warren: wha?
[03:31:57] everyone on the mailing lists wants to
keep freshrpms AND fedora AND other reps in their sources.list
[03:32:07] Warren: 'splain please
[03:32:08] but we will have these incompatibilities
[03:32:18] how are the gpa packages incompatible?
[03:32:32] a few days ago several people very vocally
said that they DON'T want fedora to have the same packages
as freshrpms
[03:32:35] Warren: I don't particularly care
to keep freshrpms and fedora if they'll cause me headaches
[03:32:42] SteamedPenguin: exactly
[03:32:59] I'll kick fedora to the curb and
get back in bed with freshies
[03:33:01] but due to dependency problems like what
you hit just, it isn't practical
[03:33:05] crap, wrong channel
[03:33:09] I don't want fedora to have the same
packages as freshrpms until the build server is going
[03:33:23] gleblanc: Then I need to rip out gpa
[03:33:33] Warren, well, wait, before you do that
[03:33:35] heh
[03:33:53] Warren, first I need to know why the
heck the two gpa packages aren't compatible
[03:34:04] gleblanc: He has an earlier version of
gpgme
[03:34:07] gleblanc: gpgme
[03:34:07] because that makes no sense to me,
unless they're non-ABI compatible versions
[03:34:08] gleblanc: and he's using epochs
[03:34:23] err, yeah, I meant gpgme, obviously
[03:34:31] now the difficult thing here is, he
mentioned earlier that he is going to eventually remove all epochs
[03:34:32] but it didn't happen yet
[03:34:52] freshrpms and fedora cannot co-exist
[03:34:55] in the long run
[03:35:06] Warren: then the question is, is
he going to remove the epochs before the buid server goes live?
[03:35:25] I don't know
[03:35:27] Warren, I agree entirely, they cannot
easily co-exist and have any overlap
[03:35:28] if yes then it becomes a problem
of coordination
[03:35:38] gleblanc: it is even worse than that
[03:35:46] if not then it becomes a problem
[03:35:54] gleblanc: Due to his release names, if we
have the same version name, you have the two way upgrade problem
_________________________________________________________________
* Previous message: [16][Fedora-devel] Re: Fedora Package Wish List
* Next message: [17][Fedora-devel] Fedora Package Naming Guidelines
(Draft #3)
* Messages sorted by: [18][ date ] [19][ thread ] [20][ subject ]
[21][ author ]
References
1. http://videl.ics.hawaii.edu/pipermail/fedora-devel/2003-February/index.html
2. http://videl.ics.hawaii.edu/pipermail/fedora-devel/2003-February/000243.html
3. http://videl.ics.hawaii.edu/pipermail/fedora-devel/2003-February/000213.html
4. mailto:fedora-devel%40videl.ics.hawaii.edu
5. http://videl.ics.hawaii.edu/pipermail/fedora-devel/2003-February/000243.html
6. http://videl.ics.hawaii.edu/pipermail/fedora-devel/2003-February/000213.html
7. http://videl.ics.hawaii.edu/pipermail/fedora-devel/2003-February/date.html#244
8. http://videl.ics.hawaii.edu/pipermail/fedora-devel/2003-February/thread.html#244
9. http://videl.ics.hawaii.edu/pipermail/fedora-devel/2003-February/subject.html#244
10. http://videl.ics.hawaii.edu/pipermail/fedora-devel/2003-February/author.html#244
11. mailto:rpm-list@freshrpms.net
12. http://lists.debian.org/debian-devel/2003/debian-devel-200302/msg00736.html
13. http://lists.debian.org/debian-devel/2003/debian-devel-200302/msg00774.html
14. http://lists.debian.org/debian-devel/2003/debian-devel-200302/msg00789.html
15. http://www.owlriver.com/projects/SLUG/
16. http://videl.ics.hawaii.edu/pipermail/fedora-devel/2003-February/000243.html
17. http://videl.ics.hawaii.edu/pipermail/fedora-devel/2003-February/000213.html
18. http://videl.ics.hawaii.edu/pipermail/fedora-devel/2003-February/date.html#244
19. http://videl.ics.hawaii.edu/pipermail/fedora-devel/2003-February/thread.html#244
20. http://videl.ics.hawaii.edu/pipermail/fedora-devel/2003-February/subject.html#244
21. http://videl.ics.hawaii.edu/pipermail/fedora-devel/2003-February/author.html#244