Re: Bug#762194: Summary:Re: Bug#762194: Proposal for upgrades to jessie (lendows 1)

[Wolodja Wentland]

On Sat, Nov 29, 2014 at 12:30 -0800, Steve Langasek wrote:
> On Sat, Nov 29, 2014 at 08:14:07PM +0100, Philipp Kern wrote:

> > That's even more unlikely than to add a debconf message (which would be
> > package-owned). Yes, debian-installer is frozen. This would add new
> > udebs, new strings, new everything. We're actually trying to release.
> 
> Debian releases when it's ready.  If large numbers of our users are going to
> have a bad experience with jessie as a result of being switched to systemd,
> then we should take appropriate steps to address that, even if that means
> unfreezing the installer.

Indeed. Jessie should be released once "large numbers of our users [will] no
longer have a bad experience as a result of being switched to systemd [because
all relevant bugs have been fixed]".

As somebody who is active in user support on IRC I dread the jessie release if 
it
means that we will ask people for years to come if they have switched to systemd
after their upgrade and, if not, walk them through the process. So far most
users who had a bad experience with jessie did so because they did *not* switch
and the fact that -shim wasn't ready.

"having a bad experience" should directly translate into bugs that can, and have
to, be fixed before the release. I would welcome a more technical discussion at
this point rather than an emotional one.

Thank you and everybody else for their wonderful work and patience.
-- 
Wolodja 

4096R/CAF14EFC
081C B7CD FF04 2BA9 94EA  36B2 8B7F 7D30 CAF1 4EFC


signature.asc
Description: Digital signature

Re: Debian default desktop environment

[Wolodja Wentland]

On Sat, Apr 05, 2014 at 12:55 +0800, Thomas Goirand wrote:
> On 04/04/2014 09:55 PM, Undefined User wrote:
> > 2014-04-04 10:52 GMT-03:00 Jonathan Dowland  > >:
> > 
> > We go over the same ground over and over. I'm increasingly in favour
> > of *no*
> > default. You must pick one from a list on install. Randomize the list if
> > necessary.
> > Perfect solution.
> > 
> > Debian installer should provide you information about desktop
> > environments and let the user choose it.
> 
> There's only one problem with this approach: somebody has to actually
> implement it... [1]

> [1] And it's been years we're (uselessly) discussing it.

Yes, that is in fact the real problem thank you for stating that so
succinctly.

But wouldn't a nicer menu in the graphical installer with pictures or even
videos and a little text in both versions be worth it? If so then we have at
least an ideal to aspire to (even though nobody implements it) and if not
then we can move on.
-- 
Wolodja 

4096R/CAF14EFC
081C B7CD FF04 2BA9 94EA  36B2 8B7F 7D30 CAF1 4EFC


signature.asc
Description: Digital signature

Re: Debian default desktop environment

[Wolodja Wentland]

On Fri, Apr 04, 2014 at 23:52 +0100, Philip Hands wrote:
> Wolodja Wentland  writes:
> ...
> > One thing I dislike about switching the default DE is that it puts a lot of
> > people active in support in a position in which they might not actually be 
> > as
> > familiar with the DE they will end up supporting most frequently simply by
> > having learned a different "default" one a few generations back. The
> > information flow from experienced users to new users is thereby slightly
> > hampered.
> Yes, because all that Gnome 2 experience is going to be so helpful when the
> poor sod at the other end of the phone is looking at a Gnome 3 desktop.

My knowledge of various GTK applications and their idioms actually helps in a
lot in this, but I simply wanted to make an argument against switching.

> Anyway, to return to the main point, I do wonder why nobody has bothered
> to mention that the reason for the switch was that Gnome no longer fits
> on CD#1.

[...]

> Actually, no, instead why don't you all check out the various threads on
> debian-boot where those arguments have failed to be persuasive, and then
> go and do something productive instead.

Exactly. Lets offer a netinstall with a sensible menu that allows the user =
to choose the DE (s)he wants plus the various CD1, [1GB, 2GB, 3GB] DVD1, BD1,
...  images for the different DEs as has been done for wheezy.

I am personally not convinced that having one unlabelled CD1 and a hard to
change preselection in the netinst is worth discussing the default DE every
other month and a very desirable goal in itself. And offering a choice does
not even prevent the expression of a preference or bias ("choose this if you
are unsure"). Neither do I think that being able to provide a single complete
CD image will be the most important factor in this discussion in the years to
come.

The interface somebody uses to interact with a computer is probably one of the
few examples in which a user actually wants to make a choice as preferences
are inherently subjective and far reaching. All I was arguing for is simply to
provide a little more information to enable the user to make this decision.
-- 
Wolodja 

4096R/CAF14EFC
081C B7CD FF04 2BA9 94EA  36B2 8B7F 7D30 CAF1 4EFC


signature.asc
Description: Digital signature

Re: Debian default desktop environment

[Wolodja Wentland]

On Fri, Apr 04, 2014 at 16:19 +0100, Jonathan Dowland wrote:
> On Fri, Apr 04, 2014 at 04:42:19PM +0200, Stefano Zacchiroli wrote:
> > And can I pass my granddad's phone call on to you when he is stuck
> > choosing among names that are absolutely obscure to him like "GNOME",
> > "Xfce", and "KDE"?
> 
> No, just say pick a random one. Surely they'll all be entirely appropriate
> for your grandad by the time we release jessie ;)

Well, one might argue that DEs are either a suitable pick for our users or
they are not and that the actual choice from the "suitable" set is therefore
irrelevant.

I would like to see the "No default" scheme implemented in such a way that
users are shown a picture of the desktop + one/two sentences about the DEs.
That way the user would be actually more likely to pick a DE (s)he likes.

But then I also believe that Gnome 3 is, like XFCE, a perfectly reasonable
choice and would be perfectly happy with Gnome 3.

One thing I dislike about switching the default DE is that it puts a lot of
people active in support in a position in which they might not actually be as
familiar with the DE they will end up supporting most frequently simply by
having learned a different "default" one a few generations back. The
information flow from experienced users to new users is thereby slightly
hampered.
-- 
Wolodja 

4096R/CAF14EFC
081C B7CD FF04 2BA9 94EA  36B2 8B7F 7D30 CAF1 4EFC


signature.asc
Description: Digital signature

Re: to make debain package

[Wolodja Wentland]

On Wed, Feb 12, 2014 at 14:08 +0100, forum::für::umläute wrote:
> On 2014-02-12 13:47, ANGESH KUMAR wrote:

> > I want to make a debian package of my software so how to that
> > one. I couldn't find any proper document. can you help me by document or
> > link so that i can understand. at last I want to install of my software like
> >  apt-get install safesquid(my software).so waht i have to do.
> 
> there is various information available in the internet, on how to create
> your own packages, see
> 
>   https://www.debian.org/doc/manuals/maint-guide/index.en.html
>   https://wiki.debian.org/IntroDebianPackaging

I'd like to add the excellent collection of information on
http://mentors.debian.net/intro-maintainers to that list.
-- 
Wolodja 

4096R/CAF14EFC
081C B7CD FF04 2BA9 94EA  36B2 8B7F 7D30 CAF1 4EFC


signature.asc
Description: Digital signature

Re: Proposal: switch default desktop to xfce

[Wolodja Wentland]

On Fri, Oct 25, 2013 at 01:41 +0100, Steve McIntyre wrote:
> Wolodja wrote:
> >On Thu, Oct 24, 2013 at 16:40 +0100, Steve McIntyre wrote:
> >> This goes back to during the wheezy release cycle. There was a little
> >> discussion around a change in tasksel [1], but rather too late in the
> >> day for the change to make sense. Now we have rather more time, I
> >> feel. Let's change the default desktop for installation to xfce.

> >Do we really need a default desktop?
> >
> >The only arguments in favour of it I can think of is that it spares users to
> >make an informed decision (which might be overwhelming to a user new to 
> >Linux)
> >and that the content of CD2 depends on it. (thanks ansgar)

> I guess not everybody understands the reasons for Debian choosing a
> default desktop, so I'll explain/expand them here.
> 
> 1. We have several types of installation media (netboot, netinst, DVD,
>BD) 
[…]
>The choice was made years ago to *not* ask users which desktop they
>prefer during the tasksel phase, to reduce the number of questions
>that new users would have to answer.

> 2. Secondly, our first full-size CD image is not big enough to contain
>all the desktops. In fact, it's not big enough any more to contain
>even a fairly minimal Gnome alone, but let's not digress.

Thank you Steve for elaborating and I am happy that you did as it allowed me
to focus to the core of *this* discussion.

1. How will new users pick a desktop environment?

2. How can be produce sets of CDs that are of use to our users and do not
   put too much stress on the mirrors.

No default DE?!
---

I believe that the question which desktop environment to use is one of the
*very few* that a new user actually wants to answer and we should enable users
to do that in a pleasant and informed way. Old users will know already what
they want and they can choose that more easily. I also believe that not
choosing a default DE but treating all "blessed" DEs as equal is a very strong
and positive statement the Debian project could make in the sense of "We do
support all of Gnome, KDE, LXDE, XFCE, ... to the same high standard".

You might disagree with this and I can happily accept that, but I personally
think that this is at least worth considering.

Another aspect I like about this decision is that it would free us from the
need to have this discussion ever again. Once a desktop environment is well
maintained and packaged it could (should?) be offered.

The implementation could be as easy as providing a short description,
screenshots, maybe a short video and a link to the upstream project for each
DE on the website and in the installer. (naturally not all of these are
appropriate everywhere).

But what about CD images?
-

The actual technical argument against not choosing a default DE is based on
the perceived inability (due to size constraints) to offer suitable CD image
sets for each "flavour". Choosing, say, XFCE as opposed to Gnome allows us to
survive yet another release in which we will be able to offer a CD1 for each
of XFCE (default), Gnome, KDE and LXDE and then CD2-CD? tailored for XFCE.

I am not sure if this constraint is one that can be upheld forever and the
problems to create CD1 images that contain all packages to install the
respective "Desktop" task during the last two (?) releases underline this. It
seems as if there will be the need to create, say, CD1+CD2 specific to a
desktop environment and then CD3-CD? for the remaining packages. (or CD1, CD2
+ CD3 specifically) soon and that the choice to offer CD images limits our
options. What's the point of shipping a Gnome CD1 if "it's not big enough any
more to contain even a fairly minimal Gnome"? (likewise for KDE or XFCE and
LXDE in 2, 4, 6, 10 years)
-- 
Wolodja 

4096R/CAF14EFC
081C B7CD FF04 2BA9 94EA  36B2 8B7F 7D30 CAF1 4EFC


signature.asc
Description: Digital signature

Re: Proposal: switch default desktop to xfce

[Wolodja Wentland]

On Fri, Oct 25, 2013 at 09:00 +0100, Lars Wirzenius wrote:
> On Fri, Oct 25, 2013 at 01:47:00AM +0200, Christoph Anton Mitterer wrote:
> > On Fri, 2013-10-25 at 10:40 +1100, Ben Finney wrote:
> > > Why force
> > > *every* user of the installer to make that choice, when many of them
> > > find the very question to be a needless imposition which makes the
> > > installer incrementally less helpful?
> > Sorry, but we're talking about Debian!
> > 
> > I don't think that our target audience are people who cannot make such
> > choices, and even if that would be our desired audience (a feeling which
> > I have with *buntu) than our actual audience is probably another one.

[…]

> I know how to make the choice. I don't fucking want to. Unless I'm
> needing to do a customised install for particular needs, I want Debian
> to provide me with defaults that just work. I don't care if the
> default choices are the ones I would choose myself, I can make changes
> later on.

I think that choosing a desktop environment is one of the *very few* things
that a completely new user would actually be interested in and I believe that
we should strive to make it easy and pleasant for them to do so.

Keep in mind that even choosing a desktop environment on a whim would yield
good results if all "blessed" desktop environments (gnome, kde, xfce and lxde)
are well maintained and users can still switch later on. As a new user I would
welcome a webpage or installer menu that shows one screenshot with a short
description of the environment in question. Experienced users will already
know what they want and can select that right away.
-- 
Wolodja 

4096R/CAF14EFC
081C B7CD FF04 2BA9 94EA  36B2 8B7F 7D30 CAF1 4EFC


signature.asc
Description: Digital signature

Re: Proposal: switch default desktop to xfce

[Wolodja Wentland]

On Thu, Oct 24, 2013 at 16:40 +0100, Steve McIntyre wrote:
> This goes back to during the wheezy release cycle. There was a little
> discussion around a change in tasksel [1], but rather too late in the
> day for the change to make sense. Now we have rather more time, I
> feel. Let's change the default desktop for installation to xfce.

Do we really need a default desktop?

The only arguments in favour of it I can think of is that it spares users to
make an informed decision (which might be overwhelming to a user new to Linux)
and that the content of CD2 depends on it. (thanks ansgar)

I understand that the both of these are good arguments, but maybe solutions
can be found for both. One idea would be the design of better download pages
[0] that provide minimal information about the desktop environments like a
picture of the desktop and a link to the upstream project. Not sure what to do
with the CD sets though.

[0] Work on making the download pages easier to navigate is long overdue anyway
-- 
Wolodja 

4096R/CAF14EFC
081C B7CD FF04 2BA9 94EA  36B2 8B7F 7D30 CAF1 4EFC


signature.asc
Description: Digital signature

Re: Proposal: switch default desktop to xfce

[Wolodja Wentland]

On Thu, Oct 24, 2013 at 18:08 +0200, Ansgar Burchardt wrote:
> On 10/24/2013 17:40, Steve McIntyre wrote:
> > This would mean:
> [...]
> >  * Tweak CD and installer builds:
> >+ change what happens with no desktop selected to use xfce instead
> >  of Gnome (netinst, DVD, BD etc.)
> >+ Add an explicitly-named Gnome CD#1
> >+ Remove the explicitly-named XFCE CD#1
> 
> How about renaming CD1 to "GNOME CD1" and make the minimal installers
> prompt which desktop to install? That is no longer having a default desktop.
> 
> The downside would be that one download link would no longer be enough.

I think that making the choice of the desktop environment explicit by either
prompting the user during the install (netinst) or by offering multiple
explicitly named images will actually make it easier for some users.

We get asked every now and then in #debian about the procedure to install
different desktop environments and it is hard for some users to grasp that
they have to make this choice in the boot menu and not during the software
selection step.

Another thing I like about it is that it renders headlines such as "Debian
switches to XFCE, Gnome3 is officially horrible" pointless as we simply state
that *all* of them are supported.
-- 
Wolodja 

4096R/CAF14EFC
081C B7CD FF04 2BA9 94EA  36B2 8B7F 7D30 CAF1 4EFC


signature.asc
Description: Digital signature

Bug#726025: ITP: tigris -- Stream-based JSON string escaping for Clojure

[Wolodja Wentland]

Package: wnpp
Severity: wishlist
Owner: Wolodja Wentland 

* Package name: tigris
  Version : 0.1.1
  Upstream Author : Matthew Lee Hinman 
* URL : https://github.com/dakrone/tigris
* License : EPL-1.0
  Programming Lang: Clojure, Java
  Description : Stream-based JSON string escaping for Clojure

Tigris is a Clojure library providing a stream for escaping JSON strings as
 they are being read from a different stream. This stream-to-stream string
 encoding allows for easy integration of JSON escaping into your data
 processing pipeline.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20131011102613.15814.2216.reportbug@asasello.local

Bug#720506: ITP: jackson-dataformat-yaml -- fast and powerful JSON library for Java -- YAML dataformat

[Wolodja Wentland]

Package: wnpp
Severity: wishlist
Owner: Wolodja Wentland 

* Package name: jackson-dataformat-yaml
  Version : 2.2.2
  Upstream Author : FasterXML, LLC, Seattle, USA 
* URL : https://github.com/FasterXML/jackson-dataformat-yaml/
* License : Apache-2.0
  Programming Lang: Java
  Description : fast and powerful JSON library for Java -- YAML dataformat
   The Jackson Data Processor is a multi-purpose Java library for processing
   JSON. Jackson aims to be the best possible combination of fast, correct,
   lightweight, and ergonomic for developers. It offers three alternative 
methods
   for processing JSON:
   .
* Streaming API inspired by StAX
* Tree Model
* Data Binding converts JSON to and from POJOs
   .
   In addition to the core library, there are numerous extension that provide
   additional functionality such as additional data formats beyond JSON,
   additional data types or JVM languages.
   .
   This package contains an extension for reading and writing YAML-encoded
   data.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20130822173923.23544.95263.reportbug@asasello.local

Bug#720505: ITP: jackson-dataformat-smile -- fast and powerful JSON library for Java -- Smile dataformat

[Wolodja Wentland]

Package: wnpp
Severity: wishlist
Owner: Wolodja Wentland 

* Package name: jackson-dataformat-smile
  Version : 2.2.2
  Upstream Author : FasterXML, LLC, Seattle, USA 
* URL : https://github.com/FasterXML/jackson-dataformat-smile/
* License : Apache-2.0
  Programming Lang: Java
  Description : fast and powerful JSON library for Java -- Smile dataformat
   The Jackson Data Processor is a multi-purpose Java library for processing
   JSON. Jackson aims to be the best possible combination of fast, correct,
   lightweight, and ergonomic for developers. It offers three alternative 
methods
   for processing JSON:
   .
* Streaming API inspired by StAX
* Tree Model
* Data Binding converts JSON to and from POJOs
   .
   In addition to the core library, there are numerous extension that provide
   additional functionality such as additional data formats beyond JSON,
   additional data types or JVM languages.
   .
   This package contains an extension for reading and writing Smile-("binary
   JSON")-encoded data.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20130822173626.22534.35647.reportbug@asasello.local

Bug#720504: ITP: jackson-databind -- fast and powerful JSON library for Java -- data binding

[Wolodja Wentland]

Package: wnpp
Severity: wishlist
Owner: Wolodja Wentland 

* Package name: jackson-databind
  Version : 2.2.2
  Upstream Author : FasterXML, LLC, Seattle, USA 
* URL : https://github.com/FasterXML/jackson-databind/
* License : Apache-2.0
  Programming Lang: Java
  Description : fast and powerful JSON library for Java -- data binding
   The Jackson Data Processor is a multi-purpose Java library for processing
   JSON. Jackson aims to be the best possible combination of fast, correct,
   lightweight, and ergonomic for developers. It offers three alternative 
methods
   for processing JSON:
   .
* Streaming API inspired by StAX
* Tree Model
* Data Binding converts JSON to and from POJOs
   .
   In addition to the core library, there are numerous extension that provide
   additional functionality such as additional data formats beyond JSON,
   additional data types or JVM languages.
   .
   This package contains general purpose data-binding functionality for data
   formats other than JSON.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20130822173052.21481.17561.reportbug@asasello.local

Bug#720503: ITP: jackson-annotations -- fast and powerful JSON library for Java -- annotations

[Wolodja Wentland]

Package: wnpp
Severity: wishlist
Owner: Wolodja Wentland 

* Package name: jackson-annotations
  Version : 2.2.2
  Upstream Author : FasterXML, LLC, Seattle, USA 
* URL : https://github.com/FasterXML/jackson-annotations
* License : Apache-2.0
  Programming Lang: Java
  Description : fast and powerful JSON library for Java -- annotations
   The Jackson Data Processor is a multi-purpose Java library for processing
   JSON. Jackson aims to be the best possible combination of fast, correct,
   lightweight, and ergonomic for developers. It offers three alternative 
methods
   for processing JSON:
   .
* Streaming API inspired by StAX
* Tree Model
* Data Binding converts JSON to and from POJOs
   .
   In addition to the core library, there are numerous extension that provide
   additional functionality such as additional data formats beyond JSON,
   additional data types or JVM languages.
   .
   This package contains general purpose annotations for value and handler 
types.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20130822172652.20618.57537.reportbug@asasello.local

Re: Bug#719323: ITP: jackson-core -- fast and powerful JSON library for Java

[Wolodja Wentland]

On Sun, Aug 11, 2013 at 12:52 +0100, Stephen Nelson wrote:
> On 11 Aug 2013 00:32, "Wolodja Wentland"  wrote:

>> It is not, but thank you for catching this and reviewing WNPP bugs! :)
>> libjackson-json-java is version 1.* of the JSON processoe by FasterXML
>> while I plan to package version 2.* which has been split into a number of
>> packages and should be packaged separately. In the light of this I will try
>> to make it more obvious that this is, in fact, Jackson2.

> Thanks for packaging the latest version. I think it would be better to be
> consistent on the naming according to the Debian Java standards [1] and name 
> it
> something like libjackson2-core-java.

> [1] http://www.debian.org/doc/packaging-manuals/java-policy/x114.html

I am not sure if it makes sense to adapt this naming scheme for source
packages and I would personally very much prefer to use the name used by
upstream. There are also quite a number of packages maintained by pkg-java
that simply use the name used by upstream.

The binary packages will, naturally, follow the naming conventions of pkg-java
and this particular source package builds two binary packages, namely:

* libjackson2-core-java
* libjackson2-core-java-doc

Please let me know if that is in line with your expectations and have a nice
day!
-- 
Wolodja 

4096R/CAF14EFC
081C B7CD FF04 2BA9 94EA  36B2 8B7F 7D30 CAF1 4EFC


signature.asc
Description: Digital signature

Re: Bug#719323: ITP: jackson-core -- fast and powerful JSON library for Java

[Wolodja Wentland]

On Sun, Aug 11, 2013 at 00:09 +0100, Stephen Nelson wrote:
> On 10 Aug 2013, at 19:17, Wolodja Wentland  wrote:
> 
> 
> Package: wnpp
> Severity: wishlist
>     Owner: Wolodja Wentland 
>
> * Package name: jackson-core
>  Version : 2.2.2
>  Upstream Author : FasterXML, LLC, Seattle, USA 
> * URL : http://wiki.fasterxml.com/JacksonHome
> * License : Apache-2.0
>  Programming Lang: Java
>  Description : fast and powerful JSON library for Java

> I believe this is already packaged as libjackson-json-java. You could assist 
> by
> packaging the latest version.

It is not, but thank you for catching this and reviewing WNPP bugs! :)

libjackson-json-java is version 1.* of the JSON processoe by FasterXML while I
plan to package version 2.* which has been split into a number of packages and
should be packaged separately. In the light of this I will try to make it more
obvious that this is, in fact, Jackson2.

Have a good day!
-- 
Wolodja 

4096R/CAF14EFC
081C B7CD FF04 2BA9 94EA  36B2 8B7F 7D30 CAF1 4EFC


signature.asc
Description: Digital signature

Bug#719323: ITP: jackson-core -- fast and powerful JSON library for Java

[Wolodja Wentland]

Package: wnpp
Severity: wishlist
Owner: Wolodja Wentland 

* Package name: jackson-core
  Version : 2.2.2
  Upstream Author : FasterXML, LLC, Seattle, USA 
* URL : http://wiki.fasterxml.com/JacksonHome
* License : Apache-2.0
  Programming Lang: Java
  Description : fast and powerful JSON library for Java

 Jackson is a fast Java-based is a multi-purpose Java library for processing
 JSON. Jackson aims to be the best possible combination of fast, correct,
 lightweight, and ergonomic for developers. It offers three alternative methods
 for processing JSON:

  * Streaming API inspired by StAX
  * Tree Model
  * Data Binding converts JSON to and from POJOs

 The streaming API is the most performant, but developers might prefer the
 convenience of a mutable in-memory tree representation or the flexibility
 offered by the data binding object mapper.

 This package contains the Jackson core library.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20130810181744.15092.66773.reportbug@asasello.local

Re: Bug#717083: ITP: pychef -- Python library to interact with the Chef server API

[Wolodja Wentland]

On Tue, Jul 16, 2013 at 12:23 -0300, Miguel Landaeta wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Miguel Landaeta 
> 
> * Package name: pychef
>   Version : 0.2.2
>   Upstream Author : Noah Kantrowitz 
> * URL : https://github.com/coderanger/pychef
> * License : BSD
>   Programming Lang: Python
>   Description : Python library to interact with the Chef server API
> 
> (Include the long description here.)

Please provide a suitable long description so that we can review it. I
personally also prefer to not start the synopsis with a capital letter.

A reasonable rule of thumb (stolen from [0]) is that if you replace $name with
the package name and $synopsis with your synopsis in the following sentence it
should make sense:

The package $name provides {a,an,the,some} $synopsis.

[0] http://lintian.debian.org/tags/description-synopsis-starts-with-article.html
-- 
Wolodja 

4096R/CAF14EFC
081C B7CD FF04 2BA9 94EA  36B2 8B7F 7D30 CAF1 4EFC


signature.asc
Description: Digital signature

Re: Bug#716981: ITP: libcore-cache-clojure -- cache abstraction library

[Wolodja Wentland]

On Mon, Jul 15, 2013 at 16:38 +0200, Eugenio Cano-Manuel Mendoza wrote:
> Package: wnpp
> Severity: wishlist
> Owner: "Eugenio Cano-Manuel Mendoza" 
> 
> * Package name: libcore-cache-clojure
>   Version : 0.6.2
>   Upstream Author : Michael Fogus 
> * URL : https://github.com/clojure/core.cache
> * License : EPL-1.0
>   Programming Lang: Java, Clojure
>   Description : cache abstraction library
> 
> core.cache provides a cache abstraction as well as different
> implementations of caching strategies such as FIFO, LRU, TTL, LIRS etc.
> Programmers can also choose to create their own implementation of the
> base cache abstraction and nest different implementations together.

This description needs some love, please make it:

Description : cache abstraction library for Clojure
 core.cache is a Clojure library that provides implementations of basic
 caching strategies such as:
 .
  * First-in-first-out (FIFOCache)
  * Least-recently-used (LRUCache)
  * Least-used (LUCache -- sometimes called Least Frequently Used)
  * Time-to-live (TTLCache)
  * Naïve cache (BasicCache)
  * Naïve cache backed with soft references (SoftCache)
 .
 It also provides an implementation of an efficient buffer replacement policy
 based on the low inter-reference recency set algorithm (LIRSCache).
 .
 All implementation use a common base abstraction (CacheProtocol) which, in
 combination with suitable macros, allows for the easy integration of user
 defined caching strategies that hook into the Clojure associative data
 capabilities.

Thanks!
-- 
Wolodja 

4096R/CAF14EFC
081C B7CD FF04 2BA9 94EA  36B2 8B7F 7D30 CAF1 4EFC


signature.asc
Description: Digital signature

Re: Bug#712908: ITP: stencil-clojure -- implementation of the Mustache template system for Clojure

[Wolodja Wentland]

On Thu, Jun 20, 2013 at 20:09 +0200, Eugenio Cano-Manuel Mendoza wrote:
> Package: wnpp
> Severity: wishlist
> Owner: "Eugenio Cano-Manuel Mendoza" 
> 
> * Package name: stencil-clojure
>   Version : 0.3.2
>   Upstream Author : David Santiago 
> * URL : https://github.com/davidsantiago/stencil
> * License : EPL-1
>   Programming Lang: Clojure, Java
>   Description : implementation of the Mustache template system for Clojure
> 
> Stencil is a Clojure implementation of Mustache, a template system.
> Mustache lacks of control flow statements such as if/else conditionals
> or for loops; it instead features section tag processing lists and
> lambdas. Mustache also enforces a strong separation of logic from
> presentation.

Thanks for working on this, but the description could certainly be improved.
The first step would be something like:

---
 Description : implementation of mustache templates for Clojure
 .
 Stencil is a Clojure implementation of Mustache, a template system.
 Mustache lacks any explicit control flow statements such as if/else
 conditionals or for loops, but instead features section tag processing lists
 and lambdas. Mustache also enforces a strong separation of logic from
 presentation.
---

But I am not too happy about the "section tag processing lists lambdas. Can't
think of anything better right now, but lets find something that makes the
design decisions behind mustache and why one would want to use it a bit
clearer. A good idea is probably to look into the other mustache libraries
(ruby-mustache, libjs-mustache, node-mustache) for inspiration.
-- 
Wolodja 

4096R/CAF14EFC
081C B7CD FF04 2BA9 94EA  36B2 8B7F 7D30 CAF1 4EFC


signature.asc
Description: Digital signature

Re: DM upload permission

[Wolodja Wentland]

On Wed, Mar 06, 2013 at 14:08 +0100, Holger Levsen wrote:
> On Mittwoch, 6. März 2013, Paul Tagliamonte wrote:
> > Fwiw since it is backwards compatible, dput-ng works fine from git in-place

> your point being?

I guess the point is that you can use dput-ng even if you don't want to
replace your "legacy" dput installation just yet.
-- 
Wolodja 

4096R/CAF14EFC
081C B7CD FF04 2BA9 94EA  36B2 8B7F 7D30 CAF1 4EFC


signature.asc
Description: Digital signature

Bug#699546: ITP: libslingshot-clojure -- Enhanced throw and catch library for Clojure

[Wolodja Wentland]

Package: wnpp
Severity: wishlist
Owner: Wolodja Wentland 

* Package name: libslingshot-clojure
  Version : 0.10.3
  Upstream Author : Stephen C. Gilardi 
* URL : https://github.com/scgilardi/slingshot/
* License : EPL-1.0
  Programming Lang: Clojure, Java
  Description : Enhanced throw and catch library for Clojure

 Slingshot is a Clojure library providing enhanced throw and catch replacements
 try+ and throw+.

 Each is 100% compatible with Clojure's and Java's native try and throw both in
 source code and at runtime. Each also provides new capabilities intended to
 improve ease of use by leveraging Clojure's features like maps, records, and
 destructuring. Among them:

* throw+ can throw any Java object, not just those whose class is derived
  from java.lang.Throwable (e.g. Clojure maps or records)

* catch clauses within try+ can catch any Java object thrown by throw+,
  Clojure's throw, or Java's throw

* selectors in catch clauses allow matching on class name, key-value
  vectors, predicates and more

* Information about the context of a throw site is accessible via a hidden
  argument that includes information on, for example, the caught object,
  exception messages and stack traces


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20130201155245.5357.13396.reportbug@asasello.local

Re: git.debian-maintainers.org, or somewhere else

[Wolodja Wentland]

On Thu, Jan 31, 2013 at 18:35 +0200, Regid Ichira wrote:

>   packages.debian.org/source/squeeze/vsftpd is refering to
> http://git.debian-maintainers.org/?p=daniel/vsftpd.git.  The
> reference is in the left column of the page, under the links for
> vsftpd title ( Debian Source Repository (Git) ).
> 
> $ host git.debian-maintainers.org
> Host git.debian-maintainers.org not found: 3(NXDOMAIN)
> 
> Neither packages.debian.org/source/wheezy/vsftpd nor the sid page
> seem to have the Debian Source Repository (Git) entry.  Was the 
> repository transfered to another site?  Is it temporarily not
> avaialble?  Something else?  Should the entry in the squeeze page 
> removed?

The Vcs-* entries have been removed in 2.3.4-1 as you can see in the
changelog:

-- snip --
vsftpd (2.3.4-1) unstable; urgency=low
…
* Removing vcs fields.
…
-- Daniel Baumann   Mon, 05 Sep 
2011 15:55:00 +0200
-- snip --

I am not sure why Daniel decided to remove them or where the package is
maintained now, but that explains the behaviour you see on p.d.o and in the
PTS.

>   Isn't maintaing debian source in a ro public accessible git
> repositories a good idea?

It is a good idea, but it is up to the maintainer to decide how (s)he wants to
maintain her/his packages. Using a git repository certainly isn't mandatory
even though it is quite common these days.

Note that you can always get a source package with, for example, "apt-get
source PKG"
-- 
Wolodja 

4096R/CAF14EFC
081C B7CD FF04 2BA9 94EA  36B2 8B7F 7D30 CAF1 4EFC


signature.asc
Description: Digital signature

Metapackages - What to do with them? (was: debian-ctte Re: Bug#688772: gnome Depends network-manager-gnome)

[Wolodja Wentland]

I am posting this on -devel because I think that it rather belongs here than
in the context of #681834 and the discussion in -ctte

On Sat, Oct 06, 2012 at 09:41 +0200, Josselin Mouette wrote:
> Le vendredi 05 octobre 2012 à 22:07 -0600, Bdale Garbee a écrit : 
> > I personally believe that metapackages should be primarily populated
> > with Recommends, with Depends largely reserved for actual technical
> > dependencies between real packages.

I would like to point you to the last time this suggestion was discussed in
debian-devel [0] as it contains a number of arguments that might otherwise go
unnoticed.

Unfortunately this issue/thread is an amalgamation of a number of
independent issues and it might make sense to discuss them independently. I
can easily make out the following:

1. Is the action to change the network manager dependency in the gnome
   metapackage in the spirit of the CTTE resolution?

2. What is the relation between GNOME and network manager (NM). How
   tightly do they *need* to be coupled and what are the
   technical/usability implications of using GNOME without it.

3. Interoperability of NM with other network configuration
   mechanisms/tools such as /etc/network/interfaces, wicd, manual
   configuration, ... and in particular bugs therein. (i.e. What happens
   if NM gets installed even though the administrator configured the
   network in a different way)

4. How should metapackages be implemented and how should they be treated
   by apt?

5. How should the Desktop task be installed during the initial
   installation and how can users tweak that?

There are probably more, but these pop into my head right now. I do not want
to comment on (1) but it might make sense to discuss the others first as that
might very well make a CTTE resolution redundant. I also can not gauge (2) and
would be happy if members of the Gnome team could comment on that, but (3)
should clearly be discussed within the scope of applicable bug reports that
can then be fixed.

As you might have guessed it is mostly (4) and (5) that are most important to
me and it would IMHO be beneficial to discuss this in a broader scope (maybe
in debian-policy) and codify the decision in the policy.

1. Motivation for a change - What is the problem?
=

The main motivation for a change to the current implementation was given in
[0], the DEP-6 discussion [1] and by Bdale:

>> This is consistent with my belief that we should try to empower our users
>> to be able to exercise a reasonable amount of choice in configuring and
>> operating their Debian systems.

A common argument formulated by the GNOME team (or members thereof) is:

> Maybe you are unfamiliar with what clueless newbies do with their
> systems. You want to empower users, that’s fine; but GNOME is for all
> users. Those who have the technical knowledge to handle their packages
> manually should also know how to make it happen without metapackages.

which is certainly true, but doesn't capture one *very* important aspect. Sure
"clueless users" won't really care and are happy to get a GNOME installation
that packs everything and the kitchen sink. This is good IMHO and encourages
exploration of different software options in a unified and well integrated
environment. It is also true that "advanced users"/"power users"/Debian
Members/Unix beards/… can easily finetune their installation or even create
new personal metapackages, but …

The problematic use case are users who are proficient enough with Debian to
realise that they do not want a set of packages and who try to remove them,
but who do not (yet) know enough about Debian and its actual implementation to
do so. The current implementation makes it incredibly hard (see [2] for 
"solutions")
to finetune a "kitchen sink" systemi). I think that the wish to explore and
finetune a system is typical for new users who get familiar with their system
and they should be encouraged and supported in doing so.

2. What can be done?


Two proposals are commonly made to rectify the situation:

1. Use Recommends in metapackages
2. Treat metapackages differently during removal/purge

After thinking about this I am still convinced that (2.1) is the better
solution as it allows users to remove some packages that were pulled in by a
matapackage without causing its complete removal. I dislike (2.2) because it
means that "apt-get install METAPKG ; apt-get purge METAPKG" does not (in terms 
of
installed packages) change anything. It would essentially mean that there is
no inverse element/action for "install".

Arguments against (2.1) comprise:

* Recommends is wrong for metapackages because it gets upgrades very
  wrong. This is why it is used very marginally. [3]

  Not sure about this and Josselin unfortunately did not elaborate on
  actual problems.

* […] there is the problem that versione

Re: Processor microcode update packages (was: Towards d-i wheezy beta 3)

[Wolodja Wentland]

On Thu, Sep 13, 2012 at 13:45 -0300, Henrique de Moraes Holschuh wrote:
> On Thu, 13 Sep 2012, Nikolaus Rath wrote:

> > I think this should be mentioned somewhere *much* more prominent. I
> > consider myself pretty tech-savy, but only stumbled upon this just now
> > on the this list. Can a non-free package be made essential or
> > required? It seems there is really absolutely no-reason other than
> > non-freeness for not installing this by default.

> It is also worth notice that enabling non-free is not just optional, it is
> officially discouraged: non-free is not even mentioned by the Debian Wheezy
> installer unless you're in expert mode.

The main problem I see is that there seem to be essentially two types of
packages in non-free right now, namely those that contain firmware/microcode
(etc) and are crucial for correctly working hardware and the rest. Most users,
and even those that prefer to install only free software, would probably want
to install all packages from non-free that are appropriate for their hardware.

> And yes, the only reason to not have it installed by default on every x86
> Debian system with an Intel or AMD processor is the non-freeness.

It is quite unfortunate that users who decide to not install non-free software
have to accept the fact that their hardware might work unreliable (if at all).
New users should, however, be made aware of this fact and offered help during
the installation to install appropriate packages. (either by the installer or
by making this explicit in the documentation)
-- 
Wolodja 

4096R/CAF14EFC
081C B7CD FF04 2BA9 94EA  36B2 8B7F 7D30 CAF1 4EFC


signature.asc
Description: Digital signature

Re: Towards d-i wheezy beta 3

[Wolodja Wentland]

On Mon, Sep 10, 2012 at 11:44 +0200, Marco d'Itri wrote:

> Also, we should mention somewhere (the install documentation?) that 
> non-free should be enabled to install microcode fixes which may be 
> critical to maintain the system stability.

Could you elaborate on this please? I have been running systems just fine
even though microcode.ctl (and corresponding microcode) was not installed and
a look at microcode.ctl's popcon [0] confirms that a majority of users do the
same.

If system stability does, in fact, depend *critically* on the presence of
microcode does this also mean that everybody should install it? What are the
implications of not installing it?

[0] http://qa.debian.org/popcon.php?package=microcode.ctl
-- 
Wolodja 

4096R/CAF14EFC
081C B7CD FF04 2BA9 94EA  36B2 8B7F 7D30 CAF1 4EFC


signature.asc
Description: Digital signature

FTBFS bugs against binary packages

[Wolodja Wentland]

Hello,

we are seeing an increasing number of users in #debian-next asking about FTBFS
bugs that are reported by apt-listbugs during upgrades. Most of those users
are not familiar with acronyms such as FTBFS or if these bugs apply to their
setup.

The underlying problem seems to be that a subset of FTBFS bugs are reported
against binary and not source packages, which is something we might want to
address. I think it is better to make sure that FTBFS bugs are reported
against source packages rather than "fixing" apt-listbugs, but I am not
entirely sure what the best approach is.

It is certainly important to spread the word, but implementing such
consistency checks in reportbug/mass-bugs/... might make sense.
-- 
Wolodja 

4096R/CAF14EFC
081C B7CD FF04 2BA9 94EA  36B2 8B7F 7D30 CAF1 4EFC


signature.asc
Description: Digital signature

Re: Bug#648017: ITP: local-file -- small clojure library

[Wolodja Wentland]

Hi Mathieu,

On Tue, Nov 08, 2011 at 12:28 +0100, Mathieu Malaterre wrote:
>   Programming Lang: Java

This should probably be "Clojure" and not "Java" :)
-- 
Wolodja 

4096R/CAF14EFC
081C B7CD FF04 2BA9 94EA  36B2 8B7F 7D30 CAF1 4EFC


signature.asc
Description: Digital signature

Re: Bug#648017: ITP: local-file -- small clojure library

[Wolodja Wentland]

On Tue, Nov 08, 2011 at 12:28 +0100, Mathieu Malaterre wrote:
> 
> * Package name: local-file
>   Version : 0.1.0
>   Upstream Author : Arthur Edelstein
> * URL : https://github.com/arthuredelstein/local-file/
> * License : 
>   Programming Lang: Java
>   Description : small clojure library
> 
>  To use this very small clojure library, add [local-file "0.1.0"] to the
>  dependencies list in your project.clj file. Then call (use 'local-file) or
>  "use" local-file in your (ns...) macro call in a clojure source file.
>  .
>  To get the current clojure project's directory (the parent dir of the source
>  dir) call project-dir with no arguments. The file* function takes a relative
>  path and returns an absolute path relative to the project directory.
>  .
>  To read and write files in a clojure project's directory, use spit* and 
> slurp*
>  with the same signatures as the standard spit and slurp calls.

Some notes:

* Please name the package liblocal-file-clojure as this is in line with the
  naming convention for other clojure libraries such as clucy
  (libclucy-clojure), robert-hooke (librobert-hooke-clojure), ...

* The license is missing in the description even though local_file.clj states
  that it is in the public domain.

  IANAL and not sure if upstream needs to declare this more formally with, for
  example [0]

* The short description should give the reader an idea what this
  package/library can be used for. "small clojure library" is not particularly
  informative and I would replace it by something like upstream's short
  description "Read and write files locally from a clojure program".

* The long description is just a verbatim copy of upstream's README.md and is
  targeted at people who *do not* use the Debian package, but want to install
  it with leiningen. Please write an informative description that gives the
  reader a good idea why (s)he would like to install this package and what it
  could be used for.

All that being said: Thank you for your continuing work on clooj and its
dependencies.

[0] http://www.gnu.org/licenses/license-list.html#CC0
-- 
Wolodja 

4096R/CAF14EFC
081C B7CD FF04 2BA9 94EA  36B2 8B7F 7D30 CAF1 4EFC


signature.asc
Description: Digital signature

Re: DEP5: proposed versioned url for Format: does not work

[Wolodja Wentland]

On Tue, Sep 06, 2011 at 15:46 +0600, Andrey Rahmatullin wrote:
> > DEP5 is in the process of being incorporated into the debian-policy
> > package, and once that is finished, there will be a stable URL to
> > the spec (with a version number in the URL), something like 
> > 
> > http://www.debian.org/debian-policy/copyright-format/1.0/
> > 
> > (But don't use that, since it's not working and might be different
> > from the real one when it actually happens.)
> > 
> > Prior to that, I prefer to not change the spec to incorporate
> > ever-growing numbers of example URLs (especially since when we
> > did that, people complained about that, too).
> > 
> > Until that happens, please use whatever URL you like. I use
> > http://dep.debian.net/deps/dep5/ myself.
> Note that some people think that http://dep.debian.net/deps/dep5/ is not a
> versioned URL and so it doesn't comply to the DEP5 requirement (and while
> DDs can use whatever URLs they like, other people need to guess what URLs
> does their sponsor count as valid).

I used the following for exactly this reason:

Format: http://anonscm.debian.org/viewvc/dep/web/deps/dep5.mdwn?revision=174
-- 
Wolodja 

4096R/CAF14EFC
081C B7CD FF04 2BA9 94EA  36B2 8B7F 7D30 CAF1 4EFC


signature.asc
Description: Digital signature

Re: Dependencies of metapackages

[Wolodja Wentland]

On Tue, Aug 30, 2011 at 17:37 +0200, Yves-Alexis Perez wrote:
> On mar., 2011-08-30 at 16:11 +0100, Wolodja Wentland wrote:
> > 
> > I agree that a general change of all metapackages is probably not a good 
> > idea,
> > but I think that changing the root-nodes of the metapackage tree (i.e.
> > metapackages like gnome, xfce4, kde-full, ...) is a sensible change. It is 
> > in
> > particular one that solves the problems without the need to introduce new
> > package fields, change packaging tools or their semantics. 
> 
> If you think some dependencies in those metapackages are unneeded or too
> strong, you're welcome to open a wishlist bug against them.
> 
> For xfce4, while I'm open to discussion, the distinction between
> depends/recommends/suggests is intended, and at first sight I don't see
> a need to change it.

Could you elaborate on your reasons and your intentions for making the
distinction? Do you have reasons for not changing Depends into Recommends? I
will probably file bugs, but do not want to do so if I already know that the
maintainer is not going to change it. I am sincerely interested and my only
motivation is to make Debian a better distribution.

It is just that I know that the behaviour discussed in this thread is a
nuisance for a subset of our users and I wanted to gather additional input
about different strategies to solve this. I tried to come up with a solution
that does not require changes to the packaging tools, the introduction of new
package fields or constitute a major change in the semantics of packages or
tools.

All that being said: I still have the opinion that metapackages *are*
different from normal and virtual packages and that, in particular, the
relations they define to other packages conflate distinct relations just
because it eases implementation. (which is not inherently bad).
-- 
Wolodja 

4096R/CAF14EFC
081C B7CD FF04 2BA9 94EA  36B2 8B7F 7D30 CAF1 4EFC


signature.asc
Description: Digital signature

Re: Dependencies of metapackages

[Wolodja Wentland]

On Tue, Aug 30, 2011 at 12:32 +0200, Cyril Brulebois wrote:
> Wolodja Wentland  (30/08/2011):
> > It is my impression that the problems mentioned in my initial mail can
> > be solved by changing metapackages (like those mentioned by Cyril in
> > his reply) to use Recommends instead of Depends.
> > 
> > I am, however, not entirely sure if there are any good reasons for not
> > doing this and therefore hoped to spur a discussion of this topic.
> > What is problematic about this change or a general suggestion that
> > metapackages should use Recommends instead of Depends?
> 
> If you do that, you lose the distinction between packages that are
> absolutely required, and those that are only a recommendation, and can
> be skipped by the experienced users.
> 
> If you look at xfce4, you can see it pulls by default xorg (which pulls
> in turn an X server and drivers), and a few extra items which are not
> strictly needed. For example, if you want to run xfce4 with an exported
> display, you don't really need an X server. Or desktop-base support. So
> if you know what you're doing, you can still use the meta package to
> pull the Depends, but skip some if not all Recommends.

Thank you Cyril for mentioning this important point, which unfortunately also
means that almost everything that can be done right now to remedy the
situation is a compromise.

It seems to me that the typical victims of this behaviour are not experienced
users, but those that installed Debian in the default configuration with the
Desktop task. After some time they might have enough experience to decide that
they do not want a certain set of packages, but know nothing about
metapackages and the way they behave. All they see is that "apt" is removing a
huge number of packages if they attempt to remove one of the dependencies.
They would, in the optimal case, know enough about Debian and the various
number of metapackages to be able to work around this problem. Solutions (for
gnome) include:

* Mark all dependencies of the metapackage as manually installed:

aptitude unmarkauto '~R^gnome$' '~RRecommends:^gnome$'

* Install one of the smaller metapackages like gnome-session and/or
  explicitly mark packages they want to keep as manually installed.

* Accept the "fact" that a particular package can not be removed without
  "breaking" their system.

You are completely right that the distinction between required packages and
recommendations is lost if the (large?) metapackages use Recommends for both
types of dependencies. I see metapackages as convenience packages that allow
the user to easily specify a set of related packages and would argue that what
is really needed for, say, Gnome is specified in the gnome-session metapackage
not the gnome package.

IMHO it is much easier for experienced users to achieve what you described in
your penultimate sentence than it is for inexperienced users to slim down
their system. So, what can be done to make life easier for all those users
that are bitten by this?

* Change large metapackages to Recommend rather then Depend on sets of
  packages that comprise a certain task.

  - Experienced users can not use these packages to only install required
packages.

→ What is really essential in these packages that is not already
  combined in a smaller metapackage?
→ Experienced users can easily specify the exact set of packages
  they want without these metapackages.

  + Inexperienced users can easily trim down their system without seeing
the interface they use to communicate with the computer being removed.

* Change the way metapackages are treated by packaging tools

  - I really dislike this idea (cf. DEP-6 thread)

* Change d-i to incorporate a more fine-grained package/task selection

- More complicated installation
- Complete removal of "gnome" is harder as multiple metapackage might
  have to be removed. (i.e. all manually selected)
- Only applies to initial installations

* Do not change anything.
* ... (?)

I agree that a general change of all metapackages is probably not a good idea,
but I think that changing the root-nodes of the metapackage tree (i.e.
metapackages like gnome, xfce4, kde-full, ...) is a sensible change. It is in
particular one that solves the problems without the need to introduce new
package fields, change packaging tools or their semantics.
-- 
Wolodja 

4096R/CAF14EFC
081C B7CD FF04 2BA9 94EA  36B2 8B7F 7D30 CAF1 4EFC


signature.asc
Description: Digital signature

Re: Dependencies of metapackages

[Wolodja Wentland]

On Tue, Aug 30, 2011 at 09:26 +0200, Andreas Tille wrote:
> On Mon, Aug 29, 2011 at 04:40:30PM +0100, Wolodja Wentland wrote:
> > is there a specific reason why metapackages depend rather then recommend
> > packages they are meant to pull in?

> The statement that metapackages depend from packages is not true in
> general.  A counter example are those metapackages which are created
> using the Blends framework (blends-dev).  It does not use Depends but
> rather Recommends and Suggests - basically for the reasons you are
> criticising in your mail.

I never meant to imply that *all* metapackages use Depends. I just know from
my experience with support in #debian that users frequently run into the
problems I described earlier and my motivation is merely to make Debian a more
pleasant and intuitively predictable distribution for our users.

It is my impression that the problems mentioned in my initial mail can be
solved by changing metapackages (like those mentioned by Cyril in his
reply) to use Recommends instead of Depends.

I am, however, not entirely sure if there are any good reasons for not doing
this and therefore hoped to spur a discussion of this topic. What is
problematic about this change or a general suggestion that metapackages should
use Recommends instead of Depends?
-- 
Wolodja 

4096R/CAF14EFC
081C B7CD FF04 2BA9 94EA  36B2 8B7F 7D30 CAF1 4EFC


signature.asc
Description: Digital signature

Dependencies of metapackages

[Wolodja Wentland]

Hi all,

is there a specific reason why metapackages depend rather then recommend
packages they are meant to pull in?

The rationale behind this question is [0] that we see a plethora of users in
#debian who ask questions like:

"Why did apt remove all my system??⸘one!one!eleven!"

and we have to explain to them that it is because they decided to remove one
of (typically) gnome's dependencies, which caused the metapackage to be
removed as well. The solution is then to either mark all other dependencies as
manually installed, install a smaller metapackage or a combination of those.

As this is a common problem of our users I was thinking why we don't make it
easier for them to slim down their system after they've done a default
installation. Are there any drawbacks to this change in metapackage semantics
that I am not aware of?

[0] The rationale is also more or less the same as the one formulated for
DEP-6
http://dep.debian.net/deps/dep6/
-- 
Wolodja 

4096R/CAF14EFC
081C B7CD FF04 2BA9 94EA  36B2 8B7F 7D30 CAF1 4EFC


signature.asc
Description: Digital signature

Re: The story behind UPG and umask.

[Wolodja Wentland]

On Wed, May 26, 2010 at 23:43 +0100, Stephen Gran wrote:
> This one time, at band camp, Roger Leigh said:
> > How will adduser cope with group addition; does it skip UIDs until
> > it finds an unused unique UID/GID pair?

> That certainly is the only approach that makes sense - it has the
> benefit of simplicity, if not elegance.

Agreed, but why not make the decision to use UPG explicit by setting
"UPG = True" in a suitable configuration file in addition to each of the
discussed heuristics?
-- 
  .''`. Wolodja Wentland 
 : :'  :
 `. `'` 4096R/CAF14EFC 
   `-   081C B7CD FF04 2BA9 94EA  36B2 8B7F 7D30 CAF1 4EFC


signature.asc
Description: Digital signature