FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 05-01-2008, 02:58 PM
Les Mikesell
 
Default Multilib Middle-Ground

Rex Dieter wrote:



No, it doesn't, which is exactly my point... the harder, or more
explicitly, anything must be done to distribute proprietary software...
the more likely it will be done with a shell script which spews files
all over the place.

You don't get proprietary software to work nicely with package
management systems by making it even harder.
Would you mind leaving the 'p' word out of this discussion?


Maybe, maybe not. 'p' to some means anything != free/oss. And if it's
free/oss, what better place than to be *in* fedora.



I don't understand why anyone would have any interest in an operating
system that can only run its own programs. Aside from the obvious
limitations since no one could seriously expect it to include all
possibilities, it has to be an enormous waste of effort to build the
specialized versions and package them in repositories that few people
will use anyway.


--
Les Mikesell
lesmikesell@gmail.com

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 05-01-2008, 03:02 PM
"Bill Crawford"
 
Default Multilib Middle-Ground

On 01/05/2008, Les Mikesell <lesmikesell@gmail.com> wrote:

> Would you mind leaving the 'p' word out of this discussion? The same
> principle applies to all software that isn't recompiled and repackaged
> between every version, including the user's own and other programs where
> source is available but you don't want to have to rebuild (if we did want to
> recompile every week we'd be running gentoo...). Pretending this is
> specific to proprietary software puts the wrong spin on the conversation
> here. The only difference being proprietary makes in this case is that
> someone else needs to do this work and probably maintain specific versions
> separately for each fedora version instead of every using doing that
> himself.

Except that ... where RPM packages are concerned, this usually happens
with proprietary software. I've never built my own RPM packages that
way, nor do most sane people.

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 05-01-2008, 03:12 PM
Les Mikesell
 
Default Multilib Middle-Ground

seth vidal wrote:

On Thu, 2008-05-01 at 08:54 -0500, Les Mikesell wrote:

seth vidal wrote:

On Thu, 2008-05-01 at 08:16 -0500, Les Mikesell wrote:
Stripping of pathname-based and package-name based dependencies I can
understand, but not the library deps.

Are they the same across all RPM based systems?


The library deps sorta have to be. The deps come out of what the program
is linked to.

as an example run:
ldd /usr/bin/xterm

and look at what it outputs

VMWare-server should probably be split into two packages. Only the
console portion needs the X libs and you can run it on a different
machine, a different OS, or not at all, so it wouldn't make much sense
for a run-time dependency for that part to prevent installation of the
rest of the server.


umm, okay. But no one here controls the vmware package. Hell, speaking
for just me, I don't even CARE about vmware.


I read that as "I don't care about fedora users" that want to run
applications of their choice. Whether that's what you mean or not, I
suspect I'm not the only one who sees that as the end result. If fedora
doesn't care about its users it will simply be irrelevant. If you want a
hint about how others feel, go to the distrowatch.com page and adjust
the time span setting to something recent on the part that shows
interest in various distributions.


--
Les Mikesell
lesmikesell@gmail.com

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 05-01-2008, 03:20 PM
Rahul Sundaram
 
Default Multilib Middle-Ground

Les Mikesell wrote:


umm, okay. But no one here controls the vmware package. Hell, speaking
for just me, I don't even CARE about vmware.


I read that as "I don't care about fedora users" that want to run
applications of their choice. Whether that's what you mean or not, I
suspect I'm not the only one who sees that as the end result.


This is just silly. Any advice on how VMWare should split it's package
is completely offtopic for this list. Nobody here can do anything about
how VMWare chooses to package anything.


If fedora
doesn't care about its users it will simply be irrelevant. If you want a
hint about how others feel, go to the distrowatch.com page and adjust
the time span setting to something recent on the part that shows
interest in various distributions.


Also read the distrowatch FAQ while you are at it that explains how
unimportant it is. If you really believe the top most distribution in
that list is the most popular globally, good luck.


Rahul

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 05-01-2008, 03:23 PM
"Jeff Spaleta"
 
Default Multilib Middle-Ground

On Thu, May 1, 2008 at 3:05 AM, Kostas Georgiou
<k.georgiou@imperial.ac.uk> wrote:
> There are 64bit versions of both so there is no need to install the
> 32bit vesrions.

wrong... mixed networks of 32bit and 64bit machines with network file
mounts. Depending on the licensing terms and licensing server
implementation you can cross the network mount boundary and run the
executables at a cheaper cost than buying a copy for each and every
machine to run locally if all you really need is a license to have a
few simultaneous users at a time.


-jef"I never said this was sane"spaleta

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 05-01-2008, 03:46 PM
Les Mikesell
 
Default Multilib Middle-Ground

Rahul Sundaram wrote:




umm, okay. But no one here controls the vmware package. Hell, speaking
for just me, I don't even CARE about vmware.


I read that as "I don't care about fedora users" that want to run
applications of their choice. Whether that's what you mean or not, I
suspect I'm not the only one who sees that as the end result.


This is just silly. Any advice on how VMWare should split it's package
is completely offtopic for this list. Nobody here can do anything about
how VMWare chooses to package anything.


No, but you can - and do - make it difficult for 3rd party packagers to
build RPMs that work across multiple distros/versions, and for users to
install such packages. It is silly if you don't see that, or that Red
Hat doesn't care if fedora alienates the potential users of RPM and
'system-config-xxx' based distributions.


Also read the distrowatch FAQ while you are at it that explains how
unimportant it is. If you really believe the top most distribution in
that list is the most popular globally, good luck.


Where can I find better metrics?

--
Les Mikesell
lesmikesell@gmail.com

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 05-01-2008, 04:01 PM
Rahul Sundaram
 
Default Multilib Middle-Ground

Les Mikesell wrote:

No, but you can - and do - make it difficult for 3rd party packagers to
build RPMs that work across multiple distros/versions, and for users to
install such packages. It is silly if you don't see that, or that Red
Hat doesn't care if fedora alienates the potential users of RPM and
'system-config-xxx' based distributions.


In this case, the packager is deliberately overriding the dependency
mechanism and not using file based dependencies that make it work across
the distribution. There is really no excuse for not using the tools
provided. VMWare packaging is just broken and suggestions on what they
should do should be taken to them. Not here. Save yourself the trouble.


Also read the distrowatch FAQ while you are at it that explains how
unimportant it is. If you really believe the top most distribution in
that list is the most popular globally, good luck.


Where can I find better metrics?


The usual method used by research firms is to track revenue but that
covers only commercial distributions. RHEL has a known majority market
share there and none of the commercial distributions would ever show up
very high on the distrowatch stats. You can't find any good metrics on
usage of non commercial or free distributions. Fedora uses Smolt. Refer


https://fedoraproject.org/wiki/Statistics

Other distributions are beginning to adopt it. If it gets integrated
better, it could provide more useful metrics for more distributions.
Without invasive techniques likely compulsory registration or automatic
phoning home options, the metrics are bound to be inherently fuzzy
however. Some details on that at


http://fedoraproject.org/wiki/Infrastructure/Metrics

Rahul

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 05-01-2008, 04:02 PM
Kevin Kofler
 
Default Multilib Middle-Ground

Les Mikesell <lesmikesell <at> gmail.com> writes:
> I don't understand why anyone would have any interest in an operating
> system that can only run its own programs. Aside from the obvious
> limitations since no one could seriously expect it to include all
> possibilities, it has to be an enormous waste of effort to build the
> specialized versions and package them in repositories that few people
> will use anyway.

Yet that's exactly what's supposed to happen. Software should be packaged for
Fedora, and rebuilt whenever necessary (which is not necessarily every single
Fedora release, it really depends on what libraries the package uses). Free
Software makes it easy because anyone interested in using the package on Fedora
can package it, not just upstream. It's the proprietary stuff which you aren't
allowed to redistribute and repackage which causes all the problems.

Kevin Kofler

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 05-01-2008, 04:04 PM
Kevin Kofler
 
Default Multilib Middle-Ground

Les Mikesell <lesmikesell <at> gmail.com> writes:
> Would you mind leaving the 'p' word out of this discussion? The same
> principle applies to all software that isn't recompiled and repackaged
> between every version, including the user's own and other programs where
> source is available but you don't want to have to rebuild (if we did
> want to recompile every week we'd be running gentoo...).

Unlike on Gentoo, the user doesn't have to rebuild the packages, only one
packager has to do it and all the users just get the packages from the
packager, be it from the Fedora repository or a third-party repository. The 'p'
word comes into play because proprietary licenses tend to disallow or at least
limit (e.g. no way to rebuild from source because you don't have it)
repackaging, which is the real cause of your problem.

Kevin Kofler

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 05-01-2008, 04:07 PM
Kevin Kofler
 
Default Multilib Middle-Ground

Les Mikesell <lesmikesell <at> gmail.com> writes:
> I read that as "I don't care about fedora users" that want to run
> applications of their choice.

Where have you seen "proprietary software" in the Fedora Objectives? You can't
fault Fedora maintainers for not caring about the applications of your choice
if said applications are proprietary. (That said, I don't speak for the Fedora
project as a whole and there are maintainers like Warren Togami who _do_ care
about making proprietary software work.)

Kevin Kofler

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 

Thread Tools




All times are GMT. The time now is 07:06 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org