[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Steam for Linux? No thanks.



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

Your impression is wrong.

I prepared my personal package for Steam when it was in beta stage. Few users
tested it successfully. And this package I was intended to maintain under
umbrella of Debian Games Team. That's why I prepared the template for
ITP #701157, closed unrelated bug #440607 [1] and began [2] this thread in
<debian-devel-games> mailing list to get more opinions.

It was unexpectedly for me to see this package in NEW queue. But since the
package is not in archive yet, it can be improved.

Also I don't see preliminary discussion in <debian-legal> mailing list which
was proposed by Paul Wise [3].

[1] http://bugs.debian.org/440607#28
[2] http://lists.debian.org/debian-devel-games/2013/02/msg00028.html
[3] http://lists.debian.org/debian-devel-games/2013/02/msg00033.html

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

Just because it will be a pain to monitor and regularly update the list of
licenses and copyright holders of libraries included into this embedded
tarball. Even upstream do not do this carefully: they just added a bundle of
commonly used licenses. But we cannot do the same in our debian/copyright.

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

Yes, I am agree here.

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

Have you opened the link? There is no steam-lib in Debian.

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

Sorry, but I believe that such "source files" for packages in non-free should
not be kept on Debian Alioth. Because I see the conflict with DMUP, which I
was signed. But maybe I am wrong here.

Best regards,
Boris


Reply to: