my thoughts on package management
by david paeme
Hello,
this is my first post on the redhat-dev mailing list, but I'd like to
share some ideas with you people, that might increase the ease of use
for redhat.
please be aware that this is my opinion, and I'm sure that your opinion
or comments will be appreciated!
(and don't shoot me for some stuff, because I haven't read the complete
docs on the site yet ;-)
here we go:
RedHat has made an excellent decision when using the RedHat-network
stuff... the update checker, so no comments there.
But on the other side, people that aren't used to Linux (in general)
will have problems installing/adding software. The rpm system is nice,
but If you can't find an rpm that's compiled for your exact system,
you're in trouble. And let's not forget the infamous dependancy hell!
So why not use apt-like system (I'll call it apt from now on)?
I know that there are probably a lot of arguments as why not to use it,
but consider the advantages:
It might be possible to have an installation version that is only 1 cd.
This can then only contain the basic system, window manager, and some
basic applications (if a system like knoppix can do this...). It is then
possible to use apt to get people to install applications, without
having to download 3 cd's in a row. (even with a graphical frontend like
Synaptic)
Also good about this, is that it can reduce debate about which packages
need to be included with the distribution itself, and which not. And
people will have 'official' redhat packages, for those that don't trust
third-party stuff.
What do you guys think?
bye,
David.
20 years, 9 months
On the inclusion of cyrus-imapd
by Paul Iadonisi
After the recent discussion of possibly including cyrus-imapd in this
upcoming release, I figured I'd check to see how things work on severn.
I've been running 2.1.12 on Red Hat 9 since Red Hat Linux 9's release
and figured I'd check for updates. I had the 2.1.13 src rpm from Simon
Matter, but hadn't upgraded and found that 2.1.14 has since been
released. Also, I had experimented with the 2.2.0 alpha a while ago
because I'm interested in the new virtual hosting feature. I found that
this has been updated, too, and Simon Matter has and rpm for it
(2.2.1-2).
So I gave an 'rpmbuild --rebuild' on severn and it failed. It builds
fine on Red Hat 9. Upon initial investigation, it appears that a
/var/tmp/cyrus-imapd-2.2.1-root/var/tmp/cyrus-imapd-2.2.1-root/
directory is getting created and much of the install is putting files in
there instead of just /var/tmp/cyrus-imapd-2.2.1-root. I'm about to dig
into the rpm spec file and possibly the default rpm config differences
between RHL 9 and servern, but wanted to ask here if anyone else has run
into this or knew of any changes in the default rpm config that would
cause this. It could be a simple fix to the spec file, but I'm just
wondering what changed, given that it works on RHL 9.
--
-Paul Iadonisi
Senior System Administrator
Red Hat Certified Engineer / Local Linux Lobbyist
Ever see a penguin fly? -- Try Linux.
GPL all the way: Sell services, don't lease secrets
20 years, 9 months
Inclusion of cyrus-imapd and mimedefang
by Stephen Smoogen
We are in the process of moving our IMAP servers from the redhat default
to the cyrus-imapd as we have found them to be a bit more robust than
WU. Currently we are using a set based off of Ivoca Linux but would like
a 'blessed' version included into RHL at some point.
Other than an RFE is there anything we can do to push this through?
--
Stephen John Smoogen smoogen(a)lanl.gov
Los Alamos National Labrador CCN-5 Sched 5/40 PH: 4-0645 (note new #)
Ta-03 SM-1498 MailStop B255 DP 10S Los Alamos, NM 87545
-- So shines a good deed in a weary world. = Willy Wonka --
20 years, 9 months
Re: Inclusion of cyrus-imapd and mimedefang
by Angles Puglisi
*sometimes* courier-imap sticks to the RFC (which is their
right) so much that known broken mailers like
some mail from AOL, which do not end with the correct
trailing CRLF, return NO message. Usually the text
version in MIME Part 1 is fine but if the HTML
in MIME part 2 does not end correctly, you get nothing.
There are other broken mailers. Maybe a 5% thing.
Dax Kelson (dax(a)gurulabs.com) wrote:
>
>On Wed, 2003-07-23 at 13:35, Bill Nottingham wrote:
>
>> We're actually considering for this upcoming release:
>>
>> - adding in cyrus-imap
>> - taking out uw-imap
>>
>> Opinions?
>
>Uh, yeah. :)
>
>The mbox sucks, Maildir rules and uw-imap is a dog.
>
>Anything that supports Maildir is plus in my book. I've always been a
>fan of courier-imap.
>
>Dax
>
>
>
>
>http://www.redhat.com/mailman/listinfo/rhl-devel-list
--
That's "angle" as in geometry.
20 years, 9 months
Re: BitTorrent enabled downloads & updates
by Panu Matilainen
Quoting Elijah P Newren <newren(a)math.utah.edu>:
> Sorry for the cross-posting. I originally posted this idea on #fedora
> at irc.freenode.net and Anvil suggested I email these two lists with
> this idea. My idea was the following:
>
> Have apt-get/yum/up2date/<insert favorite packaging system here>
> use BitTorrent for file downloads.
>
> This would have the following benefits:
> Users would get a much faster download rate (at least, that's
> been my experience for the downloads I've done with
> BitTorrent).
> It would alleviate the 'which mirror should I use' problem.
> Anyone could easily become a mirror.
> It should keep any specific mirror from getting overloaded.
>
> I figured this made so much sense that someone else has already thought
> of it and perhaps already implemented it. Anyone know if that's the
> case? If not, does that idea sound interesting to others?
See http://distro2.conectiva.com.br/pipermail/apt-rpm/2003-June/001808.html.
Haven't tried it though..
--
- Panu -
20 years, 9 months
Re: BitTorrent enabled downloads & updates
by Panu Matilainen
Quoting Elijah P Newren <newren(a)math.utah.edu>:
> Sorry for the cross-posting. I originally posted this idea on #fedora
> at irc.freenode.net and Anvil suggested I email these two lists with
> this idea. My idea was the following:
>
> Have apt-get/yum/up2date/<insert favorite packaging system here>
> use BitTorrent for file downloads.
>
> This would have the following benefits:
> Users would get a much faster download rate (at least, that's
> been my experience for the downloads I've done with
> BitTorrent).
> It would alleviate the 'which mirror should I use' problem.
> Anyone could easily become a mirror.
> It should keep any specific mirror from getting overloaded.
>
> I figured this made so much sense that someone else has already thought
> of it and perhaps already implemented it. Anyone know if that's the
> case? If not, does that idea sound interesting to others?
See http://distro2.conectiva.com.br/pipermail/apt-rpm/2003-June/001808.html.
Haven't tried it though...
>
>
> Elijah
> _______________________________________________
> Fedora-devel mailing list
> Fedora-devel(a)fedora.us
> http://www.fedora.us/mailman/listinfo/fedora-devel
>
--
- Panu -
20 years, 9 months
Re: BitTorrent enabled downloads & updates
by Panu Matilainen
Quoting Elijah P Newren <newren(a)math.utah.edu>:
> Sorry for the cross-posting. I originally posted this idea on #fedora
> at irc.freenode.net and Anvil suggested I email these two lists with
> this idea. My idea was the following:
>
> Have apt-get/yum/up2date/<insert favorite packaging system here>
> use BitTorrent for file downloads.
>
> This would have the following benefits:
> Users would get a much faster download rate (at least, that's
> been my experience for the downloads I've done with
> BitTorrent).
> It would alleviate the 'which mirror should I use' problem.
> Anyone could easily become a mirror.
> It should keep any specific mirror from getting overloaded.
>
> I figured this made so much sense that someone else has already thought
> of it and perhaps already implemented it. Anyone know if that's the
> case? If not, does that idea sound interesting to others?
See http://distro2.conectiva.com.br/pipermail/apt-rpm/2003-June/001808.html.
Haven't tried "circle" though.
>
>
> Elijah
> _______________________________________________
> Fedora-devel mailing list
> Fedora-devel(a)fedora.us
> http://www.fedora.us/mailman/listinfo/fedora-devel
>
--
- Panu -
20 years, 9 months
Re: my thoughts on package management
by Havoc Pennington
On Thu, Jul 24, 2003 at 04:31:39PM -0400, Paul Iadonisi wrote:
> Havoc Pennington has made exactly this point at least a few times in
> various forums when people argue about user interfaces. What many
> people on these mailing lists forget is that the user base of a distribution
> is typically two or three orders of magnitude larger than the mailing
> list participation. The kind of people participating in the mailing lists
> are typically not representative of the entire user base (rhl-list may be an
> exception, I don't know).
Another kind of bias is that people only complain about what they
don't like, very few people ever praise what they do like.
That is if you have 100 people who like it how it is and 10 people who
don't, you'll get 10 complaints and 1 praise, which looks like a 10-1
vote for changing it.
You find out the reality when you change it and suddenly get 100
complaints and 0 praise. ;-)
Anyway, this is why you really have to understand the goals and
rationale for why the software is how it is, otherwise you sort of
just keep changing it back and forth in response to complaints.
> I like choice too, which is why I typically replace metacity with sawfish
> on my systems (sorry, Havoc, I know I keep jabbing you with that. hehe ;-)),
I don't mind one bit, though. ;-) I understand there are tradeoffs and
everyone will use what they like, and that's all good.
Havoc
20 years, 9 months
Re: my thoughts on package management
by Jeremy Portzer
On Thu, 2003-07-24 at 16:12, Paul Iadonisi wrote:
> Although I don't think anyone at Red Hat is going to tell you 'shut up,'
> I don't think that rpm/up2date has ever included the promise of being able
> to account for custom changes users have made. Read the section in the release
> notes of the past several releases on the Ximian desktop for evidence of this.
> Take a look at other vendors, for instance. Ever decide that Solaris 'ls'
> command was too braindead for your taste and replace it with the GNU coreutils
> (yes, I know, an unlikely scenario, but bear with me)? Then try to apply a
> patch from Sun that happens to include the ls binary. Your stuck there, too.
Actually, I used to do that regularly when I was responisble for some
Solaris boxes. I just installed the GNU tools in another location --
say /usr/gnu/bin -- and modified my $PATH to look for them before the
native OS versions. Very simple, and doesn't conflick with the Sun
patches at all. However, that's not as easy with something as complex
as Ximian Desktop, and obviously you have to be responsible for keep
your versions up to date. (sunfreeware.com makes that easier)
> My examples aren't exactly perfect, but my point is that given that the
> resources that Red Hat has, (even with the new future addition of outside
> package maintainers), it's very like not going to be enough to meet the needs
> you describe. Some packages have an inordinate number of ways they can be
> built and Red Hat taking on the responsibility of providing upgrade
> paths for all possibly contingencies is probably corporate suicide.
> A source based distribution is, in some cases, exactly what some people need.
Agreed.
I find these conversations on mailing lists a bit frustrating, because
some people will join in and be very vocal about their specific needs,
which may or may not match what 99% of people use. [not focusing this
at Rober specifically, but in general]. How can we, as possible
contributors to the new Red Hat Linux Project, really get a feel for
what the majority of people want? If only the most vocal come to the
mailing lists, or bugzilla, and make their specific needs know, won't
the silent majority be ignored?
--Jeremy
--
/---------------------------------------------------------------------\
| Jeremy Portzer jeremyp(a)pobox.com trilug.org/~jeremy |
| GPG Fingerprint: 712D 77C7 AB2D 2130 989F E135 6F9F F7BC CC1A 7B92 |
\---------------------------------------------------------------------/
20 years, 9 months
Re: my thoughts on package management
by Jeff Johnson
On Thu, Jul 24, 2003 at 04:12:47PM -0400, Paul Iadonisi wrote:
> On Thu, Jul 24, 2003 at 12:07:39AM -0700, Robert LeBlanc wrote:
>
> [snip]
>
> > I'd like to see a more flexible, versatile approach in any
> > "next-generation" RPM/up2date system, and that's what I'm trying to
> > petition for here. Either a Gentoo-like system that can build applications
> > at install time with user-specified options selected, or at least a means
> > of making the option set visible somewhere within the RPM package, so that
> > when updates are downloaded for those packages the up2date process can
> > search for RPMs built with those particular options. I'm sure there are
> > other solutions that would work as well, given a little time and thought,
> > and a willingness to make changes on this level.
>
> To be frank, I think you really are looking for something more like Gentoo.
> Red Hat is doing its best to handle the 95% - 99% use cases. In my own,
> somewhat biased opinion, I think they do a pretty good job of it. But I
> have run into similar things that you have (applying a mysql patch to
> sendmail and building the cyrus-sasl-mysql module as two examples).
>
There's room for moving closer to a Gentoo approach, but typically the
problem revolves around
a) how to set up a build system
b) how to use rpmbuild to package
Both a) and b) are simple with a rpm package management domain, but
entirely outside of the scope of rpm if/when you want to do your own
thing differently.
> > If, on the other hand, you really feel this is a problem that doesn't
> > exist, or one that would require more work to fix than you're willing to
> > invest, just say so and I'll shut up. I'm only trying to help make the
> > RPM/up2date system live up to its initial promise, and if indeed you
> > believe it's as good as it can get I'll drop the matter and go back to my
> > tarballs, or to Gentoo.
>
> Although I don't think anyone at Red Hat is going to tell you 'shut up,'
> I don't think that rpm/up2date has ever included the promise of being able
> to account for custom changes users have made. Read the section in the release
> notes of the past several releases on the Ximian desktop for evidence of this.
Up2date (and rpm underneath it) depends solely on the concepts (N == name,
E == epoch, V== version, etc)
a) package N to choose what to compare with.
b) "newer" as in EVR version comparison.
c) whether to use rpm for software mgmt at all.
Both a) and b) are quite mangeable for customization. b) in particular
pretty much means that you have to choose a release that is newer than
the RHL starting point, but "older" than any release number that rpm is
likely to choose. This preserves the ability to upgrade, see "vepoch"
in the package building guidelines at http://fedora.us for a perfectly
reasonable rule based release naming scheme that has the right properties.
The other piece that might be needed is to configure up2date to
Never remove or upgrade this package.
(i.e. because it's customised). Already there, breaks on paradigm shifts,
but Red Hat does it's best to avoid aurprises. Sure there's surprises, NPTL
comes instantly to mind, but there are as few as is humanly possible.
c) is insoluble in general, way outside the scope of rpm package management
as currently implemented.
73 de Jeff
--
Jeff Johnson ARS N3NPQ
jbj(a)redhat.com (jbj(a)jbj.org)
Chapel Hill, NC
20 years, 9 months
