devel

devel@lists.fedoraproject.org

40 participants
60738 discussions

my thoughts on package management
by david paeme 26 Jul '03

26 Jul '03

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.

8 11

On the inclusion of cyrus-imapd
by Paul Iadonisi 26 Jul '03

26 Jul '03

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

2 3

Inclusion of cyrus-imapd and mimedefang
by Stephen Smoogen 25 Jul '03

25 Jul '03

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

15 28

Re: Inclusion of cyrus-imapd and mimedefang
by Angles Puglisi 25 Jul '03

25 Jul '03

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

2 1

Re: BitTorrent enabled downloads & updates
by Panu Matilainen 25 Jul '03

25 Jul '03

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 -

1 0

Re: BitTorrent enabled downloads & updates
by Panu Matilainen 25 Jul '03

25 Jul '03

1 0

Re: BitTorrent enabled downloads & updates
by Panu Matilainen 25 Jul '03

25 Jul '03

1 0

Re: my thoughts on package management
by Havoc Pennington 25 Jul '03

25 Jul '03

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

3 2

Re: my thoughts on package management
by Jeremy Portzer 24 Jul '03

24 Jul '03

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 | \---------------------------------------------------------------------/

3 4

Re: my thoughts on package management
by Jeff Johnson 24 Jul '03

24 Jul '03

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

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

devel