Re: Steam for Linux? No thanks.
On Fri, Feb 22, 2013 at 11:19:36AM +0200, Boris Pek wrote:
> Hi,
>
> > (given that's it's already waiting in the NEW queue [4])
> > ...
> > [4] http://ftp-master.debian.org/new/steam_1.0.0.28-1.html
>
> Vincent, thank you for a link. I was not aware of this.
>
> Michael, I completely don't satisfied with a quality of a package which is
> waiting now in NEW queue. Sorry if it annoying you, but I just want to help
> to improve this package to make it more conforming to Debian standards.
>
> Some notes after quick review:
> 0) I think that ITP #440607 is not suitable for this package and ITP #701157
> should be used instead.o
I'm guessing the things listed below are your reasoning for this. In general
there should not be more than one ITP for the same piece of software. I see
#440607 was filed many years before #701157, but it's not necessarily clear
that it is the same software. What is clear is that it's in the same ball-
park, so it's a shame there was not more discussion/collaboration before
#701157 was filed.
What is in the NEW queue is definitely not what was initially described in
#440607. But, the upload, once/if past ftp masters, effectively closes both
bugs: steam will be in Debian and there is no need for ITPs after that.
My impression is you rushed to file #701157, have a sense of ownership over
packaging steam in Debian (team membership notwithstanding) and are somewhat
sore that someone beat you to it.
> 1) ./usr/lib/steam/bootstraplinux_ubuntu12_32.tar.xz
> This is really bad idea. I believe that this binary file should not be
> included in the package but should be downloaded during package installing > I am not sure that debian/postinst from flashplugin-nonfree is good
> example but something similar could be used.
Why? Including it in the package means that the package installed-size field
is accurate and reflects the space that the package takes up; downloading and
installing code in postinst means transient network errors during installation
can cause the package to be in an undefined state; generally it's done by root
which opens up potential vulnerabilities unless the download is via HTTPS and
strict cert checking is on etc.; supporting mirrors, retries, multiple threads,
handling the correct amount of feedback to offer the user (interactive mode?
Is it an interactive package installation?) - basically doing it that way
should always be a last resort.
> 3) libc6 (>=2.15)
> Sorry, what? Program do not work with this version of libc6. In my personal
> packages I use a patch for ./usr/games/steam which adds
> /usr/lib/steam/libc6/ into LD_LIBRARY_PATH.
> .
> The contents of /usr/lib/steam/libc6/ should be downloaded during package
> installing if libc6 < 2.16. I use libc6 (2.17-0experimental2) from Debian
> experimental for this goal.
Completely disagree. Depend on the correct libc6 package and require people
to install it from experimental. A private libc6 copy is fine for personal
packages but totally unsuitable for something in the archive. Again downloading
stuff in postinst is a measure of last resort.
> 4) Conflicts: steam-lib.
> Sorry, why? See: http://packages.debian.org/search?keywords=steam-lib
I'm not sure if you are answering your own question or not, but I guess its
because steam-lib puts things in /usr/lib/steam too. A conflicts may not be
strictly necessary since there are no overlapping files.
> 5) Please create a git repo with only ./debian/ directory. It will simplify
> the maintaining of the package.
I'd love to see this maintained in a VCS, preferably git, (surely all games
team packages should be in a VCS), but I thoroughly disagree about a detached
./debian. Detached debian directories in VCS are a nightmare IMHO. I was very
glad to leave them behind when I moved my packages from SVN to git some time
ago. It is sometimes necessary if the source package is prohibitively large,
but otherwise, please, no!
Reply to: