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

 
 
LinkBack Thread Tools
 
Old 02-17-2009, 05:47 AM
Luk Claes
 
Default Post-Lenny discussion on packages with external (potentially non-free) dependencies

Michael S. Gilbert wrote:

> Summary of the problem: Some packages such as foo2zjs, pciutils,
> ttf-mathematica4.1, etc. have components that download files external
> to the Debian archives (from the internet) at runtime, which is
> problematic in many ways.

If possible, the to be downloaded data should be packaged so most of
below problems are solved or mitigated.

> 1. Provides a potential avenue for introducing malicious software onto
> users' systems

Well, input validation is very common for web applications. The
validation can consist of verifying the structure or a checksum etc, but
should always be present IMHO.

> 2. Components of the package may stop working in the midst of a
> stable release's lifetime
>
> Argument: Since the location and composition of external files is
> outside of the package maintainer's control, upstream changes can break
> stable scripts.

If possible the package should self adjust to or give the user the
opportunity to influence the location of the external files. Sometimes
it's possible to fallback to a location under the maintainer's control
so the package will continure to work.

If that's not possible, the package should not be included in the stable
release itself IMHO and people are encouraged to discuss the inclusion
in the volatile archive.

> 3. Allows packages in main to depend on external files, violating the
> spirit of the Debian Policy

Like Don explained it could be a convenience script, in that case the
package is not really depending on the external files.

Not packaging external files because it would be too small packages is
not an argument IMHO as it could get included in the package itself in
that case or similar things can be packaged together.

> 4. Parts of the package work as intended only under certain
> circumstances
>
> Argument: Since an internet connection is not guaranteed on the user's
> end, the program does not work as intended when the net is either down
> or unavailable. For example, a user with a printer supported by
> foo2zjs's getweb will not be able to make that printer work if they use
> their machine as a standalone. As much of Debian as possible should be
> fully functional even when standalone. Hence, non-free components (if
> they are to be supported at all) should be included in the non-free
> archive instead of fetched externally.
>
> Rebuttal: None yet.

Well yes, depending on an internet connection should be avoided if possible.

> 5. Allows packages in main to potentially depend on non-free files

If the functioning of the package needs the non-free files, it is not
just a convenience script, and I would put the package in contrib.

Cheers

Luk


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 02-17-2009, 08:15 AM
"Giacomo A. Catenazzi"
 
Default Post-Lenny discussion on packages with external (potentially non-free) dependencies

Michael S. Gilbert wrote:

Dear All,

First of all, congratulations on getting the Lenny release out the
door! I understand that it was a lot of work, and you're probably
looking forward to at least somewhat of a break. So I don't want
to treat this problem with too much urgency (yet), but I would like to
get a dialog going as people find the time to weigh in with their
opinions.


(...) [removing the long mail: too long to quote, too interesting
to extract the best parts.

my case (microcode.ctl):
- the package is in contrib and not in main
- I download only ascii file, converted to binary and feed
to the kernel device only at loading time, so difficult to exploit
- intel microcode is crypted, thus it is difficult to modify
- user had the possibility to download the microcode manually
and to put in the right position
- no microcode no worrying: the computer work normally
(but on new processors on a new family, with usually needs
a lot of updates, but usually these are developer machine, not
production machines.)
- but with problem on distribution format. Intel (I think wrongly)
changed the format (instead of a compressed file, it did a
compressed tar of the file) thus breaking debian and ubuntu.
- but with last versions, Intel changed (again) the microcode license
(I think because of us [or better because of Ubuntu :'( ] ),
so now microcode is distributed by a non-free package.
The script to download microcode from intel side is only
a convenience script.
I could live (and I think also our user) fine, if I remove the
script from postinst (BTW it was called after asking confirmation
via debconf)
- the microcode now could be installed also by the kernel firmware
infrastructure, so I still had to decide a proper procedure with
Intel and RedHat, and to debian firmware. After this the package
will be a legacy only package.


BTW: I still have the non-free.* domains, if Debian need it.

ciao
cate


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 02-22-2009, 02:29 PM
Luk Claes
 
Default Post-Lenny discussion on packages with external (potentially non-free) dependencies

Josselin Mouette wrote:
> Le mardi 17 fĂ©vrier 2009 Ă* 00:31 -0500, Michael S. Gilbert a Ă©crit :
>> 2. Components of the package may stop working in the midst of a
>> stable release's lifetime
>
> This is a problem that affects much more than this kind of packages. All
> packages relying on an external service are affected. For example, it’s
> hard to expect the totem youtube plugin to keep working for the lifetime
> of the etch release.
>
> If we find a solution to this kind of issues, it should apply to all
> packages in this situation.

Indeed, it's something to be discussed considering inclusion or not of
the package in the main, volatile and backports archives. Maybe it's one
of the discussions to put on the wiki page [1]?

Cheers

Luk

[1] http://wiki.debian.org/DiscussionsAfterLenny


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 

Thread Tools




All times are GMT. The time now is 09:43 PM.

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